Re: [PR PATCH] [Closed]: [NOMERGE] rpi-kernel: Support for Raspberry Pi 4

[Piraty <Piraty@users.noreply.github.com>]

[-- Attachment #1: Type: text/plain, Size: 4953 bytes --]

There's a closed pull request on the void-packages repository

[NOMERGE] rpi-kernel: Support for Raspberry Pi 4
https://github.com/void-linux/void-packages/pull/23541

Description:
**NOTE - This is not ready to merge,** but I am not sure whether it should be marked WIP. It does implement what I've described in the title; however, **it is likely that this change will break compatibility with rpi3.** I have not tested it on rpi3 since I do not own one. I may be able to borrow one, but testing from others on both rpi3/rpi4 would also be appreciated. If this does cause issues, then some changes may have to be made to accomodate this, either in the package itself (if possible) or more broadly in the way we currently build Raspberry Pi images.

The problematic part is that this package uses the architecture to guess which board / platform it is compiling for, which needs to be determined to [pick a defconfig](https://github.com/void-linux/void-packages/blob/6d91851983b83776e6eff5efcddf2e93f3018203/srcpkgs/rpi-kernel/template#L137). The problem with this in Void's build system is that RPi platforms support multiple ARM architectures. Conversely, this also means that some architectures are supported by more than one platform. In this case, I'm concerned about how aarch64 is supported by both rpi3 and rpi4, and I don't know if the defconfig for rpi4 (`bcm2711_defconfig`) is backwards-compatible with the one for rpi3 (`bcmrpi3_defconfig`).

In addition, this package has to pick one or more `.dtb` files corresponding to the platforms this will run on. All of the files for all platforms are shipped in the source tarball for the `rpi-firmware` package, but they get removed from that package and then are cherry-picked/readded in this package based on the guessed platform. This may not be much of an issue, since you can trivially include multiple `.dtb` files in the boot partition without issues, and each one is only ~25K uncompressed. I've chosen to remove the `.dtb` that is specific to rpi3 to see if the rpi4 alternative is compatible, but if not, feel free to add it back and see if it works in combination with the rpi4 defconfig.

If there are compatibility issues in rpi3 caused by this update, it can potentially be fixed by creating another (sub)package for building an rpi4-kernel, and then using that new package in `void-mklive` as part of a base in a new rpi4 platform.

A more robust solution would be to extend this idea across the entire Raspberry Pi family. Define a "build matrix" of platforms crossed with architectures. Have separate (sub)packages like `rpi3-kernel`, `rpi4-kernel` for each platform that selects the proper kernel configuration and targets all of the architectures supported by that platform (or whatever subset of the supported architectures we are also willing to support). This does come at a cost, since it potentially multiplies the number of packages and PLATFORMFS tarballs / images that need to be built, but it would be a great solution if it can be supported. Another benefit I see is that it makes picking images less confusing and setup less complex, since you can have a properly-configured prebuilt image for each platform/arch combination (ie. `armv6l-rpi`, `armv7l-rpi2`, `armv7l-rpi3`, `aarch64-rpi3`, `armv7l-rpi4`, `aarch64-rpi4`). 

Back on the topic of compatibility/testing: I do own an rpi4, and have verified that this works on that platform. Here is the script to reproduce the build. You can use this to build images to test the rpi3 as well:

```
# in new directory:
git clone https://github.com/agausmann/void-packages.git --depth 1 -b rpi4
git clone https://github.com/void-linux/void-mklive.git --depth 1
cd void-packages
git remote add upstream https://github.com/void-linux/void-packages
git fetch upstream
git rebase upstream/master
# configure stuff like XBPS_MAKEJOBS here if you want
./xbps-src binary-bootstrap
./xbps-src -a aarch64 pkg rpi-kernel
cd ../void-mklive
make
sudo ./mkrootfs.sh aarch64
sudo ./mkplatformfs.sh -r ../void-packages/hostdir/binpkgs/rpi4/ rpi3 void-aarch64-ROOTFS-*.tar.xz
sudo ./mkimage.sh void-rpi3-PLATFORMFS-*.tar.xz
```

Once this finishes, you should have two files, `void-mklive/void-rpi3-{PLATFORMFS-*.tar.xz,*.img.xz}`. You can unpack/flash either one to an SD card using whatever method you prefer, hook up a Pi 4, and it should boot into userspace successfully. USB, video, ethernet, and WiFi all seem to work fine; I haven't tested anything else.

For flashing, the [Raspberry Pi Imager](https://www.raspberrypi.org/blog/raspberry-pi-imager-imaging-utility/) works well in my experience, and is the method I used to verify that the image works. Select "custom OS" and pick the `.img.xz` file, then pick the SD card and click "Write". (By the way, I have another PR for an [`rpi-imager` package](https://github.com/void-linux/void-packages/pull/21103), if you want to give it a try in Void.)