Working with boot partitions across multiple SPI flash chips

[AustenRoyer]

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?

[Zhiming_Liu]

Hi @AustenRoyer 

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

Best Regards,
Zhiming

[AustenRoyer]

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

        >;

    };

[Zhiming_Liu]

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

[AustenRoyer]

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?