Re: Intel® FSP External Architecture Specification v2.1 Has Been Released
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>
participants (1)
-
Zaolin