On 9/11/26 13:39, Mike Looijmans wrote:
On 10-09-2026 15:03, Michal Simek wrote:
On 9/9/26 17:21, Mike Looijmans wrote:
On 07-09-2026 10:44, Michal Simek wrote:
Hi,
On 8/14/26 15:25, Mike Looijmans wrote:
Ever since this commit:
Commit 9bb02f7f4533 ("mtd: spi-nor: Fix the spi_nor_read() when config
SPI_STACKED_PARALLEL is enabled")
booting a 7-series Zynq using the SPL flow is broken, the board is unable
to read u-boot.img from QSPI flash using the updated routines in SPL. In
U-boot proper, reading QSPI flash works fine though.
U-Boot
When the Zynq boots from QSPI NOR flash, the ROM will have set up the
QSPI NOR chip in XIP mode, and the contents are now memory mapped (the
I would say linear mode.
first 16MB at least). All that needs to be done at this stage is to just
memcpy the u-boot code into DDR RAM. This is not only extremely simple,
it's also the fastest method to read QSPI flash on this platform.
This corresponds to a standard NOR boot.
To accomplish this, first make the SPI support optional instead of
mandatory for the ZYNQ platform. In the bootmode detection, select the
NOR bootmode instead of SPI when this config has been enabled. And
enable this by default for the ZYNQ.
To boot from QSPI NOR, the u-boot.img part must be placed after the
boot.bin (i.e. SPL). Set the CONFIG_SPL_PAD_TO configuration option to
the offset in QSPI flash. Usually this will be 0x20000 as the SPL code
easily fits in 128k.
With these changes, I was able to boot a Zynq from QSPI once more.
You should rephrase this to tested on HW etc.
Signed-off-by: Mike Looijmans <[email protected]>
---
arch/arm/Kconfig | 3 +--
arch/arm/mach-zynq/Kconfig | 6 ------
arch/arm/mach-zynq/spl.c | 8 +++++++-
include/configs/zynq-common.h | 2 ++
4 files changed, 10 insertions(+), 9 deletions(-)
When this is applied I see build failures on brcp1_1r_switch and similar.
Lexical error: arch/arm/dts/zynq-binman-brcp1.dtsi:23.14-40 Unexpected
'CONFIG_SYS_SPI_U_BOOT_OFFS'
FATAL ERROR: Syntax error parsing input tree
which also suggest change in defconfigs.
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 514bf2000b4..06c03dec552 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1346,8 +1346,7 @@ config ARCH_ZYNQ
select SPL_SOC_INIT if SPL
select SPL_CLK if SPL
select SPL_DM if SPL
- select SPL_DM_SPI if SPL
- select SPL_DM_SPI_FLASH if SPL
but you are dropping SPI support completely. I can't predict how big flashes
people have that's why don't think this is the right way to go. You can
change it to imply and then let board to decide which options to disable.
You are able to handle only image inside the first 16MB and that's something
what should be checked and handled.
This is only about the SPL part, and the only concern here is to fetch u-
boot.img (typically way less than 1MB) from the QSPI flash. It does require
that to reside in the first 16MB yes, but the profits are huge (going from
not booting at all to booting faster than before).
I am not saying that it is not a good thing but I don't think you can argue
that this is going to work on all existing setups. They can benefit from it
but your patch can also break them because this 16MB limitation wasn't
enforced from the beginning.
Once U-Boot proper is up and running, the QSPI drivers work as before and one
can use the full range of the QSPI flash.
no doubt about it.
The same method can be used on the MPSoC probably, but it's been a long time
since I ever got that to boot from SPL.
likely.
I'll polish up a v2 when I have the opportunity.
I pretty much thing that this is going in a way that this should be under
Kconfig. It means you can enable it if you want and validate on your HW. Which
obviously means that above selects for SPL_DM_SPI should changed to imply and
when your option is enabled they should be disabled and new one enabled.
Then people will have option to switch if they want after testing.
Actually the current patch should already implement that, as it doesn't disable
the SPI drivers, it just stops "enforcing" them. If you put SPL_DM_SPI_FLASH
into the defconfig for the boards that need it, that should make them revert to
the old SPI driver method.
With the Kconfig as it was, there was no way whatsoever to
disable SPL_DM_SPI_FLASH for any ZYNQ platform.
I've done some attempts to make the old way default for ZYNQ and select the mmap
method for 'my' boards, but so far failed to make that work.
Somehow SPL_DM_SPI_FLASH always made its way back into the config if I just
change "select" into "imply"
with imply you should be able to deselect it.
Thanks,
Michal
