kwboot: Marvell Dove UART booting
Hi all,
With great help from Pali, I've made some good progress on kwboot the HP Thin Client T5335z (Marvell Dove SoC) board. I had been unsuccessful running kwboot with this box until Pali pointed out a few important aspects of the Dove SoC, and how the BootROM commands work (my apology for forgetting to include the u-boot-mailing list and Marek on previous email exchanges).
Here is the summary of the attempt to kwboot.
HP Thin Client T5335z Marvell Dove SoC 88AP510 (A1) 1Ghz CPU 1 GB RAM
- Reset Strapping:
As with all Dove SoCs, there is no preamble when we send the u-boot image over the serial line. IOW, no magic handshake string to tell the BootROM that we are booting over UART. Instead, the hardware must explicitly set to UART mode booting. For boards like the Solidrun Cubox, there is a button, and some other board, a DIP switch, to enable this mode. For the T55335z, there is no button or DIP switch on the board for that purpose. Instead, there is a jumper (the exact purpose is unknown), but I found that this jumper will put the BootROM into debug mode. And from the BootROM debug prompt, we can execute a command to set the boot mode to UART with "x command.
Here is the log and my commentary starting with ***
<Begin log>
*** With jumper inserted, serial console connected, start serial console
# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready
*** Hit <Enter> here to get to the prompt and execute "x 0x0E"
Bootstrap 2.33> Bootstrap 2.33>x 0x0E
*** No more input possible here, so Control-A-X to exit serial console
Terminating... Thanks for using picocom
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................] <snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload. *** *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
- My comments in response:
Indeed. I've seen that in the Functional Spec, too. The mdt0 binwalk also shows what looks like the extension header.
DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 118161 0x1CD91 Certificate in DER format (x509 v3), header length: 4, sequence length: 3 199169 0x30A01 Certificate in DER format (x509 v3), header length: 4, sequence length: 5464 380652 0x5CEEC CRC32 polynomial table, little endian 387072 0x5E800 CRC32 polynomial table, little endian 608166 0x947A6 LZMA compressed data, properties: 0x66, dictionary size: 0 bytes, uncompressed size: 147351982848 bytes
Thanks, Tony
Hi Pali,
On Wed, Dec 22, 2021 at 8:08 PM Tony Dinh mibodhi@gmail.com wrote:
Hi all,
With great help from Pali, I've made some good progress on kwboot the HP Thin Client T5335z (Marvell Dove SoC) board. I had been unsuccessful running kwboot with this box until Pali pointed out a few important aspects of the Dove SoC, and how the BootROM commands work (my apology for forgetting to include the u-boot-mailing list and Marek on previous email exchanges).
Here is the summary of the attempt to kwboot.
HP Thin Client T5335z Marvell Dove SoC 88AP510 (A1) 1Ghz CPU 1 GB RAM
- Reset Strapping:
As with all Dove SoCs, there is no preamble when we send the u-boot image over the serial line. IOW, no magic handshake string to tell the BootROM that we are booting over UART. Instead, the hardware must explicitly set to UART mode booting. For boards like the Solidrun Cubox, there is a button, and some other board, a DIP switch, to enable this mode. For the T55335z, there is no button or DIP switch on the board for that purpose. Instead, there is a jumper (the exact purpose is unknown), but I found that this jumper will put the BootROM into debug mode. And from the BootROM debug prompt, we can execute a command to set the boot mode to UART with "x command.
Here is the log and my commentary starting with ***
<Begin log>
*** With jumper inserted, serial console connected, start serial console
# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready
*** Hit <Enter> here to get to the prompt and execute "x 0x0E"
Bootstrap 2.33> Bootstrap 2.33>x 0x0E
*** No more input possible here, so Control-A-X to exit serial console
Terminating... Thanks for using picocom
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
- My comments in response:
Indeed. I've seen that in the Functional Spec, too. The mdt0 binwalk also shows what looks like the extension header.
DECIMAL HEXADECIMAL DESCRIPTION
118161 0x1CD91 Certificate in DER format (x509 v3), header length: 4, sequence length: 3 199169 0x30A01 Certificate in DER format (x509 v3), header length: 4, sequence length: 5464 380652 0x5CEEC CRC32 polynomial table, little endian 387072 0x5E800 CRC32 polynomial table, little endian 608166 0x947A6 LZMA compressed data, properties: 0x66, dictionary size: 0 bytes, uncompressed size: 147351982848 bytes
Thanks, Tony
Follow up on the UART booting session before.
Thanks for the advice about the Reset Strapping documentation. I've extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec for Dove at: https://www.kernel.org/doc/html/latest/arm/marvell.html
Listed below are the Boot Modes that are relevant to this subject (there are other Boot Modes for SATA, NAND but we are not interested in those):
0x00 Direct boot from SPI 0x01 Boot from SPI with 3 address cycles 0x02 Boot from SPI with 4 address cycles 0x0E Boot from UART0 using Xmodem 0x0F Boot from UART1 using Xmodem 0x10 Open BootROM debug prompt on UART0 0x11 Open BootROM debug prompt on UART1
So it does look like the jumper on this HP T5335z is actually to put the box into BootROM debug mode using 0x10. And from there, we can use 0x0E to put the BootROM into UART0 booting mode.
Oddly, I've also tried booting from SPI while at the BootROM debug prompt, but have not been successful with either 0x00, 0x01, or 0x02. I was hoping that it would make testing easier if I could run "Boot from SPI" to boot into Linux without having to remove the jumper.
Thanks, Tony
On Sunday 26 December 2021 13:41:03 Tony Dinh wrote:
Follow up on the UART booting session before.
Thanks for the advice about the Reset Strapping documentation. I've extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec for Dove at: https://www.kernel.org/doc/html/latest/arm/marvell.html
Listed below are the Boot Modes that are relevant to this subject (there are other Boot Modes for SATA, NAND but we are not interested in those):
0x00 Direct boot from SPI 0x01 Boot from SPI with 3 address cycles 0x02 Boot from SPI with 4 address cycles 0x0E Boot from UART0 using Xmodem 0x0F Boot from UART1 using Xmodem 0x10 Open BootROM debug prompt on UART0 0x11 Open BootROM debug prompt on UART1
So it does look like the jumper on this HP T5335z is actually to put the box into BootROM debug mode using 0x10. And from there, we can use 0x0E to put the BootROM into UART0 booting mode.
Oddly, I've also tried booting from SPI while at the BootROM debug prompt, but have not been successful with either 0x00, 0x01, or 0x02. I was hoping that it would make testing easier if I could run "Boot from SPI" to boot into Linux without having to remove the jumper.
And which hex mode is activated when jumper is not set to that Debug prompt UART mode? You should be able to check current mode by reading 0xD00D0214 address which should contain latched sample at reset value. E.g. in U-Boot by 'md 0xD00D0214 1' command.
Hi Pali,
On Sat, Jan 1, 2022 at 1:53 PM Pali Rohár pali@kernel.org wrote:
On Sunday 26 December 2021 13:41:03 Tony Dinh wrote:
Follow up on the UART booting session before.
Thanks for the advice about the Reset Strapping documentation. I've extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec for Dove at: https://www.kernel.org/doc/html/latest/arm/marvell.html
Listed below are the Boot Modes that are relevant to this subject (there are other Boot Modes for SATA, NAND but we are not interested in those):
0x00 Direct boot from SPI 0x01 Boot from SPI with 3 address cycles 0x02 Boot from SPI with 4 address cycles 0x0E Boot from UART0 using Xmodem 0x0F Boot from UART1 using Xmodem 0x10 Open BootROM debug prompt on UART0 0x11 Open BootROM debug prompt on UART1
So it does look like the jumper on this HP T5335z is actually to put the box into BootROM debug mode using 0x10. And from there, we can use 0x0E to put the BootROM into UART0 booting mode.
Oddly, I've also tried booting from SPI while at the BootROM debug prompt, but have not been successful with either 0x00, 0x01, or 0x02. I was hoping that it would make testing easier if I could run "Boot from SPI" to boot into Linux without having to remove the jumper.
And which hex mode is activated when jumper is not set to that Debug prompt UART mode? You should be able to check current mode by reading 0xD00D0214 address which should contain latched sample at reset value. E.g. in U-Boot by 'md 0xD00D0214 1' command.
Without the jumper inserted, it was set to 0x00.
HP>> md 0xD00D0214 1 d00d0214: 00000000 ....
So while I went back to debug mode with the jumper inserted, and tried to switch to boot mode 0x00 Bootstrap 2.33>x 0x00
Nothing happened, so I hit another <Enter>, and it went back to the debug prompt: Bootstrap 2.33>
I also repeated a second time. While at the debug prompt, I removed the jumper, and then Bootstrap 2.33>x 0x00
Nothing happened, too. It seems to be stuck in debug mode. The only way I can proceed is to set the boot mode to UART, exit the serial console, and run kwboot. And of course, recycling the power to get it back to normal booting from SPI.
Thanks, Tony
On Saturday 01 January 2022 14:54:34 Tony Dinh wrote:
Hi Pali,
On Sat, Jan 1, 2022 at 1:53 PM Pali Rohár pali@kernel.org wrote:
On Sunday 26 December 2021 13:41:03 Tony Dinh wrote:
Follow up on the UART booting session before.
Thanks for the advice about the Reset Strapping documentation. I've extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec for Dove at: https://www.kernel.org/doc/html/latest/arm/marvell.html
Listed below are the Boot Modes that are relevant to this subject (there are other Boot Modes for SATA, NAND but we are not interested in those):
0x00 Direct boot from SPI 0x01 Boot from SPI with 3 address cycles 0x02 Boot from SPI with 4 address cycles 0x0E Boot from UART0 using Xmodem 0x0F Boot from UART1 using Xmodem 0x10 Open BootROM debug prompt on UART0 0x11 Open BootROM debug prompt on UART1
So it does look like the jumper on this HP T5335z is actually to put the box into BootROM debug mode using 0x10. And from there, we can use 0x0E to put the BootROM into UART0 booting mode.
Oddly, I've also tried booting from SPI while at the BootROM debug prompt, but have not been successful with either 0x00, 0x01, or 0x02. I was hoping that it would make testing easier if I could run "Boot from SPI" to boot into Linux without having to remove the jumper.
And which hex mode is activated when jumper is not set to that Debug prompt UART mode? You should be able to check current mode by reading 0xD00D0214 address which should contain latched sample at reset value. E.g. in U-Boot by 'md 0xD00D0214 1' command.
Without the jumper inserted, it was set to 0x00.
HP>> md 0xD00D0214 1 d00d0214: 00000000 ....
Sample at reset register should not be zero. So it is located at different address. You could try to look into the functional specification...
Maybe internal registers are at space 0xf1000000? Then register is 0xf10d0214
Hi Pali
On Sat, Jan 1, 2022 at 3:12 PM Pali Rohár pali@kernel.org wrote:
On Saturday 01 January 2022 14:54:34 Tony Dinh wrote:
Hi Pali,
On Sat, Jan 1, 2022 at 1:53 PM Pali Rohár pali@kernel.org wrote:
On Sunday 26 December 2021 13:41:03 Tony Dinh wrote:
Follow up on the UART booting session before.
Thanks for the advice about the Reset Strapping documentation. I've extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec for Dove at: https://www.kernel.org/doc/html/latest/arm/marvell.html
Listed below are the Boot Modes that are relevant to this subject (there are other Boot Modes for SATA, NAND but we are not interested in those):
0x00 Direct boot from SPI 0x01 Boot from SPI with 3 address cycles 0x02 Boot from SPI with 4 address cycles 0x0E Boot from UART0 using Xmodem 0x0F Boot from UART1 using Xmodem 0x10 Open BootROM debug prompt on UART0 0x11 Open BootROM debug prompt on UART1
So it does look like the jumper on this HP T5335z is actually to put the box into BootROM debug mode using 0x10. And from there, we can use 0x0E to put the BootROM into UART0 booting mode.
Oddly, I've also tried booting from SPI while at the BootROM debug prompt, but have not been successful with either 0x00, 0x01, or 0x02. I was hoping that it would make testing easier if I could run "Boot from SPI" to boot into Linux without having to remove the jumper.
And which hex mode is activated when jumper is not set to that Debug prompt UART mode? You should be able to check current mode by reading 0xD00D0214 address which should contain latched sample at reset value. E.g. in U-Boot by 'md 0xD00D0214 1' command.
Without the jumper inserted, it was set to 0x00.
HP>> md 0xD00D0214 1 d00d0214: 00000000 ....
Sample at reset register should not be zero. So it is located at different address. You could try to look into the functional specification...
It must have been the liquor yesterday :) of course there are other settings in this register... it cannot be zero.
Maybe internal registers are at space 0xf1000000? Then register is 0xf10d0214
I think 0xf1000000 is more like it. I've double checked, the Kirkwood SatR is 0xF1010030.
Functional Spec: "The BootROM firmware is located on the device’s Read Only Memory (ROM), and is executed according to the sample at reset configuration bits[4:0] in the Sample at Reset 0 Register (Table 976 p. 959)"
HP>> md f10D0214 1 f10d0214: b40a24a1 .$..
So it looks like the boot mode is 00001?
Thanks, Tony
On Saturday 01 January 2022 16:00:27 Tony Dinh wrote:
Hi Pali
On Sat, Jan 1, 2022 at 3:12 PM Pali Rohár pali@kernel.org wrote:
On Saturday 01 January 2022 14:54:34 Tony Dinh wrote:
Hi Pali,
On Sat, Jan 1, 2022 at 1:53 PM Pali Rohár pali@kernel.org wrote:
On Sunday 26 December 2021 13:41:03 Tony Dinh wrote:
Follow up on the UART booting session before.
Thanks for the advice about the Reset Strapping documentation. I've extracted the attachment 88AP510_Reset_Strapping.xls from the HW Spec for Dove at: https://www.kernel.org/doc/html/latest/arm/marvell.html
Listed below are the Boot Modes that are relevant to this subject (there are other Boot Modes for SATA, NAND but we are not interested in those):
0x00 Direct boot from SPI 0x01 Boot from SPI with 3 address cycles 0x02 Boot from SPI with 4 address cycles 0x0E Boot from UART0 using Xmodem 0x0F Boot from UART1 using Xmodem 0x10 Open BootROM debug prompt on UART0 0x11 Open BootROM debug prompt on UART1
So it does look like the jumper on this HP T5335z is actually to put the box into BootROM debug mode using 0x10. And from there, we can use 0x0E to put the BootROM into UART0 booting mode.
Oddly, I've also tried booting from SPI while at the BootROM debug prompt, but have not been successful with either 0x00, 0x01, or 0x02. I was hoping that it would make testing easier if I could run "Boot from SPI" to boot into Linux without having to remove the jumper.
And which hex mode is activated when jumper is not set to that Debug prompt UART mode? You should be able to check current mode by reading 0xD00D0214 address which should contain latched sample at reset value. E.g. in U-Boot by 'md 0xD00D0214 1' command.
Without the jumper inserted, it was set to 0x00.
HP>> md 0xD00D0214 1 d00d0214: 00000000 ....
Sample at reset register should not be zero. So it is located at different address. You could try to look into the functional specification...
It must have been the liquor yesterday :) of course there are other settings in this register... it cannot be zero.
Maybe internal registers are at space 0xf1000000? Then register is 0xf10d0214
I think 0xf1000000 is more like it. I've double checked, the Kirkwood SatR is 0xF1010030.
Functional Spec: "The BootROM firmware is located on the device’s Read Only Memory (ROM), and is executed according to the sample at reset configuration bits[4:0] in the Sample at Reset 0 Register (Table 976 p. 959)"
HP>> md f10D0214 1 f10d0214: b40a24a1 .$..
So it looks like the boot mode is 00001?
Seems yes. 30th bit in 0xb40a24a1 is unset, so first boot mode table from 88AP510_Reset_Strapping.xls applies. Bits [4:0] are 0b00001, so bootmode is 0x01 - Boot from SPI with 3 address cycles. Which should correspondent to 'x 0x01' command. If it does not work then BootROM is broken.
Note that 'x' command is broken in A385 BootROM, so I would not be surprised if it does not work in other SoCs too...
You can try to figure out at which address is mapped this sample at reset register when CPU is running that debug boot prompt. Sometimes this register is R/W, so bootrom can use it as a "cache" for its own purposes (it does not update hardware). And in case you figure out how to update it, you could try to invoke BootROM reset to just re-enter boot sequence... and maybe bootrom starts booting from SPI. Just idea.
Thanks, Tony
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
- My comments in response:
Indeed. I've seen that in the Functional Spec, too. The mdt0 binwalk also shows what looks like the extension header.
No. this is not extension header as it is at the beginning of the image.
DECIMAL HEXADECIMAL DESCRIPTION
118161 0x1CD91 Certificate in DER format (x509 v3), header length: 4, sequence length: 3 199169 0x30A01 Certificate in DER format (x509 v3), header length: 4, sequence length: 5464 380652 0x5CEEC CRC32 polynomial table, little endian 387072 0x5E800 CRC32 polynomial table, little endian 608166 0x947A6 LZMA compressed data, properties: 0x66,
These are offsets far away from the beginning. I doubt that binwalk would be able to parse some Marvell extension headers, specially even when native U-Boot tools cannot do it.
dictionary size: 0 bytes, uncompressed size: 147351982848 bytes
Thanks, Tony
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg)) - +/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 { - uint32_t offset; - uint8_t reserved[0x20 - sizeof(uint32_t)]; - struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT]; - uint8_t reserved2[7]; - uint8_t checksum; + /* + * Beware that extension header offsets specified in 88AP510 Functional + * Specifications are relative to the start of the main header, not to + * the start of the extension header itself. + */ + uint32_t offset; /* 0x0-0x3 */ + uint8_t rsvd1[8]; /* 0x4-0xB */ + uint32_t ddrinitdelay; /* 0xC-0xF */ + uint32_t match_addr; /* 0x10-0x13 */ + uint32_t match_mask; /* 0x14-0x17 */ + uint32_t match_value; /* 0x18-0x1B */ + uint8_t ddrwritetype; /* 0x1C */ + uint8_t ddrresetmpp; /* 0x1D */ + uint8_t ddrclkenmpp; /* 0x1E */ + uint8_t ddrmppdelay; /* 0x1F */ + struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */ + uint8_t rsvd2[7]; /* 0x1D8-0x1DE */ + uint8_t checksum; /* 0x1DF */ +} __packed; + +/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 { + uint32_t match_addr; /* 0x00-0x03 */ + uint32_t match_mask; /* 0x04-0x07 */ + uint32_t match_value; /* 0x08-0x0B */ + uint32_t offset; /* 0x0C-0x0F */ + uint32_t destaddr; /* 0x10-0x13 */ + uint32_t size; /* 0x14-0x17 */ + uint32_t execaddr; /* 0x18-0x1B */ + uint32_t param1; /* 0x1C-0x1F */ + uint32_t param2; /* 0x20-0x23 */ + uint32_t param3; /* 0x24-0x27 */ + uint32_t param4; /* 0x28-0x2B */ + uint8_t params; /* 0x2C */ + uint8_t rsvd1; /* 0x2D */ + uint8_t rsvd2; /* 0x2E */ + uint8_t checksum; /* 0x2F */ + uint8_t code[2000]; /* 0x30-0x7FF */ } __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
+ /* + * First extension header starts immediately after the main + * header without any padding. Between extension headers is + * 0x20 byte padding. There is no padding after the last + * extension header. First binary code header starts immediately + * after the last extension header (or immediately after the + * main header if there is no extension header) without any + * padding. There is no padding between binary code headers and + * neither after the last binary code header. + */ return sizeof(*hdr) + - hdr->ext ? sizeof(struct ext_hdr_v0) : 0; + hdr->ext * sizeof(struct ext_hdr_v0) + + ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) + + hdr->binext * sizeof(struct binext_hdr_v0); } else { const struct main_hdr_v1 *hdr = header;
It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
On Sunday 13 February 2022 17:16:42 Pali Rohár wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
- uint32_t offset;
- uint8_t reserved[0x20 - sizeof(uint32_t)];
- struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];
- uint8_t reserved2[7];
- uint8_t checksum;
- /*
* Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/- uint32_t offset; /* 0x0-0x3 */
- uint8_t rsvd1[8]; /* 0x4-0xB */
- uint32_t ddrinitdelay; /* 0xC-0xF */
- uint32_t match_addr; /* 0x10-0x13 */
- uint32_t match_mask; /* 0x14-0x17 */
- uint32_t match_value; /* 0x18-0x1B */
- uint8_t ddrwritetype; /* 0x1C */
- uint8_t ddrresetmpp; /* 0x1D */
- uint8_t ddrclkenmpp; /* 0x1E */
- uint8_t ddrmppdelay; /* 0x1F */
- struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */
- uint8_t rsvd2[7]; /* 0x1D8-0x1DE */
- uint8_t checksum; /* 0x1DF */
+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
- uint32_t match_addr; /* 0x00-0x03 */
- uint32_t match_mask; /* 0x04-0x07 */
- uint32_t match_value; /* 0x08-0x0B */
- uint32_t offset; /* 0x0C-0x0F */
- uint32_t destaddr; /* 0x10-0x13 */
- uint32_t size; /* 0x14-0x17 */
- uint32_t execaddr; /* 0x18-0x1B */
- uint32_t param1; /* 0x1C-0x1F */
- uint32_t param2; /* 0x20-0x23 */
- uint32_t param3; /* 0x24-0x27 */
- uint32_t param4; /* 0x28-0x2B */
- uint8_t params; /* 0x2C */
- uint8_t rsvd1; /* 0x2D */
- uint8_t rsvd2; /* 0x2E */
- uint8_t checksum; /* 0x2F */
- uint8_t code[2000]; /* 0x30-0x7FF */
} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +
^^^^^^^^^^^^^^^^^ Ou.. there is a mistake. It should be: "((hdr->ext - 1) * 0x20)" as number of paddings in between is number of headers minus one.
hdr->binext * sizeof(struct binext_hdr_v0);It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
On Sun, 13 Feb 2022 20:41:08 +0100 Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 17:16:42 Pali Rohár wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
- uint32_t offset;
- uint8_t reserved[0x20 - sizeof(uint32_t)];
- struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];
- uint8_t reserved2[7];
- uint8_t checksum;
- /*
* Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/- uint32_t offset; /* 0x0-0x3 */
- uint8_t rsvd1[8]; /* 0x4-0xB */
- uint32_t ddrinitdelay; /* 0xC-0xF */
- uint32_t match_addr; /* 0x10-0x13 */
- uint32_t match_mask; /* 0x14-0x17 */
- uint32_t match_value; /* 0x18-0x1B */
- uint8_t ddrwritetype; /* 0x1C */
- uint8_t ddrresetmpp; /* 0x1D */
- uint8_t ddrclkenmpp; /* 0x1E */
- uint8_t ddrmppdelay; /* 0x1F */
- struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */
- uint8_t rsvd2[7]; /* 0x1D8-0x1DE */
- uint8_t checksum; /* 0x1DF */
+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
- uint32_t match_addr; /* 0x00-0x03 */
- uint32_t match_mask; /* 0x04-0x07 */
- uint32_t match_value; /* 0x08-0x0B */
- uint32_t offset; /* 0x0C-0x0F */
- uint32_t destaddr; /* 0x10-0x13 */
- uint32_t size; /* 0x14-0x17 */
- uint32_t execaddr; /* 0x18-0x1B */
- uint32_t param1; /* 0x1C-0x1F */
- uint32_t param2; /* 0x20-0x23 */
- uint32_t param3; /* 0x24-0x27 */
- uint32_t param4; /* 0x28-0x2B */
- uint8_t params; /* 0x2C */
- uint8_t rsvd1; /* 0x2D */
- uint8_t rsvd2; /* 0x2E */
- uint8_t checksum; /* 0x2F */
- uint8_t code[2000]; /* 0x30-0x7FF */
} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +^^^^^^^^^^^^^^^^^Ou.. there is a mistake. It should be: "((hdr->ext - 1) * 0x20)" as number of paddings in between is number of headers minus one.
In that case the whole ternary operator can be dropped, i.e. instead of ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) you can have ((hdr->ext - 1) * 0x20) if I interpret this correctly.
Marek
On Sunday 13 February 2022 22:15:09 Marek Behún wrote:
On Sun, 13 Feb 2022 20:41:08 +0100 Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 17:16:42 Pali Rohár wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
- uint32_t offset;
- uint8_t reserved[0x20 - sizeof(uint32_t)];
- struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];
- uint8_t reserved2[7];
- uint8_t checksum;
- /*
* Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/- uint32_t offset; /* 0x0-0x3 */
- uint8_t rsvd1[8]; /* 0x4-0xB */
- uint32_t ddrinitdelay; /* 0xC-0xF */
- uint32_t match_addr; /* 0x10-0x13 */
- uint32_t match_mask; /* 0x14-0x17 */
- uint32_t match_value; /* 0x18-0x1B */
- uint8_t ddrwritetype; /* 0x1C */
- uint8_t ddrresetmpp; /* 0x1D */
- uint8_t ddrclkenmpp; /* 0x1E */
- uint8_t ddrmppdelay; /* 0x1F */
- struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */
- uint8_t rsvd2[7]; /* 0x1D8-0x1DE */
- uint8_t checksum; /* 0x1DF */
+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
- uint32_t match_addr; /* 0x00-0x03 */
- uint32_t match_mask; /* 0x04-0x07 */
- uint32_t match_value; /* 0x08-0x0B */
- uint32_t offset; /* 0x0C-0x0F */
- uint32_t destaddr; /* 0x10-0x13 */
- uint32_t size; /* 0x14-0x17 */
- uint32_t execaddr; /* 0x18-0x1B */
- uint32_t param1; /* 0x1C-0x1F */
- uint32_t param2; /* 0x20-0x23 */
- uint32_t param3; /* 0x24-0x27 */
- uint32_t param4; /* 0x28-0x2B */
- uint8_t params; /* 0x2C */
- uint8_t rsvd1; /* 0x2D */
- uint8_t rsvd2; /* 0x2E */
- uint8_t checksum; /* 0x2F */
- uint8_t code[2000]; /* 0x30-0x7FF */
} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +^^^^^^^^^^^^^^^^^Ou.. there is a mistake. It should be: "((hdr->ext - 1) * 0x20)" as number of paddings in between is number of headers minus one.
In that case the whole ternary operator can be dropped, i.e. instead of ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) you can have ((hdr->ext - 1) * 0x20) if I interpret this correctly.
No, it cannot be dropped, with correction it is:
((hdr->ext > 1) ? ((hdr->ext - 1) * 0x20) : 0)
When hdr->ext is zero, result must be also 0, not (uint8_t)-1 * 0x20.
On Sun, 13 Feb 2022 22:23:10 +0100 Pali Rohár pali@kernel.org wrote:
In that case the whole ternary operator can be dropped, i.e. instead of ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) you can have ((hdr->ext - 1) * 0x20) if I interpret this correctly.
No, it cannot be dropped, with correction it is:
((hdr->ext > 1) ? ((hdr->ext - 1) * 0x20) : 0)
When hdr->ext is zero, result must be also 0, not (uint8_t)-1 * 0x20.
Oh, so hdr->ext can be zero. OK.
So you can drop at least the "> 1": hdr->ext ? ((hdr->ext - 1) * 0x20) : 0 but that is almost as horrible as with "> 1", so you can keep it if you want :)
Marek
Hi Pali,
On Sun, Feb 13, 2022 at 1:33 PM Marek Behún marek.behun@nic.cz wrote:
On Sun, 13 Feb 2022 22:23:10 +0100 Pali Rohár pali@kernel.org wrote:
In that case the whole ternary operator can be dropped, i.e. instead of ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) you can have ((hdr->ext - 1) * 0x20) if I interpret this correctly.
No, it cannot be dropped, with correction it is:
((hdr->ext > 1) ? ((hdr->ext - 1) * 0x20) : 0)
When hdr->ext is zero, result must be also 0, not (uint8_t)-1 * 0x20.
Oh, so hdr->ext can be zero. OK.
So you can drop at least the "> 1": hdr->ext ? ((hdr->ext - 1) * 0x20) : 0 but that is almost as horrible as with "> 1", so you can keep it if you want :)
Marek
Thanks for the patch! I'll give it a try.
Tony
Hi Pali,
Some compile errors, please see below.
On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
uint32_t offset;uint8_t reserved[0x20 - sizeof(uint32_t)];struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];uint8_t reserved2[7];uint8_t checksum;
/** Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/uint32_t offset; /* 0x0-0x3 */uint8_t rsvd1[8]; /* 0x4-0xB */uint32_t ddrinitdelay; /* 0xC-0xF */uint32_t match_addr; /* 0x10-0x13 */uint32_t match_mask; /* 0x14-0x17 */uint32_t match_value; /* 0x18-0x1B */uint8_t ddrwritetype; /* 0x1C */uint8_t ddrresetmpp; /* 0x1D */uint8_t ddrclkenmpp; /* 0x1E */uint8_t ddrmppdelay; /* 0x1F */struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */uint8_t rsvd2[7]; /* 0x1D8-0x1DE */uint8_t checksum; /* 0x1DF */+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
uint32_t match_addr; /* 0x00-0x03 */uint32_t match_mask; /* 0x04-0x07 */uint32_t match_value; /* 0x08-0x0B */uint32_t offset; /* 0x0C-0x0F */uint32_t destaddr; /* 0x10-0x13 */uint32_t size; /* 0x14-0x17 */uint32_t execaddr; /* 0x18-0x1B */uint32_t param1; /* 0x1C-0x1F */uint32_t param2; /* 0x20-0x23 */uint32_t param3; /* 0x24-0x27 */uint32_t param4; /* 0x28-0x2B */uint8_t params; /* 0x2C */uint8_t rsvd1; /* 0x2D */uint8_t rsvd2; /* 0x2E */uint8_t checksum; /* 0x2F */uint8_t code[2000]; /* 0x30-0x7FF */} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/ return sizeof(*hdr) +
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +hdr->binext * sizeof(struct binext_hdr_v0); } else { const struct main_hdr_v1 *hdr = header;It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
Applied the patch, and make tools gave this error:
tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no member named ‘binext’ 255 | hdr->binext * sizeof(struct binext_hdr_v0);
Thanks, Tony
On Sunday 13 February 2022 14:45:07 Tony Dinh wrote:
Hi Pali,
Some compile errors, please see below.
On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
uint32_t offset;uint8_t reserved[0x20 - sizeof(uint32_t)];struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];uint8_t reserved2[7];uint8_t checksum;
/** Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/uint32_t offset; /* 0x0-0x3 */uint8_t rsvd1[8]; /* 0x4-0xB */uint32_t ddrinitdelay; /* 0xC-0xF */uint32_t match_addr; /* 0x10-0x13 */uint32_t match_mask; /* 0x14-0x17 */uint32_t match_value; /* 0x18-0x1B */uint8_t ddrwritetype; /* 0x1C */uint8_t ddrresetmpp; /* 0x1D */uint8_t ddrclkenmpp; /* 0x1E */uint8_t ddrmppdelay; /* 0x1F */struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */uint8_t rsvd2[7]; /* 0x1D8-0x1DE */uint8_t checksum; /* 0x1DF */+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
uint32_t match_addr; /* 0x00-0x03 */uint32_t match_mask; /* 0x04-0x07 */uint32_t match_value; /* 0x08-0x0B */uint32_t offset; /* 0x0C-0x0F */uint32_t destaddr; /* 0x10-0x13 */uint32_t size; /* 0x14-0x17 */uint32_t execaddr; /* 0x18-0x1B */uint32_t param1; /* 0x1C-0x1F */uint32_t param2; /* 0x20-0x23 */uint32_t param3; /* 0x24-0x27 */uint32_t param4; /* 0x28-0x2B */uint8_t params; /* 0x2C */uint8_t rsvd1; /* 0x2D */uint8_t rsvd2; /* 0x2E */uint8_t checksum; /* 0x2F */uint8_t code[2000]; /* 0x30-0x7FF */} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/ return sizeof(*hdr) +
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +hdr->binext * sizeof(struct binext_hdr_v0); } else { const struct main_hdr_v1 *hdr = header;It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
Applied the patch, and make tools gave this error:
tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no member named ‘binext’ 255 | hdr->binext * sizeof(struct binext_hdr_v0);
Thanks, Tony
Ah, I have not sent whole patch...
In tools/kwbimage.h for struct main_hdr_v0 { ... } replace
uint16_t rsvd2;
by
uint8_t rsvd2; uint8_t binext;
Hi Pali,
Looks different, but the BootROM did not start the image. Please see the log below.
On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 14:45:07 Tony Dinh wrote:
Hi Pali,
Some compile errors, please see below.
On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
uint32_t offset;uint8_t reserved[0x20 - sizeof(uint32_t)];struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];uint8_t reserved2[7];uint8_t checksum;
/** Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/uint32_t offset; /* 0x0-0x3 */uint8_t rsvd1[8]; /* 0x4-0xB */uint32_t ddrinitdelay; /* 0xC-0xF */uint32_t match_addr; /* 0x10-0x13 */uint32_t match_mask; /* 0x14-0x17 */uint32_t match_value; /* 0x18-0x1B */uint8_t ddrwritetype; /* 0x1C */uint8_t ddrresetmpp; /* 0x1D */uint8_t ddrclkenmpp; /* 0x1E */uint8_t ddrmppdelay; /* 0x1F */struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */uint8_t rsvd2[7]; /* 0x1D8-0x1DE */uint8_t checksum; /* 0x1DF */+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
uint32_t match_addr; /* 0x00-0x03 */uint32_t match_mask; /* 0x04-0x07 */uint32_t match_value; /* 0x08-0x0B */uint32_t offset; /* 0x0C-0x0F */uint32_t destaddr; /* 0x10-0x13 */uint32_t size; /* 0x14-0x17 */uint32_t execaddr; /* 0x18-0x1B */uint32_t param1; /* 0x1C-0x1F */uint32_t param2; /* 0x20-0x23 */uint32_t param3; /* 0x24-0x27 */uint32_t param4; /* 0x28-0x2B */uint8_t params; /* 0x2C */uint8_t rsvd1; /* 0x2D */uint8_t rsvd2; /* 0x2E */uint8_t checksum; /* 0x2F */uint8_t code[2000]; /* 0x30-0x7FF */} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/ return sizeof(*hdr) +
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +hdr->binext * sizeof(struct binext_hdr_v0); } else { const struct main_hdr_v1 *hdr = header;It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
Applied the patch, and make tools gave this error:
tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no member named ‘binext’ 255 | hdr->binext * sizeof(struct binext_hdr_v0);
Thanks, Tony
Ah, I have not sent whole patch...
In tools/kwbimage.h for struct main_hdr_v0 { ... } replace
uint16_t rsvd2;
by
uint8_t rsvd2; uint8_t binext;
Fixed that, and then I ran it the same way before. In the serial console, tell BootROM to set the boot device to UART, and then exit, run kwboot.
<BEGIN log>
Bootstrap 2.33>x 0x0E
Terminating... Thanks for using picocom
./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................] <snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] <END log>
It hung here. And I have to recycle power to boot again.
Observation: in the previous run with unpatched kwboot, the header size was 512 bytes, and the image was 607664 bytes. So this time kwboot sends the extension header, too. Not sure if 3072 bytes is correct.
Thanks, Tony
On Sunday 13 February 2022 15:24:46 Tony Dinh wrote:
Hi Pali,
Looks different, but the BootROM did not start the image. Please see the log below.
On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 14:45:07 Tony Dinh wrote:
Hi Pali,
Some compile errors, please see below.
On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
uint32_t offset;uint8_t reserved[0x20 - sizeof(uint32_t)];struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];uint8_t reserved2[7];uint8_t checksum;
/** Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/uint32_t offset; /* 0x0-0x3 */uint8_t rsvd1[8]; /* 0x4-0xB */uint32_t ddrinitdelay; /* 0xC-0xF */uint32_t match_addr; /* 0x10-0x13 */uint32_t match_mask; /* 0x14-0x17 */uint32_t match_value; /* 0x18-0x1B */uint8_t ddrwritetype; /* 0x1C */uint8_t ddrresetmpp; /* 0x1D */uint8_t ddrclkenmpp; /* 0x1E */uint8_t ddrmppdelay; /* 0x1F */struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */uint8_t rsvd2[7]; /* 0x1D8-0x1DE */uint8_t checksum; /* 0x1DF */+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
uint32_t match_addr; /* 0x00-0x03 */uint32_t match_mask; /* 0x04-0x07 */uint32_t match_value; /* 0x08-0x0B */uint32_t offset; /* 0x0C-0x0F */uint32_t destaddr; /* 0x10-0x13 */uint32_t size; /* 0x14-0x17 */uint32_t execaddr; /* 0x18-0x1B */uint32_t param1; /* 0x1C-0x1F */uint32_t param2; /* 0x20-0x23 */uint32_t param3; /* 0x24-0x27 */uint32_t param4; /* 0x28-0x2B */uint8_t params; /* 0x2C */uint8_t rsvd1; /* 0x2D */uint8_t rsvd2; /* 0x2E */uint8_t checksum; /* 0x2F */uint8_t code[2000]; /* 0x30-0x7FF */} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/ return sizeof(*hdr) +
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +hdr->binext * sizeof(struct binext_hdr_v0); } else { const struct main_hdr_v1 *hdr = header;It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
Applied the patch, and make tools gave this error:
tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no member named ‘binext’ 255 | hdr->binext * sizeof(struct binext_hdr_v0);
Thanks, Tony
Ah, I have not sent whole patch...
In tools/kwbimage.h for struct main_hdr_v0 { ... } replace
uint16_t rsvd2;
by
uint8_t rsvd2; uint8_t binext;
Fixed that, and then I ran it the same way before. In the serial console, tell BootROM to set the boot device to UART, and then exit, run kwboot.
<BEGIN log>
Bootstrap 2.33>x 0x0E
Terminating... Thanks for using picocom
./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] <END log>
It hung here. And I have to recycle power to boot again.
Observation: in the previous run with unpatched kwboot, the header size was 512 bytes, and the image was 607664 bytes. So this time kwboot sends the extension header, too. Not sure if 3072 bytes is correct.
If I parsed that image (file mtd0.t5335z) correctly it has: * main header (0x20) * ext header (0x1E0) * 0x20 padding (0x20) * ext header (0x1E0) * bin header (0x800) * image data (0x93bb0)
So it is: 3072 bytes for headers + 605104 bytes for image data, which now matches.
Plus in main header is stored that image data starts at offset 0xc00 which is 3072 bytes.
Now kwboot showed just that is patching UART signature and no more alignment, so it should send headers and data without adding any additional padding or alignment.
If it still does not work, I do not have an idea...
It would be required to take U-Boot source code for that board and build UART image from sources. Maybe UART version needs to be compiled differently, like it was in past also for Armada builds.
Thanks, Tony
Hi Pali,
On Sun, Feb 13, 2022 at 3:42 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 15:24:46 Tony Dinh wrote:
Hi Pali,
Looks different, but the BootROM did not start the image. Please see the log below.
On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 14:45:07 Tony Dinh wrote:
Hi Pali,
Some compile errors, please see below.
On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
*** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with *** this command: *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync
<End log>
- Pali's observation:
It looks like Dove uses kwbimage v0 format with extensions, at least according to Function Spec. See 'Binary Code Extension' and 'Header Extension'. Currently kwboot and kwbimage supports v0 image only with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
uint32_t offset;uint8_t reserved[0x20 - sizeof(uint32_t)];struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];uint8_t reserved2[7];uint8_t checksum;
/** Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/uint32_t offset; /* 0x0-0x3 */uint8_t rsvd1[8]; /* 0x4-0xB */uint32_t ddrinitdelay; /* 0xC-0xF */uint32_t match_addr; /* 0x10-0x13 */uint32_t match_mask; /* 0x14-0x17 */uint32_t match_value; /* 0x18-0x1B */uint8_t ddrwritetype; /* 0x1C */uint8_t ddrresetmpp; /* 0x1D */uint8_t ddrclkenmpp; /* 0x1E */uint8_t ddrmppdelay; /* 0x1F */struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */uint8_t rsvd2[7]; /* 0x1D8-0x1DE */uint8_t checksum; /* 0x1DF */+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
uint32_t match_addr; /* 0x00-0x03 */uint32_t match_mask; /* 0x04-0x07 */uint32_t match_value; /* 0x08-0x0B */uint32_t offset; /* 0x0C-0x0F */uint32_t destaddr; /* 0x10-0x13 */uint32_t size; /* 0x14-0x17 */uint32_t execaddr; /* 0x18-0x1B */uint32_t param1; /* 0x1C-0x1F */uint32_t param2; /* 0x20-0x23 */uint32_t param3; /* 0x24-0x27 */uint32_t param4; /* 0x28-0x2B */uint8_t params; /* 0x2C */uint8_t rsvd1; /* 0x2D */uint8_t rsvd2; /* 0x2E */uint8_t checksum; /* 0x2F */uint8_t code[2000]; /* 0x30-0x7FF */} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/ return sizeof(*hdr) +
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +hdr->binext * sizeof(struct binext_hdr_v0); } else { const struct main_hdr_v1 *hdr = header;It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
Applied the patch, and make tools gave this error:
tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no member named ‘binext’ 255 | hdr->binext * sizeof(struct binext_hdr_v0);
Thanks, Tony
Ah, I have not sent whole patch...
In tools/kwbimage.h for struct main_hdr_v0 { ... } replace
uint16_t rsvd2;
by
uint8_t rsvd2; uint8_t binext;
Fixed that, and then I ran it the same way before. In the serial console, tell BootROM to set the boot device to UART, and then exit, run kwboot.
<BEGIN log>
Bootstrap 2.33>x 0x0E
Terminating... Thanks for using picocom
./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] <END log>
It hung here. And I have to recycle power to boot again.
Observation: in the previous run with unpatched kwboot, the header size was 512 bytes, and the image was 607664 bytes. So this time kwboot sends the extension header, too. Not sure if 3072 bytes is correct.
If I parsed that image (file mtd0.t5335z) correctly it has:
- main header (0x20)
- ext header (0x1E0)
- 0x20 padding (0x20)
- ext header (0x1E0)
- bin header (0x800)
- image data (0x93bb0)
So it is: 3072 bytes for headers + 605104 bytes for image data, which now matches.
Plus in main header is stored that image data starts at offset 0xc00 which is 3072 bytes.
Now kwboot showed just that is patching UART signature and no more alignment, so it should send headers and data without adding any additional padding or alignment.
If it still does not work, I do not have an idea...
It would be required to take U-Boot source code for that board and build UART image from sources. Maybe UART version needs to be compiled differently, like it was in past also for Armada builds.
To double check I dumped the images.
./kwboot-2022/dumpimage -T kwbimage -p -1 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.cfg -rw-r--r-- 1 root root 1155 Feb 13 15:58 mtd0.t5335z.cfg
./kwboot-2022/dumpimage -T kwbimage -p 0 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.0.img -rw------- 1 root root 605100 Feb 13 15:58 mtd0.t5335z.0.img
./kwboot-2022/mkimage -l ./t5335z/mtd0.t5335z Image Type: MVEBU Boot from spi Image Image version:0 Data Size: 605100 Bytes = 590.92 KiB = 0.58 MiB Load Address: 00600000 Entry Point: 00690000
So it is checked out. The image is 605100 with 4 bytes checksum = 605104. Did I read it correctly? i.e. the dump does not include the checksum?
Seems I got to get to work on that stock UART image!
Thanks, Tony
On Sunday 13 February 2022 16:08:51 Tony Dinh wrote:
Hi Pali,
On Sun, Feb 13, 2022 at 3:42 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 15:24:46 Tony Dinh wrote:
Hi Pali,
Looks different, but the BootROM did not start the image. Please see the log below.
On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 14:45:07 Tony Dinh wrote:
Hi Pali,
Some compile errors, please see below.
On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote:
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote: > *** Run kwboot > > # kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z > Patching image boot signature to UART > Aligning image header to Xmodem block size > Waiting 2s and flushing tty > Sending boot image header (512 bytes)... > 25 % [.... ] > Done > Sending boot image data (607664 bytes)... > 0 % [......................................................................] > 1 % [......................................................................] > 2 % [......................................................................] > <snip> > 95 % [......................................................................] > 97 % [......................................................................] > 98 % [.......................................................... ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > > *** Hung here! BootROM did not execute the image payload. > *** > *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with > *** this command: > *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync > > <End log> > > > - Pali's observation: > > It looks like Dove uses kwbimage v0 format with extensions, at > least according to Function Spec. See 'Binary Code Extension' and > 'Header Extension'. Currently kwboot and kwbimage supports v0 image only > with one extension.
I quickly looked at it. Could you try following patch?
diff --git a/tools/kwbimage.h b/tools/kwbimage.h index 74e5d87a4fef..15e83ececc76 100644 --- a/tools/kwbimage.h +++ b/tools/kwbimage.h @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { uint32_t rdata; } __packed;
-#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg))
+/* Structure of the extension header, version 0 (Kirkwood, Dove) */ struct ext_hdr_v0 {
uint32_t offset;uint8_t reserved[0x20 - sizeof(uint32_t)];struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT];uint8_t reserved2[7];uint8_t checksum;
/** Beware that extension header offsets specified in 88AP510 Functional* Specifications are relative to the start of the main header, not to* the start of the extension header itself.*/uint32_t offset; /* 0x0-0x3 */uint8_t rsvd1[8]; /* 0x4-0xB */uint32_t ddrinitdelay; /* 0xC-0xF */uint32_t match_addr; /* 0x10-0x13 */uint32_t match_mask; /* 0x14-0x17 */uint32_t match_value; /* 0x18-0x1B */uint8_t ddrwritetype; /* 0x1C */uint8_t ddrresetmpp; /* 0x1D */uint8_t ddrclkenmpp; /* 0x1E */uint8_t ddrmppdelay; /* 0x1F */struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */uint8_t rsvd2[7]; /* 0x1D8-0x1DE */uint8_t checksum; /* 0x1DF */+} __packed;
+/* Structure of the binary code header, version 0 (Dove) */ +struct binext_hdr_v0 {
uint32_t match_addr; /* 0x00-0x03 */uint32_t match_mask; /* 0x04-0x07 */uint32_t match_value; /* 0x08-0x0B */uint32_t offset; /* 0x0C-0x0F */uint32_t destaddr; /* 0x10-0x13 */uint32_t size; /* 0x14-0x17 */uint32_t execaddr; /* 0x18-0x1B */uint32_t param1; /* 0x1C-0x1F */uint32_t param2; /* 0x20-0x23 */uint32_t param3; /* 0x24-0x27 */uint32_t param4; /* 0x28-0x2B */uint8_t params; /* 0x2C */uint8_t rsvd1; /* 0x2D */uint8_t rsvd2; /* 0x2E */uint8_t checksum; /* 0x2F */uint8_t code[2000]; /* 0x30-0x7FF */} __packed;
/* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) if (kwbimage_version(header) == 0) { const struct main_hdr_v0 *hdr = header;
/** First extension header starts immediately after the main* header without any padding. Between extension headers is* 0x20 byte padding. There is no padding after the last* extension header. First binary code header starts immediately* after the last extension header (or immediately after the* main header if there is no extension header) without any* padding. There is no padding between binary code headers and* neither after the last binary code header.*/ return sizeof(*hdr) +
hdr->ext ? sizeof(struct ext_hdr_v0) : 0;
hdr->ext * sizeof(struct ext_hdr_v0) +((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) +hdr->binext * sizeof(struct binext_hdr_v0); } else { const struct main_hdr_v1 *hdr = header;It fixes kwbheader_size() function to returns correct size of the image header (with all v0 extensions), so it could help kwboot to convert image with non-UART sign to UART version and send it over UART.
Applied the patch, and make tools gave this error:
tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no member named ‘binext’ 255 | hdr->binext * sizeof(struct binext_hdr_v0);
Thanks, Tony
Ah, I have not sent whole patch...
In tools/kwbimage.h for struct main_hdr_v0 { ... } replace
uint16_t rsvd2;
by
uint8_t rsvd2; uint8_t binext;
Fixed that, and then I ran it the same way before. In the serial console, tell BootROM to set the boot device to UART, and then exit, run kwboot.
<BEGIN log>
Bootstrap 2.33>x 0x0E
Terminating... Thanks for using picocom
./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] <END log>
It hung here. And I have to recycle power to boot again.
Observation: in the previous run with unpatched kwboot, the header size was 512 bytes, and the image was 607664 bytes. So this time kwboot sends the extension header, too. Not sure if 3072 bytes is correct.
If I parsed that image (file mtd0.t5335z) correctly it has:
- main header (0x20)
- ext header (0x1E0)
- 0x20 padding (0x20)
- ext header (0x1E0)
- bin header (0x800)
- image data (0x93bb0)
So it is: 3072 bytes for headers + 605104 bytes for image data, which now matches.
Plus in main header is stored that image data starts at offset 0xc00 which is 3072 bytes.
Now kwboot showed just that is patching UART signature and no more alignment, so it should send headers and data without adding any additional padding or alignment.
If it still does not work, I do not have an idea...
It would be required to take U-Boot source code for that board and build UART image from sources. Maybe UART version needs to be compiled differently, like it was in past also for Armada builds.
To double check I dumped the images.
./kwboot-2022/dumpimage -T kwbimage -p -1 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.cfg -rw-r--r-- 1 root root 1155 Feb 13 15:58 mtd0.t5335z.cfg
This cfg file is incomplete as kwbimage does not read those new structures.
There is also bin header for '-p 1' but again kwbimage cannot extract it yet.
(Btw, I have WIP patches for this stuff, if you are interesting I can send it)
./kwboot-2022/dumpimage -T kwbimage -p 0 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.0.img -rw------- 1 root root 605100 Feb 13 15:58 mtd0.t5335z.0.img
./kwboot-2022/mkimage -l ./t5335z/mtd0.t5335z Image Type: MVEBU Boot from spi Image Image version:0 Data Size: 605100 Bytes = 590.92 KiB = 0.58 MiB Load Address: 00600000 Entry Point: 00690000
So it is checked out. The image is 605100 with 4 bytes checksum = 605104. Did I read it correctly? i.e. the dump does not include the checksum?
Yes!
Seems I got to get to work on that stock UART image!
Thanks, Tony
Hi Pali,
Please see below.
On Sun, Feb 13, 2022 at 4:21 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 16:08:51 Tony Dinh wrote:
Hi Pali,
On Sun, Feb 13, 2022 at 3:42 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 15:24:46 Tony Dinh wrote:
Hi Pali,
Looks different, but the BootROM did not start the image. Please see the log below.
On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 14:45:07 Tony Dinh wrote:
Hi Pali,
Some compile errors, please see below.
On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote: > > On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote: > > *** Run kwboot > > > > # kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z > > Patching image boot signature to UART > > Aligning image header to Xmodem block size > > Waiting 2s and flushing tty > > Sending boot image header (512 bytes)... > > 25 % [.... ] > > Done > > Sending boot image data (607664 bytes)... > > 0 % [......................................................................] > > 1 % [......................................................................] > > 2 % [......................................................................] > > <snip> > > 95 % [......................................................................] > > 97 % [......................................................................] > > 98 % [.......................................................... ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > > > *** Hung here! BootROM did not execute the image payload. > > *** > > *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with > > *** this command: > > *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync > > > > <End log> > > > > > > - Pali's observation: > > > > It looks like Dove uses kwbimage v0 format with extensions, at > > least according to Function Spec. See 'Binary Code Extension' and > > 'Header Extension'. Currently kwboot and kwbimage supports v0 image only > > with one extension. > > I quickly looked at it. Could you try following patch? > > diff --git a/tools/kwbimage.h b/tools/kwbimage.h > index 74e5d87a4fef..15e83ececc76 100644 > --- a/tools/kwbimage.h > +++ b/tools/kwbimage.h > @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { > uint32_t rdata; > } __packed; > > -#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg)) > - > +/* Structure of the extension header, version 0 (Kirkwood, Dove) */ > struct ext_hdr_v0 { > - uint32_t offset; > - uint8_t reserved[0x20 - sizeof(uint32_t)]; > - struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT]; > - uint8_t reserved2[7]; > - uint8_t checksum; > + /* > + * Beware that extension header offsets specified in 88AP510 Functional > + * Specifications are relative to the start of the main header, not to > + * the start of the extension header itself. > + */ > + uint32_t offset; /* 0x0-0x3 */ > + uint8_t rsvd1[8]; /* 0x4-0xB */ > + uint32_t ddrinitdelay; /* 0xC-0xF */ > + uint32_t match_addr; /* 0x10-0x13 */ > + uint32_t match_mask; /* 0x14-0x17 */ > + uint32_t match_value; /* 0x18-0x1B */ > + uint8_t ddrwritetype; /* 0x1C */ > + uint8_t ddrresetmpp; /* 0x1D */ > + uint8_t ddrclkenmpp; /* 0x1E */ > + uint8_t ddrmppdelay; /* 0x1F */ > + struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */ > + uint8_t rsvd2[7]; /* 0x1D8-0x1DE */ > + uint8_t checksum; /* 0x1DF */ > +} __packed; > + > +/* Structure of the binary code header, version 0 (Dove) */ > +struct binext_hdr_v0 { > + uint32_t match_addr; /* 0x00-0x03 */ > + uint32_t match_mask; /* 0x04-0x07 */ > + uint32_t match_value; /* 0x08-0x0B */ > + uint32_t offset; /* 0x0C-0x0F */ > + uint32_t destaddr; /* 0x10-0x13 */ > + uint32_t size; /* 0x14-0x17 */ > + uint32_t execaddr; /* 0x18-0x1B */ > + uint32_t param1; /* 0x1C-0x1F */ > + uint32_t param2; /* 0x20-0x23 */ > + uint32_t param3; /* 0x24-0x27 */ > + uint32_t param4; /* 0x28-0x2B */ > + uint8_t params; /* 0x2C */ > + uint8_t rsvd1; /* 0x2D */ > + uint8_t rsvd2; /* 0x2E */ > + uint8_t checksum; /* 0x2F */ > + uint8_t code[2000]; /* 0x30-0x7FF */ > } __packed; > > /* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ > @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) > if (kwbimage_version(header) == 0) { > const struct main_hdr_v0 *hdr = header; > > + /* > + * First extension header starts immediately after the main > + * header without any padding. Between extension headers is > + * 0x20 byte padding. There is no padding after the last > + * extension header. First binary code header starts immediately > + * after the last extension header (or immediately after the > + * main header if there is no extension header) without any > + * padding. There is no padding between binary code headers and > + * neither after the last binary code header. > + */ > return sizeof(*hdr) + > - hdr->ext ? sizeof(struct ext_hdr_v0) : 0; > + hdr->ext * sizeof(struct ext_hdr_v0) + > + ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) + > + hdr->binext * sizeof(struct binext_hdr_v0); > } else { > const struct main_hdr_v1 *hdr = header; > > > > It fixes kwbheader_size() function to returns correct size of the image > header (with all v0 extensions), so it could help kwboot to convert > image with non-UART sign to UART version and send it over UART.
Applied the patch, and make tools gave this error:
tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no member named ‘binext’ 255 | hdr->binext * sizeof(struct binext_hdr_v0);
Thanks, Tony
Ah, I have not sent whole patch...
In tools/kwbimage.h for struct main_hdr_v0 { ... } replace
uint16_t rsvd2;
by
uint8_t rsvd2; uint8_t binext;
Fixed that, and then I ran it the same way before. In the serial console, tell BootROM to set the boot device to UART, and then exit, run kwboot.
<BEGIN log>
Bootstrap 2.33>x 0x0E
Terminating... Thanks for using picocom
./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] <END log>
It hung here. And I have to recycle power to boot again.
Observation: in the previous run with unpatched kwboot, the header size was 512 bytes, and the image was 607664 bytes. So this time kwboot sends the extension header, too. Not sure if 3072 bytes is correct.
If I parsed that image (file mtd0.t5335z) correctly it has:
- main header (0x20)
- ext header (0x1E0)
- 0x20 padding (0x20)
- ext header (0x1E0)
- bin header (0x800)
- image data (0x93bb0)
So it is: 3072 bytes for headers + 605104 bytes for image data, which now matches.
Plus in main header is stored that image data starts at offset 0xc00 which is 3072 bytes.
Now kwboot showed just that is patching UART signature and no more alignment, so it should send headers and data without adding any additional padding or alignment.
If it still does not work, I do not have an idea...
It would be required to take U-Boot source code for that board and build UART image from sources. Maybe UART version needs to be compiled differently, like it was in past also for Armada builds.
To double check I dumped the images.
./kwboot-2022/dumpimage -T kwbimage -p -1 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.cfg -rw-r--r-- 1 root root 1155 Feb 13 15:58 mtd0.t5335z.cfg
This cfg file is incomplete as kwbimage does not read those new structures.
I got your other patch for kwbimage.c compiled in dumpimage. So the cfg seems OK.
# cat /tmp/mtd0.t5335z.cfg
BOOT_FROM spi #SRC_ADDRESS 0xc00 #BLOCK_SIZE 0x93bb0 #DEST_ADDRESS 0x00600000 #EXEC_ADDRESS 0x00690000 DATA 0xd0020104 0x00000000 DATA 0xd0800020 0x00022530 DATA 0xd0800030 0x00022330 DATA 0xd0800050 0x911a00c3 DATA 0xd0800060 0x74780504 DATA 0xd0800190 0xc2005554 DATA 0xd08001c0 0x3694da09 DATA 0xd0800650 0x00130131 DATA 0xd0800660 0x84040200 DATA 0xd0800080 0x00000000 DATA 0xd0800090 0x00080000 DATA 0xd08000f0 0xc0000000 DATA 0xd08001a0 0x20c0c009 DATA 0xd0800280 0x010e0202 DATA 0xd0800760 0x00000201 DATA 0xd0800770 0x0100000a DATA 0xd0800140 0x20004044 DATA 0xd08001d0 0x177c2779 DATA 0xd08001e0 0x07700330 DATA 0xd08001f0 0x00000033 DATA 0xd0800200 0x0011311c DATA 0xd0800210 0x00300000 DATA 0xd0800240 0x80000000 DATA 0xd0800510 0x010e0101 DATA 0xd0800230 0x2028006a DATA 0xd0800e10 0x00280062 DATA 0xd0800e20 0x00280062 DATA 0xd0800e30 0x00280062 DATA 0xd0800100 0x000e0001 DATA 0xd0800110 0x000e0000 DATA 0xd0800120 0x00000001 DATA 0xd00d040c 0x00000008 DATA 0xd0010604 0x00004215 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0x0 0x0 #RSVD2 0x100r
There is also bin header for '-p 1' but again kwbimage cannot extract it yet.
(Btw, I have WIP patches for this stuff, if you are interesting I can send it)
Sure, if you want early testing while you're working on it, please send.
Thanks, Tony
./kwboot-2022/dumpimage -T kwbimage -p 0 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.0.img -rw------- 1 root root 605100 Feb 13 15:58 mtd0.t5335z.0.img
./kwboot-2022/mkimage -l ./t5335z/mtd0.t5335z Image Type: MVEBU Boot from spi Image Image version:0 Data Size: 605100 Bytes = 590.92 KiB = 0.58 MiB Load Address: 00600000 Entry Point: 00690000
So it is checked out. The image is 605100 with 4 bytes checksum = 605104. Did I read it correctly? i.e. the dump does not include the checksum?
Yes!
Seems I got to get to work on that stock UART image!
Thanks, Tony
On Sunday 13 February 2022 17:10:26 Tony Dinh wrote:
Hi Pali,
Please see below.
On Sun, Feb 13, 2022 at 4:21 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 16:08:51 Tony Dinh wrote:
Hi Pali,
On Sun, Feb 13, 2022 at 3:42 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 15:24:46 Tony Dinh wrote:
Hi Pali,
Looks different, but the BootROM did not start the image. Please see the log below.
On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 14:45:07 Tony Dinh wrote: > Hi Pali, > > Some compile errors, please see below. > > On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote: > > > > On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote: > > > *** Run kwboot > > > > > > # kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z > > > Patching image boot signature to UART > > > Aligning image header to Xmodem block size > > > Waiting 2s and flushing tty > > > Sending boot image header (512 bytes)... > > > 25 % [.... ] > > > Done > > > Sending boot image data (607664 bytes)... > > > 0 % [......................................................................] > > > 1 % [......................................................................] > > > 2 % [......................................................................] > > > <snip> > > > 95 % [......................................................................] > > > 97 % [......................................................................] > > > 98 % [.......................................................... ] > > > Done > > > Finishing transfer > > > [Type Ctrl-\ + c to quit] > > > > > > *** Hung here! BootROM did not execute the image payload. > > > *** > > > *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with > > > *** this command: > > > *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync > > > > > > <End log> > > > > > > > > > - Pali's observation: > > > > > > It looks like Dove uses kwbimage v0 format with extensions, at > > > least according to Function Spec. See 'Binary Code Extension' and > > > 'Header Extension'. Currently kwboot and kwbimage supports v0 image only > > > with one extension. > > > > I quickly looked at it. Could you try following patch? > > > > diff --git a/tools/kwbimage.h b/tools/kwbimage.h > > index 74e5d87a4fef..15e83ececc76 100644 > > --- a/tools/kwbimage.h > > +++ b/tools/kwbimage.h > > @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { > > uint32_t rdata; > > } __packed; > > > > -#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg)) > > - > > +/* Structure of the extension header, version 0 (Kirkwood, Dove) */ > > struct ext_hdr_v0 { > > - uint32_t offset; > > - uint8_t reserved[0x20 - sizeof(uint32_t)]; > > - struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT]; > > - uint8_t reserved2[7]; > > - uint8_t checksum; > > + /* > > + * Beware that extension header offsets specified in 88AP510 Functional > > + * Specifications are relative to the start of the main header, not to > > + * the start of the extension header itself. > > + */ > > + uint32_t offset; /* 0x0-0x3 */ > > + uint8_t rsvd1[8]; /* 0x4-0xB */ > > + uint32_t ddrinitdelay; /* 0xC-0xF */ > > + uint32_t match_addr; /* 0x10-0x13 */ > > + uint32_t match_mask; /* 0x14-0x17 */ > > + uint32_t match_value; /* 0x18-0x1B */ > > + uint8_t ddrwritetype; /* 0x1C */ > > + uint8_t ddrresetmpp; /* 0x1D */ > > + uint8_t ddrclkenmpp; /* 0x1E */ > > + uint8_t ddrmppdelay; /* 0x1F */ > > + struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */ > > + uint8_t rsvd2[7]; /* 0x1D8-0x1DE */ > > + uint8_t checksum; /* 0x1DF */ > > +} __packed; > > + > > +/* Structure of the binary code header, version 0 (Dove) */ > > +struct binext_hdr_v0 { > > + uint32_t match_addr; /* 0x00-0x03 */ > > + uint32_t match_mask; /* 0x04-0x07 */ > > + uint32_t match_value; /* 0x08-0x0B */ > > + uint32_t offset; /* 0x0C-0x0F */ > > + uint32_t destaddr; /* 0x10-0x13 */ > > + uint32_t size; /* 0x14-0x17 */ > > + uint32_t execaddr; /* 0x18-0x1B */ > > + uint32_t param1; /* 0x1C-0x1F */ > > + uint32_t param2; /* 0x20-0x23 */ > > + uint32_t param3; /* 0x24-0x27 */ > > + uint32_t param4; /* 0x28-0x2B */ > > + uint8_t params; /* 0x2C */ > > + uint8_t rsvd1; /* 0x2D */ > > + uint8_t rsvd2; /* 0x2E */ > > + uint8_t checksum; /* 0x2F */ > > + uint8_t code[2000]; /* 0x30-0x7FF */ > > } __packed; > > > > /* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ > > @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) > > if (kwbimage_version(header) == 0) { > > const struct main_hdr_v0 *hdr = header; > > > > + /* > > + * First extension header starts immediately after the main > > + * header without any padding. Between extension headers is > > + * 0x20 byte padding. There is no padding after the last > > + * extension header. First binary code header starts immediately > > + * after the last extension header (or immediately after the > > + * main header if there is no extension header) without any > > + * padding. There is no padding between binary code headers and > > + * neither after the last binary code header. > > + */ > > return sizeof(*hdr) + > > - hdr->ext ? sizeof(struct ext_hdr_v0) : 0; > > + hdr->ext * sizeof(struct ext_hdr_v0) + > > + ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) + > > + hdr->binext * sizeof(struct binext_hdr_v0); > > } else { > > const struct main_hdr_v1 *hdr = header; > > > > > > > > It fixes kwbheader_size() function to returns correct size of the image > > header (with all v0 extensions), so it could help kwboot to convert > > image with non-UART sign to UART version and send it over UART. > > Applied the patch, and make tools gave this error: > > tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no > member named ‘binext’ > 255 | hdr->binext * sizeof(struct binext_hdr_v0); > > Thanks, > Tony
Ah, I have not sent whole patch...
In tools/kwbimage.h for struct main_hdr_v0 { ... } replace
uint16_t rsvd2;
by
uint8_t rsvd2; uint8_t binext;
Fixed that, and then I ran it the same way before. In the serial console, tell BootROM to set the boot device to UART, and then exit, run kwboot.
<BEGIN log>
Bootstrap 2.33>x 0x0E
Terminating... Thanks for using picocom
./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] <END log>
It hung here. And I have to recycle power to boot again.
Observation: in the previous run with unpatched kwboot, the header size was 512 bytes, and the image was 607664 bytes. So this time kwboot sends the extension header, too. Not sure if 3072 bytes is correct.
If I parsed that image (file mtd0.t5335z) correctly it has:
- main header (0x20)
- ext header (0x1E0)
- 0x20 padding (0x20)
- ext header (0x1E0)
- bin header (0x800)
- image data (0x93bb0)
So it is: 3072 bytes for headers + 605104 bytes for image data, which now matches.
Plus in main header is stored that image data starts at offset 0xc00 which is 3072 bytes.
Now kwboot showed just that is patching UART signature and no more alignment, so it should send headers and data without adding any additional padding or alignment.
If it still does not work, I do not have an idea...
It would be required to take U-Boot source code for that board and build UART image from sources. Maybe UART version needs to be compiled differently, like it was in past also for Armada builds.
To double check I dumped the images.
./kwboot-2022/dumpimage -T kwbimage -p -1 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.cfg -rw-r--r-- 1 root root 1155 Feb 13 15:58 mtd0.t5335z.cfg
This cfg file is incomplete as kwbimage does not read those new structures.
I got your other patch for kwbimage.c compiled in dumpimage. So the cfg seems OK.
No, it is not. There are completely missing information from struct ext_hdr_v0 and struct binext_hdr_v0.
# cat /tmp/mtd0.t5335z.cfg
BOOT_FROM spi #SRC_ADDRESS 0xc00 #BLOCK_SIZE 0x93bb0 #DEST_ADDRESS 0x00600000 #EXEC_ADDRESS 0x00690000 DATA 0xd0020104 0x00000000 DATA 0xd0800020 0x00022530 DATA 0xd0800030 0x00022330 DATA 0xd0800050 0x911a00c3 DATA 0xd0800060 0x74780504 DATA 0xd0800190 0xc2005554 DATA 0xd08001c0 0x3694da09 DATA 0xd0800650 0x00130131 DATA 0xd0800660 0x84040200 DATA 0xd0800080 0x00000000 DATA 0xd0800090 0x00080000 DATA 0xd08000f0 0xc0000000 DATA 0xd08001a0 0x20c0c009 DATA 0xd0800280 0x010e0202 DATA 0xd0800760 0x00000201 DATA 0xd0800770 0x0100000a DATA 0xd0800140 0x20004044 DATA 0xd08001d0 0x177c2779 DATA 0xd08001e0 0x07700330 DATA 0xd08001f0 0x00000033 DATA 0xd0800200 0x0011311c DATA 0xd0800210 0x00300000 DATA 0xd0800240 0x80000000 DATA 0xd0800510 0x010e0101 DATA 0xd0800230 0x2028006a DATA 0xd0800e10 0x00280062 DATA 0xd0800e20 0x00280062 DATA 0xd0800e30 0x00280062 DATA 0xd0800100 0x000e0001 DATA 0xd0800110 0x000e0000 DATA 0xd0800120 0x00000001 DATA 0xd00d040c 0x00000008 DATA 0xd0010604 0x00004215 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0x0 0x0 #RSVD2 0x100r
Plus see this incomplete RSVD2.
There is also bin header for '-p 1' but again kwbimage cannot extract it yet.
(Btw, I have WIP patches for this stuff, if you are interesting I can send it)
Sure, if you want early testing while you're working on it, please send.
Ok, later I can prepare patches for you.
Thanks, Tony
./kwboot-2022/dumpimage -T kwbimage -p 0 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.0.img -rw------- 1 root root 605100 Feb 13 15:58 mtd0.t5335z.0.img
./kwboot-2022/mkimage -l ./t5335z/mtd0.t5335z Image Type: MVEBU Boot from spi Image Image version:0 Data Size: 605100 Bytes = 590.92 KiB = 0.58 MiB Load Address: 00600000 Entry Point: 00690000
So it is checked out. The image is 605100 with 4 bytes checksum = 605104. Did I read it correctly? i.e. the dump does not include the checksum?
Yes!
Seems I got to get to work on that stock UART image!
Thanks, Tony
Hi Pali,
On Mon, Feb 14, 2022 at 1:58 AM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 17:10:26 Tony Dinh wrote:
Hi Pali,
Please see below.
On Sun, Feb 13, 2022 at 4:21 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 16:08:51 Tony Dinh wrote:
Hi Pali,
On Sun, Feb 13, 2022 at 3:42 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 15:24:46 Tony Dinh wrote:
Hi Pali,
Looks different, but the BootROM did not start the image. Please see the log below.
On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote: > > On Sunday 13 February 2022 14:45:07 Tony Dinh wrote: > > Hi Pali, > > > > Some compile errors, please see below. > > > > On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote: > > > > > > On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote: > > > > *** Run kwboot > > > > > > > > # kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z > > > > Patching image boot signature to UART > > > > Aligning image header to Xmodem block size > > > > Waiting 2s and flushing tty > > > > Sending boot image header (512 bytes)... > > > > 25 % [.... ] > > > > Done > > > > Sending boot image data (607664 bytes)... > > > > 0 % [......................................................................] > > > > 1 % [......................................................................] > > > > 2 % [......................................................................] > > > > <snip> > > > > 95 % [......................................................................] > > > > 97 % [......................................................................] > > > > 98 % [.......................................................... ] > > > > Done > > > > Finishing transfer > > > > [Type Ctrl-\ + c to quit] > > > > > > > > *** Hung here! BootROM did not execute the image payload. > > > > *** > > > > *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with > > > > *** this command: > > > > *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync > > > > > > > > <End log> > > > > > > > > > > > > - Pali's observation: > > > > > > > > It looks like Dove uses kwbimage v0 format with extensions, at > > > > least according to Function Spec. See 'Binary Code Extension' and > > > > 'Header Extension'. Currently kwboot and kwbimage supports v0 image only > > > > with one extension. > > > > > > I quickly looked at it. Could you try following patch? > > > > > > diff --git a/tools/kwbimage.h b/tools/kwbimage.h > > > index 74e5d87a4fef..15e83ececc76 100644 > > > --- a/tools/kwbimage.h > > > +++ b/tools/kwbimage.h > > > @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { > > > uint32_t rdata; > > > } __packed; > > > > > > -#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg)) > > > - > > > +/* Structure of the extension header, version 0 (Kirkwood, Dove) */ > > > struct ext_hdr_v0 { > > > - uint32_t offset; > > > - uint8_t reserved[0x20 - sizeof(uint32_t)]; > > > - struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT]; > > > - uint8_t reserved2[7]; > > > - uint8_t checksum; > > > + /* > > > + * Beware that extension header offsets specified in 88AP510 Functional > > > + * Specifications are relative to the start of the main header, not to > > > + * the start of the extension header itself. > > > + */ > > > + uint32_t offset; /* 0x0-0x3 */ > > > + uint8_t rsvd1[8]; /* 0x4-0xB */ > > > + uint32_t ddrinitdelay; /* 0xC-0xF */ > > > + uint32_t match_addr; /* 0x10-0x13 */ > > > + uint32_t match_mask; /* 0x14-0x17 */ > > > + uint32_t match_value; /* 0x18-0x1B */ > > > + uint8_t ddrwritetype; /* 0x1C */ > > > + uint8_t ddrresetmpp; /* 0x1D */ > > > + uint8_t ddrclkenmpp; /* 0x1E */ > > > + uint8_t ddrmppdelay; /* 0x1F */ > > > + struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */ > > > + uint8_t rsvd2[7]; /* 0x1D8-0x1DE */ > > > + uint8_t checksum; /* 0x1DF */ > > > +} __packed; > > > + > > > +/* Structure of the binary code header, version 0 (Dove) */ > > > +struct binext_hdr_v0 { > > > + uint32_t match_addr; /* 0x00-0x03 */ > > > + uint32_t match_mask; /* 0x04-0x07 */ > > > + uint32_t match_value; /* 0x08-0x0B */ > > > + uint32_t offset; /* 0x0C-0x0F */ > > > + uint32_t destaddr; /* 0x10-0x13 */ > > > + uint32_t size; /* 0x14-0x17 */ > > > + uint32_t execaddr; /* 0x18-0x1B */ > > > + uint32_t param1; /* 0x1C-0x1F */ > > > + uint32_t param2; /* 0x20-0x23 */ > > > + uint32_t param3; /* 0x24-0x27 */ > > > + uint32_t param4; /* 0x28-0x2B */ > > > + uint8_t params; /* 0x2C */ > > > + uint8_t rsvd1; /* 0x2D */ > > > + uint8_t rsvd2; /* 0x2E */ > > > + uint8_t checksum; /* 0x2F */ > > > + uint8_t code[2000]; /* 0x30-0x7FF */ > > > } __packed; > > > > > > /* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ > > > @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) > > > if (kwbimage_version(header) == 0) { > > > const struct main_hdr_v0 *hdr = header; > > > > > > + /* > > > + * First extension header starts immediately after the main > > > + * header without any padding. Between extension headers is > > > + * 0x20 byte padding. There is no padding after the last > > > + * extension header. First binary code header starts immediately > > > + * after the last extension header (or immediately after the > > > + * main header if there is no extension header) without any > > > + * padding. There is no padding between binary code headers and > > > + * neither after the last binary code header. > > > + */ > > > return sizeof(*hdr) + > > > - hdr->ext ? sizeof(struct ext_hdr_v0) : 0; > > > + hdr->ext * sizeof(struct ext_hdr_v0) + > > > + ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) + > > > + hdr->binext * sizeof(struct binext_hdr_v0); > > > } else { > > > const struct main_hdr_v1 *hdr = header; > > > > > > > > > > > > It fixes kwbheader_size() function to returns correct size of the image > > > header (with all v0 extensions), so it could help kwboot to convert > > > image with non-UART sign to UART version and send it over UART. > > > > Applied the patch, and make tools gave this error: > > > > tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no > > member named ‘binext’ > > 255 | hdr->binext * sizeof(struct binext_hdr_v0); > > > > Thanks, > > Tony > > Ah, I have not sent whole patch... > > In tools/kwbimage.h for struct main_hdr_v0 { ... } replace > > uint16_t rsvd2; > > by > > uint8_t rsvd2; > uint8_t binext; > >
Fixed that, and then I ran it the same way before. In the serial console, tell BootROM to set the boot device to UART, and then exit, run kwboot.
<BEGIN log>
Bootstrap 2.33>x 0x0E
Terminating... Thanks for using picocom
./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit] <END log>
It hung here. And I have to recycle power to boot again.
Observation: in the previous run with unpatched kwboot, the header size was 512 bytes, and the image was 607664 bytes. So this time kwboot sends the extension header, too. Not sure if 3072 bytes is correct.
If I parsed that image (file mtd0.t5335z) correctly it has:
- main header (0x20)
- ext header (0x1E0)
- 0x20 padding (0x20)
- ext header (0x1E0)
- bin header (0x800)
- image data (0x93bb0)
So it is: 3072 bytes for headers + 605104 bytes for image data, which now matches.
Plus in main header is stored that image data starts at offset 0xc00 which is 3072 bytes.
Now kwboot showed just that is patching UART signature and no more alignment, so it should send headers and data without adding any additional padding or alignment.
If it still does not work, I do not have an idea...
It would be required to take U-Boot source code for that board and build UART image from sources. Maybe UART version needs to be compiled differently, like it was in past also for Armada builds.
To double check I dumped the images.
./kwboot-2022/dumpimage -T kwbimage -p -1 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.cfg -rw-r--r-- 1 root root 1155 Feb 13 15:58 mtd0.t5335z.cfg
This cfg file is incomplete as kwbimage does not read those new structures.
I got your other patch for kwbimage.c compiled in dumpimage. So the cfg seems OK.
No, it is not. There are completely missing information from struct ext_hdr_v0 and struct binext_hdr_v0.
Got it.
# cat /tmp/mtd0.t5335z.cfg
BOOT_FROM spi #SRC_ADDRESS 0xc00 #BLOCK_SIZE 0x93bb0 #DEST_ADDRESS 0x00600000 #EXEC_ADDRESS 0x00690000 DATA 0xd0020104 0x00000000 DATA 0xd0800020 0x00022530 DATA 0xd0800030 0x00022330 DATA 0xd0800050 0x911a00c3 DATA 0xd0800060 0x74780504 DATA 0xd0800190 0xc2005554 DATA 0xd08001c0 0x3694da09 DATA 0xd0800650 0x00130131 DATA 0xd0800660 0x84040200 DATA 0xd0800080 0x00000000 DATA 0xd0800090 0x00080000 DATA 0xd08000f0 0xc0000000 DATA 0xd08001a0 0x20c0c009 DATA 0xd0800280 0x010e0202 DATA 0xd0800760 0x00000201 DATA 0xd0800770 0x0100000a DATA 0xd0800140 0x20004044 DATA 0xd08001d0 0x177c2779 DATA 0xd08001e0 0x07700330 DATA 0xd08001f0 0x00000033 DATA 0xd0800200 0x0011311c DATA 0xd0800210 0x00300000 DATA 0xd0800240 0x80000000 DATA 0xd0800510 0x010e0101 DATA 0xd0800230 0x2028006a DATA 0xd0800e10 0x00280062 DATA 0xd0800e20 0x00280062 DATA 0xd0800e30 0x00280062 DATA 0xd0800100 0x000e0001 DATA 0xd0800110 0x000e0000 DATA 0xd0800120 0x00000001 DATA 0xd00d040c 0x00000008 DATA 0xd0010604 0x00004215 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0x0 0x0 #RSVD2 0x100r
Plus see this incomplete RSVD2.
Indeed. This is the missing info that I've been looking for with other Kirkwood boards, too. I can't wait to see the patch :)
Thanks, Tony
There is also bin header for '-p 1' but again kwbimage cannot extract it yet.
(Btw, I have WIP patches for this stuff, if you are interesting I can send it)
Sure, if you want early testing while you're working on it, please send.
Ok, later I can prepare patches for you.
Thanks, Tony
./kwboot-2022/dumpimage -T kwbimage -p 0 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.0.img -rw------- 1 root root 605100 Feb 13 15:58 mtd0.t5335z.0.img
./kwboot-2022/mkimage -l ./t5335z/mtd0.t5335z Image Type: MVEBU Boot from spi Image Image version:0 Data Size: 605100 Bytes = 590.92 KiB = 0.58 MiB Load Address: 00600000 Entry Point: 00690000
So it is checked out. The image is 605100 with 4 bytes checksum = 605104. Did I read it correctly? i.e. the dump does not include the checksum?
Yes!
Seems I got to get to work on that stock UART image!
Thanks, Tony
On Monday 14 February 2022 14:00:19 Tony Dinh wrote:
Hi Pali,
On Mon, Feb 14, 2022 at 1:58 AM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 17:10:26 Tony Dinh wrote:
Hi Pali,
Please see below.
On Sun, Feb 13, 2022 at 4:21 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 16:08:51 Tony Dinh wrote:
Hi Pali,
On Sun, Feb 13, 2022 at 3:42 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 15:24:46 Tony Dinh wrote: > Hi Pali, > > Looks different, but the BootROM did not start the image. Please see > the log below. > > On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote: > > > > On Sunday 13 February 2022 14:45:07 Tony Dinh wrote: > > > Hi Pali, > > > > > > Some compile errors, please see below. > > > > > > On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote: > > > > > > > > On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote: > > > > > *** Run kwboot > > > > > > > > > > # kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z > > > > > Patching image boot signature to UART > > > > > Aligning image header to Xmodem block size > > > > > Waiting 2s and flushing tty > > > > > Sending boot image header (512 bytes)... > > > > > 25 % [.... ] > > > > > Done > > > > > Sending boot image data (607664 bytes)... > > > > > 0 % [......................................................................] > > > > > 1 % [......................................................................] > > > > > 2 % [......................................................................] > > > > > <snip> > > > > > 95 % [......................................................................] > > > > > 97 % [......................................................................] > > > > > 98 % [.......................................................... ] > > > > > Done > > > > > Finishing transfer > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > *** Hung here! BootROM did not execute the image payload. > > > > > *** > > > > > *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with > > > > > *** this command: > > > > > *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync > > > > > > > > > > <End log> > > > > > > > > > > > > > > > - Pali's observation: > > > > > > > > > > It looks like Dove uses kwbimage v0 format with extensions, at > > > > > least according to Function Spec. See 'Binary Code Extension' and > > > > > 'Header Extension'. Currently kwboot and kwbimage supports v0 image only > > > > > with one extension. > > > > > > > > I quickly looked at it. Could you try following patch? > > > > > > > > diff --git a/tools/kwbimage.h b/tools/kwbimage.h > > > > index 74e5d87a4fef..15e83ececc76 100644 > > > > --- a/tools/kwbimage.h > > > > +++ b/tools/kwbimage.h > > > > @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { > > > > uint32_t rdata; > > > > } __packed; > > > > > > > > -#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg)) > > > > - > > > > +/* Structure of the extension header, version 0 (Kirkwood, Dove) */ > > > > struct ext_hdr_v0 { > > > > - uint32_t offset; > > > > - uint8_t reserved[0x20 - sizeof(uint32_t)]; > > > > - struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT]; > > > > - uint8_t reserved2[7]; > > > > - uint8_t checksum; > > > > + /* > > > > + * Beware that extension header offsets specified in 88AP510 Functional > > > > + * Specifications are relative to the start of the main header, not to > > > > + * the start of the extension header itself. > > > > + */ > > > > + uint32_t offset; /* 0x0-0x3 */ > > > > + uint8_t rsvd1[8]; /* 0x4-0xB */ > > > > + uint32_t ddrinitdelay; /* 0xC-0xF */ > > > > + uint32_t match_addr; /* 0x10-0x13 */ > > > > + uint32_t match_mask; /* 0x14-0x17 */ > > > > + uint32_t match_value; /* 0x18-0x1B */ > > > > + uint8_t ddrwritetype; /* 0x1C */ > > > > + uint8_t ddrresetmpp; /* 0x1D */ > > > > + uint8_t ddrclkenmpp; /* 0x1E */ > > > > + uint8_t ddrmppdelay; /* 0x1F */ > > > > + struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */ > > > > + uint8_t rsvd2[7]; /* 0x1D8-0x1DE */ > > > > + uint8_t checksum; /* 0x1DF */ > > > > +} __packed; > > > > + > > > > +/* Structure of the binary code header, version 0 (Dove) */ > > > > +struct binext_hdr_v0 { > > > > + uint32_t match_addr; /* 0x00-0x03 */ > > > > + uint32_t match_mask; /* 0x04-0x07 */ > > > > + uint32_t match_value; /* 0x08-0x0B */ > > > > + uint32_t offset; /* 0x0C-0x0F */ > > > > + uint32_t destaddr; /* 0x10-0x13 */ > > > > + uint32_t size; /* 0x14-0x17 */ > > > > + uint32_t execaddr; /* 0x18-0x1B */ > > > > + uint32_t param1; /* 0x1C-0x1F */ > > > > + uint32_t param2; /* 0x20-0x23 */ > > > > + uint32_t param3; /* 0x24-0x27 */ > > > > + uint32_t param4; /* 0x28-0x2B */ > > > > + uint8_t params; /* 0x2C */ > > > > + uint8_t rsvd1; /* 0x2D */ > > > > + uint8_t rsvd2; /* 0x2E */ > > > > + uint8_t checksum; /* 0x2F */ > > > > + uint8_t code[2000]; /* 0x30-0x7FF */ > > > > } __packed; > > > > > > > > /* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ > > > > @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) > > > > if (kwbimage_version(header) == 0) { > > > > const struct main_hdr_v0 *hdr = header; > > > > > > > > + /* > > > > + * First extension header starts immediately after the main > > > > + * header without any padding. Between extension headers is > > > > + * 0x20 byte padding. There is no padding after the last > > > > + * extension header. First binary code header starts immediately > > > > + * after the last extension header (or immediately after the > > > > + * main header if there is no extension header) without any > > > > + * padding. There is no padding between binary code headers and > > > > + * neither after the last binary code header. > > > > + */ > > > > return sizeof(*hdr) + > > > > - hdr->ext ? sizeof(struct ext_hdr_v0) : 0; > > > > + hdr->ext * sizeof(struct ext_hdr_v0) + > > > > + ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) + > > > > + hdr->binext * sizeof(struct binext_hdr_v0); > > > > } else { > > > > const struct main_hdr_v1 *hdr = header; > > > > > > > > > > > > > > > > It fixes kwbheader_size() function to returns correct size of the image > > > > header (with all v0 extensions), so it could help kwboot to convert > > > > image with non-UART sign to UART version and send it over UART. > > > > > > Applied the patch, and make tools gave this error: > > > > > > tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no > > > member named ‘binext’ > > > 255 | hdr->binext * sizeof(struct binext_hdr_v0); > > > > > > Thanks, > > > Tony > > > > Ah, I have not sent whole patch... > > > > In tools/kwbimage.h for struct main_hdr_v0 { ... } replace > > > > uint16_t rsvd2; > > > > by > > > > uint8_t rsvd2; > > uint8_t binext; > > > > > > Fixed that, and then I ran it the same way before. In the serial > console, tell BootROM to set the boot device to UART, and then exit, > run kwboot. > > <BEGIN log> > > Bootstrap 2.33>x 0x0E > > Terminating... > Thanks for using picocom > > ./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z > kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty > Patching image boot signature to UART > Sending boot image header (3072 bytes)... > 4 % [........................ ] > Done > Sending boot image data (605104 bytes)... > 0 % [......................................................................] > <snip> > 97 % [......................................................................] > 99 % [...................................... ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > <END log> > > It hung here. And I have to recycle power to boot again. > > Observation: in the previous run with unpatched kwboot, the header > size was 512 bytes, and the image was 607664 bytes. So this time > kwboot sends the extension header, too. Not sure if 3072 bytes is > correct.
If I parsed that image (file mtd0.t5335z) correctly it has:
- main header (0x20)
- ext header (0x1E0)
- 0x20 padding (0x20)
- ext header (0x1E0)
- bin header (0x800)
- image data (0x93bb0)
So it is: 3072 bytes for headers + 605104 bytes for image data, which now matches.
Plus in main header is stored that image data starts at offset 0xc00 which is 3072 bytes.
Now kwboot showed just that is patching UART signature and no more alignment, so it should send headers and data without adding any additional padding or alignment.
If it still does not work, I do not have an idea...
It would be required to take U-Boot source code for that board and build UART image from sources. Maybe UART version needs to be compiled differently, like it was in past also for Armada builds.
To double check I dumped the images.
./kwboot-2022/dumpimage -T kwbimage -p -1 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.cfg -rw-r--r-- 1 root root 1155 Feb 13 15:58 mtd0.t5335z.cfg
This cfg file is incomplete as kwbimage does not read those new structures.
I got your other patch for kwbimage.c compiled in dumpimage. So the cfg seems OK.
No, it is not. There are completely missing information from struct ext_hdr_v0 and struct binext_hdr_v0.
Got it.
# cat /tmp/mtd0.t5335z.cfg
BOOT_FROM spi #SRC_ADDRESS 0xc00 #BLOCK_SIZE 0x93bb0 #DEST_ADDRESS 0x00600000 #EXEC_ADDRESS 0x00690000 DATA 0xd0020104 0x00000000 DATA 0xd0800020 0x00022530 DATA 0xd0800030 0x00022330 DATA 0xd0800050 0x911a00c3 DATA 0xd0800060 0x74780504 DATA 0xd0800190 0xc2005554 DATA 0xd08001c0 0x3694da09 DATA 0xd0800650 0x00130131 DATA 0xd0800660 0x84040200 DATA 0xd0800080 0x00000000 DATA 0xd0800090 0x00080000 DATA 0xd08000f0 0xc0000000 DATA 0xd08001a0 0x20c0c009 DATA 0xd0800280 0x010e0202 DATA 0xd0800760 0x00000201 DATA 0xd0800770 0x0100000a DATA 0xd0800140 0x20004044 DATA 0xd08001d0 0x177c2779 DATA 0xd08001e0 0x07700330 DATA 0xd08001f0 0x00000033 DATA 0xd0800200 0x0011311c DATA 0xd0800210 0x00300000 DATA 0xd0800240 0x80000000 DATA 0xd0800510 0x010e0101 DATA 0xd0800230 0x2028006a DATA 0xd0800e10 0x00280062 DATA 0xd0800e20 0x00280062 DATA 0xd0800e30 0x00280062 DATA 0xd0800100 0x000e0001 DATA 0xd0800110 0x000e0000 DATA 0xd0800120 0x00000001 DATA 0xd00d040c 0x00000008 DATA 0xd0010604 0x00004215 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0x0 0x0 #RSVD2 0x100r
Plus see this incomplete RSVD2.
Indeed. This is the missing info that I've been looking for with other Kirkwood boards, too. I can't wait to see the patch :)
Now I sent it, it is there: https://patchwork.ozlabs.org/project/uboot/list/?series=286325&state=*
Thanks, Tony
There is also bin header for '-p 1' but again kwbimage cannot extract it yet.
(Btw, I have WIP patches for this stuff, if you are interesting I can send it)
Sure, if you want early testing while you're working on it, please send.
Ok, later I can prepare patches for you.
Thanks, Tony
./kwboot-2022/dumpimage -T kwbimage -p 0 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.0.img -rw------- 1 root root 605100 Feb 13 15:58 mtd0.t5335z.0.img
./kwboot-2022/mkimage -l ./t5335z/mtd0.t5335z Image Type: MVEBU Boot from spi Image Image version:0 Data Size: 605100 Bytes = 590.92 KiB = 0.58 MiB Load Address: 00600000 Entry Point: 00690000
So it is checked out. The image is 605100 with 4 bytes checksum = 605104. Did I read it correctly? i.e. the dump does not include the checksum?
Yes!
Seems I got to get to work on that stock UART image!
Do you have some _vendor_ bootable UART image?
Also look into Functional Specifications, chapter 5.7.1 Boot from UART. There is written: only one extended header is supported. But your SPI image have two extended headers and one binary header. So maybe you would have to strip one extended header...
Hi Pali,
On Tue, Feb 15, 2022 at 11:11 AM Pali Rohár pali@kernel.org wrote:
On Monday 14 February 2022 14:00:19 Tony Dinh wrote:
Hi Pali,
On Mon, Feb 14, 2022 at 1:58 AM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 17:10:26 Tony Dinh wrote:
Hi Pali,
Please see below.
On Sun, Feb 13, 2022 at 4:21 PM Pali Rohár pali@kernel.org wrote:
On Sunday 13 February 2022 16:08:51 Tony Dinh wrote:
Hi Pali,
On Sun, Feb 13, 2022 at 3:42 PM Pali Rohár pali@kernel.org wrote: > > On Sunday 13 February 2022 15:24:46 Tony Dinh wrote: > > Hi Pali, > > > > Looks different, but the BootROM did not start the image. Please see > > the log below. > > > > On Sun, Feb 13, 2022 at 2:48 PM Pali Rohár pali@kernel.org wrote: > > > > > > On Sunday 13 February 2022 14:45:07 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > Some compile errors, please see below. > > > > > > > > On Sun, Feb 13, 2022 at 8:16 AM Pali Rohár pali@kernel.org wrote: > > > > > > > > > > On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote: > > > > > > *** Run kwboot > > > > > > > > > > > > # kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z > > > > > > Patching image boot signature to UART > > > > > > Aligning image header to Xmodem block size > > > > > > Waiting 2s and flushing tty > > > > > > Sending boot image header (512 bytes)... > > > > > > 25 % [.... ] > > > > > > Done > > > > > > Sending boot image data (607664 bytes)... > > > > > > 0 % [......................................................................] > > > > > > 1 % [......................................................................] > > > > > > 2 % [......................................................................] > > > > > > <snip> > > > > > > 95 % [......................................................................] > > > > > > 97 % [......................................................................] > > > > > > 98 % [.......................................................... ] > > > > > > Done > > > > > > Finishing transfer > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > > > > *** Hung here! BootROM did not execute the image payload. > > > > > > *** > > > > > > *** The file mtd0.t5335z is a dd dump from the SPI flash mtd0 with > > > > > > *** this command: > > > > > > *** # dd if=/dev/mtd0 of=mtd0.t5335z bs=768k conv=sync > > > > > > > > > > > > <End log> > > > > > > > > > > > > > > > > > > - Pali's observation: > > > > > > > > > > > > It looks like Dove uses kwbimage v0 format with extensions, at > > > > > > least according to Function Spec. See 'Binary Code Extension' and > > > > > > 'Header Extension'. Currently kwboot and kwbimage supports v0 image only > > > > > > with one extension. > > > > > > > > > > I quickly looked at it. Could you try following patch? > > > > > > > > > > diff --git a/tools/kwbimage.h b/tools/kwbimage.h > > > > > index 74e5d87a4fef..15e83ececc76 100644 > > > > > --- a/tools/kwbimage.h > > > > > +++ b/tools/kwbimage.h > > > > > @@ -61,14 +64,46 @@ struct ext_hdr_v0_reg { > > > > > uint32_t rdata; > > > > > } __packed; > > > > > > > > > > -#define EXT_HDR_V0_REG_COUNT ((0x1dc - 0x20) / sizeof(struct ext_hdr_v0_reg)) > > > > > - > > > > > +/* Structure of the extension header, version 0 (Kirkwood, Dove) */ > > > > > struct ext_hdr_v0 { > > > > > - uint32_t offset; > > > > > - uint8_t reserved[0x20 - sizeof(uint32_t)]; > > > > > - struct ext_hdr_v0_reg rcfg[EXT_HDR_V0_REG_COUNT]; > > > > > - uint8_t reserved2[7]; > > > > > - uint8_t checksum; > > > > > + /* > > > > > + * Beware that extension header offsets specified in 88AP510 Functional > > > > > + * Specifications are relative to the start of the main header, not to > > > > > + * the start of the extension header itself. > > > > > + */ > > > > > + uint32_t offset; /* 0x0-0x3 */ > > > > > + uint8_t rsvd1[8]; /* 0x4-0xB */ > > > > > + uint32_t ddrinitdelay; /* 0xC-0xF */ > > > > > + uint32_t match_addr; /* 0x10-0x13 */ > > > > > + uint32_t match_mask; /* 0x14-0x17 */ > > > > > + uint32_t match_value; /* 0x18-0x1B */ > > > > > + uint8_t ddrwritetype; /* 0x1C */ > > > > > + uint8_t ddrresetmpp; /* 0x1D */ > > > > > + uint8_t ddrclkenmpp; /* 0x1E */ > > > > > + uint8_t ddrmppdelay; /* 0x1F */ > > > > > + struct ext_hdr_v0_reg rcfg[55]; /* 0x20-0x1D7 */ > > > > > + uint8_t rsvd2[7]; /* 0x1D8-0x1DE */ > > > > > + uint8_t checksum; /* 0x1DF */ > > > > > +} __packed; > > > > > + > > > > > +/* Structure of the binary code header, version 0 (Dove) */ > > > > > +struct binext_hdr_v0 { > > > > > + uint32_t match_addr; /* 0x00-0x03 */ > > > > > + uint32_t match_mask; /* 0x04-0x07 */ > > > > > + uint32_t match_value; /* 0x08-0x0B */ > > > > > + uint32_t offset; /* 0x0C-0x0F */ > > > > > + uint32_t destaddr; /* 0x10-0x13 */ > > > > > + uint32_t size; /* 0x14-0x17 */ > > > > > + uint32_t execaddr; /* 0x18-0x1B */ > > > > > + uint32_t param1; /* 0x1C-0x1F */ > > > > > + uint32_t param2; /* 0x20-0x23 */ > > > > > + uint32_t param3; /* 0x24-0x27 */ > > > > > + uint32_t param4; /* 0x28-0x2B */ > > > > > + uint8_t params; /* 0x2C */ > > > > > + uint8_t rsvd1; /* 0x2D */ > > > > > + uint8_t rsvd2; /* 0x2E */ > > > > > + uint8_t checksum; /* 0x2F */ > > > > > + uint8_t code[2000]; /* 0x30-0x7FF */ > > > > > } __packed; > > > > > > > > > > /* Structure of the main header, version 1 (Armada 370/XP/375/38x/39x) */ > > > > > @@ -213,8 +248,20 @@ static inline size_t kwbheader_size(const void *header) > > > > > if (kwbimage_version(header) == 0) { > > > > > const struct main_hdr_v0 *hdr = header; > > > > > > > > > > + /* > > > > > + * First extension header starts immediately after the main > > > > > + * header without any padding. Between extension headers is > > > > > + * 0x20 byte padding. There is no padding after the last > > > > > + * extension header. First binary code header starts immediately > > > > > + * after the last extension header (or immediately after the > > > > > + * main header if there is no extension header) without any > > > > > + * padding. There is no padding between binary code headers and > > > > > + * neither after the last binary code header. > > > > > + */ > > > > > return sizeof(*hdr) + > > > > > - hdr->ext ? sizeof(struct ext_hdr_v0) : 0; > > > > > + hdr->ext * sizeof(struct ext_hdr_v0) + > > > > > + ((hdr->ext > 1) ? (hdr->ext * 0x20) : 0) + > > > > > + hdr->binext * sizeof(struct binext_hdr_v0); > > > > > } else { > > > > > const struct main_hdr_v1 *hdr = header; > > > > > > > > > > > > > > > > > > > > It fixes kwbheader_size() function to returns correct size of the image > > > > > header (with all v0 extensions), so it could help kwboot to convert > > > > > image with non-UART sign to UART version and send it over UART. > > > > > > > > Applied the patch, and make tools gave this error: > > > > > > > > tools/kwbimage.h:255:13: error: ‘const struct main_hdr_v0’ has no > > > > member named ‘binext’ > > > > 255 | hdr->binext * sizeof(struct binext_hdr_v0); > > > > > > > > Thanks, > > > > Tony > > > > > > Ah, I have not sent whole patch... > > > > > > In tools/kwbimage.h for struct main_hdr_v0 { ... } replace > > > > > > uint16_t rsvd2; > > > > > > by > > > > > > uint8_t rsvd2; > > > uint8_t binext; > > > > > > > > > > Fixed that, and then I ran it the same way before. In the serial > > console, tell BootROM to set the boot device to UART, and then exit, > > run kwboot. > > > > <BEGIN log> > > > > Bootstrap 2.33>x 0x0E > > > > Terminating... > > Thanks for using picocom > > > > ./kwboot-2022/kwboot.dove -t -p -B 115200 /dev/ttyUSB0 -D ./t5335z/mtd0.t5335z > > kwboot version 2022.04-rc1-00360-g162c22bfbc-dirty > > Patching image boot signature to UART > > Sending boot image header (3072 bytes)... > > 4 % [........................ ] > > Done > > Sending boot image data (605104 bytes)... > > 0 % [......................................................................] > > <snip> > > 97 % [......................................................................] > > 99 % [...................................... ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > <END log> > > > > It hung here. And I have to recycle power to boot again. > > > > Observation: in the previous run with unpatched kwboot, the header > > size was 512 bytes, and the image was 607664 bytes. So this time > > kwboot sends the extension header, too. Not sure if 3072 bytes is > > correct. > > If I parsed that image (file mtd0.t5335z) correctly it has: > * main header (0x20) > * ext header (0x1E0) > * 0x20 padding (0x20) > * ext header (0x1E0) > * bin header (0x800) > * image data (0x93bb0) > > So it is: 3072 bytes for headers + 605104 bytes for image data, which > now matches. > > Plus in main header is stored that image data starts at offset 0xc00 > which is 3072 bytes. > > Now kwboot showed just that is patching UART signature and no more > alignment, so it should send headers and data without adding any > additional padding or alignment. > > If it still does not work, I do not have an idea... > > It would be required to take U-Boot source code for that board and build > UART image from sources. Maybe UART version needs to be compiled > differently, like it was in past also for Armada builds.
To double check I dumped the images.
./kwboot-2022/dumpimage -T kwbimage -p -1 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.cfg -rw-r--r-- 1 root root 1155 Feb 13 15:58 mtd0.t5335z.cfg
This cfg file is incomplete as kwbimage does not read those new structures.
I got your other patch for kwbimage.c compiled in dumpimage. So the cfg seems OK.
No, it is not. There are completely missing information from struct ext_hdr_v0 and struct binext_hdr_v0.
Got it.
# cat /tmp/mtd0.t5335z.cfg
BOOT_FROM spi #SRC_ADDRESS 0xc00 #BLOCK_SIZE 0x93bb0 #DEST_ADDRESS 0x00600000 #EXEC_ADDRESS 0x00690000 DATA 0xd0020104 0x00000000 DATA 0xd0800020 0x00022530 DATA 0xd0800030 0x00022330 DATA 0xd0800050 0x911a00c3 DATA 0xd0800060 0x74780504 DATA 0xd0800190 0xc2005554 DATA 0xd08001c0 0x3694da09 DATA 0xd0800650 0x00130131 DATA 0xd0800660 0x84040200 DATA 0xd0800080 0x00000000 DATA 0xd0800090 0x00080000 DATA 0xd08000f0 0xc0000000 DATA 0xd08001a0 0x20c0c009 DATA 0xd0800280 0x010e0202 DATA 0xd0800760 0x00000201 DATA 0xd0800770 0x0100000a DATA 0xd0800140 0x20004044 DATA 0xd08001d0 0x177c2779 DATA 0xd08001e0 0x07700330 DATA 0xd08001f0 0x00000033 DATA 0xd0800200 0x0011311c DATA 0xd0800210 0x00300000 DATA 0xd0800240 0x80000000 DATA 0xd0800510 0x010e0101 DATA 0xd0800230 0x2028006a DATA 0xd0800e10 0x00280062 DATA 0xd0800e20 0x00280062 DATA 0xd0800e30 0x00280062 DATA 0xd0800100 0x000e0001 DATA 0xd0800110 0x000e0000 DATA 0xd0800120 0x00000001 DATA 0xd00d040c 0x00000008 DATA 0xd0010604 0x00004215 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0xd0020104 0x00000000 DATA 0x0 0x0 #RSVD2 0x100r
Plus see this incomplete RSVD2.
Indeed. This is the missing info that I've been looking for with other Kirkwood boards, too. I can't wait to see the patch :)
Now I sent it, it is there: https://patchwork.ozlabs.org/project/uboot/list/?series=286325&state=*
Thanks, Tony
There is also bin header for '-p 1' but again kwbimage cannot extract it yet.
(Btw, I have WIP patches for this stuff, if you are interesting I can send it)
Sure, if you want early testing while you're working on it, please send.
Ok, later I can prepare patches for you.
Thanks, Tony
./kwboot-2022/dumpimage -T kwbimage -p 0 ./t5335z/mtd0.t5335z -o /tmp/mtd0.t5335z.0.img -rw------- 1 root root 605100 Feb 13 15:58 mtd0.t5335z.0.img
./kwboot-2022/mkimage -l ./t5335z/mtd0.t5335z Image Type: MVEBU Boot from spi Image Image version:0 Data Size: 605100 Bytes = 590.92 KiB = 0.58 MiB Load Address: 00600000 Entry Point: 00690000
So it is checked out. The image is 605100 with 4 bytes checksum = 605104. Did I read it correctly? i.e. the dump does not include the checksum?
Yes!
Seems I got to get to work on that stock UART image!
Do you have some _vendor_ bootable UART image?
I ran into some problems compiling the GPL source. Still trying to figure it out.
Also look into Functional Specifications, chapter 5.7.1 Boot from UART. There is written: only one extended header is supported. But your SPI image have two extended headers and one binary header. So maybe you would have to strip one extended header...
Thanks for sending the kwbimage patch. I will test and report.
All the best, Tony
Hello!
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** With jumper inserted, serial console connected, start serial console
# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready
*** Hit <Enter> here to get to the prompt and execute "x 0x0E"
Bootstrap 2.33> Bootstrap 2.33>x 0x0E
*** No more input possible here, so Control-A-X to exit serial console
Terminating... Thanks for using picocom
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
I found this github repository https://github.com/rabeeh/u-boot with Dove version of U-Boot. In its README file is section about UART: https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L131-L138 It points to the file with "w" commands which needs to be executed in bootrom prior doing calling "x" command (which enters into x-modem): https://github.com/rabeeh/u-boot/blob/master/tools/doimage_dove/uart_init.tx...
Could you try to execute all those "w" commands in that other and then use kwboot if it helps?
Hi Pali,
Please see below.
On Tue, Feb 15, 2022 at 3:02 PM Pali Rohár pali@kernel.org wrote:
Hello!
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** With jumper inserted, serial console connected, start serial console
# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready
*** Hit <Enter> here to get to the prompt and execute "x 0x0E"
Bootstrap 2.33> Bootstrap 2.33>x 0x0E
*** No more input possible here, so Control-A-X to exit serial console
Terminating... Thanks for using picocom
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
I found this github repository https://github.com/rabeeh/u-boot with Dove version of U-Boot. In its README file is section about UART: https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L131-L138 It points to the file with "w" commands which needs to be executed in bootrom prior doing calling "x" command (which enters into x-modem): https://github.com/rabeeh/u-boot/blob/master/tools/doimage_dove/uart_init.tx...
Could you try to execute all those "w" commands in that other and then use kwboot if it helps?
Unfortunately, it did not help. I ran the same procedure. Connected the HP t5335z jumper to get to the BootROM debug prompt, and executed the "w" commands. And then "x e" to enter UART booting mode. And then execute kwboot. Here is the log.
<BEGIN log>
Bootstrap 2.33>w D00D0210 00000050
w D00D802C 01010000 w D00D802C 00010000 w d0800E40 00000100 w d0800E50 00120012 w d0800E40 00000101 w d0800E50 000d000d w d0800E40 00000102 w d0800E50 000a000a w d0800E40 00000103 w d0800E50 00080008 w d0800E40 00000200 w d0800E50 00120012 w d0800E40 00000201 w d0800E50 000d000d w d0800E40 00000202 w d0800E50 000a000a w d0800E40 00000203 w d0800E50 00080008
x e
Terminating... Thanks for using picocom
./kwboot-2022/kwboot -t -B 115200 /dev/ttyUSB0 -D mtd0.t5335z kwboot version 2022.04-rc2-00001-gab8903a24d-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................] 1 % [......................................................................] <snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
<END log>
Thanks, Tony
Hello! After longer time I have something new in this area.
On Wednesday 16 February 2022 20:18:31 Tony Dinh wrote:
Hi Pali,
Please see below.
On Tue, Feb 15, 2022 at 3:02 PM Pali Rohár pali@kernel.org wrote:
Hello!
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** With jumper inserted, serial console connected, start serial console
# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready
*** Hit <Enter> here to get to the prompt and execute "x 0x0E"
Bootstrap 2.33> Bootstrap 2.33>x 0x0E
*** No more input possible here, so Control-A-X to exit serial console
Terminating... Thanks for using picocom
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
I found this github repository https://github.com/rabeeh/u-boot with Dove version of U-Boot. In its README file is section about UART: https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L131-L138 It points to the file with "w" commands which needs to be executed in bootrom prior doing calling "x" command (which enters into x-modem): https://github.com/rabeeh/u-boot/blob/master/tools/doimage_dove/uart_init.tx...
Could you try to execute all those "w" commands in that other and then use kwboot if it helps?
Unfortunately, it did not help. I ran the same procedure. Connected the HP t5335z jumper to get to the BootROM debug prompt, and executed the "w" commands. And then "x e" to enter UART booting mode. And then execute kwboot. Here is the log.
<BEGIN log>
Bootstrap 2.33>w D00D0210 00000050
w D00D802C 01010000 w D00D802C 00010000 w d0800E40 00000100 w d0800E50 00120012 w d0800E40 00000101 w d0800E50 000d000d w d0800E40 00000102 w d0800E50 000a000a w d0800E40 00000103 w d0800E50 00080008 w d0800E40 00000200 w d0800E50 00120012 w d0800E40 00000201 w d0800E50 000d000d w d0800E40 00000202 w d0800E50 000a000a w d0800E40 00000203 w d0800E50 00080008
x e
Terminating... Thanks for using picocom
./kwboot-2022/kwboot -t -B 115200 /dev/ttyUSB0 -D mtd0.t5335z kwboot version 2022.04-rc2-00001-gab8903a24d-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................] 1 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
<END log>
Thanks, Tony
I looked at the mentioned rabeeh/u-boot repository again and there are two important bits of informations:
1) https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L136 README.MARVELL says that for UART booting should be used file named with _uart.
2) https://github.com/rabeeh/u-boot/blob/master/Makefile#L313 Build rules for _uart file and normal file are different. For example UART file has different doimage DDR input file (-R) and is _without_ doimage binary file (-B option). But it has _same_ main u-boot binary u-boot.bin
So I think that for converting Dove SPI image to UART image are more steps needed. And I think you could do it by first unpacking all kwbimage parts via u-boot's tools/dumpimage tool and then packing all required parts via Marvell doimage tool from that rabeeh/u-boot github repository.
Are you going to try it?
Hi Pali,
On Mon, Mar 20, 2023 at 1:33 PM Pali Rohár pali@kernel.org wrote:
Hello! After longer time I have something new in this area.
On Wednesday 16 February 2022 20:18:31 Tony Dinh wrote:
Hi Pali,
Please see below.
On Tue, Feb 15, 2022 at 3:02 PM Pali Rohár pali@kernel.org wrote:
Hello!
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** With jumper inserted, serial console connected, start serial console
# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready
*** Hit <Enter> here to get to the prompt and execute "x 0x0E"
Bootstrap 2.33> Bootstrap 2.33>x 0x0E
*** No more input possible here, so Control-A-X to exit serial console
Terminating... Thanks for using picocom
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
I found this github repository https://github.com/rabeeh/u-boot with Dove version of U-Boot. In its README file is section about UART: https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L131-L138 It points to the file with "w" commands which needs to be executed in bootrom prior doing calling "x" command (which enters into x-modem): https://github.com/rabeeh/u-boot/blob/master/tools/doimage_dove/uart_init.tx...
Could you try to execute all those "w" commands in that other and then use kwboot if it helps?
Unfortunately, it did not help. I ran the same procedure. Connected the HP t5335z jumper to get to the BootROM debug prompt, and executed the "w" commands. And then "x e" to enter UART booting mode. And then execute kwboot. Here is the log.
<BEGIN log>
Bootstrap 2.33>w D00D0210 00000050
w D00D802C 01010000 w D00D802C 00010000 w d0800E40 00000100 w d0800E50 00120012 w d0800E40 00000101 w d0800E50 000d000d w d0800E40 00000102 w d0800E50 000a000a w d0800E40 00000103 w d0800E50 00080008 w d0800E40 00000200 w d0800E50 00120012 w d0800E40 00000201 w d0800E50 000d000d w d0800E40 00000202 w d0800E50 000a000a w d0800E40 00000203 w d0800E50 00080008
x e
Terminating... Thanks for using picocom
./kwboot-2022/kwboot -t -B 115200 /dev/ttyUSB0 -D mtd0.t5335z kwboot version 2022.04-rc2-00001-gab8903a24d-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................] 1 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
<END log>
Thanks, Tony
I looked at the mentioned rabeeh/u-boot repository again and there are two important bits of informations:
https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L136 README.MARVELL says that for UART booting should be used file named with _uart.
https://github.com/rabeeh/u-boot/blob/master/Makefile#L313 Build rules for _uart file and normal file are different. For example UART file has different doimage DDR input file (-R) and is _without_ doimage binary file (-B option). But it has _same_ main u-boot binary u-boot.bin
So I think that for converting Dove SPI image to UART image are more steps needed. And I think you could do it by first unpacking all kwbimage parts via u-boot's tools/dumpimage tool and then packing all required parts via Marvell doimage tool from that rabeeh/u-boot github repository.
Are you going to try it?
Thanks for the info. It sounds promising.
I wanted to compile a UART version for stock HP T5335z u-boot to see if it will boot with kwboot. But I did not have time to revisit this topic and kind of forgot about it.
The GPL source README said the build requires an old Marvell toolchain. The old link is broken, and I could not find it at Marvell GitHub. Do you have any idea where I can find this specific toolchain arm-marvell-linux-gnueabi.tar.bz2 version 4.4.5 or newer?
Thanks, Tony
On Monday 20 March 2023 13:48:35 Tony Dinh wrote:
Hi Pali,
On Mon, Mar 20, 2023 at 1:33 PM Pali Rohár pali@kernel.org wrote:
Hello! After longer time I have something new in this area.
On Wednesday 16 February 2022 20:18:31 Tony Dinh wrote:
Hi Pali,
Please see below.
On Tue, Feb 15, 2022 at 3:02 PM Pali Rohár pali@kernel.org wrote:
Hello!
On Wednesday 22 December 2021 20:08:56 Tony Dinh wrote:
*** With jumper inserted, serial console connected, start serial console
# picocom --b 115200 --f n --p n --d 8 /dev/ttyUSB0 Terminal ready
*** Hit <Enter> here to get to the prompt and execute "x 0x0E"
Bootstrap 2.33> Bootstrap 2.33>x 0x0E
*** No more input possible here, so Control-A-X to exit serial console
Terminating... Thanks for using picocom
*** Run kwboot
# kwboot -t -p -B 115200 /dev/ttyUSB0 -D /localdisk/mtd0.t5335z Patching image boot signature to UART Aligning image header to Xmodem block size Waiting 2s and flushing tty Sending boot image header (512 bytes)... 25 % [.... ] Done Sending boot image data (607664 bytes)... 0 % [......................................................................] 1 % [......................................................................] 2 % [......................................................................]
<snip> 95 % [......................................................................] 97 % [......................................................................] 98 % [.......................................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
*** Hung here! BootROM did not execute the image payload.
I found this github repository https://github.com/rabeeh/u-boot with Dove version of U-Boot. In its README file is section about UART: https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L131-L138 It points to the file with "w" commands which needs to be executed in bootrom prior doing calling "x" command (which enters into x-modem): https://github.com/rabeeh/u-boot/blob/master/tools/doimage_dove/uart_init.tx...
Could you try to execute all those "w" commands in that other and then use kwboot if it helps?
Unfortunately, it did not help. I ran the same procedure. Connected the HP t5335z jumper to get to the BootROM debug prompt, and executed the "w" commands. And then "x e" to enter UART booting mode. And then execute kwboot. Here is the log.
<BEGIN log>
Bootstrap 2.33>w D00D0210 00000050
w D00D802C 01010000 w D00D802C 00010000 w d0800E40 00000100 w d0800E50 00120012 w d0800E40 00000101 w d0800E50 000d000d w d0800E40 00000102 w d0800E50 000a000a w d0800E40 00000103 w d0800E50 00080008 w d0800E40 00000200 w d0800E50 00120012 w d0800E40 00000201 w d0800E50 000d000d w d0800E40 00000202 w d0800E50 000a000a w d0800E40 00000203 w d0800E50 00080008
x e
Terminating... Thanks for using picocom
./kwboot-2022/kwboot -t -B 115200 /dev/ttyUSB0 -D mtd0.t5335z kwboot version 2022.04-rc2-00001-gab8903a24d-dirty Patching image boot signature to UART Sending boot image header (3072 bytes)... 4 % [........................ ] Done Sending boot image data (605104 bytes)... 0 % [......................................................................] 1 % [......................................................................]
<snip> 97 % [......................................................................] 99 % [...................................... ] Done Finishing transfer [Type Ctrl-\ + c to quit]
<END log>
Thanks, Tony
I looked at the mentioned rabeeh/u-boot repository again and there are two important bits of informations:
https://github.com/rabeeh/u-boot/blob/master/README.MARVELL#L136 README.MARVELL says that for UART booting should be used file named with _uart.
https://github.com/rabeeh/u-boot/blob/master/Makefile#L313 Build rules for _uart file and normal file are different. For example UART file has different doimage DDR input file (-R) and is _without_ doimage binary file (-B option). But it has _same_ main u-boot binary u-boot.bin
So I think that for converting Dove SPI image to UART image are more steps needed. And I think you could do it by first unpacking all kwbimage parts via u-boot's tools/dumpimage tool and then packing all required parts via Marvell doimage tool from that rabeeh/u-boot github repository.
Are you going to try it?
Thanks for the info. It sounds promising.
I wanted to compile a UART version for stock HP T5335z u-boot to see if it will boot with kwboot. But I did not have time to revisit this topic and kind of forgot about it.
The GPL source README said the build requires an old Marvell toolchain. The old link is broken, and I could not find it at Marvell GitHub. Do you have any idea where I can find this specific toolchain arm-marvell-linux-gnueabi.tar.bz2 version 4.4.5 or newer?
Thanks, Tony
No idea where is that old Marvell toolchain. But I think you do not have to use Marvell toolchain, I think that gcc-based for ARM should be fine. Possible problem may be that old U-Boot is not able to compile with modern gcc versions. So in case of issues, take gcc 4. For example download Live CD of some Ubuntu from year 2008 and compile old U-Boot in this old Ubuntu with its old gcc.
participants (3)
-
Marek Behún -
Pali Rohár -
Tony Dinh