Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial Raspberry Pi 5 support #2914
Initial Raspberry Pi 5 support #2914
Changes from all commits
895fdbe
e810552
5d03e05
59d55d4
ff1b3bf
3260b08
a7d2cad
38bdab4
d6c6f5e
f6efd8d
8adb1dc
a0340ae
d3f1392
2475841
7542412
43a3f92
be15f28
e0fbd55
1d4d2dc
9da239e
dac5a03
dde3ec0
4bb5089
d9c488a
a23c36b
ad12f4e
5c404c8
46fc170
cb11ece
ced4a12
ec716c1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess the rpi-rf-mod overlays need testing first? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I've added now
BR2_PACKAGE_RPI_FIRMWARE=y
and an appropriate copy command.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 🤔 ..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
I noticed that
rpi-rf-mod-rpi1.dtbo
gets deployed (besidesrpi-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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's re-add them before merging and eventually address the rf-mod issues in another PR.