qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] hw/arm/boot: load device tree to base of DRAM i


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] hw/arm/boot: load device tree to base of DRAM if no -kernel option was passed
Date: Mon, 1 Sep 2014 18:50:52 +0100

On 1 September 2014 18:46, Ard Biesheuvel <address@hidden> wrote:
> On 1 September 2014 19:36, Peter Maydell <address@hidden> wrote:
>> On 26 August 2014 16:31, Ard Biesheuvel <address@hidden> wrote:
>>> If we are running the 'virt' machine, we may have a device tree blob but no
>>> kernel to supply it to if no -kernel option was passed. In that case, copy 
>>> it
>>> to the base of DRAM where it can be picked up by a bootloader executing from
>>> NOR flash.
>>>
>>> Signed-off-by: Ard Biesheuvel <address@hidden>
>>
>> In general I like this approach for providing a BIOS/bootloader
>> with information about the platform it's running on.
>> (For the benefit of readers who may be missing context, this
>> bootloader is likely to be UEFI.) Since we already have DTB for
>> telling the guest about the shape of the platform this makes
>> more sense to me than having a separate fw_cfg style
>> interface to repeat the same information.
>>
>
> I agree. But perhaps we should address the reset issue we discussed
> over IRC last Friday?

Also true; I thought about mentioning those but decided they
were orthogonal. We should probably pull together a list
of all the UEFI related QEMU patches and required work.

> Currently, reset does not work at all when using -bios (and your
> patch), but we should fix that in a sane way, i.e., the DTB should be
> reloaded into DRAM, and this patch currently does not cover that.

Yep. That's also a bug with the -kernel support, though:
currently we rely on the guest kernel never writing over the
dtb we pass it since we don't reinstate it on reset...

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]