Re: [Qemu-devel] [RFC] Machine description as data

Re: [Qemu-devel] [RFC] Machine description as data

[Hollis Blanchard]

On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
> Sorry for the length of this memo.  I tried to make it as concise as I
> could.  And there's working mock-up source code to go with it.
> 
> 
> Configuration should be data
> ----------------------------
> 
> A QEMU machine (selected with -M) is described by a struct QEMUMachine.
> Which contains almost nothing of interest.  Pretty much everything,
> including all the buses and devices is instead created by the machine's
> initialization function.
> 
> Init functions consider a plethora of ad hoc configuration parameters
> set by command line options.  Plenty of stuff remains hard-coded all
> the same.
> 
> Configuration should be data, not code.
> 
> A machine's buses and devices can be expressed as a device tree.  More
> on that below.
> 
> The need for a configuration file
> ---------------------------------
> 
> The command line is a rather odd place to define a virtual machine.
> Command line is fine for manipulating a particular run of the machine,
> but the machine description belongs into a configuration file.
> 
> Once configuration is data, we should be able to initialize it from a
> configuration file with relative ease.
> 
> However, this memo is only about the *internal* representation of
> configuration.  How we get there from a configuration file is a separate
> question.  It's without doubt a relevant question, but I feel I need to
> limit my scope to have a chance of getting anywhere.
> 
> The need for an abstract device interface
> -----------------------------------------
> 
> Currently, each virtual device is created, configured and initialized in
> its own idiosyncratic way.  Some configuration is received as arguments,
> some is passed in global variables.
> 
> This is workable as long as the machine is constructed by ad hoc init
> function code.  The resulting init function tends to be quite a
> hairball, though.
> 
> I'd like to propose an abstract device interface, so we can build a
> machine from its (tree-structured) configuration using just this
> interface.  Device idiosyncrasies are to be hidden in the driver code
> behind the interface.
> 
> What I propose to do
> --------------------
> 
> A. Configuration as data
> 
>    Define an internal machine configuration data structure.  Needs to be
>    sufficiently generic to be able to support even oddball machine
>    types.  Make it a decorated tree, i.e. a tree of named nodes with
>    named properties.
> 
>    Create an instance for a prototype machine type.  Make it a PC,
>    because that's the easiest to test.
> 
>    Define an abstract device interface, initially covering just device
>    configuration and initialization.
> 
>    Implement the device interface for the devices used by the prototype
>    machine type.
> 
>    Do not break existing machine types here.  This means we need to keep
>    legacy interfaces until their last user is gone (step B).  Could
>    become somewhat messy in places for a while.
> 
> B. Convert all the existing machine configurations to data.
> 
>    This can and should be done incrementally, each machine by people who
>    care and know about it.
> 
>    Clean up the legacy interfaces now unused, and any messes we made
>    behind them.
> 
> C. Read (and maybe write) machine configuration
> 
>    The external format to use is debatable.  Compared to the rest of the
>    task, its choice looks like detail to me, but I'm biased ;)
> 
>    Writing the data could be useful for debugging.
> 
> D. Command line options to modify the configuration tree
> 
>    If we want them.
> 
> E. Make legacy command line modify the configuration tree
> 
>    For compatibility.  This is my "favourite" part.
> 
> We need to start with A.  The other tasks are largely independent.
> 
> What I've already done
> ----------------------
> 
> Show me the code, they say.  Find attached a working prototype of step
> A.  It passes the "Linux boots" test for me.  I didn't bother to rebase
> to current HEAD, happy do to that on request.
> 
> Instead of hacking up machine "pc", I created a new machine "pcdt".  I
> took a number of shortcuts:
> 
> * I put the "pcdt" code into the new file dt.c, and copied code from
>   pc.c there.  I could have avoided that by putting my code in pc.c
>   instead.  Putting it in a new file helped me pick apart the pc.c
>   hairball.  To be cleaned up.
> 
> * I copied code from net.c.  Trivial to fix, just give it external
>   linkage there.
> 
> * I hard-coded the configuration tree in the wrong place (tree.c), out of
>   laziness.
> 
> * I didn't implement all the devices of the "pc" original.  The devices
>   I implemented might not support all existing command line options.
> 
> Notable qualities:
> 
> * Device drivers are cleanly separated from each other, and from the
>   device-agnostic configuration code.
> 
> * Each driver specifies the configurable properties in a single place.
> 
> * Device configuration is gotten from the configuration tree, which is
>   fully checked.  Unknown properties are rejected.
> 
> 
> Appendix: Linux device trees
> ----------------------------
> 
> This appendix is probably only of interest to some of you, feel free to
> skip.
> 
> The IEEE 1275 Open Firmware Device Tree solves a somewhat similar
> problem, namely to communicate environmental information (hardware and
> configuration) from firmware to operating system.  It's chiefly used on
> PowerPCs.  The OS calls Open Firmware to query the device tree.
> 
> Linux turns the Open Firmware device tree API into a data format.
> Actually two: the DT blob format is a binary data structure, and the
> DT source format is human-readable text.  The device tree compiler
> "dtc" can convert the two.
> 
> We already have a bit of code dealing with this, in device_tree.c.
> 
> I briefly examined the DT source format and the tree structure it
> describes for the purpose of QEMU configuration.  I decided against
> using it in my prototype because I found it awfully low-level and
> verbose for that purpose (I'm sure it serves the purpose it was designed
> for just fine).  Issues include:
> 
> * Since the DT is designed for booting kernels, not configuring QEMU,
>   there's information that has no place in QEMU configuration, and
>   required QEMU configuration isn't there.

What's needed is a "binding" in IEEE1275-speak: a document that
describes qemu-specific nodes/properties and how they are to be
interpreted.

As an example, you could require that block devices contain properties
named "qemu,path", "qemu,backend", etc.

> * Redundancy between node name and its device_type property.
> 
> * Property "reg", which encodes address ranges, does so in terms of
>   "cells": #address-cells 32-bit words (big endian) for the address,
>   followed by #size-cells words for the size, where #address-cells and
>   #size-cells are properties of the enclosing bus.  If this sounds
>   like gibberish to you, well, that's my point.

I'm CCing devicetree-discuss for broader discussion.

I won't say IEEE1275 is perfect, but IMHO it would be pretty silly to
reinvent all the design and infrastructure for a similar-but-different
device tree.

[Patch snipped]

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [Qemu-devel] [RFC] Machine description as data

[Hollis Blanchard]

On Wed, 2009-02-11 at 16:31 +0000, Ian Jackson wrote:
> Markus Armbruster writes ("[Qemu-devel] [RFC] Machine description as data"):
> > [stuff]
> 
> Yes, this is a good approach.  I have one question though:
> 
> >    Define an internal machine configuration data structure.  Needs to be
> >    sufficiently generic to be able to support even oddball machine
> >    types.  Make it a decorated tree, i.e. a tree of named nodes with
> >    named properties.
> 
> Many real systems are not strictly tree-structured, because there are
> hardware devices which connect via several different paths.  For
> example, much hardware supported by OpenWRT comes with a built-in
> bridge chip connected internally to a hidden ethernet card; a tape
> library would have one interface for the robot and a bunch of SCSI
> tapereaders; etc.

I'm not sure these are great examples, since there still a clear
hierarchy here (e.g. the ethernet card is "behind" the bridge chip).
Also, there is already established practice for representing SoC devices
(found in many embedded PowerPC processors): see arch/powerpc/boot/dts.

However, what *is* a good example would be the interrupt hierarchy,
which can be totally separate from the address/data hierarchy.

The device tree is about *devices*, not interfaces. Each node (device)
can mark itself as implementing multiple interfaces, which is what the
"compatible" property is about.

> When an emulation of such a device starts up, it will want to bind to
> several parents.  How will you represent this ?

There is established design for representing the interrupt hierarchy in
IEEE1275, using explicit "interrupt-parent" properties to create the
interrupt tree.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [RFC] Machine description as data

[Blue Swirl]

On 2/11/09, Hollis Blanchard <hollisb@us.ibm.com> wrote:
> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
>  > Sorry for the length of this memo.  I tried to make it as concise as I
>  > could.  And there's working mock-up source code to go with it.
>  >
>  >
>  > Configuration should be data
>  > ----------------------------
>  >
>  > A QEMU machine (selected with -M) is described by a struct QEMUMachine.
>  > Which contains almost nothing of interest.  Pretty much everything,
>  > including all the buses and devices is instead created by the machine's
>  > initialization function.
>  >
>  > Init functions consider a plethora of ad hoc configuration parameters
>  > set by command line options.  Plenty of stuff remains hard-coded all
>  > the same.
>  >
>  > Configuration should be data, not code.
>  >
>  > A machine's buses and devices can be expressed as a device tree.  More
>  > on that below.
>  >
>  > The need for a configuration file
>  > ---------------------------------
>  >
>  > The command line is a rather odd place to define a virtual machine.
>  > Command line is fine for manipulating a particular run of the machine,
>  > but the machine description belongs into a configuration file.
>  >
>  > Once configuration is data, we should be able to initialize it from a
>  > configuration file with relative ease.
>  >
>  > However, this memo is only about the *internal* representation of
>  > configuration.  How we get there from a configuration file is a separate
>  > question.  It's without doubt a relevant question, but I feel I need to
>  > limit my scope to have a chance of getting anywhere.
>  >
>  > The need for an abstract device interface
>  > -----------------------------------------
>  >
>  > Currently, each virtual device is created, configured and initialized in
>  > its own idiosyncratic way.  Some configuration is received as arguments,
>  > some is passed in global variables.
>  >
>  > This is workable as long as the machine is constructed by ad hoc init
>  > function code.  The resulting init function tends to be quite a
>  > hairball, though.
>  >
>  > I'd like to propose an abstract device interface, so we can build a
>  > machine from its (tree-structured) configuration using just this
>  > interface.  Device idiosyncrasies are to be hidden in the driver code
>  > behind the interface.
>  >
>  > What I propose to do
>  > --------------------
>  >
>  > A. Configuration as data
>  >
>  >    Define an internal machine configuration data structure.  Needs to be
>  >    sufficiently generic to be able to support even oddball machine
>  >    types.  Make it a decorated tree, i.e. a tree of named nodes with
>  >    named properties.
>  >
>  >    Create an instance for a prototype machine type.  Make it a PC,
>  >    because that's the easiest to test.
>  >
>  >    Define an abstract device interface, initially covering just device
>  >    configuration and initialization.
>  >
>  >    Implement the device interface for the devices used by the prototype
>  >    machine type.
>  >
>  >    Do not break existing machine types here.  This means we need to keep
>  >    legacy interfaces until their last user is gone (step B).  Could
>  >    become somewhat messy in places for a while.
>  >
>  > B. Convert all the existing machine configurations to data.
>  >
>  >    This can and should be done incrementally, each machine by people who
>  >    care and know about it.
>  >
>  >    Clean up the legacy interfaces now unused, and any messes we made
>  >    behind them.
>  >
>  > C. Read (and maybe write) machine configuration
>  >
>  >    The external format to use is debatable.  Compared to the rest of the
>  >    task, its choice looks like detail to me, but I'm biased ;)
>  >
>  >    Writing the data could be useful for debugging.
>  >
>  > D. Command line options to modify the configuration tree
>  >
>  >    If we want them.
>  >
>  > E. Make legacy command line modify the configuration tree
>  >
>  >    For compatibility.  This is my "favourite" part.
>  >
>  > We need to start with A.  The other tasks are largely independent.
>  >
>  > What I've already done
>  > ----------------------
>  >
>  > Show me the code, they say.  Find attached a working prototype of step
>  > A.  It passes the "Linux boots" test for me.  I didn't bother to rebase
>  > to current HEAD, happy do to that on request.
>  >
>  > Instead of hacking up machine "pc", I created a new machine "pcdt".  I
>  > took a number of shortcuts:
>  >
>  > * I put the "pcdt" code into the new file dt.c, and copied code from
>  >   pc.c there.  I could have avoided that by putting my code in pc.c
>  >   instead.  Putting it in a new file helped me pick apart the pc.c
>  >   hairball.  To be cleaned up.
>  >
>  > * I copied code from net.c.  Trivial to fix, just give it external
>  >   linkage there.
>  >
>  > * I hard-coded the configuration tree in the wrong place (tree.c), out of
>  >   laziness.
>  >
>  > * I didn't implement all the devices of the "pc" original.  The devices
>  >   I implemented might not support all existing command line options.
>  >
>  > Notable qualities:
>  >
>  > * Device drivers are cleanly separated from each other, and from the
>  >   device-agnostic configuration code.
>  >
>  > * Each driver specifies the configurable properties in a single place.
>  >
>  > * Device configuration is gotten from the configuration tree, which is
>  >   fully checked.  Unknown properties are rejected.
>  >
>  >
>  > Appendix: Linux device trees
>  > ----------------------------
>  >
>  > This appendix is probably only of interest to some of you, feel free to
>  > skip.
>  >
>  > The IEEE 1275 Open Firmware Device Tree solves a somewhat similar
>  > problem, namely to communicate environmental information (hardware and
>  > configuration) from firmware to operating system.  It's chiefly used on
>  > PowerPCs.  The OS calls Open Firmware to query the device tree.
>  >
>  > Linux turns the Open Firmware device tree API into a data format.
>  > Actually two: the DT blob format is a binary data structure, and the
>  > DT source format is human-readable text.  The device tree compiler
>  > "dtc" can convert the two.
>  >
>  > We already have a bit of code dealing with this, in device_tree.c.
>  >
>  > I briefly examined the DT source format and the tree structure it
>  > describes for the purpose of QEMU configuration.  I decided against
>  > using it in my prototype because I found it awfully low-level and
>  > verbose for that purpose (I'm sure it serves the purpose it was designed
>  > for just fine).  Issues include:
>  >
>  > * Since the DT is designed for booting kernels, not configuring QEMU,
>  >   there's information that has no place in QEMU configuration, and
>  >   required QEMU configuration isn't there.
>
>
> What's needed is a "binding" in IEEE1275-speak: a document that
>  describes qemu-specific nodes/properties and how they are to be
>  interpreted.
>
>  As an example, you could require that block devices contain properties
>  named "qemu,path", "qemu,backend", etc.

It should be nice to take the Qemu device tree and use that in
OpenBIOS to provide the OF tree. Linux could use the Qemu tree
directly.

>  > * Redundancy between node name and its device_type property.
>  >
>  > * Property "reg", which encodes address ranges, does so in terms of
>  >   "cells": #address-cells 32-bit words (big endian) for the address,
>  >   followed by #size-cells words for the size, where #address-cells and
>  >   #size-cells are properties of the enclosing bus.  If this sounds
>  >   like gibberish to you, well, that's my point.
>
>
> I'm CCing devicetree-discuss for broader discussion.
>
>  I won't say IEEE1275 is perfect, but IMHO it would be pretty silly to
>  reinvent all the design and infrastructure for a similar-but-different
>  device tree.

Fully agree. Based on the suggestions you gave, I don't even think FDT
would need to be extended.

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Wed, Feb 11, 2009 at 12:57:19PM -0600, Hollis Blanchard wrote:
> On Wed, 2009-02-11 at 16:31 +0000, Ian Jackson wrote:
> > Markus Armbruster writes ("[Qemu-devel] [RFC] Machine description as data"):
> > > [stuff]
> > 
> > Yes, this is a good approach.  I have one question though:
> > 
> > >    Define an internal machine configuration data structure.  Needs to be
> > >    sufficiently generic to be able to support even oddball machine
> > >    types.  Make it a decorated tree, i.e. a tree of named nodes with
> > >    named properties.
> > 
> > Many real systems are not strictly tree-structured, because there are
> > hardware devices which connect via several different paths.  For
> > example, much hardware supported by OpenWRT comes with a built-in
> > bridge chip connected internally to a hidden ethernet card; a tape
> > library would have one interface for the robot and a bunch of SCSI
> > tapereaders; etc.
> 
> I'm not sure these are great examples, since there still a clear
> hierarchy here (e.g. the ethernet card is "behind" the bridge chip).
> Also, there is already established practice for representing SoC devices
> (found in many embedded PowerPC processors): see arch/powerpc/boot/dts.
> 
> However, what *is* a good example would be the interrupt hierarchy,
> which can be totally separate from the address/data hierarchy.
> 
> The device tree is about *devices*, not interfaces. Each node (device)
> can mark itself as implementing multiple interfaces, which is what the
> "compatible" property is about.
> 
> > When an emulation of such a device starts up, it will want to bind to
> > several parents.  How will you represent this ?
> 
> There is established design for representing the interrupt hierarchy in
> IEEE1275, using explicit "interrupt-parent" properties to create the
> interrupt tree.

Note that despite "interrupt tree" being the normal terminology, it's
actually a DAG, which is Hollis' point.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
[snip]
> > I briefly examined the DT source format and the tree structure it
> > describes for the purpose of QEMU configuration.  I decided against
> > using it in my prototype because I found it awfully low-level and
> > verbose for that purpose (I'm sure it serves the purpose it was designed
> > for just fine).  Issues include:
> > 
> > * Since the DT is designed for booting kernels, not configuring QEMU,
> >   there's information that has no place in QEMU configuration, and
> >   required QEMU configuration isn't there.
> 
> What's needed is a "binding" in IEEE1275-speak: a document that
> describes qemu-specific nodes/properties and how they are to be
> interpreted.
> 
> As an example, you could require that block devices contain properties
> named "qemu,path", "qemu,backend", etc.

Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
extra information for qemu's use.  As for the other direction, in some
cases it may be appropriate for qemu's device tree code to fill in
missing device tree properties, based on what the device emulation
code knows about itself.

> > * Redundancy between node name and its device_type property.

Note that "device_type" may not mean what you think.  It describes
what methods the device support within the OF client interface.  New
device trees that aren't linked to a full OF implementation with
client interface should generally omit device_type in most places
(there are a few special cases for compatibility with OSes that expect
device_type properties in certain places).

> > * Property "reg", which encodes address ranges, does so in terms of
> >   "cells": #address-cells 32-bit words (big endian) for the address,
> >   followed by #size-cells words for the size, where #address-cells and
> >   #size-cells are properties of the enclosing bus.  If this sounds
> >   like gibberish to you, well, that's my point.

#address-cells and #size-cells takes a little getting used to, but
it's really not that bad.  It's just a way of representing the fact
that different busses have different sized address encodings.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [RFC] Machine description as data

[Markus Armbruster]

Hollis Blanchard <hollisb@us.ibm.com> writes:

> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
>> Sorry for the length of this memo.  I tried to make it as concise as I
>> could.  And there's working mock-up source code to go with it.
[...]
>> Appendix: Linux device trees
>> ----------------------------
>> 
>> This appendix is probably only of interest to some of you, feel free to
>> skip.
>> 
>> The IEEE 1275 Open Firmware Device Tree solves a somewhat similar
>> problem, namely to communicate environmental information (hardware and
>> configuration) from firmware to operating system.  It's chiefly used on
>> PowerPCs.  The OS calls Open Firmware to query the device tree.
>> 
>> Linux turns the Open Firmware device tree API into a data format.
>> Actually two: the DT blob format is a binary data structure, and the
>> DT source format is human-readable text.  The device tree compiler
>> "dtc" can convert the two.
>> 
>> We already have a bit of code dealing with this, in device_tree.c.
>> 
>> I briefly examined the DT source format and the tree structure it
>> describes for the purpose of QEMU configuration.  I decided against
>> using it in my prototype because I found it awfully low-level and
>> verbose for that purpose (I'm sure it serves the purpose it was designed
>> for just fine).  Issues include:
>> 
>> * Since the DT is designed for booting kernels, not configuring QEMU,
>>   there's information that has no place in QEMU configuration, and
>>   required QEMU configuration isn't there.
>
> What's needed is a "binding" in IEEE1275-speak: a document that
> describes qemu-specific nodes/properties and how they are to be
> interpreted.
>
> As an example, you could require that block devices contain properties
> named "qemu,path", "qemu,backend", etc.
>
>> * Redundancy between node name and its device_type property.
>> 
>> * Property "reg", which encodes address ranges, does so in terms of
>>   "cells": #address-cells 32-bit words (big endian) for the address,
>>   followed by #size-cells words for the size, where #address-cells and
>>   #size-cells are properties of the enclosing bus.  If this sounds
>>   like gibberish to you, well, that's my point.
>
> I'm CCing devicetree-discuss for broader discussion.
>
> I won't say IEEE1275 is perfect, but IMHO it would be pretty silly to
> reinvent all the design and infrastructure for a similar-but-different
> device tree.
>
> [Patch snipped]

I'm not at all opposed to adapting FDT for QEMU use.  My patch is a
prototype, and I'm prepared to throw away some or all of it.

To get this thing started, I wanted working code to demonstrate what I'm
talking about.  If I had dug deeper into FDTs first, we would not be
talking now.

The task I outlined in my memo involves much more than just coming up
with a device tree data structure.  That data structure is to me one
detail among many, and a much less hairy one than most others.  It
certainly was for the prototype.

If I read the comments correctly (all comments, not just this one), the
only real issue with my proposal is you'd rather use FDT for the config
tree.  I don't mind, except I don't know enough about that stuff to do
it all by myself, at least not in a reasonable time frame.  I think I
understand the concepts, can read .dts files with some head-scratching,
and I could perhaps even write one if I sacrificed a chicken or two.
Designing a binding, however, feels well above my level of
(in)competence.

So, to make FDT happen, I need help.  Specifically:

* Point me to the FDT code I'm supposed to integrate.  I'm looking for
  basic decorated tree stuff: create trees, traverse them, get and put
  properties, add and delete nodes, read and write them as plain,
  human-readable text.

* Provide an example tree describing a bare-bones PC, like the one in my
  prototype: CPU, RAM, BIOS, PIC, APIC, IOAPIC, PIT, DMA, UART, parallel
  port, floppy controller, CMOS & RTC, a20 gate (port 92) and other
  miscellanous I/O ports, i440fx, PIIX3 (ISA bridge, IDE, USB, ACPI),
  Cirrus VGA with BIOS, some PCI NIC.  This gives us all an idea of the
  tree structure.  Morphing that into something suitable for QEMU
  configuration shouldn't be too hard then, just an exercice in
  redecorating the tree.

* Advice as we go.

Volunteers?

Re: [RFC] Machine description as data

[Markus Armbruster]

David Gibson <dwg@au1.ibm.com> writes:

> On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
>> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
> [snip]
>> > I briefly examined the DT source format and the tree structure it
>> > describes for the purpose of QEMU configuration.  I decided against
>> > using it in my prototype because I found it awfully low-level and
>> > verbose for that purpose (I'm sure it serves the purpose it was designed
>> > for just fine).  Issues include:
>> > 
>> > * Since the DT is designed for booting kernels, not configuring QEMU,
>> >   there's information that has no place in QEMU configuration, and
>> >   required QEMU configuration isn't there.
>> 
>> What's needed is a "binding" in IEEE1275-speak: a document that
>> describes qemu-specific nodes/properties and how they are to be
>> interpreted.
>> 
>> As an example, you could require that block devices contain properties
>> named "qemu,path", "qemu,backend", etc.
>
> Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
> extra information for qemu's use.

I don't feel up to that task, because I'm not really familiar with
IEEE1275.  Could you help out?

>                                    As for the other direction, in some
> cases it may be appropriate for qemu's device tree code to fill in
> missing device tree properties, based on what the device emulation
> code knows about itself.

Agreed.  Configuration should only contain what is actually
configurable.  Anything else that is needed by a consumer of the tree
should be filled in automatically.

>> > * Redundancy between node name and its device_type property.
>
> Note that "device_type" may not mean what you think.  It describes
> what methods the device support within the OF client interface.  New
> device trees that aren't linked to a full OF implementation with
> client interface should generally omit device_type in most places
> (there are a few special cases for compatibility with OSes that expect
> device_type properties in certain places).

I guess the ignorance I mentioned shows ;)

>> > * Property "reg", which encodes address ranges, does so in terms of
>> >   "cells": #address-cells 32-bit words (big endian) for the address,
>> >   followed by #size-cells words for the size, where #address-cells and
>> >   #size-cells are properties of the enclosing bus.  If this sounds
>> >   like gibberish to you, well, that's my point.
>
> #address-cells and #size-cells takes a little getting used to, but
> it's really not that bad.  It's just a way of representing the fact
> that different busses have different sized address encodings.

I didn't mean to say they are a bad idea for FDTs, just that they're on
an awkward level of abstraction for QEMU configuration.  There, I'd
rather express a PCI address as "02:01.0" than as <0x00000220>.
Translating text to binary is the machine's job, not the user's.

Re: [RFC] Machine description as data

[Carl-Daniel Hailfinger]

On 12.02.2009 11:26, Markus Armbruster wrote:
> Hollis Blanchard <hollisb@us.ibm.com> writes:
>   
>> I won't say IEEE1275 is perfect, but IMHO it would be pretty silly to
>> reinvent all the design and infrastructure for a similar-but-different
>> device tree.
>>
>> [Patch snipped]
>>     
>
> I'm not at all opposed to adapting FDT for QEMU use.  My patch is a
> prototype, and I'm prepared to throw away some or all of it.
> [...]
> If I read the comments correctly (all comments, not just this one), the
> only real issue with my proposal is you'd rather use FDT for the config
> tree.  I don't mind, except I don't know enough about that stuff to do
> it all by myself, at least not in a reasonable time frame.  I think I
> understand the concepts, can read .dts files with some head-scratching,
> and I could perhaps even write one if I sacrificed a chicken or two.
> Designing a binding, however, feels well above my level of
> (in)competence.
>
> So, to make FDT happen, I need help.  Specifically:
>
> * Provide an example tree describing a bare-bones PC, like the one in my
>   prototype: CPU, RAM, BIOS, PIC, APIC, IOAPIC, PIT, DMA, UART, parallel
>   port, floppy controller, CMOS & RTC, a20 gate (port 92) and other
>   miscellanous I/O ports, i440fx, PIIX3 (ISA bridge, IDE, USB, ACPI),
>   Cirrus VGA with BIOS, some PCI NIC.  This gives us all an idea of the
>   tree structure.  Morphing that into something suitable for QEMU
>   configuration shouldn't be too hard then, just an exercice in
>   redecorating the tree.
>   

Once you start modeling any recent AMD x86_64 hardware accurately, it
starts to hurt.
The HyperTransport link topology is needed for correct setup of HT
links, but HT appears as part of virtual PCI config interfaces. That
would be OK, but the topology of the PCI config interfaces of the HT
links has almost nothing to do with the real HT topology.

You don't get a tree or even a DAG. It's just a digraph with the
occassional cycle. And you have to annotate some edges as well, not just
the vertices. I have no idea whether the FDT can represent such graphs.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [RFC] Machine description as data

[Carl-Daniel Hailfinger]

On 12.02.2009 11:26, Markus Armbruster wrote:
> David Gibson <dwg@au1.ibm.com> writes:
>
>   
>> On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
>>     
>>> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
>>>       
>>>> I briefly examined the DT source format and the tree structure it
>>>> describes for the purpose of QEMU configuration.  I decided against
>>>> using it in my prototype because I found it awfully low-level and
>>>> verbose for that purpose (I'm sure it serves the purpose it was designed
>>>> for just fine).  Issues include:
>>>>
>>>> * Since the DT is designed for booting kernels, not configuring QEMU,
>>>>   there's information that has no place in QEMU configuration, and
>>>>   required QEMU configuration isn't there.
>>>>         
>>> What's needed is a "binding" in IEEE1275-speak: a document that
>>> describes qemu-specific nodes/properties and how they are to be
>>> interpreted.
>>>
>>> As an example, you could require that block devices contain properties
>>> named "qemu,path", "qemu,backend", etc.
>>>> * Property "reg", which encodes address ranges, does so in terms of
>>>>   "cells": #address-cells 32-bit words (big endian) for the address,
>>>>   followed by #size-cells words for the size, where #address-cells and
>>>>   #size-cells are properties of the enclosing bus.  If this sounds
>>>>   like gibberish to you, well, that's my point.
>>>>         
>> #address-cells and #size-cells takes a little getting used to, but
>> it's really not that bad.  It's just a way of representing the fact
>> that different busses have different sized address encodings.
>>     
>
> I didn't mean to say they are a bad idea for FDTs, just that they're on
> an awkward level of abstraction for QEMU configuration.  There, I'd
> rather express a PCI address as "02:01.0" than as <0x00000220>.
> Translating text to binary is the machine's job, not the user's.
>   

Coreboot v3 is using some device tree variant which is IMHO a bit more
user friendly. The tree below is incomplete (for example, it leaves out
the PCI bus number and assumes that it is zero by default), but you
surely get the idea.

/{
    mainboard_vendor = "Gigabyte";
    mainboard_name = "M57SLI";
    cpus { };
    apic@0 {
    };
    domain@0 {
        pci@0,0 { /* MCP55 RAM? */ 
        };
        pci@1,0 {
            /config/("southbridge/nvidia/mcp55/lpc.dts");
            ioport@2e {
                /config/("superio/ite/it8716f/dts");
                com1enable = "1";
                ecenable = "1";
                kbenable = "1";
                mouseenable = "1";
                gpioenable = "1";
            };
        };
        pci@1,1 { /* smbus */
        };
        pci@2,0 { /* usb */
        };
        pci@2,1 { /* usb */
        };
        pci@4,0 {
            /config/("southbridge/nvidia/mcp55/ide.dts");
            ide0_enable = "1";
        };
        pci@5,0 {
            /config/("southbridge/nvidia/mcp55/sata.dts");
            sata0_enable = "1";
        };
        pci@5,1 {
            /config/("southbridge/nvidia/mcp55/sata.dts");
            sata1_enable = "1";
        };
        pci@6,0 { /* PCI */
        };
        pci@6,1 {
            /*/config/("southbridge/nvidia/mcp55/audio.dts"); */
        };
        pci@8,0 {
        /*
            /config/("southbridge/nvidia/mcp55/nic.dts");
            mac_eeprom_smbus = "3";
            mac_eeprom_addr = "0x51";
        */
        };
        pci@f,0 { /* PCIe */ 
        };
        pci@18,0 {
            /config/("northbridge/amd/k8/pci");
        };
        pci@18,1 {};
        pci@18,2 {};
        pci@18,3 {
            /config/("northbridge/amd/k8/mcf3");
        };
    };
};


The /config/("...") statements are basically comparable to #include
"..." in C.

While the syntax pci@dev,fn is different to the bus:dev.fn you're used
to, it's IMHO a lot more readable than <0x00000220>.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [RFC] Machine description as data

[M. Warner Losh]

