Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sat, 25 Mar 2023 at 13:30, Pali Rohár wrote: > > On Saturday 04 March 2023 11:50:30 Pali Rohár 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. > > > > Also could you check if SATA booting is still working correctly? > > > > 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 > > > > Is something else needed to do with this patch series? > > Because the discussion in this patch thread just pointed to different > issues, not related this this patch series. Tested this patch with everything that just went into next, plus the switch fix, and all boot successfully: - MMC - eMMC - SD card - UART via kwboot - SATA (including UART via kwboot) - SPI (including UART via kwboot) - UART Tested-by: Martin Rowe
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sat, Mar 25, 2023 at 12:27 PM Tony Dinh wrote: > > Hi Pali, > > On Sat, Mar 25, 2023 at 6:30 AM Pali Rohár wrote: > > > > On Saturday 04 March 2023 11:50:30 Pali Rohár 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. > > > > > > Also could you check if SATA booting is still working correctly? > > > > > > 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 > > > > > > > Is something else needed to do with this patch series? > > > > Because the discussion in this patch thread just pointed to different > > issues, not related this this patch series. > > For my part I'm OK. The boot mode detection works properly when the > strapping pin is set to spi1. The issue comes after that. The spi0 > versus spi1 in SPL is a different issue that I will need to > investigate further. At the moment it falls back to BootROM, which is > also very fast booting anyway. > Tested-by: Tony Dinh Thanks, Tony
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Sat, Mar 25, 2023 at 6:30 AM Pali Rohár wrote: > > On Saturday 04 March 2023 11:50:30 Pali Rohár 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. > > > > Also could you check if SATA booting is still working correctly? > > > > 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 > > > > Is something else needed to do with this patch series? > > Because the discussion in this patch thread just pointed to different > issues, not related this this patch series. For my part I'm OK. The boot mode detection works properly when the strapping pin is set to spi1. The issue comes after that. The spi0 versus spi1 in SPL is a different issue that I will need to investigate further. At the moment it falls back to BootROM, which is also very fast booting anyway. Thanks, Tony
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Saturday 04 March 2023 11:50:30 Pali Rohár 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. > > Also could you check if SATA booting is still working correctly? > > 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 > Is something else needed to do with this patch series? Because the discussion in this patch thread just pointed to different issues, not related this this patch series.
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Thursday 23 March 2023 19:33:27 Pali Rohár wrote: > On Thursday 23 March 2023 11:01:22 Martin Rowe wrote: > > On Wed, 22 Mar 2023 at 18:09, Pali Rohár wrote: > > > > > > On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote: > > > > On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > > > > > > > > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 > > > > > > > > > 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 > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > > > > > > > > > > > > > > > > > > > > > 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Thursday 23 March 2023 11:01:22 Martin Rowe wrote: > On Wed, 22 Mar 2023 at 18:09, Pali Rohár wrote: > > > > On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote: > > > On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > > > > > > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 > > > > > > > > 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 > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > > > > > > > > > > > > > > > > > > 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 > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Wed, 22 Mar 2023 at 18:09, Pali Rohár wrote: > > On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote: > > On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > > > > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 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 > > > wrote: > > > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > > > 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 > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Wednesday 22 March 2023 11:14:42 Martin Rowe wrote: > On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 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 > > wrote: > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > 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. > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tue, 21 Mar 2023 at 17:26, Pali Rohár wrote: > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 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 > wrote: > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 20:56:02 Pali Rohár wrote: > On Tuesday 21 March 2023 18:25:56 Pali Rohár wrote: > > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 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 > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 18:25:56 Pali Rohár wrote: > On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 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 wrote: > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./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 > > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 08:34:24 Martin Rowe wrote: > On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 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 wrote: > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ./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 % > > > > > > > > > > > > > > [..] > > > > > > > > > > > > > > 94 %
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Mon, 20 Mar 2023 at 21:33, Pali Rohár 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 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 wrote: > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > 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. > > > > > > > > > > > > > > > > > > > > > > > > > ./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 % > > > > > > > > > > > [..] > > > > > > > > > > > > 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 > > > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 21 March 2023 08:03:45 Martin Rowe wrote: > On Mon, 20 Mar 2023 at 19:42, Pali Rohár wrote: > > > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > > Dedicated UART still works, patching an MMC for UART with kwboot still > > > hangs after finishing transfer; no change. > > > > One more question. Did you set boot mode HW switches to UART position? > > Or are they in MMC position and magic boot pattern from kwboot triggers > > UART boot? > > > > HW switches to UART position. Could you try also the second option. Put it into mmc position and use kwboot with magic pattern for booting? Just to ensure that if some HW reset occurs we will see boot log of mmc u-boot.
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Mon, 20 Mar 2023 at 19:42, Pali Rohár wrote: > On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > > Dedicated UART still works, patching an MMC for UART with kwboot still > > hangs after finishing transfer; no change. > > One more question. Did you set boot mode HW switches to UART position? > Or are they in MMC position and magic boot pattern from kwboot triggers > UART boot? > HW switches to UART position.
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
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 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 wrote: > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. > > > > > > > > > > > > > > > > > > > > > ./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 % > > > > > > > > [..] > > > > > > > > > > 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|
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > Dedicated UART still works, patching an MMC for UART with kwboot still > hangs after finishing transfer; no change. One more question. Did you set boot mode HW switches to UART position? Or are they in MMC position and magic boot pattern from kwboot triggers UART boot?
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Monday 20 March 2023 12:01:03 Martin Rowe wrote: > On Sun, 19 Mar 2023 at 18:20, Pali Rohár 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 wrote: > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. > > > > > > > > > > > > > > > > > ./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 % > > > > > > [..] > > > > > > > > 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 > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sun, 19 Mar 2023 at 18:20, Pali Rohár 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 wrote: > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. > > > > > > > > > > > > > ./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 % > > > > [..] > > > > > > 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 0x05c4)... > > > > > > Sending boot image data (474564 bytes)... > > > 0 % > > > > [..] > > > > > > 98 % > [ > > > ] > > > Done > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
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 wrote: > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. > > > > > > > > > ./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 % > > [..] > > > > 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 0x05c4)... > > > > Sending boot image data (474564 bytes)... > > 0 % > > [..] > > > > 98 % [ > > ] > > Done > > Finishing transfer > > [Type Ctrl-\ + c to quit] > > > > > > > > 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sunday 19 March 2023 03:30:33 Martin Rowe wrote: > On Sun, 5 Mar 2023 at 11:55, Pali Rohár wrote: > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. > > > > > ./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 % > [..] > > 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 0x05c4)... > > Sending boot image data (474564 bytes)... > 0 % > [..] > > 98 % [ > ] > Done > Finishing transfer > [Type Ctrl-\ + c to quit] > > > > 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 > > > If I make menuconfig and set the boot mode to UART before making I get: > > > ./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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sun, 5 Mar 2023 at 11:55, Pali Rohár wrote: > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. > ./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 % [..] 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 0x05c4)... Sending boot image data (474564 bytes)... 0 % [..] 98 % [ ] Done Finishing transfer [Type Ctrl-\ + c to quit] 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 If I make menuconfig and set the boot mode to UART before making I get: ./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 % [..] 94 % [.. ] Done U-Boot SPL 2023.04-rc4-00339-gcefd0449d6 (Mar 19 2023 - 13:20:48 +1000)
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Tuesday 07 March 2023 12:53:45 Tony Dinh wrote: > Hi Pali, > > On Mon, Mar 6, 2023 at 11:56 PM Pali Rohár wrote: > > > > On Monday 06 March 2023 20:15:07 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár wrote: > > > > > > > > On Monday 06 March 2023 16:01:58 Tony Dinh wrote: > > > > > Hi Pali, > > > > > > > > > > On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh wrote: > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > > > > > > > > > > > > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > > > > > > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > > > > > > 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? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Mon, Mar 6, 2023 at 11:56 PM Pali Rohár wrote: > > On Monday 06 March 2023 20:15:07 Tony Dinh wrote: > > Hi Pali, > > > > On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár wrote: > > > > > > On Monday 06 March 2023 16:01:58 Tony Dinh wrote: > > > > Hi Pali, > > > > > > > > On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > > > > > > > > > > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > > > > > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > > > > > 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Monday 06 March 2023 20:15:07 Tony Dinh wrote: > Hi Pali, > > On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár wrote: > > > > On Monday 06 March 2023 16:01:58 Tony Dinh wrote: > > > Hi Pali, > > > > > > On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh wrote: > > > > > > > > Hi Pali, > > > > > > > > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > > > > > > > > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > > > > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár > > > > > > > > > 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár wrote: > > On Monday 06 March 2023 16:01:58 Tony Dinh wrote: > > Hi Pali, > > > > On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > > > > > > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > > > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Monday 06 March 2023 16:01:58 Tony Dinh wrote: > Hi Pali, > > On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh wrote: > > > > Hi Pali, > > > > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > > > > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > > > > > > > Hi Pali, > > > > > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh wrote: > > Hi Pali, > > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > > > > > Hi Pali, > > > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On 3/4/23 11:50, Pali Rohár 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. Also could you check if SATA booting is still working correctly? 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. No, theadorable only boots from SPI NOR. Thanks, Stefan
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár wrote: > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > > > Hi Pali, > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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 | > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > > > Hi Pali, > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. > 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 0x05c4)... > > BootROM: Image checksum verification PASSED > > > > Thanks, > > Tony > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh wrote: > > Hi Pali, > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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 0x05c4)... > 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_*
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Hi Pali, On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár wrote: > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. 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 0x05c4)... 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 > > > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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 > > > >
Re: [PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
On Sat, 4 Mar 2023 at 10:51, Pali Rohár 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. 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] 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. > Also could you check if SATA booting is still working correctly? > SATA works correctly. > 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 > >
