All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g
@ 2021-01-15 21:25 Brandon Maier
  2021-01-16  9:26 ` Bin Meng
  0 siblings, 1 reply; 5+ messages in thread
From: Brandon Maier @ 2021-01-15 21:25 UTC (permalink / raw)
  To: u-boot

From: Taylor Burton <taylor.burton@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@rockwellcollins.com>
Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
CC: Jagan Teki <jagan@amarulasolutions.com>
CC: Vignesh R <vigneshr@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) },
 	{ 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
-- 
2.29.1

^ permalink raw reply related	[flat|nested] 5+ messages in thread
* [PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g
  2021-01-15 21:25 [PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g Brandon Maier
@ 2021-01-16  9:26 ` Bin Meng
  2021-01-16 20:26   ` Brandon Maier
  0 siblings, 1 reply; 5+ messages in thread
From: Bin Meng @ 2021-01-16  9:26 UTC (permalink / raw)
  To: u-boot

Hi Brandon,

On Sat, Jan 16, 2021 at 5:54 AM Brandon Maier
<brandon.maier@rockwellcollins.com> wrote:
>
> From: Taylor Burton <taylor.burton@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@rockwellcollins.com>
> Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
> CC: Jagan Teki <jagan@amarulasolutions.com>
> CC: Vignesh R <vigneshr@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"

>         { 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/

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 question is for N25Q512, but I just looked at the mt25ql02g
datasheet, and found they are pretty much the same.

Regards,
Bin

^ permalink raw reply	[flat|nested] 5+ messages in thread
* [PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g
  2021-01-16  9:26 ` Bin Meng
@ 2021-01-16 20:26   ` Brandon Maier
  2021-01-18  7:13     ` Bin Meng
  0 siblings, 1 reply; 5+ messages in thread
From: Brandon Maier @ 2021-01-16 20:26 UTC (permalink / raw)
  To: u-boot

On Sat, Jan 16, 2021 at 3:27 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>
> Hi Brandon,
>
> On Sat, Jan 16, 2021 at 5:54 AM Brandon Maier
> <brandon.maier@rockwellcollins.com> wrote:
> >
> > From: Taylor Burton <taylor.burton@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@rockwellcollins.com>
> > Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
> > CC: Jagan Teki <jagan@amarulasolutions.com>
> > CC: Vignesh R <vigneshr@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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* [PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g
  2021-01-16 20:26   ` Brandon Maier
@ 2021-01-18  7:13     ` Bin Meng
  2021-01-18  8:20       ` Michal Simek
  0 siblings, 1 reply; 5+ messages in thread
From: Bin Meng @ 2021-01-18  7:13 UTC (permalink / raw)
  To: u-boot

+Michal from Xilinx

Hi Brandon,

On Sun, Jan 17, 2021 at 4:26 AM Brandon Maier <brandon.maier@collins.com> wrote:
>
> On Sat, Jan 16, 2021 at 3:27 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> >
> > Hi Brandon,
> >
> > On Sat, Jan 16, 2021 at 5:54 AM Brandon Maier
> > <brandon.maier@rockwellcollins.com> wrote:
> > >
> > > From: Taylor Burton <taylor.burton@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@rockwellcollins.com>
> > > Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
> > > CC: Jagan Teki <jagan@amarulasolutions.com>
> > > CC: Vignesh R <vigneshr@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

^ permalink raw reply	[flat|nested] 5+ messages in thread
* [PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g
  2021-01-18  7:13     ` Bin Meng
@ 2021-01-18  8:20       ` Michal Simek
  0 siblings, 0 replies; 5+ messages in thread
From: Michal Simek @ 2021-01-18  8:20 UTC (permalink / raw)
  To: u-boot

+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@collins.com> wrote:
>>
>> On Sat, Jan 16, 2021 at 3:27 AM Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> Hi Brandon,
>>>
>>> On Sat, Jan 16, 2021 at 5:54 AM Brandon Maier
>>> <brandon.maier@rockwellcollins.com> wrote:
>>>>
>>>> From: Taylor Burton <taylor.burton@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@rockwellcollins.com>
>>>> Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com>
>>>> CC: Jagan Teki <jagan@amarulasolutions.com>
>>>> CC: Vignesh R <vigneshr@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

^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2021-01-18  8:20 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-15 21:25 [PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g Brandon Maier
2021-01-16  9:26 ` Bin Meng
2021-01-16 20:26   ` Brandon Maier
2021-01-18  7:13     ` Bin Meng
2021-01-18  8:20       ` Michal Simek

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.