On March 31, 2018 4:34:28 PM PDT, Frederick Heinecke <fheinecke@xxxxxxx> wrote: >It's entirely possible the dtb is corrupted on some level, however, >I've confirmed that at least the nodes are copied correctly. I put some >early_print calls in the kernel's code to print off node names and all >of them are listed correctly, but none of the nodes have properties >(according to the kernel). > >It's unlikely I have RAM corruption. I wrote a bare-metal program to >run a few tests for memory errors and the board passed all of them. > >I'm loading the dtb to 0x20000000 (start of SRAM) and the zImage to >0x200080000. Right there is your problem. The kernel wants to use the memory below itself for page table descriptors. It would not be able to do that with the DTB being below and claiming that area as reserved, or worse, as the kernel initializes itself it clobbers the area below itself in the process. Try loading the DTB at 0x2010_0000 for instance this should work. > >As a side note, I hard-coded the kernel to use 0x20000000 and >0x10000000 instead of reading the value from the dtb. This allowed the >kernel to pass this issue, but now I have another memory related issue >that I suspect is due to the dtb property issue (can't free memory page >from boot memory because it's currently in use), although I have yet to >confirm the root cause. > >Thank you, > >Fred Heinecke > > >From: Florian Fainelli <f.fainelli@xxxxxxxxx> >Sent: Saturday, March 31, 2018 6:01 PM >To: Frederick Heinecke; linux-embedded@xxxxxxxxxxxxxxx >Subject: Re: Kernel crashing on startup while trying to allocate space >below 0x0 > > >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
