[coreboot] IORESOURCE_UMA_FB question
kyosti.malkki at gmail.com
Wed Mar 20 19:54:34 CET 2013
On Wed, 2013-03-20 at 10:30 -0500, Aaron Durbin wrote:
> On Wed, Mar 20, 2013 at 1:10 AM, Kyösti Mälkki <kyosti.malkki at gmail.com> 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 am not sure if you want some regions for SMM/TSEG as un-cacheable or
not. I believe you could use a new type of memory resource:
IORESOURCE_RESERVE | IORESOURCE_CACHEABLE
When programming MTRRs these would merge with any adjacent
ram_resource(), but would be exluced from OS in coreboot table.
But as that variable MTRR routine is so bad, any IORESOURCE_CACHEABLE
resources must be added in order and they must not overlap.
> > 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) ?
There may be issues with granularity of TOLM and UMA/framebuffer
registers so you do not get to select the optimal base for UMA and avoid
use of un-cacheable MTRR hole. For AMD there are some hardware straps
involved in setting UMA/frame-buffer base and I think the decision on
TOLM is done in vendorcode.
> > 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.
Use of IGNORE_MTRR allows you to place a resource within a previously
added ram_resource(), that was used for bad_ram_resource() for
sandybridge. You could get rid of that if variable MTRR routines were
improved to split and merge regions the same way coreboot table does.
As for UMA_FB, I think renaming would be in order but I believe the need
to carve out un-cacheable hole remains -- the base of un-cacheable
region remains to be sub-optimal for some cases. Of course, if the
region is un-cacheable by other rule already, this would not use
More information about the coreboot