postmarketOS Trailblazer (postmarketos-trailblazer)
| Manufacturer | PostmarketOS |
|---|---|
| Name | Trailblazer |
| Codename | postmarketos-trailblazer |
| Model | Various |
| Type | generic |
| Hardware | |
| Chipset | Various |
| CPU | Various (Qualcomm, i.MX, Rockchip, etc...) |
| GPU | Various |
| Architecture | aarch64 |
| Software | |
| Original software | Various |
| Original version | Various |
| postmarketOS | |
| Category | testing |
| Pre-built images | yes |
| Mainline | yes |
| Flashing | |
|---|---|
| USB Networking | |
| Internal storage | |
| SD card | |
| Battery | |
| Screen | |
| Touchscreen | |
| Keyboard | |
| Touchpad | |
| Multimedia | |
| 3D Acceleration | |
| Audio | |
| Camera | |
| Connectivity | |
| WiFi | |
| Bluetooth | |
| Ethernet | |
| GPS | |
| Modem | |
| Calls | |
| SMS | |
| Mobile data | |
| Miscellaneous | |
| FDE | |
| USB-A | |
| HDMI/DP | |
| Sensors | |
| Accelerometer | |
| Magnetometer | |
| Ambient Light | |
| Proximity | |
| Hall Effect | |
| Haptics | |
| Barometer | |
| Power Sensor | |
Trailblazer is a generic port for ARM64
devices. It can run linux-next or Alpine's LTS/Mainline kernel and should otherwise be adjusted to support
as many devices as possible.
The goal of trailblazer's linux-next support is to motivate more upstream kernel development by providing a tighter feedback loop (patches land in linux-next weeks before they make it into mainline or stable), as well as encouraging more generic solutions to the device specific hacks we have in userspace.
On supported devices, trailblazer should reflect the current state of upstream. It allows users to easily appreciate what features are unavailable, and more importantly appreciate when a new feature does get added upstream.
How it works
The linux-next kernel package in pmaports is updated daily by our CI system, for example this pipeline produced this commit.
The kernel is based on the upstream defconfig, with the postmarketOS distro-specific options added, and some additional device drivers that aren't enabled by default. No kernel patches are allowed.
 |
Since linux-next is particularly prone to breaking, it's quite possible that trailblazer won't work on a given day. We don't yet have boot testing CI, but this would certainly be a useful addition. |
Contributors
Supported devices
Devices that have been tested with Trailblazer, note that this doesn't necessarily mean they work currently in the linux-next kernel, because as mentioned before, linux-next is particularly prone to breaking.
- OnePlus_6_(oneplus-enchilada)
- Generic_MSM8916_(qcom-msm8916)
- PINE64_PinePhone_(pine64-pinephone)
- Libre_Computer_Cottonwood_(librecomputer-cottonwood)
Users running Trailblazer
Installation
Use pmbootstrap to build your own installation image.
Installation will depend on the device and usecase, for Qualcomm devices running U-Boot, install with pmbootstrap install --split --add my-device-firmware-package and then flash with fastb
boot flash userdata $(pmbootstrap config work)/chroot_native/home/pmos/rootfs/postmarketos-trailblazer-root.img flash system $(pmbootstrap config work)/chroot_native/home/pmos/rootfs/postmarketos-trailblazer-boot.img.
|
If flashing to UFS storage on a Qualcomm platform, you must pass --sector-size 4096 to pmbootstrap install! |
For installing directly to the target medium (like an sdcard or USB stick -- or internal storage) do pmbootstrap install --disk /dev/sdX where sdX is the target device (which you can usually identify with lsblk).
Reporting bugs
In general, you should expect things to not work properly if using linux-next. If you aren't sure if an issue is already known, please ask in the postmarketOS devel Matrix or IRC channel. Please avoid filing issues on pmaports unless you're certain that it's a bug that either a) should be tracked by the postmarketOS community, or b) is an issue with the trailblazer target itself (like missing kernel modules, config options, or dependencies for a device).
Adding a new device
In general we want to support as many devices as possible, as such adding new modules to the initramfs, enabling new kernel modules, or installing additional firmware by default are all reasonable things to do.
If your device requires some additional services to run during boot, then this should be done in such a way that it doesn't affect other devices. For example the service should check that it's relevant for the underlying hardware and exit otherwise.
Firmware packages can be added as long as they don't introduce firmware with conflicting paths.