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

ron minnich rminnich at gmail.com
Fri Feb 13 18:07:08 CET 2009

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 at 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 at 0 {
	domain at 0 {
		pci at 1,0 {
			/* Video RAM has to be in 2MB chunks. */
			geode_video_mb = "16";

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

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 at 6{ /* Port 2 */
		pci at 7{ /* Port 3 */
		pci at 12{
		pci at 13,0{
		pci at 13,1{
		pci at 13,2{

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.

	mainboard_vendor = "AMD";
	mainboard_name = "dbm690t";
	cpus { };
	apic at 0 {
	domain at 0 /config/("northbridge/amd/k8/domain") = {
                pci at 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 at 1,0{disable;};
                     /* don't even put port 7 in the tree -- what is a
remove going to look like?. Also new. */
                     - pcie at 5,0;
                      /* add the superio; default values are
acceptable. Also new. We can't add nodes. */
                     pnp at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtcdiff
Type: application/octet-stream
Size: 2999 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090213/49c31406/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtc-diff.l
Type: application/octet-stream
Size: 2222 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090213/49c31406/attachment-0001.obj>

More information about the coreboot mailing list