[PATCH 00/11] mtd: spi-nor: Isolate stacked/parallel support from core
Begari, Padmarao
Padmarao.Begari at amd.com
Sun Apr 19 16:27:12 CEST 2026
[Public]
Hi Takahiro,
> From: Takahiro.Kuwano at infineon.com <Takahiro.Kuwano at infineon.com>
> Sent: Tuesday, April 14, 2026 10:21 AM
> To: Begari, Padmarao <Padmarao.Begari at amd.com>; u-boot at lists.denx.de;
> tudor.ambarus at linaro.org
> Cc: jagan at amarulasolutions.com; Simek, Michal <michal.simek at amd.com>;
> trini at konsulko.com; Erkiaga Elorza, Ibai <ibai.erkiaga-elorza at amd.com>;
> vigneshr at ti.com; Kummari, Prasad <Prasad.Kummari at amd.com>;
> marek.vasut+renesas at mailbox.org; Mutya, Havish <havish.mutya at amd.com>;
> ashok.reddy.soma at amd.com; venkatesh.abbarapu at amd.com;
> Bacem.Daassi at infineon.com; Shinsuke.Okada at infineon.com;
> Hiroyuki.Saito2 at infineon.com; Shivendra.Singh at infineon.com
> Subject: RE: [PATCH 00/11] mtd: spi-nor: Isolate stacked/parallel support from core
>
> Hi Padmarao and AMD team,
>
> Could you please help to narrow down the issues?
>
> I was acknowledged a bug in spi-nor-core [1]. It would be better to fix it in a series of
> 'sync to Linux' patches after isolation of stacked/parallel, rather than patching on top
> of that.
>
Yes, it should sync with Linux after isolation of stacked/parallel.
> As discussed in [2], SPI-NOR subsystem in u-boot has not been maintained long
> time. Generic SPI-NOR driver introduced in Linux needs to be ported into u-boot to
> mitigate growing device ID table. Isolation of stacked/parallel is necessary to move
> forward.
>
> Now stacked memories support is available in Linux [3] with different approach from
> the one in u-boot. Isolation is also needed as the first step to adapt the Linux's
> approach to u-boot.
The Linux stacked approach is based on the MTD framework, not the SF framework. I am working on adapting the Linux approach in our AMD internal U-Boot, and internal regression testing is currently in progress on our platforms. I will send the patches soon.
Regards
Padmarao
>
> [1] https://lore.kernel.org/u-
> boot/683be5a32ef345229d54a68ea67fe64c at infineon.com/
> [2] https://lore.kernel.org/u-boot/20260213164607.GI2747538@bill-the-cat/#t
> [3] https://lore.kernel.org/linux-mtd/20260204-mtd-virt-concat-v17-0-
> 5e98239bb55b at bootlin.com/
>
> Thanks,
> Takahiro
>
> >
> > > Hi Takahiro Kuwano,
> > Hi
> >
> > >
> > > We have tested your patches with upstream u-boot and found issues
> > > with both QSPI and OSPI flashes. Below are results, 1 for QSPI and 2 for OSPI.
> > >
> > Thanks for your help!
> >
> > > 1). Issue : observed with QSPI flash's operating in single mode.
> > > tested below flashes
> > >
> > > n25q00a on VCK190
> > > mt25qu512a on ZCU102
> > >
> > > Observed Behavior:
> > > Data mismatch is observed in single‑mode QSPI during partial data integrity
> tests, such as:
> > > 9‑byte test
> > > 32‑byte test
> > > 32 MB test , etc.,
> > > The data written to flash does not match the data read back when compared
> byte‑by‑byte.
> > >
> > > Working Behavior
> > > Full flash size data integrity test is working fine in single mode
> > > also Dual‑mode QSPI tests working fine .
> > > The issue is reproducible only in single‑mode QSPI partial data
> > > integrity tests
> > >
> > This series tries to keep single-mode QSPI unchanged.
> > Could you please narrow down which change in series breaks it?
> >
> > > --------------------------------------------------------------------
> > > ----------- U-Boot 2026.04-rc2-00046-g967458518770 (Feb 18 2026 -
> > > 16:18:41 +0530)
> > >
> > > CPU: Versal
> > > Silicon: v2
> > > Chip: v2
> > > CPU: VersalSilicon: v2Chip: v2Model: Xilinx Versal vck190 Eval board revA
> (QSPI)
> > > DRAM: 2 GiB (total 8 GiB)
> > > EL Level: EL2
> > > Multiboot: 0
> > > Core: 41 devices, 24 uclasses, devicetree: board
> > > MMC: arasan_sdhci mmc at f1050000: Sdhci card detect state not stable
> > > arasan_sdhci mmc at f1050000: Sdhci card detect state not stable
> > > mmc at f1050000 - probe failed: -110
> > > arasan_sdhci mmc at f1050000: Sdhci card detect state not stable
> > >
> > > Loading Environment from nowhere... OK
> > > In: serial at ff000000
> > > Out: serial at ff000000
> > > Loading Environment from nowhere... OKIn: serial at ff000000Out:
> serial at ff000000Err: serial at ff000000
> > > Bootmode: JTAG_MODE
> > > Net:
> > > ZYNQ GEM: ff0c0000, mdio bus ff0c0000, phyaddr 1, interface rgmii-id
> > >
> > > Warning: ethernet at ff0c0000 (eth0) using random MAC address -
> > > 72:1e:d7:a9:9b:1a
> > > eth0: ethernet at ff0c0000Get shared mii bus on ethernet at ff0d0000
> > >
> > > ZYNQ GEM: ff0d0000, mdio bus ff0c0000, phyaddr 2, interface rgmii-id
> > >
> > > Warning: ethernet at ff0d0000 (eth1) using random MAC address -
> > > da:67:b7:c3:2f:ca , eth1: ethernet at ff0d0000
> > > Warning: ethernet at ff0d0000 (eth1) using random MAC address -
> da:67:b7:c3:2f:ca, eth1:
> > > ethernet at ff0d0000arasan_sdhci mmc at f1050000: Sdhci card detect state
> > > not stable Cannot persist EFI variables without system partition
> > > Missing TPMv2 device for EFI_TCG_PROTOCOL Missing RNG device for
> > > EFI_RNG_PROTOCOL Hit any key to stop autoboot: 0
> > > Versal> tftpb 0x400000 test_32MB.bin
> > > Filename 'test_32MB.bin'.
> > > Load address: 0x400000
> > > Loading: ################################################## 32 MiB
> > > 12.5 MiB/s
> > > done
> > > Bytes transferred = 33554432 (2000000 hex)
> > > Versal> sf probe 0 0 0
> > > SF: Detected n25q00a with page size 256 Bytes, erase size 64 KiB,
> > > total 128 MiB
> > > Versal> sf erase 0x0 0x2000000
> > > SF: 33554432 bytes @ 0x0 Erased: OK
> > > Versal> sf write 0x400000 0x0 0x2000000
> > > device 0 offset 0x0, size 0x2000000
> > > SF: 33554432 bytes @ 0x0 Written: OK
> > > Versal> mw.b 0x4000000 0 0x2000000
> > > Versal> sf read 0x4000000 0x0 0x2000000
> > > device 0 offset 0x0, size 0x2000000
> > > SF: 33554432 bytes @ 0x0 Read: OK
> > > Versal> cmp.b 0x400000 0x4000000 0x2000000
> > > byte at 0x00400000 (0x14) != byte at 0x04000000 (0xc4) Total of 0
> > > byte(s) were the same
> > >
> > >
> > > Versal> mw.b 0x8000 de 0x4000000
> > > Versal> sf erase 0x4000000 0x4000000
> > > SF: 67108864 bytes @ 0x4000000 Erased: OK
> > > Versal> sf write 0x8000 0x4000000 0x4000000
> > > device 0 offset 0x4000000, size 0x4000000
> > > SF: 67108864 bytes @ 0x4000000 Written: OK
> > > Versal> mw.b 0x20000000 0 0x4000000
> > > Versal> sf read 0x20000000 0x4000000 0x4000000
> > > device 0 offset 0x4000000, size 0x4000000
> > > SF: 67108864 bytes @ 0x4000000 Read: OK
> > > Versal> cmp.b 0x8000 0x20000000 0x4000000
> > > cmp.b 0x8000 0x20000000 0x4000000
> > > byte at 0x00008000 (0xde) != byte at 0x20000000 (0xce) Total of 0
> > > byte(s) were the same
> > > --------------------------------------------------------------------
> > > -----------
> > >
> > >
> > > 2). Issue: observed OSPI data integrity failures with MT35XU02G flash:
> > >
> > > Versal Gen 2 SoC with single mode
> > > Versal_net SoC with stacked mode
> > >
> > > Observed Behavior
> > > Data mismatch is observed in single and stacked mode OSPI during
> > > large data integrity tests, and full-size data integrity.
> > >
> > > Working Behavior
> > > Full flash size data integrity test is working fine in single mode
> > > on vck190 board: Versal platform. tested ospi flashes: gd55lx01g ,
> > > mt35xu02g
> >
> > So, in single mode, gd55lx01g works, but mt35xu02g doesn't, right?
> > I tried not to change any device specific logics.
> > Same like 1), please narrow down which change in this series breaks it.
> >
> > Best Regards,
> > Takahiro
> >
> > > --------------------------------------------------------------------
> > > ----------- U-Boot 2026.04-rc2-00047-g413f7147bb88 (Feb 18 2026 -
> > > 17:30:17 +0530)
> > > CPU: Versal Gen 2
> > > Silicon: v1.0
> > > Chip: v1.0
> > > Model: X-PRC-11 revA
> > > DRAM: 2 GiB
> > > optee optee: OP-TEE api uid mismatch
> > > NOT_SUPPORTED: A Firmware Framework implementation does not exist
> > > EL Level: EL2
> > > Core: 48 devices, 27 uclasses, devicetree: board
> > > MMC: mmc at f1040000: 0
> > > Loading Environment from nowhere... OK
> > > In: serial at f1920000
> > > Out: serial at f1920000
> > > Err: serial at f1920000
> > > Bootmode: JTAG_MODE
> > > Net:
> > > ZYNQ GEM: f1a70000, mdio bus f1a70000, phyaddr 1, interface
> > > rgmii-idWarning: ethernet at f1a70000 (eth0) using random MAC address -
> > > 02:2b:b8:0d:92:33
> > > eth0: ethernet at f1a70000
> > > Hit any key to stop autoboot: 0
> > > versal2> sf probe 0 0 0
> > > sf probe 0 0 0
> > > SF: Detected mt35xu02g with page size 256 Bytes, erase size 128 KiB,
> > > total 256 MiB
> > > versal2> mw.b 0x8000 cd 0x10000000
> > > versal2> sf erase 0x0 0x10000000
> > > SF: 268435456 bytes @ 0x0 Erased: OK
> > > versal2> sf write 0x8000 0x0 0x10000000
> > > device 0 whole chip
> > > SF: 268435456 bytes @ 0x0 Written: OK
> > > versal2> mw.b 0x20010000 0 0x10000000 sf read 0x20010000 0x0
> > > versal2> 0x10000000
> > > device 0 whole chip
> > > SF: 268435456 bytes @ 0x0 Read: OK
> > > versal2> cmp.b 0x8000 0x20010000 0x10000000
> > > cmp.b 0x8000 0x20010000 0x10000000
> > > byte at 0x05758240 (0xcd) != byte at 0x25760240 (0x0) Total of
> > > 91554368 byte(s) were the same
> > >
> > > Versal NET> sf probe 0 0 0
> > > SF: Detected mt35xu02g with page size 256 Bytes, erase size 128 KiB,
> > > total 512 MiB Versal NET> mw.b 0x8000 cd 0x20000000 Versal NET> sf
> > > erase 0x0 0x20000000
> > > SF: 536870912 bytes @ 0x0 Erased: OK Versal NET> sf write 0x8000 0x0
> > > 0x20000000 device 0 whole chip
> > > SF: 536870912 bytes @ 0x0 Written: OK Versal NET> mw.b 0x20010000 0
> > > 0x20000000 Versal NET> sf read 0x20010000 0x0 0x20000000 device 0
> > > whole chip
> > > SF: 536870912 bytes @ 0x0 Read: OK
> > > Versal NET> cmp.b 0x8000 0x20010000 0x20000000 cmp.b 0x8000
> > > 0x20010000 0x20000000 byte at 0x00008000 (0xcd) != byte at
> > > 0x20010000 (0x0) Total of 0 byte(s) were the same
> > > --------------------------------------------------------------------
> > > -----------
> > >
> > > Regards
> > > Padmarao
> > >
> > > > From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of Begari,
> > > > Padmarao
> > > > Sent: Tuesday, December 16, 2025 7:16 PM
> > > > To: Takahiro.Kuwano at infineon.com; u-boot at lists.denx.de; Tudor
> > > > Ambarus <tudor.ambarus at linaro.org>
> > > > Cc: Jagan Teki <jagan at amarulasolutions.com>; Simek, Michal
> > > > <michal.simek at amd.com>; Tom Rini <trini at konsulko.com>; Erkiaga
> > > > Elorza, Ibai <ibai.erkiaga-elorza at amd.com>; Vignesh R
> > > > <vigneshr at ti.com>; Kummari, Prasad <Prasad.Kummari at amd.com>; Marek
> > > > Vasut <marek.vasut+renesas at mailbox.org>;
> > > > Mutya, Havish <havish.mutya at amd.com>; Ashok Reddy Soma
> > > > <ashok.reddy.soma at amd.com>; Venkatesh Yadav Abbarapu
> > > > <venkatesh.abbarapu at amd.com>; Daassi Bacem
> > > > <Bacem.Daassi at infineon.com>; Shinsuke Okada
> > > > <Shinsuke.Okada at infineon.com>; Hiroyuki Saito
> > > > <Hiroyuki.Saito2 at infineon.com>; Takahiro Kuwano
> > > > <tkuw584924 at gmail.com>
> > > > Subject: RE: [PATCH 00/11] mtd: spi-nor: Isolate stacked/parallel
> > > > support from core
> > > >
> > > >
> > > > Hi Takahiro Kuwano,
> > > >
> > > > Apologies for the delay in responding and thank you for sending this patch
> series.
> > > > Since the changes are related to our AMD stacked and parallel
> > > > configurations, we’ll look into it.
> > > >
> > > > Thanks & Regards
> > > > Padmarao
> > > >
> > > > > -----Original Message-----
> > > > > From: U-Boot <u-boot-bounces at lists.denx.de> On Behalf Of
> > > > > Takahiro Kuwano via
> > > > > B4 Relay
> > > > > Sent: Wednesday, November 19, 2025 10:43 AM
> > > > > To: u-boot at lists.denx.de; Tudor Ambarus
> > > > > <tudor.ambarus at linaro.org>
> > > > > Cc: Jagan Teki <jagan at amarulasolutions.com>; Simek, Michal
> > > > > <michal.simek at amd.com>; Tom Rini <trini at konsulko.com>; Erkiaga
> > > > > Elorza, Ibai <ibai.erkiaga-elorza at amd.com>; Vignesh R
> > > > > <vigneshr at ti.com>; Kummari, Prasad <Prasad.Kummari at amd.com>;
> > > > > Marek Vasut <marek.vasut+renesas at mailbox.org>; Mutya, Havish
> > > > > <havish.mutya at amd.com>; Ashok Reddy Soma
> > > > > <ashok.reddy.soma at amd.com>; Venkatesh Yadav Abbarapu
> > > > > <venkatesh.abbarapu at amd.com>; Daassi Bacem
> > > > > <Bacem.Daassi at infineon.com>; Shinsuke Okada
> > > > > <Shinsuke.Okada at infineon.com>; Hiroyuki Saito
> > > > > <Hiroyuki.Saito2 at infineon.com>; Takahiro Kuwano
> > > > > <tkuw584924 at gmail.com>; Takahiro Kuwano
> > > > > <Takahiro.Kuwano at infineon.com>
> > > > > Subject: [PATCH 00/11] mtd: spi-nor: Isolate stacked/parallel
> > > > > support from core
> > > > >
> > > > > This series suggests to isolate stacked/parallel support from
> > > > > spi-nor-core by moving that to SPI controllers and new modules under
> mtd/spi.
> > > > >
> > > > > The patchset mainly focuses on removing references to
> > > > > stacked/parallel related items from core. The stacked/parallel
> > > > > support logic itself may have rooms to improve. Rework or
> > > > > further cleanup in stacked/parallel support would be done by other patches
> after this series is applied.
> > > > >
> > > > > Signed-off-by: Takahiro Kuwano <Takahiro.Kuwano at infineon.com>
> > > > > ---
> > > > > Takahiro Kuwano (11):
> > > > > spi: zynqmp-gqspi: Set priv->is_parallel in child_pre_probe()
> > > > > spi: zynqmp_gqspi: Remove reference to SPI_XFER_LOWER flag.
> > > > > spi: zynqmp_gqspi: Read two bytes of SR and FSR in parallel mode
> > > > > spi: zynq-qspi: Set priv->is_parallel/stacked in child_pre_probe()
> > > > > spi: zynq_qspi: Remove reference to SPI_XFER_LOWER flag.
> > > > > spi: zynq_qspi: Read two bytes of SR and FSR in parallel mode
> > > > > mtd: spi-nor: Migrate stacked/parallel part to new modules
> > > > > mtd: spi-nor: stacked: Cleanup stacked/parallel flags
> > > > > mtd: spi-nor: parallel: Cleanup stacked/parallel flags
> > > > > mtd: spi-nor: Revert stacked/parallel related commits
> > > > > mtd: spi-nor: Call stacked/parallel post init fixups
> > > > >
> > > > > drivers/mtd/spi/Makefile | 4 +
> > > > > drivers/mtd/spi/parallel.c | 412
> > > > > ++++++++++++++++++++++++++++++++++++++++
> > > > > drivers/mtd/spi/sf_internal.h | 18 ++
> > > > > drivers/mtd/spi/spi-nor-core.c | 422
> > > > > +++++++----------------------------------
> > > > > drivers/mtd/spi/stacked.c | 389
> > > > > +++++++++++++++++++++++++++++++++++++
> > > > > drivers/spi/zynq_qspi.c | 47 +++--
> > > > > drivers/spi/zynqmp_gqspi.c | 55 ++++--
> > > > > include/linux/mtd/spi-nor.h | 10 -
> > > > > include/spi.h | 2 -
> > > > > 9 files changed, 973 insertions(+), 386 deletions(-)
> > > > > ---
> > > > > base-commit: e2d51f8db207f7db70dd8104fa1da2cffda419f2
> > > > > change-id: 20251118-amd-cleanup-c8023872e3cf
> > > > >
> > > > > Best regards,
> > > > > --
> > > > > Takahiro Kuwano <Takahiro.Kuwano at infineon.com>
> > > > >
More information about the U-Boot
mailing list