Intel FSP Firmware Volume content


Marvin Häuser <Marvin.Haeuser@...>
 

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


Yao, Jiewen
 

HI Marvin
I found you mention: “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.”

I would like to point out that, this is an undefined behavior. It might or might not work, depending on each PEIM module.

If the PEIM does not have FSP dependency, you may extract it and put to host boot loader.
If the PEIM has FSP dependency, such as FSP global information, you might get incorrect initialization or even system hang, if you put it to host boot loader directly.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Marvin H?user
Sent: Sunday, July 31, 2016 10:48 AM
To: edk2-devel@lists.01.org
Cc: rafaelrodrigues.machado@gmail.com
Subject: Re: [edk2] Intel FSP Firmware Volume content

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<mailto:rafaelrodrigues.machado@gmail.com>>; Marvin H?user
<Marvin.Haeuser@outlook.com<mailto:Marvin.Haeuser@outlook.com>>; edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com<mailto:jiewen.yao@intel.com>>; Mudusuru, Giri P
<giri.p.mudusuru@intel.com<mailto: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<mailto:Marvin.Haeuser@outlook.com>>;
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Yao, Jiewen <jiewen.yao@intel.com<mailto: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<mailto: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<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel