[PATCH] arm: mvebu: spl: Always fallback to BootROM boot method
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)
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
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
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
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
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
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
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...
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
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
participants (3)
-
Pali Rohár -
Stefan Roese -
Tony Dinh