Bad data hash on QSPI on LS1043A (Yocto Tiny)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Bad data hash on QSPI on LS1043A (Yocto Tiny)

Jump to solution
2,292 Views
Might-Lee
Contributor III

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.

0 Kudos
1 Solution
2,258 Views
yipingwang
NXP TechSupport
NXP TechSupport

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.

View solution in original post

0 Kudos
8 Replies
2,274 Views
yipingwang
NXP TechSupport
NXP TechSupport

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

 

0 Kudos
2,267 Views
Might-Lee
Contributor III

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"

MightLee_0-1630511842454.png


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"

MightLee_1-1630511885585.png

 

0 Kudos
2,259 Views
yipingwang
NXP TechSupport
NXP TechSupport

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.

0 Kudos
2,234 Views
Might-Lee
Contributor III

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?

0 Kudos
2,225 Views
yipingwang
NXP TechSupport
NXP TechSupport

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

0 Kudos
2,221 Views
Might-Lee
Contributor III

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.

0 Kudos
2,204 Views
yipingwang
NXP TechSupport
NXP TechSupport

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

0 Kudos
2,170 Views
Might-Lee
Contributor III

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.

0 Kudos