cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
3,297 Views
Registered: ‎09-05-2017

ZCU102 QSPI not fully erasing

Jump to solution

I've run into an issue with the QSPI on the ZCU102 kit while wrapping up on a variety of QSPI/UBI configuration work. I swear I've seen this working previously but I've checked everything that makes sense and I currently believe this could be yet another issue with the MPSoC QSPI controller driver.

 

The issue that I've run into is that the flash is only half erasing. Here is a quick show of the issue --

My partition scheme is as follows:

root@zcu102-zynqmp:~# cat /proc/mtd
dev: size erasesize name
mtd0: 00100000 00020000 "qspi-fsbl-uboot"
mtd1: 00100000 00020000 "qspi-uboot-env"
mtd2: 07e00000 00020000 "qspi-ubi"

 

Dumping a portion of /dev/mtd0 shows -- 

root@zcu102-zynqmp:~# hexdump -C /dev/mtd0
00000000 55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 01 |UBI#............|
00000010 00 00 00 40 00 00 00 80 63 7d 67 16 00 00 00 00 |...@....c}g.....|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 04 6e d6 d0 |.............n..|
00000040 55 42 49 21 01 01 00 05 7f ff ef ff 00 00 00 00 |UBI!............|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000070 00 00 00 00 00 00 00 00 00 00 00 00 b8 25 64 a8 |.............%d.|
00000080 00 00 01 a9 00 00 00 01 00 00 00 00 01 00 00 07 |................|
00000090 72 6f 6f 74 66 73 61 00 00 00 00 00 00 00 00 00 |rootfsa.........|
000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

 

Obviously at this point the flash is not empty. It has valid data in it. I now want to erase that data so I can write new data, so I do the following:

root@zcu102-zynqmp:~# flash_erase /dev/mtd0 0 0
Erasing 128 Kibyte @ e0000 -- 100 % complete

 

Unfortunately, it appears only half of the data was erased:

root@zcu102-zynqmp:~# hexdump -C /dev/mtd0
00000000 ff 42 ff 23 ff 00 ff 00 ff 00 ff 00 ff 00 ff 01 |.B.#............|
00000010 ff 00 ff 40 ff 00 ff 80 ff 7d ff 16 ff 00 ff 00 |...@.....}......|
00000020 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................|
00000030 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 6e ff d0 |.............n..|
00000040 ff 42 ff 21 ff 01 ff 05 ff ff ff ff ff 00 ff 00 |.B.!............|
00000050 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 |................|
*
00000070 ff 00 ff 00 ff 00 ff 00 ff 00 ff 00 ff 25 ff a8 |.............%..|
00000080 ff 00 ff a9 ff 00 ff 01 ff 00 ff 00 ff 00 ff 07 |................|
00000090 ff 6f ff 74 ff 73 ff 00 ff 00 ff 00 ff 00 ff 00 |.o.t.s..........|

 

A few more details about my configuration --

 

- I'm using meta-petalinux, meta-xilinx, meta-xilinx-tools, but with a custom yocto flow not the petalinux flow.

 

- My kernel config has:

CONFIG_MTD_SPI_NOR=y
# CONFIG_MTD_MT81xx_NOR is not set
# CONFIG_MTD_SPI_NOR_USE_4K_SECTORS is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20

 

- My DTS has:

spi@ff0f0000 {
u-boot,dm-pre-reloc;
compatible = "xlnx,zynqmp-qspi-1.0";
status = "okay";
clock-names = "ref_clk", "pclk";
interrupts = <0x0 0xf 0x4>;
interrupt-parent = <0x4>;
num-cs = <0x1>;
reg = <0x0 0xff0f0000 0x0 0x1000 0x0 0xc0000000 0x0 0x8000000>;
#address-cells = <0x1>;
#size-cells = <0x0>;
#stream-id-cells = <0x1>;
iommus = <0x8 0x873>;
power-domains = <0x1f>;
clocks = <0x3 0x35 0x3 0x1f>;
is-dual = <0x1>;
has-io-mode;

flash@0 {
compatible = "m25p80";
#address-cells = <0x1>;
#size-cells = <0x1>;
reg = <0x0>;
spi-tx-bus-width = <0x1>;
spi-rx-bus-width = <0x4>;
spi-max-frequency = <0x66ff300>;

partition@qspi-fsbl-uboot {
label = "qspi-fsbl-uboot";
reg = <0x0 0x100000>;
};

partition@qspi-uboot-env {
label = "qspi-uboot-env";
reg = <0x100000 0x100000>;
};

partition@qspi-rootfs_a {
label = "qspi-ubi";
reg = <0x200000 0x7E00000>;
};
};
};

 

