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.