summaryrefslogtreecommitdiff
path: root/Documentation/soc
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/soc')
-rw-r--r--Documentation/soc/intel/code_development_model/code_development_model.md101
-rw-r--r--Documentation/soc/intel/code_development_model/coreboot_common_code_design.pngbin0 -> 368214 bytes
2 files changed, 101 insertions, 0 deletions
diff --git a/Documentation/soc/intel/code_development_model/code_development_model.md b/Documentation/soc/intel/code_development_model/code_development_model.md
new file mode 100644
index 0000000000..509b8ad3c8
--- /dev/null
+++ b/Documentation/soc/intel/code_development_model/code_development_model.md
@@ -0,0 +1,101 @@
+# Intel common code development strategy
+
+## Introduction
+
+This document captures the development strategy for Intel SOC code development
+of coreboot. As Intel keeps advancing hardware development and as new generation
+SoCs are developed, we need to add support for these SOCs into coreboot.
+
+We add this support inside the “soc/intel/soc_name” folder. This folder contains
+all the files which are related to a particular SoC.
+
+While there might be still duplicated code lying across SoCs, this document
+captures our efforts of putting as much code into shared directories across all
+Intel SoCs and of what can't be put into common code due to the possibility of
+future changes.
+
+## Design principal
+
+Any Intel coreboot project can be split into 3 parts:
+1. SoC = contains all the IP/component initialization code
+2. Mainboard = OEM/Reference boards, build based on underlying SoC support
+3. FSP = Intel firmware support package to abstract all restricted SoC registers
+from the open source code.
+
+Historically, we used to copy "X-1" generation SoC code into "X" new SoC while
+adding support for the new SoC. This resulted in having duplicated
+initialization code in both projects. This method increased redundant code
+across multiple SoCs and also it increased overhead for reviewers and
+maintainers.
+
+To solve this issue, we started following the converged IP model. The Intel
+silicon team uses the same IP/controller across various Intel SoCs. For example,
+the LPSS based UART controller is the same across all SoC products. Thus the
+"converged IP model" was propsed as the new firmware development model to create
+a common IP library across multiple SoC products and create BIOS/firmware for
+future SoCs. This will make development much simpler by using those common APIs
+based on the different configurations.
+
+## Common Code Development and Status
+
+Intel's proposed "converged IP model", also called as "common code phase 1.0",
+has reduced the number of lines of code in a single SoC folder by over 50%.
+
+We continue to analyze the code to see what can still be moved to common and try
+to reduce the footprint of the code in each SoC folder. With the current Intel
+SoC development model,the PCH has been made into a separate component for the
+big core SoCs. Intel hardware design has started following the model where the
+same PCH is used across multiple SoCs, which gives us an opportunity to make
+code more common across SoCs which use the same PCH. As part of this idea,
+common code phase 1.1 has emerged and we will try to create PCH binding for SoCs
+and thus further reduce the footprint of SoC code.
+
+Common code phase 1.1 will make code more modular for big core SoCs but there
+is still some scope to make code flow common across small core and big core
+SoCs. We will take this up as a part of common code phase 2.0 and make code flow
+common across small core and big core SoCs which will again help us to reduce
+the footprint of code as well as have a more unified code flow for all Intel
+SoCs.
+
+Here's a table which summarizes common code phase and status:
+```eval_rst
++----------------+---------------------------------------------+--------------+
+| Common code | summary | status |
+| phase | | |
++================+=============================================+==============+
+| 1.0 |follow "converged IP model" as described |Majority of |
+| |above and create common IP code which can be |the code is |
+| |used across multiple socs |common now. |
+| | |A few patches |
+| | |are in review |
++----------------+---------------------------------------------+--------------+
+| 1.1 |Create PCH binding for big core SoCs. SoCs |In development|
+| |having same PCH can use common code. |Base patch |
+| | |merged |
++----------------+---------------------------------------------+--------------+
+| 2.0 |Use common stage files (bootblock, romstage) |In development|
+| |across small core and big core SoCs. This | |
+| |will unify flow for all Intel SoCs. | |
++----------------+---------------------------------------------+--------------+
+```
+## Common code structure
+
+Code design after common code in coreboot will look as follows:
+
+**coreboot common code structure**
+![coreboot_common_code_structure][coreboot_common_code_design]
+
+[coreboot_common_code_design]: coreboot_common_code_design.png
+
+There will be still some duplicated files left in each SOC folder and we may
+copy across a SOC as a base but these files are subject to change as
+development continues.
+
+## Benefits
+
+1. coreboot will have less redundant code which is spread across multiple SOCs
+as of now.
+2. Design will be easier to understand by the community since code flow will be
+the same for all the Intel SoCs.
+3. Since we are aligning the software code design with the hardware philosophy,
+it will be easier to map why each change was done in code/SOC.
diff --git a/Documentation/soc/intel/code_development_model/coreboot_common_code_design.png b/Documentation/soc/intel/code_development_model/coreboot_common_code_design.png
new file mode 100644
index 0000000000..b5370ef54b
--- /dev/null
+++ b/Documentation/soc/intel/code_development_model/coreboot_common_code_design.png
Binary files differ