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

2022-08-09 Thread 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 


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: s...@denx.de


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

2022-08-05 Thread 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 = <5000> 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

2022-08-04 Thread 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 = <5000> in the DTS is not used in the probe.

Thanks,
Tony

On Wed, Aug 3, 2022 at 11:06 PM Tony Dinh  wrote:
>
> Hi Pali,
>
> On Wed, Aug 3, 2022 at 3:24 AM Pali Rohár  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  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=4000. Also check value of
> > > > DT property spi-max-frequency. We have: spi-max-frequency = <4000>;
> > >
> > > It seems the spi-max-frequency = <5000> 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=5000
> CONFIG_SF_DEFAULT_SPEED=5000
> (and spi-max-frequency = <5000> 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=100
> > >
> > > #grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
> > > spi-max-frequency = <5000>;
> > >
> > > 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 
> > > > >
> > > > > Thanks,
> > > > > Tony
> > > > >
> > > > > 
> > > > >
> > > > > 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 0x05c4)...
> > > > > 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@7
> > > > > Hit any key to stop autoboot:  0
> > > > >
> > > > > 
> > > > >
> > > > >
> > > > > On Tue, Aug 2, 2022 at 2:55 AM 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 

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

2022-08-04 Thread Tony Dinh
Hi Pali,

On Wed, Aug 3, 2022 at 3:24 AM Pali Rohár  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  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=4000. Also check value of
> > > DT property spi-max-frequency. We have: spi-max-frequency = <4000>;
> >
> > It seems the spi-max-frequency = <5000> 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=5000
CONFIG_SF_DEFAULT_SPEED=5000
(and spi-max-frequency = <5000> 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=100
> >
> > #grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
> > spi-max-frequency = <5000>;
> >
> > 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 
> > > >
> > > > Thanks,
> > > > Tony
> > > >
> > > > 
> > > >
> > > > 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 0x05c4)...
> > > > 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@7
> > > > Hit any key to stop autoboot:  0
> > > >
> > > > 
> > > >
> > > >
> > > > On Tue, Aug 2, 2022 at 2:55 AM 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 
> > > > > ---
> > > > >  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
> > > > >
> > > > 

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

2022-08-03 Thread 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  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=4000. Also check value of
> > DT property spi-max-frequency. We have: spi-max-frequency = <4000>;
> 
> It seems the spi-max-frequency = <5000> 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=100
> 
> #grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
> spi-max-frequency = <5000>;
> 
> 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 
> > >
> > > Thanks,
> > > Tony
> > >
> > > 
> > >
> > > 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 0x05c4)...
> > > 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@7
> > > Hit any key to stop autoboot:  0
> > >
> > > 
> > >
> > >
> > > On Tue, Aug 2, 2022 at 2:55 AM 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 
> > > > ---
> > > >  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

2022-08-03 Thread 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 


Reviewed-by: Stefan Roese 

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: s...@denx.de


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

2022-08-02 Thread Tony Dinh
Hi Pali,

On Tue, Aug 2, 2022 at 3:00 PM Pali Rohár  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=4000. Also check value of
> DT property spi-max-frequency. We have: spi-max-frequency = <4000>;

It seems the spi-max-frequency = <5000> in the DTS took precedence here?

#grep CONFIG_SF_DEFAULT_SPEED .config
CONFIG_SF_DEFAULT_SPEED=100

#grep spi-max-frequency arch/arm/dts/armada-385-synology-ds116.dts
spi-max-frequency = <5000>;

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 
> >
> > Thanks,
> > Tony
> >
> > 
> >
> > 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 0x05c4)...
> > 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@7
> > Hit any key to stop autoboot:  0
> >
> > 
> >
> >
> > On Tue, Aug 2, 2022 at 2:55 AM 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 
> > > ---
> > >  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

2022-08-02 Thread 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=4000. Also check value of
DT property spi-max-frequency. We have: spi-max-frequency = <4000>;

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 
> 
> Thanks,
> Tony
> 
> 
> 
> 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 0x05c4)...
> 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@7
> Hit any key to stop autoboot:  0
> 
> 
> 
> 
> On Tue, Aug 2, 2022 at 2:55 AM 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 
> > ---
> >  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

2022-08-02 Thread 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 

Thanks,
Tony



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




On Tue, Aug 2, 2022 at 2:55 AM 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 
> ---
>  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
>