+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 <[email protected]> > wrote: >> >> On Sat, Jan 16, 2021 at 3:27 AM Bin Meng <[email protected]> wrote: >>> >>> Hi Brandon, >>> >>> On Sat, Jan 16, 2021 at 5:54 AM Brandon Maier >>> <[email protected]> wrote: >>>> >>>> From: Taylor Burton <[email protected]> >>>> >>>> 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 <[email protected]> >>>> Signed-off-by: Brandon Maier <[email protected]> >>>> CC: Jagan Teki <[email protected]> >>>> CC: Vignesh R <[email protected]> >>>> --- >>>> 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/[email protected]/ >> >> 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@ff170000: 0 (SD) > reading uboot.env > In: serial@ff000000 > Out: serial@ff000000 > Err: serial@ff000000 > Net: ZYNQ GEM: ff0e0000, phyaddr c, interface rgmii-id > eth0: ethernet@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@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@ff170000: 0 > Loading Environment from FAT... *** Warning - bad CRC, using default > environment > > In: serial@ff000000 > Out: serial@ff000000 > Err: serial@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
