The FP6 has warm-reset itself at USB-C cable events and right after the
ADSP comes up with a charger attached, leaving nothing in the journal.
The kernel now carries a 4 MiB ramoops region (milos-linux adsp-recovery,
DTS node at 0xe2500000); build the pstore core, the ram backend and the
console + pmsg front ends in, so the previous boot's console and the
initramfs stage log survive a reset into /var/lib/systemd/pstore.
Verified on the dev phone 2026-09-15: records survive a PS_HOLD reset;
systemd-pstore archives them at the next boot.
The FP6 is 4x Cortex-A520 + 4x Cortex-A720 and this image boots nothing
else, so pass the compiler KCFLAGS="-march=armv8.6-a+fp16fml+aes+sha3+sm4
-mtune=cortex-a720". The stock arm64 build gives the compiler no arch flag
at all (so one image can boot any Armv8 board).
The string is what `gcc -march=native` derives on the phone, re-based on
armv8.6-a so clang can express the same set (clang has no flagm2/rcpc2/
frintts tokens; it reaches them through the architecture level). 8.6 is the
highest level whose mandatory set the phone exposes: 8.7 would assume WFxT
and 9.x SVE2, and neither is in its hwcaps or ID registers. clang emits
identical code for this and for -mcpu=cortex-a720+nosve+nomemtag; the
difference is only which system features (SPE, ETE, TRBE, FPAC) it knows
about, none of which generate code.
Verified on eef717f978f1 with the aport config: builds with zero warnings,
same module set as r100 (417), compat vDSO untouched, boots the dev phone
with a clean dmesg and a GREEN selftest. Record:
fp6 journal/base/captures/2026-09-05-mcpu-a720-verification.md.
The fingerprint stack needs /dev/tee0, and the pmOS config has never built the
driver -- so every session so far has loaded an out-of-tree module. That has
been recorded since 2 September as the release blocker, on the reading that
drivers/tee/qcomtee/Kconfig's `select QCOM_TZMEM_MODE_SHMBRIDGE` would flip
tzmem out of Generic mode and drag a boot+selftest round with it.
It does not. QCOM_TZMEM_MODE_SHMBRIDGE is a member of a choice block, and
Kconfig cannot select a choice member -- the statement is inert, and silently
so. Setting CONFIG_QCOMTEE=m and running olddefconfig against the tree
produces exactly one line of difference and leaves CONFIG_QCOM_TZMEM_MODE_
GENERIC=y, which is the mode every fingerprint measurement was taken on.
The driver is already in the base tree; the only reason it was out-of-tree
here was that nothing enabled it. Verified on the dev phone: the module built
from this config carries ZERO module parameters against the research build's
95, matching vermagic, and the phone boots on it with modules-load.d bringing
it up, /dev/tee0 present, fingerprintd ready and the enrolled template
loading. So the shipped module is upstream code on the tested tzmem mode.
Not pushed. Whether to ship QCOMTEE with tzmem in Generic mode is a separate
question with a real answer -- journal/tee warns about that mode -- and it is
now sequenceable on its own instead of forced by a select that does nothing.
pkgver 7.1.2 -> 7.2.0; config regenerated from the pmOS 7.2.0-r0 config
plus the FP6 bring-up fragment (same enables as before), olddefconfig'd
against the rebased combined-stable.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Kernel aport forked from pmaports 7.1.2-r0, repointed at milos-linux
combined-stable with the tested FP6 config (+EFI_ZBOOT for packaging);
imsd + nftables aports from the pending pmaports submission. build.sh
carries TODO(validate) markers - not yet run end-to-end.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
