Difference between revisions of "BELK-TN-011: Lock OTP Areas"
(→Older BSP issue) |
|||
| (7 intermediate revisions by the same user not shown) | |||
| Line 2: | Line 2: | ||
{{Applies To Bora}} | {{Applies To Bora}} | ||
{{Applies To BoraX}} | {{Applies To BoraX}} | ||
| − | |||
| − | |||
| − | |||
| − | |||
{{InfoBoxBottom}} | {{InfoBoxBottom}} | ||
__FORCETOC__ | __FORCETOC__ | ||
| Line 18: | Line 14: | ||
|- | |- | ||
|1.0.0 | |1.0.0 | ||
| − | | | + | | |
| − | | | + | | |
|} | |} | ||
== Introduction == | == Introduction == | ||
| − | As | + | As decribed on [[ConfigID_management_(BELK/BXELK)|ConfigID management]] page, these informations are stored inside a general purpouse OTP area of the SoC. |
| − | This | + | This page describes a fix to be done on BORA systems that runs BSP versions older than BELK/BXELK-4.1.2 |
=== ConfigID programming === | === ConfigID programming === | ||
| − | All | + | All the SoM are shipped with ConfgID and UniqueID already programmed and locked. The OTP lock ensure that nothing can change this data (unattempted code execution, etc). |
| − | + | These operations are permitted only by the devel versions of u-boot with the following commands: | |
<pre> | <pre> | ||
configid som_configid <16 byte code> | configid som_configid <16 byte code> | ||
| Line 38: | Line 34: | ||
== Older BSP issue == | == Older BSP issue == | ||
| − | In older BSP, due to | + | In older BSP, due to an u-boot limitation, this OTP area is not really locked and therefore it is possible to overwrite its value. This can lead to identification errors during updates. |
| − | + | From the BELK/BXELK-4.1.2 release this functionality is restored and fully tested | |
| − | == | + | == Fix lock of OTP areas == |
| − | It is | + | It is recommended to update all the systems that runs older releases to update to the newer one and to perform the follwing fix: |
| − | * program on | + | * program on the board (or boot from a different storage - eg. the uSD) the devel version of u-boot to allow the user to perform the OTP lock |
| − | + | * execute the following command <code>configid som_lock 0</code> | |
| − | + | * program the release version of u-boot to restore the normal operations | |
| − | |||
| − | * | ||
| − | * program | ||
Revision as of 14:54, 22 September 2020
| HOME | SOMs | SBCs | ToloMEO Embedded Assistant |  GET A QUOTE
|
 ONLINE HELPDESK
|
| Roadmap | IoT Services | ML/AI services | Embedded Design Services |
Info Box
|
|
This technical note was validated against specific versions of hardware and software. What is described here may not work with other versions. |
|
Contents
History[edit | edit source]
| Version | Date | Notes |
|---|---|---|
| 1.0.0 |
Introduction[edit | edit source]
As decribed on ConfigID management page, these informations are stored inside a general purpouse OTP area of the SoC.
This page describes a fix to be done on BORA systems that runs BSP versions older than BELK/BXELK-4.1.2
ConfigID programming[edit | edit source]
All the SoM are shipped with ConfgID and UniqueID already programmed and locked. The OTP lock ensure that nothing can change this data (unattempted code execution, etc).
These operations are permitted only by the devel versions of u-boot with the following commands:
configid som_configid <16 byte code> configid som_uniqueid <32 byte code> configid som_lock 0
Older BSP issue[edit | edit source]
In older BSP, due to an u-boot limitation, this OTP area is not really locked and therefore it is possible to overwrite its value. This can lead to identification errors during updates.
From the BELK/BXELK-4.1.2 release this functionality is restored and fully tested
Fix lock of OTP areas[edit | edit source]
It is recommended to update all the systems that runs older releases to update to the newer one and to perform the follwing fix:
- program on the board (or boot from a different storage - eg. the uSD) the devel version of u-boot to allow the user to perform the OTP lock
- execute the following command
configid som_lock 0 - program the release version of u-boot to restore the normal operations
