Initial Raspberry Pi 5 support #2914

agners · 2023-11-07T20:41:02Z

This produces a bootable system image. Currently no U-Boot is being used, the Home Assistant OS kernel is directly deployed onto the Raspberry Pi boot partition. System update support and A/B partition is not yet functional.

jens-maus · 2023-11-08T14:00:03Z

@agners

System update support and A/B partition is not yet functional.

Have you noticed/checked the relatively new tryboot capabilities of the RaspberryPi own bootloader? See https://www.raspberrypi.com/documentation/computers/config_txt.html#the-tryboot-filter

Perhaps this can be used as an alternative to waiting for U-Boot to be compatible with RaspberryPi5? Or is there already some early patchset for U-Boot which I am not aware of since I would also prefer to continue with using U-Boot as it is still more flexible...

agners · 2023-11-09T19:20:36Z

Have you noticed/checked the relatively new tryboot capabilities of the RaspberryPi own bootloader? See https://www.raspberrypi.com/documentation/computers/config_txt.html#the-tryboot-filter

Perhaps this can be used as an alternative to waiting for U-Boot to be compatible with RaspberryPi5? Or is there already some early patchset for U-Boot which I am not aware of since I would also prefer to continue with using U-Boot as it is still more flexible...

Yes I've noticed tryboot, and started to look into it. I think it can be done with tryboot, although it will need quite some adjustment. A second question would be if we would then stick with that (essentially supporting another bootloader) or move to U-Boot when available. If the second, then the question is if the above mentioned adjustment still would allow that. I hope I have a better idea once I've (tried) implementing it)

I am not aware of any progress on U-Boot side. A couple days back I reached out to some folks previously working on Raspberry Pi support for U-Boot, but no progress from what I've heard.

agners · 2023-12-08T12:00:08Z

So this implementation has a custom bootloader integration for RAUC using a script. I am deploying kernel and device-tree to the boot partition, maintaining two slots in a separate directory and using os_prefix to switch between the two. The regular A/B kernel partitions are unused (they do contain the kernel, but are not relevant). It is not entirely pretty but should be quite solid in general. It should be possible to migrate away from this scheme and uses the kernel partitions again, but it requires some type of bootloader.

What I am not happy about currently is 7f2c69b. It also changes the data layout. The only reason is the kernel size, but it should possible to use gzip compressed kernels instead, then we should get away with a 64MB boot partition.

Changing partition layout is a bit tricky. On one hand can (and do) make board specific partition layout. But we probably should increase regular kernel and rootfs partition as well... But then, does it help if we only do it for RPi 5? 🤔 🤷‍♂️

agners · 2023-12-08T14:10:42Z

Some notes wrt tryboot mechanism: To activate tryboot mechanism a reboot parameter must be passed (see the relevant Raspberry Pi documentation). By default, the reboot command is symlinked to systemctl. A reboot "0 tryboot" seems to generally work on Home Assistant OS.

However, with Supervisor installing the update, the reboot command is invoked through D-Bus by the Supervisor.

We could modify Supervisor to pass 0 tryboot as well (logind supports RebootWithFlags() or SetRebootParameter()). However, looking at how systemd passes the parameter, we can have the RAUC tryboot integration setting the flag directly (by writing /run/systemd/reboot-param). Testing shows this works with the way Supervisor invokes the reboot.

⚠️ However, when manually updating using rauc install, using just reboot seems to clear the reboot parameters! Instead systemctl reboot seems to preserve the parameters, so to test updates, one of these two options need to be used:

rauc install haos_rpi5-64-11.3.dev0.raucb
reboot "0 tryboot"
# or
systemctl reboot

This means that the new slot only gets booted when reboot is being used. This is a limitation of how tryboot works. 🤷‍♂️

sairon

That looks good and the changes are still quite sustainable, nice work!

There's bunch of minor issues I spotted on the first sight, see the comments in code. I will do some more testing here but so far the rest looks fine from the overall perspective 👍

buildroot-external/configs/rpi5_64_defconfig

