[U-Boot] [PATCH v4 08/25] arm: imx: hab: Fix authenticate image lockup on MX7

2018-01-02 Thread Bryan O'Donoghue 
The i.MX6 has some pretty explicit code associated with informing the IROM
about flushing caches during authenticate_image().

Looking at various pieces of documentation its pretty clear the i.MX6 IROM
registers are not documented and absent similar documentation on the i.MX7
the next-best fix is to disabled the dcache while making an
authenticate_image() callback.

This patch therefore disables dcache temporarily while doing an IROM
authenticate_image() callback, thus resolving a lockup encountered in a
complex set of authenticate-image calls observed.

Note there is no appreciable performance impact with dcache switched off so
this fix is relatively pain-free.

Signed-off-by: Bryan O'Donoghue 
Cc: Stefano Babic 
Cc: Fabio Estevam 
Cc: Peng Fan 
Cc: Albert Aribaud 
Cc: Sven Ebenfeld 
Cc: George McCollister 
Cc: Breno Matheus Lima 
---
 arch/arm/mach-imx/hab.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/arch/arm/mach-imx/hab.c b/arch/arm/mach-imx/hab.c
index 2a40d06..1d7b069 100644
--- a/arch/arm/mach-imx/hab.c
+++ b/arch/arm/mach-imx/hab.c
@@ -466,10 +466,25 @@ int authenticate_image(uint32_t ddr_start, uint32_t 
image_size,
}
}
 
+   /*
+* FIXME: Need to disable dcache on MX7 is there an IROM
+* register like on MX6 above ? Certain images called in certain
+* orders with the dcache switched on will cause
+* authenticate_image() to lockup. Switching off the dcache
+* resolves the issue.
+* https://community.nxp.com/message/953261
+*/
+   if (is_soc_type(MXC_SOC_MX7))
+   dcache_disable();
+
load_addr = (uint32_t)hab_rvt_authenticate_image(
HAB_CID_UBOOT,
ivt_offset, (void **)&start,
(size_t *)&bytes, NULL);
+
+   if (is_soc_type(MXC_SOC_MX7))
+   dcache_enable();
+
if (hab_rvt_exit() != HAB_SUCCESS) {
puts("hab exit function fail\n");
load_addr = 0;
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 08/25] arm: imx: hab: Fix authenticate image lockup on MX7

2018-01-02 Thread Breno Matheus Lima 
Hi Bryan,

2018-01-02 14:43 GMT-02:00 Bryan O'Donoghue :
> The i.MX6 has some pretty explicit code associated with informing the IROM
> about flushing caches during authenticate_image().
>
> Looking at various pieces of documentation its pretty clear the i.MX6 IROM
> registers are not documented and absent similar documentation on the i.MX7
> the next-best fix is to disabled the dcache while making an
> authenticate_image() callback.
>
> This patch therefore disables dcache temporarily while doing an IROM
> authenticate_image() callback, thus resolving a lockup encountered in a
> complex set of authenticate-image calls observed.
>

I'm trying to reproduce the same issue on an i.MX7D board but I'm not
being able so far, Is it possible to share more details on how to
reproduce this issue? Looking the thread at the NXP community seems
that this can be reproduced in a specific situation, I would like to
test in a similar environment as yours.

Thanks,
Breno Lima
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 08/25] arm: imx: hab: Fix authenticate image lockup on MX7

2018-01-03 Thread Bryan O'Donoghue 



On 03/01/18 01:25, Breno Matheus Lima wrote:

Hi Bryan,

2018-01-02 14:43 GMT-02:00 Bryan O'Donoghue :

The i.MX6 has some pretty explicit code associated with informing the IROM
about flushing caches during authenticate_image().

Looking at various pieces of documentation its pretty clear the i.MX6 IROM
registers are not documented and absent similar documentation on the i.MX7
the next-best fix is to disabled the dcache while making an
authenticate_image() callback.

This patch therefore disables dcache temporarily while doing an IROM
authenticate_image() callback, thus resolving a lockup encountered in a
complex set of authenticate-image calls observed.



I'm trying to reproduce the same issue on an i.MX7D board but I'm not
being able so far, Is it possible to share more details on how to
reproduce this issue? Looking the thread at the NXP community seems
that this can be reproduced in a specific situation, I would like to
test in a similar environment as yours.

Thanks,
Breno Lima



OK I'll try to put some images onto gdrive for you.

Do you have an mx7 board which _doesn't_ have the OTP fuses blown ?

You will need to

1. Program SRK efuse index 3 to the same SRK we use
2. Set the part into secure-boot mode

If you don't have a *spare* board - we'll have to figure out how to 
regenerate the signed images in the same format with your SRK hashes.


---
bod
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot