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

Sun Mar 19 17:47:57 CET 2023

On Sunday 19 March 2023 03:30:33 Martin Rowe wrote:
> On Sun, 5 Mar 2023 at 11:55, Pali Rohár <pali at 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 at 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.

> >
> > > > 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
> > > >
> > > >
> >