Hi,
On 10/20/21 14:40, Wouter Joris wrote:
Dear U-boot maintainers,
I'm working on an Xilinx Zynqmp project ( Checkout tag xilinx-v2019.1 https://github.com/Xilinx/u-boot-xlnx/tree/xilinx-v2019.1 ) (ARM Cortex A53 ) and I'm facing an endianess mix-up. I'm no C-code guru, so I hope you'll stick here with me for a while.
In this example I'm performing a random crc check, the result was placed into memory.
* ZynqMP> crc32 0x8000 0x8002 0x7999 * crc32 0x8000 0x8002 * crc32 for 00008000 ... 00010001 ==> 0c9cf37c
This is the result of the CRC read-back:
* ZynqMP> md 7999 1 * 00007999: 7cf39c0c
Also the itest confirms something is wrong with the result.
* ZynqMP> if itest *7999 == 7cf39c0c; then echo true; else echo false; fi * true
* ZynqMP> if itest *7999 == 0c9cf37c; then echo true; else echo false; fi * false
I know there was an historic bug https://patchwork.ozlabs.org/project/uboot/patch/1365203470-9099-1-git-send-email-sjg@chromium.org/ about the crc endianess describing this exact problem but this issue seems to be addressed in later releases, as far as I know.
Uboot Xilinx crc32.c L172 https://github.com/Xilinx/u-boot-xlnx/blob/xilinx-v2019.1/lib/crc32.c#L172
This is upstream mailing list that's why you should be using upstream code not soc vendor tree. That's why only my recommendation is to update your SW to latest and try. If the same problem is still there than it is time to deal with it.
Thanks, Michal