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-...@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
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
