DESK-MP1-L/General/ConfigID and UniqueID

History
Issue Date	Notes
2023/07/31	First DESK-MP1 release

ConfigID and UniqueID

ConfigID

ConfigID is a new feature of DAVE Embedded Systems products. Its main purpose is providing an automatic mechanism for the identification of the product model and configuration.

With ConfigID, we aim at:

• completing the hardware configuration information that the software can't normally auto-detect (i.e. RAM chip version,...), implementing a dedicated reliable detect procedure
• when required, overriding the auto-detected hardware configuration information

When implemented, this mechanism allows for:

• initializing in the proper way the hardware platform, based on the specific features and parameters of the product, using a common software base (eg: a typical case is the SDRAM controller parameters, which must be configured by U-Boot depending on the particular memory chip, which can be different for the various SOM models)
• getting the complete hardware configuration (combining ConfigID with the information collectable at runtime) of a product deployed on the field

In simple words, model identification means the capability of reading a numerical code, stored in an available device (SOC's OTP , I2C EEPROM, 1-wire memories, protected NOR flash, etc.)

There are two ConfigIDs:

• SOM ConfigID: which reflects the characteristics of the SOM (stored on the SOM itself)
• Carrier Board (CB) ConfigID: which reflects the characteristics of the carrier board that hosts the SOM (stored on the carrier board itself and read by the SOM at boot time)

UniqueID

An additional attribute is UniqueID, which is a read-only code which univocally identifies a single product and is used for traceability.

It is worth remembering that ConfigID and UniqueID are independent from product serial number.

Customer's action

DAVE Embedded Systems recommends to be up-to-date with Official SOM's BSPs for taking advantages of ConfigID/UniqueId features: this is the only required action.

• ConfigID advantage: to allow U-Boot bootloader to be executed only with the correct configuration (if the U-Boot loaded is not the proper one, it may stop execution avoiding incorrect behaviour)
• 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:

• < 0: error
  • -1: not initialized
• = 0: ConfigID legacy
  • for prototypes (ConfigID not yet defined) or for products manufactured before the introduction of the ConfigID feature
• > 0: valid ConfigID
  • values are reported accordingly with the specific product table

Hardware implementations of the ConfigID

The following paragraphs briefly describe the available solutions for storing the ConfigID.

OTP on the SOC

Some SOCs provides programmable OTPs (eg. for security, 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:

1. OTPs
   1. example: AXEL family processor (i.MX6) implements ConfigID using processor's OTP
   2. AXEL uses GP1 eFuse register to store ConfigID
2. NOR Flash SPI
   1. example: DIVA family processor (AM335x) implements ConfigID using NOR SPI (if present)
   2. DIVA and BORA use the first 32bytes OTP block on NOR SPI to store ConfigID (and its CRC32), UniqueID (and its CRC32)
3. I2C Eeprom
   1. 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)
   2. DIVA and BORA Lite use the first 32bytes on I2C EPROM to store ConfigID (and its CRC32), UniqueID (and its CRC32)
4. 1-wire
   1. example: latest AXEL Lite, 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:

U-Boot 2013.04-00010-gcb05b30 (Jun 26 2015 - 12:49:26)-xelk-2.1.0

CPU:   Freescale i.MX6Q rev1.5 at 792 MHz
CPU:   Temperature 47 C, limits (-40 C, 125 C), calibration data: 0xc0
Reset cause: POR
Environment: SPI Flash
I2C:   ready
DRAM:  2 GiB
Now running in RAM - U-Boot at: 8ff35000
NAND:  512 MiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
SF: Detected S25FL256S with page size 64 KiB, total 32 MiB
In:    serial
Out:   serial
Err:   serial
Power: found PFUZE100 (devid=10, revid=21)
SOM ConfigID#: 00000003
SOM UniqueID#: df646299:0b0579d4

For accessing these information on Linux procfs, the device tree must be modified (using u-boot fdt command): for example:

DIVA# setenv fdtfixup 'fdt addr ${fdtaddr}; run fdtfixup_configid'
DIVA# setenv fdtfixup_configid 'fdt set / som_configid ${som_configid#}; fdt set / som_uniqueid ${som_uniqueid#}; fdt set / cb_configid ${cb_configid#}; fdt set / cb_uniqueid ${cb_uniqueid#}'

Linux

It is possible to read the ConfigID/UniqueID via procfs; for example:

root@axel-lite:~# cat /proc/device-tree/som/configid && echo
00000003
root@axel-lite:~# cat /proc/device-tree/som/uniqueid && echo
df646299:0b0579d4
root@axel-lite:~#

Legacy device tree, has a sightly different procfs structure:

root@axel-lite:~# cat /proc/device-tree/som_configid && echo
00000003
root@axel-lite:~# cat /proc/device-tree/som_uniqueid && echo
df646299:0b0579d4
root@axel-lite:~#

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):

• All products have the same BOM with a single Config ID
• 

  ConfigID A

• 

  ConfigID A

• 

  ConfigID A

• 

  ConfigID A

• 

  ConfigID A

• 

  ConfigID A

In this case there are no problems to deploy a new SW update on the field: all products have the same HW configuration, then the same 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.

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.

• All products are similar BUT there are different Config ID between the 2 product versions
• 

  ConfigID A

• 

  ConfigID A

• 

  ConfigID B

• 

  ConfigID B

• 

  ConfigID A

• 

  ConfigID B

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:

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:

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

---