[coreboot] [PATCH] Warn if we run out of MTRRs
c-d.hailfinger.devel.2006 at gmx.net
Thu Feb 12 01:19:49 CET 2009
On 12.02.2009 00:19, Stefan Reinauer wrote:
> On 11.02.2009 18:11 Uhr, ron minnich wrote:
>> I agree it's an emergency however :-)
>> 10 minute boot times! call the hospital, the computer is sick!
> I did a very similar patch two days ago. Sorry this is not against
> Carl-Daniel's latest changes, but I thought I'd put it out for
> discussion first.
No problem. Two patches are better than no patch.
> There's one case when MTRR setup goes severely wrong, and that is all
> those boards with UMA graphics onboard. That's all the 945GM boards, the
> 690 boards, some VIA boards, etc etc.
> What the patch does is create a special case for UMA. It checks whether
> there's an MTRR hole, and if there is none, it creates one for the UMA area.
> With the patch applied my test board went down from 8 used MTRRs to 2
> (one for RAM and one for UMA) and at the same time the complete RAM is
> I remember there was a suggestion for a complete "optimal" MTRR setup
> algorithm that attempts to always do the right thing with major
> complexity. This patch is much simpler. It takes the most common case
> and fixes it without trying to be perfect. So I think this is a good
> solution for v2, and maybe someone wants to do the perfect thing for v3
> at some point.
> Comments? Acks?
The patch has three parts:
- Reduction of BIOS MTRRs from 8 to 6. Looks fine to me. I actually have
that in my tree as well. Ack.
- Verbose complaining if we run out of MTRRs. A variant of this has
already been committed, but we may want to use your detailed message. Good.
- UMA MTRR hole special case.
AFAICS your algorithm won't help for any board with uncached SMM memory
before UMA. One example that comes to mind is the VIA board where the
problems were noticed first. Sorry.
I'll look into creating a simplified version of my algorithm which
should be free of special cases and still understandable.
More information about the coreboot