2024-07-26 04:42 AM
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.
Solved! Go to Solution.
2024-08-01 05:47 AM
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
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
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
Regards
Patrick
2024-08-01 05:47 AM
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
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
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
Regards
Patrick