Ls1043ardb U-boot cannot find Ethernet firmware

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Ls1043ardb U-boot cannot find Ethernet firmware

Jump to solution
3,306 Views
brandensherrell
Contributor III

I booted into the default bank and made changes to the alternate bank per page 100 of the Release-Notes​ outlined to push a new U-boot build. The steps for doing so require that you first unprotect the target region of flash, which worked properly. However, somehow during the process of modifying the alternate-bank memory space, the default bank was corrupted despite it being in a protected area of memory -- or at least so it seems. Specifically, the following is now displayed on boot:

Boot-time display

U-Boot 2015.01QorIQ-SDK-V1.7+gc297f5b (Dec 20 2015 - 13:08:26)

Clock Configuration:

       CPU0(A53):1600 MHz  CPU1(A53):1600 MHz  CPU2(A53):1600 MHz 

       CPU3(A53):1600 MHz 

       Bus:      400  MHz  DDR:      1600 MT/s  FMAN:     500  MHz

Reset Configuration Word (RCW):

       00000000: 08100010 0a000000 00000000 00000000

       00000010: 14550002 80004012 e0025000 c1002000

       00000020: 00000000 00000000 00000000 00038800

       00000030: 00000000 00001101 00000096 00000001

Board: LS1043ARDB, boot from vBank 0

CPLD:  V1.4

PCBA:  V3.0

SERDES Reference Clocks:

SD1_CLK1 = 156.25MHZ, SD1_CLK2 = 100.00MHZ

I2C:   ready

DRAM:  Initializing DDR....

Detected UDIMM Fixed DDR on board

2 GiB (DDR4, 32-bit, CL=11, ECC off)

fsl-ppa: Bad firmware image (not a FIT image)

fsl-ppa: error (-22)

Not a microcode

Using SERDES1 Protocol: 5205 (0x1455)

fman_port_enet_if:71: port(FM1_DTSEC3) is OK

fman_port_enet_if:77: port(FM1_DTSEC4) is OK

Flash: 128 MiB

NAND:  512 MiB

MMC:   FSL_SDHC: 0

EEPROM: NXID v1

PCIe1: disabled

PCIe2: Root Complex no link, regs @ 0x3500000

PCIe3: Root Complex no link, regs @ 0x3600000

In:    serial

Out:   serial

Err:   serial

Net:   Fman1: Data at 0000000060300000 is not a firmware

No ethernet found.

Hit any key to stop autoboot:  0

I am not sure how the bank0 address space was modified, but apparently it was given the errors presented at boot. These errors seemed to stem from the fact that the U-boot environment was overwritten in the first bank -- but it can clearly be seen that the build time-stamp was December 20 (implying the original factory U-boot image is still present), while the alternate bank time-stamp (the new build I flashed) is March, as expected. Thankfully I have a second unmodified ls1043arb on-hand and was able to restore each variable to the original state as seen below:

Contents of U-boot environment variables

baudrate=115200

bootargs=console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,0x21c0500,115200

bootcmd=cp.b $kernel_start $kernel_load $kernel_size && bootm $kernel_load

bootdelay=3

console=ttyAMA0,38400n8

eth1addr=00:04:9F:04:1E:7A

eth2addr=00:04:9F:04:1E:7B

eth3addr=00:04:9F:04:1E:7C

eth4addr=00:04:9F:04:1E:7D

eth5addr=00:04:9F:04:1E:7E

eth6addr=00:04:9F:04:1E:7F

ethaddr=00:04:9F:04:1E:79

ethprime=FM1@DTSEC3

fdt_high=0xffffffffffffffff

fman_ucode=60300000

hwconfig=fsl_ddr:bank_intlv=auto

initrd_high=0xffffffffffffffff

kernel_addr=0x100000

kernel_load=0xa0000000

kernel_size=0x2800000

kernel_start=0x61100000

loadaddr=0x80100000

ramdisk_addr=0x800000

ramdisk_size=0x2000000

stderr=serial

stdin=serial

stdout=serial

Environment size: 778/131068 bytes

However, such changes did not solve the problem of U-boot being unable to find the various firmware sources. I also noticed that regardless of the value of fman_ucode in the U-boot environment will seemingly always look at 0x60300000 as the region for the fman firmware (what is this?) -- even when booting into the alternate bank despite its respective "fman_ucode" environment variable being something different.

