Re: [coreboot] Maintain boot order for multiple EFI based OS

[Martin Roth]

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,   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:[e-mail]]
> Sent: Friday, March 24, 2017 9:13 PM
> To: Rajasekaran, Sibi 
> Cc: Matt DeVillier ; coreboot ; Zoran Stojsavljevic 
> 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,   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:[e-mail]]
> > Sent: Friday, March 24, 2017 2:23 PM
> > To: Rajasekaran, Sibi 
> > Cc: Zoran Stojsavljevic ; coreboot
> >
> > Subject: Re: [coreboot] Maintain boot order for multiple EFI based OS
> >
> > On Fri, Mar 24, 2017 at 6:26 PM,  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.