Hi Pali, Hi Martin,
On Sat, Feb 25, 2023 at 5:41 AM Pali Rohár pali@kernel.org wrote:
On Saturday 25 February 2023 11:47:07 Martin Rowe wrote:
While I haven't tested this patchset - I have tested SPI booting with v2022.01 after applying lots of patches. I found that the magic value reported by bootrom when booting from SPI will be 0x34 on clearfog. The current sources only handle 0x32, hence having or not having SPL_SPI will always lead to returning to the bootrom.
Please consider pulling in this patch: https://github.com/SolidRun/u-boot/commit/f4f8a69740a8415c05359e01e51650f445... I can send it separately if you like.
Tested with the patch on a Clearfog Base: ================== Without SPL_SPI same return to BootROM ... mv_ddr: completed successfully Trying to boot from BOOTROM Returning to BootROM (return address 0xffff05c4)... BootROM: Image checksum verification PASSED
U-Boot 2023.04-rc2... ================== With SPL_SPI loads directly from SPI ... mv_ddr: completed successfully Trying to boot from SPI
U-Boot 2023.04-rc2...
I'm not sure how to run proper timing tests on the process, but stopwatch timing just between seeing "Trying to boot" and "U-Boot 2023.04-rc2" showed the return to BootROM under 1 second, and the direct from SPI around 4 seconds. I thought the goal of loading from SPI directly was speed, but returning to BootROM is significantly faster on this board.
You should check SPI speed in DTS file and also in the defconfig.
I think we have probably seen this slowdown before. There is a TODO in the way the DTS nodes are parsed by DM uclass. So this config must be set in defconfig to get around that bug: CONFIG_SF_DEFAULT_SPEED=50000000
All the best, Tony
which I have tested by adding these config options:
I tested the new spi_defconfig with and without SPL_SPI; no other changes