I haven't looked at it, but it's entirely possible (probable?) that rangeley and the wasn't updated to support the MRC cache outside of cbfs when that option was added. I'd try unselecting the "Use MRC Cache in FMAP" option.
Martin On Mon, Mar 27, 2017 at 7:03 AM, <[email protected]> wrote: > Yes. I have selected "Use MRC Cache in FMAP" in my config and yes I am > working from upstream coreboot. > > The console log specifies MRC cache not present. > <snip> > FMAP: base = ff000000 size = 1000000 #areas = 3 > find_current_mrc_cache: could not find fast boot cache area > FSP MRC cache not present. > > Thanks, > Sibi > > -----Original Message----- > From: Martin Roth [mailto:[email protected]] > Sent: Friday, March 24, 2017 9:13 PM > To: Rajasekaran, Sibi <[email protected]> > Cc: Matt DeVillier <[email protected]>; coreboot > <[email protected]>; Zoran Stojsavljevic <[email protected]> > Subject: Re: [coreboot] Maintain boot order for multiple EFI based OS > > As I recall, the rangeley FSP actually *REQUIRES* the mrc cache. Not having > it would be a definite problem. > > Did you select "Use MRC Cache in FMAP"? If you did, that puts it outside of > cbfs, so it wouldn't show up in that list. > > Are you working from upstream coreboot, or a tree from somewhere else? > > Martin > > On Fri, Mar 24, 2017 at 7:00 AM, <[email protected]> wrote: >> Dell - Internal Use - Confidential >> >> Hi Matt, >> >> Thanks for the prompt response. >> >> I am using Rangeley FSP in my coreboot environment and I don’t see mrc >> cache in the coreboot region even though I chose to use MRC Cache in the >> config. >> >> Performing operation on 'COREBOOT' region... >> >> Name Offset Type Size >> >> cbfs master header 0x0 cbfs header 32 >> >> fallback/romstage 0x80 stage 27612 >> >> cpu_microcode_blob.bin 0x6cc0 microcode 167936 >> >> fallback/ramstage 0x2fd40 stage 121204 >> >> config 0x4d700 raw 539 >> >> revision 0x4d980 raw 588 >> >> cmos_layout.bin 0x4dc40 cmos_layout 1320 >> >> fallback/dsdt.aml 0x4e1c0 raw 8074 >> >> fallback/payload 0x501c0 payload 648600 >> >> img/memtest 0xee7c0 payload 180268 >> >> (empty) 0x11a840 null 415320 >> >> fsp.bin 0x17fec0 fsp 389120 >> >> (empty) 0x1def00 null 132504 >> >> bootblock 0x1ff4c0 bootblock 2560 >> >> >> >> I had built the tianocore long before(may be 6 months back) and I am >> pretty sure I chose release payload. >> >> >> >> Thanks, >> >> Sibi >> >> From: Matt DeVillier [mailto:[email protected]] >> Sent: Friday, March 24, 2017 2:23 PM >> To: Rajasekaran, Sibi <[email protected]> >> Cc: Zoran Stojsavljevic <[email protected]>; coreboot >> <[email protected]> >> Subject: Re: [coreboot] Maintain boot order for multiple EFI based OS >> >> >> >> >> >> >> >> On Fri, Mar 24, 2017 at 6:26 PM, <[email protected]> wrote: >> >> >> >> For your question, takes around 26 seconds from power On till >> Tianocore execute completion. Looking at reducing this boot time. >> >> >> >> >> >> Sibi, if you're not using mrc cache for RAM training, that's likely >> contributing 10s or so at least. Have you enabled coreboot timestamps >> and used cbmem to examine time to payload execute? Also, building >> Tianocore in debug (vs release) mode adds a bit of time as well due to >> the volume of serial output. I use coreboot + Tianocore on Baytrail >> N28xx/29xx (though not with FSP) and normal boot (after RAM training) >> with a release payload is on the order of 2s, with coreboot taking about >> 6-700ms of that. >> >> >> -- >> coreboot mailing list: [email protected] >> https://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: [email protected] https://www.coreboot.org/mailman/listinfo/coreboot
