[PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()

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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Signed-off-by: Stefan Roese sr@denx.de Cc: Gaurav Jain gaurav.jain@nxp.com Cc: dullfire@yahoo.com --- drivers/crypto/fsl/fsl_hash.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/drivers/crypto/fsl/fsl_hash.c b/drivers/crypto/fsl/fsl_hash.c index a52c4ac957e0..0a371bffd5eb 100644 --- a/drivers/crypto/fsl/fsl_hash.c +++ b/drivers/crypto/fsl/fsl_hash.c @@ -168,12 +168,6 @@ int caam_hash(const unsigned char *pbuf, unsigned int buf_len, uint32_t *desc; unsigned int size;
- if (!IS_ALIGNED((uintptr_t)pbuf, ARCH_DMA_MINALIGN) || - !IS_ALIGNED((uintptr_t)pout, ARCH_DMA_MINALIGN)) { - puts("Error: Address arguments are not aligned\n"); - return -EINVAL; - } - desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE); if (!desc) { debug("Not enough memory for descriptor allocation\n");

Reviewed-by: Gaurav Jain gaurav.jain@nxp.com
-----Original Message----- From: Stefan Roese sr@denx.de Sent: Friday, April 29, 2022 7:05 PM To: u-boot@lists.denx.de Cc: Gaurav Jain gaurav.jain@nxp.com; dullfire@yahoo.com Subject: [EXT] [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Caution: EXT Email
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Signed-off-by: Stefan Roese sr@denx.de Cc: Gaurav Jain gaurav.jain@nxp.com Cc: dullfire@yahoo.com
drivers/crypto/fsl/fsl_hash.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/drivers/crypto/fsl/fsl_hash.c b/drivers/crypto/fsl/fsl_hash.c index a52c4ac957e0..0a371bffd5eb 100644 --- a/drivers/crypto/fsl/fsl_hash.c +++ b/drivers/crypto/fsl/fsl_hash.c @@ -168,12 +168,6 @@ int caam_hash(const unsigned char *pbuf, unsigned int buf_len, uint32_t *desc; unsigned int size;
if (!IS_ALIGNED((uintptr_t)pbuf, ARCH_DMA_MINALIGN) ||
!IS_ALIGNED((uintptr_t)pout, ARCH_DMA_MINALIGN)) {
puts("Error: Address arguments are not aligned\n");
return -EINVAL;
}
desc = malloc_cache_aligned(sizeof(int) * MAX_CAAM_DESCSIZE); if (!desc) { debug("Not enough memory for descriptor allocation\n");
-- 2.32.0

On 29/04/2022 15.34, Stefan Roese wrote:
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Any chance this could make it into 2022.07?
Rasmus

On Mon, Jun 06, 2022 at 07:43:52PM +0200, Rasmus Villemoes wrote:
On 29/04/2022 15.34, Stefan Roese wrote:
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Any chance this could make it into 2022.07?
I've put this in my -rc5 queue now.

Hi Stefan,
On Fri, Apr 29, 2022 at 10:35 AM Stefan Roese sr@denx.de wrote:
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Signed-off-by: Stefan Roese sr@denx.de Cc: Gaurav Jain gaurav.jain@nxp.com Cc: dullfire@yahoo.com
I applied this patch against top of tree U-Boot, but I am still getting the following error on a kontron-sl-mx8mm board with the options below selected:
CONFIG_IMX_HAB=y CONFIG_SPL_DRIVERS_MISC=y
### Loading kernel from FIT Image at 42000000 ... Using 'conf-freescale_imx8mm-kontron-n801x-s.dtb' configuration Trying 'kernel-1' kernel subimage Description: Linux kernel Created: 2022-06-07 1:58:57 UTC Type: Kernel Image Compression: gzip compressed Data Start: 0x42000100 Data Size: 7609360 Bytes = 7.3 MiB Architecture: AArch64 OS: Linux Load Address: 0x40480000 Entry Point: 0x40480000 Hash algo: sha256 Hash value: d20b5d533e123096edb05a6433d850c0fafb4b39a6e6d47e9bade3f6fa7c26ce Verifying Hash Integrity ... sha256dev_get_priv: null device 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!
Not sure why dev_get_priv is returning NULL.
I am using the TF-A from NXP: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4
If CONFIG_IMX_HAB=y is not selected, then sha256 is calculated by software and the fitImage boots.
Does anyone have any suggestions?
Thanks,
Fabio Estevam

Hi Fabio,
Am Di., 7. Juni 2022 um 04:41 Uhr schrieb Fabio Estevam festevam@gmail.com:
Hi Stefan,
On Fri, Apr 29, 2022 at 10:35 AM Stefan Roese sr@denx.de wrote:
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Signed-off-by: Stefan Roese sr@denx.de Cc: Gaurav Jain gaurav.jain@nxp.com Cc: dullfire@yahoo.com
I applied this patch against top of tree U-Boot, but I am still getting the following error on a kontron-sl-mx8mm board with the options below selected:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
CONFIG_IMX_HAB=y CONFIG_SPL_DRIVERS_MISC=y
### Loading kernel from FIT Image at 42000000 ... Using 'conf-freescale_imx8mm-kontron-n801x-s.dtb' configuration Trying 'kernel-1' kernel subimage Description: Linux kernel Created: 2022-06-07 1:58:57 UTC Type: Kernel Image Compression: gzip compressed Data Start: 0x42000100 Data Size: 7609360 Bytes = 7.3 MiB Architecture: AArch64 OS: Linux Load Address: 0x40480000 Entry Point: 0x40480000 Hash algo: sha256 Hash value: d20b5d533e123096edb05a6433d850c0fafb4b39a6e6d47e9bade3f6fa7c26ce Verifying Hash Integrity ... sha256dev_get_priv: null device 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!
Not sure why dev_get_priv is returning NULL.
I am using the TF-A from NXP: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4
If CONFIG_IMX_HAB=y is not selected, then sha256 is calculated by software and the fitImage boots.
Does anyone have any suggestions?
Thanks,
Fabio Estevam

Sorry for the typo in the mailadress.
Heiko Thiery heiko.thiery@gmail.com schrieb am Di., 7. Juni 2022, 09:44:
Hi Fabio,
Am Di., 7. Juni 2022 um 04:41 Uhr schrieb Fabio Estevam < festevam@gmail.com>:
Hi Stefan,
On Fri, Apr 29, 2022 at 10:35 AM Stefan Roese sr@denx.de wrote:
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Signed-off-by: Stefan Roese sr@denx.de Cc: Gaurav Jain gaurav.jain@nxp.com Cc: dullfire@yahoo.com
I applied this patch against top of tree U-Boot, but I am still getting the following error on a kontron-sl-mx8mm board with the options below selected:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
CONFIG_IMX_HAB=y CONFIG_SPL_DRIVERS_MISC=y
### Loading kernel from FIT Image at 42000000 ... Using 'conf-freescale_imx8mm-kontron-n801x-s.dtb' configuration Trying 'kernel-1' kernel subimage Description: Linux kernel Created: 2022-06-07 1:58:57 UTC Type: Kernel Image Compression: gzip compressed Data Start: 0x42000100 Data Size: 7609360 Bytes = 7.3 MiB Architecture: AArch64 OS: Linux Load Address: 0x40480000 Entry Point: 0x40480000 Hash algo: sha256 Hash value: d20b5d533e123096edb05a6433d850c0fafb4b39a6e6d47e9bade3f6fa7c26ce Verifying Hash Integrity ... sha256dev_get_priv: null device 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!
Not sure why dev_get_priv is returning NULL.
I am using the TF-A from NXP: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4
If CONFIG_IMX_HAB=y is not selected, then sha256 is calculated by software and the fitImage boots.
Does anyone have any suggestions?
Thanks,
Fabio Estevam

Hi Heiko,
On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery heiko.thiery@gmail.com wrote:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
Thanks for the feedback.
I managed to reproduce the problem on an imx8mm-evk board.
On top of tree U-Boot I added:
--- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_IMX_HAB=y
Then I try to load the fitImage and the sha256 calculation via CAAM fails:
U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 -0300) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from MMC1 hab fuse not enabled
Authenticate image from DDR location 0x401fcdc0... bad magic magic=0x0 length=0x00 version=0x0 bad length magic=0x0 length=0x00 version=0x0 bad version magic=0x0 length=0x00 version=0x0 Error: Invalid IVT structure NOTICE: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6 NOTICE: BL31: Built : 14:12:35, Jun 7 2022
U-Boot 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 -0300)
CPU: Freescale i.MX8MMQ rev1.0 at 1200 MHz Reset cause: POR Model: FSL i.MX8MM EVK board DRAM: 2 GiB Core: 154 devices, 20 uclasses, devicetree: separate WDT: Started watchdog@30280000 with servicing (60s timeout) MMC: FSL_SDHC: 1, FSL_SDHC: 2 Loading Environment from MMC... OK 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=> setenv autoload no u-boot=> dhcp u-boot=> tftp fitImage Using ethernet@30be0000 device TFTP from server 192.168.0.16; our IP address is 192.168.0.41 Filename 'fitImage'. Load address: 0x40480000 Loading: ################################################################# ################################################################# .... 4.3 MiB/s done Bytes transferred = 36320884 (22a3674 hex) u-boot=> bootm ${loadaddr} ## Loading kernel from FIT Image at 40480000 ... Using 'conf-freescale_imx8mm-kontron-n801x-s.dtb' configuration Trying 'kernel-1' kernel subimage Description: Linux kernel Type: Kernel Image Compression: gzip compressed Data Start: 0x40480100 Data Size: 7609360 Bytes = 7.3 MiB Architecture: AArch64 OS: Linux Load Address: 0x40480000 Entry Point: 0x40480000 Hash algo: sha256 Hash value: d20b5d533e123096edb05a6433d850c0fafb4b39a6e6d47e9bade3f6fa7c26ce Verifying Hash Integrity ... sha256CAAM 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!
Peng, Ye Li, Gaurav,
Any suggestions?
Thanks

On Tue, Jun 7, 2022 at 2:27 PM Fabio Estevam festevam@gmail.com wrote:
Hi Heiko,
On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery heiko.thiery@gmail.com wrote:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
Thanks for the feedback.
I managed to reproduce the problem on an imx8mm-evk board.
On top of tree U-Boot I added:
--- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_IMX_HAB=y
Then I try to load the fitImage and the sha256 calculation via CAAM fails:
U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 -0300) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from MMC1 hab fuse not enabled
Authenticate image from DDR location 0x401fcdc0... bad magic magic=0x0 length=0x00 version=0x0 bad length magic=0x0 length=0x00 version=0x0 bad version magic=0x0 length=0x00 version=0x0 Error: Invalid IVT structure NOTICE: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6
The problem seems to be related to the TF-A version.
If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via CAAM does not fail.
Regards,
Fabio Estevam

Hi Fabio
-----Original Message----- From: Fabio Estevam festevam@gmail.com Sent: Wednesday, June 8, 2022 4:20 AM To: Heiko Thiery heiko.thiery@gmail.com Cc: Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; Gaurav Jain gaurav.jain@nxp.com; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; ZHIZHIKIN Andrey <andrey.zhizhikin@leica- geosystems.com>; Horia Geanta horia.geanta@nxp.com; Thomas Schäfer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Caution: EXT Email
On Tue, Jun 7, 2022 at 2:27 PM Fabio Estevam festevam@gmail.com wrote:
Hi Heiko,
On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery heiko.thiery@gmail.com wrote:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
Thanks for the feedback.
I managed to reproduce the problem on an imx8mm-evk board.
On top of tree U-Boot I added:
--- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y
CONFIG_SYSRESET_WATCHDOG=y
CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_IMX_HAB=y
Then I try to load the fitImage and the sha256 calculation via CAAM fails:
U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 -0300) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from MMC1 hab fuse not enabled
Authenticate image from DDR location 0x401fcdc0... bad magic magic=0x0 length=0x00 version=0x0 bad length magic=0x0 length=0x00 version=0x0 bad version magic=0x0 length=0x00 version=0x0 Error: Invalid IVT structure NOTICE: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6
The problem seems to be related to the TF-A version.
If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via CAAM does not fail.
I think you are right. Patch submitted in TFA for not releasing JR0 to non-secure which is causing this issue. https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?h=refs/h...
I will share a patch for switching to JR1 in uboot.
Regards Gaurav Jain
Regards,
Fabio Estevam

Hello Gaurav,
-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Gaurav Jain Sent: Wednesday, June 8, 2022 7:45 AM To: Fabio Estevam festevam@gmail.com; Heiko Thiery heiko.thiery@gmail.com Cc: Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; ZHIZHIKIN Andrey <andrey.zhizhikin@leica- geosystems.com>; Horia Geanta horia.geanta@nxp.com; Thomas Schäfer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: RE: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Hi Fabio
-----Original Message----- From: Fabio Estevam festevam@gmail.com Sent: Wednesday, June 8, 2022 4:20 AM To: Heiko Thiery heiko.thiery@gmail.com Cc: Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; Gaurav Jain gaurav.jain@nxp.com; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; ZHIZHIKIN Andrey <andrey.zhizhikin@leica- geosystems.com>; Horia Geanta horia.geanta@nxp.com; Thomas Schäfer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Caution: EXT Email
On Tue, Jun 7, 2022 at 2:27 PM Fabio Estevam festevam@gmail.com wrote:
Hi Heiko,
On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery heiko.thiery@gmail.com wrote:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
Thanks for the feedback.
I managed to reproduce the problem on an imx8mm-evk board.
On top of tree U-Boot I added:
--- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y
CONFIG_SYSRESET_WATCHDOG=y
CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_IMX_HAB=y
Then I try to load the fitImage and the sha256 calculation via CAAM fails:
U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 -0300) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from MMC1 hab fuse not enabled
Authenticate image from DDR location 0x401fcdc0... bad magic magic=0x0 length=0x00 version=0x0 bad length magic=0x0 length=0x00 version=0x0 bad version magic=0x0 length=0x00 version=0x0 Error: Invalid IVT structure NOTICE: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6
The problem seems to be related to the TF-A version.
If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via CAAM does not fail.
I think you are right. Patch submitted in TFA for not releasing JR0 to non- secure which is causing this issue. https://git.trustedfirmware.org/TF-A/trusted-firmware- a.git/commit/?h=refs/heads/integration&id=77850c96f23bcdc76ecb0ecd27a982c00fde5d9 d
I believe that Fabio used NXP TF-A for booting, while you're referring to upstream TF-A commit.
Coming back to our discussion that we had with CAAM support series, which JRs are now used for which purposes? Does upstream TF-A (so as NXP TF-A) reserves JR0 for HAB operations, hence JR1 is required in U-Boot for crypto operations?
Is it possible that you provide a clear picture of JR reservations in all combinations of SPL -> TF-A (upstream or NXP) -> U-Boot?
I will share a patch for switching to JR1 in uboot.
Regards Gaurav Jain
Regards,
Fabio Estevam
Regards, Andrey

