On Sun, May 2, 2010 at 9:24 PM, Ed Swierk <[email protected]> wrote: > On Sun, May 2, 2010 at 3:45 PM, Rudolf Marek <[email protected]> wrote: >> I re-checked and it was OK, we do have an early function with same name which >> takes bytes parameters (mtrr-early.c). So this is not the case. I >> investigated >> MTRRs bit more. > > I noticed that too. Perhaps we should rename the early version to > something like early_set_var_mtrr() to avoid confusion? >
That would be good. >> The RAM init on AMD does not use the varmtrr0 and varmtrr1 the reason is >> that it >> thinks the first is used for 0-RAMBASE second for ROM caching. >> >> I also changed the XIP MTRR setup to cache whole ROM with the MTRR. I think >> it >> is OK to do it this way... >> >> After the code goes to the post_cache_as_ram.c it sets up an mtrr for the >> coreboot_ram as 0-RAMTOP. Maybe we can go with a big mtrr 0-TOM and create >> UCs >> for VGA.... > > Would we also need to carve out an uncached space for any MMIO BARs > that are used during early setup? > TOM will have the hole already handled and additional memory would be hoisted. Marc -- http://se-eng.com -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