Solving this problem would be made much easier is U-boot could find the Ethernet firmware since I could then leverage the TFTP capabilities and re-flash the device.

1) What are my other options here if I do not have a JTAG programmer? What JTAG programmer could be used to modify the CPLD flash memory? I do have a Dstream ARM debug unit if it can be used.

2) I do have a second LS1043arb on hand with the original factory flash image.

3) Am I doing something incorrect when attempting to re-flash the alternate bank?

Labels (1)
1 Solution
2,121 Views
ufedor
NXP Employee
NXP Employee

The whole SDRAM is filled by "deadbeef" during the memory initialization.

It could be that wrong "filesize" parameter was specified for the "cp.b" command and the firmware area was overwritten by contents of unused SDRAM area.

In the current state the board could be recovered by the CodeWarrior Flash Programmer tool.

View solution in original post

0 Kudos
6 Replies
2,121 Views
ufedor
NXP Employee
NXP Employee

> These errors seemed to stem from the fact that the U-boot environment was overwritten

The error message is about the FMan firmware absence at the address 0x60300000.

The firmware (ucode) is required for normal FMan operation.

Please refer to the Table 3-6. NOR Flash Memory Mapin the RN document for the ucode placement:

0x60300000 - 0x603FFFFF bank0 Fman ucode

0x64300000 - 0x643FFFFF bank4 Fman ucode (alternate)

After you've got "Net:   Fman1: Data at 0000000060300000 is not a firmware" please execute "cpld reset altbank" and provide the log.

2,121 Views
brandensherrell
Contributor III

Thanks for the quick response.

Resetting to the alternate bank gives identical log results.

U-Boot 2015.01QorIQ-SDK-V1.7+gc297f5b (Mar 11 2016 - 15:23:01)

Clock Configuration:

       CPU0(A53):1600 MHz  CPU1(A53):1600 MHz  CPU2(A53):1600 MHz 

       CPU3(A53):1600 MHz 

       Bus:      400  MHz  DDR:      1600 MT/s  FMAN:     500  MHz

Reset Configuration Word (RCW):

       00000000: 08100010 0a000000 00000000 00000000

       00000010: 14550002 80004012 e0025000 c1002000

       00000020: 00000000 00000000 00000000 00038800

       00000030: 00000000 00001101 00000096 00000001

Board: LS1043ARDB, boot from vBank 4

CPLD:  V1.4

PCBA:  V3.0

SERDES Reference Clocks:

SD1_CLK1 = 156.25MHZ, SD1_CLK2 = 100.00MHZ

I2C:   ready

DRAM:  Initializing DDR....

Detected UDIMM Fixed DDR on board

2 GiB (DDR4, 32-bit, CL=11, ECC off)

fsl-ppa: Bad firmware image (not a FIT image)

fsl-ppa: error (-22)

Not a microcode

Using SERDES1 Protocol: 5205 (0x1455)

fman_port_enet_if:71: port(FM1_DTSEC3) is OK

fman_port_enet_if:77: port(FM1_DTSEC4) is OK

Flash: 128 MiB

NAND:  512 MiB

MMC:   FSL_SDHC: 0

EEPROM: NXID v1

PCIe1: disabled

PCIe2: Root Complex no link, regs @ 0x3500000

PCIe3: Root Complex no link, regs @ 0x3600000

In:    serial

Out:   serial

Err:   serial

Net:   Fman1: Data at 0000000060300000 is not a firmware

No ethernet found.

Hit any key to stop autoboot:  0

Where the environment variables are:

baudrate=115200

bootargs=console=ttyS0,115200 root=/dev/ram0 earlycon=uart8250,0x21c0500,115200

bootcmd=cp.b $kernel_start $kernel_load $kernel_size && bootm $kernel_load

bootdelay=3

console=ttyAMA0,38400n8

eth1addr=00:04:9F:04:1E:7A

eth2addr=00:04:9F:04:1E:7B

eth3addr=00:04:9F:04:1E:7C

eth4addr=00:04:9F:04:1E:7D

eth5addr=00:04:9F:04:1E:7E

eth6addr=00:04:9F:04:1E:7F

ethaddr=00:04:9F:04:1E:79

ethprime=e1000#0

fdt_high=0xffffffffffffffff

fman_ucode=64300000

hwconfig=fsl_ddr:bank_intlv=auto

