Mariusz Szafrański has uploaded this change for review. ( https://review.coreboot.org/c/coreboot/+/56263 )
Change subject: [RFC] Intel IIO split stack - multidomain approach ......................................................................
[RFC] Intel IIO split stack - multidomain approach
RFC/initial proposal on how to support Intel split IIO architecture in coreboot
Change-Id: I38ac830ee05866a09c5661ec48fab96af8135f44 Signed-off-by: Mariusz Szafranski mariuszx.szafranski@intel.com --- A Documentation/RFC/intel-iio-split-stack.md 1 file changed, 91 insertions(+), 0 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/63/56263/1
diff --git a/Documentation/RFC/intel-iio-split-stack.md b/Documentation/RFC/intel-iio-split-stack.md new file mode 100644 index 0000000..740a64c --- /dev/null +++ b/Documentation/RFC/intel-iio-split-stack.md @@ -0,0 +1,91 @@ += Intel split IIO design support in coreboot + +== Status of this document + +This document is RFC/initial proposal how to implement split IIO in coreboot. +First attempt to support new design is already present in Xeon SP code. +This document is proposal to use another approach to handle new design. +Please fill free to comment, present your valuable opinions and additional ideas. + +== Introduction. What is split IIO? + +IIO - Integrated I/O +The processor Integrated I/O is the next generation I/O offering a very high bandwidth +interface while maintaining software compatibility with existing chipset solutions. + +Let`s describe it in high level and simplified version without going into details. + +In the past Intel`s products there was one root bus (bus 0) coming out "directly" from CPU. +Additional (secondary/subordinate) busses were connected via bridge devices. +Latest Intel`s products (CooperLake SP, SkyLake SP and upcoming) extends above legacy +architecture by introducing additional root busses coming out directly from cpu. +One root bus with all busses and devices connected to it is called "stack". +We have multiple stacks to support in coreboot. + +== split IIO vs. coreboot + +Current coreboot has support for legacy architecture with only one root bus (one stack). +There is a need to extend it to support new design. Due to the split IIO design, programming +of system resources is quite different from past products. In legacy case full IO/MMIO range +was assigned to root bus 0. In new design there is a need to split available resource ranges +between each stack. + +== Current state + +There exists initial implementation of new design in Xeon SP code. But it is not final +nor complete. + +== How to support new design in coreboot? + +* 1. Continue Xeon SP like approach +* 2. Introduce additional virtual root bridge device which will connect CPU to root busses +* 3. Reuse existing domain to encapsulate each stack. (multidomain approach) + +AFAIK first one Xeon SP like code has many implementation difficulties to overcome +and is not "clear" enough solution. + +Previously we have tried to follow second option - added new virtual root bridge device to +connect each root bus to cpu. This approach added high level of complexity to the code. This +approach was abandoned and never come to fully working state. + +We followed third option finally - multidomain approach. It has very small impact on and +seamlessly integrates into current coreboot code without need for huge changes to core parts. +Currently we have almost ready to upstream and fully working code for new SoC based on this +approach. + +== Multidomain approach - implementation details + +=== devicetree.cb + +Use multiple domains in devicetree.cb. Each stack has its own domain + + device domain 0 on //stack 0 + device pci 00.0 on end + ....... + end + device domain 1 on //stack 1 + device pci 00.0 on end + ....... + end + ...... + +Note: +CB:51180 - Small change is needed to util/sconfig to support multiple domains. + +=== Resource allocation + +We need to split available full resource range IO/MMIO between each stack. +This is done internally by FSP. Information about ranges available for each stack is exposed +via UDS hob (universal data hob). In domain level read_resources function we are assigning +available ranges to each domain then allow built in resource allocator to freely assign +resources to devices within available ranges. + +=== Above 4G resources + +Small change is needed to allow resource allocation for both below and above 4G barrier. + +== Summary + +Presented above multidomain concept to support split IIO design in coreboot allowed us to +prepare fully working POC for upcoming SoC. It is almost ready for upstreaming. +
-
Mariusz Szafrański (Code Review)