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

[Tony Dinh]

On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh <mibodhi at gmail.com> wrote:
>
> Hi Pali,
>
> On Sun, Mar 5, 2023 at 3:55 AM 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.
> >
> > 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).
>
> It works great! Here the strapping is SPI 1 (0x34), and the boot mode
> is set to "Trying to boot from SPI" correctly.  I'm having a problem
> with SPL SPI probing the device. But I don't think it is not related
> to this boot mode patch. There is something in SPL SPI that either I
> don't understand or it is a bug.

I meant "But I don't think it is related to this boot mode patch".

Thanks,
Tony

>
> U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 -
> 13:52:31 -0800)
> High speed PHY - Version: 2.0
> Detected Device ID 6820
> board SerDes lanes topology details:
>  | Lane # | Speed |  Type       |
>  --------------------------------
>  |   0    |   0   | SGMII0 |
>  |   1    |   3   | SATA0 |
>  |   2    |   3   | SATA1 |
>  |   4    |   5   | USB3 HOST0 |
>  |   5    |   5   | USB3 HOST1 |
>  --------------------------------
> High speed PHY - Ended Successfully
> mv_ddr: 14.0.0
> DDR4 Training Sequence - Switching XBAR Window to FastPath Window
> mv_ddr: completed successfully
> SAR_REG=0xcb00934c boot_device=0x34
> Trying to boot from SPI
> spl_spi_load_image sf_bus = 0 sf_cs = 0
> spi_flash_probe spi_flash
> Invalid bus 0 (err=-19)
> SPI probe failed.
> Trying to boot from BOOTROM
> Returning to BootROM (return address 0xffff05c4)...
> BootROM: Image checksum verification PASSED
>
> Thanks,
> Tony
>
> > > >
> > > > 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
> > > >
> > > >