From: lambertarthur22@gmail.com (Arthur LAMBERT)
To: linux-arm-kernel@lists.infradead.org
Subject: issue with kexec/kdump on imx6ull
Date: Tue, 3 Apr 2018 16:15:28 +0200 [thread overview]
Message-ID: <20180403141528.GA5701@arthur-bzh> (raw)
In-Reply-To: <20180329205413.GG16141@n2100.armlinux.org.uk>
>
> From the debug output of kexec, I think the problem has been located
> with these two lines:
>
> kernel symbol _stext vaddr = 80100000
> segment[0].mem = 0x88008000
>
> It is standard with Linux kernels that they are loaded with a 32kB
> offset to allow room for data including the page tables below the
> kernel image. kexec-tools knows about this offset. It seems,
> however, that the kernel tree you're using omits this offset and
> builds the kernel to execute at a 1MB offset.
>
> This difference is sufficient that the kernel will crash as a result.
>
> All the offsets established to date in arch/arm/Makefile include
> this 32kB offset, except, it seems, for your case - which is
> presumably a vendor supplied (NXP?) or modified kernel tree.
>
> That's the root of the problem, and I'm afraid I can't help you any
> further - please complain to the vendor about this.
>
> I suspect that they wanted to load the kernel at 1MB to avoid data
> in the low 1MB of RAM, but have forgotten that both the decompressor
> and the kernel itself will scribble over the 16 to 32k of memory
> _below_ where it's loaded.
>
> One way to fix this is to change the initialiser for extra_size in
> kexec-tools/kexec/arch/arm/kexec-zImage-arm.c to reflect this offset,
> but that will be at the expense of having to increase the crashdump
> memory to allow for this offset. It also makes kexec incompatible
> with other kernels in the same way as stock kexec is incompatible
> with your kernel.
>
> The other solution is to include the 32k offset into the 1MB offset
> in arch/arm/Makefile as per all the other textofs settings therein.
Not sure to fully understand you here. For me the offset is correct. 32kb.
I add some extra debug in kexec in the function with extra size and result is :
TUTU base addr : 0x88000000
TUTU extra size : 0x00008000
TUTU kernel base addr : 0x88008000
Base address is 0x88000000. extra size is 0x8000
So kernel base addr is 0x88008000. Offset is 32kB
as expected.
In my arch/arm/Makefile as expected :
# Text offset. This list is sorted numerically by address in order to
# provide a means to avoid/resolve conflicts in multi-arch kernels.
textofs-y := 0x00008000.
My kernel is compiled with good TEXT_OFFSET :
-DTEXT_OFFSET=0x00008000
the _stext vaddr is incorrect here ? It must be 0x88000000 instead of
80100000 ?
next prev parent reply other threads:[~2018-04-03 14:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-20 10:04 issue with kexec/kdump on imx6ull Arthur LAMBERT
2018-03-20 10:43 ` Russell King - ARM Linux
2018-03-20 15:07 ` Russell King - ARM Linux
2018-03-20 17:16 ` Arthur LAMBERT
2018-03-20 19:12 ` Russell King - ARM Linux
2018-03-21 13:25 ` Arthur LAMBERT
2018-03-29 20:54 ` Russell King - ARM Linux
2018-04-03 14:15 ` Arthur LAMBERT [this message]
2018-04-09 13:58 ` Arthur LAMBERT
2018-04-09 14:31 ` Russell King - ARM Linux
2018-05-16 10:31 ` Arthur LAMBERT
2018-05-16 10:42 ` Russell King - ARM Linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180403141528.GA5701@arthur-bzh \
--to=lambertarthur22@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox