[coreboot] Porting to RS780/SB700 board

[Patrick Georgi]

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