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

[Pali Rohár]

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.

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.

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