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