Since each build system had different fit keys, we ended up with different bootloaders. Devices flashed with key1 only ota upgrade to fit images signed with key1 and devices and vice versa.
Wait let me try to understand this point since I’m still a little confused. So you had one build with one set of keys, then when you did your build on the cloud VM for azure a second set of keys was used instead, causing this confusion.
If that is the case, would it not just make more sense to use the same set of keys? You can just take the keys from your first build system and share them with the second. This would be a lot better for maintenance than having 2 sets of keys floating around and trying to manage which device is using which set of keys. I mean for your current devices I guess this doesn’t help since you can’t re-flash them cause they’re closed, but I mean going forward.
Also, how did your devices get into this state to begin with where they have a mismatching bootloader? Were the devices originally flashed with the OS image from build system 1, and then you did an OTA update for just the OS from build system 2?
In any case to do a bootloader update with your custom bootloader you just need to upload your own bootloader binary. However, this needs to be done in a certain way. First of all you can upload your bootloader binary using TorizonCore Builider like so:
torizoncore-builder platform push --credentials credentials.zip --hardwareid verdin-imx8mp-bootloader --custom-meta <json-blob> imx-boot
Important things to note here, the --hardwareid must be of the form “(name of module)-bootloader”. So in this example if the device is a Verdin i.MX8MP then the hardwareid is “verdin-imx8mp-bootloader”. Also the name of the bootloader binary might be different depending on the SOM, for the Verdin i.MX8MP the binary is called “imx-boot”.
Finally, the most important detail is the json information passed to the --custom-meta flag. This json information should be of the form:
"bootloader": {
"ddOptions": "seek=0",
"dtVersion": "2022.04-6.2.0-devel+git.0e1f11392251",
"env": {
"type": "embedded",
"resetOnUpdate": true,
"embeddedOffset": 1005975,
"embeddedSize": 4130,
"keepVars": null,
"setVars": null
}
}
Of course pass it to the tool as a one-liner json. i just presented it as multi-line for readability. Now the values in this json will be specific to your bootloader. In your Yocto build, in the output directory where all your build output is, there should be a file called u-boot-ota.json. The file contents should look something like this:
{
"ubootversion": "2022.04",
"ubootrelease": "2022.04-6.4.0-devel+git.dc27426aa417",
"envoffset": 1025146,
"envsize": 4128
}
This contains the values that you should use for your json that you pass to --custom-meta:
ubootrelease → dtVersionenvoffset → embeddedOffsetenvsize → embeddedSize
Every other field in the json can be the same as what I showed in my example json above. It’s important that these values correspond to the bootloader binary that you will upload. If these do not match the update will probably fail or not work correctly.
Best Regards,
Jeremias
