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] > To unsubscribe send an email to [email protected]
signature.asc
Description: OpenPGP digital signature
_______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
