[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection
Tony Dinh
mibodhi at gmail.com
Tue Mar 7 05:15:07 CET 2023
Hi Pali,
On Mon, Mar 6, 2023 at 4:11 PM Pali Rohár <pali at 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 <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.
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.
Thanks,
Tony
>
> > 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