[coreboot] v3 stage2 running from flash

[Corey Osgood]

On Wed, Jan 7, 2009 at 1:35 AM, Corey Osgood <corey.osgood at gmail.com> wrote:

> On Wed, Jan 7, 2009 at 12:45 AM, ron minnich <rminnich at gmail.com> wrote:
>
>> On Tue, Jan 6, 2009 at 11:47 AM, Carl-Daniel Hailfinger
>> <c-d.hailfinger.devel.2006 at gmx.net> wrote:
>>
>> > As long as CAR is active, we don't want the cacheable area (CAR+ROM) to
>> > be bigger than the cache to prevent cache evictions of CAR contents.
>>
>
> Ah, that explains the reboots I'm seeing if the lar isn't zero-filled.
>
>
>>
>> > That means we can cache the boot block and maybe initram. In that
>> > situation, having initram directly before the boot block is a huge speed
>> > benefit.
>> > Once CAR is no longer active, we immediately want to mark the whole ROM
>> > and RAM as cacheable to speed up decompression.
>>
>> Yes. And you want to have those MTRRs in a state that they'll be
>> correct even if the OS you boot doesn't touch them.
>>
>> One logical place is at the end of initram. I'd like to get the
>> discussion to some agreement on where this code should be, and then we
>> can worry about writing the code. Maybe I am missing part of the
>> discussion but we seem to be going in circles at times :-)
>
>
> Probably my fault, I've just been skimming through the list the last couple
> months while I was in class, and I head back next week, so I'd like to get
> this running before then ;) Although the end of initram makes sense (I was
> going to tuck it into disable_car()), if we only mark the first couple MB of
> ram and all of ROM as cachable there (some safe value that every system
> should have and coreboot will always fit inside) and then mark all of it
> later when we add the ram resources, we eliminate the need for
> chipset-specific code to tell coreboot the ram size twice. Does that make
> sense, or will it just complicate things more?
>

And actually, we already have a config variable and function to do that in
stage1, the following should make it work (this is inside stage1_phase3).
All that would be left would be to teach ram_resource to re-set the mtrrs,
or use the mtrr setup functions I pulled in from v2. The next question
concerns that though, everything I can find suggests that coreboot uses the
range from 0MB-CBMEMK. What happens if/when it hits a reserved range? IE the
range from 768k-1MB which is always reserved on vt8237r, IIRC.

Thanks,
Corey

Index: arch/x86/stage1.c
===================================================================
--- arch/x86/stage1.c    (revision 1101)
+++ arch/x86/stage1.c    (working copy)
@@ -332,6 +332,10 @@
     /* Provide an easy way to check whether RAM is available. */
     global_vars()->ram_available = 1;

+#ifdef CONFIG_MTRR
+    cache_cbmem(MTRR_TYPE_WRBACK);
+#endif
+
     // location and size of image.
     init_archive(&archive);


>
>
> As for the CAR+ROM area caching, no argument; what I think we're
>> saying is we may need the ability to control where a LAR file ends up
>> in ROM so we can limit the cacheable area. Does that make sense?
>
>
> Perfect sense.
>
> Thanks,
> Corey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20090107/2788d2dc/attachment.html>