<div class="gmail_quote">On Sat, Jan 24, 2009 at 2:58 PM, Stefan Reinauer <span dir="ltr"><<a href="mailto:stepan@coresystems.de">stepan@coresystems.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Carl-Daniel Hailfinger wrote:<br>
> Example:<br>
> We want to cache 0MB - (2G-64M-64k).<br>
><br>
</div>Where do the 64k come from?<br>
<div class="Ih2E3d">> Current setup:<br>
> reg00: base=0x00000000 (   0MB), size=1024MB: write-back, count=1<br>
> reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1<br>
> reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1<br>
> reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1<br>
> reg04: base=0x78000000 (1920MB), size=  32MB: write-back, count=1<br>
> reg05: base=0x7a000000 (1952MB), size=  16MB: write-back, count=1<br>
> reg06: base=0x7b000000 (1968MB), size=   8MB: write-back, count=1<br>
> reg07: base=0x7b800000 (1976MB), size=   4MB: write-back, count=1<br>
> --Here we run out of MTRRs, additionally needed MTRRs follow--<br>
><br>
</div>And actually we should have run out of MTRRs 2 steps earlier. The BIOS<br>
is only allowed to grab 6 of the 8 possible MTRRs. The other two have to<br>
be left free to use by the operating system. There is code in coreboot<br>
to enforce this, but it's #if 0'ed.<br>
<div class="Ih2E3d">> We could achieve the same effect with a subtractive setup:<br>
> reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1<br>
> reg01: base=0x7c000000 (1984MB), size=64MB: uncached, count=1<br>
> reg02: base=0x7bff0000 (1983MB), size=64kB: uncached, count=1<br>
><br>
> However, a subtractive setup is not always more efficient.<br>
</div>Is it not? It sounds like at least if we have 2^x bytes of memory and<br>
subtract a small chunk or two, we would be quite well off with it.<br>
<br>
I wonder... the subtractive strategy you subscribe is mentioned in<br>
mtrr.c too and the comment claims it is implemented. But it very much<br>
seems it is not.<br>
<div class="Ih2E3d">> That means we<br>
> have to select the best setup type. I devised a slightly tricky<br>
> algorithm to do that:<br>
> 1. Check if there are multiple disjoint cached areas in a given<br>
> power-of-two sized area.<br>
> 1a. If no, go to step 2<br>
> 1b. If yes, stop here. Need advanced setup not described here.<br>
><br>
</div>please describe ;)<br>
<div class="Ih2E3d">> 2. additive_count=bitcount(top_cached_addr+1)<br>
> 3.<br>
> subtractive_count=bitcount(rounduptonextpowerof2(top_cached_addr)-(top_cached_addr+1))<br>
> 4. if (additive_count>subtractive_count) go to subtractive_method else<br>
> go to additive_method<br>
><br>
</div>Yes, sounds good.</blockquote><div><br>I've already been working on it for v3, along with handling the cached flash area. Quick question though, what would happen if, for a few instructions, both MTRR0 and MTRR1 covered the flash area? Also, I've been extremely busy lately and haven't had much time for coreboot, so I won't be offended if someone beats me to fixing this.<br>
<br>-Corey <br></div></div><br>