sairon · 2023-12-08T15:21:41Z

buildroot-external/board/raspberrypi/rpi5-64/hassos-hook.sh

+    mkdir -p "${BOOT_DATA}/slot-A/"
+    cp "${BINARIES_DIR}"/*.dtb "${BOOT_DATA}/slot-A/"
+    gzip --stdout "${BINARIES_DIR}"/Image > "${BOOT_DATA}/slot-A/kernel_2712.img"
+    cp "${BINARIES_DIR}"/*.dtbo "${BOOT_DATA}/slot-A/overlays/" 2>/dev/null || true


We need BR2_PACKAGE_RPI_FIRMWARE=y in the board config, otherwise there will be no DT overlays, as we use those from that package.

Moreover, there should be almost always some overlays (at least in HAOS) - and this currently just fails because the target directory doesn't exist, so even the rpi-rf-mod overlays don't get copied.

I guess the rpi-rf-mod overlays need testing first? 🤔

Ok I've added now BR2_PACKAGE_RPI_FIRMWARE=y and an appropriate copy command.

That being said, I wonder if we should do this differently: IMHO either we consider device tree and device tree overlays firmware, and we should both take from there, or we should build both and deploy our builds 🤔 ..

If we have to pick from those two options, then I vote for using self-built DTBs and overlays. We have to build and supply DTB for Yellow anyway and having the rest built from sources is IMHO more flexible and easier for maintenance than using those from the RPi repo.

Anyway it's been like this for ages and there's no urgency for changing that, but good point.

We have to build and supply DTB for Yellow anyway and having the rest built from sources is IMHO more flexible and easier for maintenance than using those from the RPi repo.

So far we build and supply extra overlays through the rpi-rf-mod package, which is Homematic specific (speaking of which, maybe we should make that more clear in that package name 🤔 ). But other than that we do not supply overlays from the main Linux kernel source tree so far.

IMHO, the current situation is bad, as we mix the device tree from kernel source and overlays from the firmware.

Technically, the device tree is supposed to be provided by the machine's firmware. Like in the x86 world the ACPI tables are part of the BIOS. So there is definitely an argument to make that we should deploy device tree and kernel from the Raspberry Pi provided directory.

However, in the Arm world the boards are much more diverse, and quite often firmware (or part of the firmware) is bundled with the OS. That is also the case in Home Assistant OS: We deploy machine firmware along with the OS (and not just the device trees and overlay, but also Raspberry Pi's start4.elf, or U-Boot which on some boards can be seen as firmware). Now where the individual components of the "firmware" come from are almost implementation detail: The Raspberry Pi device trees and overlays are maintained in their Linux kernel source tree anyway. It is only a matter of do we deploy their pre-built one or do we deploy our own builds.

Deploying our own builds gives us more flexibility and proves to be less confusing/error-prone (as often the newer Linux kernel benefits from a newer/matching device tree).

So with this in mind, I agree let's deploy overlays from our build.

It seems that Buildroot doesn't support that use case yet. But it is a fairly simple extension for the Buildroot build system: home-assistant/buildroot#18.

So far we build and supply extra overlays through the rpi-rf-mod package, which is Homematic specific (speaking of which, maybe we should make that more clear in that package name 🤔 ). But other than that we do not supply overlays from the main Linux kernel source tree so far.

Sorry, but didn't follow the discussions closely enough. So what is the exact issue with the rpi-rf-mod since I noticed that you removed its CONFIG options from the rpi5 config file? In fact, it perfectly builds and runs with a rpi5 and the device tree overlay is working nicely AFAICS.

IMHO, the current situation is bad, as we mix the device tree from kernel source and overlays from the firmware.

I am not really sure if this is exactly the case for the RaspberryPi stuff. In fact, AFAIK even for RaspberryPiOS the makers are not directly using the in-tree device tree overlay stuff but rather uses the pre-build rpi-firmware dtbo files from their repository. So I am quite unsure if this would not construct an additional issue here if you guys would now switch to using the dtbo files from the kernel tree rather than pulling them from the rpi-firmware package.

And again. why is disabling/removing the rpi-rf-mod.dtbo required ATM?

In fact, it perfectly builds and runs with a rpi5 and the device tree overlay is working nicely AFAICS.

Ok, I wasn't aware that this got tested already, so we can re-enable it if it's known to be working. However, with just these two set:

BR2_PACKAGE_RPI_RF_MOD=y BR2_PACKAGE_RPI_RF_MOD_DTS=y

I noticed that rpi-rf-mod-rpi1.dtbo gets deployed (besides rpi-rf-mod.dtbo), which I think is just wrong for Raspberry Pi 5? This might be just a config issue, not sure.

Btw, you typically find the rationals behind a change in the individual commits (46fc170 in this case).

@jens-maus any thought on the rpi1 mod file? It came in with this commit 9582183.

I am fine re-adding the two config symbols above, but I think we should cleanup the rpi-rf-mod package.

Let's re-add them before merging and eventually address the rf-mod issues in another PR.

buildroot-external/board/raspberrypi/rpi5-64/cmdline.txt

buildroot-external/rootfs-overlay/usr/libexec/hassos-persists

buildroot-external/board/raspberrypi/rpi5-64/rootfs-overlay/usr/lib/rauc/rpi-tryboot.sh

buildroot-external/board/raspberrypi/rpi5-64/hassos-hook.sh

Use sed to append the new cmdline parameter to the first line.

This allows us to use the os_prefix feature to switch between slot A and B. Compared to the boot_partition option, this option allows to use a shared config.txt and cmdline.txt, which makes it more like how HAOS currently works on other Raspberry Pis.

This makes sure we can store up to three kernels (slot A, B and an temporary one while installing the OTA update).

This reverts commit 7f2c69b.

Co-authored-by: Jan Čermák <[email protected]>

Only match actual hexadecimal characters.

* buildroot fd1dc86f40...f13ad03408 (1): > linux: add in-tree device tree overlay support

No Raspberry Pi 5 specific device tree overlays are available, drop RPi RF mod for now.

* buildroot f13ad03408...07e08e01b2 (1): > linux: fix add in-tree device tree overlay support

sairon

Looks good enough (or even better!) for beta testing - let's merge it to dev to make testing easier 🎉

This reverts commit 46fc170.

mpadinhabrandao · 2023-12-12T13:49:03Z

Shall we have a Christmas present? 🎁

Great work everyone 🎊

KayGundhardt · 2023-12-18T12:10:29Z

Hello everyone,

Two things first:

I would like to thank you very much for all your hard work: especially for finishing the beta so quickly. Really great!
I'm just a user and have no programming skills whatsoever.

Buuuuut I've been a very enthusiastic HA user for a very long time and would be happy to make my modest little contribution:

:)

Tried to get the beta running on my RPI5: attached is the log. Maybe this will help someone?

Let me know if I've done something wrong or can do something else for you!

Best wishes

Kay

logs.txt

agners · 2023-12-18T13:32:42Z

Thanks for using Home Assistant 😄

Make sure to change to the beta or dev channel first. There is quite some discussions around it in the Community post e.g. #2844 (comment).

agners added the board/raspberrypi Raspberry Pi Boards label Nov 7, 2023

home-assistant bot added the cla-signed label Nov 7, 2023

agners force-pushed the add-rpi5 branch from 34a5f67 to 045de80 Compare December 8, 2023 11:52

agners marked this pull request as ready for review December 8, 2023 11:54

agners changed the title ~~WIP: Initial Raspberry Pi 5 support~~ Initial Raspberry Pi 5 support Dec 8, 2023

sairon reviewed Dec 8, 2023

View reviewed changes

agners requested a review from sairon December 8, 2023 17:45

agners added 19 commits December 11, 2023 12:00

Add initial Raspberry Pi 5 buildroot config

895fdbe

Add machine-id support via cmdline.txt

e810552

Add new entry if entry is missing

5d03e05

Don't overwrite cmdline.txt when adding machine-id

59d55d4

Use sed to append the new cmdline parameter to the first line.

Skeleton script for RAUC custom bootloader interface

ff1b3bf

Deploy new kernel/device-tree to correct slot on installation

a7d2cad

Increase boot size to 128MB

38bdab4

This makes sure we can store up to three kernels (slot A, B and an temporary one while installing the OTA update).

Initial tryboot implementation using os_prefix

d6c6f5e

Make sure to delete the old slot completely

f6efd8d

Add Busybox xargs for tryboot bootloader script

8adb1dc

Compare tryboot bootloader file silently

a0340ae

Revert "Increase boot size to 128MB"

d3f1392

This reverts commit 7f2c69b.

Use compressed kernel

2475841

Address shellcheck

7542412

Address shellcheck issue in rauc-hook

43a3f92

Fix shellcheck for rpi-tryboot.sh

be15f28

Do not follow source - it gets checked separately

e0fbd55

Correctly set the slot to boot

1d4d2dc

agners and others added 9 commits December 11, 2023 12:00

Apply suggestions from code review

9da239e

Co-authored-by: Jan Čermák <[email protected]>

Drop serial console from default cmdline.txt

dac5a03

Resync rpi5_64_defconfig with rpi4_64_defconfig

dde3ec0

Improve machine-id match

4bb5089

Only match actual hexadecimal characters.

Deploy firmware overlays to OS prefix directory

d9c488a

Add Raspberry Pi 5 to documentation

a23c36b

Bump buildroot

ad12f4e

* buildroot fd1dc86f40...f13ad03408 (1): > linux: add in-tree device tree overlay support

Install device tree overlays from Kernel sources

5c404c8

Drop RPi RF modules for now

46fc170

No Raspberry Pi 5 specific device tree overlays are available, drop RPi RF mod for now.

agners force-pushed the add-rpi5 branch from 8271658 to 5c404c8 Compare December 11, 2023 11:02

agners added 2 commits December 11, 2023 21:49

Use Raspberry 5 specific identifiers for Supervisor/OS Agent

cb11ece

Bump buildroot

ced4a12

* buildroot f13ad03408...07e08e01b2 (1): > linux: fix add in-tree device tree overlay support

sairon approved these changes Dec 12, 2023

View reviewed changes

Revert "Drop RPi RF modules for now"

ec716c1

This reverts commit 46fc170.

agners merged commit 8e1016d into dev Dec 12, 2023
2 checks passed

agners deleted the add-rpi5 branch December 12, 2023 12:19

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Initial Raspberry Pi 5 support #2914

Initial Raspberry Pi 5 support #2914

agners commented Nov 7, 2023 •

edited

Loading

jens-maus commented Nov 8, 2023

agners commented Nov 9, 2023

agners commented Dec 8, 2023

agners commented Dec 8, 2023

sairon left a comment

sairon Dec 8, 2023

agners Dec 8, 2023

agners Dec 8, 2023

agners Dec 8, 2023

sairon Dec 11, 2023

agners Dec 11, 2023

jens-maus Dec 11, 2023

agners Dec 11, 2023 •

edited

Loading

agners Dec 12, 2023

sairon Dec 12, 2023

sairon left a comment

mpadinhabrandao commented Dec 12, 2023

KayGundhardt commented Dec 18, 2023

agners commented Dec 18, 2023

Initial Raspberry Pi 5 support #2914

Initial Raspberry Pi 5 support #2914

Conversation

agners commented Nov 7, 2023 • edited Loading

jens-maus commented Nov 8, 2023

agners commented Nov 9, 2023

agners commented Dec 8, 2023

agners commented Dec 8, 2023

sairon left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

agners Dec 11, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sairon left a comment

Choose a reason for hiding this comment

mpadinhabrandao commented Dec 12, 2023

KayGundhardt commented Dec 18, 2023

agners commented Dec 18, 2023

agners commented Nov 7, 2023 •

edited

Loading

agners Dec 11, 2023 •

edited

Loading