qemu-discuss
[Top][All Lists]
Advanced

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

Re: [Qemu-discuss] How to specify memory map for QEMU driver?


From: TB
Subject: Re: [Qemu-discuss] How to specify memory map for QEMU driver?
Date: Wed, 01 Aug 2018 16:45:34 +0000

Thank you, that clarifies things!

- TB

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 1, 2018 12:09 PM, Peter Maydell <address@hidden> wrote:

> On 1 August 2018 at 15:09, TB address@hidden wrote:
>
> > New QEMU user here, reaching out for some clarification
> > on the “-dtb” and “-device” flags. How can I tell QEMU to
> > map a device I specify with the “-device” flag to a
> > specific memory region that I know about from the Device
> > Tree Blob (DTB) file?
>
> You can't. -device cannot be used to instantiate devices
> which are memory mapped, beacuse there is no way to
> specify memory address, interrupt line wiring, and so on.
> It is for pluggable devices (like PCI devices, ISA bus
> devices, and so on).
>
> Memory-mapped devices are created within QEMU's sources
> by the code which emulates a specific board, SoC, etc.
> Implementing support for a new board implies writing a
> fair amount of C code.
>
> > For example, the DTB for a kernel I’m attempting to
> > emulate specifies a bus with a set of SCU registers
> > (line “compatible = "arm,cortex-a9-scu"’”) and their
> > memory addresses. “qemu-system-arm -M virt -device help”
> > shows “name "a9-scu", bus System” on the list of supported
> > devices. So it seems that I have a match between a driver
> > implemented in QEMU and a device the emulated kernel
> > wants to initialize!
>
> The list of devices is not trimmed down by board: it will
> be the same regardless of what argument you pass to -M,
> and doesn't imply that any particular device works with
> any particular board.
>
> The "virt" board doesn't work with the cortex-a9,
> which is why it doesn't create the A9-specific SCU
> registers.
>
> Finally, you're using a slightly older QEMU, which was
> a bit over-loose with what devices it listed in the
> -device help option, and included ones that weren't
> actually usefully usable by the user. We've tightened
> this up and newer QEMU versions don't list the
> cortex-a9-scu device (because it's not in fact
> possible to create it on the command line).
>
> > qemu-system-arm -M vexpress-a9 -kernel <zImage-file> -initrd 
> > <initramfs-file> -append console=ttyS0,115200 -dtb <dtb-file> -cpu 
> > cortex-a9 -device a9-scu
>
> This doesn't work (as you've noticed) and in any case
> the vexpress-a9 board already creates an a9-scu for you.
>
> > Throws the error:
> > “qemu-system-arm: Option '-device a9-scu' cannot be handled by this machine”
> > Switching to the “virt” machine, I get:
> > “qemu-system-arm: Device a9-scu can not be dynamically instantiated”
>
> The error messages are a bit unhelpful and we've improved
> them. Current QEMU will tell you the same thing in both
> cases:
>
> qemu-system-arm: -device a9-scu: Parameter 'driver' expects pluggable
> device type
>
> > Not sure how to make sense of these errors, any advice on
> > how I should be matching up DTB information (driver name,
> > memory location for registers) to QEMU’s device drivers?
>
> For QEMU, you use DTBs in one of two ways:
>
> (1) For board models which are models of a particular
> piece of real hardware, like the vexpress-a9: you
> pass QEMU the DTB which is the one you'd use on
> that bit of real hardware, the same way that if you
> were booting a kernel on real hardware you'd pass
> u-boot the correct dtb file. QEMU creates emulated
> devices at the addresses where the hardware puts them,
> and so they match the dtb addresses.
>
> (2) The "virt" board model is a special case, because
> it is purely-virtual hardware that QEMU controls the
> specification for. In this case you don't pass QEMU
> a dtb file at all -- QEMU creates one internally that
> matches the device layout of the system, and passes
> it to the kernel automatically.
>
> thanks
> -- PMM





reply via email to

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