qemu-devel
[Top][All Lists]
Advanced

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

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


From: Markus Armbruster
Subject: Re: [Qemu-devel] [RFC] Machine description as data
Date: Thu, 12 Feb 2009 19:29:12 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)

"M. Warner Losh" <address@hidden> writes:

> <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.

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.

[...]




reply via email to

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