Re: Kernel crashing on startup while trying to allocate space below 0x0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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




[Index of Archives]     [Gstreamer Embedded]     [Linux MMC Devel]     [U-Boot V2]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux ARM Kernel]     [Linux OMAP]     [Linux SCSI]

  Powered by Linux