Re: [Qemu-devel] [PATCH] hw/arm/boot: load device tree to base of DRAM if no -kernel option was passed

[Ard Biesheuvel]

On 1 September 2014 19:50, Peter Maydell <address@hidden> wrote:
> 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.
>

By orthogonal, do you mean this bit still belongs in
arm_load_kernel(), and the reset handling should be adapted to call
arm_load_kernel() again in its entirety?

>> 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