The proposed definition for a Component Identifier (see #4), is a value that identifies the target for a firmware image within a specific device.
Analysis
Whatever scheme is used for component identification for this API, there will need to be a mapping to the firmware identification scheme used by the Update Server and the protocol between the Server and the Client.
In earlier versions of the specification, the Image Id was a 128-bit GUID, following the pattern used by the UEFI UpdateCapsule() API.
There was no significant advantage to making the identifier globally unique, given that the update process will use the device model information to discover and validate firmware updates for the system.
The required scope of the proposal component identifier is the device, allowing the Client to target a firmware update to the appropriate Component. Typically, we expect that the mapping will be the same across all devices that are the same model/make, but may be allocated in common by a device vendor across a family of devices.
For this use, an 8-bit integer is probably sufficient. However, the values are allocated by the implementation, and are not present in data structures defined by the specification, so a wider integer type would also be a reasonable choice.
Comparison
Both TF-M and the v0.7 specification define the Image Id type as uint32_t.
Proposal
We propose to define this type as:
typedef uint8_t psa_fwu_component_t;
Is this a sufficient size for the required use?
Is there benefit in keeping the size of this type small?
Is there benefit in a wider type, providing a larger range of values?
The proposed definition for a Component Identifier (see #4), is a value that identifies the target for a firmware image within a specific device.
Analysis
Whatever scheme is used for component identification for this API, there will need to be a mapping to the firmware identification scheme used by the Update Server and the protocol between the Server and the Client.
In earlier versions of the specification, the Image Id was a 128-bit GUID, following the pattern used by the UEFI
UpdateCapsule()API.There was no significant advantage to making the identifier globally unique, given that the update process will use the device model information to discover and validate firmware updates for the system.
The required scope of the proposal component identifier is the device, allowing the Client to target a firmware update to the appropriate Component. Typically, we expect that the mapping will be the same across all devices that are the same model/make, but may be allocated in common by a device vendor across a family of devices.
For this use, an 8-bit integer is probably sufficient. However, the values are allocated by the implementation, and are not present in data structures defined by the specification, so a wider integer type would also be a reasonable choice.
Comparison
Both TF-M and the v0.7 specification define the Image Id type as
uint32_t.Proposal
We propose to define this type as: