Should spi-nand wok with SPI on Zynq?

Charles Manning cdhmanning at gmail.com
Tue Oct 17 18:20:39 PDT 2023


Hi All

I am trying to use spi-nand an a Zynq via an spi port (NB not qspi)

I have tried both 5.15 and 6.1.5 as supported on the XIlinx linux tree,

The device tree node is:
        spi at e0007000 {
            compatible = "xlnx,zynq-spi-r1p6";
            reg = <0xe0007000 0x1000>;
            status = "okay";
            interrupt-parent = <0x04>;
            interrupts = <0x00 0x31 0x04>;
            clocks = <0x01 0x1a 0x01 0x23>;
            clock-names = "ref_clk\0pclk";
            #address-cells = <0x01>;
            #size-cells = <0x00>;

            nandflash at 0 {
                compatible = "spi-nand";
                reg = <0x00>;
                spi-max-frequency = <0x989680>;

                partitions {
                    compatible = "fixed-partitions";
                    #address-cells = <0x02>;
                    #size-cells = <0x02>;

                    partition at 0 {
                        label = "small";
                        reg = <0x00 0x00 0x00 0x800000>;
                    };
                };
            };
        };


The boot up recognises the device fine:

spi-nand spi0.0: Micron SPI NAND was found.
spi-nand spi0.0: 128 MiB, block size: 128 KiB, page size: 2048, OOB size: 128
1 fixed-partitions partitions found on MTD device spi0.0
Creating 1 MTD partitions on "spi0.0":
0x000000000000-0x000000800000 : "small"

But all the blocks are bad.

# nanddump -c /dev/mtd0
ECC failed: 0
ECC corrected: 0
Number of bad blocks: 62
Number of bbt blocks: 0
Block size 131072, page size 2048, OOB size 128
Dumping data starting at 0x00000000 and ending at 0x00800000...
libmtd: error!: cannot read 2048 bytes from mtd0 (eraseblock 0, offset 0)
        error 110 (Connection timed out)
nanddump: error!: mtd_read

When I attach a logic analyser I can see that when the CPU issues a
request for status, the expected traffic is on the bus, with the
status being 0x00, but the spi_mem_status() is not giving back a valid
status (I'm betting 0xff) and the -110 return value indicating a time
out.

In spi_mem_poll_status() the ret == -ENOTSUPP) code is being executed.

        if (ret == -EOPNOTSUPP) {
                if (!spi_mem_supports_op(mem, op))
                        return ret;

                if (initial_delay_us < 10)
                        udelay(initial_delay_us);
                else
                        usleep_range((initial_delay_us >> 2) + 1,
                                     initial_delay_us);

                ret = read_poll_timeout(spi_mem_read_status, read_status_ret,
                                        (read_status_ret || ((status)
& mask) == match),
                                        polling_delay_us, timeout_ms *
1000, false, mem,
                                        op, &status);
   +          pr_info("mem op status status 0x%x ret %d\n", status, ret);

                if (read_status_ret)
                        return read_status_ret;
        }

That gives me :
mem op status status 0xff ret -110

This suggests to me that something isn't working properly in the
spi-mem is using the underlying driver.

Any suggestions/pointers would be welcome.

Thanks

Charles



More information about the linux-mtd mailing list