Le 03/28/18 à 12:19, Frederick Heinecke a écrit : > Hello all, > > I've cross-compiled Linux 4.16 for a AT91SAM9XE512 MPU which uses an ARMv5TEJ instruction set. I'm using a custom board, bootloader, and device tree. On startup, I receive the following kernel panic: > > Uncompressing Linux... done, booting the kernel. > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.16.0-rc5-FFAero (root@localhost.localdomain) (gcc version 6.2.0 (GCC)) #3 Sat Mar 17 07:51:27 CDT 2018 > [ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f > [ 0.000000] CPU: VIVT data cache, VIVT instruction cache > [ 0.000000] OF: fdt: Machine model: FFAero > [ 0.000000] bootconsole [earlycon0] enabled > [ 0.000000] Memory policy: Data cache writeback > [ 0.000000] Kernel panic - not syncing: ERROR: Failed to allocate 0x00002000 bytes below 0x00000000. > [ 0.000000] > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.16.0-rc5-FFAero #3 > [ 0.000000] Hardware name: Atmel AT91SAM9 > [ 0.000000] Backtrace: invalid frame pointer 0xc0a01e68 > [ 0.000000] ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x00002000 bytes below 0x00000000. > [ 0.000000] > > Here's a copy of the stack trace: > > (gdb) bt > #0 __loop_delay () at arch/arm/lib/delay-loop.S:58 > #1 0xc011f69c in panic () > #2 0xc0918c9c in memblock_alloc_base (size=8192, align=<optimized out>, max_addr=0) at mm/memblock.c:1229 > #3 0xc0918cc4 in memblock_alloc (size=<optimized out>, align=<optimized out>) at mm/memblock.c:1237 > #4 0xc0905840 in early_alloc_aligned (sz=3231719088, align=<optimized out>) at arch/arm/mm/mmu.c:724 > #5 0xc0905940 in early_alloc (sz=<optimized out>) at arch/arm/mm/mmu.c:731 > #6 0xc09060bc in devicemaps_init (mdesc=<optimized out>) at arch/arm/mm/mmu.c:1324 > #7 paging_init (mdesc=<optimized out>) at arch/arm/mm/mmu.c:1631 > #8 0xc090359c in setup_arch (cmdline_p=0xc0a01fc0) at arch/arm/kernel/setup.c:1120 > #9 0xc0900ae8 in start_kernel () at init/main.c:536 > #10 0x00000000 in ?? () > > While spending the last week tracing this issue back through the kernel source code it looks like the "of_get_flat_dt_prop" method is never returning a valid result for any property under the memory node. My decompiled device tree (dtb -> dts) is available here: https://hastebin.com/wopaxiwawo.c That is likely the source of your problem, judging by other AT91SAM9 DTS it looks like RAM does start at physical offset 512MB and if you have 256MB populated, then this looks correct in your Device Tree. Is it possible that somehow your Device Tree blob is being corrupted as passed by the bootloader and only the top-level compatible node ends-up being correct and therefore matched? Do you possibly have a DRAM corruption? Where are you loading the kernel and DTB in memory? -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
