sun50i-h6: fix secondary CPU bring-up failure and clean up dangling series.armbian reference

[Copilot]

Changes

• Removed the dangling add-initial-support-for-orangepi3-lts.patch reference from series.armbian for consistency with the actual state of patches.armbian/. Note: series.armbian is not applied by the build system — only series.conf and patches placed directly in the root of the sunxi-6.12/ directory are applied.

• Removed kaslr-seed = <0xfeedbeef 0xc0def00d> from dt/sun50i-h6-orangepi-3-lts.dts to fix secondary CPU bring-up failure.

Root Cause Analysis

The boot log showed all three secondary CPUs (CPU1–CPU3) failing with failed in unknown state : 0x0, meaning they never write to secondary_data.status — i.e., they never execute any kernel code despite PSCI CPU_ON returning success (each times out after exactly 5 seconds).

The kaslr-seed property in the DTS was enabling KASLR, which in Linux 6.12 ARM64 forces KPTI (Kernel Page Table Isolation) on, as confirmed by the boot log:

KASLR enabled
CPU features: kernel page table isolation forced ON by KASLR
CPU features: detected: Kernel page table isolation (KPTI)

KPTI adds a trampoline page-table transition to the ARM64 secondary CPU startup path (secondary_startup_64). A failure in this trampoline produces exactly the observed 0x0 state symptom.

The sunxi-6.15 version of the same DTS (add-initial-support-for-orangepi3-lts.patch) does not include kaslr-seed, which aligns with this fix. The removed seed was also a fixed constant (0xfeedbeef 0xc0def00d) rather than a truly random value, so it provided deterministic rather than meaningful KASLR randomisation.

Note

Hardware testing is needed to confirm that secondary CPUs come online after this change.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[MichaIng]

