[LinuxBIOS] MC struct

ron minnich rminnich at gmail.com
Wed Jun 13 06:37:27 CEST 2007


On 6/12/07, ron minnich <rminnich at gmail.com> wrote:
> On 6/7/07, Peter Stuge <stuge-linuxbios at cdy.org> wrote:
>
>
> >
> > A device tree (not list) in code that
> > * is seeded by the mainboard dts, which lists all devices
> > * has device options set from defaults in device dts
> > * has device option overrides from mainboard dts
>
> I have this almost done, just FYI.


it seems to work, but the error checking is incomplete.

But you can have something like this:

/{
                        north{
                                /config/("northbridge/intel/i440bxemulation");
                        };
};

The /config/ keyword (there has to be a better way to do keywords?) means:
suck in northbridge/intel/i440bxemulation/dts.
That file has a list of properties, well, currently only one:
 { dram = "no"; };

The "no" value for the dram property will provide a reasonable default
if the dram property is not spec'ed. A mainboard value can override
it. You probably want a number there.

The dtc generates the struct as described by the
northbridge/intel/i440bxemulation/dts file:
struct  north {
        u32 dram;
}; /*north*/
(i.e. this struct generation came ENTIRELY from the chip dts, and was
emitted by the device tree compiler (dtc))

and, as it generates the initializations, you see this:
struct  north {
        .dram = {0|(0x6e<<24)|(0x6f<<16)|(0x00<<8)},
}; /*north*/

i.e. you only get u32's at present and, until we're sure we need
something else, that's all you get. I hope people aren't going to
start asking for types ...

So you can spec that a chip dts is to be used; that chip dts will
cause a struct to be generated; the struct members in there can have a
default value, set for that chip; and, the defaults can be over-ridden
by mainboard settings.

Pretty much what we said we wanted, I think. But your Kconfig request
is not in there, as supporting it will require:
1) dtc pass
2) kconfig pass
3) dtc pass again

I think.

The changes are backwards-compatible; current qemu target builds just fine.

Peter, is this it?

I can generate a patch if people want to look at the code. I admit it
is rough, but gives us a starting point.

ron




More information about the coreboot mailing list