-
Notifications
You must be signed in to change notification settings - Fork 258
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
imx6qdlsabresd: cp from coreutils failure with uboot-imx #1506
Comments
This sounds like a memory calibration issue. Does |
Yes, |
Some questions:
|
Hello,
|
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. |
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
The text was updated successfully, but these errors were encountered: