i.MX ProcessorsのトピックRe: Working with boot partitions across multiple SPI flash chips

Working with boot partitions across multiple SPI flash chips

AustenRoyer — Wed, 17 Dec 2025 02:18:34 GMT

Hello

I am working on a design with an IMx8x Quad Plus, and we are trying to set up additional memory partitions across two different NOR SPI flashes. We have been able to boot into Linux out of the "primary" SPI flash, which is on Chip Select 0 of the FlexSPI interface, and we have had several MTD partitions on that primary flash working for a while. We have a secondary SPI flash chip for additional boot media storage that we do not seem to be able to boot out of. We are able to interact with the "secondary" SPI flash (on FlexSPI Chip Select 2) via uboot, and are getting valid responses when we probe it via `sf probe 0:2`, so we know that the HW is functional and supports reading/writing.

However, when the linux kernel boots after uboot, we can see in the kernel error logs that the primary flash gets registered, but the secondary flash fails to register a response from the spi-nor driver:

[ 1.483726] spi-nor spi3.0: {PN_omitted}({memory_size_omitted)
[ 1.490624] spi-nor spi3.2: unrecognized JEDEC id bytes: 00 00 00 00 00 00

Furthermore, we have noticed that, if we try to have both SPI flashes populated in an MTDparts string, we get a failure to list both devices in uboot. i.e. if our mtdparts string is "mtdparts=5d120000.spi.0:-@0x00000000(nor0partition0);5d120000.spi.2:-@0x00000000(nor1partition0);" and make a similar mtdids string for the two flashes, then running `mtd list` from uboot will only show the memory partitions from the flash that was most recently probed via `sf probe BUS_NUM:CHIP_NUM`.

Given the issues that we have seen so far when trying to store boot media on both SPI flash devices and access both during boot, we were curious as to the following questions:

Do any of the nxp kernel drivers prevent the kernel from accessing two different NOR SPI flash devices during boot? Is only one active SPI flash at a time supported?

Similiarly, do mtdparts and mtdids support having two different NOR SPI flashes on the same SPI bus?

Does using the "nxp,imx8-flexspi" framework for these SPI flash devices instead of the "spi-nor" framework (via the devicetree "compatible" string) change how the memory partitions are managed in uboot and Linux?

Re: Working with boot partitions across multiple SPI flash chips

Zhiming_Liu — Wed, 17 Dec 2025 05:59:37 GMT

Hi @AustenRoyer

Can you share your spi node and pinctrl setting in Linux?

Best Regards,
Zhiming

Re: Working with boot partitions across multiple SPI flash chips

AustenRoyer — Wed, 17 Dec 2025 21:44:04 GMT

Hello, SPI nodes and pinctrl are as follows:

/*************************************************************************************************

* NOR flash

*************************************************************************************************/

&flexspi0 {

pinctrl-names = "default";

pinctrl-0 = <&pinctrl_flexspi0>;

status = "okay";

/* Flash CS `reg` values

0 - QSPIA SS0

1 - QSPIA SS1

3 - QSPIB SS1

2 - QSPIB SS0

flash0: flash@0 {

reg = <0>;

#address-cells = <1>;

#size-cells = <1>;

compatible = "jedec,spi-nor";

spi-max-frequency = <66000000>;

spi-nor,ddr-quad-read-dummy = <8>;

spi-tx-bus-width = <1>;

spi-rx-bus-width = <4>;

macronix,dsr = <0x3>;

u-boot,dm-spl;

u-boot,dm-pre-proper;

partitions {

compatible = "fixed-partitions";

#address-cells = <1>;

#size-cells = <1>;

partition@0 {

label = "u-boot0";

reg = <0x00000000 0x00400000>;

};

partition@3c0000 {

label = "env0";

reg = <0x003C0000 0x00010000>; /* 64 KiB @ 3968 KiB */

};

partition@3f0000 {

label = "env1";

reg = <0x003F0000 0x00010000>; /* 64 KiB @ 4032 KiB */

};

partition@400000 {

label = "u-boot1";

reg = <0x00400000 0x00400000>;

};

partition@800000 {

label = "gubi";

reg = <0x00800000 0x07800000>;

};

/* Secondary flash */

flash1: flash@2 {

reg = <2>;

#address-cells = <1>;

#size-cells = <1>;

compatible = "jedec,spi-nor";

spi-max-frequency = <66000000>;

spi-tx-bus-width = <1>;

spi-rx-bus-width = <4>;

partitions {

compatible = "fixed-partitions";

#address-cells = <1>;

#size-cells = <1>;

partition@0 {

label = "fubi";

reg = <0x00000000 0x8000000>;

};

And the pinctrl settings for FlexSPI are as follows:

pinctrl_flexspi0: flexspi0grp {

fsl,pins = <

IMX8QXP_QSPI0A_DATA0_LSIO_QSPI0A_DATA0 0x0600004d

IMX8QXP_QSPI0A_DATA1_LSIO_QSPI0A_DATA1 0x0600004d

IMX8QXP_QSPI0A_DATA2_LSIO_QSPI0A_DATA2 0x0600004d

IMX8QXP_QSPI0A_DATA3_LSIO_QSPI0A_DATA3 0x0600004d

IMX8QXP_QSPI0A_DQS_LSIO_QSPI0A_DQS 0x0600004d

IMX8QXP_QSPI0A_SS0_B_LSIO_QSPI0A_SS0_B 0x0600004d

IMX8QXP_QSPI0A_SCLK_LSIO_QSPI0A_SCLK 0x0600004d

IMX8QXP_QSPI0B_SCLK_LSIO_QSPI0B_SCLK 0x0600004d

IMX8QXP_QSPI0B_DATA0_LSIO_QSPI0B_DATA0 0x0600004d

IMX8QXP_QSPI0B_DATA1_LSIO_QSPI0B_DATA1 0x0600004d

IMX8QXP_QSPI0B_DATA2_LSIO_QSPI0B_DATA2 0x0600004d

IMX8QXP_QSPI0B_DATA3_LSIO_QSPI0B_DATA3 0x0600004d

IMX8QXP_QSPI0B_DQS_LSIO_QSPI0B_DQS 0x0600004d

IMX8QXP_QSPI0B_SS0_B_LSIO_QSPI0B_SS0_B 0x0600004d

IMX8QXP_QSPI0B_SS1_B_LSIO_QSPI0B_SS1_B 0x0600004d

};

Re: Working with boot partitions across multiple SPI flash chips

Zhiming_Liu — Tue, 23 Dec 2025 08:02:03 GMT

Hi,

I found there is a feature in Linux dts: nxp,fspi-individual-mode, can you test this in Linux to check if threre is error in kernel?

Most i.MX EVK boards use both portA and portB data lines for Octal NOR access with fspi controller OCTCOMBINE bit enabled, but customers may connect two individual devices on each port, so individual mode was introduced in driver to support such case. If portA and portB connected to individual devices rather than combined together, please add the nxp,fspi-individual-mode string in DT file.

Best Regards,
Zhiming

Re: Working with boot partitions across multiple SPI flash chips

AustenRoyer — Mon, 05 Jan 2026 19:58:36 GMT

Hello,

After including the nxp,fspi-individual-mode, I get the same result where the dmesg logs show that the first SPI chip (at chip select 0) is successfully probed, but the second SPI chip fails to enumerate. It also seems that, regardless of the contents of the mtdparts string which is passed into the bootargs for linux, the MTD partitions are seen as being located on the first SPI flash chip:

```

[ 1.475230] spi-nor spi3.0: spi-flash-name (spi-flash-size Kbytes)
[ 1.480355] 1 fixed-partitions partitions found on MTD device 5d120000.spi-0
[ 1.487417] Creating 1 MTD partitions on "5d120000.spi-0":
[ 1.499452] spi-nor spi3.2: unrecognized JEDEC id bytes: 00 00 00 00 00 00

```

After the "booti" command is called from uboot, but before the linux kernel starts to boot, we see that the first SPI flash is probed again via a call to sf probe:

```

=> booti ${loadaddr} - ${fdt_addr};

## Flattened Device Tree blob at 83000000
Booting using the fdt blob at 0x83000000
Loading Device Tree to 00000000bbe11000, end 00000000bbe29e2b ... OK
SF: Detected spi-flash-name with page size 256 Bytes, erase size 64 KiB, total spi-flash-size MiB
addr_width = 4 erase_cmd = d8 rd_cmd = b pp_cmd = 2
Updating MTD partitions...
enable /bus@5d000000/spi@5d120000

```

Do I need to set the status of the SPI device at 5d120000.spi.0 to "disabled" in the devicetree for Uboot and Linux to be able to access the SPI device at 5d120000.spi.2 without these issues?