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

Mon Jan 18 09:20:16 CET 2021

+Ashok

On 1/18/21 8:13 AM, Bin Meng wrote:
> +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
> 

M