Mender-convert and uboot partition vs RPi4 firmware

General Discussions
, , ,
1

Hi!

First question/discussion here, so be gentle. :slight_smile: Also, just wanted to say a BIG THANK YOU to the whole mender team and community for building an awesome set of tools.

tl;dr - Q. What’s the recommended best practice for updating RPi4 config.txt and other files (e.g. firmware) in /uboot when deploying rootfs updates (to A/B partitions) generated by mender-convert?

Background
I recently started evaluating Mender for RPi4, using the hosted.mender.io trial server together with mender-convert. Our preliminary (tyre kicking) work-flow is:

Fielded-Device Initialisation

  1. Grab clean older RasPi OS Lite distribution (raspios_lite_armhf-2020-05-28 due to MEN-3941).
  2. Use mender-convert with minimal/simple config to create a .img (and .mender artifact) which is then written to RPi4 sd-card.
  3. Power-up and authorise RPi4 “vanilla” device to mender server.

Golden System/Application

  1. Grab clean RasPi OS Lite distribution (recent raspios_lite_armhf-2020-12-04).
  2. Write to another sd-card and boot RPi4, boot.
  3. Run Ansible playbook against RPi4 to construct “golden” configuration, shutdown.
  4. Grab copy (dd) of RPi4 sd-card image.
  5. Use mender-convert with more interesting config/overlay, which nullifies machine-id, and installs a systemd one-shot service that renames host at same moment new machine-id is committed, so that our fielded devices don’t inherit device-specifics from golden image. This create a new .mender artifact which is then uploaded to Mender server. NOTE: As mentioned above, .img does not boot reference MEN-3941, so this is not of interest right now.
  6. Use Mender server to deploy new .mender rootfs artifact to fielded device.

The above works, and it’s great for our current experimentation with Mender. Some of the current gaps and issues (or potential future issues) I can foresee are:

  • The /uboot partition on the fielded device contains the firmware binaries and config.txt of the original/older system image, not the golden system. Given that we require specific config.txt settings (for HDMI output mode, etc.), and some system/kernel updates go hand-in-hand with new firmware, I’d like to be able to update the firmware files along with the rootfs.
  • I understand that handling RPi4 firmware updates is not robust (as described in this post and then this post).
  • I figure that it is possible to deploy file updates to /uboot (given that its writable), so Q. Is it possible to create a mender update artifact that includes a rootfs filesystem image AND a file update to `/uboot’?

In the not-too-distant future, I will look at building for mender with Yocto Project and perhaps also EDI, but that’s a future learning-curve. Q. Could a Yocto Project (and/or EDI) based build make the firmware /uboot update process more (if not absolutely) robust, compared with mender-convert?

Many thanks and apologies if these questions are already answered in other docs/topics.

Tom

2

Hi @wombat, thanks for getting in touch.

As you noted, the update of anything in the /uboot folder is not robust. This is due to the fact that there is no redundancy of that partition. Using the rpi-update-firmware option from your second post above is the closest we can get to allowing updates to that partition. It ultimately comes from the fact that the onboard firmware (before u-boot) loads the config.txt from the hard-coded partition and does not have support for redundancy. Unfortunately, using Yocto or EDI will not remove that limitation.

It’s possible to use a post-reboot state script to update files in that partition as part of a full image update but you will need to take care to properly handle rollback. Also note that if your system reboots, either as an intentional step of the update or due to a poorly timed power cycle, and the updated files in the /uboot partition are bad, then you may end up with a bricked board.

Drew