- Oct 18, 2023
-
-
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
-
This reverts commit 72e55aae, which was itself a revert of this change
[ci:skip-build]: Already built successfully in CI -
-
-
- Oct 16, 2023
-
-
[ci:skip-build]: already built successfully in CI
-
This was missed in the original c720400e ("google-sargo: add q6voiced config (MR 4412)"), then pointed out by craftyguy when reviewing the full bonito port. Link: https://gitlab.com/postmarketOS/pmaports/-/merge_requests/4318#note_1587356675 [ci:skip-build]: already built successfully in CI
-
[ci:skip-build]: already built successfully in CI
-
[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
-
Fixes #2303 [ci:skip-vercheck] [ci:skip-build]: changing source location only
-
- Oct 15, 2023
-
-
[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
-
Oliver Smith authored
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
-
- Oct 13, 2023
-
-
[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!
-
-
Clayton Craft authored
-
- Oct 12, 2023
-
-
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.
-
linux-firmware-amlogic doesn't exist. The "vdec" firmware actually resides in linux-firmware-meson. [ci:skip-build]: already built successfully in CI
-
linux-firmware-amlogic doesn't exist. The "vdec" firmware actually resides in linux-firmware-meson.
-
Required for cross compiling 32-bit EFI apps/bootloaders on x86_64 [ci:skip-vercheck] [ci:skip-build]: already built successfully in CI
-
-
Oliver Smith authored
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]
-
Clayton Craft authored
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 7608d185. [ci:skip-vercheck]
-
- Oct 11, 2023
-
-
Clayton Craft authored
The others were upgraded in 5e42745c
-
The maintainer line should only be present in APKBUILDs, not other files in the package. [ci:skip-build] already built successfully in CI
-
The maintainer line should only be present in APKBUILDs, not other files in the package.
-
- Oct 10, 2023
-
-
[ci:skip-build]: Already built successfully in CI
-
- Oct 09, 2023
-
-
Affe Null authored
[ci:skip-build]: already built successfully in CI
-
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
-
Package the zap shader firmware needed on this device.
-
Kconfig changes: * Enable DRM_PANEL_RAYDIUM_RM692E5 * Enable TYPEC_MUX_FSA4480 * Enable TYPEC_MUX_PTN36502 * Disable DRM_SIMPLEDRM
-
Oliver Smith authored
[ci:skip-build]: already built successfully in CI
-
[ci:skip-build]: already built successfully in CI
-
- Oct 08, 2023
-