Hi Anthony,
So the primary motivation for using this is in embedded systems design flows
where you are already working with DTS for software boot. For
microblaze-linux, xilinx-ppc and the xilinx-arm platforms which we are
working with, it even more makes sense as the hardware platform design tools
are capable of emitting platforms descriptions as DTS. With this framework,
there is no need to write another description of your system (i.e. a config
file, or a hardcoded machine model). DTSs are a standardised way of
describing machines in the embedded linux arena, and are our machine
description source, so in one way or another, we will continue need to
create QEMU machines that match a DTB.
So anyways, the framework does a little bit more than read-config as the
framework allows you to define a mapping between dts descriptions and qdev
device models, rather than your configuration source being straight up qdev
property values. There's also examples of more Ad-Hoc device models that are
not currently qdev models (e.g. pflash_cfi) where you are forced to take a
code driven approach rather than have to rely on QDev. It also allows you to
define machine creation behavior for device nodes that are not QDev devices
at all (e.g. simple busses or memories).
The possibility would exist to take a DTS and to auto-translate it into a
config format, however the process for doing this would be near identical to
the code in this patch series, but rather than just straight up instantiate
the devices as you go, you would have to dump all the results to a single
data structure then read-config that result i.e:
foo.dtb -> foo.cfg -> pass to qemu.
But another important feature of this work that is perhaps glossed over in
the original description, is the ability to specify opaque interconnection
data for inter-communicating devices. dtb provides a natural way for devices
to reference each other and we use this to handle device interconnections
without interferring with device models. In the example given, we create
qemu_irqs for interrupt controllers as they are discovered then tag them as
opaque data for the interrupt controller fdt_node. When connected device
instantiate, they cast the opaque data to qemu_irq and connect the
interrupt. It would be difficult to do this is the two stage process, as you
would have create directives for managing this opaque data in config files.
Now my understanding is the part of the qdev philosophy is to not embed
connection information in device models themselves? So I am wondering what
you mean by the work needs to happen in the device model? Just briefly
looking at the QOM patches you mentioned they seem to solving a different
problem of encapsulating and interfacing device connections at the device
level. The problem we are trying to solve here is instanitating and
interconnecting devices at the machine level, so I am looking for some
clarification on what you mean there.
Regards
Peter
On Thu, Aug 25, 2011 at 11:27 PM, Anthony Liguori <anth...@codemonkey.ws>wrote:
> On 08/25/2011 01:41 AM, Peter A. G. Crosthwaite wrote:
>
>> Hello
>>
>> This is a general RFC for a framework developed at Petalogix for creating
>> QEMU models based on a passed device tree. Machine models are dynamically
>> constructed from parsing a Device Tree Specification (DTS) - no more
>> hard-coded machine models, which is critical for the FPGA-based platforms
>> (i.e. target-microblaze) but also will be very useful for forthcoming
>> DTS-driven ARM kernels as well. Device models (including QDev models) are
>> tagged as being associated with a "compatible" string. If a node with the
>> registered compatible string is found when the argument dts is parsed, then
>> the QDev model is instantiated.
>>
>> For example, An ethernet controller might have a device tree node:
>>
>> Ethernet_MAC: ethernet@81000000 {
>> compatible = "xlnx,xps-ethernetlite-4.00.a"**,
>> "xlnx,xps-ethernetlite-1.00.a"**;
>> device_type = "network";
>> interrupt-parent =<&xps_intc_0>;
>> interrupts =< 1 0>;
>> local-mac-address = [ 00 0a 35 00 22 01 ];
>> reg =< 0x81000000 0x10000>;
>> ...
>> } ;
>>
>> Our framework registers the compatibility "xlnx,xps-ethernetlite-1.00.a"
>> as being associated with the xilinx.ethlite qdev model
>> (hw/xilinx_ethlite.c), and each time this compatiblity is discovered in the
>> device tree, the qdev model is instantiated (see path 10/14 for code details
>> on this particular example).The reg property is used to set the device base
>> address and the interrupt properties are used to connect interrupts. Device
>> tree (more info @ devicetree.org) provides a standarised way of
>> specifiying such connecitons, and we use all this to create machine models.
>>
>> Compatibilities are registered statically from within device models as
>> such:
>>
>> fdt_qdev_register_**compatibility(&xilinx_ethlite_**fdt_qdev_ops,
>> "xlnx,xps-ethernetlite-1.00.a"**);
>>
>> Where the first argument is a struct containing constant and handlers
>> provided by the deivce model to handle device instantiation. Device
>> instantiation is performed by the framework (not the Qdev models themselves)
>>
>> We have also set up a mechanism for machine models to communicate with
>> each other by means other than bus transactions. DTS provides a means to
>> specify arbitrary interconnections between devices, and we use this to
>> instantiate connections such as hierarchical interrupt controllers and point
>> to point DMA interconnections. This provides a consistent and clean way of
>> specifying inter-device connectivity other than via the system bus.
>>
>> The platform is tested for Xilinx Microblaze and PPC platforms, and we
>> have been using it both interally at PetaLogix and publishing to customers
>> for approx. 6 months now. We have setup FDT instantiation code for all of
>> the xilinx microbalze/PPC supported periphperals. We are currently
>> developing support for an ARM platform. The framework itself is however
>> independent of architecture so this could be used for creating machine
>> models for any machine.
>>
>> This patch series is a minimal patch series containing support for only
>> microblaze and a handful of peripherals. Support for a more complete range
>> of device models and other cpu architectures will come in future patches.
>>
>> We would welcome any comments or questions about the approach so that we
>> can get it merged upstream.
>>
>
> This is just another form of -readconfig AFAICT.
>
> I don't think the data representation really has anything to do with why we
> have hard coded machines. The real work needs to happen in the device model
> (see my QEMU Object Model patches).
>
> I'm also not a big fan of the DTS syntax for machine representation since
> it makes it very hard to represent backends.
>
> Regards,
>
> Anthony Liguori
>
>
>
>> Regards,
>> Peter
>>
>> Edgar E. Iglesias (2):
>> microblaze: Make the MSR PVR bit non writable
>> microblaze: Add an MSR_PVR constant and use it.
>>
>> Peter A. G. Crosthwaite (12):
>> qemu-coroutine: Add simple work queue support
>> device_tree: Extended interface for fdt_generic
>> fdt_generic: First revision
>> xilinx_uartlite: Added fdt gen. platform support
>> pflash_cfi01: Added fdt generic platform support
>> qdev: Added fn for querying device property types
>> fdt_generic_qdev: first revision
>> xilinx_timer: Added fdt_generic platform support
>> xilinx_intc: Added fdt generic platform support
>> xilinx_ethlite: Added fdt generic platform support
>> vl.c: Added hw_dtb/kern_dtb command line opts
>> microblaze_generic_fdt: first revision
>>
>> Makefile.objs | 4 +
>> Makefile.target | 1 +
>> device_tree.c | 202 +++++++++++++++++++
>> device_tree.h | 30 +++
>> hw/fdt_generic.c | 199 +++++++++++++++++++
>> hw/fdt_generic.h | 92 +++++++++
>> hw/fdt_generic_devices.h | 8 +
>> hw/fdt_generic_qdev.c | 75 +++++++
>> hw/fdt_generic_qdev.h | 46 +++++
>> hw/fdt_generic_util.c | 196 ++++++++++++++++++
>> hw/fdt_generic_util.h | 43 ++++
>> hw/microblaze_generic_fdt.c | 439 ++++++++++++++++++++++++++++++**
>> +++++++++++
>> hw/pflash_cfi01.c | 37 ++++
>> hw/qdev-properties.c | 9 +
>> hw/qdev.h | 1 +
>> hw/xilinx_ethlite.c | 39 ++++-
>> hw/xilinx_intc.c | 35 ++++-
>> hw/xilinx_timer.c | 39 ++++-
>> hw/xilinx_uartlite.c | 24 +++
>> qemu-coroutine-lock.c | 13 ++
>> qemu-coroutine.h | 9 +
>> qemu-options.hx | 47 +++++
>> sysemu.h | 4 +
>> target-microblaze/cpu.h | 1 +
>> target-microblaze/translate.c | 11 +-
>> vl.c | 19 ++
>> 26 files changed, 1617 insertions(+), 6 deletions(-)
>> create mode 100644 hw/fdt_generic.c
>> create mode 100644 hw/fdt_generic.h
>> create mode 100644 hw/fdt_generic_devices.h
>> create mode 100644 hw/fdt_generic_qdev.c
>> create mode 100644 hw/fdt_generic_qdev.h
>> create mode 100644 hw/fdt_generic_util.c
>> create mode 100644 hw/fdt_generic_util.h
>> create mode 100644 hw/microblaze_generic_fdt.c
>>
>>
>
