Following up on this - Patrick helped in IRC this evening, and we came to the conclusion that it's probably *not* an MTRR issue, since we figured out the code seems to set MTRRs properly.
We found out after adding an extra MTRR over the flash chip, which did not change anything.
The system boots fairly normally after the slowdowns, and appears to work normally. It sets three MTRRs further in the bootup process:
reg00: base=0x00000000 ( 0MB), size=32768MB: write-back, count=1 reg01: base=0x800000000 (32768MB), size= 512MB: write-back, count=1 reg02: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
Any thoughts on something else I should look at to debug this?
Thanks, Ward.
On Sun, Jul 19, 2009 at 09:23:21PM -0400, Ward Vandewege wrote:
Hi all,
I'm working on a fam10 tree for supermicro h8dmr. I'm using CBFS.
It boots, but I'm struggling with some extreme slowness during boot. In particular, the memset function in src/lib/memset.c takes *minutes* to clear 1.2MB of ram. A little further CBFS does a memcpy which takes another 20 or 30 seconds:
Stage: load fallback/coreboot_ram @ 2097152/1245184 bytes, enter @ 200000
....LOOOOOONG pause....
Stage: after memset on-stack variables at 00ffbec8 and 00ffbed4 cbfs_decompress: algo: 0 cbfs_decompress: uncompressed
....another lengthy pause....
cbfs_decompress: memcpy from 0xffbecc to 0xffbed0 for 0x2d304 bytes done Stage: done loading.
The first, lengthly pause is new; it is apparently caused by something introduced between r4368 and r4440.
The second pause was there already in r4368.
I understand this may have something to do with MTRRs - looking at the logs it seems MTRRs are not set up until well after CBFS has dealt with coreboot_ram.
This box has 32GB of ram, in case that makes a difference.
Any suggestions?
Thanks, Ward.