Hello Andrey
There is a patch in review related caam hash.
Please check if it fixes your problem.
http://patchwork.ozlabs.org/project/uboot/patch/20220616101009.809953-1-gaurav.j...@nxp.com/
Regards
Gaurav Jain
> -----Original Message-----
> From: ZHIZHIKIN Andrey <andrey.zhizhi...@leica-geosystems.com>
> Sent: Friday, July 15, 2022 6:11 PM
> To: Gaurav Jain <gaurav.j...@nxp.com>
> Cc: u-boot@lists.denx.de; feste...@denx.de; sba...@denx.de; Michael
> Walle <mich...@walle.cc>; Tommaso Merciai
> <tommaso.merc...@amarulasolutions.com>; Michael Trimarchi
> <mich...@amarulasolutions.com>; Marek Vasut <ma...@denx.de>; Simon
> Glass <s...@chromium.org>; Patrick Delaunay
> <patrick.delau...@foss.st.com>; Stefan Roese <s...@denx.de>; Horia Geanta
> <horia.gea...@nxp.com>; Pankaj Gupta <pankaj.gu...@nxp.com>; Varun
> Sethi <v.se...@nxp.com>; Ye Li <ye...@nxp.com>; dl-uboot-imx <uboot-
> i...@nxp.com>
> Subject: [EXT] [REGRESSION]: v2022.07: SHA256 hash is broken on imx8m
> series with CAAM enabled
>
> Caution: EXT Email
>
> Hello Gaurav,
>
> In the new v2022.07, I've stumbled upon the issue with calculating the
> SHA256 of memory blocks with CAAM hashing. This causes the FIT image not
> to pass the hash validation, and also `sha256` command not operable.
>
> I'm also wondering if any i.MX8M-based board maintainers have seen the
> same issues at their end?
>
> I've made a small test executing the following command sequence (with
> corresponding serial output):
>
> U-Boot 2022.07 (Jul 15 2022 - 14:36:00 +0200)
>
> CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz
> Reset cause: POR
> Model: FSL i.MX8MM EVK board
> DRAM: 2 GiB
> Core: 153 devices, 19 uclasses, devicetree: separate
> WDT: Started watchdog@30280000 with servicing (60s timeout)
> MMC: FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
>
> In: serial@30890000
> Out: serial@30890000
> Err: serial@30890000
> SEC0: RNG instantiated
> Net: eth0: ethernet@30be0000
> Hit any key to stop autoboot: 0
> u-boot=> mw.b ${kernel_addr_r} DE 100
> u-boot=> md.b ${kernel_addr_r} 100
> 40480000: dededede dededede dededede dededede ................
> 40480010: dededede dededede dededede dededede ................
> 40480020: dededede dededede dededede dededede ................
> 40480030: dededede dededede dededede dededede ................
> 40480040: dededede dededede dededede dededede ................
> 40480050: dededede dededede dededede dededede ................
> 40480060: dededede dededede dededede dededede ................
> 40480070: dededede dededede dededede dededede ................
> 40480080: dededede dededede dededede dededede ................
> 40480090: dededede dededede dededede dededede ................
> 404800a0: dededede dededede dededede dededede ................
> 404800b0: dededede dededede dededede dededede ................
> 404800c0: dededede dededede dededede dededede ................
> 404800d0: dededede dededede dededede dededede ................
> 404800e0: dededede dededede dededede dededede ................
> 404800f0: dededede dededede dededede dededede ................
>
> u-boot=> hash sha256 ${kernel_addr_r} 100 CAAM was not setup properly or
> it is faulty
> sha256 for 40480000 ... 404800ff ==>
> 736372697074616464727d0a626f6f745f6566695f62696e6172793d6c6f6164
>
> Running `sha256` commands several times in a row also produces different
> Results, sometimes it comes out as all 0's.
>
> For comparison purposes, I've did similar on the desktop:
> $ while true ; do printf "\xDE"; done | dd of=./test_data bs=1 count=256
> 256+0 records in
> 256+0 records out
> 256 bytes copied, 0.000484 s, 529 kB/s
>
> $ hexdump -C -v ./test_data
> 00000000 de de de de de de de de de de de de de de de de |................|
> 00000010 de de de de de de de de de de de de de de de de |................|
> 00000020 de de de de de de de de de de de de de de de de |................|
> 00000030 de de de de de de de de de de de de de de de de |................|
> 00000040 de de de de de de de de de de de de de de de de |................|
> 00000050 de de de de de de de de de de de de de de de de |................|
> 00000060 de de de de de de de de de de de de de de de de |................|
> 00000070 de de de de de de de de de de de de de de de de |................|
> 00000080 de de de de de de de de de de de de de de de de |................|
> 00000090 de de de de de de de de de de de de de de de de |................|
> 000000a0 de de de de de de de de de de de de de de de de |................|
> 000000b0 de de de de de de de de de de de de de de de de |................|
> 000000c0 de de de de de de de de de de de de de de de de |................|
> 000000d0 de de de de de de de de de de de de de de de de |................|
> 000000e0 de de de de de de de de de de de de de de de de |................|
> 000000f0 de de de de de de de de de de de de de de de de |................|
> 00000100
>
> $ sha256sum ./test_data
> 8b11bcdc65d5f1af0fa1edfa7b5db089dba40d4e8d29b455295d58ab2b314e76
> ./test_data
>
> As one can see, the SHA256 has a totally different value, with desktop
> produces a rather correct one.
>
> Since the CAAM is enabled per default for all i.MX8M derivatives, there is no
> way to target SHA hash calculations back to SW implementation, therefore it
> blocks a lot of people to boot FIT images that has `hash` nodes in them.
>
> Looking a bit deeper into why it fails, I saw that the JR used for hash
> calculations is hard-coded to `0` in run_descriptor_jr() call, which is now
> reserved in S-World for HAB operations. But changing it to `1` did not change
> the behavior, the SHA256 is still not calculated proper.
>
> Can you please advise how this can be solved?
>
> And more conceptually: why is SHA hashing now hardwired to HW CAAM
> module, while it was perfectly executed in SW via `lib/sha.c`?
>
> Thanks a lot!
>
> Regards,
> Andrey
