* kwboot: Marvell Dove UART booting
@ 2021-12-23 4:08 Tony Dinh
2021-12-26 21:41 ` Tony Dinh
` (3 more replies)
0 siblings, 4 replies; 30+ messages in thread
From: Tony Dinh @ 2021-12-23 4:08 UTC (permalink / raw)
To: Pali Rohár, Marek Behún, U-Boot Mailing List
Cc: Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2021-12-23 4:08 kwboot: Marvell Dove UART booting Tony Dinh
@ 2021-12-26 21:41 ` Tony Dinh
2022-01-01 21:53 ` Pali Rohár
2022-02-13 16:10 ` Pali Rohár
` (2 subsequent siblings)
3 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2021-12-26 21:41 UTC (permalink / raw)
To: Pali Rohár, Marek Behún, U-Boot Mailing List
Cc: Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2021-12-26 21:41 ` Tony Dinh
@ 2022-01-01 21:53 ` Pali Rohár
2022-01-01 22:54 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-01-01 21:53 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-01-01 21:53 ` Pali Rohár
@ 2022-01-01 22:54 ` Tony Dinh
2022-01-01 23:12 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-01-01 22:54 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-01-01 22:54 ` Tony Dinh
@ 2022-01-01 23:12 ` Pali Rohár
2022-01-02 0:00 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-01-01 23:12 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-01-01 23:12 ` Pali Rohár
@ 2022-01-02 0:00 ` Tony Dinh
2022-01-02 0:28 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-01-02 0:00 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-01-02 0:00 ` Tony Dinh
@ 2022-01-02 0:28 ` Pali Rohár
0 siblings, 0 replies; 30+ messages in thread
From: Pali Rohár @ 2022-01-02 0:28 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2021-12-23 4:08 kwboot: Marvell Dove UART booting Tony Dinh
2021-12-26 21:41 ` Tony Dinh
@ 2022-02-13 16:10 ` Pali Rohár
2022-02-13 16:16 ` Pali Rohár
2022-02-15 23:02 ` Pali Rohár
3 siblings, 0 replies; 30+ messages in thread
From: Pali Rohár @ 2022-02-13 16:10 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2021-12-23 4:08 kwboot: Marvell Dove UART booting Tony Dinh
2021-12-26 21:41 ` Tony Dinh
2022-02-13 16:10 ` Pali Rohár
@ 2022-02-13 16:16 ` Pali Rohár
2022-02-13 19:41 ` Pali Rohár
2022-02-13 22:45 ` Tony Dinh
2022-02-15 23:02 ` Pali Rohár
3 siblings, 2 replies; 30+ messages in thread
From: Pali Rohár @ 2022-02-13 16:16 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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.
^ permalink raw reply related [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 16:16 ` Pali Rohár
@ 2022-02-13 19:41 ` Pali Rohár
2022-02-13 21:15 ` Marek Behún
2022-02-13 22:45 ` Tony Dinh
1 sibling, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-13 19:41 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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.
> + */
> 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) +
^^^^^^^^^^^^^^^^^
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);
> } 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 19:41 ` Pali Rohár
@ 2022-02-13 21:15 ` Marek Behún
2022-02-13 21:23 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Marek Behún @ 2022-02-13 21:15 UTC (permalink / raw)
To: Pali Rohár; +Cc: Tony Dinh, U-Boot Mailing List, Stefan Roese, Tom Rini
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.
> > + */
> > 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) +
>
> ^^^^^^^^^^^^^^^^^
> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 21:15 ` Marek Behún
@ 2022-02-13 21:23 ` Pali Rohár
2022-02-13 21:33 ` Marek Behún
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-13 21:23 UTC (permalink / raw)
To: Marek Behún; +Cc: Tony Dinh, U-Boot Mailing List, Stefan Roese, Tom Rini
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.
> > > + */
> > > 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) +
> >
> > ^^^^^^^^^^^^^^^^^
> > 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 21:23 ` Pali Rohár
@ 2022-02-13 21:33 ` Marek Behún
2022-02-13 21:55 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Marek Behún @ 2022-02-13 21:33 UTC (permalink / raw)
To: Pali Rohár; +Cc: Tony Dinh, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 21:33 ` Marek Behún
@ 2022-02-13 21:55 ` Tony Dinh
0 siblings, 0 replies; 30+ messages in thread
From: Tony Dinh @ 2022-02-13 21:55 UTC (permalink / raw)
To: Marek Behún
Cc: Pali Rohár, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 16:16 ` Pali Rohár
2022-02-13 19:41 ` Pali Rohár
@ 2022-02-13 22:45 ` Tony Dinh
2022-02-13 22:48 ` Pali Rohár
1 sibling, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-02-13 22:45 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 22:45 ` Tony Dinh
@ 2022-02-13 22:48 ` Pali Rohár
2022-02-13 23:24 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-13 22:48 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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;
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 22:48 ` Pali Rohár
@ 2022-02-13 23:24 ` Tony Dinh
2022-02-13 23:42 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-02-13 23:24 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 23:24 ` Tony Dinh
@ 2022-02-13 23:42 ` Pali Rohár
2022-02-14 0:08 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-13 23:42 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-13 23:42 ` Pali Rohár
@ 2022-02-14 0:08 ` Tony Dinh
2022-02-14 0:21 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-02-14 0:08 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-14 0:08 ` Tony Dinh
@ 2022-02-14 0:21 ` Pali Rohár
2022-02-14 1:10 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-14 0:21 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-14 0:21 ` Pali Rohár
@ 2022-02-14 1:10 ` Tony Dinh
2022-02-14 9:58 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-02-14 1:10 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-14 1:10 ` Tony Dinh
@ 2022-02-14 9:58 ` Pali Rohár
2022-02-14 22:00 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-14 9:58 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-14 9:58 ` Pali Rohár
@ 2022-02-14 22:00 ` Tony Dinh
2022-02-15 19:11 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-02-14 22:00 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-14 22:00 ` Tony Dinh
@ 2022-02-15 19:11 ` Pali Rohár
2022-02-15 22:11 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-15 19:11 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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...
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-15 19:11 ` Pali Rohár
@ 2022-02-15 22:11 ` Tony Dinh
0 siblings, 0 replies; 30+ messages in thread
From: Tony Dinh @ 2022-02-15 22:11 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2021-12-23 4:08 kwboot: Marvell Dove UART booting Tony Dinh
` (2 preceding siblings ...)
2022-02-13 16:16 ` Pali Rohár
@ 2022-02-15 23:02 ` Pali Rohár
2022-02-17 4:18 ` Tony Dinh
3 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2022-02-15 23:02 UTC (permalink / raw)
To: Tony Dinh; +Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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.txt
Could you try to execute all those "w" commands in that other and then
use kwboot if it helps?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-15 23:02 ` Pali Rohár
@ 2022-02-17 4:18 ` Tony Dinh
2023-03-20 20:33 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2022-02-17 4:18 UTC (permalink / raw)
To: Pali Rohár
Cc: Marek Behún, U-Boot Mailing List, Stefan Roese, Tom Rini
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.txt
>
> 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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2022-02-17 4:18 ` Tony Dinh
@ 2023-03-20 20:33 ` Pali Rohár
2023-03-20 20:48 ` Tony Dinh
0 siblings, 1 reply; 30+ messages in thread
From: Pali Rohár @ 2023-03-20 20:33 UTC (permalink / raw)
To: Tony Dinh; +Cc: U-Boot Mailing List
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.txt
> >
> > 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?
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2023-03-20 20:33 ` Pali Rohár
@ 2023-03-20 20:48 ` Tony Dinh
2023-03-20 21:06 ` Pali Rohár
0 siblings, 1 reply; 30+ messages in thread
From: Tony Dinh @ 2023-03-20 20:48 UTC (permalink / raw)
To: Pali Rohár; +Cc: U-Boot Mailing List
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.txt
> > >
> > > 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?
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: kwboot: Marvell Dove UART booting
2023-03-20 20:48 ` Tony Dinh
@ 2023-03-20 21:06 ` Pali Rohár
0 siblings, 0 replies; 30+ messages in thread
From: Pali Rohár @ 2023-03-20 21:06 UTC (permalink / raw)
To: Tony Dinh; +Cc: U-Boot Mailing List
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.txt
> > > >
> > > > 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?
>
> 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.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2023-03-20 21:06 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-23 4:08 kwboot: Marvell Dove UART booting Tony Dinh
2021-12-26 21:41 ` Tony Dinh
2022-01-01 21:53 ` Pali Rohár
2022-01-01 22:54 ` Tony Dinh
2022-01-01 23:12 ` Pali Rohár
2022-01-02 0:00 ` Tony Dinh
2022-01-02 0:28 ` Pali Rohár
2022-02-13 16:10 ` Pali Rohár
2022-02-13 16:16 ` Pali Rohár
2022-02-13 19:41 ` Pali Rohár
2022-02-13 21:15 ` Marek Behún
2022-02-13 21:23 ` Pali Rohár
2022-02-13 21:33 ` Marek Behún
2022-02-13 21:55 ` Tony Dinh
2022-02-13 22:45 ` Tony Dinh
2022-02-13 22:48 ` Pali Rohár
2022-02-13 23:24 ` Tony Dinh
2022-02-13 23:42 ` Pali Rohár
2022-02-14 0:08 ` Tony Dinh
2022-02-14 0:21 ` Pali Rohár
2022-02-14 1:10 ` Tony Dinh
2022-02-14 9:58 ` Pali Rohár
2022-02-14 22:00 ` Tony Dinh
2022-02-15 19:11 ` Pali Rohár
2022-02-15 22:11 ` Tony Dinh
2022-02-15 23:02 ` Pali Rohár
2022-02-17 4:18 ` Tony Dinh
2023-03-20 20:33 ` Pali Rohár
2023-03-20 20:48 ` Tony Dinh
2023-03-20 21:06 ` Pali Rohár
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.