Skip to main content
Graduate
July 26, 2024
Solved

BSEC node can not retireve OTP data

  • July 26, 2024
  • 1 reply
  • 1112 views

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.

    This topic has been closed for replies.
    Best answer by PatrickD

    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

     

    1 reply

    PatrickDAnswer
    ST Employee
    August 1, 2024

    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