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 |
Multimedia | |
---|---|
Connectivity | |
GPS |
No data |
Modem | |
Calls |
No data |
SMS |
No data |
Mobile data |
No data |
Miscellaneous | |
Sensors | |
Accelerometer |
No data |
Magnetometer |
No data |
Ambient Light |
No data |
Proximity |
No data |
Hall Effect |
No data |
Barometer |
No data |
Power Sensor |
No data |
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.
Ensure that you have chosen a suitable kernel during pmbootstrap init
, the "next" kernel is recommended for most devices and especially if you intend to later replace it with a #Custom kernel
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
).
After installation, the resulting GPT disk image can be found at ~/.local/var/pmbootstrap/chroot_native/home/pmos/rootfs/postmarketos-trailblazer.img
.
Qualcomm devices running U-Boot
For Qualcomm devices running U-Boot, install with:
pmbootstrap install --split --add my-device-firmware-package
And then flash with
fastboot 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
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.
Customising
Manually specify DTB
If your device uses devicetree but is not supported by dtbloader and doesn't have its own mechanism (e.g. U-Boot loading the DTB) to load one, you will need to customise the installation so that your devicetree is selected.
The simplest way to do this is to do the pmbootstrap install --no-image
and then:
echo 'deviceinfo_dtb="VENDOR/MY-BOARD" | sudo tee -a ~/.local/var/pmbootstrap/chroot_rootfs_postmarketos-trailblazer/etc/deviceinfo
Where VENDOR
is e.g. qcom
, meson
, etc. and MY-BOARD
is the name of the DTB with the extension removed (e.g. qcs6490-rb3gen2
.
Then perform the normal pmbootstrap install
(with any additional flags) to build the image.
Custom kernel
It is possible to use pmbootstrap's "envkernel" logic to use your own kernel instead of the standard one. This allows your to compile a kernel as you typically would, and then produce a kernel package from the build artifacts that will be included in your image (or can be installed to your board with pmbootstrap sideload
).
The process is documented in Developing_with_postmarketOS#Mainline_kernel, just use linux-next
as the name of the kernel package.