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

[M. Warner Losh]

<address@hidden>
<address@hidden>
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: <address@hidden>
Carl-Daniel Hailfinger <address@hidden> 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 { };
:     address@hidden {
:     };
:     address@hidden {
:         address@hidden,0 { /* MCP55 RAM? */ 
:         };
:         address@hidden,0 {
:             /config/("southbridge/nvidia/mcp55/lpc.dts");
:             address@hidden {

<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