thingSoC Firmware Architecture
- Q: What is the thingSoC Firmware Meta Data Store (FDMS) ?
- All thingSoC Compliant boards contain a memory/storage device
containing data that identifies the board type, serial number, pin multiplexing,
and other setup information. This allows a thingSoC Compliant system to automatically discover
what boards have been installed into a system, and to configure itself properly to communicate with them.
thingSoC firmware is referred to as a "data driven architecture", because the memory/storage device contains only pure data, without any executable code that would be specific to a particular processor. The thingSoC Firmware Meta Data Store (FMDS) contains information that can be used across different hardware platforms, to support a wide variety of different processor types.
(i.e. low-power, high-speed, different architectures/vendors, etc.) - Q: Is the thingSoC Firmware Meta Data Store (FDMS) compatible with the Beaglebone Cape Manager?
- Yes. thingSoC Compliant devices implement the thingSoC thingSoC Firmware Meta Data Store (FDMS) mechanism, which is compatible with the Linux 3.8 Kernal and Device Tree Overlays. The thingSoC Firmware Meta Data Store (FDMS) mechanism implements additional features, however it is backward compatible with the Linux/Beaglebone Cape Manager.
- Q: What additional features does the thingSoC Firmware Meta Data Store (FDMS) support?
- The thingSoC Firmware Meta Data Store (FDMS) mechanism can implement additional features by allowing additional
"BLOBs" (Binary Level Objects) to be included in
the memory/storage device after the Raspberry Pie Hat "BLOB". For example, an
IPMI FRU
(Intelligent Peripheral Management Interface - Field Replaceable Unit) "BLOB" could be located immediately after the
Raspberry Pie Hat "BLOB", giving access IPMI format data as well.
Each "BLOB" type can be identified by a unique "Magic Word" sequence at the beginning of the "BLOB" data section. This mechanism allows for complete backward compatibility, while allowing for the support of many new "BLOB" types within thingSoC.
- Q: What type of memory device is used for the thingSoC Firmware Meta Data Store (FDMS)?
- That choice is up to the implementor, and may include I2C EEPROM, FLASH, NVSRAM, FRAM, or others.
For low cost applications with relatively fixed data storage needs, typically EEPROMs of the CAT24C256 types are used.
For applications that require a high data update/write to data storage, typically an NVSRAM or battery backed SRAM
would be used to avoid write wear leveling issues.
In many cases a FLASH based microprocessor may be used as a "smart" memory device, in place of a dumb storage device, like an EEPROM. This allows for "live updates" of meta data, such as the number of hours of operation, or other changing metrics.
There are really only three (3) requirements for the memory device used for the thingSoC Firmware Meta Data Store (FDMS)
- It be I2C bus compatible with 3.3V level signaling
- It be I2C bus addressable from addresses 0x50 to 0x57
- It appear as an I2C EEPROM (i.e. CAT24C256 compatible) register address model
- Q: What is the discovery algorithm for the thingSoC Firmware Meta Data Store (FDMS)?
-
(A simplified discovery algorithm in english)
(FDMS structure Magic Word is : 0xAA, 0x55, 0x33, 0xEE)The primary processor on the BASE level will use it's I2C1 Master port to :
- Read four (4) bytes from I2C Address 0x50, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the BASE Level - Read four (4) bytes from I2C Address 0x51, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the TEST Level 1 - Read four (4) bytes from I2C Address 0x52, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the TEST Level 2 - Read four (4) bytes from I2C Address 0x53, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the TEST Level 3 - Read four (4) bytes from I2C Address 0x54, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the EXPA Level 1 - Read four (4) bytes from I2C Address 0x55, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the EXPA Level 2 - Read four (4) bytes from I2C Address 0x56, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the EXPA Level 3 - Read four (4) bytes from I2C Address 0x57, Offset 0x0000 and compare to the Magic Word
If True, then a valid FDMS structure exists on the EXPA Level 4 - Read and Parse all valid FDMS structures for data, as needed
There are many other details covered in the thingSoC firmware specification, such as data integrity and checksum validation, as well as security (authentication keys are encrypted) and authentication.
- Read four (4) bytes from I2C Address 0x50, Offset 0x0000 and compare to the Magic Word
- Q: Is the thingSoC Firmware Meta Data Store (FDMS) accessible from the Host as well as the Target?
- Yes. thingSoC Compliant devices implement both a USB-to-UART Host Bridge as well as a USB-to-I2C Host Bridge.
This is important because it allows the Integrated Development Enviroment (IDE) running on the Host computer to read the thingSoC Firmware Meta Data Store (FDMS) as well as the Target processor. For example, this would allow something like the Arduino IDE to automatically determine the type of Target processor board installed, and be able to configure it automatically.