On Sun, May 2, 2010 at 9:24 PM, Ed Swierk eswierk@aristanetworks.com wrote:
On Sun, May 2, 2010 at 3:45 PM, Rudolf Marek r.marek@assembler.cz 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