On Tue, Jan 6, 2009 at 12:31 PM, Marc Jones
<marcj303@gmail.com> wrote:
On Tue, Jan 6, 2009 at 7:39 AM, Myles Watson <
mylesgw@gmail.com> wrote:
> On Tue, Jan 6, 2009 at 4:52 AM, Corey Osgood <
corey.osgood@gmail.com> wrote:
>> Tested and working on hardware :D
>
> Great job!
>
> As I read your patch I wondered if there's a good reason to disable
> caching. Can we just take out the #ifdefs? Or maybe make it an
> #ifndef DONT_CACHE_AND_RUN_REAL_SLOW_ON_C7? :)
>
> Acked-by: Myles Watson <
mylesgw@gmail.com>
>
> Thanks,
> Myles
Ooops, this never got committed, figured that out very quickly last night. r1164
I think that we need to examine this for all the CPUs. In a legacy
only need prior to memory setup. That is not the case for coreboot
because we have the XIP printk and LAR code. We should use one MTRR
for caching the ROM. So MTRR for ROM caching is setup by the CPU
specific CAR code and then later in normal MTRR setup we add an MTRR
that will support XIP for the rest of POST and payload loading. There
are two minor drawbacks to doing this.
1. You use an MTRR that could be used by the OS. No big deal, there
are more than enough MTRRs for every confguration I can think of.
2. You might use cache space for ROM code that will fetch slowly and
might only run once. This is no longer a problem with large L2 and L3
caches. Even on Geode it should be ok. Also, the ROM shouldn't be
accessed once the OS loads.
The last thing is if the ROM should be cached read-only or
write-through. If set RO, flashrom will need to be MTRR aware and set
it to WT when writing ROMs.
Currently, at least with C7 CAR and I think some others, CAR uses the first variable MTRR, MTRR 0, and the ROM is cached at MTRR 1 by stage 0. Once the MTRR setup code runs, the ROM cache is killed off, and things slow down. I see a few solutions:
1. Give ROM caching priority, MTRR code first sets up a WB MTRR 0 to cache the ROM, then clears out MTRR 1-8, and sets up MTRRs for RAM. This way the ROM is never not cached, and the code should be easier to write.
2. Give memory priority, MTRR code clears all variable MTRRs, sets up memory, and then does the ROM cache as the very last thing. If memory eats up all the MTRRs, oh well, the rest of the boot will be slow. Any calls to XIP functions between the time MTRRs are cleared and the time the ROM MTRR is set up will be slow.
3. Give memory priority, but reserve the last MTRR for the ROM cache. At that point you might as well go for 1.