1# Intel common code development strategy
2
3## Introduction
4
5This document captures the development strategy for Intel SOC code development
6of coreboot. As Intel keeps advancing hardware development and as new generation
7SoCs are developed, we need to add support for these SOCs into coreboot.
8
9We add this support inside the “soc/intel/soc_name” folder. This folder contains
10all the files which are related to a particular SoC.
11
12While there might be still duplicated code lying across SoCs, this document
13captures our efforts of putting as much code into shared directories across all
14Intel SoCs and of what can't be put into common code due to the possibility of
15future changes.
16
17## Design principal
18
19Any Intel coreboot project can be split into 3 parts:
201. SoC = contains all the IP/component initialization code
212. Mainboard = OEM/Reference boards, build based on underlying SoC support
223. FSP = Intel firmware support package to abstract all restricted SoC registers
23from the open source code.
24
25Historically, we used to copy "X-1" generation SoC code into "X" new SoC while
26adding support for the new SoC. This resulted in having duplicated
27initialization code in both projects. This method increased redundant code
28across multiple SoCs and also it increased overhead for reviewers and
29maintainers.
30
31To solve this issue, we started following the converged IP model. The Intel
32silicon team uses the same IP/controller across various Intel SoCs. For example,
33the LPSS based UART controller is the same across all SoC products. Thus the
34"converged IP model" was propsed as the new firmware development model to create
35a common IP library across multiple SoC products and create BIOS/firmware for
36future SoCs. This will make development much simpler by using those common APIs
37based on the different configurations.
38
39## Common Code Development and Status
40
41Intel's proposed "converged IP model", also called as "common code phase 1.0",
42has reduced the number of lines of code in a single SoC folder by over 50%.
43
44We continue to analyze the code to see what can still be moved to common and try
45to reduce the footprint of the code in each SoC folder. With the current Intel
46SoC development model,the PCH has been made into a separate component for the
47big core SoCs. Intel hardware design has started following the model where the
48same PCH is used across multiple SoCs, which gives us an opportunity to make
49code more common across SoCs which use the same PCH. As part of this idea,
50common code phase 1.1 has emerged and we will try to create PCH binding for SoCs
51and thus further reduce the footprint of SoC code.
52
53Common code phase 1.1 will make code more modular for big core SoCs but there
54is still some scope to make code flow common across small core and big core
55SoCs. We will take this up as a part of common code phase 2.0 and make code flow
56common across small core and big core SoCs which will again help us to reduce
57the footprint of code as well as have a more unified code flow for all Intel
58SoCs.
59
60Here's a table which summarizes common code phase and status:
61```{eval-rst}
62+----------------+---------------------------------------------+--------------+
63|   Common code  |           summary                           |   status     |
64|     phase      |                                             |              |
65+================+=============================================+==============+
66|     1.0        |follow "converged IP model" as described     |Majority of   |
67|                |above and create common IP code which can be |the code is   |
68|                |used across multiple socs                    |common now.   |
69|                |                                             |A few patches |
70|                |                                             |are in review |
71+----------------+---------------------------------------------+--------------+
72|     1.1        |Create PCH binding for big core SoCs. SoCs   |In development|
73|                |having same PCH can use common code.         |Base patch    |
74|                |                                             |merged        |
75+----------------+---------------------------------------------+--------------+
76|     2.0        |Use common stage files (bootblock, romstage) |In development|
77|                |across small core and big core SoCs. This    |              |
78|                |will unify flow for all Intel SoCs.          |              |
79+----------------+---------------------------------------------+--------------+
80```
81## Common code structure
82
83Code design after common code in coreboot will look as follows:
84
85**coreboot common code structure**
86![coreboot_common_code_structure][coreboot_common_code_design]
87
88[coreboot_common_code_design]: coreboot_common_code_design.png
89
90There will be still some duplicated files left in each SOC folder and we may
91copy across a SOC as a base but these files are subject to change as
92development continues.
93
94## Benefits
95
961. coreboot will have less redundant code which is spread across multiple SOCs
97as of now.
982. Design will be easier to understand by the community since code flow will be
99the same for all the Intel SoCs.
1003. Since we are aligning the software code design with the hardware philosophy,
101it will be easier to map why each change was done in code/SOC.
102