Am Sonntag, den 02.05.2010, 21:47 -0600 schrieb Marc Jones:
I was just looking at the same thing. I don't like the MTRR manipulation that is happening in post_cache_as_ram.c. Doing 0-TOM is a little tricky if the dimms are different sizes. It is easier to let
It's one MTRR per DIMM, where identically sized DIMMs can be merged (in pairs of two, until merging is done). Actually, as long as there are only power-of-two DIMMs around, it's a matter of knowing the total memory size (in addition to usable memory due to UMA and the like), and counting bits.
Then another MTRR for shared video memory (if configured, and if it's power-of-two sized) and another for 0xa0000-0xc0000.
For 512 + 512 + 128 + 128MB DIMMs and 8MB UMA this gives: 0-1024MB: cached 1024-(1024+256): cached (1024+256-8) - (1024+256): uncached 0xa0000-0xc0000: uncached 0xfff00000-0x10000000: ROM: cached
Contrast this to the current setup: 0x00000-0x80000 cached 0x80000-0xa0000 cached 0xa0000-0xc0000 uncached 0xe0000-0x100000 cached 0x100000-whereever cached (hopefully covering all of RAMBASE..RAMTOP) subset of 0xfff00000-0x10000000 (XIP_ROM): ROM: cached
The latter takes more MTRRs, and we still have to hope that the >1MB MTRR actually covers the whole RAMBASE..RAMTOP area. And we can't simply use RAMBASE and RAMTOP to determine the MTRR, as MTRRs have these nice requirements about power-of-two sizes and being aligned to their size.
that get setup in the RAM stage. Getting the XIP setup correctly for the lzma decompress seems to be an issue. I am not certain what is happening and if we are crossing some boundaries that are causing flushes.
That would most likely mean that the XIP_ROM_SIZE is too small (so XIP_ROM + CAR isn't larger than the available cache). Curiously, the romstage doesn't run slow, only the memcpy/ulzma part.
But it's not that bad: When we decompress, RAM is around, so CAR should already be disabled, and we can cache the entire ROM area and all of RAM.
In addition to fixing the cache, Arne's patch to put the lzma into memory may be the way to go.
I'm not sure we can trust the compiler to always build the code in a way that we can copy it, so I'd prefer that solution to be a work-around until the real issue is solved and then to never reappear.
Patrick