Tool/software: Linux
Hello, I'm working with getting my AM5728-based custom board to boot, and I'm running into a strange hang early in the kernel boot procedure. I believe it may have to do with my RAM configuration. During boot, my kernel prints the following messages then hangs indefinitely:
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.9.28-geed43d1050 (tom@tom-ThinkPad-P50s) (gcc version 6.2.1 20161016 (Linaro GCC 6.2-2016.11) ) #6 SMP PREEMPT Mon Oct 2 10:59:18 EDT 2017
[ 0.000000] CPU: ARMv7 Processor [412fc0f2] revision 2 (ARMv7), cr=30c5387d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[ 0.000000] OF: fdt:Machine model: tom's custom board
[ 0.000000] bootconsole [earlycon0] enabled
[ 0.000000] efi: Getting EFI parameters from FDT:
[ 0.000000] efi: UEFI not found.
[ 0.000000] Reserved memory: created CMA memory pool at 0x0000000095800000, size 56 MiB
[ 0.000000] OF: reserved mem: initialized node ipu2_cma@95800000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x0000000099000000, size 64 MiB
[ 0.000000] OF: reserved mem: initialized node dsp1_cma@99000000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000009d000000, size 32 MiB
[ 0.000000] OF: reserved mem: initialized node ipu1_cma@9d000000, compatible id shared-dma-pool
[ 0.000000] Reserved memory: created CMA memory pool at 0x000000009f000000, size 8 MiB
[ 0.000000] OF: reserved mem: initialized node dsp2_cma@9f000000, compatible id shared-dma-pool
[ 0.000000] cma: Reserved 24 MiB at 0x000000008e400000
[ 0.000000] Memory policy: Data cache writealloc
Could hanging after Data cache writealloc indicate a problem with the main system RAM? The major difference between my board and the AM5728 EVM is that I only have 256MB of DDR3 RAM with different timings. I've updated the u-boot configurations for this, and u-boot seems to have no issues with running and relocating itself in the RAM. u-boot RAM read and write tests also indicate a high degree of coherency.
According to the EVM, the next line in the kernel boot should be:
[ 0.000000] OMAP4: Map 0x00000000ffd00000 to fe600000 for dram barrier
which is why I feel like the problem could be memory related. Is this assumption valid? If it is what could cause u-boot to work correctly with my RAM and Linux not?
Another possibility is that the addresses given by the IPU/DSP's in the debug lines are accessing memory spaces that are unavailable to them. Since we have only 256MB of RAM, mapped as 0x80000000 to 0x90000000, and those memory addresses for the DSP/IPU are outside of that range (0x95800000, 0x99000000, 0x9d000000, 0x9f000000, etc) they're trying to access memory that is simply unavailable to them?
Here is the full boot, in case anyone is interested. Full decompiled device tree is as well.