Bad data hash on QSPI on LS1043A (Yocto Tiny)

[Might-Lee]

Platform: LS1043A

LSDK: LSDK 20.12

I have 7 target boards. I programmed with the same image to these 7 target boards. Everything works well under SDboot for all 7 boards, but not for QSPI Yocto tiny.

I used the command "flex-builder -i mkfw -m ls1043ardb -b sd" to generate the uboot enviroment. Then flash QSPI with the image that using ”flex-builder -I mkfw -m ls1043ardb -b qspi”. But when I start to run Yocto tiny, there are 3 different test results below on these 7 target boards.

1. 4 boards: getting "bad data hash" issue on Kernel image

2. 1 board: it's normal on Kernel image, but it also got "bad data hash" when it went to ramdisk image

3. 2 boards: It can successfully run Yocto tiny.

How can I fix these issues?

Please see attached for the log file and ls1043ardb_tfa_defconfig file for these 3 test results.

[yipingwang]

Please do the following verification.

1. Please download pro-built image lsdk2012_yocto_tiny_LS_arm64.itb.

wget https://www.nxp.com/lgfiles/sdk/lsdk2012/lsdk2012_yocto_tiny_LS_arm64.itb

2. Please write image to offset 0x1000000 on QSPI flah.

tftp 0xa0000000 nxa22585/ls1046ardb/lsdk2012_yocto_tiny_LS_arm64.itb

sf probe 0:0

sf write 0xa0000000 0x1000000 0x2800000

3. Read image from offset 0x1000000 on QSPI flash.

sf read 0xa0000000 0x1000000 0x2800000

4. boot image.

bootm 0xa0000000#ls1043ardb

[Might-Lee]

I run the tests as follows:
1. Followed your suggestion which flash the QSPI with pre-build image and write to the DDR from QSPI to run Yocto tiny.
  => the log of "QSPI_YOCTO_TINY.txt" shows it's still "bad data hash"

2. Read the data content of itb to DDR(0xa0000000) then bootm a0000000#ls1043ardb
  => the log of "DDR_YCOTO_TINY.txt" shows it's still "bad data hash"

[yipingwang · Accepted solution]

According to your test result, it seems that there is problem with DDR controller initialization.

Please use QCVS DDRv tool to connect to your target board to do optimization and validation.

You also could define CONFIG_CMD_MEMTEST=y in configs/ls1043ardb_tfa_defconfig in u-boot source code, rebuild u-boot image and use mtest under u-boot to test DDR memory.

[Might-Lee]

I fine-tune the DDR timing again and flash SD/QSPI/eMMC with this new timing setting, it turns out to normally run linux kernel under all boot source for all boards.

But I used "mtest f8000000 ffffffff" to run DDR test, then found a failure happened and it's fixed at the address of F800,0000~FFFF,FFFF (the final 128MB) for all boards.

Is it possible that the MPU is using this range to access data while running DDR checking to fail the DDR checking?

[yipingwang]

Please test DDR address range a0000000 to afffffff used in the testing procedure.

[Might-Lee]

I already run the test which includes whole range first and then narrow down to f8000000 ffffffff to make sure all is good except for this zone.

[yipingwang]

Please load image from SD card to RAM to check whether it is bootable from RAM.

[Might-Lee]

I have run the DDR tests below and the test results should turn out the current DDR on target board works normally.
1. Run DDR test at Uboot mode on LS1046ARDB => it has the same test result which failed at the final 128MB. That proved the root cause is the MPU is using this zone while sweeping the address of DDR to fail the DDR test.
2. Run DDR test at kernel on our target board => there is no failure detected

Anyway, after we fine-tune the DDR configuration with increasing comparsion size on QVCS DDR tool, all the target boards work well under any boot source.

Many thanks for your support.