Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Nicolas Pitre <nico@fluxnic.net>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: kexec@lists.infradead.org, neumann@teufel.de,
	linux-arm-kernel@lists.infradead.org,
	Daniel Mack <zonque@gmail.com>
Subject: Re: [PATCH v2] ARM: head-common.S: relocate atags area if necessary
Date: Sat, 19 Oct 2013 11:15:48 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.03.1310191059290.1951@syhkavp.arg> (raw)
In-Reply-To: <20131018175414.GF25034@n2100.arm.linux.org.uk>

On Fri, 18 Oct 2013, Russell King - ARM Linux wrote:

> When things were at a fixed location, they were always placed at
> around 256 bytes into the memory, below the kernel.  I guess now people
> are placing them at some random location elsewhere.
> 
> This is becoming more a more of a pain.  We have all sorts of randomly
> placed objects in memory now that its only a matter of time before we
> hit something.  We keep on dreaming up these "well, let's move it"
> solutions but does that really help?  Move it to where?  Another place
> where we think there isn't going to be anything?  What if there is?

This is why I suggested adding a recommendation for placing the 
initrd/DTB/ATAGs above the 128MB boundary from start of RAM in the ARM 
booting document.

The zImage code does have to take into account the location of the final 
kernel's .bss area in order to properly accommodate appended DTB to 
zImage, otherwise the simple relocation of the decompressor (with its 
appended DTB) out of the way of the final kernel image is not sufficient 
to guarantee that the appended DTB won't be overwritten.

But I think that this is the extent of what we should do.  We already 
don't relocate the initrd if it is in the way either.  Trying to make 
everything automagically relocate properly in all cases during very 
early boot is very difficult, so it is best to simply not attempt it.  
On the other hand, the loader agent, whether it is kexec or a 
bootloader, should be aware of all the available RAM and could therefore 
make things safe.

If you have the ability to load the DTB and/or ATAG independently from 
zImage or uncompressed Image (which is not the case for the appended 
DTB) then it is your responsibility to load it sufficiently far away 
from the kernel.  Same rule applies for the initrd.  Hence the "above 
128MB from start of RAM" recommendation.


Nicolas

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2013-10-19 15:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-18 16:12 [PATCH v2] ARM: head-common.S: relocate atags area if necessary Daniel Mack
2013-10-18 16:29 ` Russell King - ARM Linux
2013-10-18 17:09   ` Daniel Mack
2013-10-18 17:54     ` Russell King - ARM Linux
2013-10-19 15:15       ` Nicolas Pitre [this message]
2013-10-19 16:10         ` Daniel Mack
2013-10-19 16:13           ` Russell King - ARM Linux
2013-10-19 16:19             ` Daniel Mack

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=alpine.LFD.2.03.1310191059290.1951@syhkavp.arg \
    --to=nico@fluxnic.net \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@arm.linux.org.uk \
    --cc=neumann@teufel.de \
    --cc=zonque@gmail.com \
    /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