cancel
Showing results for 
Search instead for 
Did you mean: 

BSEC node can not retireve OTP data

ahamod3.1416
Associate III

Hello everyone,

We have a custom board based on stm32mp157c. We have a working bsp, which have tf-a 2.2 and u-boot 2020 version. Currently we are updating tf-a to 2.6 and u-boot to 2022. In our board we have burned mac address in the otp and we can read the mac address from otp using the old tf-a and u-boot version.

But currently we can not read otp from the using the current version. It is showing following message while retrieving mac-address from the otp. 

 

invalid MAC address 0 in OTP 00:00:00:00:00:00

 



I have following device tree configuration in the optee.

 

&bsec {
        status = "okay";
        ethernet_mac_address@e4 {
                reg = <0xe4 0x8>;
                st,non-secure-otp;
        };

        ethernet_mac1_address@ec {
                reg = <0xec 0x8>;
                st,non-secure-otp;
        };

        ethernet_mac2_address@f4 {
                reg = <0xf4 0x8>;
                st,non-secure-otp;
        };

        board_id@fc {
                reg = <0xfc 0x4>;
                st,non-secure-otp;
        };

        user_otp@100 {
                reg = <0x100 0x80>;
                st,non-secure-otp;
        };
};

 

 
In u-boot environment if I give "stboard" command I get following reply:

 

STM32MP> stboard 
Board : OTP board FREE
      OTP 59 NOT locked !

 

 

Can anyone help me to solve this issue? Thanks in advance.

N.B: Using random mac address and setting the mac-address manually is not a feasible solution for me. I must need to retrieve the mac address from the otp.

1 ACCEPTED SOLUTION

Accepted Solutions
PatrickD
ST Employee

Hi

in U-Boot on STM32MP15 boards, we are using for the ST Microelectronics boards the OTP defined in arch/arm/mach-stm32mp/include/mach/stm32.h

#define BSEC_OTP_MAC 57
#define BSEC_OTP_BOARD 59
(they are hardcoded in U-Boot / not read from device-tree)

1/ "stboard" is a STMicroelectronics command / information for ST board identification

provided as example for customer

=> board/st/common/cmd_stboard.c

=> board/st/stm32mp1/stm32mp1.c: checkboard() / board_late_init()

if you are re-using this command for your custom board you MUST use the same OTP

and it is not your case  board_id@fc (vs board_id@ec in ST boards)

 

For me CMD_STBOARD should be not used in your BSP, except if it s really needed

 
This command it is activated only for ST Microelectronics boards
(when CONFIG_TARGET_ST_STM32MP15X is activated)
and this flag shoudl be not activated for your defconfig.

For details => https://wiki.st.com/stm32mpu/wiki/How_to_configure_U-Boot_for_your_board#Kconfig

 

2/ for MAC address, the ST board, STM32MP15x SoC support only support one MAC address 

    with BSEC_OTP_MAC = 57 in arch/arm/mach-stm32mp/soc.c::setup_mac_address()

    and get_eth_nb() return 1  in arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c

    but even if you are modifying these function, 

    we are using 6 bytes in consecutive OTP word by mac address (only 6 OTP for 2 mac address),

    but in your device your are using 8 bytes = 2 OTP words by mac address

    so the 2 last bytes are unused for each OTP word.

 

the next trace 

invalid MAC address 0 in OTP 00:00:00:00:00:00

in done in ST setup_mac_address(), written for ST default MAC location.

 

    but it is a weak function => you can override it in your BSP for your board

    to support 3 mac address

 

it is already done by DHELECTRONICS BSP to read MAC in EEPROM
see  => board/dhelectronics/dh_stm32mp1/board.c:setup_mac_address()

 

=> if these OTPs are read to configure the MACs in your BSP for u-boot 2020 version,

     you must have some patches for it, not correctly reported in v2022.10 (openSTLinux V5.X)

 

 

Other idea:  you have perhaps also issue for OTP read in U-Boot....

