spi-nor dummy bytes for fast read command

spi-nor dummy bytes for fast read command

[Bin Meng]

Hi,

It seems both U-Boot and Linux kernel spi-nor drivers have the same
assumption on dummy cycles required in a fast read command.

In U-Boot spi_nor_read_data(), there is a logic to calculate the dummy
bytes needed for fast read command:

    /* convert the dummy cycles to the number of bytes */
    op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;

This logic assumes the (nor->read_dummy * op.dummy.buswidth) is a
multiple of 8, otherwise this won't work.

In Linux, the same logic exists in spi_nor_spimem_read_data().

Note on most flashes this is not a problem, however on some flashes
the dummy cycles for the fast read command is configurable. If the
dummy cycle is configured to some odd value which makes this
assumption false, then we get a non-working driver.

Regards,
Bin

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: spi-nor dummy bytes for fast read command

[Tudor.Ambarus]

On 1/13/21 4:06 AM, Bin Meng wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> Hi,

Hi,

> 
> It seems both U-Boot and Linux kernel spi-nor drivers have the same
> assumption on dummy cycles required in a fast read command.
> 
> In U-Boot spi_nor_read_data(), there is a logic to calculate the dummy
> bytes needed for fast read command:
> 
>     /* convert the dummy cycles to the number of bytes */
>     op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
> 
> This logic assumes the (nor->read_dummy * op.dummy.buswidth) is a
> multiple of 8, otherwise this won't work.
> 
> In Linux, the same logic exists in spi_nor_spimem_read_data().
> 
> Note on most flashes this is not a problem, however on some flashes
> the dummy cycles for the fast read command is configurable. If the
> dummy cycle is configured to some odd value which makes this
> assumption false, then we get a non-working driver.
> 

Right. We should use dummy cycles directly and get rid of the
dummy bytes logic. I have this in my todo queue for linux.

Cheers,
ta
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: spi-nor dummy bytes for fast read command

[Bin Meng]

On Wed, Jan 13, 2021 at 6:04 PM <Tudor.Ambarus@microchip.com> wrote:
>
> On 1/13/21 4:06 AM, Bin Meng wrote:
> > EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> >
> > Hi,
>
> Hi,
>
> >
> > It seems both U-Boot and Linux kernel spi-nor drivers have the same
> > assumption on dummy cycles required in a fast read command.
> >
> > In U-Boot spi_nor_read_data(), there is a logic to calculate the dummy
> > bytes needed for fast read command:
> >
> >     /* convert the dummy cycles to the number of bytes */
> >     op.dummy.nbytes = (nor->read_dummy * op.dummy.buswidth) / 8;
> >
> > This logic assumes the (nor->read_dummy * op.dummy.buswidth) is a
> > multiple of 8, otherwise this won't work.
> >
> > In Linux, the same logic exists in spi_nor_spimem_read_data().
> >
> > Note on most flashes this is not a problem, however on some flashes
> > the dummy cycles for the fast read command is configurable. If the
> > dummy cycle is configured to some odd value which makes this
> > assumption false, then we get a non-working driver.
> >
>
> Right. We should use dummy cycles directly and get rid of the
> dummy bytes logic. I have this in my todo queue for linux.

Thanks! Good to know this will be improved.

I got another dummy cycle question during testing N25Q512 flash with
the Xilinx ZynqMP Generic QSPI controller.
The N25Q512 flash datasheet is at [1].

It seems both U-Boot and Linux spi-nor drivers assume that the dummy
cycle bus width is equal to the address bus width. See codes:

spi_nor_read_data() in u-boot/drivers/mtd/spi/spi-nor-core.c:

op.dummy.buswidth = op.addr.buswidth;

spi_nor_spimem_setup_op() in linux/drivers/mtd/spi-nor/core.c:

        if (op->dummy.nbytes)
                op->dummy.buswidth = spi_nor_get_protocol_addr_nbits(proto);

However the following Xilinx U-Boot driver:
https://github.com/Xilinx/u-boot-xlnx/blob/master/drivers/spi/zynqmp_gqspi.c#L611

programs the controller's dummy cycle bus width to 4 (QSPI) when
issuing the Fast Read Quad Output (6Bh). I changed the codes to
program dummy cycle bus width to 1 (SPI) but the command did not read
the flash contents at all.

The board has a N25Q512 flash, and the datasheet does not state
crystal clearly how many lines are used for 6Bh. Only figure 19
showing the command sequence could be interpreted that dummy cycles
need to be on 4 lines for 6Bh. But still it is not clear.

Do you, or anyone happen to know whether this is indeed the case for
N25Q512 flash? If yes, I think we will need some fix-ups in U-Boot and
Linux spi-nor drivers for the Numonyx/Micron flashes?

[1] https://media-www.micron.com/-/media/client/global/documents/products/data-sheet/nor-flash/serial-nor/n25q/n25q_512mb_1ce_3v_65nm.pdf

Regards,
Bin

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/