[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Pali Rohár
pali at kernel.org
Tue Mar 7 01:11:14 CET 2023
On Monday 06 March 2023 16:01:58 Tony Dinh wrote:
> Hi Pali,
>
> On Sun, Mar 5, 2023 at 4:41 PM Tony Dinh <mibodhi at gmail.com> wrote:
> >
> > Hi Pali,
> >
> > On Sun, Mar 5, 2023 at 2:54 PM Pali Rohár <pali at 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 <mibodhi at gmail.com> wrote:
> > > > >
> > > > > Hi Pali,
> > > > >
> > > > > On Sun, Mar 5, 2023 at 3:55 AM Pali Rohár <pali at kernel.org> wrote:
> > > > > >
> > > > > > On Sunday 05 March 2023 04:21:42 Martin Rowe wrote:
> > > > > > > On Sat, 4 Mar 2023 at 10:51, Pali Rohár <pali at kernel.org> wrote:
> > > > > > >
> > > > > > > > Improve code for checking strapping pins which specifies boot mode source.
> > > > > > > >
> > > > > > > > Martin, could you test if Clearfog can be still configured into UART
> > > > > > > > booting mode via HW switches and if it still works correctly? First
> > > > > > > > patch is reverting UART related commit for Clearfog which I think it not
> > > > > > > > needed anymore.
> > > > > > > >
> > > > > > >
> > > > > > > On Clearfog the logic in the CONFIG_ARMADA_38X ifdef before the switch that
> > > > > > > you refactored in cpu.c/get_boot_device is all that gets processed. It
> > > > > > > decides there is an error and returns BOOT_DEVICE_UART, probably because of
> > > > > > > the invalid boot workaround for broken UART selection that you identified.
> > > > > >
> > > > > > Ok, so I figured out correctly how this invalid mode works.
> > > > > >
> > > > > > > UART only works if I use the clearfog_spi_defconfig or if I select
> > > > > > > CONFIG_MVEBU_SPL_BOOT_DEVICE_UART=y. It does not work with the MMC or SATA
> > > > > > > defconfigs. I get the same result without this patch series applied, though.
> > > > > > >
> > > > > > > The failed cases have the same output (other than kwboot header patching
> > > > > > > output) until after sending boot image data is complete. The output stops
> > > > > > > after:
> > > > > > > ================================
> > > > > > > 98 % [.................................................................
> > > > > > > ]
> > > > > > > Done
> > > > > > > Finishing transfer
> > > > > > > [Type Ctrl-\ + c to quit]
> > > > > > > ================================
> > > > > >
> > > > > > This is very strange because CONFIG_MVEBU_SPL_BOOT_DEVICE_UART just
> > > > > > instruct mkimage what to put into kwbimage header.
> > > > > >
> > > > > > If I'm looking at the output correctly then SPL was booted, it correctly
> > > > > > trained DDR RAM, returned back to bootrom, kwboot continued sending main
> > > > > > u-boot and bootrom confirmed that transfer of both SPL and main u-boot
> > > > > > is complete. But then there is no output from main u-boot.
> > > > > >
> > > > > > > It looks like an unrelated issue with kwboot.c, which I was sure was
> > > > > > > working after the last patches but I can no longer reproduce a successful
> > > > > > > boot.
> > > > > >
> > > > > > Can you check that you are using _both_ mkimage and kwboot from version
> > > > > > with applying _all_ my patches recently sent to ML? Because both mkimage
> > > > > > and kwboot have fixes for SATA and SDIO images.
> > > > > >
> > > > > > For me it looks like that either mkimage generated incorrect image size
> > > > > > for SATA or SDIO image. Or kwboot incorrectly parsed that image size
> > > > > > from kwbimage header and sent smaller image.
> > > > > >
> > > > > > >
> > > > > > > > Also could you check if SATA booting is still working correctly?
> > > > > > > >
> > > > > > >
> > > > > > > SATA works correctly.
> > > > > >
> > > > > > Perfect!
> > > > > >
> > > > > > >
> > > > > > > > Tony, should address problems with SPI booting when it is configured to
> > > > > > > > different configuration. In fourth commit I added all possible boot mode
> > > > > > > > strapping pin configurations which are recognized by A385 bootrom (and
> > > > > > > > not the only one described in the HW spec, which is incomplete).
> > > > >
> > > > > It works great! Here the strapping is SPI 1 (0x34), and the boot mode
> > > > > is set to "Trying to boot from SPI" correctly. I'm having a problem
> > > > > with SPL SPI probing the device. But I don't think it is not related
> > > > > to this boot mode patch. There is something in SPL SPI that either I
> > > > > don't understand or it is a bug.
> > > >
> > > > I meant "But I don't think it is related to this boot mode patch".
> > >
> > > 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 at 70000 (eth0) using random MAC address - fe:d5:7a:cc:a7:65
> eth0: ethernet at 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 at 11000
> i2c 1 [ ] i2c_mvtwsi | | |-- i2c at 11100
> serial 0 [ + ] ns16550_serial | | |-- serial at 12000
> pinctrl 0 [ ] armada-38x-pinctrl | | |-- pinctrl at 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 at 18100
> gpio 1 [ ] gpio_mvebu | | |-- gpio at 18140
> reset 0 [ + ] mvebu-reset | | |--
> system-controller at 18200
> timer 0 [ + ] orion_timer | | |-- timer at 20300
> ethernet 0 [ + ] mvneta | | |-- ethernet at 70000
> bootdev 0 [ ] eth_bootdev | | | `--
> ethernet at 70000.bootdev
> usb 0 [ ] ehci_mvebu | | |-- usb at 58000
> mdio 0 [ ] mvmdio | | |-- mdio at 72004
> rtc 0 [ ] rtc-armada38x | | |-- rtc at a3800
> ahci 0 [ ] ahci_mvebu | | |-- sata at a8000
> scsi 0 [ ] ahci_scsi | | | `-- ahci_scsi
> usb 1 [ ] xhci_mvebu | | |-- usb3 at f0000
> usb 2 [ ] xhci_mvebu | | `-- usb3 at f8000
> spi 0 [ ] mvebu_spi | |-- spi at 10680
> spi_flash 0 [ ] jedec_spi_nor | | `-- spi-flash at 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.
> Note that for
> a38x, spi0 is @10600, and spi1 is spi at 10680. So the dm tree listing,
> spi 0 [ ] mvebu_spi | |-- spi at 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
> > > > > > > >
> > > > > > > >
More information about the U-Boot
mailing list