initrd_high=0xffffffffffffffff

kernel_addr=0x100000

kernel_load=0xa0000000

kernel_size=0x2800000

kernel_start=0x65100000

loadaddr=0x80100000

ramdisk_addr=0x800000

ramdisk_size=0x2000000

stderr=serial

stdin=serial

stdout=serial

For some reason we still get

Net:   Fman1: Data at 0000000060300000 is not a firmware

Despite the related environment variable being

fman_ucode=64300000

0 Kudos
2,120 Views
ufedor
NXP Employee
NXP Employee

This seems to be a bug in the SDK v0.4 (it is possible to download the SDK v0.5 after applying search key "LS1043A SDK" in the NXP website search).

Please execute "md 64300000" on a problem board and "md 60300000" on the second unmodified ls1043arb.

0 Kudos
2,120 Views
brandensherrell
Contributor III

I used the latest SDK (V0.5) to build this second U-boot image. How could you tell from the log which SDK version was used? The first line shows V1.7.

U-Boot 2015.01QorIQ-SDK-V1.7+gc297f5b

Unmodified ls1043ardb

=> md 64300000

64300000: a07e0000 01464551 7263694d 646f636f    ..~.QEF.Microcod

64300010: 65762065 6f697372 3031206e 2e342e36    e version 106.4.

64300020: 66203731 5420726f 30383032 2e317220    17 for T2080 r1.

64300030: 00000031 00000000 00000000 00000000    1..............00000    ................

643000c0: 00000000 00000000 00000000 00000000    ................

643000d0: 00000000 00000000..............

64300060: 00000000 00000000 00000000 00000000    ................

64300070: 00000000 00000000 00000000 7263694d    ............Micr

64300080: 646f636f 6f662065 32542072 20303830    ocode for T2080

64300090: 312e3172 00000000 00000000 00000000    r1.1............

643000a0: 00000000 00000000 00000000 00000000    ................

643000b0: 00000000 00000000 00000000 00000000    ................

643000c0: 00000000 00000000 00000000 00000000    ................

643000d0: 00000000 00000000 00000000 00008020    ............ ...

643000e0: 00000000 6a1f0000 f4000000 0011046a    .......j....j...

643000f0: 00000000 b101ffb7 11046a00 c501ffb7    .........j......

=> md 60300000

60300000: a07e0000 01464551 7263694d 646f636f    ..~.QEF.Microcod

60300010: 65762065 6f697372 3031206e 2e342e36    e version 106.4.

60300020: 66203731 5420726f 30383032 2e317220    17 for T2080 r1.

60300030: 00000031 00000000 00000000 00000000    1...............

60300040: 00000000 01000000 01012008 00000000    ......... ......

60300050: 00000000 00000000 00000000 00000000    ................

60300060: 00000000 00000000 00000000 00000000    ................

60300070: 00000000 00000000 00000000 7263694d    ............Micr

60300080: 646f636f 6f662065 32542072 20303830    ocode for T2080

60300090: 312e3172 00000000 00000000 00000000    r1.1............

603000a0: 00000000 00000000 00000000 00000000    ................

603000b0: 00000000 00000000 00000000 00000000    ................

603000c0: 00000000 00000000 00000000 00000000    ................

603000d0: 00000000 00000000 00000000 00008020    ............ ...

603000e0: 00000000 6a1f0000 f4000000 0011046a    .......j....j...

603000f0: 00000000 b101ffb7 11046a00 c501ffb7    .........j......

Modified ls1043ardb

=> md 64300000

64300000: deadbeef deadbeef deadbeef deadbeef    ................

...

=> md 60300000

60300000: ffffffff ffffffff ffffffff ffffffff    ................

...

I am not sure what happened with 0x64300000, but 0x60300000 was clearly erased.

0 Kudos
2,122 Views
ufedor
NXP Employee
NXP Employee

The whole SDRAM is filled by "deadbeef" during the memory initialization.

It could be that wrong "filesize" parameter was specified for the "cp.b" command and the firmware area was overwritten by contents of unused SDRAM area.

In the current state the board could be recovered by the CodeWarrior Flash Programmer tool.

0 Kudos
2,121 Views
brandensherrell
Contributor III

Thank you for your help with this. I was able to restore the device by copying the fman code from the original unmodified ls1043ardb, copying the contents into DRAM, and then cp'ing the data to flash.

0 Kudos