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"
Thanks,
Michal
--
Mike Looijmans
System Expert
TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands
T: +31 (0) 499 33 69 69
E: [email protected]
W: www.topic.nl