These settings match https://www.xilinx.com/support/answers/69576.html

 

Has anyone else run into the same issue? 

 

Any support/advice is appreciated.

 

Thanks,

 

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
2,847 Views
Registered: ‎09-05-2017

After chasing this issue around for the better part of two days I believe I finally have a fix.

 

It turns out that this issue is a direct result of locking the flash on the ZCU102 (I suspect really with any board running the linux-xlnx fork). As soon as the flash is locked it becomes impossible to unlock due to an issue in the drivers/mtd/spi-nor/spi-nor.c implementation. 

 

Specifically, the implementation of spi_nor_lock/unlock utilizes a few helper functions to compute which regions of flash are currently locked to determine if more regions need to be locked/unlocked. Those functions depend on "sector_size" and "n_sectors" to compute which sectors are currently locked based on the status register protection bits. Without the provided patch, these variables wind up equal to 0 which results in the spi-nor layer believing the flash is already unlocked when it is not actually unlocked.

 

Out of courtesy to the community I am providing my patch. I can't say for sure that this will work in any configuration other than dual parallel, but if similar issues are experienced in another mode this would be the first thing I would look at.

 

View solution in original post

0 Kudos
3 Replies
Highlighted
2,043 Views
Registered: ‎09-05-2017

Posting back on my own thread. I reached out to my Xilinx FAE's, but have not yet received any reply. In the meantime I'm digging into this issue.

 

I've scoped the QSPI IC's U119, U120 during flash erasing and see CS and CLK toggling on both parts as would be expected.

 

While hunting around in the linux-xlnx tree I found the following comment regarding a fixme for dual parallel mode. https://github.com/Xilinx/linux-xlnx/blob/xilinx-v2017.2/arch/arm64/boot/dts/xilinx/zynqmp-zcu102.dts#L856

 

I also went ahead and downloaded the base TRD images, set up a fresh sdcard and tried the procedure on the TRD. Same result there. The TRD only facilitates erasing half of the flash.

 

I then went and found XTP434. This is a test procedure from Xilinx for factory provisioning of the QSPI flash on the ZCU102. I followed all of the steps in this document and unfortunately am seeing the exact same issue still...

Performing Erase Operation...
Erase Operation successful.
INFO: [Xicom 50-44] Elapsed time = 57 sec.
Performing Program Operation...
Program Operation successful.
INFO: [Xicom 50-44] Elapsed time = 182 sec.
Performing Verify Operation...
INFO: [Xicom 50-44] Elapsed time = 1 sec.
Verify Operation unsuccessful.
ERROR: [Labtools 27-3161] Flash Programming Unsuccessful

So far this looks like completely broken support on Xilinx's end to me. However, I find it really hard to believe that no one would have run into this issue previously, which makes me believe I'm missing something basic. I will continue to post back with progress. Any feedback/advice/support is appreciated.

0 Kudos
Highlighted
2,032 Views
Registered: ‎09-05-2017

One more brief update for today. I have several ZCU102's available to me. I tested with another two boards and obtained mixed results. Two out of three boards shows this issue, but one board works just fine. That is, one out of three boards allows me to fully erase and reprogram the flash as many times as I want.

 

I did a visual inspection between these boards but have not found any glaring manufacturing defect at this point. I'm not entirely sure where to go with this investigation at this point. I'm hoping that there is maybe a register somewhere in the QSPI part which is protecting the array from modification. The two boards showing this issue have been used for ongoing flash and UBI development so it is possible that one of them has a subtle setting change.

0 Kudos
Highlighted
2,848 Views
Registered: ‎09-05-2017

After chasing this issue around for the better part of two days I believe I finally have a fix.

 

It turns out that this issue is a direct result of locking the flash on the ZCU102 (I suspect really with any board running the linux-xlnx fork). As soon as the flash is locked it becomes impossible to unlock due to an issue in the drivers/mtd/spi-nor/spi-nor.c implementation. 

 

Specifically, the implementation of spi_nor_lock/unlock utilizes a few helper functions to compute which regions of flash are currently locked to determine if more regions need to be locked/unlocked. Those functions depend on "sector_size" and "n_sectors" to compute which sectors are currently locked based on the status register protection bits. Without the provided patch, these variables wind up equal to 0 which results in the spi-nor layer believing the flash is already unlocked when it is not actually unlocked.

 

Out of courtesy to the community I am providing my patch. I can't say for sure that this will work in any configuration other than dual parallel, but if similar issues are experienced in another mode this would be the first thing I would look at.

 

View solution in original post

0 Kudos