public inbox for linux-arm-kernel@lists.infradead.org
 help / color / mirror / Atom feed
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 ?

  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