Difference between revisions of "BELK-TN-011: Lock OTP Areas"
(→History) |
(→History) (Tag: Visual edit) |
||
| Line 15: | Line 15: | ||
|1.0.0 | |1.0.0 | ||
|Sep 2020 | |Sep 2020 | ||
| − | |First | + | |First release |
|} | |} | ||
| Line 24: | Line 24: | ||
=== ConfigID programming === | === ConfigID programming === | ||
| − | All the SoM are shipped with ConfgID and UniqueID already programmed and locked. The OTP lock ensure that | + | All the SoM are shipped with ConfgID and UniqueID already programmed and locked. The OTP lock ensure that nobody can change this data (unattempted code execution, etc). |
| − | + | It is possibile to execute these operations only using 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 34: | Line 34: | ||
== Older BSP issue == | == Older BSP issue == | ||
| − | In older BSP, due to | + | In older BSP, due to a u-boot limitation, this OTP area is not ''really'' locked and therefore it should be possible to overwrite its value, with possible identification errors during updates. |
| − | + | Starting from the BELK/BXELK-4.1.2 release this issue have been solved. | |
== Fix lock of OTP areas == | == Fix lock of OTP areas == | ||
| − | It is | + | It is suggested to update the systems that runs ''older BSP releases'' to the BELK 4.1.2 and perform the following fixing steps: |
| − | * program on | + | * program on boot from the uSD using the u-boot devel version - that can be found on our [https://cloud.dave.eu/ws-mirror/bora/belk-4.1.2 mirror server] - allowing the OTP lock command to be executed |
| − | * execute the | + | * execute the command <code>configid som_lock 0</code> |
| − | * program | + | * program any u-boot release version to restore the normal operations (''this is not required if previous operations have been executed using an external boot from SD'') |
Revision as of 14:01, 25 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 | Sep 2020 | First release |
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 nobody can change this data (unattempted code execution, etc).
It is possibile to execute these operations only using 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 a u-boot limitation, this OTP area is not really locked and therefore it should be possible to overwrite its value, with possible identification errors during updates.
Starting from the BELK/BXELK-4.1.2 release this issue have been solved.
Fix lock of OTP areas[edit | edit source]
It is suggested to update the systems that runs older BSP releases to the BELK 4.1.2 and perform the following fixing steps:
- program on boot from the uSD using the u-boot devel version - that can be found on our mirror server - allowing the OTP lock command to be executed
- execute the command
configid som_lock 0 - program any u-boot release version to restore the normal operations (this is not required if previous operations have been executed using an external boot from SD)
