[EXT] fsl_hash.c: Alignment problem when using caam_hash() for FIT images

Stefan Roese sr at denx.de
Fri Apr 29 15:26:03 CEST 2022


On 4/29/22 15:22, Gaurav Jain wrote:
> Hello Stefan
> 
>> -----Original Message-----
>> From: Stefan Roese <sr at denx.de>
>> Sent: Friday, April 29, 2022 6:24 PM
>> To: U-Boot Mailing List <u-boot at lists.denx.de>
>> Cc: Gaurav Jain <gaurav.jain at nxp.com>; 'dullfire at yahoo.com
>> Subject: [EXT] fsl_hash.c: Alignment problem when using caam_hash() for FIT
>> images
>>
>> Caution: EXT Email
>>
>> Hi,
>>
>> while working on an LX2160 based board and updating to latest mainline I
>> noticed problems using the HW accelerated hash functions on this platform,
>> when trying to boot a FIT Kernel image. Here the resulting error message:
>>
>> ## Loading kernel from FIT Image at a0000000 ...
>>      Using 'conf-freescale_lx2160a.dtb' configuration
>>      Trying 'kernel-1' kernel subimage
>>      Verifying Hash Integrity ... sha256Error: Address arguments are not aligned
>> CAAM was not setup properly or it is faulty
>>    error!
>> Bad hash value for 'hash-1' hash node in 'kernel-1' image node Bad Data Hash
>> ERROR: can't get kernel image!
>>
>> And here the addresses, printed from caam_hash():
>> caam_hash (171): pbuf=00000000a00000fc pout=00000000fbde6f80
>> buf_len=5291241 ARCH_DMA_MINALIGN=64
>>
>> pbuf points to an area in the FIT image itself. So its not easy to change this.
>>
>> In some quick tests I've dropped the alignment check and have not seen any
>> problems yet. The hash is calculated without any problems and seems to be okay.
>> I might be just lucky though, not sure.
>>
>> So my basic question is: Is this alignment really necessary and required for both
>> addresses in this function?
> You are right, Alignment is not necessary and can be removed.

Perfect, thanks. Let me generate a patch for this. Stay tuned... ;)

Thanks,
Stefan

>>
>> If yes, do you have some suggestions on how to handle this? Other than
>> allocating new aligned buffers in caam_hash() and memcpy'ing to those new
>> buffers instead. BTW, this is not a preferred solution for me, as boot-time is
>> crucial for my platform.
>>
>> Thanks,
>> Stefan

Viele Grüße,
Stefan Roese

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr at denx.de


More information about the U-Boot mailing list