News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

JFFS2 errors, QSPI data doesn't persist on petalinux 2021.2 tool on TE0720 board

Started by neels, April 22, 2024, 05:10:32 PM

Previous topic - Next topic

neels

Hi All,

I have a TE0720 module. I have a design that was running on a old Vivado toolchain (2016.2). I am currently updating the design to use Vivado 2021.2 toolchain. Much of the tool migration has gone as expected. But I have had a few issues with the QSPI on 2021.2 toolchain. I have the following patch that changes the QSPI from the default to my custom config.
 
--- project-spec/configs/config 2024-04-22 14:46:11.193697828 +0100
@@ -35,7 +35,7 @@
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_SELECT=y
 # CONFIG_SUBSYSTEM_MEMORY_MANUAL_SELECT is not set
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_BASEADDR=0x0
-CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_SIZE=0x10000000
+CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_SIZE=0x0e000000
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_KERNEL_BASEADDR=0x0
 CONFIG_SUBSYSTEM_MEMORY_PS7_DDR_0_BANKLESS_U__BOOT_TEXTBASE_OFFSET=0x400000
 CONFIG_SUBSYSTEM_MEMORY_IP_NAME="PS7_DDR_0"
@@ -43,12 +43,12 @@
 #
 # Serial Settings
 #
-# CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_0_SELECT is not set
-CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_1_SELECT=y
+CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_0_SELECT=y
+# CONFIG_SUBSYSTEM_FSBL_SERIAL_PS7_UART_1_SELECT is not set
 # CONFIG_SUBSYSTEM_FSBL_SERIAL_AXI_UART16550_0_SELECT is not set
 # CONFIG_SUBSYSTEM_FSBL_SERIAL_MANUAL_SELECT is not set
-# CONFIG_SUBSYSTEM_SERIAL_PS7_UART_0_SELECT is not set
-CONFIG_SUBSYSTEM_SERIAL_PS7_UART_1_SELECT=y
+CONFIG_SUBSYSTEM_SERIAL_PS7_UART_0_SELECT=y
+# CONFIG_SUBSYSTEM_SERIAL_PS7_UART_1_SELECT is not set
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_SELECT is not set
 # CONFIG_SUBSYSTEM_SERIAL_MANUAL_SELECT is not set
 # CONFIG_SUBSYSTEM_SERIAL_PS7_UART_0_BAUDRATE_600 is not set
@@ -72,8 +72,8 @@
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_BAUDRATE_230400 is not set
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_BAUDRATE_460800 is not set
 # CONFIG_SUBSYSTEM_SERIAL_AXI_UART16550_0_BAUDRATE_921600 is not set
-CONFIG_SUBSYSTEM_SERIAL_FSBL_IP_NAME="ps7_uart_1"
-CONFIG_SUBSYSTEM_SERIAL_IP_NAME="ps7_uart_1"
+CONFIG_SUBSYSTEM_SERIAL_FSBL_IP_NAME="ps7_uart_0"
+CONFIG_SUBSYSTEM_SERIAL_IP_NAME="ps7_uart_0"

 #
 # Ethernet Settings


The above patch used to work fine in the 2016.2 version (jffs2 had no errors, QSPI data used to persist after reboots). But on the 2021.2 version I am have noticed a lot of jffs2 errors in the boot log (as shown below) and the QSPI doesn't persist data after reboots.

Run /init as init process
INIT: version 2.97 booting
random: fast init done
jffs2: jffs2_scan_dirent_node(): Node CRC failed on node at 0x001d00f0: Read 0x5c97f158, calculated 0xbd247889
jffs2: jffs2_scan_dirent_node(): Node CRC failed on node at 0x001d10cc: Read 0x385250f9, calculated 0x99a1e049
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0000: 0x19ff instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0004: 0x000c instead
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001f0008: 0xb0b1 instead
jffs2: notice: (66) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2ccc. {19ff,e001,00000034,755c292f}
jffs2: notice: (66) jffs2_get_inode_nodes: Node header CRC failed at 0x1d295c. {196b,e001,00000034,755c292f}
jffs2: notice: (66) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2604. {1973,e001,00000032,503776f3}
Starting udev
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2ba4. {1954,e002,00000044,98f7fb1d}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2b48. {19be,e002,0000005a,2831dbb1}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2b04. {1916,e002,00000044,98f7fb1d}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2aa8. {19bd,e002,0000005a,2831dbb1}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d271c. {1916,e002,00000044,98f7fb1d}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d26cc. {1900,e002,0000004f,4ff67c1c}
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2688. {190b,e002,00000044,98f7fb1d}
udevd[79]: starting version 3.2.9
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2638. {1900,e002,0000004f,4ff67c1c}
random: udevd: uninitialized urandom read (16 bytes read)
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d25c0. {193e,e002,00000044,98f7fb1d}
random: udevd: uninitialized urandom read (16 bytes read)
jffs2: warning: (68) jffs2_do_read_inode_internal: no data nodes found for ino #66
jffs2: Returned error for crccheck of ino #66. Expect badness...
random: udevd: uninitialized urandom read (16 bytes read)
udevd[80]: starting eudev-3.2.9
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2904. {193e,e002,00000057,da5b036c}
jffs2: warning: (68) jffs2_do_read_inode_internal: no data nodes found for ino #70
jffs2: Returned error for crccheck of ino #70. Expect badness...
jffs2: notice: (68) jffs2_get_inode_nodes: Node header CRC failed at 0x1d2c74. {1913,e002,00000057,da5b036c}
jffs2: warning: (68) jffs2_do_read_inode_internal: no data nodes found for ino #74
jffs2: Returned error for crccheck of ino #74. Expect badness...
FAT-fs (mmcblk0p1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

From the log it can be seen that the MTD device is detected and the patches are taking effect. But the data on QSPI doesn't persist after the reboot.

spi-nor spi0.0: s25fl256s1 (32768 Kbytes)
2 fixed-partitions partitions found on MTD device spi0.0
Creating 2 MTD partitions on "spi0.0":
0x000000000000-0x000000e00000 : "qspi-boot"
0x000000e00000-0x000001000000 : "qspi-user"

I have attached a full log if it is of interest. Any pointers to fix the issue is greatly appreciated.

M Kirberg

Hi,

normally the problem with QSPI access is the QuadMode/QuadEnable fiddling of FSBL/Uboot/Linux.
I assume this can also be the case for you if you Boot via QSPI.

Linux changed the underlying devicetree configuration quite a bit in recent versions.
So please check if you are correct here.

Normally a good place to look for the correct bits in recent versions is the Uboot Devicetrees that Vivado uses internally:

So for 2021.2 please have a look at:
https://github.com/u-boot/u-boot/blob/v2021.01/arch/arm/dts/zynq-cse-qspi.dtsi#L65-L66

Most important are the highlighted Lines.

br

neels

Thanks @M kirberg for your suggestion.
Updating the spi bus width, frequency and compatible device fixed the jffs2 errors.
I can also confirm that the data in QSPI persists after reboots.
It will be great if the petalinux kickstart page can be updated with your suggestion, so that it might benefit other users when they try to do similar things.

Thanks.