[coreboot] fam10/h8dmr: extreme slowness in CBFS memset / memcpy
ward at gnu.org
Tue Jul 21 03:09:17 CEST 2009
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
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?
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
> This box has 32GB of ram, in case that makes a difference.
> Any suggestions?
Ward Vandewege <ward at gnu.org>
More information about the coreboot