Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

21 Mar 2023

On Mon, 20 Mar 2023 at 21:33, Pali Rohár pali@kernel.org wrote:
...
On Monday 20 March 2023 18:45:01 Pali Rohár wrote:
...
On Monday 20 March 2023 12:01:03 Martin Rowe wrote:
...
On Sun, 19 Mar 2023 at 18:20, Pali Rohár pali@kernel.org wrote:
...
On Sunday 19 March 2023 17:47:57 Pali Rohár wrote:
...
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
...
On Sun, 5 Mar 2023 at 11:55, Pali Rohár pali@kernel.org wrote:
> On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
> > On Sat, 4 Mar 2023 at 10:51, Pali Rohár pali@kernel.org
wrote:
...
...
...
...
...
> >
> > > Improve code for checking strapping pins which specifies
boot
...
...
...
mode
...
...
> source.
> > >
> > > Martin, could you test if Clearfog can be still configured
into
...
...
...
UART
...
...
> > > booting mode via HW switches and if it still works
correctly?
...
...
...
First
...
...
> > > patch is reverting UART related commit for Clearfog which I
think it
...
...
> not
> > > needed anymore.
> > >
> >
> > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before
the
...
...
...
switch
...
...
> that
> > you refactored in cpu.c/get_boot_device is all that gets
processed. It
...
...
> > decides there is an error and returns BOOT_DEVICE_UART,
probably
...
...
...
because
...
...
> of
> > the invalid boot workaround for broken UART selection that
you
...
...
...
...
...
> identified.
>
> Ok, so I figured out correctly how this invalid mode works.
>
> > UART only works if I use the clearfog_spi_defconfig or if I
select
...
...
...
...
...
> > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with
the MMC
...
...
...
or
...
...
> SATA
> > defconfigs. I get the same result without this patch series
applied,
...
...
> though.
> >
> > The failed cases have the same output (other than kwboot
header
...
...
...
patching
...
...
> > output) until after sending boot image data is complete. The
output stops
...
...
> > after:
> > ================================
> >  98 %
[.................................................................
...
...
> >   ]
> > Done
> > Finishing transfer
> > [Type Ctrl-\ + c to quit]
> > ================================
>
> This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART
just
...
...
...
...
...
> instruct mkimage what to put into kwbimage header.
>
> If I'm looking at the output correctly then SPL was booted, it
correctly
...
...
> trained DDR RAM, returned back to bootrom, kwboot continued
sending
...
...
...
main
...
...
> u-boot and bootrom confirmed that transfer of both SPL and main
u-boot
...
...
> is complete. But then there is no output from main u-boot.
>
> > It looks like an unrelated issue with kwboot.c, which I was
sure
...
...
...
was
...
...
> > working after the last patches but I can no longer reproduce
a
...
...
...
successful
...
...
> > boot.
>
> Can you check that you are using _both_ mkimage and kwboot from
version
...
...
> with applying _all_ my patches recently sent to ML? Because
both
...
...
...
mkimage
...
...
> and kwboot have fixes for SATA and SDIO images.
>
I tested using the latest next branch which has those changes in
it.
...
...
...
Steps:
...
...

Set UART boot mode on device
make clean
make clearfog_defconfig
make
./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0

For me it looks like that either mkimage generated incorrect
image size
...
...
...
...
...
> for SATA or SDIO image. Or kwboot incorrectly parsed that
image size
...
...
...
...
...
> from kwbimage header and sent smaller image.
>
<MMC output>
./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
kwboot version 2023.04-rc4-00339-gcefd0449d6
Detected kwbimage v1 with SDIO boot signature
Patching image boot signature to UART
Aligning image header to Xmodem block size
Sending boot message. Please reboot the target...\
Sending boot image header (113408 bytes)...
  0 %
[......................................................................]
...
...
...
...
...
<snip>
 94 % [..............................................
 ]
Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 12:57:31
+1000)
...
...
...
...
...
High speed PHY - Version: 2.0
EEPROM TLV detection failed: Using static config for Clearfog
Pro.
...
...
...
...
...
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane # | Speed |  Type       |

|   0    |   3   | SATA0 |
 |   1    |   0   | SGMII1 |
 |   2    |   5   | PCIe1 |
 |   3    |   5   | USB3 HOST1 |
 |   4    |   5   | PCIe2 |
 |   5    |   0   | SGMII2 |

High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474564 bytes)...
  0 %
[......................................................................]
...
...
...
...
...
<snip>
 98 %
