From: Frieder Schrempf <frieder.schrempf@kontron.de>

This depends on [1] for the support of the Edgelock Secure Enclave firmware
driver.

There are at least two ways to access the OTP fuses on i.MX93:

(1) through the FSB (fuseblock) registers
(2) through the ELE S400 API

There currently is a NVMEM driver imx-ocotp-ele.c that (despite its name)
implements (1). As the FSB only provides limited access to the OTP registers
(read only) it's not sufficient for all use-cases.

It seems like imx-ocotp-ele.c was intended to be extended later to implement
(1) and (2) deciding on a per-fuse-register basis which of both access methods
should be used.

This has some downsides:

* the driver gets convoluted and complex
* the driver decides which OTP registers are accessed in which way and therefore
  mixes read-only and read/write access

Therefore I implemented a simple driver that uses the ELE S400 API only, as the
FSB access (1) doesn't provide any benefits except for that it doesn't depend
on the ELE firmware being available. This is used by us downstream.

For the upstream solution I would like to have some feedback on how to move
on:

1. switch imx-ocotp-ele.c to use ELE API exclusively
   -> this will create a hard dependency on the ELE firmware/driver being available
2. extend imx-ocotp-ele.c to use FSB and ELE API
   -> make the driver use ELE API for all registers if ELE firmware/driver is available
3. create separate drivers as done in this RFC

Thanks!

[1] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20250409-imx-se-if-v16-0-5394e5f3417e@nxp.com/

Frieder Schrempf (5):
  firmware: imx: ele: Add API functions for OCOTP fuse access
  nvmem: Add i.MX OCOTP fuse driver using ELE S400 API
  arm64: dts: imx93: Add node for EdgeLock Enclave (ELE) firmware driver
  arm64: dts: imx93: Add node for OCOTP S400 NVMEM driver
  arm64: dts: imx93-kontron: Add DMA memory region for ELE firmware

 .../dts/freescale/imx93-kontron-osm-s.dtsi    |  16 ++
 arch/arm64/boot/dts/freescale/imx93.dtsi      |  11 +
 drivers/firmware/imx/ele_base_msg.c           | 122 +++++++++++
 drivers/firmware/imx/ele_base_msg.h           |   8 +
 drivers/nvmem/Kconfig                         |  11 +
 drivers/nvmem/Makefile                        |   2 +
 drivers/nvmem/imx-ocotp-s400.c                | 195 ++++++++++++++++++
 include/linux/firmware/imx/se_api.h           |   3 +
 8 files changed, 368 insertions(+)
 create mode 100644 drivers/nvmem/imx-ocotp-s400.c

-- 
2.49.0

Hi Frieder,

On Wed, Apr 16, 2025 at 04:26:19PM +0200, Frieder Schrempf wrote:
>From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
>This depends on [1] for the support of the Edgelock Secure Enclave firmware
>driver.
>
>There are at least two ways to access the OTP fuses on i.MX93:
>
>(1) through the FSB (fuseblock) registers
>(2) through the ELE S400 API
>
>There currently is a NVMEM driver imx-ocotp-ele.c that (despite its name)
>implements (1). As the FSB only provides limited access to the OTP registers
>(read only) it's not sufficient for all use-cases.
>
>It seems like imx-ocotp-ele.c was intended to be extended later to implement
>(1) and (2) deciding on a per-fuse-register basis which of both access methods
>should be used.
>
>This has some downsides:
>
>* the driver gets convoluted and complex
>* the driver decides which OTP registers are accessed in which way and therefore
>  mixes read-only and read/write access
>
>Therefore I implemented a simple driver that uses the ELE S400 API only, as the
>FSB access (1) doesn't provide any benefits except for that it doesn't depend
>on the ELE firmware being available. This is used by us downstream.
>
>For the upstream solution I would like to have some feedback on how to move
>on:
>
>1. switch imx-ocotp-ele.c to use ELE API exclusively
>   -> this will create a hard dependency on the ELE firmware/driver being available
>2. extend imx-ocotp-ele.c to use FSB and ELE API
>   -> make the driver use ELE API for all registers if ELE firmware/driver is available
>3. create separate drivers as done in this RFC

Need to confirm ELE APIs supports all fuses. If yes, switching to using ELE API
exclusively should be ok, no need to mix FSB and ELE API. And drop the current
FSB usage

Thanks,
Peng.

>
>Thanks!
>
>[1] https://patchwork.kernel.org/project/linux-arm-kernel/cover/20250409-imx-se-if-v16-0-5394e5f3417e@nxp.com/
>
>Frieder Schrempf (5):
>  firmware: imx: ele: Add API functions for OCOTP fuse access
>  nvmem: Add i.MX OCOTP fuse driver using ELE S400 API
>  arm64: dts: imx93: Add node for EdgeLock Enclave (ELE) firmware driver
>  arm64: dts: imx93: Add node for OCOTP S400 NVMEM driver
>  arm64: dts: imx93-kontron: Add DMA memory region for ELE firmware
>
> .../dts/freescale/imx93-kontron-osm-s.dtsi    |  16 ++
> arch/arm64/boot/dts/freescale/imx93.dtsi      |  11 +
> drivers/firmware/imx/ele_base_msg.c           | 122 +++++++++++
> drivers/firmware/imx/ele_base_msg.h           |   8 +
> drivers/nvmem/Kconfig                         |  11 +
> drivers/nvmem/Makefile                        |   2 +
> drivers/nvmem/imx-ocotp-s400.c                | 195 ++++++++++++++++++
> include/linux/firmware/imx/se_api.h           |   3 +
> 8 files changed, 368 insertions(+)
> create mode 100644 drivers/nvmem/imx-ocotp-s400.c
>
>-- 
>2.49.0