Hi Andrey
-----Original Message----- From: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Sent: Wednesday, June 8, 2022 11:59 AM To: Gaurav Jain gaurav.jain@nxp.com; Fabio Estevam festevam@gmail.com; Heiko Thiery heiko.thiery@gmail.com Cc: Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; Horia Geanta horia.geanta@nxp.com; Thomas Schäfer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: RE: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Caution: EXT Email
Hello Gaurav,
-----Original Message----- From: U-Boot u-boot-bounces@lists.denx.de On Behalf Of Gaurav Jain Sent: Wednesday, June 8, 2022 7:45 AM To: Fabio Estevam festevam@gmail.com; Heiko Thiery heiko.thiery@gmail.com Cc: Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; ZHIZHIKIN Andrey <andrey.zhizhikin@leica- geosystems.com>; Horia Geanta horia.geanta@nxp.com; Thomas Schäfer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: RE: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Hi Fabio
-----Original Message----- From: Fabio Estevam festevam@gmail.com Sent: Wednesday, June 8, 2022 4:20 AM To: Heiko Thiery heiko.thiery@gmail.com Cc: Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; Gaurav Jain gaurav.jain@nxp.com; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; ZHIZHIKIN Andrey <andrey.zhizhikin@leica- geosystems.com>; Horia Geanta horia.geanta@nxp.com; Thomas Schäfer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: [EXT] Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Caution: EXT Email
On Tue, Jun 7, 2022 at 2:27 PM Fabio Estevam festevam@gmail.com
wrote:
Hi Heiko,
On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery heiko.thiery@gmail.com
wrote:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
Thanks for the feedback.
I managed to reproduce the problem on an imx8mm-evk board.
On top of tree U-Boot I added:
--- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y
CONFIG_SYSRESET_WATCHDOG=y
CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_IMX_HAB=y
Then I try to load the fitImage and the sha256 calculation via CAAM fails:
U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 -0300) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from MMC1 hab fuse not enabled
Authenticate image from DDR location 0x401fcdc0... bad magic magic=0x0 length=0x00 version=0x0 bad length magic=0x0 length=0x00 version=0x0 bad version magic=0x0 length=0x00 version=0x0 Error: Invalid IVT structure NOTICE: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6
The problem seems to be related to the TF-A version.
If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via CAAM does not fail.
I think you are right. Patch submitted in TFA for not releasing JR0 to non- secure which is causing this issue. https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit. trustedfirmware.org%2FTF-A%2Ftrusted-firmware-
&data=05%7C01%7Cgaur
av.jain%40nxp.com%7C66e72d1fa9af4624495908da49182e1f%7C686ea1d3bc2 b4c6
fa92cd99c5c301635%7C0%7C0%7C637902665441907174%7CUnknown%7CTW FpbGZsb3d
8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D %7C
3000%7C%7C%7C&sdata=iv3BrTHm0YbCk0hDv9GJck0MMmv4yNJxPKSzytU tl20%3D
&reserved=0 a.git/commit/?h=refs/heads/integration&id=77850c96f23bcdc76ecb0ecd27a9 82c00fde5d9 d
I believe that Fabio used NXP TF-A for booting, while you're referring to upstream TF-A commit.
Ok. But I can see the commit for reserving JR0 is merged as 77850c96f23bcdc76ecb0ecd27a982c00fde5d9d in TF-A.
Coming back to our discussion that we had with CAAM support series, which JRs are now used for which purposes? Does upstream TF-A (so as NXP TF-A) reserves JR0 for HAB operations, hence JR1 is required in U-Boot for crypto operations?
Yes upstream TF-A reserving JRO for HAB, so JR1 needed in U-Boot.
Is it possible that you provide a clear picture of JR reservations in all combinations of SPL -> TF-A (upstream or NXP) -> U-Boot?
If we mark JRO status as disabled then SPL will also use JR1, as the caam driver is same for SPL and U-Boot. JR0 -> reserved for HAB in TF-A JR1 -> release to non-secure(U-Boot, kernel) JR2 -> reserved for OPTEE
Regards Gaurav Jain
I will share a patch for switching to JR1 in uboot.
Regards Gaurav Jain
Regards,
Fabio Estevam
Regards, Andrey

