xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "patches@linaro.org" <patches@linaro.org>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] xen/arm: Rework the way to compute dom0 DTB base address
Date: Mon, 27 May 2013 16:44:26 +0100	[thread overview]
Message-ID: <51A37F5A.2080302@linaro.org> (raw)
In-Reply-To: <51A3667D.80209@citrix.com>

On 05/27/2013 02:58 PM, Andrew Cooper wrote:

> On 27/05/13 14:50, Julien Grall wrote:
>> If the DTB is loading right the after the kernel, on some setup, Linux will
>> overwrite the DTB during the decompression step.
>>
>> To be sure the DTB won't be overwritten by the decrompression stage, load
> decompression
>> the DTB near the end of the first memory bank and below 4Gib (if memory range is
>> greater).
> 
> Surely the correct solution is to make Linux aware that a DTB is present
> so it wont overwrite it? 


Most of the setup I used let the user choose the DTB base address or
automatically generate it (randomly?).

For instance, QEMU assumes the DTB will be load from 128Mo, if there is
more than 256Mo, or the amount of memory divide by 2.
It's possible to assume the same things because Linux is built with
CONFIG_AUTO_ZRELADDR, which is enabled by the multiple platform support.
This option will assume that the zImage will be place in the first 128
MB from start of memory.

It's also possible to enable CONFIG_ARM_APPENDED_DTB which checks during
decompression stage if there is an appended DTB. But it's for the old
bootloader (ie which doesn't set the DTB address in r2) and won't allow
to boot Linux either on bare metal or on XEN.

Your solution is the best, but, if I didn't miss something, it means
some rework on the Linux decompression stage. I think, this is also on
issue with all the bootloaders.

> Sticking it at the end of memory in the hope that it wont be overwritten
> is still going to fail in a somewhat memory-limited situation.

Quick question, on x86 does Linux take care of the initrd during
decompression stage? Is there any assumption on the memory layout?

-- 
Julien

  reply	other threads:[~2013-05-27 15:44 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-27 13:50 [PATCH] xen/arm: Rework the way to compute dom0 DTB base address Julien Grall
2013-05-27 13:58 ` Andrew Cooper
2013-05-27 15:44   ` Julien Grall [this message]
2013-05-28  9:05     ` Ian Campbell
2013-05-28  9:03 ` Ian Campbell
2013-05-28 11:11   ` Julien Grall
2013-05-28 11:19     ` Ian Campbell
2013-05-28 11:24       ` Julien Grall

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=51A37F5A.2080302@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=Stefano.Stabellini@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=patches@linaro.org \
    --cc=xen-devel@lists.xen.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;
as well as URLs for NNTP newsgroup(s).