* Booting from NAND on an Armada-370 based machine -> Invalid header checksum
@ 2021-09-05 15:48 Uwe Kleine-König
2021-09-05 16:20 ` Pali Rohár
0 siblings, 1 reply; 3+ messages in thread
From: Uwe Kleine-König @ 2021-09-05 15:48 UTC (permalink / raw)
To: Pali Rohár, Marek Behún, Stefan Roese, Chris Packham; +Cc: u-boot
[-- Attachment #1: Type: text/plain, Size: 3539 bytes --]
Hello,
I'm trying to unbrick a Netgear ReadyNAS 104 (Armada 370). (I
accidentally erased the u-boot partition in NAND when I tried to change
the NAND partitioning to make the Debian bullseye kernel+initramfs fit.)
I have the Vendor U-Boot image that I can boot using kwboot. Its first
byte is 0x8b which is the right for NAND booting. The image's size is
0xda548 bytes.
I wrote the image to the start of NAND and verified it to be correctly
written:
Marvell>> nand read 0x2100000 0 0xda548
NAND read: device 0 offset 0x0, size 0xda548
894280 bytes read: OK
Marvell>> dhcp
egiga1 wait for link .Done - link up.
...
DHCP client bound to address 192.168.77.145
Marvell>> tftp 0x2000000 192.168.77.175:u-boot-rn104-2.0.img
Using egiga1 device
TFTP from server 192.168.77.175; our IP address is 192.168.77.145
Filename 'u-boot-rn104-2.0.img'.
Load address: 0x2000000
Loading: #############################################################
done
Bytes transferred = 894280 (da548 hex)
Marvell>> cmp.b 0x2000000 0x2100000 0xda548
Total of 894280 bytes were the same
There are no bad blocks in this area.
Also the checksum is right as far as I understand:
$ python3
...
>>> a = open("/srv/tftp/u-boot-rn104-2.0.img", "rb")
>>> data = a.read(0x14000)
>>> len(data)
81920
>>> hex(sum(data[:31]) + sum(data[32:]))
'0x79f616'
So the checksum field should be 0x16 (at offset 31), which it is:
Marvell>> md.b 0x2100000
02100000: 8b 00 00 00 48 65 0c 00 01 01 00 40 00 40 01 00 ....He.....@.@..
02100010: 00 00 00 00 00 00 00 00 00 02 01 00 00 00 01 16 ................
02100020: 02 01 18 35 02 00 00 00 5b 00 00 00 00 00 00 00 ...5....[.......
02100030: ff 5f 2d e9 1c 00 00 fa 00 00 a0 e3 ff 9f bd e8 ._-.............
Still when trying to boot I get:
BootROM 1.08
Booting from NAND flash
BootROM: Invalid header checksum
BootROM: Bad header at offset 00010000
BootROM: Bad header at offset 00020000
BootROM: Bad header at offset 00030000
BootROM: Bad header at offset 00040000
BootROM: Bad header at offset 00050000
BootROM: Bad header at offset 00060000
BootROM: Bad header at offset 00070000
BootROM: Bad header at offset 00080000
BootROM: Bad header at offset 00090000
BootROM: Bad header at offset 000A0000
BootROM: Bad header at offset 000B0000
BootROM: Bad header at offset 000C0000
BootROM: Bad header at offset 000D0000
BootROM: Bad header at offset 000E0000
BootROM: Bad header at offset 000F0000
BootROM: Bad header at offset 00100000
BootROM: Bad header at offset 00110000
BootROM: Bad header at offset 00120000
BootROM: Bad header at offset 00130000
BootROM: Bad header at offset 00140000
BootROM: Bad header at offset 00150000
BootROM: Bad header at offset 00160000
BootROM: Bad header at offset 00170000
BootROM: Bad header at offset 00180000
BootROM: Bad header at offset 00190000
BootROM: Bad header at offset 001A0000
BootROM: Bad header at offset 001B0000
BootROM: Bad header at offset 001C0000
BootROM: Bad header at offset 001D0000
BootROM: Bad header at offset 001E0000
BootROM: Bad header at offset 001F0000
BootROM: Bad header at offset 00200000
BootROM: Bad header at offset 00210000
BootROM: Bad header at offset 00220000
...
Is there anything obvious I'm missing or doing wrong? Does "Invalid
header checksum" indicate that the 0x16 is wrong or is there another
checksum anywhere that I missed? Any other idea?
If you have an idea and prefer irc over email, I hang around e.g. in
#mvlinux on libera as ukleinek.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Booting from NAND on an Armada-370 based machine -> Invalid header checksum
2021-09-05 15:48 Booting from NAND on an Armada-370 based machine -> Invalid header checksum Uwe Kleine-König
@ 2021-09-05 16:20 ` Pali Rohár
2021-09-06 22:39 ` Uwe Kleine-König
0 siblings, 1 reply; 3+ messages in thread
From: Pali Rohár @ 2021-09-05 16:20 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Marek Behún, Stefan Roese, Chris Packham, u-boot
Hello!
On Sunday 05 September 2021 17:48:16 Uwe Kleine-König wrote:
> Hello,
>
> I'm trying to unbrick a Netgear ReadyNAS 104 (Armada 370). (I
> accidentally erased the u-boot partition in NAND when I tried to change
> the NAND partitioning to make the Debian bullseye kernel+initramfs fit.)
>
> I have the Vendor U-Boot image that I can boot using kwboot. Its first
> byte is 0x8b which is the right for NAND booting. The image's size is
> 0xda548 bytes.
>
> I wrote the image to the start of NAND and verified it to be correctly
> written:
>
> Marvell>> nand read 0x2100000 0 0xda548
>
> NAND read: device 0 offset 0x0, size 0xda548
> 894280 bytes read: OK
>
> Marvell>> dhcp
> egiga1 wait for link .Done - link up.
> ...
> DHCP client bound to address 192.168.77.145
>
> Marvell>> tftp 0x2000000 192.168.77.175:u-boot-rn104-2.0.img
> Using egiga1 device
> TFTP from server 192.168.77.175; our IP address is 192.168.77.145
> Filename 'u-boot-rn104-2.0.img'.
> Load address: 0x2000000
> Loading: #############################################################
> done
> Bytes transferred = 894280 (da548 hex)
>
> Marvell>> cmp.b 0x2000000 0x2100000 0xda548
> Total of 894280 bytes were the same
>
> There are no bad blocks in this area.
>
> Also the checksum is right as far as I understand:
>
> $ python3
> ...
> >>> a = open("/srv/tftp/u-boot-rn104-2.0.img", "rb")
> >>> data = a.read(0x14000)
> >>> len(data)
> 81920
> >>> hex(sum(data[:31]) + sum(data[32:]))
> '0x79f616'
>
> So the checksum field should be 0x16 (at offset 31), which it is:
>
> Marvell>> md.b 0x2100000
> 02100000: 8b 00 00 00 48 65 0c 00 01 01 00 40 00 40 01 00 ....He.....@.@..
So...
Image version = 0x01
Header Size MSB = 0x01
Header Size LSB = 0x00 0x40 = 0x4000
So header size is 0x014000 = 81920
> 02100010: 00 00 00 00 00 00 00 00 00 02 01 00 00 00 01 16 ................
Checksum = 0x16
Which seems that the header checksum is correct.
> 02100020: 02 01 18 35 02 00 00 00 5b 00 00 00 00 00 00 00 ...5....[.......
> 02100030: ff 5f 2d e9 1c 00 00 fa 00 00 a0 e3 ff 9f bd e8 ._-.............
>
> Still when trying to boot I get:
>
> BootROM 1.08
> Booting from NAND flash
> BootROM: Invalid header checksum
> BootROM: Bad header at offset 00010000
> BootROM: Bad header at offset 00020000
> BootROM: Bad header at offset 00030000
> BootROM: Bad header at offset 00040000
> BootROM: Bad header at offset 00050000
> BootROM: Bad header at offset 00060000
> BootROM: Bad header at offset 00070000
> BootROM: Bad header at offset 00080000
> BootROM: Bad header at offset 00090000
> BootROM: Bad header at offset 000A0000
> BootROM: Bad header at offset 000B0000
> BootROM: Bad header at offset 000C0000
> BootROM: Bad header at offset 000D0000
> BootROM: Bad header at offset 000E0000
> BootROM: Bad header at offset 000F0000
> BootROM: Bad header at offset 00100000
> BootROM: Bad header at offset 00110000
> BootROM: Bad header at offset 00120000
> BootROM: Bad header at offset 00130000
> BootROM: Bad header at offset 00140000
> BootROM: Bad header at offset 00150000
> BootROM: Bad header at offset 00160000
> BootROM: Bad header at offset 00170000
> BootROM: Bad header at offset 00180000
> BootROM: Bad header at offset 00190000
> BootROM: Bad header at offset 001A0000
> BootROM: Bad header at offset 001B0000
> BootROM: Bad header at offset 001C0000
> BootROM: Bad header at offset 001D0000
> BootROM: Bad header at offset 001E0000
> BootROM: Bad header at offset 001F0000
> BootROM: Bad header at offset 00200000
> BootROM: Bad header at offset 00210000
> BootROM: Bad header at offset 00220000
> ...
>
> Is there anything obvious I'm missing or doing wrong? Does "Invalid
> header checksum" indicate that the 0x16 is wrong or is there another
> checksum anywhere that I missed? Any other idea?
Image version 1 has only one header checksum (at 0x1F) and one data
checksum (4 bytes at the end of data image). But data checksum can be
verified only after loading data image to the RAM, which can happen only
after executing binary headers. If you are using standard DDR training
(prevent in binary headers) then it should print some debug log on UART.
And if you do not see it then error should refer to header checksum at
0x1F offset.
Could you run latest version of 'mkimage -l' from U-Boot git master on
your image to verify that image is really valid?
> If you have an idea and prefer irc over email, I hang around e.g. in
> #mvlinux on libera as ukleinek.
>
> Best regards
> Uwe
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Booting from NAND on an Armada-370 based machine -> Invalid header checksum
2021-09-05 16:20 ` Pali Rohár
@ 2021-09-06 22:39 ` Uwe Kleine-König
0 siblings, 0 replies; 3+ messages in thread
From: Uwe Kleine-König @ 2021-09-06 22:39 UTC (permalink / raw)
To: Pali Rohár; +Cc: Marek Behún, Stefan Roese, Chris Packham, u-boot
[-- Attachment #1.1: Type: text/plain, Size: 5363 bytes --]
Hello,
first of all thanks for your reply and also your ideas on irc.
The machine started to properly boot now after I changed the UART-to-USB
adapter. (The first one I used stopped providing the /dev/ttyUSB0 device
on my host machine and got quite hot.)
Maybe this is related to the UART TX pin being a bootstrap pin that
selects the boot medium and the used mode!?
My answers below just for the record ...
On 9/5/21 6:20 PM, Pali Rohár wrote:
> On Sunday 05 September 2021 17:48:16 Uwe Kleine-König wrote:
>> I'm trying to unbrick a Netgear ReadyNAS 104 (Armada 370). (I
>> accidentally erased the u-boot partition in NAND when I tried to change
>> the NAND partitioning to make the Debian bullseye kernel+initramfs fit.)
>>
>> I have the Vendor U-Boot image that I can boot using kwboot. Its first
>> byte is 0x8b which is the right for NAND booting. The image's size is
>> 0xda548 bytes.
>>
>> I wrote the image to the start of NAND and verified it to be correctly
>> written:
>>
>> Marvell>> nand read 0x2100000 0 0xda548
>>
>> NAND read: device 0 offset 0x0, size 0xda548
>> 894280 bytes read: OK
>>
>> Marvell>> dhcp
>> egiga1 wait for link .Done - link up.
>> ...
>> DHCP client bound to address 192.168.77.145
>>
>> Marvell>> tftp 0x2000000 192.168.77.175:u-boot-rn104-2.0.img
>> Using egiga1 device
>> TFTP from server 192.168.77.175; our IP address is 192.168.77.145
>> Filename 'u-boot-rn104-2.0.img'.
>> Load address: 0x2000000
>> Loading: #############################################################
>> done
>> Bytes transferred = 894280 (da548 hex)
>>
>> Marvell>> cmp.b 0x2000000 0x2100000 0xda548
>> Total of 894280 bytes were the same
>>
>> There are no bad blocks in this area.
>>
>> Also the checksum is right as far as I understand:
>>
>> $ python3
>> ...
>> >>> a = open("/srv/tftp/u-boot-rn104-2.0.img", "rb")
>> >>> data = a.read(0x14000)
>> >>> len(data)
>> 81920
>> >>> hex(sum(data[:31]) + sum(data[32:]))
>> '0x79f616'
>>
>> So the checksum field should be 0x16 (at offset 31), which it is:
>>
>> Marvell>> md.b 0x2100000
>> 02100000: 8b 00 00 00 48 65 0c 00 01 01 00 40 00 40 01 00 ....He.....@.@..
>
> So...
> Image version = 0x01
> Header Size MSB = 0x01
> Header Size LSB = 0x00 0x40 = 0x4000
>
> So header size is 0x014000 = 81920
>
>> 02100010: 00 00 00 00 00 00 00 00 00 02 01 00 00 00 01 16 ................
>
> Checksum = 0x16
>
> Which seems that the header checksum is correct.
>
>> 02100020: 02 01 18 35 02 00 00 00 5b 00 00 00 00 00 00 00 ...5....[.......
>> 02100030: ff 5f 2d e9 1c 00 00 fa 00 00 a0 e3 ff 9f bd e8 ._-.............
>>
>> Still when trying to boot I get:
>>
>> BootROM 1.08
>> Booting from NAND flash
>> BootROM: Invalid header checksum
>> BootROM: Bad header at offset 00010000
>> BootROM: Bad header at offset 00020000
>> BootROM: Bad header at offset 00030000
>> BootROM: Bad header at offset 00040000
>> BootROM: Bad header at offset 00050000
>> BootROM: Bad header at offset 00060000
>> BootROM: Bad header at offset 00070000
>> BootROM: Bad header at offset 00080000
>> BootROM: Bad header at offset 00090000
>> BootROM: Bad header at offset 000A0000
>> BootROM: Bad header at offset 000B0000
>> BootROM: Bad header at offset 000C0000
>> BootROM: Bad header at offset 000D0000
>> BootROM: Bad header at offset 000E0000
>> BootROM: Bad header at offset 000F0000
>> BootROM: Bad header at offset 00100000
>> BootROM: Bad header at offset 00110000
>> BootROM: Bad header at offset 00120000
>> BootROM: Bad header at offset 00130000
>> BootROM: Bad header at offset 00140000
>> BootROM: Bad header at offset 00150000
>> BootROM: Bad header at offset 00160000
>> BootROM: Bad header at offset 00170000
>> BootROM: Bad header at offset 00180000
>> BootROM: Bad header at offset 00190000
>> BootROM: Bad header at offset 001A0000
>> BootROM: Bad header at offset 001B0000
>> BootROM: Bad header at offset 001C0000
>> BootROM: Bad header at offset 001D0000
>> BootROM: Bad header at offset 001E0000
>> BootROM: Bad header at offset 001F0000
>> BootROM: Bad header at offset 00200000
>> BootROM: Bad header at offset 00210000
>> BootROM: Bad header at offset 00220000
>> ...
>>
>> Is there anything obvious I'm missing or doing wrong? Does "Invalid
>> header checksum" indicate that the 0x16 is wrong or is there another
>> checksum anywhere that I missed? Any other idea?
>
> Image version 1 has only one header checksum (at 0x1F) and one data
> checksum (4 bytes at the end of data image). But data checksum can be
> verified only after loading data image to the RAM, which can happen only
> after executing binary headers. If you are using standard DDR training
> (prevent in binary headers) then it should print some debug log on UART.
The binary header that is responsible to setup DRAM indeed prints some
info to the UART and this wasn't printed in the failing state.
> And if you do not see it then error should refer to header checksum at
> 0x1F offset.
ack
> Could you run latest version of 'mkimage -l' from U-Boot git master on
> your image to verify that image is really valid?
I did that and it didn't show any problems.
Best regards
Uwe
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-09-07 18:27 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-05 15:48 Booting from NAND on an Armada-370 based machine -> Invalid header checksum Uwe Kleine-König
2021-09-05 16:20 ` Pali Rohár
2021-09-06 22:39 ` Uwe Kleine-König
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.