Hello Fabio et al.,
-----Original Message----- From: Fabio Estevam festevam@gmail.com Sent: Wednesday, June 8, 2022 12:50 AM To: Heiko Thiery heiko.thiery@gmail.com Cc: Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; Gaurav Jain gaurav.jain@nxp.com; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com; Horia Geanta Neag horia.geanta@nxp.com; Thomas Schaefer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
On Tue, Jun 7, 2022 at 2:27 PM Fabio Estevam festevam@gmail.com wrote:
Hi Heiko,
On Tue, Jun 7, 2022 at 4:48 AM Heiko Thiery heiko.thiery@gmail.com wrote:
Thomas Schäfer sees this behavior also on an imx8mn NXP evk board. Thus I added him to this thread.
Thanks for the feedback.
I managed to reproduce the problem on an imx8mm-evk board.
On top of tree U-Boot I added:
--- a/configs/imx8mm_evk_defconfig +++ b/configs/imx8mm_evk_defconfig @@ -87,3 +87,4 @@ CONFIG_SYSRESET_PSCI=y CONFIG_SYSRESET_WATCHDOG=y CONFIG_DM_THERMAL=y CONFIG_IMX_WATCHDOG=y +CONFIG_IMX_HAB=y
Then I try to load the fitImage and the sha256 calculation via CAAM fails:
U-Boot SPL 2022.07-rc3-00093-g7d3acf08ec60-dirty (Jun 07 2022 - 14:20:02 -0300) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from MMC1 hab fuse not enabled
Authenticate image from DDR location 0x401fcdc0... bad magic magic=0x0 length=0x00 version=0x0 bad length magic=0x0 length=0x00 version=0x0 bad version magic=0x0 length=0x00 version=0x0 Error: Invalid IVT structure NOTICE: BL31: v2.4(release):lf-5.15.5-1.0.0-10-gcb51a0faa4b6
The problem seems to be related to the TF-A version.
If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via CAAM does not fail.
I just tried the imx8mp_evk and with CONFIG_IMX_HAB=y the board does not pass the SPL.
I used the upstream TF-A for my build, without HAB support enabled the board boots: ---- U-Boot SPL 2022.07-rc4-00003-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from BOOTROM image offset 0x8000, pagesize 0x200, ivt offset 0x0 NOTICE: BL31: v2.7(release):v2.7.0-17-g65a5e1c04-dirty NOTICE: BL31: Built : 06:19:26, Jun 8 2022
U-Boot 2022.07-rc4-00003-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200)
CPU: Freescale i.MX8MP[8] rev1.0 at 1200 MHz Reset cause: POR Model: NXP i.MX8MPlus EVK board DRAM: 6 GiB Core: 176 devices, 22 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, eth1: ethernet@30bf0000 [PRIME] Hit any key to stop autoboot: 0 u-boot=> ----
When HAB in enabled, the only thing that can be observed in the console is: ---- U-Boot SPL 2022.07-rc4-00003-g9eca6cc66a-dirty (Jun 08 2022 - 09:40:52 +0200) ----
I believe there is a common problem with the CAAM configuration here and usage of HAB, perhaps due to JR reservations.
Gaurav,
Can you please advise on what could be causing this behavior on i.MX8MP?
Thanks a lot!
Regards,
Fabio Estevam
-- andrey

