imx6qdlsabresd: cp from coreutils failure with uboot-imx
Hello,
I am working on imx6qdlsabresd on yocto kirstone (fsl-community-bsp-platform manifest). I am building core-image-base with IMX_DEFAULT_BOOTLOADER set to "u-boot-imx", IMX_DEFAULT_BSP set to "nxp" and with "coreutils" added in IMAGE_INSTALL.
Sometimes, when using cp (from coreutils) to copy data from rootfs to tmpfs, the destination file does not have the same sha256 than the source one.
Commands ("for" command can be called twice to be sure that the issue is reproduced or not): dd if=/dev/urandom of=/home/root/30M.txt bs=30M count=1 && sha256sum /home/root/30M.txt for i in $(seq 1 1 20); do rm -f /tmp/30M.txt && cp /home/root/30M.txt /tmp/30M.txt && sha256sum /tmp/30M.txt; done
Results: dd if=/dev/urandom of=/home/root/30M.txt bs=30M count=1 && sha256sum /home/root/30M.txt 1+0 records in 1+0 records out 31457280 bytes (31 MB, 30 MiB) copied, 2.11143 s, 14.9 MB/s 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /home/root/30M.txt for i in $(seq 1 1 20); do rm -f /tmp/30M.txt && cp /home/root/30M.txt /tmp/30M.txt && sha256sum /tmp/30M.txt; done 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt d5c3ee70c0609ad3010457aaf8a69f7fdfaf50fe0a0c6793bf050debbfc61a36 /tmp/30M.txt 1ece694dc6380bda38760c571dd4683ae8468f656c5cb38baa28395728c5a33a /tmp/30M.txt 8a549142c6b3c84f38d67748d03d65414f8a6f0ac737d4d614a92dead6c3e7f1 /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 960382eb3d8428fca275eb6273a52b44c22bf9af40852cbc55f3104dd603e0b6 /tmp/30M.txt ed4e946d753f3a2185c738cde9cb53373e0a235530e7857bb44969e1f9fcbfa3 /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 391167f18efc76f89711b2d85de3b1e0d7a6fc95d970e27a6b2892b616f8bd1a /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 9b9528be4ec000dc2695569b97143030bdeebbf7b6b0e2addee28be755a1ee39 /tmp/30M.txt 63664e32858a363d8bb242f9f388684bd6cff124edadf9325987b629a764f8e4 /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 0e1e1b4479c372cf26e45d352b732d9aa47b746380abf6d2e2d4fc81969cc909 /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt 20b4c6005280badfa08a94a1713fa12d3cd1e890b6675f656ff56692b2c86b3b /tmp/30M.txt
It seems that we have the same issue with dunfell. The test is ok with "u-boot-fslc" or with cp from "busybox".
Do you know what can cause this behavior?
Regards
Sébastien
This sounds like a memory calibration issue. Does cp from coreutils works with u-boot-fslc?
Yes, cp from coreutils works with u-boot-fslc. Moreover, cp from busybox works with u-boot-fslc and u-boot-imx
Some questions:
- Could you check if https://github.com/Freescale/meta-freescale/commit/0a4fc52a9d6d1a4a2b1b245e400e72c5a3f58a68 helps?
- Why do you need
u-boot-imx?
Hello,
- Even with this SRCREV, I still have the issue
- In previous versions of our products, we use u-boot-imx. If we change to use u-boot-fslc, we will have to change the partitioning (because of SPL+uboot). Moreover, what is the difference between u-boot-imx and u-boot-fslc concerning secure boot and crypto?
Hello,
- Even with this SRCREV, I still have the issue
- In previous versions of our products, we use u-boot-imx. If we change to use u-boot-fslc, we will have to change the partitioning (because of SPL+uboot).
You could change this with a u-boot config for your project.
Moreover, what is the difference between u-boot-imx and u-boot-fslc concerning secure boot and crypto?
For imx6-based boards, I believe there are no significant changes in secure boot and crypto between imx and mainline u-boot.