Hey @Gadorach ! Thanks for the encouragement, and thanks for reviving the thread (I was coming up against the 3-post limit).
I was ultimately able to pull the full kernel oops: https://paste.c-net.org/LakhiToner
?BUG: Unable to handle kernel data access on read at 0xc9ffa008
?Faulting instruction address: 0xc033c920
?Thread overran stack, or stack corrupted
?Oops: Kernel access of bad area, sig: 11 #1
?BE PAGE_SIZE=4K
?Modules linked in:
?CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.82 #0
?NIP: c033c920 LR: c033ca50 CTR: c000e938
?REGS: c0c01e28 TRAP: 0300 Not tainted (5.10.82)
? MSR: 00021000 <CE,ME> CR: 28248044 XER: 200000000
GPR00: c033ccdc c0c01ee0 c0b7ba40 c9ffa000 00000000 00000004 40000000 60000000
GPR08: c9ffa000 fffffff8 00000000 00a3a348 88242044 00a3a2a0 00000000
At point, the problem is that the kernel is given a somewhat high address for the device tree blob (starting at 0x09ffa000 in physical memory / 0xc9ffa000 in ppc32 virtual memory). Upon accessing it the kernel panics, apparently due to a memory restriction violation.
The AP3710i, a working OpenWrt board which is extremely similar but which does not relocate the device tree blob, does not panic.
If I can figure out how to tell u-boot on the AP3825i to not relocate the dtb, I am confident booting will succeed.
One part of that will be figuring out through which region of memory the Linux kernel is informed of the location of the device tree blob.
Edit: I looked up one of the variables, CONFIG_SYS_BOOTMAPSZ, from the u-boot source dump whose value helps determine where the flattened device tree (fdt) gets relocated to, and found a patch (mind you, for ARM) which actually describes the situation we're seeing where the fdt can be relocated high enough that the kernel panics.
This bootlin presentation helps me answer my above question:
One part of that will be figuring out through which region of memory the Linux kernel is informed of the location of the device tree blob.
... the answer is on slide 18:
The DTB address is passed through a dedicated CPU register to the kernel: r2 on ARM32
I also see for the u-boot Beaglebone documentation a variable (fdt_high) which can be used to tell u-boot not to relocate too high to solve the issue we're having -- but I worry our u-boot is too old (and I bet the u-boot derivative used on the AP3825i squashes any attempt to mess with the device tree's relocation address).