[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] xen/arm: Rework the way to compute dom0 DTB base address



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.