[PATCH] mtd: spi-nor-ids: add support for Micron mt25ql02g
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
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@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
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.
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
+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
+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
participants (4)
-
Bin Meng -
Brandon Maier -
Brandon Maier -
Michal Simek