[PATCH] arm: mvebu: spl: Always fallback to BootROM boot method

[Tony Dinh]

Hi Pali,

On Wed, Aug 3, 2022 at 3:24 AM Pali Rohár <pali at kernel.org> wrote:
>
> On Tuesday 02 August 2022 15:13:13 Tony Dinh wrote:
> > Hi Pali,
> >
> > On Tue, Aug 2, 2022 at 3:00 PM Pali Rohár <pali at kernel.org> wrote:
> > >
> > > Hello! We have tested that A385 BootROM on Turris Omnia board is much
> > > slower when reading proper U-Boot from SPI NOR than native SPL SPI
> > > driver.
> > >
> > > If you have different test results on A385, could you check SPI speed
> > > used by U-Boot? I think that CONFIG_SF_DEFAULT_SPEED should define it.
> > > For Omnia we use CONFIG_SF_DEFAULT_SPEED=40000000. Also check value of
> > > DT property spi-max-frequency. We have: spi-max-frequency = <40000000>;
> >
> > It seems the spi-max-frequency = <50000000> in the DTS took precedence here?
>
> I'm not sure. It is possible that config option has higher priority. Try
> to set both values to same speed.

That's exactly what has caused the SPL SPI driver to slow down. Once I
set the configurations for the default and the max to the same speed,
SPL SPI driver boots instantly (no observable delay).

CONFIG_ENV_SPI_MAX_HZ=50000000
CONFIG_SF_DEFAULT_SPEED=50000000
(and spi-max-frequency = <50000000> in the DTS)

It is noticeably faster than BootROM loading the u-boot image, which
takes an observable fraction of a second.

So somewhere in the SPL SPL driver, the logic needs some improvement.
Setting default speed and max speed to the same value apparently has
short-circuit that logic.

Thanks,
Tony





>
> > #grep CONFIG_SF_DEFAULT_SPEED .config
> > CONFIG_SF_DEFAULT_SPEED=1000000
> >
> > #grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
> > spi-max-frequency = <50000000>;
> >
> > Thanks,
> > Tony
> >
> >
> > > On Tuesday 02 August 2022 14:50:32 Tony Dinh wrote:
> > > > Hi Pali,
> > > >
> > > > It works great!
> > > >
> > > > An observation: BootROM boot method is a lot faster than SPL SPI
> > > > driver method on this Armada 385 board. The BootROM took a fraction of
> > > > a second to load the u-boot image. SPL SPI driver took a few seconds
> > > > to load. Perhaps the SPI flash speed vs some probing code in SPL SPI
> > > > driver? I also include the boot log after signature.
> > > >
> > > > Tested-by: Tony Dinh <mibodhi at gmail.com>
> > > >
> > > > Thanks,
> > > > Tony
> > > >
> > > > <Begin boot log>
> > > >
> > > > BootROM - 1.73
> > > > Booting from SPI flash
> > > >
> > > > U-Boot SPL 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 -0700)
> > > > High speed PHY - Version: 2.0
> > > > Detected Device ID 6820
> > > > board SerDes lanes topology details:
> > > >  | Lane # | Speed |  Type       |
> > > >  --------------------------------
> > > >  |   0    |   0   | SGMII0 |
> > > >  |   1    |   6   | SATA0 |
> > > >  |   4    |   5   | USB3 HOST0 |
> > > >  |   5    |   5   | USB3 HOST1 |
> > > >  --------------------------------
> > > > High speed PHY - Ended Successfully
> > > > mv_ddr: 14.0.0
> > > > DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> > > > mv_ddr: completed successfully
> > > > Trying to boot from SPI
> > > > Invalid bus 0 (err=-19)
> > > > SPI probe failed.
> > > > Trying to boot from BOOTROM
> > > > Returning to BootROM (return address 0xffff05c4)...
> > > > BootROM: Image checksum verification PASSED
> > > >
> > > >
> > > > U-Boot 2022.10-rc1-00212-g80e1491a03-dirty (Aug 02 2022 - 14:07:12 -0700)
> > > > Synology DS116
> > > >
> > > > SoC:   MV88F6820-A0 at 1866 MHz
> > > > DRAM:  1 GiB (933 MHz, 32-bit, ECC not enabled)
> > > > Core:  41 devices, 18 uclasses, devicetree: separate
> > > > MMC:
> > > > Loading Environment from SPIFlash... SF: Detected mx25l6405d with page
> > > > size 256 Bytes, erase size 4 KiB, total 8 MiB
> > > > OK
> > > > Model: Synology DS116
> > > > Board: Synology DS116
> > > > Net:   eth0: ethernet at 70000
> > > > Hit any key to stop autoboot:  0
> > > >
> > > > <End boot log>
> > > >
> > > >
> > > > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár <pali at kernel.org> wrote:
> > > > >
> > > > > BootROM boot method should always work so always add it as fallback method
> > > > > to spl_boot_list. In case U-Boot SPI driver fails it is better to try using
> > > > > BootROM than hanging as by default only one boot method is specified.
> > > > >
> > > > > Signed-off-by: Pali Rohár <pali at kernel.org>
> > > > > ---
> > > > >  arch/arm/mach-mvebu/spl.c | 7 +++++++
> > > > >  1 file changed, 7 insertions(+)
> > > > >
> > > > > diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> > > > > index 13c99913c380..bfcba2e73bab 100644
> > > > > --- a/arch/arm/mach-mvebu/spl.c
> > > > > +++ b/arch/arm/mach-mvebu/spl.c
> > > > > @@ -271,6 +271,13 @@ u32 spl_boot_device(void)
> > > > >         }
> > > > >  }
> > > > >
> > > > > +void board_boot_order(u32 *spl_boot_list)
> > > > > +{
> > > > > +       spl_boot_list[0] = spl_boot_device();
> > > > > +       if (spl_boot_list[0] != BOOT_DEVICE_BOOTROM)
> > > > > +               spl_boot_list[1] = BOOT_DEVICE_BOOTROM;
> > > > > +}
> > > > > +
> > > > >  #else
> > > > >
> > > > >  u32 spl_boot_device(void)
> > > > > --
> > > > > 2.20.1
> > > > >