mbox series

[0/2] imx93_var_som: Enable AHAB support

Message ID 20240208094518.391-1-othacehe@gnu.org
Headers show
Series imx93_var_som: Enable AHAB support | expand

Message

Mathieu Othacehe Feb. 8, 2024, 9:45 a.m. UTC 
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(-)

Comments

Fabio Estevam Feb. 8, 2024, 9:20 p.m. UTC | #1 
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?
Mathieu Othacehe Feb. 9, 2024, 8:04 a.m. UTC | #2 
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
Fabio Estevam Feb. 9, 2024, 10:35 a.m. UTC | #3 
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?
Mathieu Othacehe Feb. 9, 2024, 2:24 p.m. UTC | #4 
> 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
Fabio Estevam Feb. 9, 2024, 2:28 p.m. UTC | #5 
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.