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

Bin Meng bmeng.cn at gmail.com
Mon Jan 18 08:13:26 CET 2021


+Michal from Xilinx

Hi Brandon,

On Sun, Jan 17, 2021 at 4:26 AM Brandon Maier <brandon.maier at collins.com> wrote:
>
> 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.

Yes, Xilinx's version of the U-Boot driver has hardcoded the dummy
buswdith to the value of "spi-rx-bus-width" from device tree which is
4. That's why I suspect the dummy cycle buswdith for 6Bh should also
be 4.

> 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 once had the same thoughts as you, but looks only setting the dummy
cycle buswidth to 4 for command 6Bh can work on the ZCU102 board.

>
> 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?
>

Here is my testing result:

U-Boot 2018.01-dirty (Apr 03 2019 - 15:00:40 -0400) Xilinx ZynqMP ZCU102 rev1.0

I2C:   ready
DRAM:  4 GiB
EL Level:       EL2
Chip ID:        zu9eg
MMC:   sdhci at ff170000: 0 (SD)
reading uboot.env
In:    serial at ff000000
Out:   serial at ff000000
Err:   serial at ff000000
Net:   ZYNQ GEM: ff0e0000, phyaddr c, interface rgmii-id
eth0: ethernet at ff0e0000
Hit any key to stop autoboot:  0
ZynqMP>
ZynqMP> sf probe;sf read 100000 10000 10000;md 100000
SF: Detected n25q512a with page size 512 Bytes, erase size 128 KiB,
total 128 MiB
device 0 offset 0x10000, size 0x10000
SF: 65536 bytes @ 0x10000 Read: OK
00100000: ffffffff ffffffff ffffffff ffffffff    ................
00100010: ffffffff ffffffff ffffffff ffffffff    ................
00100020: ffffffff ffffffff ffffffff ffffffff    ................
00100030: ffffffff ffffffff ffffffff ffffffff    ................
00100040: ffffffff ffffffff ffffffff ffffffff    ................
00100050: ffffffff ffffffff ffffffff ffffffff    ................
00100060: ffffffff ffffffff ffffffff ffffffff    ................
00100070: ffffffff ffffffff ffffffff ffffffff    ................
00100080: ffffffff ffffffff ffffffff ffffffff    ................
00100090: ffffffff ffffffff ffffffff ffffffff    ................
001000a0: ffffffff ffffffff ffffffff ffffffff    ................
001000b0: ffffffff ffffffff ffffffff ffffffff    ................
001000c0: ffffffff ffffffff ffffffff ffffffff    ................
001000d0: ffffffff ffffffff ffffffff ffffffff    ................
001000e0: ffffffff ffffffff ffffffff ffffffff    ................
001000f0: ffffffff ffffffff ffffffff ffffffff    ................
ZynqMP> setenv serverip 128.224.156.143;tftpboot 0x08000000
bmeng/u-boot.bin;go 0x08000000
Using ethernet at ff0e0000 device
TFTP from server 128.224.156.143; our IP address is 128.224.156.122
Filename 'bmeng/u-boot.bin'.
Load address: 0x8000000
Loading: #################################################################
         ###############
         9.2 MiB/s
done
Bytes transferred = 1170408 (11dbe8 hex)
## Starting application at 0x08000000 ...


U-Boot 2021.01-00552-gbfe3a98 (Jan 18 2021 - 15:04:16 +0800)

Model: ZynqMP ZCU102 RevA
Board: Xilinx ZynqMP
DRAM:  4 GiB
PMUFW:  v1.1
EL Level:       EL2
Chip ID:        zu9eg
WDT:   Started with servicing (60s timeout)
NAND:  0 MiB
MMC:   mmc at ff170000: 0
Loading Environment from FAT... *** Warning - bad CRC, using default environment

In:    serial at ff000000
Out:   serial at ff000000
Err:   serial at ff000000
Bootmode: LVL_SHFT_SD_MODE1
Reset reason:   SOFT
Net:
ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 21, interface rgmii-id
Could not get PHY for eth0: addr 21
No ethernet found.

Hit any key to stop autoboot:  0
ZynqMP> sf probe;sf read 100000 10000 10000;md 100000
spi->mode 2000
SF: Detected mt25qu512a with page size 256 Bytes, erase size 64 KiB,
total 64 MiB
device 0 offset 0x10000, size 0x10000
cmd 6b addr 10000 dummy buswidth 1 bytes 1
SF: 65536 bytes @ 0x10000 Read: OK
00100000: eeeeeeee bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100010: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100020: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100030: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100040: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100050: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100060: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100070: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100080: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
00100090: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
001000a0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
001000b0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
001000c0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
001000d0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
001000e0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................
001000f0: bbbbbbbb bbbbbbbb bbbbbbbb bbbbbbbb    ................

The board firstly boots with the original U-Boot, and I used "sf read"
to read the contents of SPI flash starting from offset 0x10000 which
are all 0xFFs.
Then I boots a U-Boot with your GQSPI patch. I added some debug print
to show spi->mode (0x2000) and command/addr/dummy during the read. The
contents are incorrect.
The command being used is 6Bh, the protocol is 1-1-4.

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

Regards,
Bin


More information about the U-Boot mailing list