[coreboot] More v3 questions/issues

[Myles Watson]

On Thu, Dec 18, 2008 at 9:07 AM, Corey Osgood <corey.osgood at gmail.com>wrote:

> 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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20081218/2456768f/attachment.html>