Programming the Mac ID in OTP

[PTewa.1]

Hello Team,

We are using a product build around STM32MP157C. We have a requirement for programming the OTP with MAC Id. Here is my understanding on the same:

1. The OTP_57 and OTP_58 are meant for MAC address
2. MAC address can be programmed from the uboot using the fuse command
3. MAC address can be programmed from user space (with kernel booted up) using the sysfs interface.

We boot up our platform in basic mode. However, there was a mention that by default, OTP can be updated only in the secure mode. So, want to check if there is any setting which allows to update the MAC address specific OTP in basic mode?

Also, want to understand if there is any automated tool which would efficiently allows the MAC address to updated during the Mass Production?

[OlivierK]

Hello PTewa.1 (Community Member)

For 1 2 and 3. I can confirm,

OTP are programmed via the BSEC h/w peripheral (Boot, SEcurity and otp Control) which is a secured peripheral and configured at boot time. Basic U-boot does not have the security features to access the BSEC.

https://wiki.st.com/stm32mpu/wiki/BSEC_internal_peripheral

https://wiki.st.com/stm32mpu/wiki/BSEC_device_tree_configuration

STM32Cubeprogrammer can be used to program the OTP, although this is not a mass production programmer.

https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer

[PTewa.1]

Hi Oliver,

Thanks for the quick reply.

Wanted to understand few things:

1. So, does this mean there is no way to program the MAC address with basic boot? Please confirm.
2. Also, as mentioned BSEC is a secure peripheral and configured at boot time. So, want to understand which component is responsible for configuration? Is it ROM code or some other bootloader?
3. Since BSEC is a secured peripheral, how does STM32CubeProgrammer gets an access to it? Does it boots up the system in secured mode?
4. As STM32CubeProgrammer is not a mass production programmer, Is there any other mechanism for program the flashes for mass production or OEMs design their own tool for the same?

Regards,

Pradeep

Since STM32CubeProgrammer can be used to program the OTP

[OlivierK]

Hi PTewa.1 (Community Member)

Basic boot is not intended for production and does not embed secure services. It can only access the lower OTP from BSEC as non secure accesses.

https://wiki.st.com/stm32mpu/wiki/NVMEM_overview

As MAC address is part of the upper OTPs, it could accessed if TF-A as FSBL and U-Boot as SSBL are used.

STM32CubeProgrammer relies on the embedded secured Rom Code, TF-A and U-Boot to be able to program the OTPs. OEMs design their own tool based on this for production, or use it as is but at their own risks.

Regards,

Olivier

[PTewa.1]

Hi Olivier,

Thanks for clarifying.

One follow up question - I understand u-boot can access the MAC address with fuse command in secure mode. So, provided the system is booted in secure mode, is it possible to program the MAC address from the user space using the sysfs interface for nvmem? This would allow the tool to be operated in user space with system booted up.

Regards,

Pradeep

[OlivierK]

Hi PTewa.1 (Community Member)

As mentioned in https://wiki.st.com/stm32mpu/wiki/NVMEM_overview

Only if a trusted boot chain is used, it is possible to access the upper OTPs via sysfs if already enabled in the BSEC device tree.

There is an exception management explained in order to allow some upper OTPs to be accessed by the non-secure world.

 using the "st,non-secure-otp" definition 

https://wiki.st.com/stm32mpu/wiki/BSEC_device_tree_configuration

Regards,

Olivier

[PTewa.1]

Hi Olivier,

Thanks for the prompt response. I added the device tree node as suggested in https://wiki.st.com/stm32mpu/wiki/BSEC_device_tree_configuration as below:

 &bsec {

       mac_addr: mac_addr@e4 {

               reg = <0xe4 0x8>;

               st,non-secure-otp;

       };

However still the OTP for MAC-ID is not accessible using the sysfs. Am I missing something? As per my understanding, adding the node in the DTB should allow an access to specific OTP words in non-secure mode.

The reason we don't want to switch to secure mode is that we have already designed & implemented the complete application using the non-secure mode and product is already in market. So, we are not sure of the implications which secure mode will bring in. And also, just for OTP update, switching to secure mode is somehow not working out for us. That's the reason we are looking for an alternative. And so far, what I understood from our conversations and the reference manual is that there is a way out to update the OTP in non-secure world. Please confirm if my understanding is correct.

Looking forward.

Regards,

Pradeep

[OlivierK]

Hello Pradeep,

Sorry for the late answer, the exception management explained in order to allow some upper OTPs to be accessed by the non-secure world (using the st,non-secure-otp in DT) requires anyway to go through secure world services for very specific needs, therefore it needs the Trusted boot chain.

The only way to update the OTP via the Basic boot chain is through the fuse command in U-boot, with a restriction of the LOCK that is not available.

How to update OTP with U-Boot - stm32mpu

Best Regards

Olivier