Hi, has anybody tried using Mender on Raspberry Pi 5? When can we expect the official support?
It’s not yet officially supported in Yocto either, but there have been some changes for porting it.
Hi @janaperic,
I am actively watching the situation there, but we are tied to Yocto upstream. Until a reasonably well maintained BSP (preferably in GitHub - agherzan/meta-raspberrypi: Yocto/OE BSP layer for the Raspberry Pi boards) emerges, Mender is not able to support it. The main problem is that the standard RPi boot flow does not use u-boot, so until that or something similar is in place, no A/B mechanism is possible.
Where have you seen any Yocto work being done on it?
Greetz,
Josef
Hi Josef,
Thank you for a quick reply.
I’ve come across this PR (Add Raspberry Pi 5 by floion · Pull Request #1237 · agherzan/meta-raspberrypi · GitHub) for adding RPi 5 config files to meta-raspberrypi, which gave me hope it will be merged soon.
If I understood correctly their blocker right now is U-Boot, which doesn’t yet support RPi 5, and I haven’t found any information on when that’s going to be solved.
I guess we will have to wait a bit longer 
Thanks again!
Hi @janaperic,
Thats a nice find! With the mentioned company working on it, u-boot support is probably not too far away too. So thats good news indeed. Maybe @leon-anavi can point us to a preliminary fork here or at least give a short update?
Greetz,
Josef
2 Likes
Yes, Raspberry Pi 5 support hasn’t been added to U-Boot yet. Recently Dmitry Malkin shared in the U-Boot mailing list 3 patches to add initial support for Raspberry Pi 5 to a state just to enter U-Boot’s command-line prompt through UART: U-Boot - Patchwork
Furthermore a U-Boot device tree will be required for Raspberry Pi 5 and a driver to read the microSD card. As far as I saw from the Linux kernel device tree and drivers, in Raspberry Pi 5 SDIO1 is used to drive the SD card therefore I expect something similar will be required in U-Boot. So there is work in progress but don’t hold your breath. Raspberry Pi 5 is quite different from Raspberry Pi 4 and it is not just a matter of a few configurations to get U-Boot fully working.
2 Likes
Some u-boot related remarks:
The Raspberry Pi bootloader does read and modify the device tree binary. This becomes a headache when running u-boot on top of the stock boot loader. I described some details here: Fix the dtb handling during A/B update · Issue #23 · lueschem/edi-pi · GitHub
Luckily, the Raspberry Pi folks baked the tryboot feature into the stock boot loader/kernel: firmware: raspberrypi: Add support for tryonce reboot flag · raspberrypi/linux@7576667 · GitHub
Based on this feature it is possible to implement a robust A/B mechanism without u-boot. I have done this for Debian and you can find the description here: Debian Bullseye Upgrade for the Raspberry Pi - edi
Another guy has done an integration with a custom update module too: GitHub - silitics/rugpi: An open-source platform empowering you to build innovative products based on Raspberry Pi.
The tryboot feature has proven to be very reliable on my Debian based installations. Once I get the Pi 5 I will also integrate into the edi-pi setup (GitHub - lueschem/edi-pi: Debian tool chain and image generation for Raspberry Pi 2, 3 and 4.). Also on Yocto I would prefer “tryboot” over u-boot.
1 Like
Hi @lueschem,
Thanks a lot for the input! Yeah the tryboot approach is definitely a valid alternative - just nobody has taken on it so far and/or contributed it. So in edi, there already is a state script setup respectively update module that offers these semantics? If so, can you point me to it? Baking it into a Yocto build should not be too complicated then.
Plus, the rugpi thing is neat, never heard of that so far. Thanks for bringing it up!
Greetz,
Josef
Hi,
In the mean time there are some very promising patches for Raspberry Pi 5 in the U-Boot mailing list by Ivan T. Ivanov which are based on previous patch set by Dmitry Malkin. With some modifications on top of them I was able to boot Poky images with meta-raspberrypi for Raspberry Pi 5. I am planning to integrate this in meta-mender-raspberrypi.
Best regards, Leon
3 Likes
With the edi setup I am actually using a script that fakes u-boot so that mender-client thinks that it is running on a normal u-boot based system. The script intercepts (with the help of the PATH variable) the calls to fw_setenv, fw_printenv and reboot.
I did not analyze how rugpi does achieve the same goal of matching mender together with tryboot using a custom update module.
1 Like
Now thats an interesting approach @lueschem. It definitely makes it easier to transplant into an existing Mender setup. Will need to play a bit with it.
By just looking at it, the tryboot approach needs a different partitioning scheme though? Or am I mistaken here, and boot+A+B+persistent should work?
Greetz,
Josef
Yes, this is what I am using and what was part of the initial offering. Now the bootloader also supports multiple boot partitions.
1 Like
Apologies if this bump isn’t allowed, but i’m curious if there’s been any word of progress on the Pi 5s since? I know that pi 5 support was recently merged into the meta-raspberrypi kirkstone branch (without u-boot support) but was wondering about u-boot specifically
From what i’ve been able to build from the u-boot master branch (after manually creating a config and specifying the bcm2712 dtbs), I’m able to get it to display the u-boot logo, but not much else. There might be some stuff potentially happening on UART but I don’t have a connector for it right now.
Just want to update this since i’m unsure if anyone else has attempted this yet and say with the latest u-boot RC release (2024.04-rc4) and some small changes to meta-raspberrypi and the meta-mender-raspberrypi patchfile, I was able to successfully boot a Raspberry Pi 5 with our Yocto layer, and deploy a test RootFS update with a successful switchover. I had to manually specify the devicetrees for the BCM2712, Pi 5 and the RP1, create a new config from rpi_arm64_defconfig to point to the bcm2712 devicetree, and comment out the following in arch/arm/dts/bcm283x-u-boot.dtsi to get a successful compile:
//&uart0_gpio14 {
// bootph-all;
//};
//&uart1_gpio14 {
// bootph-all;
//};
Note that this means no serial over GPIO for the u-boot process. (this is after adding `dtparam=uart0_console to config.txt to tell the kernel to choose the GPIO as uart0 instead of the dedicated header) Unsure if this affects the dedicated UART connector as I don’t have something for it on hand. Obviously this was done on a dedicated Pi 5 test device, and i’m unsure on how stable it is for the time being, but seems to be running quite well and has done multiple successful reboots.
I also want to mention that a 300MB RootFS update file only took 4 minutes to download and apply compared to the 11 or so minutes on a Pi 4 with the same RAM amount!
2 Likes
Very cool @pyxlwuff, thanks for sharing!
Do you have the adjusted layers in some public space so I can give it a spin too, or do you maybe even feel like preparing a PR to meta-mender-community?
Greets,
Josef
Hi Josef,
We’ve forked the layers we made adjustments to and you can find them here:
U-Boot
meta-mender
We’ve only done tests of this so far all together with our Pi 5, nothing with our Pi 4s yet. I’ll see if I can get the small changes to meta-raspberrypi up later today but the changes for that are:
- In
recipes-bsp/u-boot/u-boot_%.bbappend, comment out the following:
#COMPATIBLE_MACHINE:raspberrypi5 = "(-)"
In conf/machine/raspberrypi5.conf, add UBOOT_MACHINE = "rpi_arm64_config"
1 Like
Hi @pyxlwuff,
Just trying to replicate the setup, and u-boot gives me some headaches. Did you build kirkstone, or a later release? Reason I’m asking, The u-boot version there is 2022.01, and not playing along nicely with your repo. So I wonder which approach is the most elegant now.
Greets,
Josef
Hi Josef,
The version of u-boot i’m supplying in the reply above is 2024.04-rc4, which includes Ivan’s work on getting Pi 5 support in the bootloader. When I was setting this up I took the u-boot recipe files from meta-openembedded here into its own folder, then edited the SRC_URI and SRCREV to our fork with the dtsi files included, then added PREFERRED_VERSION_u-boot = "2024.04-rc4" to our distro config.
I’ll see if I can add something into a meta-mender-community fork to make reproducing a little easier sometime this week
Hi @pyxlwuff,
Ah, now I get it. No, I don’t think that’s necessary. Currently I envision the RPi5 support to go into a meta-mender-community/meta-mender-raspberrypi-community layer, and I am just trying to isolate the required pieces here.
Thanks you a lot!
Greets,
Josef
Managed to assemble everything! But u-boot is still not playing nice:
U-Boot 2024.04-rc4 (Mar 15 2024 - 11:01:39 +0000)
DRAM: 1020 MiB (effective 4 GiB)
mbox: Header response code invalid
RPI 5 Model B (0xc04170)
Core: 20 devices, 10 uclasses, devicetree: board
MMC: mmc@fff000: 0, mmc@1100000: 1
Loading Environment from MMC... *** Warning - bad CRC, using default environment
In: serial,usbkbd
Out: serial,vidconsole
Err: serial,vidconsole
mbox: Header response code invalid
bcm2835: Could not query MAC address
Net: No ethernet found.
starting USB...
No working controllers found
Hit any key to stop autoboot: 0
U-Boot>
Does this ring a bell? @pyxlwuff @leon-anavi