On Wed, Mar 20, 2013 at 1:10 AM, Kyösti Mälkki <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
