On Thu, Dec 18, 2008 at 9:07 AM, Corey Osgood <[email protected]>wrote:
> On Thu, Dec 18, 2008 at 9:22 AM, Myles Watson <[email protected]> wrote: > >> >> >> On Wed, Dec 17, 2008 at 11:38 PM, Corey Osgood <[email protected]>wrote: >> >>> On Wed, Dec 17, 2008 at 11:04 PM, Corey Osgood >>> <[email protected]>wrote: >>> >>>> On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge <[email protected]> wrote: >>>> >>>>> Corey Osgood wrote: >>>>> > would there be any problem with calling functions to enable mtrrs >>>>> > and the cache (if it's not already) from the end of disable_car()? >>>>> >>>>> None whatsoever. Commit at will. >>>> >>>> >>>> It didn't help, disable_car() already does essentially the same thing; >>>> disable cache, enable mtrrs, re-enable cache. I'm comparing memtest between >>>> the stock bios and coreboot right now, the throughput for the stock bios is >>>> 6122MB/s for L1 cache and 574MB/s for memory. With v2, it's 3265 and 191, >>>> respectively (using ROMCC), with v3 it's 15 and 18. So something's not >>>> right >>>> somewhere. The other thing is that in v2 and v3, the CPU is only running at >>>> 800MHz in memtest, but with the stock BIOS it runs at 1.5GHz, that's >>>> probably the reason for the differing cache throughputs. Anyways, I'm >>>> diving >>>> into both v2 and v3 and trying to track down why this is running so slowly. >>>> >>> >>> <insert happy dance here> >>> >>> From the currently-running memtest86 on coreboot-v3: >>> L1 Cache: 128K 3265 MB/s >>> Memory : 480M 240 MB/s >> >> >> Congratulations! >> >> >>> >>> That's right, faster then v2 :) I've managed to coerce the northbridge >>> into running the memory at 200MHz (DDR400) without locking up the system >>> like it does in v2, and also to use 1GB of ram, which the fuctory BIOS only >>> sees as 512MB, and v2 for some reason trips over. However, it's a mixed >>> blessing, even though memtest86 now runs at an acceptable speed, coreboot is >>> still running fairly slowly. I'm attaching a patch that brings over mtrr.c >>> from v2 and hacks it to work with v3, but no sign-off because IMO it's not >>> ready to be committed. I'll try booting a FILO payload and a kernel >>> tomorrow, but right now it's time for some sleep. >>> >> >> I know it takes a while to try new things, but have you tried a different >> debug level. Switching Serengeti from BIOS_SPEW to BIOS_INFO cuts boot time >> by about 10x. I'm interested if that's true for you too. >> > > Still running with no errors, 9 hours later :) I dropped the debug level > from SPEW to DEBUG and it helped greatly, it seems for some reason that v3 > takes longer to print messages then v2 did. Also, disabling the console log > buffer seems to have shaved a little time off, but I couldn't say for sure. > It's possible that that's because printk is running out of the ROM. There have been some discussions on the list about that. Thanks, Myles
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
