On 1 September 2014 19:50, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 1 September 2014 18:46, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: >> On 1 September 2014 19:36, Peter Maydell <peter.mayd...@linaro.org> wrote: >>> On 26 August 2014 16:31, Ard Biesheuvel <ard.biesheu...@linaro.org> 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 <ard.biesheu...@linaro.org> >>> >>> 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
