[coreboot] [v3] r1164 - in coreboot-v3: arch/x86 arch/x86/via mainboard/jetway

[Carl-Daniel Hailfinger]

On 15.04.2009 00:26, Corey Osgood wrote:
> On Tue, Apr 14, 2009 at 6:16 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> wrote:
>
>   
>> On 14.04.2009 17:41, svn at coreboot.org wrote:
>>     
>>> Author: cozzie
>>> Date: 2009-04-14 17:41:33 +0200 (Tue, 14 Apr 2009)
>>> New Revision: 1164
>>>
>>> Modified:
>>>    coreboot-v3/arch/x86/pirq_routing.c
>>>    coreboot-v3/arch/x86/via/stage0.S
>>>    coreboot-v3/mainboard/jetway/Kconfig
>>> Log:
>>> Enable caching for Via C7 CPUs, and also improve readability. Tested on
>>>       
>> hardware
>>     
>>> and seems to be working.
>>>
>>> Signed-off-by: Corey Osgood <corey.osgood at gmail.com>
>>> Acked-by: Myles Watson <mylesgw at gmail.com>
>>>
>>>       
>> Sorry I didn't see the patch earlier.
>>
>> If (CONFIG_COREBOOT_ROMSIZE_KB + CONFIG_CARSIZE) exceeds L2 cache size,
>> CAR will explode. I bet your test conditions didn't trigger that condition.
>> You can calculate allowed ROM cache size, though. CPUID can tell you L2
>> size and from that you subtract CARSIZE, then round down to the next
>> power of two.
>>     
>
>
> Alright, I'll fix it tonight. The bootblock and stage0/1 code should always
> be at the start of the ROM, right?

The bootblock (stage0+1) will always be at the end of the ROM. Initram
is usually at the start of the ROM because the LAR utility always uses
the lowest possible address for adding a LAR member, but that can be
changed.

For the LAR placement strategy change, look at
util/lar/stream.c:lar_add_entry(), specifically the call to
lar_empty_offset(). You'll want to create a variant
lar_last_empty_offset_for_size() or somesuch.


> Is there a chance of explosion if
> stage0+1 is larger then the cached size?
>   

No, just slowness for some code paths.
What you really want for fast bootup is having initram directly before
the bootblock at the end (highest address) of the ROM and both of them
cached as one contiguous block. That gives you lightning fast startup
until MTRRs are reset (but then RAM is available and you can cache the
whole ROM).


>> It seems some unrelated PIRQ change snuck in this changeset.
>>
>>     
>
> Sorry about that, I forgot my svn password and I guess in the process I
> forgot to single out that file when I figured it out. The Kconfig change is
> needed to build the Jetway target, so I think it should stay, and the
> pirq_routing.c is simply clarification, the file does actually reside in
> include/arch/x86/. If anyone wants the latter revert the latter, feel free.
>   

OK with me, I just wanted to clarify.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/