CRC32 endianess

[Michal Simek]

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

-- 
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