[PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g

[Brandon Maier]

On Sat, Jan 16, 2021 at 3:27 AM Bin Meng <bmeng.cn at gmail.com> wrote:
>
> Hi Brandon,
>
> On Sat, Jan 16, 2021 at 5:54 AM Brandon Maier
> <brandon.maier at rockwellcollins.com> wrote:
> >
> > From: Taylor Burton <taylor.burton at rockwellcollins.com>
> >
> > Micron's mt25ql02g is not currently supported in
> > U-Boot, but is in Linux. Linux already has this flash
> > present in its table. A snippet below:
> >
> > { "mt25ql02g",   INFO(0x20ba22, 0, 64 * 1024, 4096...},
> >
> > Signed-off-by: Taylor Burton <taylor.burton at rockwellcollins.com>
> > Signed-off-by: Brandon Maier <brandon.maier at rockwellcollins.com>
> > CC: Jagan Teki <jagan at amarulasolutions.com>
> > CC: Vignesh R <vigneshr at ti.com>
> > ---
> >  drivers/mtd/spi/spi-nor-ids.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
> > index 5bd5dd3003..b1f7a1cf81 100644
> > --- a/drivers/mtd/spi/spi-nor-ids.c
> > +++ b/drivers/mtd/spi/spi-nor-ids.c
> > @@ -187,6 +187,7 @@ const struct flash_info spi_nor_ids[] = {
> >         { INFO("n25q00a",     0x20bb21, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >         { INFO("mt25ql01g",   0x21ba20, 0, 64 * 1024, 2048, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> >         { INFO("mt25qu02g",   0x20bb22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
> > +       { INFO("mt25ql02g",   0x20ba22, 0, 64 * 1024, 4096, SECT_4K | USE_FSR | SPI_NOR_QUAD_READ | NO_CHIP_ERASE) },
>
> nits: please insert this entry after "mt25ql01g"

Makes sense, if a maintainer applies this could you swap these? Else I
can send a v2 if needed.

>
> >         { INFO("mt35xu512aba", 0x2c5b1a, 0,  128 * 1024,  512, USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> >         { INFO("mt35xu02g",  0x2c5b1c, 0, 128 * 1024,  2048, USE_FSR | SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
> >  #endif
>
> I believe you have tested this flash with the updated Xilinx GQSPI
> controller driver below.
> patchwork.ozlabs.org/project/uboot/patch/20210115213020.41897-1-brandon.maier at rockwellcollins.com/

Correct, those driver changes were needed to make this chip work.

> Did you test the flash with Extended SPI mode (1-1-2 or 1-1-4)? If so,
> would you mind taking a look at the following question regarding the
> dummy cycle bus width question for the Dual/Quad Output Fast Read?
> https://lists.denx.de/pipermail/u-boot/2021-January/437213.html

The way I have U-Boot configured, it's using the Quad I/O Fast Read
1-4-4 (EBh). I was also having problems with dummy cycles. I had
attempted to use the zynqmp_gqspi.c driver from Xilinx/u-boot-xlnx,
but their version of dual/quad mode works by inferring the buswidth
for specific commands by either snooping the NOR commands and hard
coding the width, or for dummy cycles it assumes dummy buswidth ==
data buswidth. So Xilinx's version probably only works for specific
flash chips and configurations where it only uses supported NOR
commands.

If your question is if the driver should send the dummy cycles in
Single/Dual/Quad width, I don't think the flash chip cares, as it
ignores the data lines during the dummy cycles. Only the Linux/U-Boot
spi-mem framework cares, as it has to pick a width so it can convert
dummy cycles -> dummy bytes. And probably it's simpler to assume dummy
width == addr width as the dummy cycles immediately follow the address
anyway.

I would guess you are having the same problem as me, U-Boot is trying
to use certain NOR commands that Xilinx's driver hasn't hard coded a
fix for, and so the dummy cycles get calculated wrong. If you have a
chance maybe try my patch and see if that fixes it for you too?

>
> The question is for N25Q512, but I just looked at the mt25ql02g
> datasheet, and found they are pretty much the same.
>
> Regards,
> Bin