[coreboot] More v3 questions/issues

[Corey Osgood]

On Thu, Dec 18, 2008 at 9:22 AM, Myles Watson <mylesgw at gmail.com> wrote:

>
>
> On Wed, Dec 17, 2008 at 11:38 PM, Corey Osgood <corey.osgood at gmail.com>wrote:
>
>> On Wed, Dec 17, 2008 at 11:04 PM, Corey Osgood <corey.osgood at gmail.com>wrote:
>>
>>> On Wed, Dec 17, 2008 at 8:55 PM, Peter Stuge <peter at stuge.se> 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.

-Corey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081218/85ad4f24/attachment.html>