qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v7 0/3] hw/arm: Add 'virt' platform


From: Christoffer Dall
Subject: Re: [Qemu-devel] [PATCH v7 0/3] hw/arm: Add 'virt' platform
Date: Thu, 12 Sep 2013 09:29:05 -0700
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Sep 12, 2013 at 11:17:50AM +0100, Peter Maydell wrote:
> This patch series adds a 'virt' platform which uses the
> kernel's mach-virt (fully device-tree driven) support
> to create a simple minimalist platform intended for
> use for KVM VM guests.

looks good to me.  fwiw
Reviewed-by: Chritoffer Dall <address@hidden>

> 
> The major change here is that I've added a PL011 UART.
> 
> Sample command line:
> 
>  qemu-system-arm -machine type=virt -display none \
>   -kernel zImage \
>   -append 'root=/dev/vda rw console=ttyAMA0 rootwait'
>   -cpu cortex-a15 \
>   -device virtio-blk-device,drive=foo \
>   -drive if=none,file=arm-wheezy.img,id=foo \
>   -m 2048 -serial stdio
> 
> Note that there is no earlyprintk via the PL011 because
> there's no defined device tree binding for "hey, here
> is your earlyprintk UART".
> 
> 
> *** NOTE *** to get the PL011 to work you'll need to
> tweak the kernel a bit:
> 
> diff --git a/arch/arm/mach-virt/virt.c b/arch/arm/mach-virt/virt.c
> index b184e57..2b6aceb 100644
> --- a/arch/arm/mach-virt/virt.c
> +++ b/arch/arm/mach-virt/virt.c
> @@ -21,11 +21,13 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/smp.h>
> +#include <linux/clk-provider.h>
>  
>  #include <asm/mach/arch.h>
>  
>  static void __init virt_init(void)
>  {
> +       of_clk_init(NULL);
>         of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
>  }
>  
> 
> Otherwise the kernel doesn't ever add the clock to its
> list, and then it refuses to probe for the PL011.
> (I'm told this isn't really the right fix, though, and
> ideally the call should be done in some generic location
> rather than in every machine's init function.)
> 
> The alternative would be for the kernel to be fixed to
> follow its own device tree binding documentation and not
> require clocks/clock-names properties on the pl011 node.

Is anyone taking a look at a proper fix as far as you know?

-Christoffer



reply via email to

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