Hi Andrey,
On Wed, Jun 8, 2022 at 4:46 AM ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com wrote:
The problem seems to be related to the TF-A version.
If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via CAAM does not fail.
I just tried the imx8mp_evk and with CONFIG_IMX_HAB=y the board does not pass the SPL.
I used the upstream TF-A for my build, without HAB support enabled the board boots:
U-Boot SPL 2022.07-rc4-00003-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from BOOTROM image offset 0x8000, pagesize 0x200, ivt offset 0x0 NOTICE: BL31: v2.7(release):v2.7.0-17-g65a5e1c04-dirty NOTICE: BL31: Built : 06:19:26, Jun 8 2022
U-Boot 2022.07-rc4-00003-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200)
CPU: Freescale i.MX8MP[8] rev1.0 at 1200 MHz Reset cause: POR Model: NXP i.MX8MPlus EVK board DRAM: 6 GiB Core: 176 devices, 22 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, eth1: ethernet@30bf0000 [PRIME] Hit any key to stop autoboot: 0 u-boot=>
When HAB in enabled, the only thing that can be observed in the console is:
U-Boot SPL 2022.07-rc4-00003-g9eca6cc66a-dirty (Jun 08 2022 - 09:40:52 +0200)
My understanding, at least for the i.MX8MM case, is that mainline TF-A does not support HAB, so the NXP TF-A should be used if HAB support is required.
Please check: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.o...
Does the board boot with IMX_HAB=y with NXP TF-A?
Regards,
Fabio Estevam

