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

[Peter Crosthwaite]

On Wed, Sep 3, 2014 at 10:01 PM, 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>
> ---
> v2: comment style, call exit(1) on load_dtb() failure

On respins, please add "Vx" to git subject prefix.

git fomat-patch --subject-prefix "PATCH v2"

>
>  hw/arm/boot.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/hw/arm/boot.c b/hw/arm/boot.c
> index e32f2f415885..a32ff28d9be1 100644
> --- a/hw/arm/boot.c
> +++ b/hw/arm/boot.c
> @@ -459,6 +459,17 @@ void arm_load_kernel(ARMCPU *cpu, struct arm_boot_info 
> *info)
>
>      /* Load the kernel.  */
>      if (!info->kernel_filename) {
> +
> +        if (have_dtb(info)) {
> +            /* If we have a device tree blob, but no kernel to supply it to,
> +             * copy it to the base of DRAM for a bootloader executing from
> +             * NOR flash to pick up.

arm/boot is generic code so you shouldn't mention the specifics of
DRAM/NOR implementation. s/DRAM/RAM and can remove "executing from NOR
flash" completely.

> +             */
> +            if (load_dtb(info->loader_start, info)) {
> +                exit(1);
> +            }
> +        }
> +

Can we get this functionality in the elf loading path too? With this
patch, you now get:

1: -kernel Linux : dtb
2: -kernel elf : no dtb
3: nothing : dtb

It would be nice and consistent if you always got a dtb. If the elf
sections overlap the dts, then the elf should take precedence. Not
sure if the ROM loading framework supports this natively just yet
though.

This would allow for easier debugging of your bootloader as an elf
guest, rather that having to do build cycles all the way down to
firmware blob image.

Regards,
Peter

>          /* If no kernel specified, do nothing; we will start from address 0
>           * (typically a boot ROM image) in the same way as hardware.
>           */
> --
> 1.8.3.2
>
>