[PATCH v3] misc: Add RZG2L OTP support

Mathieu Othacehe othacehe at gnu.org
Mon Apr 27 11:15:04 CEST 2026


Hello Marek,

> If you do want to expose the fuses via SMC , then the fuse region has to be
> secure only , so only TFA can access it . TFA can then decide which exact fuse
> the user can or can not read or program, on a single fuse granularity.
>
> By default, non-secure user should be able to read some select fuses (IDs),
> program no fuses. User should have the ability to expose some select fuses as
> programmable, for manufacturing purposes.
>
> Mathieu, which fuses exactly do you plan to program ?

I plan to program all fuses (enable secureboot, ROT hash, user
encryption keys) using U-Boot directly or U-Boot + TF-A during
manufacturing.

I then see two possibilities:

1. During manufacturing, use a specific TF-A that allows fusing from the
non-secure world (with SYS_SLVACCCTL7 register). Fuse directly
everything from U-Boot, using the patch under review. Then, flash the
regular, default TF-A that does not allow fusing from the non-secure
world.

2. During manufacturing, use a specific TF-A that allows, via SMC,
fusing everything from the non-secure world. Write a new U-Boot driver
that performs fusing through SMC. Use it to fuse everything from U-Boot
during manufacturing. Then, flash the regular, default TF-A that only
allows specific ID fuse read via SMC.

Both options require a specific TF-A during manufacturing. The only real
difference to me is that with option 2, we can allow ID fuse read from
U-Boot via SMC during regular use.

What do you think?

Thanks,

Mathieu


More information about the U-Boot mailing list