Hi Pali, On Mon, Mar 6, 2023 at 11:56 PM Pali Rohár <p...@kernel.org> 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 <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_.
Indeed that environment probe did not work. I meant the part that is working is: in u-boot the spi1 was initialized by DM SPI and assigned the index 0, as shown in dm tree. And then we can do "sf probe 0:0". 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 > > > > > > > > > > > > > > > > > > > > > >