Skip to content
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

Open
sebfabre opened this issue Apr 19, 2023 · 5 comments
Open

imx6qdlsabresd: cp from coreutils failure with uboot-imx #1506

sebfabre opened this issue Apr 19, 2023 · 5 comments
Assignees

Comments

@sebfabre
Copy link

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

@otavio
Copy link
Member

otavio commented Apr 19, 2023

This sounds like a memory calibration issue. Does cp from coreutils works with u-boot-fslc?

@sebfabre
Copy link
Author

Yes, cp from coreutils works with u-boot-fslc. Moreover, cp from busybox works with u-boot-fslc and u-boot-imx

@otavio
Copy link
Member

otavio commented Apr 24, 2023

Some questions:

  1. Could you check if 0a4fc52 helps?
  2. Why do you need u-boot-imx?

@sebfabre
Copy link
Author

Hello,

  1. Even with this SRCREV, I still have the issue
  2. 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?

@MrCry0
Copy link
Contributor

MrCry0 commented Feb 17, 2024

Hello,

  1. Even with this SRCREV, I still have the issue
  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants