Bureaucrats, dave_user, Administrators
8,186
edits
Changes
→DAVE Embedded Systems' hardware implementation
{{InfoBoxTop}}
{{AppliesToAXEL Lite TN}}
{{AppliesToAXEL ULite TN}}
{{AppliesTo SBC Lynx TN}}
{{AppliesTo ORCA TN}}
{{AppliesTo ORCA SBC TN}}
{{AppliesTo MITO 8M Mini TN}}
{{AppliesTo MITO 8M Nano TN}}
{{AppliesTo MITO 8M TN}}
{{AppliesToETRA TN}}
{{AppliesTo ETRA SBC TN}}
{{AppliesToBORA TN}}
{{AppliesToBORA Lite TN}}
{{Applies To Diva}}
{{InfoBoxBottom}}
<section begin="Body" />= Introduction = ConfigID and UniqueID==
=== ConfigID ===
An additional attribute is '''UniqueID''', which is a read-only code which univocally identifies a single product and is used for traceability.
{{ImportantMessage|text=It is worth remembering that ConfigID and UniqueID are independent from [[Product_serial_number|product serial number]].}}
=== Customer's action ===
DAVE Embedded Systems <u>recommends to be up-to-date with Official SOM's BSPs</u> for taking advantages of ConfigID/UniqueId features: this is the '''only''' required action.
* '''UniqueID advantage''': to trace univocally each individual SOMs and, in turn, all the on-the-field equipments
=== ConfigID values ===
ConfigID is a N-bit (typically N>8) signed integer, that can have the following values:
** values are reported accordingly with the specific product table
=== Hardware implementations of the ConfigID ===
The following paragraphs briefly describe the available solution solutions for storing the ConfigID.
==== OTP on the SOC ====
Some SOCs provides programmable OTPs (eg. for security, mac MAC address, boot modes, etc). Usually , some of these are general purpose registers and can be managed by the user.
This is the ideal implementation, because:
* ConfigID is stored in the most important component of the SOM
* the component that hosts the ConfigID is NOT optional
* typically, a very selective lock can be forced. In general, for reliability and/or security reasons, OTP areas used to store ConfigIDs may be locked during the manufacturing process.
==== OTP 1-wire memory ====
This implementation requires a 1-wire memory chip.
==== I2C Eeprom ====
This implementation requires connecting an EEPROM to an I2C bus of the SOC. Moreover, routing a write protect pin to the SOM connector is required.
==== NOR Flash SPI ====
This implementation requires a NOR flash connected to the SPI bus of the SOC.
=== DAVE Embedded Systems' hardware implementation ===
DAVE's SOCs implement the ConfigID feature depending on hardware Capabilities of the SOCs. The following list shows the priority used for its implementation:
## DIVA and BORA use the first 32bytes OTP block on NOR SPI to store ConfigID (and its CRC32), UniqueID (and its CRC32)
# I2C Eeprom
## example: DIVA family processor (AM335x) or BORA Lite processor (ZYNQ) implements ConfigID using I2C Eeprom when NOR SPI is not present (module boots from NAND or SD)## DIVA and BORA Lite use the first 32bytes on I2C EPROM to store ConfigID (and its CRC32), UniqueID (and its CRC32)
# 1-wire
## example: latest XELKAXEL Lite, DIVELK, BELK Carrier Boards AXEL ULite and BORA/BORA Xpress/BORA Lite Evaluation Kits implement CB ConfigID using the onboard 1-wire device (DS2431)
==== Software implementation ====
===== U-Boot =====
u-boot integrates the software routines for reading and displaying the ConfigID: hereunder an example of SOM ConfigID at startup:
</pre>
===== Linux =====
It is possible to read the ConfigID/UniqueID via <code>procfs</code>; for example:
root@axel-lite:~#
</pre>
=== A real case example of ConfigID benefit ===
The ConfigID benefit is clear when:
* there is a number of products deployed on the field
* the products deployed on the field needs a SW update
The ideal scenario is that all products are equal and there are no differences on the Bill Of Material (BOM):<gallery caption="All products have the same BOM with a single Config ID">
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon.png|ConfigID A
</gallery>In this case there are no problems to deploy a new SW update on the field: all products have the <u>'''same'''</u> HW configuration, then the '''<u>same</u>''' SW configuration.
Unfortunately, this is an ideal scenario. The reality is that:
* component obsolescence
* product shortage
* second source strategies
force to have an on-the-field different version of product (with same functionalities but with different HW configuration) which doesn't permit to realize what proposed in the ideal case.
{{ImportantMessage|text=The usage of the ConfigID technique, allows the running SW to identify the underlying HW configuration and automatically adapt the BSP (i.e. the driver layer) to properly use the HW subsystems: this, maintaining the overall product features identical to the final User point-of-view.}}
<gallery caption="All products are similar BUT there are different Config ID between the 2 product versions">
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon-2.png|ConfigID B
File:Smartphone-icon-2.png|ConfigID B
File:Smartphone-icon.png|ConfigID A
File:Smartphone-icon-2.png|ConfigID B
</gallery>With a scenario, like the one described above, if you would like to update the SW you need to implement a strategy for understanding what platform version is going to be updated. The Config ID is used exactly for this goal.
The ConfigID provides to the software update routine the information on which product version is so the update can be adapted to the exact product version.
In this way, you can distribute one single version of the software update which will automatically adapt itself to the currently running platform.
==== How to handle After Sales with Config ID ====
One of the mos common questions about Config ID is how to handle the Config ID issue. Below is described with an example how to handle it.
This product is returned from the field with a problem on the display:
[[File:Smartphone-icon.png|none|thumb|159x159px|Config ID A]]
After Sales Dept analizes the product and decide to substitute the display. The problem is that the existing display is not available - because of is End Of Life (EOL) - and it is required to move to a different display: in the product a different Config ID will be written because of the 2 displays requires a dedicated SW version and cannot be distinguished automatically during the startup. The final result is to have the similar product:
[[File:Smartphone-icon-2.png|none|thumb|189x189px|Config ID B]]
As indicated, the new display requires a different Config ID (from A to B) so it can be updated with an easy software routine before start the SW update. This Config ID update routine can be implemented in manufacturing facility typically using a dedicated USB pen drive which modify the saved ConfigID to the new one depending on the storage memory in use<section end="Body" />