Hi,
Has anyone successfully used kexec on MSM8974/APQ8074? Or are there some
outstanding issues that have to be fixed before it is possible?
I’m trying to use Linux with kexec as a second stage bootloader on my
APQ8074-based board. I fail while loading the second kernel, with no error
message whatsoever (no panic, and I do not have access to JTAG to know what is
going on).
The kernel I use is based upon branch jb_mr1_rb1.47 of
git://codeaurora.org/quic/la/kernel/msm (tag M8974AAAAANLYA31050138)
with these commits cherry-picked from mainline for kexec support:
2456f44 ARM: 7555/1: kexec: fix segment memory addresses check
c564df4 ARM: 7540/1: kexec: Check segment memory addresses
4cabd1d ARM: 7539/1: kexec: scan for dtb magic in segments
The commands I run look like this:
/bin/kexec \
--debug \
--load /system/boot/Image \
--dtb=/system/boot/dtb \
--append="console=ttyHSL0,115200,n8 maxcpus=1 msm_rtb.filter=0x37 \
earlyprintk debug bootmem_debug"
/bin/kexec -e
This goes well, but the kernel apparently stops working early-on. With
bootmem_debug and printascii-based tracing, I narrowed the freeze down inside
free_all_bootmem -> free_all_bootmem_core -> __free_pages_bootmem ->
__free_pages -> __free_pages_ok -> free_pages_prepare -> kernel_map_pages
-> poison_pages -> memset) when poisoning a page with physical adress
0x33262000.
If I disable HIGHMEM, I get the freeze a little later, in cma_create_area; the
last line that gets printed to the serial is
[ 0.614040] cma_create_area(base 00032400, count 1000)
To me, it looks like I am somehow stepping on some memory that should be left
alone, but I am not really sure where to go from here. I have a boot log
attached which shows the serial output.
Can anyone tell what might be going on?
Thanks in advance,
Noé.
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
