Hi Pali, On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár <p...@kernel.org> wrote: > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh <mibo...@gmail.com> wrote: > > > > > > Hi Pali, > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár <p...@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 <p...@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". > > 0x34 uses SPI controller 1. So maybe you need to adjust some config > options? In your log is usage of bus 0, so maybe this could be the > reason.
Previously I did not use bus 1, and used the default bus 0 and it still works! so I've suspected there is some problem in SPL SPI (i.e. it works when it should not). But now default bus 0 no longer works. I am configuring bus 1, but I'm not yet successful. There are multiple places where bus 1 is needed to be specified. Also, might I also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ? 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 > > > > > > > > > > > >