Discussion:
Kexec on ARM - memory detection
Kristian Kielhofner
2017-04-06 16:17:00 UTC
Permalink
Hello,

I'm trying to use kexec on ARM. I'm using LEDE 17.01 with their
ipq806x target on various boards of this type.

I've followed many threads and a bit on the history of kexec on ARM
because I'm running into a strange problem:

***@LEDE:/tmp# kexec -d -t uImage --dtb=C2600-uImage.dtb
--command-line="" -l C2600-uImage
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on C2600-uImage of 65536 bytes failed
kernel: 0xb6d27010 kernel_size: 0x1eb76e
MEMORY RANGES
00012028b6d27010-bea6aee700000004 (0)
zImage header: 0x016f2818 0x00000000 0x001e5cd0
zImage size 0x1e5cd0, file size 0x1eb72e
Could not find a free area of memory of 0x1edcd0 bytes...
Cannot load C2600-uImage
***@LEDE:/tmp# cat /proc/iomem
00108000-00108fff : /soc/***@108000
00700000-00700fff : /soc/***@700000
00800000-00803fff : /soc/***@800000
00900000-00903fff : /soc/clock-***@900000
02011000-02011fff : /soc/clock-***@2011000
02088000-02088fff : /soc/clock-***@2088000
0208a000-0208a0ff : /soc/***@200a000
02098000-02098fff : /soc/clock-***@2098000
08000000-081fffff : ath
10000000-10007fff : /soc/***@1/***@10000000
10000000-10007fff : /soc/***@1/***@10000000
1000c100-1000ccff : /soc/***@1/***@10000000
100f8800-100f882f : /soc/***@100f8800
100f8830-100f885f : /soc/***@100f8830
11000000-11007fff : /soc/***@0/***@11000000
11000000-11007fff : /soc/***@0/***@11000000
1100c100-1100ccff : /soc/***@0/***@11000000
110f8800-110f882f : /soc/***@110f8800
110f8830-110f885f : /soc/***@110f8830
16300000-163000ff : /soc/***@16300000
16340000-16340fff : msm_serial
18300000-183fffff : /soc/***@18300000
1a200000-1a2000ff : /soc/***@1a200000
1a280000-1a280fff : /soc/***@1a200000/***@1a280000
1a500000-1a5001ff : /soc/***@1a500000
1b500000-1b500fff : dbi
1b502000-1b50207f : elbi
1b600000-1b6000ff : parf
1b700000-1b700fff : dbi
1b702000-1b70207f : elbi
1b800000-1b8000ff : parf
2e000000-2e1fffff : ath
37200000-373fffff : /soc/***@37200000
37400000-375fffff : /soc/***@37400000
42000000-5fffffff : System RAM
42208000-4278de77 : Kernel code
427c4000-4283ab77 : Kernel data
***@LEDE:/tmp# uname -a
Linux LEDE 4.4.53 #0 SMP Fri Mar 17 12:56:58 2017 armv7l GNU/Linux
***@LEDE:/tmp#

I've tried every possible combination of uImage/zImage (with and
without initramfs, etc) and always end up with the same error. I've
compiled my own LEDE 17.01 image with the following LEDE options
enabled:

grep -i kexec .config
CONFIG_KERNEL_KEXEC=y
CONFIG_PACKAGE_kexec-tools=y
CONFIG_KEXEC_TOOLS_kdump=y
CONFIG_KEXEC_ZLIB=y
CONFIG_KEXEC_LZMA=y

I've also updated my local build to use kexec-tools-2.0.14 but
always the same result. What else should I be looking at?

Thanks!
--
Kristian Kielhofner
Pratyush Anand
2017-04-21 11:27:43 UTC
Permalink
Hi Kristian,

Sorry, I missed this mail.
Are you still on it, or it is solved?
Post by Kristian Kielhofner
Hello,
I'm trying to use kexec on ARM. I'm using LEDE 17.01 with their
ipq806x target on various boards of this type.
I've followed many threads and a bit on the history of kexec on ARM
--command-line="" -l C2600-uImage
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on C2600-uImage of 65536 bytes failed
kernel: 0xb6d27010 kernel_size: 0x1eb76e
MEMORY RANGES
00012028b6d27010-bea6aee700000004 (0)
How does kexec-tools see above memory ranges?
As per your /proc/iomem, it should have been
42000000-5fffffff (0)

Can you put some extra debug print in your code and check why do you have
above behavior?

~Pratyush
Post by Kristian Kielhofner
zImage header: 0x016f2818 0x00000000 0x001e5cd0
zImage size 0x1e5cd0, file size 0x1eb72e
Could not find a free area of memory of 0x1edcd0 bytes...
Cannot load C2600-uImage
08000000-081fffff : ath
16340000-16340fff : msm_serial
1b500000-1b500fff : dbi
1b502000-1b50207f : elbi
1b600000-1b6000ff : parf
1b700000-1b700fff : dbi
1b702000-1b70207f : elbi
1b800000-1b8000ff : parf
2e000000-2e1fffff : ath
42000000-5fffffff : System RAM
42208000-4278de77 : Kernel code
427c4000-4283ab77 : Kernel data
Linux LEDE 4.4.53 #0 SMP Fri Mar 17 12:56:58 2017 armv7l GNU/Linux
I've tried every possible combination of uImage/zImage (with and
without initramfs, etc) and always end up with the same error. I've
compiled my own LEDE 17.01 image with the following LEDE options
grep -i kexec .config
CONFIG_KERNEL_KEXEC=y
CONFIG_PACKAGE_kexec-tools=y
CONFIG_KEXEC_TOOLS_kdump=y
CONFIG_KEXEC_ZLIB=y
CONFIG_KEXEC_LZMA=y
I've also updated my local build to use kexec-tools-2.0.14 but
always the same result. What else should I be looking at?
Thanks!
Kristian Kielhofner
2017-04-26 17:15:26 UTC
Permalink
Post by Pratyush Anand
Hi Kristian,
Sorry, I missed this mail.
Are you still on it, or it is solved?
No problem, I'm still experiencing the issue but I haven't
investigated it further.
Post by Pratyush Anand
How does kexec-tools see above memory ranges?
As per your /proc/iomem, it should have been
42000000-5fffffff (0)
Can you put some extra debug print in your code and check why do you have
above behavior?
Can you point towards some examples or documentation for what you're
looking for?

Thanks for your help!
--
Kristian Kielhofner
Pratyush Anand
2017-04-28 17:20:43 UTC
Permalink
Post by Kristian Kielhofner
Post by Pratyush Anand
Hi Kristian,
Sorry, I missed this mail.
Are you still on it, or it is solved?
No problem, I'm still experiencing the issue but I haven't
investigated it further.
Post by Pratyush Anand
How does kexec-tools see above memory ranges?
As per your /proc/iomem, it should have been
42000000-5fffffff (0)
Can you put some extra debug print in your code and check why do you have
above behavior?
Can you point towards some examples or documentation for what you're
looking for?
kexec-tools:kexec/arch/arm/kexec-arm.c:get_memory_ranges() is telling you that
you have
MEMORY RANGES
00012028b6d27010-bea6aee700000004 (0)

However, you /proc/iomem is telling you:

42000000-5fffffff : System RAM

get_memory_ranges() is reading /proc/iomem and finding out the available ram
locations. So, can you debug this kexec-tools function and see why you do not
get the range which is coming from /proc/iomem

~Pratyush

Loading...