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

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

[Pali Rohár]

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@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

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

[Tony Dinh]

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@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@70000
Hit any key to stop autoboot:  0

<End boot log>


On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár <pali@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@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
>

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

[Pali Rohár]

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>;

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@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@70000
> Hit any key to stop autoboot:  0
> 
> <End boot log>
> 
> 
> On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár <pali@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@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
> >

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

[Tony Dinh]

Hi Pali,

On Tue, Aug 2, 2022 at 3:00 PM Pali Rohár <pali@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?

#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@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@70000
> > Hit any key to stop autoboot:  0
> >
> > <End boot log>
> >
> >
> > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár <pali@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@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
> > >

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

[Pali Rohár]

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@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.

> #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@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@70000
> > > Hit any key to stop autoboot:  0
> > >
> > > <End boot log>
> > >
> > >
> > > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár <pali@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@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
> > > >

Re: [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@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@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@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@70000
> > > > Hit any key to stop autoboot:  0
> > > >
> > > > <End boot log>
> > > >
> > > >
> > > > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár <pali@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@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
> > > > >

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

[Tony Dinh]

Hi Pali,

Follow up on the topic of slow/fast SPL SPI loading.

common/spl/spl_spi.c
        /*
         * Load U-Boot image from SPI flash into RAM
         * In DM mode: defaults speed and mode will be
         * taken from DT when available
         */
        flash = spi_flash_probe(sf_bus, sf_cs,
                                CONFIG_SF_DEFAULT_SPEED,
                                CONFIG_SF_DEFAULT_MODE);
        if (!flash) {
                puts("SPI probe failed.\n");
                return -ENODEV;
        }

So that spi-max-frequency = <50000000> in the DTS is not used in the probe.

Thanks,
Tony

On Wed, Aug 3, 2022 at 11:06 PM Tony Dinh <mibodhi@gmail.com> wrote:
>
> Hi Pali,
>
> On Wed, Aug 3, 2022 at 3:24 AM Pali Rohár <pali@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@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@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@70000
> > > > > Hit any key to stop autoboot:  0
> > > > >
> > > > > <End boot log>
> > > > >
> > > > >
> > > > > On Tue, Aug 2, 2022 at 2:55 AM Pali Rohár <pali@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@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
> > > > > >

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

[Pali Rohár]

On Thursday 04 August 2022 16:06:30 Tony Dinh wrote:
> Hi Pali,
> 
> Follow up on the topic of slow/fast SPL SPI loading.
> 
> common/spl/spl_spi.c
>         /*
>          * Load U-Boot image from SPI flash into RAM
>          * In DM mode: defaults speed and mode will be
>          * taken from DT when available
>          */
>         flash = spi_flash_probe(sf_bus, sf_cs,
>                                 CONFIG_SF_DEFAULT_SPEED,
>                                 CONFIG_SF_DEFAULT_MODE);
>         if (!flash) {
>                 puts("SPI probe failed.\n");
>                 return -ENODEV;
>         }
> 
> So that spi-max-frequency = <50000000> in the DTS is not used in the probe.

Based on that comment, spi_flash_probe() function should read
spi-max-frequency from device tree when DM mode is enabled. And fallback
to CONFIG_SF_DEFAULT_SPEED value.

Probably there is a bug in DM spi_flash_probe() function
implementation...

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

[Stefan Roese]

On 02.08.22 11:55, Pali Rohár 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@kernel.org>

Reviewed-by: Stefan Roese <sr@denx.de>

Thanks,
Stefan

> ---
>   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)

Viele Grüße,
Stefan Roese

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de

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

[Stefan Roese]

On 02.08.22 11:55, Pali Rohár 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@kernel.org>

Applied to u-boot-marvell/master

Thanks,
Stefan

> ---
>   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)

Viele Grüße,
Stefan Roese

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de