imx6qdlsabresd: cp from coreutils failure with uboot-imx

[SebastienFabre]

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

[SebastienFabre]

Hello,

Do you have any update about this issue?

Best regards

[SebastienFabre]

I make more test:

• If I use imx manifest imx-5.15.32-2.0.0.xml (so meta-imx): it works
• If I use fsl manifest and linux-imx from meta-freescale (5.15.71): there is the issue
• If I use fsl manifest and previous linux-imx from meta-freescale (5.15.52): it works

So the issue seems to appear between linux-imx 5.15.52 and 5.15.71