Raspberry Pi 5

Board Integrations Yocto Project
, ,
1

Board description

The Raspberry Pi 5 Model is a popular single board computer based on Broadcom SoCs. It is the most recent board within the Raspberry Pi family.

ID_230061_orig
ID_230061_orig1968Ă—1500 381 KB

URL: https://www.raspberrypi.com/products/raspberry-pi-5/

Wiki: https://elinux.org/RPi_Hub

Test results

Raspberry Pi 5 is a community contributed board integration, extending the range of supported RPi family boards to the newest and most powerful interation.

The Yocto Project releases in the table below have been tested by the Mender community. Please update it if you have tested this integration on other Yocto Project releases:

Yocto Project Build Runtime
scarthgap (5.0) :test_works: :test_works: 1

1. Disabled GRUB integration for ARM systems which is default in meta-mender. U-boot is still primary integration method for this board.

Build Means that the Yocto Project build using this Mender integration completes without errors and outputs images.

Runtime Means that Mender has been verified to work on the board. For U-Boot-based boards, the integration checklist has been verified.

Getting started

Prerequisites

  • A supported Linux distribution and dependencies installed on your workstation/laptop as described in the Yocto Development Manual
  • NOTE. Instructions depend on which Yocto version you intend to use.
  • kas installed and in your PATH.

Configuring the build

Setup Yocto environment

Create a directory for your mender-raspberrypi5 setup to live in and clone the

meta information.

mkdir mender-raspberrypi5 && cd mender-raspberrypi5

Clone the meta-mender-community layer:

git clone https://github.com/theyoctojester/meta-mender-community \
  -b scarthgap

Setup build environment

Change into the cloned repository and create a directory to hold the build:

cd meta-mender-community
mkdir my-raspberrypi5
cd my-raspberrypi5

Use kas to set up the build structure:

kas shell ../kas/raspberrypi5.yml

This opens a sub-shell which is initialized for the build process. You can close it using the exit command.

Configure Mender server URL (optional)

This section is not required for a successful build but images that are generated by default are only suitable for usage with the Mender client in standalone mode, due to lack of server configuration.

You can edit the conf/local.conf file to provide your Mender server configuration, ensuring the generated images and Mender Artifacts are connecting to the Mender server that you are using. To use Hosted Mender, add your tenant token and set the server URL like this:

MENDER_SERVER_URL = "https://hosted.mender.io"
MENDER_TENANT_TOKEN = "<copy token here>"

To get your tenant token:

  • log in to https://hosted.mender.io
  • click your email at the top right and then “My organization”
  • press the “COPY TO CLIPBOARD”
  • assign content of clipboard to MENDER_TENANT_TOKEN

Building the image

You can now proceed with building an image:

bitbake core-image-base

Replace core-image-base with your desired image target.

Using the build output

After a successful build, the relevant images and build artifacts are:

  • tmp/deploy/images/raspberrypi5/core-image-base-raspberrypi5.sdimg
  • tmp/deploy/images/raspberrypi5/core-image-base-raspberrypi5.mender

The disk image (with .sdimg suffix) is used to provision the device storage for devices without Mender running already. Please proceed to the official documentation on provisioning a new device for steps to do this.

On the other hand, if you already have Mender running on your device and want to deploy a rootfs update using this build, you should use the Mender Artifact files, which have .mender suffix. You can either deploy this Artifact in managed mode with the Mender server (upload it under Releases in the server UI) or by using the Mender client standalone mode.

References

  • The template files that are used by this setup can be found in mender-mender-community
  • The Mender integration layer for Raspberry Pi boards can be found in meta-mender.
  • The official Mender documentation explains how Mender works. This is simply a board-specific complement to the official documentation.

Known issues

Tested board versions

  • Raspberry Pi 5 4GB - Josef, 2024-03-25

If this post was useful to you, please press like, or leave a thank you note to the contributor who put valuable time into this and made it available to you. It will be much appreciated!

1 Like
2

Awesome work!

The Pi3 and Pi4 posts all say that the bootfiles, firmware, etc are not copies. Is that issue solved with the Pi5 giving us true a/b booting? (except for uboot i guess?)

3

Hi @mterwoord,

That’s one of the discrepancies between Debian-based and Yocto-based builds.

  • Debian: kernel is on A/B partitions, device trees and overlays are not. This is required for the firmware loader magic to take effect, e.g. load/modify the device tree and modify the cmdline through config.txt.
  • Yocto: kernel and device trees are on A/B partitions. u-boot and firmware which is in effect before u-boot are not.

Technically there could be a RPi-specific root filesystem Update Module which doesn’t require u-boot and the related magic altogether but uses the autoboot and tryboot features, but sadly this requires quite a bit more effort than I can invest at the moment. But I have it on the to-do list!

Greets,
Josef

4

Hi @TheYostoJester,

Thanks for the very fast answer.

You mention Debian places device trees and overlays NOT on the A/B partitions due to that being a requirement for the firmware loader. How is that not a requirement for Yocto-based builds?

I just ordered a Pi5 to do testing, but what I’m hoping I can do with the 5 is have all the files needing (kernel, device tree and overlays, etc) changes be on the A/B partitions. Does that work? I guess doing cmdline/config changes does need changes on the initial partition.

Thanks for answering!

Regards, Matthijs

5

Hi @mterwoord,

The key difference is that when using Yocto, we control the whole build. This means we know the required kernel configuration and device tree, and can make sure all of this is taken care for in the actual image. On Debian, the supplied golden image contains numerous unknowns. The most critical ones are

  • users expect to be able to use and modify config.txt
  • several RPi-specific start scripts expect the passed cmdline and partitions to behave in a certain way.

So fully technically speaking it is not a “Debian” requirement, it is required for the “Raspberry Pi OS” style user experience. One could possibly get rid of it, but it breaks a lot of use cases that we keep seeing.

As you stated you want kernel, DT and overlays on A/B, Yocto should have you covered already.

Greets,
Josef

6

Hi @TheYoctoJester ,

Thanks for clarifying.

Just making sure here: A/B fully works with changing kernel versions etc?

I guess I’ll have to think of what to do with my Pi3 stock now… :slight_smile:

Regards,
Matthijs

7

Hi @mterwoord ,

On Yocto, yes. If not, then it is a bug.

Nitpick: I remember at least one case where upgrading the firmware files was also required because of a hidden dependency. So those might show up again, sadly.

Greets,
Josef

8

Hi @TheYoctoJester ,

Can’t resist asking this: So on Pi3 and Pi4, the limitation of putting the kernel/dtb(o)'s on the primary partition still exists?

Thanks!

Regards,
Matthijs

9

Hi @mterwoord,

Only on Debianoids. Do you have any indication or post claiming that it applies to Yocto?

Greetz,
Josef

10

Hi @TheYoctoJester ,

For Pi 4, see Raspberry Pi 4 Model B - Yocto 5.0 "scarthgap" and later

For Pi 3, see Raspberry Pi 3 Model B/B+

Or am I just completely misunderstanding those statements?

Thanks for valueable insights!

Regards,
Matthijs

11

Besides that note, I currently use a script that copies the files to the boot partition before rebooting into the new partition, but that’s brittle: A wrong build then bricks the device.