[PATCH 0/2] imx93_var_som: Enable AHAB support
Hello,
This enables AHAB support on the imx93_var_som. I was able to test that I can boot from signed images on a closed board.
There is one issue that has been discovered and that is discussed here: https://lists.denx.de/pipermail/u-boot/2024-February/545404.html
This series can still be applied in the meantime I guess.
Thanks,
Mathieu
Mathieu Othacehe (2): board: imx93_var_som: Probe ELE MU configs: imx93_var_som: Enable AHAB support
board/variscite/imx93_var_som/spl.c | 5 +++-- configs/imx93_var_som_defconfig | 1 + 2 files changed, 4 insertions(+), 2 deletions(-)
Probing the MU is needed to prevent this error in the SPL:
ele dev is not initialized Authenticate container hdr failed, return -19, resp 0x0 IND = INVALID
ele dev is not initialized Error: release container failed, resp 0x0! IND = INVALID
SPL: failed to boot from all boot devices
Signed-off-by: Mathieu Othacehe othacehe@gnu.org --- board/variscite/imx93_var_som/spl.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/board/variscite/imx93_var_som/spl.c b/board/variscite/imx93_var_som/spl.c index 502e599b91a..0965a2de996 100644 --- a/board/variscite/imx93_var_som/spl.c +++ b/board/variscite/imx93_var_som/spl.c @@ -97,6 +97,7 @@ int power_init_board(void) return 0; }
+extern int imx9_probe_mu(void *ctx, struct event *event); void board_init_f(ulong dummy) { int ret; @@ -114,9 +115,9 @@ void board_init_f(ulong dummy)
preloader_console_init();
- ret = arch_cpu_init(); + ret = imx9_probe_mu(NULL, NULL); if (ret) { - printf("Fail to init Sentinel API\n"); + printf("Fail to init ELE API\n"); } else { printf("SOC: 0x%x\n", gd->arch.soc_rev); printf("LC: 0x%x\n", gd->arch.lifecycle);
On Thu, Feb 8, 2024 at 6:45 AM Mathieu Othacehe othacehe@gnu.org wrote:
diff --git a/board/variscite/imx93_var_som/spl.c b/board/variscite/imx93_var_som/spl.c index 502e599b91a..0965a2de996 100644 --- a/board/variscite/imx93_var_som/spl.c +++ b/board/variscite/imx93_var_som/spl.c @@ -97,6 +97,7 @@ int power_init_board(void) return 0; }
+extern int imx9_probe_mu(void *ctx, struct event *event);
Please put this prototype into a header file.
Currently, it appears in 3 imx93 spl.c files.
Enable AHAB support in the imx93_var_som configuration.
Signed-off-by: Mathieu Othacehe othacehe@gnu.org --- configs/imx93_var_som_defconfig | 1 + 1 file changed, 1 insertion(+)
diff --git a/configs/imx93_var_som_defconfig b/configs/imx93_var_som_defconfig index cc0c5a79bc1..14922f2a3e2 100644 --- a/configs/imx93_var_som_defconfig +++ b/configs/imx93_var_som_defconfig @@ -12,6 +12,7 @@ CONFIG_IMX_CONFIG="arch/arm/mach-imx/imx9/imximage.cfg" CONFIG_DM_GPIO=y CONFIG_DEFAULT_DEVICE_TREE="imx93-var-som-symphony" CONFIG_SPL_TEXT_BASE=0x2049A000 +CONFIG_AHAB_BOOT=y CONFIG_TARGET_IMX93_VAR_SOM=y CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_SPL_SERIAL=y
Hi Mathieu,
On Thu, Feb 8, 2024 at 6:45 AM Mathieu Othacehe othacehe@gnu.org wrote:
Hello,
This enables AHAB support on the imx93_var_som. I was able to test that I can boot from signed images on a closed board.
There is one issue that has been discovered and that is discussed here: https://lists.denx.de/pipermail/u-boot/2024-February/545404.html
This series can still be applied in the meantime I guess.
Just wanted to make sure I understand: if someone programs the fuse to close the board, it will fail to boot U-Boot proper and this means that the board is bricked. Is this correct?
Is the boot failure related to some malloc size needing to be increased?
Hello Fabio,
Just wanted to make sure I understand: if someone programs the fuse to close the board, it will fail to boot U-Boot proper and this means that the board is bricked. Is this correct?
No. I fused the board and with this series applied and the three HAFDBS commits reverted, I can boot just fine on that board.
Without reverting those commits, the SPL is working fine and u-boot hangs at relocation. It is 100% reproducible on my board.
Is the boot failure related to some malloc size needing to be increased?
I tried that it has no influence.
Thanks,
Mathieu
Hi Mathieu,
On Fri, Feb 9, 2024 at 5:05 AM Mathieu Othacehe othacehe@gnu.org wrote:
No. I fused the board and with this series applied and the three HAFDBS commits reverted, I can boot just fine on that board.
Yes, this part I understood.
Without reverting those commits, the SPL is working fine and u-boot hangs at relocation. It is 100% reproducible on my board.
This is what I am concerned about: this hang causes the board to brick and can no longer be recovered since it has the fuse programmed to close the device, right?
This is what I am concerned about: this hang causes the board to brick and can no longer be recovered since it has the fuse programmed to close the device, right?
Once the board is closed you can only boot from signed images. If the signed image is not working (hanging during relocation for instance), then you can always boot from a new one. All the interfaces: SD-card, UART, USB are still usable.
I have tried many u-boot versions on my closed board until I had something working. So, no you do not end-up with a brick unless you cannot sign your image properly anymore.
Or maybe I missed your point?
Thanks,
Mathieu
On Fri, Feb 9, 2024 at 11:25 AM Mathieu Othacehe othacehe@gnu.org wrote:
Once the board is closed you can only boot from signed images. If the signed image is not working (hanging during relocation for instance), then you can always boot from a new one. All the interfaces: SD-card, UART, USB are still usable.
I have tried many u-boot versions on my closed board until I had something working. So, no you do not end-up with a brick unless you cannot sign your image properly anymore.
Thanks for the clarification. I will apply your v2 soon.
participants (2)
-
Fabio Estevam -
Mathieu Othacehe