Hi Peng,

Am 22.04.25 um 08:30 schrieb Peng Fan:
> Hi Frieder,
> 
> On Wed, Apr 16, 2025 at 04:26:19PM +0200, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> This depends on [1] for the support of the Edgelock Secure Enclave firmware
>> driver.
>>
>> There are at least two ways to access the OTP fuses on i.MX93:
>>
>> (1) through the FSB (fuseblock) registers
>> (2) through the ELE S400 API
>>
>> There currently is a NVMEM driver imx-ocotp-ele.c that (despite its name)
>> implements (1). As the FSB only provides limited access to the OTP registers
>> (read only) it's not sufficient for all use-cases.
>>
>> It seems like imx-ocotp-ele.c was intended to be extended later to implement
>> (1) and (2) deciding on a per-fuse-register basis which of both access methods
>> should be used.
>>
>> This has some downsides:
>>
>> * the driver gets convoluted and complex
>> * the driver decides which OTP registers are accessed in which way and therefore
>>  mixes read-only and read/write access
>>
>> Therefore I implemented a simple driver that uses the ELE S400 API only, as the
>> FSB access (1) doesn't provide any benefits except for that it doesn't depend
>> on the ELE firmware being available. This is used by us downstream.
>>
>> For the upstream solution I would like to have some feedback on how to move
>> on:
>>
>> 1. switch imx-ocotp-ele.c to use ELE API exclusively
>>   -> this will create a hard dependency on the ELE firmware/driver being available
>> 2. extend imx-ocotp-ele.c to use FSB and ELE API
>>   -> make the driver use ELE API for all registers if ELE firmware/driver is available
>> 3. create separate drivers as done in this RFC
> 
> Need to confirm ELE APIs supports all fuses. If yes, switching to using ELE API
> exclusively should be ok, no need to mix FSB and ELE API. And drop the current
> FSB usage

Ok, I already compared what fuse registers I can access via FSB and ELE.
The ELE seems to cover all registers that are available via FSB so that
shouldn't be a problem.

Still, after thinking a bit more about it, option 2 above seems like the
best way to go to me.

In case someone wants to use the system without the proprietary ELE
firmware, I'd like them to not run into the obstacle of loosing read
access to the OTPs. Especially as the Ethernet driver expects the NVMEM
cells for the MAC address to be available.

I know that the ELE firmware is currently somewhat mandatory as the
bootloader uses it, but I guess it would be possible and for some people
also desirable to have a system without it.

So what I would like to have is an optional DT property for the
imx-ocotp-ele.c driver to point to the secure enclave node. If the ELE
device is available at probe time, make the driver use the ELE API
exclusively. If not, fall back to the FSB API with read-only access.

If someone wants to avoid the ELE API altogether for whatever reason,
they could remove the link to the secure enclave node in their board DT.

Thanks
Frieder

On Wed, Apr 16, 2025, at 16:26, Frieder Schrempf wrote:

> Therefore I implemented a simple driver that uses the ELE S400 API only, as the
> FSB access (1) doesn't provide any benefits except for that it doesn't depend
> on the ELE firmware being available. This is used by us downstream.
>
> For the upstream solution I would like to have some feedback on how to move
> on:
>
> 1. switch imx-ocotp-ele.c to use ELE API exclusively
>    -> this will create a hard dependency on the ELE firmware/driver 
> being available

Could this cause problems for real-time Linux users? Usually going
through a firmware driver adds more latency than doing the thing
from Linux directly, and the firmware is usually not preemptable.

In particular, programming a one-time fuse is likely a slow
operation in hardware, so it may still be necessary to support
both methods if there are users that need to update the fuses
on real-time systems.

     Arnd

Am 22.04.25 um 08:40 schrieb Arnd Bergmann:
> On Wed, Apr 16, 2025, at 16:26, Frieder Schrempf wrote:
> 
>> Therefore I implemented a simple driver that uses the ELE S400 API only, as the
>> FSB access (1) doesn't provide any benefits except for that it doesn't depend
>> on the ELE firmware being available. This is used by us downstream.
>>
>> For the upstream solution I would like to have some feedback on how to move
>> on:
>>
>> 1. switch imx-ocotp-ele.c to use ELE API exclusively
>>    -> this will create a hard dependency on the ELE firmware/driver 
>> being available
> 
> Could this cause problems for real-time Linux users? Usually going
> through a firmware driver adds more latency than doing the thing
> from Linux directly, and the firmware is usually not preemptable.
> 
> In particular, programming a one-time fuse is likely a slow
> operation in hardware, so it may still be necessary to support
> both methods if there are users that need to update the fuses
> on real-time systems.

Hm, interesting thought. I can't really tell if that could end up being
a real problem, but it might just be another good argument for
supporting both methods, yes.