@copilot here is the kernel log until the relevant CPU init failures:

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 6.12.74-current-sunxi64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04.1) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP Thu Feb 19 15:29:56 UTC 2026
[    0.000000] KASLR enabled
[    0.000000] Machine model: OrangePi 3 LTS
[    0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
[    0.000000] NUMA: Faking a node at [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] NODE_DATA(0) allocated [mem 0xbfbd36c0-0xbfbd577f]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000040000000-0x00000000bfffffff]
[    0.000000] cma: Reserved 128 MiB at 0x00000000b5a00000 on node -1
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.5
[    0.000000] percpu: Embedded 33 pages/cpu s96728 r8192 d30248 u135168
[    0.000000] pcpu-alloc: s96728 r8192 d30248 u135168 alloc=33*4096
[    0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[    0.000000] Detected VIPT I-cache on CPU0
[    0.000000] CPU features: kernel page table isolation forced ON by KASLR
[    0.000000] CPU features: detected: Kernel page table isolation (KPTI)
[    0.000000] CPU features: detected: ARM erratum 845719
[    0.000000] alternatives: applying boot alternatives
[    0.000000] Kernel command line: root=UUID=aff49849-0ea3-4eb6-a80d-6dc667c0efb3 rootfstype=ext4 rootwait console=tty1 consoleblank=0 coherent_pool=2M ubootpart=14ff413a-01 fsck.repair=yes net.ifnames=0 cgroup_enable=memory
[    0.000000] Unknown kernel command line parameters "ubootpart=14ff413a-01 cgroup_enable=memory", will be passed to user space.                                                   [    0.000000] Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes, linear)
[    0.000000] Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
[    0.000000] Fallback order for Node 0: 0
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 524288
[    0.000000] Policy zone: DMA
[    0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[    0.000000] software IO TLB: SWIOTLB bounce buffer size adjusted to 2MB
[    0.000000] software IO TLB: area num 4.
[    0.000000] software IO TLB: mapped [mem 0x00000000b5600000-0x00000000b5800000] (2MB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] ftrace: allocating 49887 entries in 195 pages
[    0.000000] ftrace: allocated 195 pages with 4 groups
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[    0.000000]  Rude variant of Tasks RCU enabled.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[    0.000000] RCU Tasks Rude: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[    0.000000] RCU Tasks Trace: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[    0.000000] NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
[    0.000000] Root IRQ handler: gic_handle_irq
[    0.000000] GIC: Using split EOI/Deactivate mode
[    0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[    0.000000] arch_timer: cp15 timer(s) running at 24.00MHz (phys).
[    0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[    0.000001] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps every 4398046511097ns
[    0.000132] clocksource: timer: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 79635851949 ns
[    0.000709] Console: colour dummy device 80x25
[    0.000723] printk: legacy console [tty1] enabled
[    0.001338] Calibrating delay loop (skipped), value calculated using timer frequency.. 48.00 BogoMIPS (lpj=96000)
[    0.001370] pid_max: default: 32768 minimum: 301
[    0.001466] LSM: initializing lsm=capability,yama,apparmor,ima,evm
[    0.001558] Yama: becoming mindful.
[    0.001801] AppArmor: AppArmor initialized
[    0.001997] Mount-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.002030] Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes, linear)
[    0.004868] rcu: Hierarchical SRCU implementation.
[    0.004903] rcu:     Max phase no-delay instances is 1000.
[    0.005199] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[    0.006456] smp: Bringing up secondary CPUs ...
[    5.092262] CPU1: failed to come online
[    5.092283] CPU1: failed in unknown state : 0x0
[   10.216585] CPU2: failed to come online
[   10.216605] CPU2: failed in unknown state : 0x0
[   15.340913] CPU3: failed to come online
[   15.340933] CPU3: failed in unknown state : 0x0
[   15.341008] smp: Brought up 1 node, 1 CPU
[   15.341026] SMP: Total of 1 processors activated.
[   15.341040] CPU: All CPU(s) started at EL2
[   15.341078] CPU features: detected: 32-bit EL0 Support
[   15.341093] CPU features: detected: 32-bit EL1 Support
[   15.341112] CPU features: detected: CRC32 instructions

Let me know if any logs after that would help to clarify something relevant.

We did now test it with the defconf from pyavitz: https://github.com/pyavitz/debian-image-builder/blob/feature/defconfig/sunxi64_defconfig
Applied with the commit here: 86f3167
This rules out NUMA and the initial CPU governor as culprit. The functional kernel from pyavitz actually contains CONFIG_SUN50I_H6_PRCM_PPU=m as well, and it is effective since that new driver is patched into the kernel there as well. But the patch is better named with "h616" in the name, indicating which SoC it is effectively applied to, while in our patches it is confusingly named with "h6", while not being references in any Allwinner H6 device tree: https://github.com/pyavitz/debian-image-builder/blob/feature/patches/allwinner/6.12/001-arm64-sunxi-h616-Enable-Mali-GPU.patch
But it means that the presence of this new PRCM PPU driver is not the culprit either.

Hence the debugging could need to focus on the patches, in combination with above kernel log.

[Copilot]

@copilot here is the kernel log until the relevant CPU init failures:

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]

...

The boot log is very revealing — failed in unknown state : 0x0 means the secondary CPUs never wrote to secondary_data.status at all, i.e., they never executed any kernel code despite PSCI CPU_ON returning success (5 s = exact timeout, not immediate).

Two key observations from the log:

• KASLR enabled + CPU features: kernel page table isolation forced ON by KASLR — KPTI is active because of kaslr-seed = <0xfeedbeef 0xc0def00d> in our DTS
• KPTI adds a trampoline page-table transition to the ARM64 secondary CPU startup path (secondary_startup_64); a failure there produces exactly this symptom

The sunxi-6.15 version of the same DTS (add-initial-support-for-orangepi3-lts.patch) has no kaslr-seed and therefore no KPTI. All other H6 patches are equivalent between the two kernel versions.

Commit 442d571 removes kaslr-seed from dt/sun50i-h6-orangepi-3-lts.dts to align with sunxi-6.15. This should allow secondary CPUs to come online by eliminating the KPTI trampoline from the startup path. A hardware test will confirm whether this is the root cause.

Security note: the removed seed was a fixed constant (0xfeedbeef 0xc0def00d), not truly random, so it provided deterministic rather than meaningful KASLR randomisation anyway.