Hello Fabio,
-----Original Message----- From: Fabio Estevam festevam@gmail.com Sent: Wednesday, June 8, 2022 2:14 PM To: ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com Cc: Heiko Thiery heiko.thiery@gmail.com; Stefan Roese sr@denx.de; U-Boot-Denx u-boot@lists.denx.de; Gaurav Jain gaurav.jain@nxp.com; dullfire@yahoo.com; Rasmus Villemoes rasmus.villemoes@prevas.dk; Schrempf Frieder frieder.schrempf@kontron.de; Horia Geanta Neag horia.geanta@nxp.com; Thomas Schaefer thomas.schaefer@kontron.com; Ye Li ye.li@nxp.com; Peng Fan peng.fan@nxp.com Subject: Re: [PATCH] crypto: fsl_hash: Remove unnecessary alignment check in caam_hash()
Hi Andrey,
On Wed, Jun 8, 2022 at 4:46 AM ZHIZHIKIN Andrey andrey.zhizhikin@leica-geosystems.com wrote:
The problem seems to be related to the TF-A version.
If I use the older imx_5.4.47_2.2.0 TF-A then the sha256 calculation via CAAM does not fail.
I just tried the imx8mp_evk and with CONFIG_IMX_HAB=y the board does not pass the SPL.
I used the upstream TF-A for my build, without HAB support enabled the board boots:
U-Boot SPL 2022.07-rc4-00003-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200) SEC0: RNG instantiated Normal Boot WDT: Started watchdog@30280000 with servicing (60s timeout) Trying to boot from BOOTROM image offset 0x8000, pagesize 0x200, ivt offset 0x0 NOTICE: BL31: v2.7(release):v2.7.0-17-g65a5e1c04-dirty NOTICE: BL31: Built : 06:19:26, Jun 8 2022
U-Boot 2022.07-rc4-00003-g9eca6cc66a (Jun 08 2022 - 08:21:41 +0200)
CPU: Freescale i.MX8MP[8] rev1.0 at 1200 MHz Reset cause: POR Model: NXP i.MX8MPlus EVK board DRAM: 6 GiB Core: 176 devices, 22 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, eth1: ethernet@30bf0000 [PRIME] Hit any key to stop autoboot: 0 u-boot=>
When HAB in enabled, the only thing that can be observed in the console is:
U-Boot SPL 2022.07-rc4-00003-g9eca6cc66a-dirty (Jun 08 2022 - 09:40:52 +0200)
My understanding, at least for the i.MX8MM case, is that mainline TF-A does not support HAB, so the NXP TF-A should be used if HAB support is required.
Please check: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.o...
Thanks for the hint!
That would be understandable, but I would at least be expecting to have some error messages. But I do not get any - the board just does not pass SPL at all, as like SEC0 hangs during RNG instantiation (my rough speculations here).
Does the board boot with IMX_HAB=y with NXP TF-A?
Nope, unfortunately also not. Once HAB config is enabled on the i.MX8MP - the board does not pass the SPL, even with NXP TF-A.
Regards,
Fabio Estevam
-- andrey

