On Wed, Jan 7, 2009 at 1:35 AM, Corey Osgood <span dir="ltr"><<a href="mailto:corey.osgood@gmail.com">corey.osgood@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Wed, Jan 7, 2009 at 12:45 AM, ron minnich <span dir="ltr"><<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="Ih2E3d">
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Jan 6, 2009 at 11:47 AM, Carl-Daniel Hailfinger<br>
<div><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net" target="_blank">c-d.hailfinger.devel.2006@gmx.net</a>> wrote:<br>
<br>
</div><div>> As long as CAR is active, we don't want the cacheable area (CAR+ROM) to<br>
> be bigger than the cache to prevent cache evictions of CAR contents.</div></blockquote></div><div><br>Ah, that explains the reboots I'm seeing if the lar isn't zero-filled.<br> </div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> That means we can cache the boot block and maybe initram. In that<br>
> situation, having initram directly before the boot block is a huge speed<br>
> benefit.<br>
> Once CAR is no longer active, we immediately want to mark the whole ROM<br>
> and RAM as cacheable to speed up decompression.<br>
<br>
</div>Yes. And you want to have those MTRRs in a state that they'll be<br>
correct even if the OS you boot doesn't touch them.<br>
<br>
One logical place is at the end of initram. I'd like to get the<br>
discussion to some agreement on where this code should be, and then we<br>
can worry about writing the code. Maybe I am missing part of the<br>
discussion but we seem to be going in circles at times :-)</blockquote></div><div><br>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?</div>
</div></blockquote><div><br>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.<br>
<br>Thanks,<br>Corey<br><br>Index: arch/x86/stage1.c<br>===================================================================<br>--- arch/x86/stage1.c (revision 1101)<br>+++ arch/x86/stage1.c (working copy)<br>@@ -332,6 +332,10 @@<br>
/* Provide an easy way to check whether RAM is available. */<br> global_vars()->ram_available = 1;<br> <br>+#ifdef CONFIG_MTRR<br>+ cache_cbmem(MTRR_TYPE_WRBACK);<br>+#endif<br>+<br> // location and size of image.<br>
init_archive(&archive);<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><br>
<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">As for the CAR+ROM area caching, no argument; what I think we're<br>
saying is we may need the ability to control where a LAR file ends up<br>
in ROM so we can limit the cacheable area. Does that make sense?</blockquote></div><div><br>Perfect sense.<br></div></div><br>Thanks,<br><font color="#888888">Corey<br>
</font></blockquote></div><br>