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 <p...@kernel.org> 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 <mibo...@gmail.com> wrote: > > > > > > > > Hi Pali, > > > > > > > > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár <p...@kernel.org> wrote: > > > > > > > > > > On Sunday 05 March 2023 14:46:55 Tony Dinh wrote: > > > > > > On Sun, Mar 5, 2023 at 2:44 PM Tony Dinh <mibo...@gmail.com> wrote: > > > > > > > > > > > > > > Hi Pali, > > > > > > > > > > > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár <p...@kernel.org> wrote: > > > > > > > > > > > > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote: > > > > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <p...@kernel.org> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Improve code for checking strapping pins which specifies > > > > > > > > > > boot mode source. > > > > > > > > > > > > > > > > > > > > Martin, could you test if Clearfog can be still configured > > > > > > > > > > into UART > > > > > > > > > > booting mode via HW switches and if it still works > > > > > > > > > > correctly? First > > > > > > > > > > patch is reverting UART related commit for Clearfog which I > > > > > > > > > > think it not > > > > > > > > > > needed anymore. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before > > > > > > > > > the switch that > > > > > > > > > you refactored in cpu.c/get_boot_device is all that gets > > > > > > > > > processed. It > > > > > > > > > decides there is an error and returns BOOT_DEVICE_UART, > > > > > > > > > probably because of > > > > > > > > > the invalid boot workaround for broken UART selection that > > > > > > > > > you identified. > > > > > > > > > > > > > > > > Ok, so I figured out correctly how this invalid mode works. > > > > > > > > > > > > > > > > > UART only works if I use the clearfog_spi_defconfig or if I > > > > > > > > > select > > > > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with > > > > > > > > > the MMC or SATA > > > > > > > > > defconfigs. I get the same result without this patch series > > > > > > > > > applied, though. > > > > > > > > > > > > > > > > > > The failed cases have the same output (other than kwboot > > > > > > > > > header patching > > > > > > > > > output) until after sending boot image data is complete. The > > > > > > > > > output stops > > > > > > > > > after: > > > > > > > > > ================================ > > > > > > > > > 98 % > > > > > > > > > [................................................................. > > > > > > > > > ] > > > > > > > > > Done > > > > > > > > > Finishing transfer > > > > > > > > > [Type Ctrl-\ + c to quit] > > > > > > > > > ================================ > > > > > > > > > > > > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART > > > > > > > > just > > > > > > > > instruct mkimage what to put into kwbimage header. > > > > > > > > > > > > > > > > If I'm looking at the output correctly then SPL was booted, it > > > > > > > > correctly > > > > > > > > trained DDR RAM, returned back to bootrom, kwboot continued > > > > > > > > sending main > > > > > > > > u-boot and bootrom confirmed that transfer of both SPL and main > > > > > > > > u-boot > > > > > > > > is complete. But then there is no output from main u-boot. > > > > > > > > > > > > > > > > > It looks like an unrelated issue with kwboot.c, which I was > > > > > > > > > sure was > > > > > > > > > working after the last patches but I can no longer reproduce > > > > > > > > > a successful > > > > > > > > > boot. > > > > > > > > > > > > > > > > Can you check that you are using _both_ mkimage and kwboot from > > > > > > > > version > > > > > > > > with applying _all_ my patches recently sent to ML? Because > > > > > > > > both mkimage > > > > > > > > and kwboot have fixes for SATA and SDIO images. > > > > > > > > > > > > > > > > For me it looks like that either mkimage generated incorrect > > > > > > > > image size > > > > > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image > > > > > > > > size > > > > > > > > from kwbimage header and sent smaller image. > > > > > > > > > > > > > > > > > > > > > > > > > > > Also could you check if SATA booting is still working > > > > > > > > > > correctly? > > > > > > > > > > > > > > > > > > > > > > > > > > > > SATA works correctly. > > > > > > > > > > > > > > > > Perfect! > > > > > > > > > > > > > > > > > > > > > > > > > > > Tony, should address problems with SPI booting when it is > > > > > > > > > > configured to > > > > > > > > > > different configuration. In fourth commit I added all > > > > > > > > > > possible boot mode > > > > > > > > > > strapping pin configurations which are recognized by A385 > > > > > > > > > > bootrom (and > > > > > > > > > > not the only one described in the HW spec, which is > > > > > > > > > > incomplete). > > > > > > > > > > > > > > It works great! Here the strapping is SPI 1 (0x34), and the boot > > > > > > > mode > > > > > > > is set to "Trying to boot from SPI" correctly. I'm having a > > > > > > > problem > > > > > > > with SPL SPI probing the device. But I don't think it is not > > > > > > > related > > > > > > > to this boot mode patch. There is something in SPL SPI that > > > > > > > either I > > > > > > > don't understand or it is a bug. > > > > > > > > > > > > I meant "But I don't think it is related to this boot mode patch". > > > > > > > > > > 0x34 uses SPI controller 1. So maybe you need to adjust some config > > > > > options? In your log is usage of bus 0, so maybe this could be the > > > > > reason. > > > > > > > > Previously I did not use bus 1, and used the default bus 0 and it > > > > still works! so I've suspected there is some problem in SPL SPI (i.e. > > > > it works when it should not). But now default bus 0 no longer works. > > > > > > > > I am configuring bus 1, but I'm not yet successful. There are > > > > multiple places where bus 1 is needed to be specified. Also, might I > > > > also need -u-boot.dtsi to tag the spi1 as dm,pre-reloc ? > > > > > > I know it's no longer boot mode detection in my test. We knew that worked. > > > > > > But I can't seem to get that SPI 1 booting to work, and hope you can > > > see something in this log. The strapping pin is 0x34, but the SPI > > > probe on bus 1 always fails. The envs loading on SPI 1 also fails. But > > > the BootROM apparently *can* load the u-boot image from SPI. And after > > > u-boot start, the SPI bus is 0 (shown in dm tree, and in sf probe > > > command below). > > > > > > <BEGIN LOG> > > > BootROM - 1.73 > > > Booting from SPI flash > > > > > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - > > > 15:25:16 -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 = 1 sf_cs = 0 > > > spi_flash_probe spi_flash > > > Invalid bus 1 (err=-19) > > > SPI probe failed. > > > Trying to boot from BOOTROM > > > Returning to BootROM (return address 0xffff05c4)... > > > BootROM: Image checksum verification PASSED > > > > > > > > > U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 15:25:16 > > > -0800) > > > Thecus N2350 > > > > > > SoC: MV88F6820-A0 at 1066 MHz > > > DRAM: 1 GiB (533 MHz, 32-bit, ECC not enabled) > > > Core: 62 devices, 22 uclasses, devicetree: separate > > > MMC: > > > Loading Environment from SPIFlash... Invalid bus 1 (err=-19) > > > *** Warning - spi_flash_probe_bus_cs() failed, using default environment > > > > > > Model: Thecus N2350 > > > Net: > > > Warning: ethernet@70000 (eth0) using random MAC address - > > > fe:d5:7a:cc:a7:65 > > > eth0: ethernet@70000 > > > Hit any key to stop autoboot: 0 > > > N2350 > dm tree > > > Class Index Probed Driver Name > > > ----------------------------------------------------------- > > > root 0 [ + ] root_driver root_driver > > > simple_bus 0 [ + ] simple_bus |-- soc > > > simple_bus 1 [ + ] simple_bus | |-- internal-regs > > > i2c 0 [ ] i2c_mvtwsi | | |-- i2c@11000 > > > i2c 1 [ ] i2c_mvtwsi | | |-- i2c@11100 > > > serial 0 [ + ] ns16550_serial | | |-- serial@12000 > > > pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl@18000 > > > pinconfig 0 [ ] pinconfig | | | |-- > > > ge-rgmii-pins-0 > > > pinconfig 1 [ ] pinconfig | | | |-- > > > ge-rgmii-pins-1 > > > pinconfig 2 [ ] pinconfig | | | |-- i2c-pins-0 > > > pinconfig 3 [ ] pinconfig | | | |-- mdio-pins > > > pinconfig 4 [ ] pinconfig | | | |-- > > > ref-clk-pins-0 > > > pinconfig 5 [ ] pinconfig | | | |-- > > > ref-clk-pins-1 > > > pinconfig 6 [ ] pinconfig | | | |-- spi-pins-0 > > > pinconfig 7 [ ] pinconfig | | | |-- spi-pins-1 > > > pinconfig 8 [ ] pinconfig | | | |-- nand-pins > > > pinconfig 9 [ ] pinconfig | | | |-- nand-rb > > > pinconfig 10 [ ] pinconfig | | | |-- > > > uart-pins-0 > > > pinconfig 11 [ ] pinconfig | | | |-- > > > uart-pins-1 > > > pinconfig 12 [ ] pinconfig | | | |-- sdhci-pins > > > pinconfig 13 [ ] pinconfig | | | |-- > > > sata-pins-0 > > > pinconfig 14 [ ] pinconfig | | | |-- > > > sata-pins-1 > > > pinconfig 15 [ ] pinconfig | | | |-- > > > sata-pins-2 > > > pinconfig 16 [ ] pinconfig | | | |-- > > > sata-pins-3 > > > pinconfig 17 [ ] pinconfig | | | |-- > > > pmx-power-button > > > pinconfig 18 [ ] pinconfig | | | |-- > > > pmx-copy-button > > > pinconfig 19 [ ] pinconfig | | | |-- > > > pmx-reset-button > > > pinconfig 20 [ ] pinconfig | | | |-- > > > pmx-sata1-white-led > > > pinconfig 21 [ ] pinconfig | | | |-- > > > pmx-sata1-red-led > > > pinconfig 22 [ ] pinconfig | | | |-- > > > pmx-sata2-white-led > > > pinconfig 23 [ ] pinconfig | | | |-- > > > pmx-sata2-red-led > > > pinconfig 24 [ ] pinconfig | | | |-- > > > pmx-sys-white-led > > > pinconfig 25 [ ] pinconfig | | | |-- > > > pmx-sys-red-led > > > pinconfig 26 [ ] pinconfig | | | |-- pmx-buzzer > > > pinconfig 27 [ ] pinconfig | | | |-- > > > pmx-pwr-off > > > pinconfig 28 [ ] pinconfig | | | |-- > > > pmx-pwr-blue-led > > > pinconfig 29 [ ] pinconfig | | | |-- > > > pmx-pwr-red-led > > > pinconfig 30 [ ] pinconfig | | | |-- > > > pmx-usb-white-led > > > pinconfig 31 [ ] pinconfig | | | `-- > > > pmx-usb-red-led > > > gpio 0 [ ] gpio_mvebu | | |-- gpio@18100 > > > gpio 1 [ ] gpio_mvebu | | |-- gpio@18140 > > > reset 0 [ + ] mvebu-reset | | |-- > > > system-controller@18200 > > > timer 0 [ + ] orion_timer | | |-- timer@20300 > > > ethernet 0 [ + ] mvneta | | |-- ethernet@70000 > > > bootdev 0 [ ] eth_bootdev | | | `-- > > > ethernet@70000.bootdev > > > usb 0 [ ] ehci_mvebu | | |-- usb@58000 > > > mdio 0 [ ] mvmdio | | |-- mdio@72004 > > > rtc 0 [ ] rtc-armada38x | | |-- rtc@a3800 > > > ahci 0 [ ] ahci_mvebu | | |-- sata@a8000 > > > scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi > > > usb 1 [ ] xhci_mvebu | | |-- usb3@f0000 > > > usb 2 [ ] xhci_mvebu | | `-- usb3@f8000 > > > spi 0 [ ] mvebu_spi | |-- spi@10680 > > > spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash@0 > > > misc 0 [ ] pcie_mvebu_base | `-- pcie > > > pci 0 [ ] pcie_mvebu | |-- pcie0.0 > > > pci 1 [ ] pcie_mvebu | `-- pcie1.0 > > > simple_bus 2 [ ] simple_bus |-- regulators > > > bootstd 0 [ ] bootstd_drv `-- bootstd > > > bootmeth 0 [ ] bootmeth_distro |-- distro > > > bootmeth 1 [ ] bootmeth_efi |-- efi > > > bootmeth 2 [ ] bootmeth_pxe `-- pxe > > > N2350 > sf probe 0:0 > > > SF: Detected mx25l3205d with page size 256 Bytes, erase size 4 KiB, total > > > 4 MiB > > > N2350 > sf probe 1:0 > > > Invalid bus 1 (err=-19) > > > dev_get_uclass_priv: null device > > > Failed to initialize SPI flash at 1:0 (error -19) > > > <END LOG> > > > > > > So I think there is probably some problem in SPL SPI. > > > > Yes, it clearly proves that problem is only in SPL. And also it proves > > that you have to use bus 0. So for sure rebuild u-boot and spl with bus > > number 0. > > Yes, indeed. Now it's working again after I removed all bus 1 configs > and let all default to 0. > > <BEGIN LOG> > BootROM - 1.73 > Booting from SPI flash > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - > 17:18:47 -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 name=spi_flash busnum=0 cd=0 > > > U-Boot 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 06 2023 - 17:18:47 > -0800) > Thecus N2350 > <END LOG> > > So the one time that it did not work with bus=0 must have been a bad > test. Now onto tracing why the DM SPI probe works in u-boot, even with > bus=1.
Look at your output with bus=1 properly, it does _not_ work as expected: Loading Environment from SPIFlash... Invalid bus 1 (err=-19) *** Warning - spi_flash_probe_bus_cs() failed, using default environment bus 1 is _invalid_. > Thanks, > Tony > > > > > > Note that for > > > a38x, spi0 is @10600, and spi1 is spi@10680. So the dm tree listing, > > > spi 0 [ ] mvebu_spi | |-- spi@10680 > > > > > > index 0 is *not* bus 0, it is just the 1st device. > > > > Yea, it looks like that. > > > > > Meanwhile, the sf probe command is supposed to take bus:cs as > > > argument, but it is taking the first device too. My thinking is DM SPI > > > probably has never been tested with this scenario (spi1 is the only > > > active SPI controller in the board). > > > > Can you try to trace probe function in u-boot and in spl? I think this > > should be the key here, why in u-boot it works and in spl not. > > > > > Thanks, > > > Tony > > > > > > > > > > > > > > > > > > > > > U-Boot SPL 2023.04-rc2-tld-1-00090-g3652b7b399-dirty (Mar 05 2023 > > > > > > > - > > > > > > > 13:52:31 -0800) > > > > > > > High speed PHY - Version: 2.0 > > > > > > > Detected Device ID 6820 > > > > > > > board SerDes lanes topology details: > > > > > > > | Lane # | Speed | Type | > > > > > > > -------------------------------- > > > > > > > | 0 | 0 | SGMII0 | > > > > > > > | 1 | 3 | SATA0 | > > > > > > > | 2 | 3 | SATA1 | > > > > > > > | 4 | 5 | USB3 HOST0 | > > > > > > > | 5 | 5 | USB3 HOST1 | > > > > > > > -------------------------------- > > > > > > > High speed PHY - Ended Successfully > > > > > > > mv_ddr: 14.0.0 > > > > > > > DDR4 Training Sequence - Switching XBAR Window to FastPath Window > > > > > > > mv_ddr: completed successfully > > > > > > > SAR_REG=0xcb00934c boot_device=0x34 > > > > > > > Trying to boot from SPI > > > > > > > spl_spi_load_image sf_bus = 0 sf_cs = 0 > > > > > > > spi_flash_probe spi_flash > > > > > > > Invalid bus 0 (err=-19) > > > > > > > SPI probe failed. > > > > > > > Trying to boot from BOOTROM > > > > > > > Returning to BootROM (return address 0xffff05c4)... > > > > > > > BootROM: Image checksum verification PASSED > > > > > > > > > > > > > > Thanks, > > > > > > > Tony > > > > > > > > > > > > > > > > > > > > > > > > > > > Stefan, do you have some AXP board with SATA boot source? > > > > > > > > > > Because I'm > > > > > > > > > > adding it for completeness in the last sixth patch. > > > > > > > > > > > > > > > > > > > > Pali Rohár (6): > > > > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_UART_ALT 0x3f constant > > > > > > > > > > arm: mvebu: Remove A38x BOOT_FROM_SATA 0x22 constant > > > > > > > > > > arm: mvebu: Convert BOOT_FROM_* constants to function > > > > > > > > > > macros > > > > > > > > > > arm: mvebu: Define all options for A38x BOOT_FROM_* macros > > > > > > > > > > arm: mvebu: Define all BOOTROM_ERR_MODE_* macros > > > > > > > > > > arm: mvebu: Define all options for AXP BOOT_FROM_* macros > > > > > > > > > > > > > > > > > > > > arch/arm/mach-mvebu/cpu.c | 20 ++++++------- > > > > > > > > > > arch/arm/mach-mvebu/include/mach/soc.h | 41 > > > > > > > > > > ++++++++++++++++---------- > > > > > > > > > > 2 files changed, 35 insertions(+), 26 deletions(-) > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > 2.20.1 > > > > > > > > > > > > > > > > > > > >