The only new thing in this version is the addition of a deprecation warning
when osk-sdl is installed in the initramfs.
Also see: https://gitlab.com/postmarketOS/pmaports/-/issues/2319
[ci:skip-build]: already built successfully in CI
Upstream boot-deploy (me, lol) removed generate_gummiboot,
and now generate_systemd_boot is used to configure both gummiboot and
systemd boot.
[ci:skip-build]: already built successfully in CI
EFI bootloader from systemd, with hacks to build it on Alpine/pmOS.
Cross compilation (using a meson cross file) is used for building
32-bit version on x86_64, for systems that have a 32-bit EFI. Everything
else assumes that the EFI arch matches the CPU arch.
Besides supporting all the archs we need, another major goal was to
minimize the number of changes to systemd's build system required to
build only the bootloader, so that maintaining/rebasing isn't *too*
painful...
I am adding this to the "main" category, because I don't think there's a
way to add it to Alpine. It requires cross compiling to x86 on x86_64
(to support 32-bit EFI on this arch), and Alpine doesn't support this.
It requires stuff in pmaports/cross.
--- Research notes ---
I started looking at all of this because I wanted to come up with a
single way to boot Linux via EFI, that supports all (or as many as possible)
devices in pmaports. I looked at quite a few different options, and have
some notes below about my observations and conclusions for each.
Of everything I looked at, systemd-boot was the clear winner that met
the most requirements ("pro" below) with the fewest downsides ("con"
below).
Using a Unified Kernel Image (UKI) was a close second place, however
systemd-boot can also support booting UKI images quite easily (while
also giving us more flexibility to boot other things easily too), so I
think it wins over UKI.
The capitalization (or lack thereof) of the "pro" and "con" markers
below is significant: "PRO" / "CON" are major pros or cons for each
point (e.g. a major downside that blocks using the option), and
"pro"/"con" are minor (e.g. a downside that I'm willing to overlook.)
---- Requirements ----
- Arch support:
- x86_64
- x86 (nice to have, but not sure if necessary...)
- armv7
- aarch64
- riscv64
- EFI support:
- support 32-bit EFI on x86_64 CPU (includes being able to build
32-bit .efi app on x86_64)
- Easy to configure
- Easy to maintain
- Any changes to the bootloader required to get it working in
pmOS
- Config for it
---- Evaluated options ----
------ grub ------
- (PRO) can target all required archs
- (CON) grub can't be installed in pmb chroot, it calls grub-install and
that fails due to something missing in /dev. Maybe this could be worked
around in pmb?
- (CON) grub-mkimage exe is integrated in grub package, grub-efi depends on
grub
- don't want to install all of grub just for 1 exe and/or the EFI modules
- downsides of installing all of grub is that I think it can mislead
users into thinking we use grub the "normal way". this might cause them
to have the wrong expectations and break pmOS boot on their
system
- have POC "fixing" this
- I'm not sure upstream Alpine will like this, it's ugly
- (CON) grub x86 EFI support for x86_64 is currently in pmaports, that's
pretty ugly.
- IMHO forking grub (or grub components) for this purpose signals
to me that grub is the wrong tool for this job
------- kernel's efistub -------
- (PRO) already included in the kernel, nothing else required
- (pro) initrd and dtb can be passed in the kernel cmdline...
however....
- (CON) kernel cmdline can only be set at compile time
- (con) not all kernels may have EFISTUB set?
- (con) can't do measured/secure boot
- (con) requires a fairly recent kernel on aarch w/ efi_zboot support
enabled since we compress the kernel
------- UKI -------
- (PRO) very simple, 1 file thing
- (PRO) supports adding dtb, setting kernel cmdline and so on
- (pro) can do measured/secure boot
- (CON) requires an EFI stub loader
- can't find a stub loader that meets all requirements (other than
the one from systemd-boot...)
- (con) requires efi-mkuki or dealing with objcopy directly (eww)
- (con) requires a fairly recent kernel on aarch w/ efi_zboot support
------- limine -------
- (PRO) easy to install/configure, already have boot-deploy and pmaports
patches
- (PRO) can be cross compiled easily
- evidence is in aports
- ...but I couldn't reproduce building aarch64 and riscv64 on x86_64
- (pro) can do measured/secure boot (I think?)
- (CON) doesn't target all required archs
- can't do "linux boot" on aarch64, only "chainload"
- what about using chainload everywhere?
- requires using efistub in kernel
- what about dtb= and upstream recommendation to not use it except for
debug?
- no kernel compression support on aarch64
- see efi-stub.txt kernel doc
- (CON) vendors libgcc to support cross compilation
- probably not a good idea to trust binaries produced in microsoft
github's CI for some random project
------- stubbyboot -------
- (PRO) a straight forward stub loader
- (pro) can do measured/secure boot
- (CON) doesn't target all required archs
- (CON) cross compiling doesn't work.
- gcc can't do 32-bit on x86_64 Alpine...
- gnu-efi-dev needs to be fixed to package both 32-bit and 64-bit on x86_64...
- have patch in ~/src/aports that kinda does it.. but needs to be
fixed/finished
- maybe limine-efi works with it?
- tried, but fails due to missing efilib.h in limine-efi
------- systemd-stub -------
- (PRO) another straight forward stub loader
- (PRO) many (many) people using it, as part of systemd-boot
- (pro) can do measured/secure boot
- (con) requires a fairly recent kernel on aarch w/ efi_zboot support
enabled since we compress the kernel
- (con) doesn't target all required archs
- but does claim to support most... missing armv7.. maybe it
works?
- (con) will end up maintaining some downstream patch to build it
- hopefully the patch (if I can even make a working one!) is not too
complex!
- (CON) can't be built outside of systemd's silly large build system.
- UPDATE: largely resolved this in pmaports
- was able to build for native arch!
- can't build 32-bit on x86_64, no gcc multilib support in Alpine...
Couldn't get clang to work properly, but maybe it can somehow...
- https://github.com/mintsuki/libgcc-binaries ? NO! (don't want
bootloader binaries that depend on code compiled by microsoft /
github...)
------- DIY stub / bootloader -----
- (PRO) **might** target all required archs and other meet
requirements
- (CON) lots of time required to learn, design, do, debug, test
- (CON) lots of time required to learn, design, do, debug, test
- (CON) lots of time required to learn, design, do, debug, test
- (CON) (get the hint yet???)
- (CON) written in C, probably (there's a rust EFI lib, lol...)
[ci:skip-build]: Already built successfully in CI
Backported from our development branch:
- SPI flash for chromebooks;
- support for samsung-manta (see !4406 for status);
- fix performance of video decoder which drastically reduces lag when streaming games.
[ci:skip-build]: already built successfully in CI
Adjust to change in Alpine that moved rockchip to single image:
https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/51827
Fix for:
ERROR: The following firmware binary does not exist in the rootfs_pine64-rockpro64 chroot: /usr/share/u-boot/rockpro64-rk3399/idbloader.img
[ci:skip-build]: already built successfully in CI
As with the firmware commit, no effort is done to keep firmware packages
working with downstream kernel.
[ci:skip-build]: already built successfully in CI
Package adsp, modem and wifi firmware for mainline. Compatibility with
downstream firmware is not kept on purpose, if somebody wants this,
please make some subpackage for it!
Tested on the V0.2 variant of the hardware which comes with some U-Boot
build preinstalled. I don't know if this will be the case for the final
version that will be shipped to customers, but the announecment would
imply so given that it says the device "incorporates a advanced [sic]
BIOS compatible with UEFI".
[ci:skip-build]: already built successfully in CI
This includes the "Alta" and "Solitude" boards, the latter of which I
also introduce a device package for in a later patch. It should be easy
to introduce support for the former, but I don't have the hardware to
test that on.
The two new patches have been merged and will be included in Linux 6.7
as I understand.
Using versions before 1.53.0 leads to various problems, from Alpine
v3.18 not appearing as supported, to some timezone file conflicts that
were fixed long ago. Bump the version to force users to use at least
that version.
Due to symlinks from linux-firmware-ath10k apk is now pulling in
linux-firmware-qcom which already provides a630_sqe.fw.
Since this file is not device/vendor-specific we can really use the file
from linux-firmware and not provide our own. For the record,
a619_gmu.bin also shouldn't be device-specific but currently
linux-firmware doesn't provide that one.
Also just pulling linux-firmware-qcom for this tiny file is pretty space
inefficient but due to the symlink dependency mentioned above, just
removing this file for now from the firmware package removes the file
conflict reported by apk:
ERROR: linux-firmware-qcom-20230919-r1: trying to overwrite lib/firmware/qcom/a630_sqe.fw owned by firmware-fairphone-fp4-adreno-20230215-r1.
[luca: update commit message to reflect dependency situation, update
packaging code a bit]
For some reason this isn't building, and it's blocking bpo + gitlab CI.
Let's revert it until someone had time to debug. In the meantime the
"upstream compat" monitoring check will fail.
This reverts commit 7608d18533.
[ci:skip-vercheck]
I cannot maintain this device because I do not have it, but it is
similar to the Pixel 3a, which I can maintain.
Move the kernel into a subpackage in case support for a different panel
(the Tianma NT37700F panel) is added.
[ci:skip-build]: already built successfully in CI
* Add kernel modules for display to modules-initfs
* Add GPU firmware and dependency for Vulkan
* Add qbootctl to mark the current A/B slot as successful
* Add bootmac to set the Bluetooth MAC address on boot
[ci:skip-build]: already built successfully in CI
Kconfig changes:
* Enable PWM_CLK and INPUT_PWM_VIBRA instead of INPUT_CLK_VIBRATOR for
Nexus 5
* Disable unused clock drivers
* Disable MEDIA_SUPPORT - currently unused
* Enable LEDS_TRIGGER_PATTERN for feedbackd
* Disable all of NET_VENDOR_* (which is Ethernet devices)
[ci:skip-build]: already built successfully in CI
It utilize msm-firmware-loader for minimize device specific firmware package.
It add necessary modules to initramfs for fix fde.
modem package has been removed in favor of soc-qcom-msm8953-modem.
30-gpu-firmware-files has been removed.
[ci:skip-build]: already built successfully in CI
