Mistake on this page? Email us

Device identifiers

To ensure that an update is correctly matched to your device, Device Management Update uses two additional unique identifiers to identify the "type" of device.

We recommend that these be RFC-4122 Type 5 UUIDs.

Vendor ID

The following use the vendor ID:

  • Device Management Update, to verify manifests.
  • Device Management Update service, to verify that only accounts associated with a particular domain name can sign manifests for the corresponding vendor ID.

We recommend deriving the vendor ID from the manufacturer's domain name using the algorithm in RFC-4122, Section 4.3.

Here is a Python example:

import uuid
vendor_id = uuid.uuid5(uuid.NAMESPACE_DNS, 'vendor.com')

A vendor ID is static - it does not change in the lifetime of the firmware - so you can typically build it into the firmware image. You can use the manifest tool to create a UUID that follows this convention:

manifest-tool init -d "vendor.com"

Class ID

Together with the Vendor ID, Device Management Update uses the device class to check that a manifest is compatible with a device.

We recommend that:

  • The device class ID conforms to RFC-4122, Type 5.
  • You use the vendor ID as the namespace. The ID within the namespace is arbitrary.
  • You use a model name and revision number as the ID.

For example:

import uuid
vendor_id = uuid.uuid5(uuid.NAMESPACE_DNS, 'vendor.com')
class_id = uuid.uuid5(vendor_id, 'widget X rev A')

A device class ID is static - it does not change in the lifetime of the firmware - so you can typically build it into the firmware image. You can use the manifest tool to create a UUID that follows this convention:

manifest-tool init -d "vendor.com" -m "widget X rev A"

Usage

Both of these parameters are stored in Device Management Update's configuration for a device. See the Update client section for more information on how to store these. When the Update client receives a manifest, Update client checks the class and vendor in the manifest to make sure they match the configured values.

Also, when a device connects to Device Management, Device Management receives and stores these parameters. Operators can then create device filters to find specific device types.

Together, these act as a "double check" for firmware compatibility - by both accurate cloud-based targeting using filters and a final check by the device itself.

Important Information for this Arm website

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies. If you are not happy with the use of these cookies, please review our Cookie Policy to learn how they can be disabled. By disabling cookies, some features of the site will not work.