On Fri, Apr 29, 2022 at 10:35 AM Stefan Roese sr@denx.de wrote:
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Signed-off-by: Stefan Roese sr@denx.de Cc: Gaurav Jain gaurav.jain@nxp.com Cc: dullfire@yahoo.com
I applied this patch against top of tree U-Boot, but I am still getting the following error on a kontron-sl-mx8mm board with the options below selected:
CONFIG_IMX_HAB=y CONFIG_SPL_DRIVERS_MISC=y
### Loading kernel from FIT Image at 42000000 ... Using 'conf-freescale_imx8mm-kontron-n801x-s.dtb' configuration Trying 'kernel-1' kernel subimage Description: Linux kernel Created: 2022-06-07 1:58:57 UTC Type: Kernel Image Compression: gzip compressed Data Start: 0x42000100 Data Size: 7609360 Bytes = 7.3 MiB Architecture: AArch64 OS: Linux Load Address: 0x40480000 Entry Point: 0x40480000 Hash algo: sha256 Hash value: d20b5d533e123096edb05a6433d850c0fafb4b39a6e6d47e9bade3f6fa7c26ce Verifying Hash Integrity ... sha256dev_get_priv: null device
Hi Fabio, I had the very same problem/error on i.MX6 and figured out that CONFIG_ARCH_MISC_INIT=y must be enabled otherwise the caam_jr driver is not initialized.
I also tried this patch. Now the caam_hash() returns OK and I can boot the board but I am still seeing a warning regarding wrong alignment from cache lib:
=> bootm 12000000#conf-4 ## Loading kernel from FIT Image at 12000000 ... Using 'conf-4' configuration Verifying Hash Integrity ... OK Trying 'kernel' kernel subimage Description: Kernel Type: Kernel Image Compression: uncompressed Data Start: 0x120000dc Data Size: 2901024 Bytes = 2.8 MiB Architecture: ARM OS: Linux Load Address: 0x10800000 Entry Point: 0x10800000 Hash algo: sha256 Hash value: a3343f1df615f14677176ea4966644fcaa25b31bd3808682567b7fedf704cfb8 Verifying Hash Integrity ... sha256CACHE: Misaligned operation at range [120000dc, 122c451c] + OK ## Loading fdt from FIT Image at 12000000 ... Using 'conf-4' configuration Verifying Hash Integrity ... OK Trying 'fdt-4' fdt subimage Description: Orion Flattened Device Tree blob Type: Flat Device Tree Compression: uncompressed Data Start: 0x122c4604 Data Size: 41038 Bytes = 40.1 KiB Architecture: ARM Load Address: 0x18000000 Hash algo: sha256 Hash value: 13e0b23bd49f9e86a0425080fc788db67bf318d6f103f217d5705a455737e91c Verifying Hash Integrity ... sha256CACHE: Misaligned operation at range [122c4604, 122ce684] + OK Loading fdt from 0x122c4604 to 0x18000000 Booting using the fdt blob at 0x18000000 Loading Kernel Image Using Device Tree in place at 18000000, end 1800d04d
Starting kernel ...
Michal