<87iqng0x3t.fsf@pike.pond.sub.org>
<49941AE3.1000806@gmx.net>
X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In message: <49941AE3.1000806@gmx.net>
Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> writes:
: > I didn't mean to say they are a bad idea for FDTs, just that they're on
: > an awkward level of abstraction for QEMU configuration.  There, I'd
: > rather express a PCI address as "02:01.0" than as <0x00000220>.
: > Translating text to binary is the machine's job, not the user's.
: 
: Coreboot v3 is using some device tree variant which is IMHO a bit more
: user friendly. The tree below is incomplete (for example, it leaves out
: the PCI bus number and assumes that it is zero by default), but you
: surely get the idea.
: 
: /{
:     mainboard_vendor = "Gigabyte";
:     mainboard_name = "M57SLI";
:     cpus { };
:     apic@0 {
:     };
:     domain@0 {
:         pci@0,0 { /* MCP55 RAM? */ 
:         };
:         pci@1,0 {
:             /config/("southbridge/nvidia/mcp55/lpc.dts");
:             ioport@2e {

<etc>

I'd like to make a couple of comments here.

One, I dislike the DTS syntax.  It is hard to learn to read, and I
always have to have the manual in my hands to read it.

However, every board that's being produced for powerpc has the DTB at
least available.  It has to be, or (recent?) Linux kernels flat out
won't work.  This suggests that it might be a good idea to look at
this format.

There's DTS and DTB.  One is the source, the other is the binary
created from the source.  I'd recommend that qemu actually use the DTB
rather than the DTS to implement things.  This way one could have a
nicer syntax like the above and generate the DTB, or one could use the
DTS provided by a vendor if there was a more specific board they
wanted qemu to emulate.

Carl-Daniel, how does coreboot v3 generate the data that's passed to
the kernel?

Warner

Re: [Qemu-devel] [RFC] Machine description as data

[Hollis Blanchard]

On Thu, 2009-02-12 at 11:26 +0100, Markus Armbruster wrote:
>  David Gibson <dwg-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org> writes:
> 
> > On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
> >> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
> > [snip]
> >> > I briefly examined the DT source format and the tree structure it
> >> > describes for the purpose of QEMU configuration.  I decided
> against
> >> > using it in my prototype because I found it awfully low-level and
> >> > verbose for that purpose (I'm sure it serves the purpose it was
> designed
> >> > for just fine).  Issues include:
> >> > 
> >> > * Since the DT is designed for booting kernels, not configuring
> QEMU,
> >> >   there's information that has no place in QEMU configuration,
> and
> >> >   required QEMU configuration isn't there.
> >> 
> >> What's needed is a "binding" in IEEE1275-speak: a document that
> >> describes qemu-specific nodes/properties and how they are to be
> >> interpreted.
> >> 
> >> As an example, you could require that block devices contain
> properties
> >> named "qemu,path", "qemu,backend", etc.
> >
> > Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
> > extra information for qemu's use.
> 
> I don't feel up to that task, because I'm not really familiar with
> IEEE1275.  Could you help out?

I'm not really a "language lawyer" for device trees, but I can help.

FWIW, I was imagining (from a PowerPC point of view) that a strict
subset of the device tree interpreted by qemu would be passed into the
guest. In other words, once qemu is done with it, it would strip every
property prefixed with "qemu," and copy the result into guest memory.
PowerPC kernels require this data structure, and even when firmware runs
in the guest, you still need to tell the firmware what the system layout
is, and the device tree is an obvious candidate...

For x86, maybe it doesn't make sense to have in-guest BIOS split a
qemu-provided device tree into all the nasty BIOS data structures, but I
just wanted to give you an idea of how this could be used on multiple
architectures.

-- 
Hollis Blanchard
IBM Linux Technology Center

Re: [RFC] Machine description as data

[Markus Armbruster]

"M. Warner Losh" <imp@bsdimp.com> writes:

> <87iqng0x3t.fsf@pike.pond.sub.org>
> <49941AE3.1000806@gmx.net>
> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
> Mime-Version: 1.0
> Content-Type: Text/Plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> In message: <49941AE3.1000806@gmx.net>
> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> writes:
> : > I didn't mean to say they are a bad idea for FDTs, just that they're on
> : > an awkward level of abstraction for QEMU configuration.  There, I'd
> : > rather express a PCI address as "02:01.0" than as <0x00000220>.
> : > Translating text to binary is the machine's job, not the user's.
> : 
> : Coreboot v3 is using some device tree variant which is IMHO a bit more
> : user friendly. The tree below is incomplete (for example, it leaves out
> : the PCI bus number and assumes that it is zero by default), but you
> : surely get the idea.
> : 
> : /{
> :     mainboard_vendor = "Gigabyte";
> :     mainboard_name = "M57SLI";
> :     cpus { };
> :     apic@0 {
> :     };
> :     domain@0 {
> :         pci@0,0 { /* MCP55 RAM? */ 
> :         };
> :         pci@1,0 {
> :             /config/("southbridge/nvidia/mcp55/lpc.dts");
> :             ioport@2e {
>
> <etc>
>
> I'd like to make a couple of comments here.
>
> One, I dislike the DTS syntax.  It is hard to learn to read, and I
> always have to have the manual in my hands to read it.
>
> However, every board that's being produced for powerpc has the DTB at
> least available.  It has to be, or (recent?) Linux kernels flat out
> won't work.  This suggests that it might be a good idea to look at
> this format.
>
> There's DTS and DTB.  One is the source, the other is the binary
> created from the source.  I'd recommend that qemu actually use the DTB
> rather than the DTS to implement things.  This way one could have a
> nicer syntax like the above and generate the DTB, or one could use the
> DTS provided by a vendor if there was a more specific board they
> wanted qemu to emulate.

As far as I know, dtc can decompile DTB into DTS.

I'm not a fan of DTS syntax either, but if we choose FDT, then inventing
an alternative syntax seems rather pointless to me.

As to reading configuration in a binary format: let's not complicate
things more than we need.  It's just a decorated tree, folks.

[...]

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:

> On Thu, 2009-02-12 at 11:26 +0100, Markus Armbruster wrote:
>>  David Gibson <dwg-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org> writes:
>> 
>> > On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
>> >> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
>> > [snip]
>> >> > I briefly examined the DT source format and the tree structure it
>> >> > describes for the purpose of QEMU configuration.  I decided
>> against
>> >> > using it in my prototype because I found it awfully low-level and
>> >> > verbose for that purpose (I'm sure it serves the purpose it was
>> designed
>> >> > for just fine).  Issues include:
>> >> > 
>> >> > * Since the DT is designed for booting kernels, not configuring
>> QEMU,
>> >> >   there's information that has no place in QEMU configuration,
>> and
>> >> >   required QEMU configuration isn't there.
>> >> 
>> >> What's needed is a "binding" in IEEE1275-speak: a document that
>> >> describes qemu-specific nodes/properties and how they are to be
>> >> interpreted.
>> >> 
>> >> As an example, you could require that block devices contain
>> properties
>> >> named "qemu,path", "qemu,backend", etc.
>> >
>> > Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
>> > extra information for qemu's use.
>> 
>> I don't feel up to that task, because I'm not really familiar with
>> IEEE1275.  Could you help out?
>
> I'm not really a "language lawyer" for device trees, but I can help.

Appreciated!

> FWIW, I was imagining (from a PowerPC point of view) that a strict
> subset of the device tree interpreted by qemu would be passed into the
> guest. In other words, once qemu is done with it, it would strip every
> property prefixed with "qemu," and copy the result into guest memory.
> PowerPC kernels require this data structure, and even when firmware runs
> in the guest, you still need to tell the firmware what the system layout
> is, and the device tree is an obvious candidate...
>
> For x86, maybe it doesn't make sense to have in-guest BIOS split a
> qemu-provided device tree into all the nasty BIOS data structures, but I
> just wanted to give you an idea of how this could be used on multiple
> architectures.

We want a machine configuration: a tree describing configurable devices
and their configurable properties.

For PowerPC, we also want a machine description: a tree describing those
devices and properties that the kernel can't easily and safely probe.

Now, there will be some overlap, and to get the machine description, you
surely want to start with the machine configuration.  But you'll
certainly have to add information beyond configuration.  Just stripping
out "qemu," properties won't do, I fear, unless you're happy to put tons
of stuff in the configuration file that is not actually configurable.
Which would likely annoy its human users.  And what to do with it?  Just
pass it on?  Or verify it matches reality?  Wouldn't that work be better
spent on generating the additional information on the fly, for the
targets that need it?

Once again, I'm not opposed to using some FDT binding for QEMU
configuration.  Syntax is superficial anyway.  It's the tree that
matters.

Re: [Qemu-devel] [RFC] Machine description as data

[Mitch Bradley]

>
> We want a machine configuration: a tree describing configurable devices
> and their configurable properties.
>   


Regarding configurable devices in Open Firmware:

The baseline usage model for configurable devices was that the firmware 
is responsible for establishing a consistent system configuration, 
possibly based on user-modifiable variables in non-volatile storage.  It 
reports the actual configuration to the OS via the device tree.

For cases where the choice needs to deferred until later, or perhaps 
changed dynamically, a device tree property reports the set of 
possibilities.  In cases where the firmware has already set up the 
devices, it reports the current choice via another property.

The device tree hierarchy serves as the "name space" framework for these 
properties.  Obviously, you need to specify the device for which the 
choice set applies.  The device tree is a coherent naming model for that 
purpose.

Obviously the hierarchical model has problems for highly-configurable 
chipsets in which a setting can result in a wholesale rearrangement of 
the overall connectivity, but it seems to me that board-design 
constraints usually make that a non-problem. The wiring on a given board 
generally forces the choice at that level, so the firmware for that 
board need not report that as a configurable choice.
> For PowerPC, we also want a machine description: a tree describing those
> devices and properties that the kernel can't easily and safely probe.
>   

The gist of the above sentence seems to presuppose that, if the kernel 
can probe, it should.  That's not the only way of thinking about the 
problem.  As a practical matter, the firmware usually needs to do a fair 
amount of probing too, in order to locate the console display and the 
boot devices.  In the process, the firmware usually discovers pretty 
much the entire machine configuration.  If the OS has to repeat the 
process from scratch, it slows down the boot process.  So the IEEE1275 
design supports the model where the firmware can do all the probing, 
handing off a complete system description to the OS.  The OS startup 
code can walk the tree and attach device drivers for what it finds, then 
arrange to handle insert/remove events from hot-pluggable buses.

Re: [RFC] Machine description as data

[Carl-Daniel Hailfinger]

On 12.02.2009 17:46, M. Warner Losh wrote:
> <87iqng0x3t.fsf@pike.pond.sub.org>
> <49941AE3.1000806@gmx.net>
> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
> Mime-Version: 1.0
> Content-Type: Text/Plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
>
> In message: <49941AE3.1000806@gmx.net>
> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> writes:
> : > I didn't mean to say they are a bad idea for FDTs, just that they're on
> : > an awkward level of abstraction for QEMU configuration.  There, I'd
> : > rather express a PCI address as "02:01.0" than as <0x00000220>.
> : > Translating text to binary is the machine's job, not the user's.
> : 
> : Coreboot v3 is using some device tree variant which is IMHO a bit more
> : user friendly. The tree below is incomplete (for example, it leaves out
> : the PCI bus number and assumes that it is zero by default), but you
> : surely get the idea.
> : 
> : /{
> :     mainboard_vendor = "Gigabyte";
> :     mainboard_name = "M57SLI";
> :     cpus { };
> :     apic@0 {
> :     };
> :     domain@0 {
> :         pci@0,0 { /* MCP55 RAM? */ 
> :         };
> :         pci@1,0 {
> :             /config/("southbridge/nvidia/mcp55/lpc.dts");
> :             ioport@2e {
>
> <etc>
>
> I'd like to make a couple of comments here.
>
> One, I dislike the DTS syntax.  It is hard to learn to read, and I
> always have to have the manual in my hands to read it.
>
> However, every board that's being produced for powerpc has the DTB at
> least available.  It has to be, or (recent?) Linux kernels flat out
> won't work.  This suggests that it might be a good idea to look at
> this format.
>   

If this is true, I'd consider it to be a misfeature/bug in Linux for
powerpc.

Unless I'm mistaken, Linux is able to probe most hardware properties.
The exceptions on x86 are interrupt routing (at least on most machines)
and memory area designations. Memory configuration can be given as a
command line parameter and with polling enabled on all interrupts, a
kernel should come up fine as well.


> There's DTS and DTB.  One is the source, the other is the binary
> created from the source.  I'd recommend that qemu actually use the DTB
> rather than the DTS to implement things.  This way one could have a
> nicer syntax like the above and generate the DTB, or one could use the
> DTS provided by a vendor if there was a more specific board they
> wanted qemu to emulate.
>
> Carl-Daniel, how does coreboot v3 generate the data that's passed to
> the kernel?
>   

Coreboot v3 does not pass anything derived from the device tree to the
kernel. It simply wouldn't make sense.

Linux and Windows use a few legacy tables and ACPI on x86/x86_64
platforms and if the device tree is any good for firmware purposes, it
won't resemble the ACPI tables at all.

Stuffing info usable for ACPI into the device tree is certainly
possible, but due to topology and content mismatch it's a painful and
pointless exercise.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [RFC] Machine description as data

[Paul Brook]

> Unless I'm mistaken, Linux is able to probe most hardware properties.

You are badly mistaken.

On x86 workstation/server class hardware you might get away with it because 
everything interesting is either  standard legacy ports or PCI, and your 
firmware/bios already took care of the really hairy bits.

On embedded systems there's often very little that can be automatically 
detected, much less functionality provided by the firmware (You're lucky if 
all your RAM is even turned on!) and you just have to know where stuff is.

Paul

Re: [RFC] Machine description as data

[Carl-Daniel Hailfinger]

On 12.02.2009 19:29, Markus Armbruster wrote:
> "M. Warner Losh" <imp@bsdimp.com> writes:
>
>   
>> In message: <49941AE3.1000806@gmx.net>
>> Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> writes:
>> : > I didn't mean to say they are a bad idea for FDTs, just that they're on
>> : > an awkward level of abstraction for QEMU configuration.  There, I'd
>> : > rather express a PCI address as "02:01.0" than as <0x00000220>.
>> : > Translating text to binary is the machine's job, not the user's.
>> : 
>> : Coreboot v3 is using some device tree variant which is IMHO a bit more
>> : user friendly. The tree below is incomplete (for example, it leaves out
>> : the PCI bus number and assumes that it is zero by default), but you
>> : surely get the idea.
>> : 
>> : /{
>> :     mainboard_vendor = "Gigabyte";
>> :     mainboard_name = "M57SLI";
>> :     cpus { };
>> :     apic@0 {
>> :     };
>> :     domain@0 {
>> :         pci@0,0 { /* MCP55 RAM? */ 
>> :         };
>> :         pci@1,0 {
>> :             /config/("southbridge/nvidia/mcp55/lpc.dts");
>> :             ioport@2e {
>>
>> <etc>
>>
>> I'd like to make a couple of comments here.
>>
>> One, I dislike the DTS syntax.  It is hard to learn to read, and I
>> always have to have the manual in my hands to read it.
>>
>> However, every board that's being produced for powerpc has the DTB at
>> least available.  It has to be, or (recent?) Linux kernels flat out
>> won't work.  This suggests that it might be a good idea to look at
>> this format.
>>
>> There's DTS and DTB.  One is the source, the other is the binary
>> created from the source.  I'd recommend that qemu actually use the DTB
>> rather than the DTS to implement things.  This way one could have a
>> nicer syntax like the above and generate the DTB, or one could use the
>> DTS provided by a vendor if there was a more specific board they
>> wanted qemu to emulate.
>>     
>
> As far as I know, dtc can decompile DTB into DTS.
>
> I'm not a fan of DTS syntax either, but if we choose FDT, then inventing
> an alternative syntax seems rather pointless to me.
>   

If the alternative syntax is more readable, why not?

If the DTS text file is compiled into DTB anyway, there's absolutely no
reason to make the text file hard to read for humans. Except maybe
making sure that nobody will ever want to change them, and in that case
we can advise developers to modify the DTB directly.

Compilers for DTS variants do exist. For example, coreboot v3 has one.

> As to reading configuration in a binary format: let's not complicate
> things more than we need.  It's just a decorated tree, folks.
>   

How exactly do you represent a digraph with some cycles as a decorated
tree? The solution should allow people without an extensive background
in IEEE1275 to change the graph as needed.
Having to keep a calculator handy for PCI bus addresses is embarrassing
(and with a calculator, requiring the user to determine the full CF8/CFC
PCI config cycles is not that much more effort ;-) ).


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] [RFC] Machine description as data

[M. Warner Losh]

In message: <4994B22E.6060608-hi6Y0CQ0nG0@public.gmane.org>
            Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006-hi6Y0CQ0nG0@public.gmane.org> writes:
: On 12.02.2009 17:46, M. Warner Losh wrote:
: > <87iqng0x3t.fsf-A7mx1g9ivIOttUaS3K59qNi2O/JbrIOy@public.gmane.org>
: > <49941AE3.1000806-hi6Y0CQ0nG0@public.gmane.org>
: > X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI)
: > Mime-Version: 1.0
: > Content-Type: Text/Plain; charset=us-ascii
: > Content-Transfer-Encoding: 7bit
: >
: > In message: <49941AE3.1000806-hi6Y0CQ0nG0@public.gmane.org>
: > Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006-hi6Y0CQ0nG0@public.gmane.org> writes:
: > : > I didn't mean to say they are a bad idea for FDTs, just that they're on
: > : > an awkward level of abstraction for QEMU configuration.  There, I'd
: > : > rather express a PCI address as "02:01.0" than as <0x00000220>.
: > : > Translating text to binary is the machine's job, not the user's.
: > : 
: > : Coreboot v3 is using some device tree variant which is IMHO a bit more
: > : user friendly. The tree below is incomplete (for example, it leaves out
: > : the PCI bus number and assumes that it is zero by default), but you
: > : surely get the idea.
: > : 
: > : /{
: > :     mainboard_vendor = "Gigabyte";
: > :     mainboard_name = "M57SLI";
: > :     cpus { };
: > :     apic@0 {
: > :     };
: > :     domain@0 {
: > :         pci@0,0 { /* MCP55 RAM? */ 
: > :         };
: > :         pci@1,0 {
: > :             /config/("southbridge/nvidia/mcp55/lpc.dts");
: > :             ioport@2e {
: >
: > <etc>
: >
: > I'd like to make a couple of comments here.
: >
: > One, I dislike the DTS syntax.  It is hard to learn to read, and I
: > always have to have the manual in my hands to read it.
: >
: > However, every board that's being produced for powerpc has the DTB at
: > least available.  It has to be, or (recent?) Linux kernels flat out
: > won't work.  This suggests that it might be a good idea to look at
: > this format.
: >   
: 
: If this is true, I'd consider it to be a misfeature/bug in Linux for
: powerpc.

It is neither.  It is absolutely required.  It can probe things like
usb devices and pci devices, but it is impossible to probe how
interrupts are wired, where devices exist on local busses connected to
the SoC, etc.

The DTS tables can have pci nodes in them, it isn't required.

: Unless I'm mistaken, Linux is able to probe most hardware properties.
: The exceptions on x86 are interrupt routing (at least on most machines)
: and memory area designations. Memory configuration can be given as a
: command line parameter and with polling enabled on all interrupts, a
: kernel should come up fine as well.

s/most/some/.  On powerpc you have a much richer pallet to choose
from, and the knowledge of how things are wired into the dtb blob
that's passed.

: > There's DTS and DTB.  One is the source, the other is the binary
: > created from the source.  I'd recommend that qemu actually use the DTB
: > rather than the DTS to implement things.  This way one could have a
: > nicer syntax like the above and generate the DTB, or one could use the
: > DTS provided by a vendor if there was a more specific board they
: > wanted qemu to emulate.
: >
: > Carl-Daniel, how does coreboot v3 generate the data that's passed to
: > the kernel?
: >   
: 
: Coreboot v3 does not pass anything derived from the device tree to the
: kernel. It simply wouldn't make sense.
: 
: Linux and Windows use a few legacy tables and ACPI on x86/x86_64
: platforms and if the device tree is any good for firmware purposes, it
: won't resemble the ACPI tables at all.
: 
: Stuffing info usable for ACPI into the device tree is certainly
: possible, but due to topology and content mismatch it's a painful and
: pointless exercise.

That's likely true...

Warner

Re: [Qemu-devel] [RFC] Machine description as data

[Carl-Daniel Hailfinger]

On 13.02.2009 00:58, Paul Brook wrote:
>> Unless I'm mistaken, Linux is able to probe most hardware properties.
>>     
>
> You are badly mistaken.
>   

Point taken.


> On x86 workstation/server class hardware you might get away with it because 
> everything interesting is either  standard legacy ports or PCI, and your 
> firmware/bios already took care of the really hairy bits.
>   

If the firmware doesn't set up the things which can't be probed, can it
even be called firmware or is it more like a glorified bootloader?


> On embedded systems there's often very little that can be automatically 
> detected, much less functionality provided by the firmware (You're lucky if 
> all your RAM is even turned on!) and you just have to know where stuff is.
>   

Ouch. I always thought turning on all the RAM was either a hardware (old
x86) or firmware (modern x86) task.

I'm a bit surprised by the lack of automatically detectable features in
embedded systems. Wouldn't automatic detection allow reusing whole OS
images on slighly different systems and thus lower development cost?


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Thu, Feb 12, 2009 at 11:26:12AM +0100, Markus Armbruster wrote:
> Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
[snip]
> > I won't say IEEE1275 is perfect, but IMHO it would be pretty silly to
> > reinvent all the design and infrastructure for a similar-but-different
> > device tree.
> >
> > [Patch snipped]
> 
> I'm not at all opposed to adapting FDT for QEMU use.  My patch is a
> prototype, and I'm prepared to throw away some or all of it.
> 
> To get this thing started, I wanted working code to demonstrate what I'm
> talking about.  If I had dug deeper into FDTs first, we would not be
> talking now.
> 
> The task I outlined in my memo involves much more than just coming up
> with a device tree data structure.  That data structure is to me one
> detail among many, and a much less hairy one than most others.  It
> certainly was for the prototype.
> 
> If I read the comments correctly (all comments, not just this one), the
> only real issue with my proposal is you'd rather use FDT for the config
> tree.  I don't mind, except I don't know enough about that stuff to do
> it all by myself, at least not in a reasonable time frame.  I think I
> understand the concepts, can read .dts files with some head-scratching,
> and I could perhaps even write one if I sacrificed a chicken or two.
> Designing a binding, however, feels well above my level of
> (in)competence.
> 
> So, to make FDT happen, I need help.  Specifically:
> 
> * Point me to the FDT code I'm supposed to integrate.  I'm looking for
>   basic decorated tree stuff: create trees, traverse them, get and put
>   properties, add and delete nodes, read and write them as plain,
>   human-readable text.

dtc and libfdt is a good place to start, if you haven't yet
investigated them:
	git://git.jdl.com/software/dtc.git
Note that although they're distributed together as one tree, dtc and
libfdt are essentially independent pieces of software.  dtc converts
device trees between various formats, dts and dtb in particular.

libfdt does a number of the things you mention with flat trees -
get/set properties, build trees, traverse etc.  If it doesn't do
everything you need, we can probably extend it so that it does: I want
libfdt to be *the* library for manipulating trees in the fdt forma.
It's designed to be easy to embed in other packages for this reason,
although it does have some usage peculiarities because in particular
it's possible to integrate into very limited environments like
firmwares.

[Jon Loeliger is the current maintainer of dtc and libfdt, but I
originally wrote both of them - I know as much about them as anyone
does]

> * Provide an example tree describing a bare-bones PC, like the one in my
>   prototype: CPU, RAM, BIOS, PIC, APIC, IOAPIC, PIT, DMA, UART, parallel
>   port, floppy controller, CMOS & RTC, a20 gate (port 92) and other
>   miscellanous I/O ports, i440fx, PIIX3 (ISA bridge, IDE, USB, ACPI),
>   Cirrus VGA with BIOS, some PCI NIC.  This gives us all an idea of the
>   tree structure.  Morphing that into something suitable for QEMU
>   configuration shouldn't be too hard then, just an exercice in
>   redecorating the tree.

I don't off hand know any trees for a PC system.  There are a bunch of
example trees for powerpc systems in arch/powerpc/boot/dts in the
kernel tree.  A few of those, such as prep, at least have parts which
somewhat resemble a PC.  I believe the OLPC also has OF; that would be
an example OF tree for an x86 machine, if not a typical PC.

> * Advice as we go.

I'll do what I can.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
> David Gibson <dwg-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org> writes:
> 
> > On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
> >> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
> > [snip]
> >> > I briefly examined the DT source format and the tree structure it
> >> > describes for the purpose of QEMU configuration.  I decided against
> >> > using it in my prototype because I found it awfully low-level and
> >> > verbose for that purpose (I'm sure it serves the purpose it was designed
> >> > for just fine).  Issues include:
> >> > 
> >> > * Since the DT is designed for booting kernels, not configuring QEMU,
> >> >   there's information that has no place in QEMU configuration, and
> >> >   required QEMU configuration isn't there.
> >> 
> >> What's needed is a "binding" in IEEE1275-speak: a document that
> >> describes qemu-specific nodes/properties and how they are to be
> >> interpreted.
> >> 
> >> As an example, you could require that block devices contain properties
> >> named "qemu,path", "qemu,backend", etc.
> >
> > Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
> > extra information for qemu's use.
> 
> I don't feel up to that task, because I'm not really familiar with
> IEEE1275.  Could you help out?

Uh.. up to some level at least.

> >                                    As for the other direction, in some
> > cases it may be appropriate for qemu's device tree code to fill in
> > missing device tree properties, based on what the device emulation
> > code knows about itself.
> 
> Agreed.  Configuration should only contain what is actually
> configurable.  Anything else that is needed by a consumer of the tree
> should be filled in automatically.

Right.  I guess it will depend exactly what the balance is between
configuration and generated information whether we want to use a dts
with annontations in extra properties or a different tree format as
the root source format.  Either way I think we want to use the fdt
format as the format that qemu and the guest firmware work with.

> >> > * Redundancy between node name and its device_type property.
> >
> > Note that "device_type" may not mean what you think.  It describes
> > what methods the device support within the OF client interface.  New
> > device trees that aren't linked to a full OF implementation with
> > client interface should generally omit device_type in most places
> > (there are a few special cases for compatibility with OSes that expect
> > device_type properties in certain places).
> 
> I guess the ignorance I mentioned shows ;)

Heh, well, device_type is very commonly misunderstood for good
reason.  It made sense in the original OF context, but in the context
of flat trees, the name is very misleading.

> >> > * Property "reg", which encodes address ranges, does so in terms of
> >> >   "cells": #address-cells 32-bit words (big endian) for the address,
> >> >   followed by #size-cells words for the size, where #address-cells and
> >> >   #size-cells are properties of the enclosing bus.  If this sounds
> >> >   like gibberish to you, well, that's my point.
> >
> > #address-cells and #size-cells takes a little getting used to, but
> > it's really not that bad.  It's just a way of representing the fact
> > that different busses have different sized address encodings.
> 
> I didn't mean to say they are a bad idea for FDTs, just that they're on
> an awkward level of abstraction for QEMU configuration.  There, I'd
> rather express a PCI address as "02:01.0" than as <0x00000220>.
> Translating text to binary is the machine's job, not the user's.

Ah, I see what you mean.  Hrm, there are several possibilities here,
we'll have to see which works out best for your purposes.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [RFC] Machine description as data

[Jamie Lokier]

Carl-Daniel Hailfinger wrote:
> I'm a bit surprised by the lack of automatically detectable features in
> embedded systems. Wouldn't automatic detection allow reusing whole OS
> images on slighly different systems and thus lower development cost?

Where systems are slightly different, what often happens is the boot
firmware (boot loader, whatever you want to call it) has different
parameters patched in.  They might be compiled in differently or
different values in a small config block.

That only applies to different versions of the same product though.
Among embedded systems generally there are huge differences between
them.

In the OS image, you often have only drivers for devices on the board,
to keep the OS as small as possible, so it's customised for each board
anyway, except being shared between minor revisions.  There are often
a few custom devices and kernel patches too.

-- Jamie

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Thu, Feb 12, 2009 at 09:33:59AM -1000, Mitch Bradley wrote:
>>
>> We want a machine configuration: a tree describing configurable devices
>> and their configurable properties.
>
> Regarding configurable devices in Open Firmware:
>
> The baseline usage model for configurable devices was that the firmware  
> is responsible for establishing a consistent system configuration,  
> possibly based on user-modifiable variables in non-volatile storage.  It  
> reports the actual configuration to the OS via the device tree.
>
> For cases where the choice needs to deferred until later, or perhaps  
> changed dynamically, a device tree property reports the set of  
> possibilities.  In cases where the firmware has already set up the  
> devices, it reports the current choice via another property.
>
> The device tree hierarchy serves as the "name space" framework for these  
> properties.  Obviously, you need to specify the device for which the  
> choice set applies.  The device tree is a coherent naming model for that  
> purpose.
>
> Obviously the hierarchical model has problems for highly-configurable  
> chipsets in which a setting can result in a wholesale rearrangement of  
> the overall connectivity, but it seems to me that board-design  
> constraints usually make that a non-problem. The wiring on a given board  
> generally forces the choice at that level, so the firmware for that  
> board need not report that as a configurable choice.
>> For PowerPC, we also want a machine description: a tree describing those
>> devices and properties that the kernel can't easily and safely probe.
>
> The gist of the above sentence seems to presuppose that, if the kernel  
> can probe, it should.  That's not the only way of thinking about the  
> problem.  As a practical matter, the firmware usually needs to do a fair  
> amount of probing too, in order to locate the console display and the  
> boot devices.  In the process, the firmware usually discovers pretty  
> much the entire machine configuration.  If the OS has to repeat the  
> process from scratch, it slows down the boot process.  So the IEEE1275  
> design supports the model where the firmware can do all the probing,  
> handing off a complete system description to the OS.  The OS startup  
> code can walk the tree and attach device drivers for what it finds, then  
> arrange to handle insert/remove events from hot-pluggable buses.

In the context of a full IEEE1275 implementation that makes sense.
However, in the context of flat trees - which were designed with
embedded machines in mind particularly - cutting down the device tree
to only things which the kernel can't probe is normal practice.  In
this context firmware is often really minimal and doesn't actually
need to probe much.  Basic IO devices like console are often on chip
and easily accessible so in particular the firmware has no need to
probe complex bus structures like PCI.

But more importantly, this is a design decision driven by the
prevalence of buggy-as-hell firmwares.  There are many instances where
to work around broken firmware probing, the kernel has to do almost as
much work as probing from scratch (and the code to do it is generally
more confusing).  And while it might be nice to imagine a world with
good firmware supporting standard interfaces, I really can't see it
ever happening.

So, we've taken the approach of moving as much as possible of the
probing and device-discovery logic into the kernel which is usually a
more easily replacable / fixable component of the system.  The less
the firmware has to put into the tree, the less it can get wrong.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Thu, Feb 12, 2009 at 11:52:42AM -0600, Hollis Blanchard wrote:
> On Thu, 2009-02-12 at 11:26 +0100, Markus Armbruster wrote:
> >  David Gibson <dwg-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org> writes:
> > 
> > > On Wed, Feb 11, 2009 at 12:50:28PM -0600, Hollis Blanchard wrote:
> > >> On Wed, 2009-02-11 at 16:40 +0100, Markus Armbruster wrote:
> > > [snip]
> > >> > I briefly examined the DT source format and the tree structure it
> > >> > describes for the purpose of QEMU configuration.  I decided
> > against
> > >> > using it in my prototype because I found it awfully low-level and
> > >> > verbose for that purpose (I'm sure it serves the purpose it was
> > designed
> > >> > for just fine).  Issues include:
> > >> > 
> > >> > * Since the DT is designed for booting kernels, not configuring
> > QEMU,
> > >> >   there's information that has no place in QEMU configuration,
> > and
> > >> >   required QEMU configuration isn't there.
> > >> 
> > >> What's needed is a "binding" in IEEE1275-speak: a document that
> > >> describes qemu-specific nodes/properties and how they are to be
> > >> interpreted.
> > >> 
> > >> As an example, you could require that block devices contain
> > properties
> > >> named "qemu,path", "qemu,backend", etc.
> > >
> > > Yes, it shouldn't be hard to annotate an IEEE1275 style tree with
> > > extra information for qemu's use.
> > 
> > I don't feel up to that task, because I'm not really familiar with
> > IEEE1275.  Could you help out?
> 
> I'm not really a "language lawyer" for device trees, but I can help.
> 
> FWIW, I was imagining (from a PowerPC point of view) that a strict
> subset of the device tree interpreted by qemu would be passed into the
> guest. In other words, once qemu is done with it, it would strip every
> property prefixed with "qemu," and copy the result into guest memory.
> PowerPC kernels require this data structure, and even when firmware runs
> in the guest, you still need to tell the firmware what the system layout
> is, and the device tree is an obvious candidate...

I wouldn't actually bother stripping the "qemu,..." properties.  They
should be ignored by the OS anyway.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Thu, Feb 12, 2009 at 07:29:12PM +0100, Markus Armbruster wrote:
> "M. Warner Losh" <imp-uzTCJ5RojNnQT0dZR+AlfA@public.gmane.org> writes:
[snip]
> > However, every board that's being produced for powerpc has the DTB at
> > least available.  It has to be, or (recent?) Linux kernels flat out
> > won't work.  This suggests that it might be a good idea to look at
> > this format.
> >
> > There's DTS and DTB.  One is the source, the other is the binary
> > created from the source.  I'd recommend that qemu actually use the DTB
> > rather than the DTS to implement things.  This way one could have a
> > nicer syntax like the above and generate the DTB, or one could use the
> > DTS provided by a vendor if there was a more specific board they
> > wanted qemu to emulate.
> 
> As far as I know, dtc can decompile DTB into DTS.

That's correct.  However, like many decompilation processes,
converting dts->dtb->dts is usually a lossy process to some extent.
dts has multiple ways to represent some things for readability
reasons, which don't affect the content of the compiled tree.

> I'm not a fan of DTS syntax either, but if we choose FDT, then inventing
> an alternative syntax seems rather pointless to me.

If you have suggestions for improving dts that don't involve
completely breaking compatibility with existing trees, we might be
able to incorporate them into dtc to make everyone's life easier.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Fri, Feb 13, 2009 at 01:32:19AM +0100, Carl-Daniel Hailfinger wrote:
> On 13.02.2009 00:58, Paul Brook wrote:
> >> Unless I'm mistaken, Linux is able to probe most hardware properties.
> >
> > You are badly mistaken.
> 
> Point taken.
> 
> 
> > On x86 workstation/server class hardware you might get away with it because 
> > everything interesting is either  standard legacy ports or PCI, and your 
> > firmware/bios already took care of the really hairy bits.
> 
> If the firmware doesn't set up the things which can't be probed, can it
> even be called firmware or is it more like a glorified bootloader?

A bootloader, not even much glorified, is often all there is on
embedded systems.

> > On embedded systems there's often very little that can be automatically 
> > detected, much less functionality provided by the firmware (You're lucky if 
> > all your RAM is even turned on!) and you just have to know where stuff is.
> 
> Ouch. I always thought turning on all the RAM was either a hardware (old
> x86) or firmware (modern x86) task.
> 
> I'm a bit surprised by the lack of automatically detectable features in
> embedded systems. Wouldn't automatic detection allow reusing whole OS
> images on slighly different systems and thus lower development cost?

Automatic detection requires protocols between hardware, firmware and
OS to implement it.  The ones that exist for full systems are too
heavyweight for embedded systems, or assume things about the hardware
setup that don't suit what embedded systems want to include.
Typically it's just been easier for embedded vendors to hack their
kernels to know the hardware directly.

The tradeoffs we've made for use of flattened device trees represent
an effort to achieve lower development cost precisely as you describe
here.  Inherently probably hardware (e.g. PCI, USB) is mostly omitted
from the tree, leaving a minimal blob of almost static information
which the firmware/bootloader can include to tell the OS about the
hardware setup while still having almost no "moving parts".

The kernel can still neatly support systems which don't provide a
flattened tree by being built with a wrapper.  The wrapper, which is
specific to a particular hardware/firmware combination contains a
flattened tree, plus some code to tweak it with what little
information the embedded firmware / hardware does provide (ram size
and flash size are common examples).

This way we have a kernel which can run unmodified on many systems
which do provide a flattened tree, and we're no worse off for systems
which don't (a hardware specific kernel is replaced by a hardware
specific kernel+wrapper combination).

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[Carl-Daniel Hailfinger]

On 13.02.2009 01:43, David Gibson wrote:
> On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
>   
>> I didn't mean to say they are a bad idea for FDTs, just that they're on
>> an awkward level of abstraction for QEMU configuration.  There, I'd
>> rather express a PCI address as "02:01.0" than as <0x00000220>.
>> Translating text to binary is the machine's job, not the user's.
>>     
>
> Ah, I see what you mean.  Hrm, there are several possibilities here,
> we'll have to see which works out best for your purposes.
>   

Using the DTC version included in the coreboot v3 sources would solve
that problem and give you a readable PCI address representation.

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Fri, Feb 13, 2009 at 03:11:20AM +0100, Carl-Daniel Hailfinger wrote:
> On 13.02.2009 01:43, David Gibson wrote:
> > On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
> >   
> >> I didn't mean to say they are a bad idea for FDTs, just that they're on
> >> an awkward level of abstraction for QEMU configuration.  There, I'd
> >> rather express a PCI address as "02:01.0" than as <0x00000220>.
> >> Translating text to binary is the machine's job, not the user's.
> >>     
> >
> > Ah, I see what you mean.  Hrm, there are several possibilities here,
> > we'll have to see which works out best for your purposes.
> 
> Using the DTC version included in the coreboot v3 sources would solve
> that problem and give you a readable PCI address representation.

Hrm.. it would be nice if you'd co-ordinated with Jon and I about
this.  Then we could have at least the bits which make sense in
upstream dtc...

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

DTS syntax and DTC patches (was: Re: [Qemu-devel] [RFC] Machine description as data)

[Carl-Daniel Hailfinger]

[Adding the coreboot mailing list to CC. It's moderated for
non-subscribers, but it won't take long for legitimate mails to be
approved.]

On 13.02.2009 03:17, David Gibson wrote:
> On Fri, Feb 13, 2009 at 03:11:20AM +0100, Carl-Daniel Hailfinger wrote:
>   
>> On 13.02.2009 01:43, David Gibson wrote:
>>     
>>> On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
>>>   
>>>       
>>>> I didn't mean to say they are a bad idea for FDTs, just that they're on
>>>> an awkward level of abstraction for QEMU configuration.  There, I'd
>>>> rather express a PCI address as "02:01.0" than as <0x00000220>.
>>>> Translating text to binary is the machine's job, not the user's.
>>>>     
>>>>         
>>> Ah, I see what you mean.  Hrm, there are several possibilities here,
>>> we'll have to see which works out best for your purposes.
>>>       
>> Using the DTC version included in the coreboot v3 sources would solve
>> that problem and give you a readable PCI address representation.
>>     
>
> Hrm.. it would be nice if you'd co-ordinated with Jon and I about
> this.  Then we could have at least the bits which make sense in
> upstream dtc...
>   

Probably the biggest obstacle for a full merge right now is that the
coreboot v3 DTC is rather old and has been extended not only for a more
readable DTS syntax variant, but also for additional output modes (C
header and C code).

We (coreboot developers) are interested in reducing our diff with
upstream DTC in order to improve maintainability of our DTC code.


Regards,
Carl-Daniel

Re: DTS syntax and DTC patches (was: Re: [Qemu-devel] [RFC] Machine description as data)

[David Gibson]

On Fri, Feb 13, 2009 at 03:45:45AM +0100, Carl-Daniel Hailfinger wrote:
> [Adding the coreboot mailing list to CC. It's moderated for
> non-subscribers, but it won't take long for legitimate mails to be
> approved.]
> 
> On 13.02.2009 03:17, David Gibson wrote:
> > On Fri, Feb 13, 2009 at 03:11:20AM +0100, Carl-Daniel Hailfinger wrote:
> >   
> >> On 13.02.2009 01:43, David Gibson wrote:
> >>     
> >>> On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
> >>>   
> >>>       
> >>>> I didn't mean to say they are a bad idea for FDTs, just that they're on
> >>>> an awkward level of abstraction for QEMU configuration.  There, I'd
> >>>> rather express a PCI address as "02:01.0" than as <0x00000220>.
> >>>> Translating text to binary is the machine's job, not the user's.
> >>>>     
> >>>>         
> >>> Ah, I see what you mean.  Hrm, there are several possibilities here,
> >>> we'll have to see which works out best for your purposes.
> >>>       
> >> Using the DTC version included in the coreboot v3 sources would solve
> >> that problem and give you a readable PCI address representation.
> >>     
> >
> > Hrm.. it would be nice if you'd co-ordinated with Jon and I about
> > this.  Then we could have at least the bits which make sense in
> > upstream dtc...
> >   
> 
> Probably the biggest obstacle for a full merge right now is that the
> coreboot v3 DTC is rather old and has been extended not only for a more
> readable DTS syntax variant, but also for additional output modes (C
> header and C code).

If the C output mode is what I'm guessing, it should be pretty easy to
add (we already have an asm output mode upstream).

The syntax changes will be trickier.  I want to review any new syntax
for dts very carefully, because I really, really don't want to have to
break backwards compatibility in future (I'm unhappy enough about the
dts-v0 to dts-v1 transition we've already have).

Can you summarise what the syntax changes are?  Maybe start a new
thread with just devicetree-discuss not the other lists for that.

> We (coreboot developers) are interested in reducing our diff with
> upstream DTC in order to improve maintainability of our DTC code.

Good :)

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006-hi6Y0CQ0nG0@public.gmane.org> writes:

> How exactly do you represent a digraph with some cycles as a decorated
> tree? The solution should allow people without an extensive background
> in IEEE1275 to change the graph as needed.

Okay, calling it just a decorated tree is not 100% accurate.  It's a
decorated tree where a certain kind of decoration can refer to another
node.  These additional edges actually make it a directed graph.  But we
still have a tree embedded in that graph, which is useful when we
convert it to or from text.

[...]

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:

> On Thu, Feb 12, 2009 at 11:26:12AM +0100, Markus Armbruster wrote:
>> Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> [snip]
>> > I won't say IEEE1275 is perfect, but IMHO it would be pretty silly to
>> > reinvent all the design and infrastructure for a similar-but-different
>> > device tree.
>> >
>> > [Patch snipped]
>> 
>> I'm not at all opposed to adapting FDT for QEMU use.  My patch is a
>> prototype, and I'm prepared to throw away some or all of it.
>> 
>> To get this thing started, I wanted working code to demonstrate what I'm
>> talking about.  If I had dug deeper into FDTs first, we would not be
>> talking now.
>> 
>> The task I outlined in my memo involves much more than just coming up
>> with a device tree data structure.  That data structure is to me one
>> detail among many, and a much less hairy one than most others.  It
>> certainly was for the prototype.
>> 
>> If I read the comments correctly (all comments, not just this one), the
>> only real issue with my proposal is you'd rather use FDT for the config
>> tree.  I don't mind, except I don't know enough about that stuff to do
>> it all by myself, at least not in a reasonable time frame.  I think I
>> understand the concepts, can read .dts files with some head-scratching,
>> and I could perhaps even write one if I sacrificed a chicken or two.
>> Designing a binding, however, feels well above my level of
>> (in)competence.
>> 
>> So, to make FDT happen, I need help.  Specifically:
>> 
>> * Point me to the FDT code I'm supposed to integrate.  I'm looking for
>>   basic decorated tree stuff: create trees, traverse them, get and put
>>   properties, add and delete nodes, read and write them as plain,
>>   human-readable text.
>
> dtc and libfdt is a good place to start, if you haven't yet
> investigated them:
> 	git://git.jdl.com/software/dtc.git
> Note that although they're distributed together as one tree, dtc and
> libfdt are essentially independent pieces of software.  dtc converts
> device trees between various formats, dts and dtb in particular.
>
> libfdt does a number of the things you mention with flat trees -
> get/set properties, build trees, traverse etc.  If it doesn't do
> everything you need, we can probably extend it so that it does: I want
> libfdt to be *the* library for manipulating trees in the fdt forma.
> It's designed to be easy to embed in other packages for this reason,
> although it does have some usage peculiarities because in particular
> it's possible to integrate into very limited environments like
> firmwares.
>
> [Jon Loeliger is the current maintainer of dtc and libfdt, but I
> originally wrote both of them - I know as much about them as anyone
> does]

Okay, I looked at dtc and libfdt again, a bit more closely.  I'm sure
there's plenty of ignorance left in me, so please correct me when I'm
babbling nonsense.

FDT is a "flattened tree", i.e. a tree data structure laid out in a
block of memory in a clever way to make it compact and easily
relocatable.  I understand why these are important requirements for
passing information through bootloader to kernel.  They're irrelevant,
however, for use as QEMU configuration.

You can identify an FDT node by node offset or node name.  The node
offset can change when you add or delete nodes or properties.

You want everyone to use libfdt for manipulating FDTs.  I think that's
entirely sensible.  What I still don't get is something else: Why use
FDT for QEMU configuration in the first place?  Let me explain.

I think we have two distinct problems: the need for a flexible,
expressive QEMU machine configuration file and a virtual device
configuration machinery driven by it, and the need for an FDT to pass to
a PowerPC kernel.  The two may be related, but they are not identical.

Let's pretend for a minute the latter need doesn't exist.

QEMU machine configuration wants to be a decorated tree: a tree of named
nodes with named properties.

IEEE 1275 is a standard describing a special kind of decorated tree.
Other kinds can be created with a binding.  If we create a suitable
binding, we can surely cast our configuration trees in the IEEE 1275
framework.

But what would that buy us?  This is a honest question, born out of my
relative ignorance of IEEE 1275.  Mind that we're still busily ignoring
the need for an FDT to pass to a kernel, so "it makes it easier to
create an FDT for the kernel" doesn't count here (it counts elsewhere).

FDTs are a special representation of IEEE 1275 trees in memory, designed
to be compact and relocatable.  But that comes at a price: nodes move
around when the tree changes.  The only real node id is the full name.

This is not the common representation of decorated trees in C programs,
and for a reason.  It's simpler to represent edges as C pointers.  Not
the least advantage of that is notation: "->" beats a function call in
legibility hands down.

Example: the QEMU device data type needs to refer to its device node in
the configuration tree.  If that tree is coded the plain old way, you
store a pointer to the node and follow that.  If it is an FDT, then you
have to store the full node name, and look up the node by name.  I find
that tedious and verbose.

My point is: the question how to represent our decorated tree in memory
is entirely separate from the question of the tree's structure.  Just
because you want your tree to conform to IEEE 1275 doesn't mean you want
your tree flat at all times.

Now let's examine how QEMU machine configuration and FDT machine
descriptions for kernels are related.

In a way, both can be regarded as copies of a complete machine
description with lots of stuff pruned.  Except the complete machine
description doesn't exist.  Because there is no use for it.

FDT routinely prunes stuff like PCI and USB devices, because those are
better probed.

QEMU configuration should certainly prune everything that is not
actually configurable.

To go from QEMU configuration to FDT we therefore may want to prune
superflous stuff, to keep it compact, and we definitely have to add lots
of stuff that has no place in configuration.  Compared to that task, a
change of representation seems trivial.  I figure we want to copy the
tree anyway, because we need to edit it pretty drastically.

It's not obvious to me whether it makes sense to create the FDT from the
QEMU configuration automatically.  If we simulate a specific board, the
FDT is pretty fixed, isn't it?  Much of the configurable stuff could be
precisely in those parts that are omitted from FDT: PCI devices and
such.

>> * Provide an example tree describing a bare-bones PC, like the one in my
>>   prototype: CPU, RAM, BIOS, PIC, APIC, IOAPIC, PIT, DMA, UART, parallel
>>   port, floppy controller, CMOS & RTC, a20 gate (port 92) and other
>>   miscellanous I/O ports, i440fx, PIIX3 (ISA bridge, IDE, USB, ACPI),
>>   Cirrus VGA with BIOS, some PCI NIC.  This gives us all an idea of the
>>   tree structure.  Morphing that into something suitable for QEMU
>>   configuration shouldn't be too hard then, just an exercice in
>>   redecorating the tree.
>
> I don't off hand know any trees for a PC system.  There are a bunch of
> example trees for powerpc systems in arch/powerpc/boot/dts in the
> kernel tree.  A few of those, such as prep, at least have parts which
> somewhat resemble a PC.  I believe the OLPC also has OF; that would be
> an example OF tree for an x86 machine, if not a typical PC.

Could you point me to a specific file?  I grepped for prep and OLPC, no
luck.

>> * Advice as we go.
>
> I'll do what I can.

Thanks in advance!

Re: [Qemu-devel] [RFC] Machine description as data

[Paul Brook]

> Now let's examine how QEMU machine configuration and FDT machine
> descriptions for kernels are related.
>
> In a way, both can be regarded as copies of a complete machine
> description with lots of stuff pruned.  Except the complete machine
> description doesn't exist.  Because there is no use for it.
>
> FDT routinely prunes stuff like PCI and USB devices, because those are
> better probed.
>
> QEMU configuration should certainly prune everything that is not
> actually configurable.

I'm not sure I agree here, or at least we may be talking past each other.

IMHO the machine config should specify all the bits of the machine that don't 
really want to be exposed to the average user. e.g. the memory layout and 
interrupt routings, etc. We then have a seaparate user config file (possibly 
structured differently) which exposes things like host bindings for disks and 
network devices.

It's all a bit muddy because the current commandline options effect both the 
devices present and the host bindings for the corresponding interfaces. While 
this seems like a good idea to start with, I'm not convinced this is actually 
a desirable feature.  Certainly for embedded machines you want a fixed set of 
hardware. e.g. if we have a SoC with 3 UARTs we should always create those 3 
devices, and it's not meaningful to have more. If the user doesn't specify 
sufficient -serial options then the remainder just get connected 
to /dev/null. Likewise there's a good argument for having the vlan and disc 
configuration be separate from creation of the NIC/HBA devices.

One possibility is that it might actually make more sense to specify 
hot-pluggable devices (e.g. PCI and USB) in a sumilar way that they would be 
added at runtime, rather than trying to force them into a static tree.

My implementation focsed on just the machine config, mostly ignoring the user 
config and host bindings.

Paul

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> writes:

>> Now let's examine how QEMU machine configuration and FDT machine
>> descriptions for kernels are related.
>>
>> In a way, both can be regarded as copies of a complete machine
>> description with lots of stuff pruned.  Except the complete machine
>> description doesn't exist.  Because there is no use for it.
>>
>> FDT routinely prunes stuff like PCI and USB devices, because those are
>> better probed.
>>
>> QEMU configuration should certainly prune everything that is not
>> actually configurable.
>
> I'm not sure I agree here, or at least we may be talking past each other.

That could be my fault; I guess I didn't express myself clearly.  What
"configurable" means depends on your point of view.

One point of view is assembling pieces of QEMU functionality into a
virtual machine type.  You call that "machine config" below.

Another point of view is configuring a specific virtual machine, based
on a virtual machine type.  I think you call that "user config" below.

In my view, we start with static machine configuration, which we then
modify according to the user's wishes.  The result then drives the
construction of the virtual machine.

My prototype has the static machine configuration compiled in, but I
think it belongs in a config file.

A config file would also be convenient for users.  I guess we'll also
want to support existing command line options, at least for some time.

I'm arguing that both the static machine configuration and the final
configuration (after user config is edited in) lack stuff that needs to
be put into the FDT for the kernel.

Hypothetical example: say the kernel needs to know exactly how the
interrupts are wired.  But QEMU can wire the interrupts just one way,
the way it has always wired them.  What's the point in putting that way
into the machine configuration?  Verifying that whatever is there
matches reality is no less work than generating the information from
scratch, isn't it?

> IMHO the machine config should specify all the bits of the machine that don't 
> really want to be exposed to the average user. e.g. the memory layout and 
> interrupt routings, etc. We then have a seaparate user config file (possibly 
> structured differently) which exposes things like host bindings for disks and 
> network devices.
>
> It's all a bit muddy because the current commandline options effect both the 
> devices present and the host bindings for the corresponding interfaces. While 
> this seems like a good idea to start with, I'm not convinced this is actually 
> a desirable feature.  Certainly for embedded machines you want a fixed set of 
> hardware. e.g. if we have a SoC with 3 UARTs we should always create those 3 
> devices, and it's not meaningful to have more. If the user doesn't specify 
> sufficient -serial options then the remainder just get connected 
> to /dev/null. Likewise there's a good argument for having the vlan and disc 
> configuration be separate from creation of the NIC/HBA devices.
>
> One possibility is that it might actually make more sense to specify 
> hot-pluggable devices (e.g. PCI and USB) in a sumilar way that they would be 
> added at runtime, rather than trying to force them into a static tree.
>
> My implementation focsed on just the machine config, mostly ignoring the user 
> config and host bindings.
>
> Paul

I'm still reading your code.  It would help if you could provide a
Makefile patch that let me actually build it.

My initial impression is that we both approached the problem from
different directions, yet converged on fairly similar solutions.  Each
of us covers stuff the other glossed over.  More later.

Re: [Qemu-devel] [RFC] Machine description as data

[Paul Brook]

> Hypothetical example: say the kernel needs to know exactly how the
> interrupts are wired.  But QEMU can wire the interrupts just one way,
> the way it has always wired them.  What's the point in putting that way
> into the machine configuration?  Verifying that whatever is there
> matches reality is no less work than generating the information from
> scratch, isn't it?

Much of the reason for having a machine config is that it allows control over 
things like interrupt routing. Particularly for embedded machines, it's 
common to have a variety of different machines all using the same components, 
but varying in how those components are connected. For example the ARM 
Integrator, Versatile, Realview and Luminary Stellaris boards are all based 
on approximately the same basic set of devices (the ARM PrimeCell SoC 
peripherals), just with different memory maps and interrupt topologies. I 
suspect the same is true for many of the PPC, SH4 and ColdFire boards, and 
probably the different SPARC sun4m/sun4u variants.

Most of the intrastructure to do modular machine construction is already there 
in qemu, it's just currently driven by hardcoded C QEMUMachineInitFunc rather 
than a runtime config.

I guess that's where I see the distinction. Roughly speaking the "machine 
config" replaces pc.c:pc_init1, and the "user config" replaces a lot of the 
goo in vl.c:main, drive_init, etc.

Paul

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> writes:

>> Hypothetical example: say the kernel needs to know exactly how the
>> interrupts are wired.  But QEMU can wire the interrupts just one way,
>> the way it has always wired them.  What's the point in putting that way
>> into the machine configuration?  Verifying that whatever is there
>> matches reality is no less work than generating the information from
>> scratch, isn't it?
>
> Much of the reason for having a machine config is that it allows control over 
> things like interrupt routing. Particularly for embedded machines, it's 
> common to have a variety of different machines all using the same components, 
> but varying in how those components are connected. For example the ARM 
> Integrator, Versatile, Realview and Luminary Stellaris boards are all based 
> on approximately the same basic set of devices (the ARM PrimeCell SoC 
> peripherals), just with different memory maps and interrupt topologies. I 
> suspect the same is true for many of the PPC, SH4 and ColdFire boards, and 
> probably the different SPARC sun4m/sun4u variants.

We make stuff configurable in QEMU when we need it more than one way.
While the kernel wants to see configuration when it could conceivably
exist in more than one way.

> Most of the intrastructure to do modular machine construction is already there 
> in qemu, it's just currently driven by hardcoded C QEMUMachineInitFunc rather 
> than a runtime config.
>
> I guess that's where I see the distinction. Roughly speaking the "machine 
> config" replaces pc.c:pc_init1, and the "user config" replaces a lot of the 
> goo in vl.c:main, drive_init, etc.
>
> Paul

Not that I disagree with that.

Look, my goals are rather modest.  I want to start where we are, put
devices behind a nice abstract interface one by one, picking apart the
pc.c hairball on the way.  The idea is not to design the perfect,
all-encompassing abstract device interface, just to capture what we
need, and extend as we go.  The abstract device interface makes a simple
machine builder possible, driven by tree-structured configuration.  That
in turn makes it easier to make things configurable.  Which can be
expected to lead to more configurability, when and where there's a need
for it.

All this can be done in nice, safe baby steps.  I don't need to come up
with an all-singing machine description fit for a picky kernel before I
can start doing something useful.

Now, if you hand me such a configuration on a platter, I'd be a fool not
to take it.  The catch: I need one for a PC.

I believe there's significant overlap in what we two want to accomplish.
We just come from different directions, with somewhat differing
priorities.

Re: [Qemu-devel] [RFC] Machine description as data

[Paul Brook]

> Look, my goals are rather modest.  I want to start where we are, put
> devices behind a nice abstract interface one by one, picking apart the
> pc.c hairball on the way.  The idea is not to design the perfect,
> all-encompassing abstract device interface, just to capture what we
> need, and extend as we go.  The abstract device interface makes a simple
> machine builder possible, driven by tree-structured configuration.  That
> in turn makes it easier to make things configurable.  Which can be
> expected to lead to more configurability, when and where there's a need
> for it.
>
> All this can be done in nice, safe baby steps.  I don't need to come up
> with an all-singing machine description fit for a picky kernel before I
> can start doing something useful.
>
> Now, if you hand me such a configuration on a platter, I'd be a fool not
> to take it.  The catch: I need one for a PC.

I suspect these two goals may be contradictory. The PC machine is so hairy 
that you need a singing, dancing machine description to be able to describe 
it.

OTOH if what you really want to do is configure the host binding side of 
things, then as I've mentioned before, I see that as been somewhat separate 
from the actual machine creation, and trying to combine the two is probably a 
mistake. I really don't want users to have to hack the machine config just to 
change the name of an image file.

Paul

Re: [RFC] Machine description as data

[Lennart Sorensen]

On Fri, Feb 13, 2009 at 01:32:19AM +0100, Carl-Daniel Hailfinger wrote:
> Point taken.
> 
> If the firmware doesn't set up the things which can't be probed, can it
> even be called firmware or is it more like a glorified bootloader?
> 
> Ouch. I always thought turning on all the RAM was either a hardware (old
> x86) or firmware (modern x86) task.

Certainly a lot of embedded systems, the bootloader is the firmware and
is responsible for a lot of hardwre configuration, although often the
operating system also does a lot.  Most x86 systems configure devices on
the PCI bus fairly sensible at power on before the OS starts.  On an arm
system, the linux kernel has to do all the PCI bus enumeration and
configuration since there is generally no PCI handling in the
firmware/boot laoder on such a system.  Of course embedded x86 systems
sometimes also don't do everything you want, in which case fixing it in
the boot loader is handy to avoid messing too much with the kernel.

> I'm a bit surprised by the lack of automatically detectable features in
> embedded systems. Wouldn't automatic detection allow reusing whole OS
> images on slighly different systems and thus lower development cost?

There is the problem of detecting what a given GPIO line does.  Use of
GPIO lines is very common on embedded systems, and the use is almost
always custom to each device.

-- 
Len Sorensen

Re: [Qemu-devel] [RFC] Machine description as data

[Jamie Lokier]

Paul Brook wrote:
> > Now, if you hand me such a configuration on a platter, I'd be a fool not
> > to take it.  The catch: I need one for a PC.
> 
> I suspect these two goals may be contradictory. The PC machine is so hairy 
> that you need a singing, dancing machine description to be able to describe 
> it.

About 8 months ago I wanted a QEMU PC, but with PIIX4 IDE controller
instead of the PIIX3 IDE controller that hw/pc.c binds.  (That's
needed to allow a Windows 2000 guest imported from Virtual PC to boot
without a blue screen).

It would have been handy to have an option "-drive if=ide,hw=piix4" or
similar, but considering the obscure reasons for it, I'd have been
happy with a machine configuration file where I could edit the type of
attached device.

By the way, Virtual PC has an XML configuration file which describes
the machine it's emulating in some detail, including device serial
numbers and such.  Is it worth a look?

> OTOH if what you really want to do is configure the host binding
> side of things, then as I've mentioned before, I see that as been
> somewhat separate from the actual machine creation, and trying to
> combine the two is probably a mistake. I really don't want users to
> have to hack the machine config just to change the name of an image
> file.

I agree that host binding is separate, but they're related.

"Placeholders" in the machine config for where particular command line
input can modify the config, with defaults, would be nice.

In the case of a disk image file, the machine config's default would
give a default of "no image file" (no disk present), with a
placeholder indicating that "-drive if=ide,index=0 affects this node"
or similar.

For some devices in the machine config, if the setting is "no image
file" or "no terminal attached", the config may say that the device
itself is to be omitted.  This would apply to hard disks, since you
can't have a not present hard disk.

For other devices in the machine config, the config may say the device
should be present but does nothing.  This would apply for those SoC
emulations which always have 3 UARTs, for example.  If the command
line doesn't attach those UARTs to something, the machine config would
still cause the UARTs to be present.  On a PC, you might always
include an emulated floppy drive, even if no floppy options are
included on the command line - unless "-drive
if=floppy,index=0,disabled" is passed on the command line perhaps.

I expect this can fit into any of the machine config syntaxes and tree
types which have been discussed.  It would be nice to have a generic
command line option which can modify any part of the machine config
tree too, but not necessary.

If the machine config syntax is human friendly enough, it may be
possible for host binding config to use the same syntax, instead of
copying a machine config and editing a small section when command line
options aren't detailed enough.

-- Jamie

Re: [coreboot] DTS syntax and DTC patches (was: Re: [Qemu-devel] [RFC] Machine description as data)

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 4772 bytes --]

Here is the sum total of the differences from when we checked it in
over 2 years ago until now (parser). Our real changes are to
flattree.c and livetree.c, where we do some ugly by-hand parsing of
the ids such that pci@1,0 etc. work. I'd love to see a way to bring
this into the real syntax. I've tried to do as little as possible to
.y and .l.

The diff with comments is attached.

But this brings up a bigger issue and we could use your help.

OK, what did we do? We implemented the ability to have a sort of
template. Here is a sample from real use.

/{
	mainboard_vendor = "Artec";
	mainboard_name = "DBE62";
	cpus { };
	apic@0 {
		/config/("northbridge/amd/geodelx/apic");
	};
	domain@0 {
		/config/("northbridge/amd/geodelx/domain");
		pci@1,0 {
			/config/("northbridge/amd/geodelx/pci");
			/* Video RAM has to be in 2MB chunks. */
			geode_video_mb = "16";
		};
	etc.

so what's going on here?

The config file in most cases is pretty straightforward. It's actually
just a list of properties with a standard setting for chip control. We
MUST have this; we don't want hundreds of settings in each mainboard,
because sometimes a chip fix comes along and we want that to go into
one chip file, and set the correct value, and have all mainboards get
the new value next time they are built.

Let's look at /config/("northbridge/amd/geodelx/pci");

{
	device_operations = "geodelx_mc";

	/* Video RAM has to be in 2MB chunks. */
	geode_video_mb = "0";
};

The device_operations property is processed by flattree and is of no
importance to you, but it is used in coreboot .h and .c code
generation. For coreboot use, we have several property names that are
special.

Note that we create a property, geode_video_mb, and set it to 0.

In the mainboard dts, we over-ride this value, and set it to 16.

These are pretty much the changes and, again, they work. But I'd like
more, as would our community.

Right now, we can take a file containing a list of dts properties,
read them in, and modify them as above. It's not really ideal, and I
am sure you can already see it could be done better. But what we
really want is the ability to read in  a dts node (with subnodes,
etc.) and then elide them in the mainboard file.

So, for example, we have this subsection of one mainboard:

		pci@6{ /* Port 2 */
			/config/("southbridge/amd/rs690/pcie.dts");
		};
		pci@7{ /* Port 3 */
			/config/("southbridge/amd/rs690/pcie.dts");
		};
		pci@12{
			/config/("southbridge/amd/sb600/hda.dts");
		};
		pci@13,0{
			/config/("southbridge/amd/sb600/usb.dts");
		};
		pci@13,1{
			/config/("southbridge/amd/sb600/usb.dts");
		};
		pci@13,2{
			/config/("southbridge/amd/sb600/usb.dts");
		};

This is not a bunch of chips, but one chip. It has lots of pci devices
in it; this one chip is equivalent to a whole mainboard from previous
years. What we'd really like is the ability to do what my wife calls
restrict, add, and remove (I don't have these terms just right, it's
some kind of compiler-speak which is what she does for a living).

Restrict we have; change property values from a default.
Add is what we'd like: add a node to a tree in some way.
Remove we would also like: remove a node from a dts we have read in
via /config/.

Note that the syntax is only suggested here, the right way to do this
is up to you experts.

/{
	device_operations="dbm690t";
	mainboard_vendor = "AMD";
	mainboard_name = "dbm690t";
	cpus { };
	apic@0 {
	};
	domain@0 /config/("northbridge/amd/k8/domain") = {
                pci@1,0 /config/("southbridge/amd/sb600/dts") = {
                      /* change default xyz to "1" */
                      xyz = "1";
                      /* disable pcie port 6. Note this is over-riding
a value in a node. This is new. */
                     pcie@1,0{disable;};
                     /* don't even put port 7 in the tree -- what is a
remove going to look like?. Also new. */
                     - pcie@5,0;
                      /* add the superio; default values are
acceptable. Also new. We can't add nodes. */
                     pnp@2e /config/("superio/winbond/1234");
              };
       };
};

The result would be more compact files and easier maintenance.

I realize these changes may be too large for the dts to take on; there
is an ongoing discussion as to whether some other language might not
be more appropriate.

But, at the same time, people are comfortable with dts. They have
found it very comfortable to use.

I'd like to thank you for this excellent tool. It is being used to
build production BIOSes that are shipping in products as I write this.
It really saved us a lot of work on coreboot v3 and it is a much
better job, certainly, than I could have done myself.

Thanks, and I hope we can discuss this and work together.

ron

[-- Attachment #2: dtcdiff --]
[-- Type: application/octet-stream, Size: 2999 bytes --]

Index: dtc-parser.y
===================================================================
--- dtc-parser.y	(.../LinuxBIOSv3/util/dtc/dtc-parser.y)	(revision 2)
+++ dtc-parser.y	(.../coreboot-v3/util/dtc/dtc-parser.y)	(working copy)
@@ -23,7 +23,6 @@
 
 %{
 #include "dtc.h"
-
 int yylex (void);
 void yyerror (char const *);
 
@@ -46,7 +45,7 @@
 	struct reserve_info *re;
 }
 
-%token DT_MEMRESERVE
+%token <str> DT_MEMRESERVE

>>>>>>>>>>We made this a string. It's never been of any use to us; you might consider whether the concept is obsolete; what's it for?


 %token <addr> DT_ADDR
 %token <str> DT_PROPNAME
 %token <str> DT_NODENAME
@@ -56,6 +55,8 @@
 %token <str> DT_UNIT
 %token <str> DT_LABEL
 %token <str> DT_REF
+%token <str> DT_FILENAME
+%token <proplist> DT_CONFIG


We implemented a "sort of" include. More in the note. You may not like it, the .l is also attached. We needed these two tokens for it. 


 
 %type <data> propdata
 %type <re> memreserve
@@ -68,14 +69,18 @@
 %type <node> devicetree
 %type <node> nodedef
 %type <node> subnode
+%type <proplist> config

This is for extensions/changes to the property list. More in the email. 


 %type <nodelist> subnodes
 %type <str> label
 %type <str> nodename
-
+%type <data> includepath
+%type <data> structname
 %%
 
-sourcefile:	memreserves devicetree {
-			the_boot_info = build_boot_info($1, $2);
+/*sourcefile:	memreserves devicetree {*/
+sourcefile:	devicetree {
+/*			the_boot_info = build_boot_info($1, $2);*/
+			the_boot_info = build_boot_info(0, $1);
 		}
 	;
 
@@ -100,8 +105,8 @@
 		}
 	;
 
-nodedef:	'{' proplist subnodes '}' ';' {
-			$$ = build_node($2, $3);
+nodedef:	'{' config proplist subnodes '}' ';' {
+			$$ = build_node($2, $3, $4);
 		}
 	;
 
@@ -113,6 +118,49 @@
 		}
 	;
 
+config:        DT_CONFIG '(' 
+		includepath {
+			void switchin(FILE *f);
+			FILE *f;
+			/* The need for a cast here is silly */
+			char *name = (char *)$3.val;
+
+			/* TODO: keep track of which of these we have read in. If we have already done it, then 
+			  * don't do it twice. 
+			  */
+			f  = fopenfile(name);
+			if (! f){
+				perror(name);
+				exit(1);
+			}
+			switchin(f);
+		}  '{' proplist '}' ';' {
+			void	switchback(void);
+			switchback();
+			
+		}
+		')' ';' {
+				int namelen;
+				char *name = strdup((char *)$3.val);
+				/* convention: first property is labeled with path */
+				$6->label = name;
+
+				/* convention: if it ends in .dts, strip that off	*/
+				namelen = strlen($6->label);
+				if ((namelen > 4) && (! strncmp(&name[namelen-4], ".dts", 4)))
+					$6->label[namelen-4] = '\0';
+
+				$$ = $6;
+			}
+	|
+	;
+
+includepath:	DT_STRING  { $$ = $1; }
+	;
+
+structname: 	DT_FILENAME {$$ = $1; }
+	;
+

The actual config command. What happens here is that if you have a config, the config properties are attached to tree->config. 

in flattree.c we resolve the property names. More in the mail. 



 propdef:	label DT_PROPNAME '=' propdata ';' {
 			$$ = build_property($2, $4, $1);
 		}

[-- Attachment #3: dtc-diff.l --]
[-- Type: application/octet-stream, Size: 2222 bytes --]

Index: dtc-lexer.l
===================================================================
--- dtc-lexer.l	(.../LinuxBIOSv3/util/dtc/dtc-lexer.l)	(revision 2)
+++ dtc-lexer.l	(.../coreboot-v3/util/dtc/dtc-lexer.l)	(working copy)
@@ -23,6 +23,7 @@
 %x CELLDATA
 %x BYTESTRING
 %x MEMRESERVE
+%x PASSTHROUGH
 
 PROPCHAR	[a-zA-Z0-9,._+*#?-]
 UNITCHAR	[0-9a-f,]
@@ -35,16 +36,33 @@
 
 #include "dtc-parser.tab.h"
 
-/*#define LEXDEBUG	1*/
-
 #ifdef LEXDEBUG
 #define DPRINT(fmt, ...)	fprintf(stderr, fmt, ##__VA_ARGS__)
 #else
 #define DPRINT(fmt, ...)	do { } while (0)
 #endif
 
+char *code = 0;
 
+YY_BUFFER_STATE bstack = NULL;
+int line;
 
+void
+switchin(FILE *f){
+	YY_BUFFER_STATE b;
+	bstack = YY_CURRENT_BUFFER;
+	b = yy_create_buffer(f, 8192);
+	line = yylineno;
+	yylineno = 1;
+	yy_switch_to_buffer(b);
+	
+}
+
+void
+switchback(void){
+		yy_switch_to_buffer(bstack);
+		yylineno = line;
+}


This is for switching input via /config/("filename");

 %}
 
 %%
@@ -58,6 +76,22 @@
 			return DT_STRING;
 		}
 
+^%%\n	{
+			DPRINT("Begin passthrough\n");
+			/* let's be stupid. 1 MB is way more than enough ... */
+			code = malloc(1048576);
+			*code = 0;
+			BEGIN(PASSTHROUGH);
+		}
+
+<PASSTHROUGH>.*	{
+					DPRINT("Matching in passthrough %s\n", yytext);
+					/* you tell me why echo does not work */
+					/*ECHO;*/
+					strcat(code, yytext);
+					strcat(code, "\n");
+				}
+
AFAIK the passthrough stuff is dead and no longer used. This would be removed. 

 "/memreserve/"	{
 			yylloc.first_line = yylineno;
 			DPRINT("Keyword: /memreserve/\n");
@@ -67,7 +101,7 @@
 
 <MEMRESERVE>[0-9a-fA-F]+ {
 			yylloc.first_line = yylineno;
-			if (yyleng > 2*sizeof(yylval.addr)) {
+			if ((unsigned long)yyleng > 2*sizeof(yylval.addr)) {
 				fprintf(stderr, "Address value %s too large\n",
 					yytext);
 			}
@@ -84,9 +118,15 @@
 			return ';';
 		}
 
+"/config/"	{
+			yylloc.first_line = yylineno;
+			DPRINT("Keyword: /config/\n");
+			return DT_CONFIG;
+		}
+

implements DT_CONFIG 
 <CELLDATA>[0-9a-fA-F]+	{
 			yylloc.first_line = yylineno;
-			if (yyleng > 2*sizeof(yylval.cval)) {
+			if ((unsigned long)yyleng > 2*sizeof(yylval.cval)) {
 				fprintf(stderr,
 					"Cell value %s too long\n", yytext);
 			}

[-- Attachment #4: Type: text/plain, Size: 194 bytes --]

_______________________________________________
devicetree-discuss mailing list
devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/devicetree-discuss

Re: [Qemu-devel] [RFC] Machine description as data

[Mitch Bradley]

Here is an IEEE1275 device tree for a OLPC system, which is close enough 
to a PC.

** /

ec-name                  PQ2E21
ec-version               00000054
serial-number            SHF73300042
board-revision-int       00000c18
model                    C1
dma-ranges               07000000 09000000
banner-name              OLPC C1
architecture             OLPC
#size-cells              00000001
#address-cells           00000001

** /cpus

#size-cells              00000000
#address-cells           00000001
name                     cpus

** /cpus/cpu@0

clock-frequency          19d42455
model                    AMD,Geode LX
reg                      00000000
device_type              cpu
name                     cpu

** /flash@fff00000

#address-cells           00000001
reg                      fff00000 00100000
name                     flash

** /memory@0

reg                      00000000 10000000
available                0efca000 00010000
                         0ef80000 00048000
                         00100000 0eb00000
                         00002000 0009e000
name                     memory

** /pci/usb@f,5

assigned-addresses       82007d10 00000000 fe01b000 00000000 00000100
reg                      00007d00 00000000 00000000 00000000 00000000
                         02007d10 00000000 00000000 00000000 00000100
#size-cells              00000000
#address-cells           00000002
name                     usb
device_type              ehci
66mhz-capable
devsel-speed             00000001
class-code               000c0320
subsystem-vendor-id      00001022
subsystem-id             00002095
interrupts               00000004
max-latency              00000000
min-grant                00000000
revision-id              00000002
device-id                00002095
vendor-id                00001022


** /pci/usb@f,4

assigned-addresses       82007c10 00000000 fe01a000 00000000 00001000
reg                      00007c00 00000000 00000000 00000000 00000000
                         02007c10 00000000 00000000 00000000 00001000
#size-cells              00000000
#address-cells           00000002
name                     usb
device_type              ohci
66mhz-capable
devsel-speed             00000001
class-code               000c0310
subsystem-vendor-id      00001022
subsystem-id             00002094
interrupts               00000004
max-latency              00000000
min-grant                00000000
revision-id              00000002
device-id                00002094
vendor-id                00001022


** /pci/audio@f,3

assigned-addresses       81007b10 00000000 00001480 00000000 00000080
reg                      00007b00 00000000 00000000 00000000 00000000
                         01007b10 00000000 00000000 00000000 00000080
compatible               AD1888
                         AC97,CODEC
output-encoding-types    16bit-LE-signed-linear
input-encoding-types     16bit-LE-signed-linear
sample-frame-size        00000010
sample-precisions        00000010
#output-channels         00000002
#input-channels          00000001
device_type              sound
name                     audio
66mhz-capable
fast-back-to-back
devsel-speed             00000001
class-code               00040100
subsystem-vendor-id      00001022
subsystem-id             00002093
interrupts               00000002
max-latency              00000000
min-grant                00000000
revision-id              00000001
device-id                00002093
vendor-id                00001022


** /pci/camera@c,2

assigned-addresses       82006210 00000000 fe028000 00000000 00004000
reg                      00006200 00000000 00000000 00000000 00000000
                         02006210 00000000 00000000 00000000 00004000
sensor                   OV7670
compatible               olpc,camera
device_type              camera
model                    olpc,camera
name                     camera
66mhz-capable
fast-back-to-back
devsel-speed             00000001
class-code               00040001
subsystem-vendor-id      000011ab
subsystem-id             00004100
interrupts               00000001
max-latency              00000008
min-grant                00000008
revision-id              00000010
device-id                00004102
vendor-id                000011ab


** /pci/sd@c,1

assigned-addresses       81006110 00000000 fe024000 00000000 00004000
reg                      00006100 00000000 00000000 00000000 00000100
                         01006110 00000000 00000000 00000000 00004000
compatible               sdhci
#size-cells              00000000
#address-cells           00000000
name                     sd
66mhz-capable
fast-back-to-back
devsel-speed             00000001
class-code               00080501
subsystem-vendor-id      000011ab
subsystem-id             00004100
interrupts               00000001
max-latency              00000008
min-grant                00000008
revision-id              00000010
device-id                00004101
vendor-id                000011ab


** /pci/nandflash@c

assigned-addresses       82006010 00000000 fe020000 00000000 00004000
reg                      00006000 00000000 00000000 00000000 00000000
                         02006010 00000000 00000000 00000000 00004000
compatible               olpc,cafenand
model                    olpc,cafenand
name                     nandflash
66mhz-capable
fast-back-to-back
devsel-speed             00000001
class-code               00050101
subsystem-vendor-id      000011ab
subsystem-id             00004100
interrupts               00000001
max-latency              00000008
min-grant                00000008
revision-id              00000010
device-id                00004100
vendor-id                000011ab


** /pci/pci1022,2082@1,2

assigned-addresses       82000a10 00000000 fe010000 00000000 00004000
reg                      00000a00 00000000 00000000 00000000 00000000
                         02000a10 00000000 00000000 00000000 00004000
compatible               pci1022,2082
                         pci1022,2082
                         pciclass,101000
name                     pci1022,2082
66mhz-capable
fast-back-to-back
devsel-speed             00000001
class-code               00101000
subsystem-vendor-id      00001022
subsystem-id             00002082
interrupts               00000001
max-latency              00000000
min-grant                00000000
revision-id              00000000
device-id                00002082
vendor-id                00001022


** /pci/host@1

assigned-addresses       81000810 00000000 0000ac1c 00000000 00000004
power-consumption        00 00 00 00 01 7d 78 40
reg                      00000800 00000000 00000000 00000000 00000000
                         01000810 00000000 00000000 00000000 00000004
compatible               pci1022,2080
                         pci1022,2080
                         pciclass,060000
name                     host
66mhz-capable
devsel-speed             00000001
class-code               00060000
subsystem-vendor-id      00001022
subsystem-id             00002080
max-latency              00000000
min-grant                00000000
revision-id              00000021
device-id                00002080
vendor-id                00001022


** /pci/display@1,1

compatible               pci1022,2081
                         pci1022,2081
                         pciclass,030000
66mhz-capable
devsel-speed             00000001
class-code               00030000
subsystem-vendor-id      00001022
subsystem-id             00002081
interrupts               00000001
max-latency              00000000
min-grant                00000000
revision-id              00000000
device-id                00002081
vendor-id                00001022
address                  fd000000
linebytes                00000960
depth                    00000010
height                   00000384
width                    000004b0
assigned-addresses       82000910 00000000 fd000000 00000000 00800000
                         82000914 00000000 fe000000 00000000 00004000
                         82000918 00000000 fe004000 00000000 00004000
                         8200091c 00000000 fe008000 00000000 00004000
                         82000920 00000000 fe00c000 00000000 00004000
iso6429-1983-colors
character-set            ISO8859-1
device_type              display
reg                      00000900 00000000 00000000 00000000 00000100
                         02000910 00000000 00000000 00000000 00800000
                         02000914 00000000 00000000 00000000 00004000
                         02000918 00000000 00000000 00000000 00004000
                         0200091c 00000000 00000000 00000000 00004000
                         02000920 00000000 00000000 00000000 00004000
name                     display


** /pci/isa@f

assigned-addresses       81007810 00000000 000018b0 00000000 00000000
                         81007814 00000000 00001000 00000000 00000000
                         81007818 00000000 00001800 00000000 00000000
                         8100781c 00000000 00001880 00000000 00000000
                         81007820 00000000 00001400 00000000 00000000
                         81007824 00000000 00001840 00000000 00000000
66mhz-capable
fast-back-to-back
devsel-speed             00000001
class-code               00060100
subsystem-vendor-id      00001022
subsystem-id             00002090
max-latency              00000000
min-grant                00000000
revision-id              00000003
device-id                00002090
vendor-id                00001022
interrupt-parent         ff867a98
#interrupt-cells         00000002
ranges                   00000000 00000000 02000000 00000000 00000000 
01000000
                         00000001 00000000 01000000 00000000 00000000 
00010000
clock-frequency          007ea5e0
reg                      00007800 00000000 00000000 00000000 00000000
#size-cells              00000001
#address-cells           00000002
device_type              isa
name                     isa


** /pci/usb@f,5/wlan@0,0

device_type              wireless-network
configuration#           00000001
bulk-in-size             00000200
bulk-in-pipe             00000003
bulk-out-size            00000200
bulk-out-pipe            00000002
serial$
device$                  MARVELL Wireless Device
vendor$                  Marvell
compatible               usb1286,2001.3107
                         usb1286,2001
                         usbif1286,classff.ff.ff
                         usbif1286,classff.ff
                         usbif1286,classff
                         usbif,classff.ff.ff
                         usbif,classff.ff
                         usbif,classff
                         usb,device
vendor-id                00001286
device-id                00002001
release                  00003107
name                     wlan
class                    000000ff
subclass                 000000ff
protocol                 000000ff
high-speed
assigned-address         00000001
reg                      00000000 00000000
#size-cells              00000000
#address-cells           00000001


** /pci/sd@c,1/disk

device_type              block
iconname                 sdmmc
name                     disk


** /pci/isa@f/rtc@i70

status                   okay
century                  00000032
alarm_month              0000003e
alarm_day                0000003d
device#                  00000002
interrupts               00000008
                         00000000
reg                      00000001 00000070 00000002
compatible               pnpPNP,b00
device_type              rtc
name                     rtc


** /pci/isa@f/8042@i60

#size-cells              00000000
#address-cells           00000001
reg                      00000001 00000060 00000001
                         00000001 00000064 00000001
compatible               ps2-keyboard-controller
                         INTC,80c42
device_type              8042
name                     8042
model                    INTC,80c42
interrupts               00000001
                         00000003
                         0000000c
                         00000003


** /pci/isa@f/serial@i3f8

reg                      00000001 000003f8 00000008
compatible               pnpPNP,501
device_type              serial
name                     serial
clock-frequency          001c2000
interrupts               00000004
                         00000003


** /pci/isa@f/timer@i40

interrupts               00000000
                         00000003
reg                      00000001 00000040 00000004
                         00000001 00000061 00000001
compatible               pnpPNP,100
device_type              timer
name                     timer


** /pci/isa@f/interrupt-controller@i20

reg                      00000001 00000020 00000002
                         00000001 000000a0 00000002
                         00000001 000004d0 00000002
compatible               pnpPNP,0
device_type              interrupt-controller
name                     interrupt-controller
#address-cells           00000000
#interrupt-cells         00000002
interrupt-controller


** /pci/isa@f/dma-controller@i00

reg                      00000001 00000000 00000010
                         00000001 00000080 00000020
                         00000001 000000c0 00000020
                         00000001 00000481 0000000f
compatible               pnpPNP,200
device_type              dma-controller
name                     dma-controller


** /pci/isa@f/8042@i60/mouse@aux

reg                      00000001
compatible               pnpPNP,f03
device_type              mouse
name                     mouse


** /pci/isa@f/8042@i60/keyboard@kbd

language                 EN
keyboard-type            us
reg                      00000000
device_type              keyboard
compatible               pnpPNP,303
name                     keyboard

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> writes:

> Here is an IEEE1275 device tree for a OLPC system, which is close
> enough to a PC.
[snip...]

Thanks!  Got this in .dts syntax, by chance?

Re: [Qemu-devel] [RFC] Machine description as data

[Mitch Bradley]

>
> Mitch Bradley <wmb-D5eQfiDGL7eakBO8gow8eQ@public.gmane.org> writes:
>
>   
>> > Here is an IEEE1275 device tree for a OLPC system, which is close
>> > enough to a PC.
>>     
> [snip...]
>
> Thanks!  Got this in .dts syntax, by chance?
>   

Sorry, I do full-up Open Firmware, not flattened device trees.

Re: [Qemu-devel] [RFC] Machine description as data

[Jon Loeliger]

On Fri, 2009-02-13 at 03:11 +0100, Carl-Daniel Hailfinger wrote:
> On 13.02.2009 01:43, David Gibson wrote:
> > On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
> >   
> >> I didn't mean to say they are a bad idea for FDTs, just that they're on
> >> an awkward level of abstraction for QEMU configuration.  There, I'd
> >> rather express a PCI address as "02:01.0" than as <0x00000220>.
> >> Translating text to binary is the machine's job, not the user's.
> >>     
> >
> > Ah, I see what you mean.  Hrm, there are several possibilities here,
> > we'll have to see which works out best for your purposes.
> >   
> 
> Using the DTC version included in the coreboot v3 sources would solve
> that problem and give you a readable PCI address representation.

As would the proposed language enhancements I suggested.

jdl

Re: [Qemu-devel] [RFC] Machine description as data

[Carl-Daniel Hailfinger]

On 13.02.2009 21:04, Jon Loeliger wrote:
> On Fri, 2009-02-13 at 03:11 +0100, Carl-Daniel Hailfinger wrote:
>   
>> On 13.02.2009 01:43, David Gibson wrote:
>>     
>>> On Thu, Feb 12, 2009 at 11:26:46AM +0100, Markus Armbruster wrote:
>>>   
>>>       
>>>> I didn't mean to say they are a bad idea for FDTs, just that they're on
>>>> an awkward level of abstraction for QEMU configuration.  There, I'd
>>>> rather express a PCI address as "02:01.0" than as <0x00000220>.
>>>> Translating text to binary is the machine's job, not the user's.
>>>>     
>>>>         
>>> Ah, I see what you mean.  Hrm, there are several possibilities here,
>>> we'll have to see which works out best for your purposes.
>>>   
>>>       
>> Using the DTC version included in the coreboot v3 sources would solve
>> that problem and give you a readable PCI address representation.
>>     
>
> As would the proposed language enhancements I suggested.
>   

Do you have a pointer to the archives for that?

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/

Re: [Qemu-devel] [RFC] Machine description as data

[Jon Loeliger]

On Fri, 2009-02-13 at 21:15 +0100, Carl-Daniel Hailfinger wrote:

> > As would the proposed language enhancements I suggested.
> >   
> 
> Do you have a pointer to the archives for that?


All that code is available in the "testing" branch of
the repository on jdl.com.

Fair warning, I'm rebasing that branch to HEAD of master regularly.

jdl

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Fri, Feb 13, 2009 at 12:26:28PM +0100, Markus Armbruster wrote:
> David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
> > On Thu, Feb 12, 2009 at 11:26:12AM +0100, Markus Armbruster wrote:
> >> Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
[snip]
> > dtc and libfdt is a good place to start, if you haven't yet
> > investigated them:
> > 	git://git.jdl.com/software/dtc.git
> > Note that although they're distributed together as one tree, dtc and
> > libfdt are essentially independent pieces of software.  dtc converts
> > device trees between various formats, dts and dtb in particular.
> >
> > libfdt does a number of the things you mention with flat trees -
> > get/set properties, build trees, traverse etc.  If it doesn't do
> > everything you need, we can probably extend it so that it does: I want
> > libfdt to be *the* library for manipulating trees in the fdt forma.
> > It's designed to be easy to embed in other packages for this reason,
> > although it does have some usage peculiarities because in particular
> > it's possible to integrate into very limited environments like
> > firmwares.
> >
> > [Jon Loeliger is the current maintainer of dtc and libfdt, but I
> > originally wrote both of them - I know as much about them as anyone
> > does]
> 
> Okay, I looked at dtc and libfdt again, a bit more closely.  I'm sure
> there's plenty of ignorance left in me, so please correct me when I'm
> babbling nonsense.

Sure.  So, I realize that there are two different questions here:
	a) Is IEEE1275 a good starting point for the content of a
decorated tree for configuring qemu.

Personally, I suspect the answer to this is yes, but more information
might convince me otherwise.

	b) Is the flattened tree format for representing IEEE1275-like
trees useful for qemu.

Personally, I think this is a "maybe".  More on this below.

Actually, on consideration there's a third question, too:
	c) Are the extensions / simplifications / adjustments we've
made to IEEE1275 conventions in the context of flattened trees also
useful and appropriate for qemu-configuration tree.

I think if the answer to (a) is yes, then the answer to (c) is yes,
too.

> FDT is a "flattened tree", i.e. a tree data structure laid out in a
> block of memory in a clever way to make it compact and easily

That's correct.

> relocatable.  I understand why these are important requirements for
> passing information through bootloader to kernel.  They're irrelevant,
> however, for use as QEMU configuration.

That's probably largely true.

> You can identify an FDT node by node offset or node name.  The node
> offset can change when you add or delete nodes or properties.

Correct.

> You want everyone to use libfdt for manipulating FDTs.  I think that's
> entirely sensible.  What I still don't get is something else: Why use
> FDT for QEMU configuration in the first place?  Let me explain.

Yeah, I see your point, hence my "maybe" to (b) above.  There's no
obvious call for the fdt format in qemu, but I can see a couple of
minor things that might make it worthwhile: First, if qemu ever does
want to record its configuration tree persistently - to be passed
between programs, or between invocations of a program - then it's
probably better to use the established fdt format rather than creating
a new one, even if fdt isn't designed particularly towards qemu's
purposes.  Second, the existing code / tools for working with the fdt
format *might* be sufficiently useful to make it worth using.

[Note also that the fdt tools will mostly work fine even if the tree
content is *not* very IEEE1275-like]

> I think we have two distinct problems: the need for a flexible,
> expressive QEMU machine configuration file and a virtual device
> configuration machinery driven by it, and the need for an FDT to pass to
> a PowerPC kernel.  The two may be related, but they are not identical.
> 
> Let's pretend for a minute the latter need doesn't exist.
> 
> QEMU machine configuration wants to be a decorated tree: a tree of named
> nodes with named properties.
> 
> IEEE 1275 is a standard describing a special kind of decorated tree.
> Other kinds can be created with a binding.  If we create a suitable
> binding, we can surely cast our configuration trees in the IEEE 1275
> framework.

That's not quite what "binding" usually means in the 1275 context, but
I think I the point is right enough.

> But what would that buy us?  This is a honest question, born out of my
> relative ignorance of IEEE 1275.  Mind that we're still busily ignoring
> the need for an FDT to pass to a kernel, so "it makes it easier to
> create an FDT for the kernel" doesn't count here (it counts elsewhere).

I think the idea behind using IEEE1275-like trees is that there is
significant overlap between the device information that IEEE1275
represents, and the device information which is configurable in qemu.
Ultimately whether it buys you enough depends on how large that
overlap is.

> FDTs are a special representation of IEEE 1275 trees in memory, designed
> to be compact and relocatable.  But that comes at a price: nodes move
> around when the tree changes.  The only real node id is the full name.

Or phandle, for those nodes which have one.

> This is not the common representation of decorated trees in C programs,
> and for a reason.  It's simpler to represent edges as C pointers.  Not
> the least advantage of that is notation: "->" beats a function call in
> legibility hands down.

Yes.  If there's enough manipulation of the tree, then you're
generally better off having a "live" format which uses pointers,
whether or not the fdt format is used at some stage in the process.
Both the kernel and dtc (when taking fdt input) convert the flattened
tree into a "live" representation internally.

> Example: the QEMU device data type needs to refer to its device node in
> the configuration tree.  If that tree is coded the plain old way, you
> store a pointer to the node and follow that.  If it is an FDT, then you
> have to store the full node name, and look up the node by name.  I find
> that tedious and verbose.

Um.. I don't really follow your example.  But I think I see your
point.  How problematic the flattened format is for this depends a lot
on exactly what you need to do with it.  Sometimes it's much easier to
avoid the flattened tree altogether, or transcribe it to a live
format.  Other times, the tree manipulation is simple enough that it's
easier to leave it flat (one example, for phases of the program where
the tree is read-only, which could be a lot for a configuration tree,
then node offsets *can* safely be used like pointers).

> My point is: the question how to represent our decorated tree in memory
> is entirely separate from the question of the tree's structure.  Just
> because you want your tree to conform to IEEE 1275 doesn't mean you want
> your tree flat at all times.

Absolutely, yes.


> Now let's examine how QEMU machine configuration and FDT machine
> descriptions for kernels are related.
> 
> In a way, both can be regarded as copies of a complete machine
> description with lots of stuff pruned.  Except the complete machine
> description doesn't exist.  Because there is no use for it.
> 
> FDT routinely prunes stuff like PCI and USB devices, because those are
> better probed.
> 
> QEMU configuration should certainly prune everything that is not
> actually configurable.
> 
> To go from QEMU configuration to FDT we therefore may want to prune
> superflous stuff, to keep it compact,

Not necessarily.  The kernel should be fine to deal with a tree that
has complete information, even if it doesn't need it, since that's
what a real OF implementation provides.

>  and we definitely have to add lots
> of stuff that has no place in configuration.

Yes.  Well.. whether this is a good plan depends critically on how big
that "lots" really is.

>  Compared to that task, a
> change of representation seems trivial.  I figure we want to copy the
> tree anyway, because we need to edit it pretty drastically.
> 
> It's not obvious to me whether it makes sense to create the FDT from the
> QEMU configuration automatically.  If we simulate a specific board, the
> FDT is pretty fixed, isn't it?  Much of the configurable stuff could be
> precisely in those parts that are omitted from FDT: PCI devices and
> such.

Well.. you definitely want to create the FDT passed to the kernel from
the qemu configuration.  But whether that's best done by essentially
transcribing a configuration tree which is in a similar format, or
just using the configuration tree info to poke the changable bits in a
"skeleton" FDT for the relevant machine is not so clear.

Possibly.  I'm not familiar enough with the various qemu supported
machine models to say.

> >> * Provide an example tree describing a bare-bones PC, like the one in my
> >>   prototype: CPU, RAM, BIOS, PIC, APIC, IOAPIC, PIT, DMA, UART, parallel
> >>   port, floppy controller, CMOS & RTC, a20 gate (port 92) and other
> >>   miscellanous I/O ports, i440fx, PIIX3 (ISA bridge, IDE, USB, ACPI),
> >>   Cirrus VGA with BIOS, some PCI NIC.  This gives us all an idea of the
> >>   tree structure.  Morphing that into something suitable for QEMU
> >>   configuration shouldn't be too hard then, just an exercice in
> >>   redecorating the tree.
> >
> > I don't off hand know any trees for a PC system.  There are a bunch of
> > example trees for powerpc systems in arch/powerpc/boot/dts in the
> > kernel tree.  A few of those, such as prep, at least have parts which
> > somewhat resemble a PC.  I believe the OLPC also has OF; that would be
> > an example OF tree for an x86 machine, if not a typical PC.
> 
> Could you point me to a specific file?  I grepped for prep and OLPC, no
> luck.

Oh, sorry, the prep tree hasn't gone into mainline yet.  But I believe
Mitch Bradley supplied a PC tree later in the thread, which would be
better for your purposes, anyway.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:

> On Fri, Feb 13, 2009 at 12:26:28PM +0100, Markus Armbruster wrote:
>> David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
>> > On Thu, Feb 12, 2009 at 11:26:12AM +0100, Markus Armbruster wrote:
>> >> Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> writes:
> [snip]
>> > dtc and libfdt is a good place to start, if you haven't yet
>> > investigated them:
>> > 	git://git.jdl.com/software/dtc.git
>> > Note that although they're distributed together as one tree, dtc and
>> > libfdt are essentially independent pieces of software.  dtc converts
>> > device trees between various formats, dts and dtb in particular.
>> >
>> > libfdt does a number of the things you mention with flat trees -
>> > get/set properties, build trees, traverse etc.  If it doesn't do
>> > everything you need, we can probably extend it so that it does: I want
>> > libfdt to be *the* library for manipulating trees in the fdt forma.
>> > It's designed to be easy to embed in other packages for this reason,
>> > although it does have some usage peculiarities because in particular
>> > it's possible to integrate into very limited environments like
>> > firmwares.
>> >
>> > [Jon Loeliger is the current maintainer of dtc and libfdt, but I
>> > originally wrote both of them - I know as much about them as anyone
>> > does]
>> 
>> Okay, I looked at dtc and libfdt again, a bit more closely.  I'm sure
>> there's plenty of ignorance left in me, so please correct me when I'm
>> babbling nonsense.
>
> Sure.  So, I realize that there are two different questions here:
> 	a) Is IEEE1275 a good starting point for the content of a
> decorated tree for configuring qemu.
>
> Personally, I suspect the answer to this is yes, but more information
> might convince me otherwise.

I think it's simply too early to call.  We're learning as we go.

> 	b) Is the flattened tree format for representing IEEE1275-like
> trees useful for qemu.
>
> Personally, I think this is a "maybe".  More on this below.
>
> Actually, on consideration there's a third question, too:
> 	c) Are the extensions / simplifications / adjustments we've
> made to IEEE1275 conventions in the context of flattened trees also
> useful and appropriate for qemu-configuration tree.
>
> I think if the answer to (a) is yes, then the answer to (c) is yes,
> too.

Sounds fair to me, but I'm hardly qualified to judge.

>> FDT is a "flattened tree", i.e. a tree data structure laid out in a
>> block of memory in a clever way to make it compact and easily
>
> That's correct.
>
>> relocatable.  I understand why these are important requirements for
>> passing information through bootloader to kernel.  They're irrelevant,
>> however, for use as QEMU configuration.
>
> That's probably largely true.
>
>> You can identify an FDT node by node offset or node name.  The node
>> offset can change when you add or delete nodes or properties.
>
> Correct.
>
>> You want everyone to use libfdt for manipulating FDTs.  I think that's
>> entirely sensible.  What I still don't get is something else: Why use
>> FDT for QEMU configuration in the first place?  Let me explain.
>
> Yeah, I see your point, hence my "maybe" to (b) above.  There's no
> obvious call for the fdt format in qemu, but I can see a couple of
> minor things that might make it worthwhile: First, if qemu ever does
> want to record its configuration tree persistently - to be passed
> between programs, or between invocations of a program - then it's
> probably better to use the established fdt format rather than creating
> a new one, even if fdt isn't designed particularly towards qemu's
> purposes.  Second, the existing code / tools for working with the fdt
> format *might* be sufficiently useful to make it worth using.
>
> [Note also that the fdt tools will mostly work fine even if the tree
> content is *not* very IEEE1275-like]
>
>> I think we have two distinct problems: the need for a flexible,
>> expressive QEMU machine configuration file and a virtual device
>> configuration machinery driven by it, and the need for an FDT to pass to
>> a PowerPC kernel.  The two may be related, but they are not identical.
>> 
>> Let's pretend for a minute the latter need doesn't exist.
>> 
>> QEMU machine configuration wants to be a decorated tree: a tree of named
>> nodes with named properties.
>> 
>> IEEE 1275 is a standard describing a special kind of decorated tree.
>> Other kinds can be created with a binding.  If we create a suitable
>> binding, we can surely cast our configuration trees in the IEEE 1275
>> framework.
>
> That's not quite what "binding" usually means in the 1275 context, but
> I think I the point is right enough.
>
>> But what would that buy us?  This is a honest question, born out of my
>> relative ignorance of IEEE 1275.  Mind that we're still busily ignoring
>> the need for an FDT to pass to a kernel, so "it makes it easier to
>> create an FDT for the kernel" doesn't count here (it counts elsewhere).
>
> I think the idea behind using IEEE1275-like trees is that there is
> significant overlap between the device information that IEEE1275
> represents, and the device information which is configurable in qemu.
> Ultimately whether it buys you enough depends on how large that
> overlap is.

I think that's fair.

I believe we don't quite know yet whether the overlap will make it
worthwhile.

One way to approach this is to assume it will until proven wrong.  You
start with an IEEE 1275 description of the machine, and extend or adapt
it as you go.  My problem with that is that we don't have such
descriptions for the machines that interest me.  Developing them is a
big step that pays no immediate benefits, but blocks the little steps
that do pay.  Moreover, without a *real* user of the description, I'd
likely develop something that looks like IEEE 1275 to me, but isn't.  If
it turns out that IEEE 1275 is not worth it, tough, we already paid for
it.

Another way to approach this is to admit we don't know enough and punt
the decision until we do.  Start with the beneficial baby steps.  Limit
the machine description business to what is required for the baby steps,
making a best effort to stay close to IEEE 1275 structurally.  If it
turns out that IEEE 1275 is worth it, we do whatever is left to make the
descriptions conform to it.

I'm much more comfortable with the second approach.

>> FDTs are a special representation of IEEE 1275 trees in memory, designed
>> to be compact and relocatable.  But that comes at a price: nodes move
>> around when the tree changes.  The only real node id is the full name.
>
> Or phandle, for those nodes which have one.

Right, forgot about those.

>> This is not the common representation of decorated trees in C programs,
>> and for a reason.  It's simpler to represent edges as C pointers.  Not
>> the least advantage of that is notation: "->" beats a function call in
>> legibility hands down.
>
> Yes.  If there's enough manipulation of the tree, then you're
> generally better off having a "live" format which uses pointers,
> whether or not the fdt format is used at some stage in the process.
> Both the kernel and dtc (when taking fdt input) convert the flattened
> tree into a "live" representation internally.

Not surprising.

>> Example: the QEMU device data type needs to refer to its device node in
>> the configuration tree.  If that tree is coded the plain old way, you
>> store a pointer to the node and follow that.  If it is an FDT, then you
>> have to store the full node name, and look up the node by name.  I find
>> that tedious and verbose.
>
> Um.. I don't really follow your example.  But I think I see your
> point.  How problematic the flattened format is for this depends a lot
> on exactly what you need to do with it.  Sometimes it's much easier to
> avoid the flattened tree altogether, or transcribe it to a live
> format.  Other times, the tree manipulation is simple enough that it's
> easier to leave it flat (one example, for phases of the program where
> the tree is read-only, which could be a lot for a configuration tree,
> then node offsets *can* safely be used like pointers).

The machines I care for come with many optional and configurable parts.
We select the basic machine type with command line option -M, and
configure the rest with more command line options.  I figure we want to
keep supporting these options, at least for a while.

I believe the best way to deal with that is start with a basic tree
selected by -M, then modify it according to the other options.  So,
there's a fair amount of configuration tree mutation.

>> My point is: the question how to represent our decorated tree in memory
>> is entirely separate from the question of the tree's structure.  Just
>> because you want your tree to conform to IEEE 1275 doesn't mean you want
>> your tree flat at all times.
>
> Absolutely, yes.
>
>
>> Now let's examine how QEMU machine configuration and FDT machine
>> descriptions for kernels are related.
>> 
>> In a way, both can be regarded as copies of a complete machine
>> description with lots of stuff pruned.  Except the complete machine
>> description doesn't exist.  Because there is no use for it.
>> 
>> FDT routinely prunes stuff like PCI and USB devices, because those are
>> better probed.
>> 
>> QEMU configuration should certainly prune everything that is not
>> actually configurable.
>> 
>> To go from QEMU configuration to FDT we therefore may want to prune
>> superflous stuff, to keep it compact,
>
> Not necessarily.  The kernel should be fine to deal with a tree that
> has complete information, even if it doesn't need it, since that's
> what a real OF implementation provides.

Well, wasn't compactness one of the reasons to flatten it in the first
place?

>>  and we definitely have to add lots
>> of stuff that has no place in configuration.
>
> Yes.  Well.. whether this is a good plan depends critically on how big
> that "lots" really is.

I suspect the only way to find out is to try.

>>  Compared to that task, a
>> change of representation seems trivial.  I figure we want to copy the
>> tree anyway, because we need to edit it pretty drastically.
>> 
>> It's not obvious to me whether it makes sense to create the FDT from the
>> QEMU configuration automatically.  If we simulate a specific board, the
>> FDT is pretty fixed, isn't it?  Much of the configurable stuff could be
>> precisely in those parts that are omitted from FDT: PCI devices and
>> such.
>
> Well.. you definitely want to create the FDT passed to the kernel from
> the qemu configuration.  But whether that's best done by essentially
> transcribing a configuration tree which is in a similar format, or
> just using the configuration tree info to poke the changable bits in a
> "skeleton" FDT for the relevant machine is not so clear.
>
> Possibly.  I'm not familiar enough with the various qemu supported
> machine models to say.

Familiarity with all of them is a tall order...

>> >> * Provide an example tree describing a bare-bones PC, like the one in my
>> >>   prototype: CPU, RAM, BIOS, PIC, APIC, IOAPIC, PIT, DMA, UART, parallel
>> >>   port, floppy controller, CMOS & RTC, a20 gate (port 92) and other
>> >>   miscellanous I/O ports, i440fx, PIIX3 (ISA bridge, IDE, USB, ACPI),
>> >>   Cirrus VGA with BIOS, some PCI NIC.  This gives us all an idea of the
>> >>   tree structure.  Morphing that into something suitable for QEMU
>> >>   configuration shouldn't be too hard then, just an exercice in
>> >>   redecorating the tree.
>> >
>> > I don't off hand know any trees for a PC system.  There are a bunch of
>> > example trees for powerpc systems in arch/powerpc/boot/dts in the
>> > kernel tree.  A few of those, such as prep, at least have parts which
>> > somewhat resemble a PC.  I believe the OLPC also has OF; that would be
>> > an example OF tree for an x86 machine, if not a typical PC.
>> 
>> Could you point me to a specific file?  I grepped for prep and OLPC, no
>> luck.
>
> Oh, sorry, the prep tree hasn't gone into mainline yet.  But I believe
> Mitch Bradley supplied a PC tree later in the thread, which would be
> better for your purposes, anyway.

Got that, haven't digested it yet.

Re: [Qemu-devel] [RFC] Machine description as data

[David Gibson]

On Mon, Feb 16, 2009 at 05:39:40PM +0100, Markus Armbruster wrote:
> David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
> > On Fri, Feb 13, 2009 at 12:26:28PM +0100, Markus Armbruster wrote:
[snip]
> > I think the idea behind using IEEE1275-like trees is that there is
> > significant overlap between the device information that IEEE1275
> > represents, and the device information which is configurable in qemu.
> > Ultimately whether it buys you enough depends on how large that
> > overlap is.
> 
> I think that's fair.
> 
> I believe we don't quite know yet whether the overlap will make it
> worthwhile.

Yeah, true enough.

> One way to approach this is to assume it will until proven wrong.  You
> start with an IEEE 1275 description of the machine, and extend or adapt
> it as you go.  My problem with that is that we don't have such
> descriptions for the machines that interest me.  Developing them is a
> big step that pays no immediate benefits, but blocks the little steps
> that do pay.  Moreover, without a *real* user of the description, I'd
> likely develop something that looks like IEEE 1275 to me, but isn't.  If
> it turns out that IEEE 1275 is not worth it, tough, we already paid for
> it.
> 
> Another way to approach this is to admit we don't know enough and punt
> the decision until we do.  Start with the beneficial baby steps.  Limit
> the machine description business to what is required for the baby steps,
> making a best effort to stay close to IEEE 1275 structurally.  If it
> turns out that IEEE 1275 is worth it, we do whatever is left to make the
> descriptions conform to it.
> 
> I'm much more comfortable with the second approach.

That's reasonable.  However, once you've taken enough baby steps you
do want to be careful that you don't end up long term with something
that's similar enough to 1275 to be confusing, but not similar enough
to be useful.  So at some point we do want to take a look ahead and
see how much difference there will be between the qemu-required config
information and the 1275 dectree.

> >> FDTs are a special representation of IEEE 1275 trees in memory, designed
> >> to be compact and relocatable.  But that comes at a price: nodes move
> >> around when the tree changes.  The only real node id is the full name.
> >
> > Or phandle, for those nodes which have one.
> 
> Right, forgot about those.
> 
> >> This is not the common representation of decorated trees in C programs,
> >> and for a reason.  It's simpler to represent edges as C pointers.  Not
> >> the least advantage of that is notation: "->" beats a function call in
> >> legibility hands down.
> >
> > Yes.  If there's enough manipulation of the tree, then you're
> > generally better off having a "live" format which uses pointers,
> > whether or not the fdt format is used at some stage in the process.
> > Both the kernel and dtc (when taking fdt input) convert the flattened
> > tree into a "live" representation internally.
> 
> Not surprising.
> 
> >> Example: the QEMU device data type needs to refer to its device node in
> >> the configuration tree.  If that tree is coded the plain old way, you
> >> store a pointer to the node and follow that.  If it is an FDT, then you
> >> have to store the full node name, and look up the node by name.  I find
> >> that tedious and verbose.
> >
> > Um.. I don't really follow your example.  But I think I see your
> > point.  How problematic the flattened format is for this depends a lot
> > on exactly what you need to do with it.  Sometimes it's much easier to
> > avoid the flattened tree altogether, or transcribe it to a live
> > format.  Other times, the tree manipulation is simple enough that it's
> > easier to leave it flat (one example, for phases of the program where
> > the tree is read-only, which could be a lot for a configuration tree,
> > then node offsets *can* safely be used like pointers).
> 
> The machines I care for come with many optional and configurable parts.
> We select the basic machine type with command line option -M, and
> configure the rest with more command line options.  I figure we want to
> keep supporting these options, at least for a while.
> 
> I believe the best way to deal with that is start with a basic tree
> selected by -M, then modify it according to the other options.  So,
> there's a fair amount of configuration tree mutation.

Yeah, you're probably right.  Although, in some cases the amount of
complex tree mutation can be cut down by thinking about things in the
right order.  For example if you have a bunch of optional devices,
rather than adding them one by one (with all the required properties)
to the skeleton tree, you can instead have the skeleton tree be the
all-bells-and-whistles variant then delete the subtrees that aren't
present.  libfdt even has a function to replace subtrees with nops
instead of eliding them, which means the offsets of other nodes won't
change.

> >> My point is: the question how to represent our decorated tree in memory
> >> is entirely separate from the question of the tree's structure.  Just
> >> because you want your tree to conform to IEEE 1275 doesn't mean you want
> >> your tree flat at all times.
> >
> > Absolutely, yes.
> >
> >> Now let's examine how QEMU machine configuration and FDT machine
> >> descriptions for kernels are related.
> >> 
> >> In a way, both can be regarded as copies of a complete machine
> >> description with lots of stuff pruned.  Except the complete machine
> >> description doesn't exist.  Because there is no use for it.
> >> 
> >> FDT routinely prunes stuff like PCI and USB devices, because those are
> >> better probed.
> >> 
> >> QEMU configuration should certainly prune everything that is not
> >> actually configurable.
> >> 
> >> To go from QEMU configuration to FDT we therefore may want to prune
> >> superflous stuff, to keep it compact,
> >
> > Not necessarily.  The kernel should be fine to deal with a tree that
> > has complete information, even if it doesn't need it, since that's
> > what a real OF implementation provides.
> 
> Well, wasn't compactness one of the reasons to flatten it in the first
> place?

One, since we were aiming at embedded systems, but not nearly a big a
factor as relocatability.  For qemu, I don't think the compactness is
much of an issue.

> >>  and we definitely have to add lots
> >> of stuff that has no place in configuration.
> >
> > Yes.  Well.. whether this is a good plan depends critically on how big
> > that "lots" really is.
> 
> I suspect the only way to find out is to try.

Indeed.

[snip]
> > Oh, sorry, the prep tree hasn't gone into mainline yet.  But I believe
> > Mitch Bradley supplied a PC tree later in the thread, which would be
> > better for your purposes, anyway.
> 
> Got that, haven't digested it yet.

Fair enough.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:

> On Mon, Feb 16, 2009 at 05:39:40PM +0100, Markus Armbruster wrote:
>> David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> writes:
>> > On Fri, Feb 13, 2009 at 12:26:28PM +0100, Markus Armbruster wrote:
> [snip]
>> > I think the idea behind using IEEE1275-like trees is that there is
>> > significant overlap between the device information that IEEE1275
>> > represents, and the device information which is configurable in qemu.
>> > Ultimately whether it buys you enough depends on how large that
>> > overlap is.
>> 
>> I think that's fair.
>> 
>> I believe we don't quite know yet whether the overlap will make it
>> worthwhile.
>
> Yeah, true enough.
>
>> One way to approach this is to assume it will until proven wrong.  You
>> start with an IEEE 1275 description of the machine, and extend or adapt
>> it as you go.  My problem with that is that we don't have such
>> descriptions for the machines that interest me.  Developing them is a
>> big step that pays no immediate benefits, but blocks the little steps
>> that do pay.  Moreover, without a *real* user of the description, I'd
>> likely develop something that looks like IEEE 1275 to me, but isn't.  If
>> it turns out that IEEE 1275 is not worth it, tough, we already paid for
>> it.
>> 
>> Another way to approach this is to admit we don't know enough and punt
>> the decision until we do.  Start with the beneficial baby steps.  Limit
>> the machine description business to what is required for the baby steps,
>> making a best effort to stay close to IEEE 1275 structurally.  If it
>> turns out that IEEE 1275 is worth it, we do whatever is left to make the
>> descriptions conform to it.
>> 
>> I'm much more comfortable with the second approach.
>
> That's reasonable.  However, once you've taken enough baby steps you
> do want to be careful that you don't end up long term with something
> that's similar enough to 1275 to be confusing, but not similar enough
> to be useful.  So at some point we do want to take a look ahead and
> see how much difference there will be between the qemu-required config
> information and the 1275 dectree.

Agreed.

I think it would help if 1275 experts reviewed the baby steps for
gratuitous deviations from 1275.

[Rest snipped, helpful comments, but I don't have anything interesting
to add...]

Re: [Qemu-devel] [RFC] Machine description as data

[Paul Brook]

> > The machines I care for come with many optional and configurable parts.
> > We select the basic machine type with command line option -M, and
> > configure the rest with more command line options.  I figure we want to
> > keep supporting these options, at least for a while.
> >
> > I believe the best way to deal with that is start with a basic tree
> > selected by -M, then modify it according to the other options.  So,
> > there's a fair amount of configuration tree mutation.
>
> Yeah, you're probably right.  Although, in some cases the amount of
> complex tree mutation can be cut down by thinking about things in the
> right order.  For example if you have a bunch of optional devices,
> rather than adding them one by one (with all the required properties)
> to the skeleton tree, you can instead have the skeleton tree be the
> all-bells-and-whistles variant then delete the subtrees that aren't
> present.  libfdt even has a function to replace subtrees with nops
> instead of eliding them, which means the offsets of other nodes won't
> change.

I'm not so sure this is a vital feature. The current commandline options only 
provide the absolute bare minimum mutation for a basic PC machine, and don't 
even do that particularly well. I'm inclined to say we should punt 
significant machine config modification/generation to an external tool.

Paul

Re: [Qemu-devel] [RFC] Machine description as data

[Markus Armbruster]

Paul Brook <paul-qD8j1LwMmJjtCj0u4l0SBw@public.gmane.org> writes:

>> > The machines I care for come with many optional and configurable parts.
>> > We select the basic machine type with command line option -M, and
>> > configure the rest with more command line options.  I figure we want to
>> > keep supporting these options, at least for a while.
>> >
>> > I believe the best way to deal with that is start with a basic tree
>> > selected by -M, then modify it according to the other options.  So,
>> > there's a fair amount of configuration tree mutation.
>>
>> Yeah, you're probably right.  Although, in some cases the amount of
>> complex tree mutation can be cut down by thinking about things in the
>> right order.  For example if you have a bunch of optional devices,
>> rather than adding them one by one (with all the required properties)
>> to the skeleton tree, you can instead have the skeleton tree be the
>> all-bells-and-whistles variant then delete the subtrees that aren't
>> present.  libfdt even has a function to replace subtrees with nops
>> instead of eliding them, which means the offsets of other nodes won't
>> change.
>
> I'm not so sure this is a vital feature. The current commandline options only 
> provide the absolute bare minimum mutation for a basic PC machine, and don't 
> even do that particularly well. I'm inclined to say we should punt 
> significant machine config modification/generation to an external tool.

I'm not exactly in love with the currrent command line myself.  It's
just that I'm trying to make improvements in modest steps with minimal
disruption.  I'd rather not start with throwing out the command line.

If the need for tree manipulation goes away, we can still ditch the
separate internal tree structure and go all FDT.  My prototype already
has a converter to and from FDTs, to demonstrate that the internal tree
is just as treeish as an FDT.

Re: [coreboot] DTS syntax and DTC patches (was: Re: [Qemu-devel] [RFC] Machine description as data)

[David Gibson]

On Fri, Feb 13, 2009 at 09:07:08AM -0800, ron minnich wrote:
> Here is the sum total of the differences from when we checked it in
> over 2 years ago until now (parser). Our real changes are to
> flattree.c and livetree.c, where we do some ugly by-hand parsing of
> the ids such that pci@1,0 etc. work. I'd love to see a way to bring
> this into the real syntax. I've tried to do as little as possible to
> .y and .l.
> 
> The diff with comments is attached.
> 
> But this brings up a bigger issue and we could use your help.
> 
> OK, what did we do? We implemented the ability to have a sort of
> template. Here is a sample from real use.
> 
> /{
> 	mainboard_vendor = "Artec";
> 	mainboard_name = "DBE62";
> 	cpus { };
> 	apic@0 {
> 		/config/("northbridge/amd/geodelx/apic");
> 	};
> 	domain@0 {
> 		/config/("northbridge/amd/geodelx/domain");
> 		pci@1,0 {
> 			/config/("northbridge/amd/geodelx/pci");
> 			/* Video RAM has to be in 2MB chunks. */
> 			geode_video_mb = "16";
> 		};
> 	etc.
> 
> so what's going on here?
> 
> The config file in most cases is pretty straightforward. It's actually
> just a list of properties with a standard setting for chip control. We
> MUST have this; we don't want hundreds of settings in each mainboard,
> because sometimes a chip fix comes along and we want that to go into
> one chip file, and set the correct value, and have all mainboards get
> the new value next time they are built.
> 
> Let's look at /config/("northbridge/amd/geodelx/pci");
> 
> {
> 	device_operations = "geodelx_mc";
> 
> 	/* Video RAM has to be in 2MB chunks. */
> 	geode_video_mb = "0";
> };
> 
> The device_operations property is processed by flattree and is of no
> importance to you, but it is used in coreboot .h and .c code
> generation. For coreboot use, we have several property names that are
> special.
> 
> Note that we create a property, geode_video_mb, and set it to 0.
> 
> In the mainboard dts, we over-ride this value, and set it to 16.
> 
> These are pretty much the changes and, again, they work. But I'd like
> more, as would our community.
> 
> Right now, we can take a file containing a list of dts properties,
> read them in, and modify them as above. It's not really ideal, and I
> am sure you can already see it could be done better. But what we
> really want is the ability to read in  a dts node (with subnodes,
> etc.) and then elide them in the mainboard file.
> 
> So, for example, we have this subsection of one mainboard:
> 
> 		pci@6{ /* Port 2 */
> 			/config/("southbridge/amd/rs690/pcie.dts");
> 		};
> 		pci@7{ /* Port 3 */
> 			/config/("southbridge/amd/rs690/pcie.dts");
> 		};
> 		pci@12{
> 			/config/("southbridge/amd/sb600/hda.dts");
> 		};
> 		pci@13,0{
> 			/config/("southbridge/amd/sb600/usb.dts");
> 		};
> 		pci@13,1{
> 			/config/("southbridge/amd/sb600/usb.dts");
> 		};
> 		pci@13,2{
> 			/config/("southbridge/amd/sb600/usb.dts");
> 		};
> 
> This is not a bunch of chips, but one chip. It has lots of pci devices
> in it; this one chip is equivalent to a whole mainboard from previous
> years. What we'd really like is the ability to do what my wife calls
> restrict, add, and remove (I don't have these terms just right, it's
> some kind of compiler-speak which is what she does for a living).

Hrm, I see.  So, if we added the ability to list properties multiple
times, with the last definition overriding earlier ones, then I
believe that, along with include files, which are already supported
would accomplish what you have implemented with /config/.  Does that
seem correct?

> Restrict we have; change property values from a default.
> Add is what we'd like: add a node to a tree in some way.
> Remove we would also like: remove a node from a dts we have read in
> via /config/.

Hrm.  Well, this sort of thing is certainly on the cards with the
expression support stuff we had in mind.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

Re: [coreboot] DTS syntax and DTC patches (was: Re: [Qemu-devel] [RFC] Machine description as data)

[ron minnich]

On Thu, Feb 19, 2009 at 6:29 PM, David Gibson <dwg-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org> wrote:

> Hrm, I see.  So, if we added the ability to list properties multiple
> times, with the last definition overriding earlier ones, then I
> believe that, along with include files, which are already supported
> would accomplish what you have implemented with /config/.  Does that
> seem correct?


That ought to do it.

>
>> Restrict we have; change property values from a default.
>> Add is what we'd like: add a node to a tree in some way.
>> Remove we would also like: remove a node from a dts we have read in
>> via /config/.
>
> Hrm.  Well, this sort of thing is certainly on the cards with the
> expression support stuff we had in mind.


Would be just what we need.

Thanks

ron