Getting the Raspberry Pi 4 GPU and 7-inch Touch Display 2 working was
quite challenging. Several kernel drivers are needed, beyond the
obvious VC4 and V3D, like voltage regulators and backlight controls.
Even with all the drivers enabled, I still had trouble getting
`/dev/dri/card1` (the display device, as opposed to `/dev/dri/card0`,
the 3D rendering device) to appear until I explicitly enabled the
`vc4-kms-dsi-ili9881-7inch` device tree overlay. I am not entirely sure
why this is necessary, since `display_auto_detect` supposedly should
have added this overlay automatically. I am also not sure how it would
work if I wanted to use an HDMI monitor instead of the DSI panel, but
fortunately, for this project, that's not necessary.
This commit introduces the _kiosk.service_ unit, which launches `sway`
to start a Wayland session, which in turn launches Firefox. The
`policies.json` file configures Firefox in a sort of kiosk mode,
disabling most features and blocking all but the desginated sites.
Unfortunately, running `firefox --kiosk` doesn't actually work: Firefox
apparently runs, but doesn't draw anything on the screen.
Note that we have to launch Firefox by its "real" path, since
`/usr/bin/firefox` is a Bash script, and Bash is not installed.
Fortunately, the wrapper script doesn't do anything we really care
about, so bypassing it is fine.
Unfortunately, even building Firefox with GCC fails:
> 3:30.02 [gecko-profiler 0.1.0] /../lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14/cstdlib:79:15: fatal error: 'stdlib.h' file not found
> 3:30.02 [gecko-profiler 0.1.0] thread 'main' panicked at tools/profiler/rust-api/build.rs:104:10:
> 3:30.02 [gecko-profiler 0.1.0] Unable to generate bindings: ClangDiagnostic("/../lib/gcc/aarch64-unknown-linux-gnu/14/include/g++-v14/cstdlib:79:15: fatal error: 'stdlib.h' file not found\n")
Clearly, something is misconfigured, because `stdlib.h` does indeed
exist. I am not sure what, though, and I am getting tired of messing
with this.
Fortunately, the official Gentoo binary package project has a build of
_www-client/firefox_ for ARM64. It has a rather different USE flag
configuration than what we did, though, so we have to pull in quite a
few more dependencies.
We can't just add _www-client/firefox_ to `install.packages` because
Aimee OS runs `emerge` with `--getbinpkgonly`, which implies
`--binpkg-changed-deps=y`. This since we want to build everything
_except_ Firefox locally, the dependency graph is quite a bit different,
so Portage ignores the binary package and will try to build
_www-client/firefox_ from source.
To work around this limitation, we need to install Firefox manually in
the `customize.sh` script in two phases. First, we install all of its
dependencies in the build root (`/usr/aarch64-…`), but not Firefox
itself, to get binpkgs for them. Then, we install _www-client/firefox_
in the target root (`/mnt/gentoo`) with the `--getbinpkg` and
`--usepkgonly` flags.
Hopefully, one day I can figure out how to cross-compile Firefox (and it
doesn't take days to build once I do), and we can remove this hackery.
Building _www-client/firefox_ fails fairly early with an error about not
being able to find `aarch64-unknown-linux-gnu-clang-19` to use as `CC`.
I have not been able to determine what is supposed to provide this
program/symlink, nor much information at all about cross-compiling with
Clang, really. We shall try building Firefox with GCC, since we know
that toolchain is complete.
Attempting to cross-compile Firefox will be rather challenging. It has
loads of dependencies, written in a variety of languages. Some issues
are more interesting than others. Notably, _dev-libs/nss_ needs to be
installed on the host in order to cross-compile itself, but its ebuild
does not specify this ([Bug 759127][0]). Also the build system for
_gnome-base/librsvg_ is broken: [Gentoo Bug 835758][1], [GNOME
Issue #810][2]. Cross-compiling _dev-libs/gobject-introspection_ is
also broken ([Bug 759127][3], [850895][4]).
With all of these changes, we can get to the point where Portage starts
building Firefox, it will take hours and all of my machine's resources,
so I haven't tested if will actually build. We shall see once Jenkins
tries it...
[0]: https://bugs.gentoo.org/759127
[1]: https://bugs.gentoo.org/835758
[2]: https://gitlab.gnome.org/GNOME/librsvg/-/issues/810
[3]: https://bugs.gentoo.org/850895
[4]: https://bugs.gentoo.org/751325
The `disableConcurrentBuilds` pipeline option tells Jenkins to force
subsequent builds _of the same job_ to wait in queue until the one
running has completed. This is sufficient when there is only one
branch/project in development at a time. In order to prevent multiple
projects from running simultaneously, we need to acquire a global lock;
all projects need to have this same option in order for it to be
effective.
Recompiling the entire OS for every build takes way too long for
development purposes. Since we build binary packages anyway, let's keep
them around between builds by storing them on a Kubernetes persistent
volume.
Eventually, I want add a build parameter to wipe out the binary package
storage to force a from-scratch build. We'll use that option for robust
periodic builds, once development has slowed down.
I don't know what this is for; I think it has something to do with
containers, possibly for `systemd-npsawn`? It spawns a bunch of
processes and wastes several megabytes of RAM.
Deleting the initial password for `root` so we can log in to the serial
console for debugging.
Enabling _wpa_supplicant_ to connect to WiFi automatically.
We need the Broadcom firmware from the _linux-firmware_ package (and
nothing else). We also need _wpa_supplicant_, to configure the WiFi
connection. Finally, we need to configure _systemd-networkd_ to manage
the network device.
Need to add `rootwait` because the Raspberry Pi SD card reader is really
slow and does not initialize in time for the kernel to load the root
filesystem from it.
Dustin