[....................................................................
...
...
]
Done
Finishing transfer
[Type Ctrl-\ + c to quit]
</MMC output>
<MMC sizes>
du -b u-boot*
4996828 u-boot
474304 u-boot.bin
15155 u-boot.cfg
19496 u-boot.dtb
474304 u-boot-dtb.bin
474368 u-boot-dtb.img
474368 u-boot.img
1721 u-boot.lds
1069982 u-boot.map
454808 u-boot-nodtb.bin
1307712 u-boot.srec
198841 u-boot.sym
588288 u-boot-with-spl.kwb
</MMC sizes>
If I make menuconfig and set the boot mode to UART before making
I get:
...
...
...
...
...
<UART output>
./tools/kwboot -b u-boot-with-spl.kwb -t /dev/ttyUSB0
kwboot version 2023.04-rc4-00339-gcefd0449d6
Detected kwbimage v1 with UART boot signature
Aligning image header to Xmodem block size
Sending boot message. Please reboot the target...\
Sending boot image header (113408 bytes)...
  0 %
[......................................................................]
...
...
...
...
...
<snip>
 94 % [..............................................
 ]
Done
U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
...
...
...
...
...
High speed PHY - Version: 2.0
EEPROM TLV detection failed: Using static config for Clearfog
Pro.
...
...
...
...
...
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane # | Speed |  Type       |

|   0    |   3   | SATA0 |
 |   1    |   0   | SGMII1 |
 |   2    |   5   | PCIe1 |
 |   3    |   5   | USB3 HOST1 |
 |   4    |   5   | PCIe2 |
 |   5    |   0   | SGMII2 |

High speed PHY - Ended Successfully
mv_ddr: 14.0.0
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from BOOTROM
Returning to BootROM (return address 0xffff05c4)...
Sending boot image data (474404 bytes)...
  0 %
[......................................................................]
...
...
...
...
...
<snip>
 98 %
