+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
