almalinux-10: kernel page-allocation splat at dma_atomic_pool_init (order:7 GFP_DMA32) #164

Symptom

Booting AlmaLinux 10 (kernel 6.12.0-205.el10.riscv64) on the X280 produces a
page-allocation failure during early init, before userspace ever starts:

```
[ 0.020828] swapper/0: page allocation failure: order:7, mode:0xcc4(GFP_KERNEL|GFP_DMA32), nodemask=(null),cpuset=/,mems_allowed=0
[ 0.020871] CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-205.el10.riscv64 #1 PREEMPT(voluntary)
[ 0.020889] Call Trace:
[ 0.020889] [] dump_backtrace+0x1c/0x24
[ 0.020899] [] show_stack+0x28/0x34
[ 0.020905] [] dump_stack_lvl+0x4a/0x68
[ 0.020915] [] dump_stack+0x14/0x1c
[ 0.020921] [] warn_alloc+0xfe/0x176
[ 0.020929] [] __alloc_pages_slowpath.constprop.0+0x586/0x7a4
[ 0.020935] [] __alloc_pages_noprof+0x284/0x2a2
[ 0.020940] [] alloc_pages_mpol_noprof+0xb0/0x1d8
[ 0.020950] [] alloc_pages_noprof+0x54/0xaa
[ 0.020957] [] atomic_pool_expand+0x5e/0x1f8
[ 0.020965] [] __dma_atomic_pool_init+0x48/0xa2
[ 0.020971] [] dma_atomic_pool_init+0x90/0x116
[ 0.020977] [] do_one_initcall+0x54/0x288
[ 0.021261] DMA: failed to allocate 484 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocation
```

Mem-Info shows 4 GiB total (`1048576 pages RAM`), 991166 pages free at the
moment of failure — so it's not a global memory pressure problem, it's
specifically the GFP_DMA32 zone failing to satisfy an order-7 (512 KiB)
contiguous allocation.

Why GFP_DMA32 is the issue here

The L2CPU sees DRAM at `0x4000_3000_0000+` — physical addresses well above
the 32-bit watermark (`< 0x1_0000_0000`). The kernel's GFP_DMA32 zone
covers "addresses < 4 GiB" by definition, so on a chip whose entire DRAM
window starts above 4 GiB the GFP_DMA32 zone is empty. The DMA atomic pool
init sees "GFP_DMA32 zone exists, give me 484 KiB" and gets ENOMEM.

The kernel doesn't crash (it's a WARN-on-fail, not a panic), but the DMA
atomic pool ends up unallocated, and any later GFP_DMA32 driver request
also fails. AlmaLinux 10's kernel has the dma-pool init in
`mm/dma-pool.c::__dma_atomic_pool_init` calling `alloc_pages_noprof` with
`__GFP_DMA32`. Ubuntu 24.04 (the working baseline) skips this on the same
hardware because either: a) its kernel has CONFIG_DMA_DIRECT_REMAP off,
b) the dma-pool init is gated on a CONFIG that AlmaLinux 10 enables, or c)
the patches to suppress GFP_DMA32 on platforms with no DMA32-eligible RAM
are present.

Investigation needed

1. Check AlmaLinux 10's kernel config for CONFIG_DMA_COHERENT_POOL,
   CONFIG_DMA_DIRECT_REMAP, CONFIG_ZONE_DMA32 — whichever set conspires to
   demand a non-empty DMA32 zone on a chip where it's empty.
2. Compare against Ubuntu 24.04's RISC-V build for the same configs.
3. Check whether the X280's DTB declares any DMA32-friendly memory region,
   or whether modifying `/memory` to span below 4 GiB would help (it can't
   — the chip's physical address map is what it is).

Likely fixes are upstream-kernel-side (mark the zone empty so init
short-circuits), not bhx-side. The DTB we patch already names the
above-4G memory region correctly.

Mitigations to consider

• Document AlmaLinux 10 as known-broken until upstream patches.
  Existing distro registry has Fedora 42 / Debian 13 / Ubuntu 24.04 working
  cleanly; AlmaLinux 10 is the odd one out.
• Patch the AlmaLinux kernel to skip dma_atomic_pool_init when DMA32 is
  empty, vendor as a third_party/almalinux-kernel/ patch series.
• Build a custom kernel with CONFIG_DMA_DIRECT_REMAP off and use that
  via initramfs.

Acceptance criteria

• AlmaLinux 10 boot reaches a login prompt without the page-allocation
  splat. (Or: the issue is closed with a clear "upstream kernel bug,
  tracked at " note and the image registry deprioritizes 10.)