[...................................................................
...
...
]
Done
Finishing transfer
[Type Ctrl-\ + c to quit]
U-Boot 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48
+1000)
...
...
...
...
...
</UART output>
<UART sizes>
du -b u-boot*
4997204 u-boot
474400 u-boot.bin
15103 u-boot.cfg
19496 u-boot.dtb
474400 u-boot-dtb.bin
474464 u-boot-dtb.img
474464 u-boot.img
1721 u-boot.lds
1070068 u-boot.map
454904 u-boot-nodtb.bin
1307988 u-boot.srec
198886 u-boot.sym
587904 u-boot-with-spl.kwb
</UART sizes>
The difference is very small somewhere if that is the cause. Let
me
...
...
...
know if
...
...
there's other data I can get to help with this one.
Difference should be only in the kwbimage header plus some
aligning. It
...
...
...
...
just proves what I wrote before "mkimage generated incorrect image
size
...
...
...
...
for SDIO image. Or kwboot incorrectly parsed that image size
from kwbimage header and sent smaller image.".
I will try to find a bug in mkimage or kwboot tool. Or you can try
it
...
...
...
...
too. As mmc booting is working fine from mmc I have felling that
bug is
...
...
...
...
in kwboot code which parses mmc images.
Ok, I think I found 3 bugs, all are UART related (not mmc). Could
you try
...
...
...
these changes?
Dedicated UART still works, patching an MMC for UART with kwboot still
hangs after finishing transfer; no change.
Bah :-( So there is still another bug. I will look at the code again...
I do not see anything wrong there :-(
Could you try to normally build mmc image and then run following
commands to manually generate uart image u-boot-with-spl.uart.kwb?
sed 's/^BOOT_FROM.*/BOOT_FROM uart/' ./arch/arm/mach-mvebu/kwbimage.cfg
...
kwbimage.uart.cfg
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e
0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
I would like to know if this UART image is bootable or not.
It is bootable. Here is the output from the normal mkimage:
./tools/mkimage -n ./arch/arm/mach-mvebu/kwbimage.cfg -T kwbimage -a
0x00800000 -e 0x00800000  -d u-boot.bin u-boot-with-spl.kwb
Image Type:   MVEBU Boot from sdio Image
Image version:1
BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB
BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB
Data Size:    475072 Bytes = 463.94 KiB = 0.45 MiB
Data Offset:  113664 Bytes = 111.00 KiB = 0.11 MiB
Load Address: 00800000
Entry Point:  00800000
Here is the output from your custom command:
./tools/mkimage -n kwbimage.uart.cfg -T kwbimage -a 0x00800000 -e
0x00800000 -d u-boot.bin u-boot-with-spl.uart.kwb
Image Type:   MVEBU Boot from uart Image
Image version:1
BIN Img Size: 113416 Bytes = 110.76 KiB = 0.11 MiB
BIN Img Offs: 48 Bytes = 0.05 KiB = 0.00 MiB
Data Size:    475072 Bytes = 463.94 KiB = 0.45 MiB
Data Offset:  113536 Bytes = 110.88 KiB = 0.11 MiB
Load Address: 00800000
Entry Point:  00800000
The difference is 128 bytes for the data offset. When I run kwboot I get:
Sending boot image data (475204 bytes)... [for the normal mkimage which
doesn't work]
Sending boot image data (475076 bytes)... [for the custom mkimage which
does work]
That 128 extra carries across. I'll poke around a bit more, but it seems
like a good lead so I wanted to share.
...
Also it would be interesting to enable CONFIG_DEBUG_UART_ANNOUNCE option
and check if you see early announce message on UART.
That's enabled for all the clearfog builds already.
...
...
Meanwhile could you do following tests?

The one which you done with patched kwboot and kwbimage, but send

output (sizes and aligning information from kwboot is useful there).

Use kwboot only for sending magic packet (-b without image) and then

use "sx" program for transferring kwb image over UART (instead of
kwboot). "sx" should work only with dedicated UART image type.
These commands would do it (replace ttyX by correct UART device)
$ ./tools/kwboot -b /dev/ttyX
  $ sh -c 'exec 0<>/dev/ttyX 1>&0; sx u-boot-with-spl.kwb'
...
...

diff --git a/tools/kwbimage.c b/tools/kwbimage.c
index 309657a5637b..177084adf825 100644
--- a/tools/kwbimage.c
+++ b/tools/kwbimage.c
@@ -1231,6 +1231,16 @@ static size_t image_headersz_v1(int *hasext)
        if (count > 0)
                headersz += sizeof(struct register_set_hdr_v1) + 8 *
count
...
...
...

4;

  /*


   * For all images except UART, headersz stored in header



itself
...
...
...
should

   * contains header size without padding. For UART image



BootROM
...
...
...
rounds

   * down headersz to multiply of 128 bytes. Therefore align



UART
...
...
...
headersz

   * to multiply of 128 bytes to ensure that remaining UART



header
...
...
...
bytes

   * are not ignored by BootROM.


   */


  if (image_get_bootfrom() == IBR_HDR_UART_ID)


          headersz = ALIGN(headersz, 128);


  return headersz;



}
diff --git a/tools/kwboot.c b/tools/kwboot.c
index 1844d7291fe0..b40800c108fc 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -2079,6 +2079,8 @@ kwboot_img_patch(void *img, size_t *size, int
baudrate)
                        goto err;
                }
                kwboot_img_grow_data_right(img, size,
sizeof(uint32_t));
...
...
...

          /* Update the 32-bit data checksum */


          *kwboot_img_csum32_ptr(img) = kwboot_img_csum32(img);
  }

  if (!kwboot_img_has_ddr_init(img) &&



@@ -2168,6 +2170,17 @@ kwboot_img_patch(void *img, size_t *size, int
baudrate)
            kwboot_printv("Aligning image header to Xmodem block

size\n");
                kwboot_img_grow_hdr(img, size, grow);


          /*


           * kwbimage v1 contains header size field and for



UART
...
...
...
type it

           * must be set to the aligned xmodem header size



because
...
...
...
BootROM

           * rounds header size down to xmodem block size.


           */


          if (kwbimage_version(img) == 1) {


                  hdrsz += grow;


                  hdr->headersz_msb = hdrsz >> 16;


                  hdr->headersz_lsb = cpu_to_le16(hdrsz &



0xffff);
...
...
...

          }
  }

  hdr->checksum = kwboot_hdr_csum8(hdr) - csum;





...
...
>
> > > Also could you check if SATA booting is still working
correctly?
...
...
...
...
...
> > >
> >
> > SATA works correctly.
>
> Perfect!
>
> >
> > > Tony, should address problems with SPI booting when it is
configured to
...
...
> > > different configuration. In fourth commit I added all
possible
...
...
...
boot
...
...
> mode
> > > strapping pin configurations which are recognized by A385
bootrom (and
...
...
> > > not the only one described in the HW spec, which is
incomplete).
...
...
...
...
...
> > >
> > > Stefan, do you have some AXP board with SATA boot source?
Because I'm
...
...
> > > adding it for completeness in the last sixth patch.
> > >
> > > Pali Rohár (6):
> > >   arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant
> > >   arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant
> > >   arm: mvebu: Convert BOOT_FROM_* constants to function
macros
...
...
...
...
...
> > >   arm: mvebu: Define all options for A38x BOOT_FROM_*
macros
...
...
...
...
...
> > >   arm: mvebu: Define all BOOTROM_ERR_MODE_* macros
> > >   arm: mvebu: Define all options for AXP BOOT_FROM_* macros
> > >
> > >  arch/arm/mach-mvebu/cpu.c              | 20 ++++++-------
> > >  arch/arm/mach-mvebu/include/mach/soc.h | 41
++++++++++++++++----------
...
...
> > >  2 files changed, 35 insertions(+), 26 deletions(-)
> > >
> > > --
> > > 2.20.1
> > >
> > >
>

    