=> you can check if the bsec driver is probed U-Boot (execute the command => dm tree)

and if the OTP are accessible, with command fuse by example 

STM32MP1> fuse sense 0 57 2

See https://wiki.st.com/stm32mpu/wiki/How_to_update_OTP_with_U-Boot

for other example.

=> are you using OP-TEE with U-Boot v2022.10 ?

if yes, you need to check the non-secure access to OTP, define in OP-TEE device tree 

 
ethernet_mac_address: mac@e4 {
reg = <0xe4 0x8>;
st,non-secure-otp;
};
 
Normally with OP-TEE, the OTP are provided by the OP-TEE TA BSEC

to check, try to activate trace in U-Boot bsec driver
=> ./arch/arm/mach-stm32mp/bsec.c
 

 

Regards

Patrick

 

View solution in original post

1 REPLY 1
PatrickD
ST Employee

Hi

in U-Boot on STM32MP15 boards, we are using for the ST Microelectronics boards the OTP defined in arch/arm/mach-stm32mp/include/mach/stm32.h

#define BSEC_OTP_MAC 57
#define BSEC_OTP_BOARD 59
(they are hardcoded in U-Boot / not read from device-tree)

1/ "stboard" is a STMicroelectronics command / information for ST board identification

provided as example for customer

=> board/st/common/cmd_stboard.c

=> board/st/stm32mp1/stm32mp1.c: checkboard() / board_late_init()

if you are re-using this command for your custom board you MUST use the same OTP

and it is not your case  board_id@fc (vs board_id@ec in ST boards)

 

For me CMD_STBOARD should be not used in your BSP, except if it s really needed

 
This command it is activated only for ST Microelectronics boards
(when CONFIG_TARGET_ST_STM32MP15X is activated)
and this flag shoudl be not activated for your defconfig.

For details => https://wiki.st.com/stm32mpu/wiki/How_to_configure_U-Boot_for_your_board#Kconfig

 

2/ for MAC address, the ST board, STM32MP15x SoC support only support one MAC address 

    with BSEC_OTP_MAC = 57 in arch/arm/mach-stm32mp/soc.c::setup_mac_address()

    and get_eth_nb() return 1  in arch/arm/mach-stm32mp/stm32mp1/stm32mp15x.c

    but even if you are modifying these function, 

    we are using 6 bytes in consecutive OTP word by mac address (only 6 OTP for 2 mac address),

    but in your device your are using 8 bytes = 2 OTP words by mac address

    so the 2 last bytes are unused for each OTP word.

 

the next trace 

invalid MAC address 0 in OTP 00:00:00:00:00:00

in done in ST setup_mac_address(), written for ST default MAC location.

 

    but it is a weak function => you can override it in your BSP for your board

    to support 3 mac address

 

it is already done by DHELECTRONICS BSP to read MAC in EEPROM
see  => board/dhelectronics/dh_stm32mp1/board.c:setup_mac_address()

 

=> if these OTPs are read to configure the MACs in your BSP for u-boot 2020 version,

     you must have some patches for it, not correctly reported in v2022.10 (openSTLinux V5.X)

 

 

Other idea:  you have perhaps also issue for OTP read in U-Boot....

=> you can check if the bsec driver is probed U-Boot (execute the command => dm tree)

and if the OTP are accessible, with command fuse by example 

STM32MP1> fuse sense 0 57 2

See https://wiki.st.com/stm32mpu/wiki/How_to_update_OTP_with_U-Boot

for other example.

=> are you using OP-TEE with U-Boot v2022.10 ?

if yes, you need to check the non-secure access to OTP, define in OP-TEE device tree 

 
ethernet_mac_address: mac@e4 {
reg = <0xe4 0x8>;
st,non-secure-otp;
};
 
Normally with OP-TEE, the OTP are provided by the OP-TEE TA BSEC

to check, try to activate trace in U-Boot bsec driver
=> ./arch/arm/mach-stm32mp/bsec.c
 

 

Regards

Patrick