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:[email protected]]
> *Sent:* Thursday, May 16, 2019 9:01 AM
> *To:* Desimone, Nathaniel L <[email protected]>;
> [email protected]
> *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 -- [email protected] 
> <mailto:[email protected]>
>
>     To unsubscribe send an email to [email protected] 
> <mailto:[email protected]>
>

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to