[PATCH RFC u-boot-mvebu 0/6] arm: mvebu: Fix boot mode detection

Pali Rohár pali at kernel.org
Tue Mar 7 21:55:05 CET 2023


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 <pali at 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 <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.
> >
> >
> > 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".

Yes, this is what I thought too.

> 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