Thank you, that clarifies things! - TB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On August 1, 2018 12:09 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 1 August 2018 at 15:09, TB tim.black...@pm.me 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
