rpi2-fedora-image-builder
rpi2-fedora-image-builder copied to clipboard
Kernel updates
What is the best solution to kernel updates? dnf
tries hard with kernels from the official repo but it won't work at the moment.
Because the RPi kernel contains out of tree drivers, updates will need to come from the raspberrypi/firmware repo for now.
To handle the "dnf update" case, we could add exclude=kernel* to the dnf.conf so that it doesn't try to update the kernel packages.
Might be handy to write a script that would pull the new /boot contents from github, like "update-rpi-boot" or something. PRs welcome!
@spartacus06 you being a RH guy, do you have any knowledge - or an educated guess - about RPi support landing into the tree any time soon?
I have not looked closely to see what RPi is carrying out of tree and what the effort is to get those parts upstream.
A quick look, they have about 106 commits out of tree vs 4.1.1
$ git log v4.1.1..rpi/rpi-4.1.y | wc -l
106
Looking at the diff, they still have the majority of their device tree, arch platform/machine tree, and device drivers out of tree. A lot of work still left to do getting all that upstream :-/
They also have some commits in the tree which tune the kernel for the raspberry pi, such as disabling memory cgroups unless explicitly enabled on the cmdline, which would not be acceptable as-is upstream.
Looking at the silver lining though, it is nice that they continue to rebase :)
Right, I'm not holding my breath then :) Thank you very much.
@sjenning Any improvement on the situation with kernel 4.5?
@Conan-Kudo
$ git log v4.5-rc6..rpi/rpi-4.5.y | wc -l
140
$ git diff --stat v4.5-rc6..rpi/rpi-4.5.y
...
401 files changed, 116468 insertions(+), 2899 deletions(-)
The out of tree changes are still quite significant, unfortunately.
@sjenning AFAIK, it should be significant because the approach being done for upstream is not the same as what the RPi people are doing. According to Eric Anholt, he's doing work in a branch he forked from rpi2 4.5.y kernel.
@Conan-Kudo that project seems to be largely focused on the graphics related components (drm/vc4). It doesn't seem like that tree is any closer to upstream.
@sjenning it also has updated code for initializing the device (hence the -boot at the end of the name).