On Wed, Jan 7, 2009 at 1:35 AM, Corey Osgood <[email protected]> wrote:
> On Wed, Jan 7, 2009 at 12:45 AM, ron minnich <[email protected]> wrote: > >> On Tue, Jan 6, 2009 at 11:47 AM, Carl-Daniel Hailfinger >> <[email protected]> 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 >
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
