Re: Intel® FSP External Architecture Specification v2.1 Has Been Released - coreboot

16 May 2019

      Okay will do. Another point would be FSP-M multi core ram training for
example.
I will mark issues with the enhancement flag.
Best Regards, Philipp
On 16.05.19 17:05, Zimmer, Vincent wrote:
...
Of course. Intel is open to feedback.  Near-term perhaps some of the
issues you’ve observed could be posted to
https://github.com/IntelFsp/FSP/issues ?
Vincent
*From:*Zaolin [mailto:zaolin@das-labor.org]
*Sent:* Thursday, May 16, 2019 9:01 AM
*To:* Desimone, Nathaniel L nathaniel.l.desimone@intel.com;
coreboot@coreboot.org
*Subject:* [coreboot] Re: Intel® FSP External Architecture
Specification v2.1 Has Been Released
Hey Nate,
Would it be possible for us to influence future specifications as well.
The community experienced some issues with the overall FSP-S design and
we would like to discuss that with your team.
Best Regards,
Philipp
On 16.05.19 04:36, Desimone, Nathaniel L wrote:
Hi Everyone,

We are pleased to announce that the FSP External Architecture
Specification v2.1 has been posted to https://www.intel.com/fsp!

*Highlights*

  * *Dispatch Mode*– A new optional FSP boot mode intended to ease
    integration of FSP with PI spec bootloaders. In dispatch mode,
    FSP-M and FSP-S are containers that expose firmware volumes
    (FVs) directly to the bootloader. The PEIMs in these FVs are
    executed directly in the context of the PEI environment
    provided by the bootloader. In dispatch mode, the
    /FspMemoryInit/(), /FspSiliconInit/(), and /NotifyPhase/()
    API’s are not used. /NotifyPhase/() is replaced by FSP-S
    containing DXE drivers that provide a native implementation of
    equivalent events for each of the /NotifyPhase/() invocations.

    */_Dispatch mode is entirely optional._/* FSP 2.1 is fully
    backwards compatible with FSP 2.0, all of the APIs still work
    the same way. We have no plans to change that. While dispatch
    mode is the biggest new feature, it is also largely not
    relevant for coreboot.

  * *More Robust Error Reporting *– The current FSP 2.0 just
    returns an EFI_STATUS code without any context. If that status
    code is anything other than EFI_SUCCESS, FSP 2.0 gives very
    little visibility in to what specifically may be going wrong.
    FSP 2.1 adds the FSP_ERROR_INFO_HOB, which provides more
    granularity on FSP error data and will aid in the debug of
    error codes returned by FSP.

  * *Improved Graphics Support*– Starting with FSP 2.1, in
    addition to the EFI_PEI_GRAPHICS_INFO_HOB, FSP will now also
    produce the EFI_PEI_GRAPHICS_DEVICE_INFO_HOB. This enables the
    implementation of a generic graphics driver.

  * *Improved Memory Utilization*– /FspMemoryInit/() will now run
    on top of the existing bootloader stack instead of
    establishing it own stack. his allows the stack memory to be
    reused after /FspMemoryInit/() returns to the bootloader.
    After /FspMemoryInit/(), large amounts of DRAM will be
    available. So FSP will split its stack and global data at this
    point, since the memory pressure is gone.

*Roadmap*

AmberLakeFspBinPkg has been released on
https://github.com/IntelFsp/FSP, which provides the first
implementation of FSP 2.1. This FSP is backward compatible with
Kaby Lake, so there should be a good amount of existing hardware
available for those who are interested in trying FSP 2.1. Looking
forward, our upcoming Ice Lake and Comet Lake platforms will have
FSP 2.1 binaries once they are released.

*Does Anything Need to Change in coreboot?*

For the most part no. There are some new header structure
definitions to bring in. Optionally, coreboot can now report any
data provided by FSP_ERROR_INFO_HOB and a generic graphics driver
can now be written leveraging EFI_PEI_GRAPHICS_DEVICE_INFO_HOB.

_______________________________________________

coreboot mailing list -- coreboot@coreboot.org <mailto:coreboot@coreboot.org>

To unsubscribe send an email to coreboot-leave@coreboot.org <mailto:coreboot-leave@coreboot.org>