
+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@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@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