Hi Michal,
On Fri, Jun 10, 2022 at 7:02 AM Michal Vokáč michal.vokac@ysoft.com wrote:
Hi Fabio, I had the very same problem/error on i.MX6 and figured out that CONFIG_ARCH_MISC_INIT=y must be enabled otherwise the caam_jr driver is not initialized.
Yes, correct. There is a patch from Gaurav to address this: https://lists.denx.de/pipermail/u-boot/2022-June/485959.html
Hash algo: sha256 Hash value: 13e0b23bd49f9e86a0425080fc788db67bf318d6f103f217d5705a455737e91c Verifying Hash Integrity ... sha256CACHE: Misaligned operation at range [122c4604, 122ce684]
- OK Loading fdt from 0x122c4604 to 0x18000000 Booting using the fdt blob at 0x18000000 Loading Kernel Image Using Device Tree in place at 18000000, end 1800d04d
On a imx6sabresd the board simply hangs in SPL, when CONFIG_IMX_HAB=y: https://lists.denx.de/pipermail/u-boot/2022-June/485993.html
Does your board use SPL?
Regards,
Fabio Estevam

On 10. 06. 22 13:47, Fabio Estevam wrote:
[EXTERNAL EMAIL]
Hi Michal,
On Fri, Jun 10, 2022 at 7:02 AM Michal Vokáč michal.vokac@ysoft.com wrote:
Hi Fabio, I had the very same problem/error on i.MX6 and figured out that CONFIG_ARCH_MISC_INIT=y must be enabled otherwise the caam_jr driver is not initialized.
Yes, correct. There is a patch from Gaurav to address this: https://lists.denx.de/pipermail/u-boot/2022-June/485959.html
OK, thanks for the reference. It took me some time to reply to the thread and this patch came in the meantime.
Hash algo: sha256 Hash value: 13e0b23bd49f9e86a0425080fc788db67bf318d6f103f217d5705a455737e91c Verifying Hash Integrity ... sha256CACHE: Misaligned operation at range [122c4604, 122ce684]
- OK Loading fdt from 0x122c4604 to 0x18000000 Booting using the fdt blob at 0x18000000 Loading Kernel Image Using Device Tree in place at 18000000, end 1800d04d
On a imx6sabresd the board simply hangs in SPL, when CONFIG_IMX_HAB=y: https://lists.denx.de/pipermail/u-boot/2022-June/485993.html
Does your board use SPL?
Normally it does but I am not that far yet. We are in a process of upgrade from v2019.07 to the latest version and moving everything from the legacy support to the driver model etc. is quite challenging.
So far I am building just the non-SPL version and loading it over the NXP uuu tool to fail-fast.
I expect ton of new problems once I move to the SPL version :)
Regards, Michal

On Fri, Apr 29, 2022 at 03:34:44PM +0200, Stefan Roese wrote:
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:
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!
Testing and checking with Gaurav Jain from NXP has revealed, that this alignment check is not necessary here at all. So let's remove this check completely.
Signed-off-by: Stefan Roese sr@denx.de Cc: Gaurav Jain gaurav.jain@nxp.com Cc: dullfire@yahoo.com Reviewed-by: Gaurav Jain gaurav.jain@nxp.com
Applied to u-boot/master, thanks!
participants (8)
-
Fabio Estevam
-
Gaurav Jain
-
Heiko Thiery
-
Michal Vokáč
-
Rasmus Villemoes
-
Stefan Roese
-
Tom Rini
-
ZHIZHIKIN Andrey