Customizing hardware ID and auto-provision on first boot

Technical Support
, , ,
1

Context/wall-of-text:
We have a project in which we will have two components both of which contain the same Toradex SoM and which will be running very similar software. There will be minor differences between the two (for example, one has a display and the other does not).

I am in the process of looking at configuring OTA/offline updates and at this time I think it is in our interest to give these devices different hardware IDs should we need to differentiate them in the future (though at this time we do not expect this).

I have seen the Aktualizr article here

which discusses how to do this as a pre-baked option at image build time. However, I am wondering if it is possible to make this a “first-boot” or “install time” self-configuration.

For example, the image is flashed, and based on hardware differences (e.g. we detect a display or the state of a particular GPIO) I would like to set the hardware id to verdin-imx8mp-myproduct-display, but if there is no display, it would be set to verdin-imx8mp-myproduct-remote.

This in itself is not tricky, and could be easily done with a simple script of some kind to generate an appropriate .toml file if it does not already exist.

However, the pitfall is this:

Because this is a change to provisioning configuration, you will need to re-provision the device if you want to change it on a live device. It’s highly recommended to apply the changes to a custom TorizonCore image that you can use for production programming, following the instructions in Capture Changes in the Configuration of a Board on TorizonCore. That way, your devices will use their custom hardware ID as soon as they are programmed.

However, pre-baking it would necessitate some production overhead we are looking to avoid - separate images/part numbers/procedures and all the organization that comes with it - ideally it’s as simple as "pull a blank/new SoM off the shelf, install it in the device, and [connect to network or insert USB key] for a fully automatic unattended TEZI install that will finish in the correct configuration.

My actual question(s):
“At what point is the provisioning in a state where it is invalidated by the hardware ID change?” Is it immediately on execution of the torizoncore-builder images provision command (or tcbuild.yaml equivalent) when the image is built, or is it during the first boot of the installed image?

If the latter, does this mean that if I write a TEZI wrapup.sh to set the hardwareID on a just-flashed device, provisioning on reboot would still be successful?

If the former, is there a viable alternate way to do this as a “one shot” step during the initial flash without significant risk to the online data required during provisioning? (for example, a self-destructing script/container to execute the provisioning command and then remove itself from the device when done?)

2

Greetings @bw908,

“At what point is the provisioning in a state where it is invalidated by the hardware ID change?” Is it immediately on execution of the torizoncore-builder images provision command (or tcbuild.yaml equivalent) when the image is built, or is it during the first boot of the installed image?

The short answer is closer to the latter situation you presented. Though more specifically, the provisioning process happens when the update client (Aktualizr) runs for the first time. So technically the device can boot without the provisioning occurring, as long as the update client doesn’t start.

This is the service that starts the update client: https://github.com/toradex/meta-toradex-torizon/blob/dunfell-5.x.y/recipes-sota/aktualizr-torizon/files/aktualizr-torizon.service

Basically the update client will start if the provisioning material is found in the right place on the filesystem. Therefore normally if a device is “provisioned” then the update client will start automatically.

One idea is you could create an override for this service. You could add another conditional start condition such that the update client doesn’t start if your *.toml file doesn’t exist. This would give a chance for whatever startup script you have to determine the correct hardware ID and create that toml file.

Or alternatively, you orchestrate it such that your startup script runs and creates the toml file before the Aktualizr service even runs. But, basically provisioning won’t occur until Aktualizr runs for the first time. Which gives some flexibility in how you can approach this.

Best Regards,
Jeremias

3

Perfect, that is exactly what I needed to know. Thank you!

4

Glad I could help!