[coreboot] Resource Allocation discussion

Myles Watson mylesgw at gmail.com
Tue Dec 2 14:57:40 CET 2008



> -----Original Message-----
> From: Marc Jones [mailto:marcj303 at gmail.com]
> Sent: Monday, December 01, 2008 10:42 PM
> To: Myles Watson
> Cc: Coreboot
> Subject: Re: [coreboot] Resource Allocation discussion
> 
> Hi Myles,
> I will try to help..... :)
> 
> On Mon, Dec 1, 2008 at 2:37 PM, Myles Watson <mylesgw at gmail.com> wrote:
> > The resource patches I submitted work fairly well, but still need a
> little
> > help.
> >
> > I haven't touched subtractively decoded resources, and that's where the
> > breakage is right now.
> >
> > Questions:
> > - Who should have a resource that moves all other IO resources above
> 0x400
> > or 0x1000?
> 
> What do you mean? By definition the subtractive port takes all
> unclaimed cycles. There should be a LPC or ISA bridge in the
> southbridge that forwards cycles that the legacy southbridge devices
> don't claim.

Sorry.  I wasn't clear enough again.  What I meant was something more like:

Since the resource allocation algorithm can't avoid resources that it
doesn't know about, who decides if the subtractive area to avoid is
0x0-0x400, 0x0-0x1000, or some other range?  If I declare some device to
hold these addresses so that no other resource ends up there, should it be
subtractive?  I'm inclined to put it in the domain or in the SuperIO.

> > - Is one needed if subtractive resources are implemented correctly?
> 
> I don't think so. You might need to track the the subtractive bit in
> the bridges so you don't try to add those resources to the bridge BAR.

Right now subtractive resources are just skipped altogether.

> > - Who is responsible for setting the top of the address range?
> 
> This should be set per mainboard but the chipset will probably have
> them most influence on the value.

Are you aware of mainboards with the same chipset that have different
DEVICE_MEM_HIGH?

> #define DEVICE_MEM_HIGH 0xFEBFFFFFUL is probably ok for most systems
> but an easy way to override it would be good.

I'd like this to be in the domain as well.  If we set the domain's resource
range to 0x0-0xFEBFFFFF, then nothing will get allocated outside of that.

> >    - From an earlier thread with Carl-Daniel it sounded like there are
> fixed
> > locations for APICs that need to be avoided.  Where should these be
> avoided?
> 
> Yes, APICs are generally at FEC00000(IO) and FEE00000(local).

So these should be created in the domain?

Thanks,
Myles





More information about the coreboot mailing list