Re: [coreboot] IORESOURCE_UMA_FB question

[Kyösti Mälkki]

On Tue, 2013-03-19 at 23:16 -0500, Aaron Durbin wrote:
> Hi corebooters,
>
> I'm trying to understand the reason for the existence of
> IORESOURCE_UMA_FB. Is this to allow one to carve out an uncacheable
> MTRR region for the UMA framebuffer? If so, why was that ram added as
> cacheable to begin with?
>
> Thanks for the help. Full disclosure: I'd like to get rid of it and
> handle these concepts in a different manner.
>
> -Aaron

Hi Aaron

Reasons are in the poor implementation of variable MTRRs and choice of
defined IORESOURCE flags.

Variable MTRR routine causes excessive use of MTRRs when the cacheable
resources do not add to powers of 2. Try describing 3 GiB - 128 MiB
cacheable memory, and current variable MTRR routines might use 5 MTRRs
for that (2048+1024+512+256+128 MiB).

I did quite a few changes on this topic last summer to fix issues with
AMD boards with 4GB or more RAM. I believe I received enough change
resistance to not touch MTRR further.

Also see: http://review.coreboot.org/#/c/1431

Kyösti

IORESOURCE_UMA_FB question

[Aaron Durbin]

On Wed, Mar 20, 2013 at 1:10 AM, Kyösti Mälkki  wrote:
> On Tue, 2013-03-19 at 23:16 -0500, Aaron Durbin wrote:
> > Hi corebooters,
> >
> > I'm trying to understand the reason for the existence of
> > IORESOURCE_UMA_FB. Is this to allow one to carve out an uncacheable
> > MTRR region for the UMA framebuffer? If so, why was that ram added as
> > cacheable to begin with?
> >
> > Thanks for the help. Full disclosure: I'd like to get rid of it and
> > handle these concepts in a different manner.
> >
> > -Aaron
>
> Hi Aaron
>
> Reasons are in the poor implementation of variable MTRRs and choice of
> defined IORESOURCE flags.
>
> Variable MTRR routine causes excessive use of MTRRs when the cacheable
> resources do not add to powers of 2. Try describing 3 GiB - 128 MiB
> cacheable memory, and current variable MTRR routines might use 5 MTRRs
> for that (2048+1024+512+256+128 MiB).

Understood. That 128MiB aligned UMA area met the 64MiB alignment
minimum in the current code which led to sub-optimal variable MTRR
usage.  If I understand correctly, the only way for this scheme to
work is to include 1 large resource as IORESOURCE_CACHEABLE and have a
smaller IORESOURCE_UMA_FB resource. Correct?
> I did quite a few changes on this topic last summer to fix issues with
> AMD boards with 4GB or more RAM. I believe I received enough change
> resistance to not touch MTRR further.

I'm not sure what 4GiB or more of RAM has to do w/ the non-optimal
variable MTRR usage. However, I've run into this very issue recently
(use too many MTRRs). Why wasn't a more suitable IO hole used? i.e.
largest memory address below 4GiB is 2^N + UMA memory size. Were you
then getting bit on the upper end (cacheable area above 4GiB) ?
> Also see: http://review.coreboot.org/#/c/1431

Thanks for the context. I'm looking into removing
IORESOURCE_IGNORE_MTRR as that is the wrong layer to deal with OS
reserved address space. However, I wanted to properly handle the
UMA_FB type as well. Longer term, I think we can get rid of UMA_FB
too, but that will require a smarter MTRR algorithm.

Thanks again.

-Aaron