[coreboot] Resource allocation

Corey Osgood corey.osgood at gmail.com
Wed Nov 12 18:42:54 CET 2008


On Wed, Nov 12, 2008 at 11:46 AM, Peter Stuge <peter at stuge.se> wrote:

> ron minnich wrote:
> > > Dynamic superio probing only makes any sense to me if it can be used
> > > verbatim on each and every superio
> >
> > yes, but having a single superio device structure in the static
> > tree is what requires dynamic devices. We're not probing.
> > We are actually just creating devices on demand. Those are two
> > different things.
>
> Right. Who knows what should be demanded? I would like the mainboard
> dts to be the source.
>
>
> > Plus, the weird thing on a superio: even if you don't want a
> > function (e.g. serial) it's important to make sure you turn certain
> > pnp functions off in some cases --
> > so you may want that pnp function controlled, even if you do not
> > use it.
>
> Yes, that's why I think all functions of the chip should be listed
> somewhere (superio dts) but the ones that actually are enabled
> somewhere else (mainboard dts)..
>
>
> > Remember the rule: one dts -> one device.
>
> I tend to like one dts -> one chip. But as long as dtses can pull in
> other dtses we both win.
>
>
> ..
> > so we get a new dynamic device for each pnp function.
> >
> > Making one device for each pnp function, we will need one dts for
> > each pnp function. This is very easy to do, although it will be a
> > bit of work. But now is the time to do it if we want to do it. I am
> > not convinced we want to do it.
>
> It will end up being a lot of files, which is a little clumsy. I'd
> like to roll it into one file..
>
> I guess we've gone back and forth on this. I guess dtc is the
> bottleneck because it only deals with one struct per input file?
>
>
> > I'd rather put the effort into getting the k8 to work,
>
> Or GeodeLX, C7, or Core2. There's plenty of unfinished stuff in v3
> now. :) SCNR.


C7 I'll be getting back to ASAP, I've got lots of other things on my plate
right this moment though. It's mostly done, just needs a few more bugs
tracked down and squashed. Also, for some reason, doing early_mtrr_init()
like via epia-cn does in v3 completely breaks booting.

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081112/3d649fef/attachment.html>


More information about the coreboot mailing list