Re: Intel FSP Firmware Volume content

* Re: Intel FSP Firmware Volume content
       [not found]   ` <4666AEFED60F8E4198B42BB01DCEABDF764A95ED@ORSMSX109.amr.corp.intel.com>
@ 2016-07-31  2:48     ` Marvin Häuser
  2016-07-31  5:51       ` Yao, Jiewen
  0 siblings, 1 reply; 2+ messages in thread
From: Marvin Häuser @ 2016-07-31  2:48 UTC (permalink / raw)
  To: edk2-devel@lists.01.org
  Cc: Mudusuru, Giri P, rafaelrodrigues.machado@gmail.com

Hey Rafael and Giri,

Thanks for your information. I really appreciate your answers and time, though the answers have been quite general.

But I think I finally got the hang of FSP. The following is how I understand it by looking at FSP binaries and IntelFspPkg and by now means a verified explaination:
As Intel FSP is based on the Intel Reference Code, it of course relies on UEFI and UEFI PI concepts. So, one's own SecCore is supposed to handle the reset vector and do anything you want to do with the exception of setting up CAR. When it's time for CAR to be set up, you pass control to FspSecCore, which does its internal checks and other magic...
When you, at a later point in time, call the API to set up the Silicon, FspSecCore starts its own PeiCore (it cannot know about the existing one as it is Boot Loader-independent) and this one executes all modules within the FSP binary, as they are within the FV of FSP's PeiCore. So, in this isolated PeiCore, everything is happening that would be happening on a platform that embeds the Intel Reference Code, from start to end. The Dxe modules seem to be Intel RC modules, that are usually executed in DXE phase but, as FSP is entirely 32-bit anyway, are simply called as part of the isolated PEI phase (probably modded for FSP usage) and a HOB list is built, as it would in 'normal PEI'. FspDxeIpl is actually returning the control back tot he host Boot Loader, returning the HOB list oft he isolated PEI - and as the HOB list is the only thing DXE gets from all stages before, all modules in the FSP bin have served their purpose, just isolated. The HOBs are returned to the host Boot Loader and it is the very same situation, as if it executed the PEIMs itself.

Summary: As far as I can see, FSP is launching an isolated PEI to execute all platform init modules and collect the HOBs.

If one spends a few hours on FSP, I think it wouldn't be too hard to split the binary and integrate its PEIMs into the host Boot Loader directly, so that the isolated PEI would not be needed with UEFI PI-compatible firmware... just that the DXE modules, that FSP ships, will remain modded to be PEIMs.

Thanks again for your time!

Best regards,
Marvin.

> -----Original Message-----
> From: Mudusuru, Giri P [mailto:giri.p.mudusuru@intel.com]
> Sent: Friday, July 8, 2016 9:38 AM
> To: Rafael Machado <rafaelrodrigues.machado@gmail.com>; Marvin H?user
> <Marvin.Haeuser@outlook.com>; edk2-devel@lists.01.org
> Cc: Yao, Jiewen <jiewen.yao@intel.com>; Mudusuru, Giri P
> <giri.p.mudusuru@intel.com>
> Subject: RE: [edk2] Intel FSP Firmware Volume content
> 
> Hi Marvin, Rafael,
> 
> Thank you for your studies on FSP.
> 
> FSP is a self-contained binary. Since the silicon code implementation is based
> on edk2, some modules are redundant like PeiCore, DxeIpl as Rafael
> explained below (Thanks Rafael).
> While it is redundant, it is a small price to make FSP binary pluggable into
> different bootloaders (EDK2, Coreboot etc...)
> 
> Also entire FSP is implemented in PEI phase and DXE code is built in Dual
> mode (DXE and PEI for FSP) which is why you see *DxeFsp
> 
> Hope this clarifies your questions
> 
> Thanks and Regards,
> -Giri
> 
> > -----Original Message-----
> > From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> > Rafael Machado
> > Sent: Thursday, July 7, 2016 4:31 AM
> > To: Marvin H?user <Marvin.Haeuser@outlook.com>;
> > edk2-devel@lists.01.org
> > Cc: Yao, Jiewen <jiewen.yao@intel.com>
> > Subject: Re: [edk2] Intel FSP Firmware Volume content
> >
> > Hi Marvin
> >
> > I'm also starting my studies on FSP, but I think I can help with at
> > least one of the questions.
> > About the two Sec cores.
> >
> > The existence of two sec cores represents what is called "FSP Normal Boot"
> > There is the main sec core, and another sec core that is placed inside
> > the FspInitPei. They communicate to each other so the needed
> > information is passed correctly.
> >
> > Each sec core has it's responsibilities, so they don't do the same thing.
> >
> > Hope this can help you to find more information.
> >
> > Thanks and Regards
> > Rafael R. Machado
> >
> >
> >
> > Em qua, 6 de jul de 2016 às 20:40, Marvin H?user
> > <Marvin.Haeuser@outlook.com>
> > escreveu:
> >
> > > Dear EDK2 community members,
> > >
> > > Recently, I have gained interest in the Intel FSP and have been
> > > reading the Intel documents regarding its design and integration with
> EDK2.
> > > In the white paper 'A Tour Beyond BIOS Using the Intel(r) Firmware
> > > Support Package with the EFI Developer Kit II', the chapter 'FSP Wrapper
> Boot Flow'
> > > mentions different ways of how SecCore and following can interact with
> FSP.
> > > This, in my opinion, implies that SecCore is present in source-form
> > > (likely IntelFspWrapperPkg/FspWrapperSecCore), while the actual
> > > silicon initialization is of course within the FSP binary. This is
> > > how I understood it and thought it made sense.
> > > However, when I opened a few of the FSP Firmware Volume files, I
> > > discovered that it did not only have the FSP header and
> > > initialization PEIMs/drivers, but also SecCore, PeiCore and
> > > FspDxeIpl embedded. For what reason are these generic modules
> > > embedded? Until discovering them within the image, I had assumed
> these would be provided by the consumer package.
> > > To better understand the creation and consumption of Intel FSP, I
> > > have looked at Quark and Braswell Reference Codes provided within
> > > the edk2-platforms tree. BraswellPlatformPkg, which consumes
> > > BSWFSP.fd that
> > has
> > > SecCore embedded, also consumes FspWrapperSecCore (seen here:
> > > https://github.com/tianocore/edk2-platforms/blob/pentium-celeron-n-
> > udk2015/BraswellPlatformPkg/PlatformPkg.fdf#L387)
> > > from the source tree. If I am not mistaken, building it would end up
> > > having SecCore duplicated - once as part of the FSP volume (binary)
> > > and once within the FVRECOVERY volume (source). As SecCore includes
> > > the Reset Vector, wouldn't one of the two be obsolete as it would never
> be invoked?
> > > The same applies to PeiCore and a few other generic modules which
> > > are part oft he chain.
> > >
> > > Furthermore, a couple of modules that have 'Dxe' in their name are
> > > declared as PEI module in their FFS header, for example
> > > 'PchInitDxeFsp'. I have observed this in all FSP version I have
> > > looked at, including Braswell, Broadwell and Ivy Bridge. Is there
> > > any special reason for that? Is it because the FSP initialization
> > > code is what has them loaded and called, so it doesn't matter?
> > >
> > > Please forgive me for my ignorance and thank you in advance for your
> time!
> > >
> > > Best regards,
> > > Marvin.
> > > _______________________________________________
> > > edk2-devel mailing list
> > > edk2-devel@lists.01.org
> > > https://lists.01.org/mailman/listinfo/edk2-devel
> > >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel

^ permalink raw reply	[flat|nested] 2+ messages in thread