[coreboot] v3 stage2 running from flash

[Corey Osgood]

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?

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/e3c551f7/attachment.html>