Compare commits
61 Commits
oryp4
...
system76-4
Author | SHA1 | Date | |
---|---|---|---|
|
4244f4c3d1 | ||
|
8f1a8f2a81 | ||
|
682621fa1f | ||
|
2b030e54fd | ||
|
df09f534d8 | ||
|
ae923aa0c1 | ||
|
1ffa727cfa | ||
|
9eb65f388b | ||
|
ec5be45d26 | ||
|
428b7f6732 | ||
|
6d2d86ff43 | ||
|
91f99f94c2 | ||
|
01fa3c80df | ||
|
adc5695c39 | ||
|
ccd417e587 | ||
|
a7a7428a76 | ||
|
a986888a74 | ||
|
f33cf4bcd3 | ||
|
d725961114 | ||
|
6f71845692 | ||
|
68d9b42b26 | ||
|
f56daffffc | ||
|
b3d3fc9a87 | ||
|
8d72084349 | ||
|
89d2235e0f | ||
|
ed6990802a | ||
|
0278090e68 | ||
|
80fb39363b | ||
|
ac2f8121cd | ||
|
09b395bee6 | ||
|
9a7984f839 | ||
|
6d20bf4a9f | ||
|
d9a9796150 | ||
|
221796fa23 | ||
|
9798b1f3fd | ||
|
7d38db7d49 | ||
|
1522e01426 | ||
|
01e11ae288 | ||
|
e19c39eb59 | ||
|
48e7ffc9cd | ||
|
8c4eeafcfe | ||
|
6b56932606 | ||
|
28cc4183c8 | ||
|
ffb97ba314 | ||
|
b47923d714 | ||
|
5783ad7a65 | ||
|
090448674d | ||
|
7f1b3fa98c | ||
|
0004ff6f28 | ||
|
f55ab41430 | ||
|
912122d95f | ||
|
8933418194 | ||
|
25eb9c20a8 | ||
|
9b0cf73235 | ||
|
7727cc504b | ||
|
9c0913d5c2 | ||
|
c7998fda31 | ||
|
2fae43f36a | ||
|
fa92d159d4 | ||
|
243b89b15c | ||
|
832fd34cf5 |
4
.gitignore
vendored
4
.gitignore
vendored
@@ -31,8 +31,6 @@ site-local
|
||||
# Development friendly files
|
||||
tags
|
||||
.clang_complete
|
||||
.cache
|
||||
compile_commands.json
|
||||
|
||||
# Cross-compile toolkits
|
||||
xgcc/
|
||||
@@ -42,3 +40,5 @@ tarballs/
|
||||
*~
|
||||
*.kate-swp
|
||||
*.kdev4
|
||||
|
||||
doxygen/*
|
||||
|
32
.gitmodules
vendored
32
.gitmodules
vendored
@@ -1,63 +1,63 @@
|
||||
[submodule "3rdparty/blobs"]
|
||||
path = 3rdparty/blobs
|
||||
url = ../blobs.git
|
||||
url = https://review.coreboot.org/blobs.git
|
||||
update = none
|
||||
ignore = dirty
|
||||
[submodule "util/nvidia-cbootimage"]
|
||||
path = util/nvidia/cbootimage
|
||||
url = ../nvidia-cbootimage.git
|
||||
url = https://review.coreboot.org/nvidia-cbootimage.git
|
||||
[submodule "vboot"]
|
||||
path = 3rdparty/vboot
|
||||
url = ../vboot.git
|
||||
url = https://review.coreboot.org/vboot.git
|
||||
branch = main
|
||||
[submodule "arm-trusted-firmware"]
|
||||
path = 3rdparty/arm-trusted-firmware
|
||||
url = ../arm-trusted-firmware.git
|
||||
url = https://review.coreboot.org/arm-trusted-firmware.git
|
||||
[submodule "3rdparty/chromeec"]
|
||||
path = 3rdparty/chromeec
|
||||
url = ../chrome-ec.git
|
||||
url = https://review.coreboot.org/chrome-ec.git
|
||||
[submodule "libhwbase"]
|
||||
path = 3rdparty/libhwbase
|
||||
url = ../libhwbase.git
|
||||
url = https://review.coreboot.org/libhwbase.git
|
||||
[submodule "libgfxinit"]
|
||||
path = 3rdparty/libgfxinit
|
||||
url = ../libgfxinit.git
|
||||
url = https://review.coreboot.org/libgfxinit.git
|
||||
[submodule "3rdparty/fsp"]
|
||||
path = 3rdparty/fsp
|
||||
url = ../fsp.git
|
||||
url = https://review.coreboot.org/fsp.git
|
||||
update = none
|
||||
ignore = dirty
|
||||
[submodule "opensbi"]
|
||||
path = 3rdparty/opensbi
|
||||
url = ../opensbi.git
|
||||
url = https://review.coreboot.org/opensbi.git
|
||||
[submodule "intel-microcode"]
|
||||
path = 3rdparty/intel-microcode
|
||||
url = ../intel-microcode.git
|
||||
url = https://review.coreboot.org/intel-microcode.git
|
||||
update = none
|
||||
ignore = dirty
|
||||
branch = main
|
||||
[submodule "3rdparty/ffs"]
|
||||
path = 3rdparty/ffs
|
||||
url = ../ffs.git
|
||||
url = https://review.coreboot.org/ffs.git
|
||||
[submodule "3rdparty/amd_blobs"]
|
||||
path = 3rdparty/amd_blobs
|
||||
url = ../amd_blobs
|
||||
url = https://review.coreboot.org/amd_blobs
|
||||
update = none
|
||||
ignore = dirty
|
||||
[submodule "3rdparty/cmocka"]
|
||||
path = 3rdparty/cmocka
|
||||
url = ../cmocka.git
|
||||
url = https://review.coreboot.org/cmocka.git
|
||||
update = none
|
||||
branch = stable-1.1
|
||||
[submodule "3rdparty/qc_blobs"]
|
||||
path = 3rdparty/qc_blobs
|
||||
url = ../qc_blobs.git
|
||||
url = https://review.coreboot.org/qc_blobs.git
|
||||
update = none
|
||||
ignore = dirty
|
||||
[submodule "3rdparty/intel-sec-tools"]
|
||||
path = 3rdparty/intel-sec-tools
|
||||
url = ../9esec-security-tooling.git
|
||||
url = https://review.coreboot.org/9esec-security-tooling.git
|
||||
[submodule "3rdparty/stm"]
|
||||
path = 3rdparty/stm
|
||||
url = ../STM
|
||||
url = https://review.coreboot.org/STM
|
||||
branch = stmpe
|
||||
|
2
3rdparty/amd_blobs
vendored
2
3rdparty/amd_blobs
vendored
Submodule 3rdparty/amd_blobs updated: 89fae132a6...a0693217d2
2
3rdparty/blobs
vendored
2
3rdparty/blobs
vendored
Submodule 3rdparty/blobs updated: d55c315b61...8c580e55da
2
3rdparty/fsp
vendored
2
3rdparty/fsp
vendored
Submodule 3rdparty/fsp updated: 3853be02e7...f4bbf5ab89
2
3rdparty/intel-microcode
vendored
2
3rdparty/intel-microcode
vendored
Submodule 3rdparty/intel-microcode updated: 6c0c4691e5...115c3e4cda
2
3rdparty/qc_blobs
vendored
2
3rdparty/qc_blobs
vendored
Submodule 3rdparty/qc_blobs updated: e8efa5d98d...9ab0f0b71c
2
3rdparty/vboot
vendored
2
3rdparty/vboot
vendored
Submodule 3rdparty/vboot updated: a975eed306...25b9493525
@@ -1,9 +0,0 @@
|
||||
# See one of the following URLs for explanations of all the rules
|
||||
# https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
|
||||
# https://web.archive.org/web/20220424164542/https://github.com/markdownlint/markdownlint/blob/master/docs/RULES.md
|
||||
|
||||
all
|
||||
exclude_rule 'no-multiple-blanks'
|
||||
exclude_rule 'blanks-around-headers'
|
||||
exclude_rule 'blanks-around-lists'
|
||||
rule 'line-length', :line_length => 72
|
2441
Documentation/Doxyfile.coreboot
Normal file
2441
Documentation/Doxyfile.coreboot
Normal file
File diff suppressed because it is too large
Load Diff
2441
Documentation/Doxyfile.coreboot_simple
Normal file
2441
Documentation/Doxyfile.coreboot_simple
Normal file
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
Before Width: | Height: | Size: 230 KiB After Width: | Height: | Size: 230 KiB |
@@ -3,7 +3,7 @@
|
||||
This document describes the preferred C coding style for the
|
||||
coreboot project. It is in many ways exactly the same as the Linux
|
||||
kernel coding style. In fact, most of this document has been copied from
|
||||
the [Linux kernel coding style](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/4.Coding.rst)
|
||||
the [Linux kernel coding style](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodingStyle?id=HEAD)
|
||||
|
||||
The guidelines in this file should be seen as a strong suggestion, and
|
||||
should overrule personal preference. But they may be ignored in
|
||||
|
@@ -53,10 +53,7 @@ it's implemented, should restart the wait period.
|
||||
a recently-introduced issue (build, boot or OS-level compatibility, not
|
||||
necessarily identified by coreboot.org facilities). Its commit message
|
||||
has to explain what change introduced the problem and the nature of
|
||||
the problem so that the emergency need becomes apparent. Avoid stating
|
||||
something like "fix build error" in the commit summary, describe what
|
||||
the commit does instead, just like any other commit. In addition, it is
|
||||
recommended to reference the commit that introduced the issue. The change
|
||||
the problem so that the emergency need becomes apparent. The change
|
||||
itself should be as limited in scope and impact as possible to make it
|
||||
simple to assess the impact. Such a change can be merged early with 3
|
||||
Code-Review+2. For emergency fixes that affect a single project (SoC,
|
||||
|
@@ -1,40 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<svg
|
||||
width="250"
|
||||
height="200"
|
||||
viewBox="0 0 250.00001 200"
|
||||
version="1.1"
|
||||
id="svg4"
|
||||
sodipodi:docname="coreboot_logo.svg"
|
||||
inkscape:version="1.1.2 (0a00cf5339, 2022-02-04)"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<defs
|
||||
id="defs8" />
|
||||
<sodipodi:namedview
|
||||
id="namedview6"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="true"
|
||||
showgrid="false"
|
||||
width="250px"
|
||||
height="200px"
|
||||
inkscape:zoom="1.464382"
|
||||
inkscape:cx="-62.825135"
|
||||
inkscape:cy="121.21154"
|
||||
inkscape:window-width="1519"
|
||||
inkscape:window-height="920"
|
||||
inkscape:window-x="209"
|
||||
inkscape:window-y="73"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="svg4" />
|
||||
<path
|
||||
id="path61"
|
||||
d="m 80.661062,0.13961031 c 0,0 8.15178,6.60943399 23.247088,18.58954069 1.05796,0.880056 1.33191,1.294888 1.12373,1.641232 -0.31985,0.543174 -1.75582,-0.08872 -1.75582,-0.08872 -11.664048,-4.438128 -24.834388,-6.953649 -33.759848,-6.376408 -2.95434,0.189259 -3.90102,0.665956 -4.321175,1.508159 -0.19683,0.395552 -0.226549,1.460608 0.765169,2.779745 3.900636,5.157312 13.294036,15.263399 28.921176,24.855056 16.060528,9.852834 44.423978,23.830157 69.508388,34.990773 11.22686,4.992657 19.31714,11.666735 16.74132,19.3658 -2.87674,8.579122 -13.98099,9.747592 -22.85157,6.198982 C 151.07253,100.72135 144.33596,91.685794 133.39489,79.565635 114.43868,58.561649 105.44571,50.180157 73.988942,56.584689 58.21986,59.796417 43.339503,72.701794 31.438885,86.322779 23.497569,96.338376 19.677814,104.66948 18.527118,114.71536 c 0,0 -2.168556,-3.98066 -0.01478,-14.17227 3.764359,-17.803609 -4.428375,-25.450182 -4.428375,-25.450182 -41.49508,58.844472 17.526881,112.045702 63.024789,61.095232 0,0 -14.887006,33.05468 -13.647358,43.34849 -6.349646,2.08185 -9.170023,7.92269 0.332682,14.9707 10.382756,7.69907 35.885136,7.03371 56.001494,-1.61165 37.55849,-16.14193 60.9693,-46.22207 72.57279,-65.32401 2.71019,-4.46651 5.57763,-6.63885 7.56296,-7.34857 3.01112,-1.08635 23.72764,0.16234 33.42717,-5.3451 1.34942,0.65673 3.06678,1.00763 5.33032,0.8354 C 245.71787,115.17969 250,106.76795 250,106.76795 c 0,0 -8.87062,-16.922111 -30.12254,-29.55327 C 199.86141,65.319739 194.02789,69.457093 176.05582,55.128281 147.99814,32.763519 114.02178,7.3201044 80.661062,0.13961031 Z M 102.26692,70.594304 c 13.26505,-0.0029 23.37736,4.660953 25.1286,13.170519 2.97326,14.478329 -27.955978,50.936567 -25.92334,51.521377 0.19683,0.0549 0.6391,-0.16704 1.28637,-0.60991 10.15186,-13.28789 29.37687,-33.69148 36.58765,-32.90227 12.92072,1.41187 17.38079,18.53779 17.38079,18.53779 l -43.07864,38.86837 c 8.89707,2.41684 18.6275,3.29074 28.363,2.54317 -19.24009,13.70237 -40.10745,17.52487 -53.007358,11.85088 20.405928,-14.79629 57.956938,-51.80601 57.956938,-51.80601 0,0 -6.24718,-15.74184 -17.51757,-6.10287 -10.90133,9.32102 -20.97474,20.96607 -24.95486,24.68502 -2.46226,2.29571 -6.636458,6.63454 -9.104398,4.76844 -3.00355,-2.26922 5.935248,-22.37963 12.771298,-39.0458 9.32669,-22.730028 -1.40413,-29.828637 -13.965258,-29.198404 -11.25525,0.565885 -26.629956,7.384774 -37.644841,14.120509 -3.118992,1.909626 -5.249017,3.0833 -6.036334,2.354652 -0.688903,-0.641589 0.03892,-1.850245 2.084808,-3.578182 C 68.148932,76.592284 87.233202,70.597548 102.26692,70.594304 Z"
|
||||
style="stroke-width:1.89259;fill:#ffffff" />
|
||||
</svg>
|
Before Width: | Height: | Size: 3.6 KiB |
@@ -8,15 +8,6 @@ and those providing after-market firmware to extend the usefulness of devices.
|
||||
|
||||
## Hardware shipping with coreboot
|
||||
|
||||
### NovaCustom laptops
|
||||
|
||||
[NovaCustom](https://configurelaptop.eu/) sells configurable laptops with
|
||||
[Dasharo](https://dasharo.com/) coreboot based firmware on board, maintained by
|
||||
[3mdeb](https://3mdeb.com/). NovaCustom offers full GNU/Linux and Microsoft
|
||||
Windows compatibility. NovaCustom ensures security updates via fwupd for 5 years
|
||||
and the firmware is equipped with important security features such as measured
|
||||
boot, verified boot, TPM integration and UEFI Secure Boot.
|
||||
|
||||
### ChromeOS Devices
|
||||
|
||||
All ChromeOS devices ([Chromebooks](https://chromebookdb.com/), Chromeboxes,
|
||||
@@ -63,15 +54,6 @@ provides ready-made firmware images for supported devices: those which can be
|
||||
built entirely from source code. Their copy of the coreboot repository is
|
||||
therefore stripped of all devices that require binary components to boot.
|
||||
|
||||
|
||||
### Dasharo
|
||||
|
||||
[Dasharo](https://dasharo.com/) is an open-source based firmware distribution
|
||||
focusing on clean and simple code, long-term maintenance, transparent
|
||||
validation, privacy-respecting implementation, liberty for the owners, and
|
||||
trustworthiness for all.
|
||||
|
||||
|
||||
### MrChromebox
|
||||
|
||||
[MrChromebox](https://mrchromebox.tech/) provides upstream coreboot firmware
|
||||
|
319
Documentation/doxygen/Doxyfile.coreboot_platform
Normal file
319
Documentation/doxygen/Doxyfile.coreboot_platform
Normal file
@@ -0,0 +1,319 @@
|
||||
# Doxyfile 1.8.11
|
||||
|
||||
#---------------------------------------------------------------------------
|
||||
# Project related configuration options
|
||||
#---------------------------------------------------------------------------
|
||||
DOXYFILE_ENCODING = UTF-8
|
||||
PROJECT_NAME = "coreboot for $(DOXYGEN_PLATFORM)"
|
||||
PROJECT_NUMBER =
|
||||
PROJECT_BRIEF = "coreboot is an Open Source project aimed at replacing the proprietary BIOS found in most computers."
|
||||
PROJECT_LOGO = Documentation/coreboot_logo.png
|
||||
OUTPUT_DIRECTORY = $(DOXYGEN_OUTPUT_DIR)
|
||||
CREATE_SUBDIRS = YES
|
||||
ALLOW_UNICODE_NAMES = NO
|
||||
OUTPUT_LANGUAGE = English
|
||||
BRIEF_MEMBER_DESC = YES
|
||||
REPEAT_BRIEF = YES
|
||||
ABBREVIATE_BRIEF =
|
||||
ALWAYS_DETAILED_SEC = YES
|
||||
INLINE_INHERITED_MEMB = NO
|
||||
FULL_PATH_NAMES = YES
|
||||
STRIP_FROM_PATH =
|
||||
STRIP_FROM_INC_PATH =
|
||||
SHORT_NAMES = NO
|
||||
JAVADOC_AUTOBRIEF = YES
|
||||
QT_AUTOBRIEF = NO
|
||||
MULTILINE_CPP_IS_BRIEF = NO
|
||||
INHERIT_DOCS = YES
|
||||
SEPARATE_MEMBER_PAGES = NO
|
||||
TAB_SIZE = 8
|
||||
ALIASES =
|
||||
TCL_SUBST =
|
||||
OPTIMIZE_OUTPUT_FOR_C = YES
|
||||
OPTIMIZE_OUTPUT_JAVA = NO
|
||||
OPTIMIZE_FOR_FORTRAN = NO
|
||||
OPTIMIZE_OUTPUT_VHDL = NO
|
||||
EXTENSION_MAPPING =
|
||||
MARKDOWN_SUPPORT = YES
|
||||
AUTOLINK_SUPPORT = YES
|
||||
BUILTIN_STL_SUPPORT = NO
|
||||
CPP_CLI_SUPPORT = NO
|
||||
SIP_SUPPORT = NO
|
||||
IDL_PROPERTY_SUPPORT = YES
|
||||
DISTRIBUTE_GROUP_DOC = NO
|
||||
GROUP_NESTED_COMPOUNDS = NO
|
||||
SUBGROUPING = YES
|
||||
INLINE_GROUPED_CLASSES = NO
|
||||
INLINE_SIMPLE_STRUCTS = NO
|
||||
TYPEDEF_HIDES_STRUCT = NO
|
||||
LOOKUP_CACHE_SIZE = 0
|
||||
#---------------------------------------------------------------------------
|
||||
# Build related configuration options
|
||||
#---------------------------------------------------------------------------
|
||||
EXTRACT_ALL = YES
|
||||
EXTRACT_PRIVATE = NO
|
||||
EXTRACT_PACKAGE = NO
|
||||
EXTRACT_STATIC = YES
|
||||
EXTRACT_LOCAL_CLASSES = YES
|
||||
EXTRACT_LOCAL_METHODS = NO
|
||||
EXTRACT_ANON_NSPACES = NO
|
||||
HIDE_UNDOC_MEMBERS = NO
|
||||
HIDE_UNDOC_CLASSES = NO
|
||||
HIDE_FRIEND_COMPOUNDS = NO
|
||||
HIDE_IN_BODY_DOCS = NO
|
||||
INTERNAL_DOCS = NO
|
||||
CASE_SENSE_NAMES = YES
|
||||
HIDE_SCOPE_NAMES = NO
|
||||
HIDE_COMPOUND_REFERENCE= NO
|
||||
SHOW_INCLUDE_FILES = YES
|
||||
SHOW_GROUPED_MEMB_INC = NO
|
||||
FORCE_LOCAL_INCLUDES = NO
|
||||
INLINE_INFO = YES
|
||||
SORT_MEMBER_DOCS = YES
|
||||
SORT_BRIEF_DOCS = NO
|
||||
SORT_MEMBERS_CTORS_1ST = NO
|
||||
SORT_GROUP_NAMES = NO
|
||||
SORT_BY_SCOPE_NAME = NO
|
||||
STRICT_PROTO_MATCHING = NO
|
||||
GENERATE_TODOLIST = YES
|
||||
GENERATE_TESTLIST = YES
|
||||
GENERATE_BUGLIST = YES
|
||||
GENERATE_DEPRECATEDLIST= YES
|
||||
ENABLED_SECTIONS =
|
||||
MAX_INITIALIZER_LINES = 30
|
||||
SHOW_USED_FILES = YES
|
||||
SHOW_FILES = YES
|
||||
SHOW_NAMESPACES = YES
|
||||
FILE_VERSION_FILTER =
|
||||
LAYOUT_FILE =
|
||||
CITE_BIB_FILES =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to warning and progress messages
|
||||
#---------------------------------------------------------------------------
|
||||
QUIET = YES
|
||||
WARNINGS = YES
|
||||
WARN_IF_UNDOCUMENTED = YES
|
||||
WARN_IF_DOC_ERROR = YES
|
||||
WARN_NO_PARAMDOC = YES
|
||||
WARN_AS_ERROR = NO
|
||||
WARN_FORMAT = "$file:$line: $text"
|
||||
WARN_LOGFILE =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the input files
|
||||
#---------------------------------------------------------------------------
|
||||
INPUT = $(DOXYFILES)
|
||||
INPUT_ENCODING = UTF-8
|
||||
FILE_PATTERNS =
|
||||
RECURSIVE = NO
|
||||
EXCLUDE =
|
||||
EXCLUDE_SYMLINKS = NO
|
||||
EXCLUDE_PATTERNS =
|
||||
EXCLUDE_SYMBOLS =
|
||||
EXAMPLE_PATH =
|
||||
EXAMPLE_PATTERNS =
|
||||
EXAMPLE_RECURSIVE = NO
|
||||
IMAGE_PATH =
|
||||
INPUT_FILTER =
|
||||
FILTER_PATTERNS =
|
||||
FILTER_SOURCE_FILES = NO
|
||||
FILTER_SOURCE_PATTERNS =
|
||||
USE_MDFILE_AS_MAINPAGE =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to source browsing
|
||||
#---------------------------------------------------------------------------
|
||||
SOURCE_BROWSER = YES
|
||||
INLINE_SOURCES = NO
|
||||
STRIP_CODE_COMMENTS = NO
|
||||
REFERENCED_BY_RELATION = YES
|
||||
REFERENCES_RELATION = YES
|
||||
REFERENCES_LINK_SOURCE = YES
|
||||
SOURCE_TOOLTIPS = YES
|
||||
USE_HTAGS = NO
|
||||
VERBATIM_HEADERS = YES
|
||||
CLANG_ASSISTED_PARSING = NO
|
||||
CLANG_OPTIONS =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the alphabetical class index
|
||||
#---------------------------------------------------------------------------
|
||||
ALPHABETICAL_INDEX = YES
|
||||
COLS_IN_ALPHA_INDEX = 5
|
||||
IGNORE_PREFIX =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the HTML output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_HTML = YES
|
||||
HTML_OUTPUT = html
|
||||
HTML_FILE_EXTENSION = .html
|
||||
HTML_HEADER =
|
||||
HTML_FOOTER =
|
||||
HTML_STYLESHEET =
|
||||
HTML_EXTRA_STYLESHEET =
|
||||
HTML_EXTRA_FILES =
|
||||
HTML_COLORSTYLE_HUE = 220
|
||||
HTML_COLORSTYLE_SAT = 100
|
||||
HTML_COLORSTYLE_GAMMA = 80
|
||||
HTML_TIMESTAMP = NO
|
||||
HTML_DYNAMIC_SECTIONS = NO
|
||||
HTML_INDEX_NUM_ENTRIES = 100
|
||||
GENERATE_DOCSET = NO
|
||||
DOCSET_FEEDNAME = "Doxygen documentation"
|
||||
DOCSET_BUNDLE_ID = org.doxygen.Project
|
||||
DOCSET_PUBLISHER_ID = org.doxygen.Publisher
|
||||
DOCSET_PUBLISHER_NAME = Publisher
|
||||
GENERATE_HTMLHELP = NO
|
||||
CHM_FILE =
|
||||
HHC_LOCATION =
|
||||
GENERATE_CHI = NO
|
||||
CHM_INDEX_ENCODING =
|
||||
BINARY_TOC = NO
|
||||
TOC_EXPAND = NO
|
||||
GENERATE_QHP = NO
|
||||
QCH_FILE =
|
||||
QHP_NAMESPACE = org.doxygen.Project
|
||||
QHP_VIRTUAL_FOLDER = doc
|
||||
QHP_CUST_FILTER_NAME =
|
||||
QHP_CUST_FILTER_ATTRS =
|
||||
QHP_SECT_FILTER_ATTRS =
|
||||
QHG_LOCATION =
|
||||
GENERATE_ECLIPSEHELP = NO
|
||||
ECLIPSE_DOC_ID = org.doxygen.Project
|
||||
DISABLE_INDEX = NO
|
||||
GENERATE_TREEVIEW = YES
|
||||
ENUM_VALUES_PER_LINE = 4
|
||||
TREEVIEW_WIDTH = 250
|
||||
EXT_LINKS_IN_WINDOW = NO
|
||||
FORMULA_FONTSIZE = 10
|
||||
FORMULA_TRANSPARENT = YES
|
||||
USE_MATHJAX = NO
|
||||
MATHJAX_FORMAT = HTML-CSS
|
||||
MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest
|
||||
MATHJAX_EXTENSIONS =
|
||||
MATHJAX_CODEFILE =
|
||||
SEARCHENGINE = YES
|
||||
SERVER_BASED_SEARCH = NO
|
||||
EXTERNAL_SEARCH = NO
|
||||
SEARCHENGINE_URL =
|
||||
SEARCHDATA_FILE = searchdata.xml
|
||||
EXTERNAL_SEARCH_ID =
|
||||
EXTRA_SEARCH_MAPPINGS =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the LaTeX output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_LATEX = NO
|
||||
LATEX_OUTPUT = latex
|
||||
LATEX_CMD_NAME = latex
|
||||
MAKEINDEX_CMD_NAME = makeindex
|
||||
COMPACT_LATEX = NO
|
||||
PAPER_TYPE = a4wide
|
||||
EXTRA_PACKAGES =
|
||||
LATEX_HEADER =
|
||||
LATEX_FOOTER =
|
||||
LATEX_EXTRA_STYLESHEET =
|
||||
LATEX_EXTRA_FILES =
|
||||
PDF_HYPERLINKS = NO
|
||||
USE_PDFLATEX = NO
|
||||
LATEX_BATCHMODE = NO
|
||||
LATEX_HIDE_INDICES = NO
|
||||
LATEX_SOURCE_CODE = NO
|
||||
LATEX_BIB_STYLE = plain
|
||||
LATEX_TIMESTAMP = NO
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the RTF output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_RTF = NO
|
||||
RTF_OUTPUT = rtf
|
||||
COMPACT_RTF = NO
|
||||
RTF_HYPERLINKS = NO
|
||||
RTF_STYLESHEET_FILE =
|
||||
RTF_EXTENSIONS_FILE =
|
||||
RTF_SOURCE_CODE = NO
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the man page output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_MAN = NO
|
||||
MAN_OUTPUT = man
|
||||
MAN_EXTENSION = .3
|
||||
MAN_SUBDIR =
|
||||
MAN_LINKS = NO
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the XML output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_XML = NO
|
||||
XML_OUTPUT = xml
|
||||
XML_PROGRAMLISTING = YES
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the DOCBOOK output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_DOCBOOK = NO
|
||||
DOCBOOK_OUTPUT = docbook
|
||||
DOCBOOK_PROGRAMLISTING = NO
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options for the AutoGen Definitions output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_AUTOGEN_DEF = NO
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the Perl module output
|
||||
#---------------------------------------------------------------------------
|
||||
GENERATE_PERLMOD = NO
|
||||
PERLMOD_LATEX = NO
|
||||
PERLMOD_PRETTY = YES
|
||||
PERLMOD_MAKEVAR_PREFIX =
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the preprocessor
|
||||
#---------------------------------------------------------------------------
|
||||
ENABLE_PREPROCESSING = YES
|
||||
MACRO_EXPANSION = YES
|
||||
EXPAND_ONLY_PREDEF = YES
|
||||
SEARCH_INCLUDES = YES
|
||||
INCLUDE_PATH =
|
||||
INCLUDE_FILE_PATTERNS =
|
||||
PREDEFINED = __attribute__(x)=
|
||||
EXPAND_AS_DEFINED =
|
||||
SKIP_FUNCTION_MACROS = YES
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to external references
|
||||
#---------------------------------------------------------------------------
|
||||
TAGFILES =
|
||||
GENERATE_TAGFILE =
|
||||
ALLEXTERNALS = NO
|
||||
EXTERNAL_GROUPS = YES
|
||||
EXTERNAL_PAGES = YES
|
||||
PERL_PATH = /usr/bin/perl
|
||||
#---------------------------------------------------------------------------
|
||||
# Configuration options related to the dot tool
|
||||
#---------------------------------------------------------------------------
|
||||
CLASS_DIAGRAMS = YES
|
||||
MSCGEN_PATH =
|
||||
DIA_PATH =
|
||||
HIDE_UNDOC_RELATIONS = NO
|
||||
HAVE_DOT = NO
|
||||
DOT_NUM_THREADS = 0
|
||||
DOT_FONTNAME = Helvetica
|
||||
DOT_FONTSIZE = 10
|
||||
DOT_FONTPATH =
|
||||
CLASS_GRAPH = YES
|
||||
COLLABORATION_GRAPH = YES
|
||||
GROUP_GRAPHS = YES
|
||||
UML_LOOK = YES
|
||||
UML_LIMIT_NUM_FIELDS = 10
|
||||
TEMPLATE_RELATIONS = NO
|
||||
INCLUDE_GRAPH = YES
|
||||
INCLUDED_BY_GRAPH = YES
|
||||
CALL_GRAPH = YES
|
||||
CALLER_GRAPH = YES
|
||||
GRAPHICAL_HIERARCHY = YES
|
||||
DIRECTORY_GRAPH = YES
|
||||
DOT_IMAGE_FORMAT = png
|
||||
INTERACTIVE_SVG = NO
|
||||
DOT_PATH =
|
||||
DOTFILE_DIRS =
|
||||
MSCFILE_DIRS =
|
||||
DIAFILE_DIRS =
|
||||
PLANTUML_JAR_PATH =
|
||||
PLANTUML_INCLUDE_PATH =
|
||||
DOT_GRAPH_MAX_NODES = 50
|
||||
MAX_DOT_GRAPH_DEPTH = 0
|
||||
DOT_TRANSPARENT = NO
|
||||
DOT_MULTI_TARGETS = YES
|
||||
GENERATE_LEGEND = YES
|
||||
DOT_CLEANUP = YES
|
@@ -3,7 +3,7 @@
|
||||
## Overview
|
||||
![][architecture]
|
||||
|
||||
[architecture]: comparison_coreboot_uefi.svg
|
||||
[architecture]: comparision_coreboot_uefi.svg
|
||||
|
||||
## Stages
|
||||
coreboot consists of multiple stages that are compiled as separate binaries and
|
||||
|
@@ -2,7 +2,7 @@
|
||||
|
||||
A coreboot image for an Intel SoC contains two separate definitions of the
|
||||
layout of the flash. The Intel Flash Descriptor (IFD) which defines offsets and
|
||||
sizes of various regions of flash and the [coreboot FMAP](../../lib/flashmap.md).
|
||||
sizes of various regions of flash and the [coreboot FMAP](../lib/flashmap.md).
|
||||
|
||||
The FMAP should define all of the of the regions defined by the IFD to ensure
|
||||
that those regions are accounted for by coreboot and will not be accidentally
|
||||
@@ -29,7 +29,7 @@ way to categorize anything required by the SoC but not provided by coreboot.
|
||||
+------------+------------------+-----------+-------------------------------------------+
|
||||
| 4 | Platform Data | SI_PDR | |
|
||||
+------------+------------------+-----------+-------------------------------------------+
|
||||
| 8 | EC Firmware | SI_EC | Most ChromeOS devices do not use this |
|
||||
| 8 | EC Firmware | SI_EC | Most Chrome OS devices do not use this |
|
||||
| | | | region; EC firmware is stored in BIOS |
|
||||
| | | | region of flash |
|
||||
+------------+------------------+-----------+-------------------------------------------+
|
@@ -5,11 +5,6 @@ It is built from Markdown files in the
|
||||
[Documentation](https://review.coreboot.org/cgit/coreboot.git/tree/Documentation)
|
||||
directory in the source code.
|
||||
|
||||
## Spelling of coreboot
|
||||
|
||||
The correct spelling of coreboot is completely in lower case characters and in
|
||||
one word without a space between the two parts.
|
||||
|
||||
## Purpose of coreboot
|
||||
|
||||
coreboot is a project to develop open source boot firmware for various
|
||||
@@ -194,7 +189,5 @@ Contents:
|
||||
* [Vendorcode](vendorcode/index.md)
|
||||
* [Utilities](util.md)
|
||||
* [Project infrastructure & services](infrastructure/index.md)
|
||||
* [Boards supported in each release directory](releases/boards_supported_on_branches.md)
|
||||
* [Release notes](releases/index.md)
|
||||
* [Acronyms & Definitions](acronyms.md)
|
||||
* [Documentation License](documentation_license.md)
|
||||
|
@@ -41,33 +41,25 @@ can run into "out of storage space" errors.
|
||||
#### Current Build Machines
|
||||
|
||||
To give an idea of what a suitable build machine might be, currently the
|
||||
coreboot project has 6 active jenkins build machines.
|
||||
coreboot project has 4 active jenkins build machines.
|
||||
|
||||
These times are taken from the week of Feb 21 - Feb 28, 2022
|
||||
|
||||
* Congenialbuilder - 128 threads, 256GiB RAM
|
||||
* Coverity Builds, Toolchain builds, Scanbuild-builds
|
||||
* Fastest Passing coreboot gerrit build: 6 min, 47 sec
|
||||
* Slowest Passing coreboot gerrit build: 14 min
|
||||
* Fastest Passing coreboot gerrit build: 6 min, 47 sec
|
||||
* Slowest Passing coreboot gerrit build: 14 min
|
||||
|
||||
* Gleefulbuilder - 64 threads, 64GiB RAM
|
||||
* Fastest Passing coreboot gerrit build: 10 min
|
||||
* Slowest Passing coreboot gerrit build: 46 min
|
||||
* Gleefulbuilder - 64 thread, 64GiB RAM
|
||||
* Fastest Passing coreboot gerrit build: 10 min
|
||||
* Slowest Passing coreboot gerrit build: 46 min
|
||||
|
||||
* Fabulousbuilder - 64 threads, 64GiB RAM
|
||||
* Fastest Passing coreboot gerrit build: 7 min, 56 sec
|
||||
* Slowest Passing coreboot gerrit build: 56 min (No ccache)
|
||||
* Fastest Passing coreboot gerrit build: 7 min, 56 sec
|
||||
* Slowest Passing coreboot gerrit build: 56 min (No ccache)
|
||||
|
||||
* Ultron (9elements) - 48 threads, 128GiB RAM
|
||||
* Fastest Passing coreboot gerrit build: 12 min
|
||||
* Slowest Passing coreboot gerrit build: 58 min
|
||||
|
||||
* Bob - 64 threads, 128GiB RAM
|
||||
* Fastest Passing coreboot gerrit build: 7 min
|
||||
* Slowest Passing coreboot gerrit build: 34 min
|
||||
|
||||
* Pokeybuilder - 32 Threads, 96GiB RAM
|
||||
* Runs coreboot-checkpatch and other lighter builds
|
||||
* Fastest Passing coreboot gerrit build: 12
|
||||
* Slowest Passing coreboot gerrit build: 58 min
|
||||
|
||||
|
||||
### Jenkins Builds
|
||||
@@ -77,18 +69,7 @@ for a number of different projects - coreboot, flashrom, memtest86+,
|
||||
em100, etc. Many of these have builders for their current master branch
|
||||
as well as Gerrit and [Coverity](coverity.md) builds.
|
||||
|
||||
|
||||
#### Long builds - over 90 minutes on congenialbuilder
|
||||
There are a few builds that take a long time even on the fastest
|
||||
machines. These tasks run overnight in the US timezones.
|
||||
* coreboot_coverity - 9 to 12 hours
|
||||
* coreboot_scanbuild - ~3 hours
|
||||
* coreboot_toolchain - ~1 hour 45 minutes
|
||||
|
||||
|
||||
#### All builds
|
||||
|
||||
You can see all the builds in the main jenkins interface:
|
||||
You can see all the builds here:
|
||||
[https://qa.coreboot.org/](https://qa.coreboot.org/)
|
||||
|
||||
Most of the time on the builders is taken up by the coreboot master and
|
||||
@@ -110,8 +91,8 @@ hour.
|
||||
|
||||
On a system with 32 cores, it was tested with this command:
|
||||
|
||||
```sh
|
||||
stress-ng --cpu 20 --io 6 --vm 6 --vm-bytes 1G --verify --metrics-brief -t 60m
|
||||
```
|
||||
$ stress-ng --cpu 20 --io 6 --vm 6 --vm-bytes 1G --verify --metrics-brief -t 60m
|
||||
```
|
||||
|
||||
You can watch the temperature with the sensors package or with ‘acpi -t’
|
||||
@@ -121,8 +102,8 @@ You can check for thermal throttling by running this command and seeing
|
||||
if the values go down on any of the cores after it's been running for a
|
||||
while.
|
||||
|
||||
```sh
|
||||
while [ true ]; do clear; cat /proc/cpuinfo | grep 'cpu MHz' ; sleep 1; done
|
||||
```
|
||||
$ while [ true ]; do clear; cat /proc/cpuinfo | grep 'cpu MHz' ; sleep 1; done
|
||||
```
|
||||
|
||||
If the machine throttles or resets, you probably need to upgrade the
|
||||
@@ -161,7 +142,7 @@ These instructions keep changing, so just check the latest information.
|
||||
|
||||
As a regular user - *Not root*, run:
|
||||
|
||||
```sh
|
||||
```
|
||||
sudo mkdir -p ${COREBOOT_JENKINS_CACHE_DIR}
|
||||
sudo mkdir -p ${COREBOOT_JENKINS_CCACHE_DIR}
|
||||
sudo chown $(whoami):$(whoami) ${COREBOOT_JENKINS_CCACHE_DIR}
|
||||
@@ -177,7 +158,7 @@ To make configuration and the later commands easier, these should go in
|
||||
your shell's .rc file. Note that you only need to set them if you're
|
||||
using something other than the default.
|
||||
|
||||
```sh
|
||||
```
|
||||
# Set the port used on your machine to connect to jenkins.
|
||||
export COREBOOT_JENKINS_PORT=49151
|
||||
|
||||
@@ -199,13 +180,13 @@ continuing to the next step.
|
||||
|
||||
From the coreboot directory, run
|
||||
|
||||
```sh
|
||||
```
|
||||
make -C util/docker help
|
||||
```
|
||||
|
||||
This will show you the available targets and variables needed:
|
||||
|
||||
```text
|
||||
```
|
||||
Commands for working with docker images:
|
||||
coreboot-sdk - Build coreboot-sdk container
|
||||
upload-coreboot-sdk - Upload coreboot-sdk to hub.docker.com
|
||||
@@ -240,7 +221,7 @@ Variables:
|
||||
|
||||
### Install the coreboot jenkins builder
|
||||
|
||||
```sh
|
||||
```
|
||||
make -C util/docker docker-jenkins-server
|
||||
```
|
||||
|
||||
@@ -271,12 +252,11 @@ the ccache gets populated, the build time will drop.
|
||||
|
||||
|
||||
### How to log in to the docker instance for debugging
|
||||
|
||||
```sh
|
||||
make -C util/docker docker-jenkins-attach
|
||||
su coreboot
|
||||
cd ~/slave-root/workspace
|
||||
bash
|
||||
```
|
||||
$ make -C util/docker docker-jenkins-attach
|
||||
$ su coreboot
|
||||
$ cd ~/slave-root/workspace
|
||||
$ bash
|
||||
```
|
||||
|
||||
|
||||
@@ -293,18 +273,18 @@ then update to get a fresh installation.
|
||||
|
||||
To delete the old containers & images:
|
||||
|
||||
```sh
|
||||
docker stop $COREBOOT_JENKINS_CONTAINER
|
||||
docker rm $COREBOOT_JENKINS_CONTAINER
|
||||
docker images # lists all existing images
|
||||
docker rmi XXXX # Use the image ID found in the above command.
|
||||
```
|
||||
$ docker stop $COREBOOT_JENKINS_CONTAINER
|
||||
$ docker rm $COREBOOT_JENKINS_CONTAINER
|
||||
$ docker images # lists all existing images
|
||||
$ docker rmi XXXX # Use the image ID found in the above command.
|
||||
```
|
||||
|
||||
To get and run the new coreboot-jenkins image, change the value in the
|
||||
`DOCKER_COMMIT` variable to the new image value.
|
||||
|
||||
```sh
|
||||
make -C util/docker docker-jenkins-server
|
||||
```
|
||||
$ make -C util/docker docker-jenkins-server
|
||||
```
|
||||
|
||||
#### Getting ready to push the docker images
|
||||
@@ -318,15 +298,15 @@ Get an admin to add the account to the coreboot team on hub.docker.com
|
||||
Make sure your credentials are configured on your host machine by
|
||||
running
|
||||
|
||||
```sh
|
||||
docker login
|
||||
```
|
||||
$ docker login
|
||||
```
|
||||
|
||||
This will prompt you for your docker username, password, and your email
|
||||
address, and write out to ~/.docker/config.json. Without this file, you
|
||||
won’t be able to push the images.
|
||||
|
||||
#### Updating the Dockerfiles
|
||||
#### Updating the Dockerfiles:
|
||||
|
||||
The coreboot-sdk Dockerfile will need to be updated when any additional
|
||||
dependencies are added. Both the coreboot-sdk and the
|
||||
@@ -337,15 +317,15 @@ files are stored in the coreboot repo under coreboot/util/docker.
|
||||
Read the [dockerfile best practices](https://docs.docker.com/v1.8/articles/dockerfile_best-practices/)
|
||||
page before updating the files.
|
||||
|
||||
#### Rebuilding the coreboot-sdk docker image to update the toolchain
|
||||
#### Rebuilding the coreboot-sdk docker image to update the toolchain:
|
||||
|
||||
```sh
|
||||
make -C util/docker coreboot-sdk
|
||||
```
|
||||
$ make -C util/docker coreboot-sdk
|
||||
```
|
||||
|
||||
This takes a relatively long time.
|
||||
|
||||
#### Test the coreboot-sdk docker image
|
||||
#### Test the coreboot-sdk docker image:
|
||||
|
||||
There are two methods of running the docker image - interactively as a
|
||||
shell, or doing the build directly. Running interactively as a shell is
|
||||
@@ -353,44 +333,44 @@ useful for early testing, because it allows you to update the image
|
||||
(without any changes getting saved) and re-test builds. This saves the
|
||||
time of having to rebuild the image for every issue you find.
|
||||
|
||||
#### Running the docker image interactively
|
||||
#### Running the docker image interactively:
|
||||
|
||||
Run:
|
||||
|
||||
```sh
|
||||
make -C util/docker docker-jenkins-server
|
||||
make -C util/docker docker-jenkins-attach
|
||||
```
|
||||
$ make -C util/docker docker-jenkins-server
|
||||
$ make -C util/docker docker-jenkins-attach
|
||||
```
|
||||
|
||||
#### Running the build directly
|
||||
#### Running the build directly:
|
||||
|
||||
From the coreboot directory:
|
||||
|
||||
```sh
|
||||
make -C util/docker docker-build-coreboot
|
||||
```
|
||||
$ make -C util/docker docker-build-coreboot
|
||||
```
|
||||
|
||||
You’ll also want to test building the other projects and payloads:
|
||||
ChromeEC, flashrom, memtest86+, em100, Grub2, SeaBIOS, iPXE, coreinfo,
|
||||
nvramcui, tint...
|
||||
|
||||
#### Pushing the coreboot-sdk image to hub.docker.com for use
|
||||
#### Pushing the coreboot-sdk image to hub.docker.com for use:
|
||||
|
||||
When you’re satisfied with the testing, push the coreboot-sdk image to
|
||||
the hub.docker.com
|
||||
|
||||
```sh
|
||||
make -C util/docker upload-coreboot-sdk
|
||||
```
|
||||
$ make -C util/docker upload-coreboot-sdk
|
||||
```
|
||||
|
||||
#### Building and pushing the coreboot-jenkins-node docker image
|
||||
#### Building and pushing the coreboot-jenkins-node docker image:
|
||||
|
||||
This docker image is pretty simple, so there’s not really any testing
|
||||
that needs to be done.
|
||||
|
||||
```sh
|
||||
make -C util/docker coreboot-jenkins-node
|
||||
make -C util/docker upload-coreboot-jenkins-node
|
||||
```
|
||||
$ make -C util/docker coreboot-jenkins-node
|
||||
$ make -C util/docker upload-coreboot-jenkins-node
|
||||
```
|
||||
|
||||
### Coverity Setup
|
||||
@@ -411,7 +391,7 @@ Rename the directory from its original name
|
||||
(cov-analysis-linux64-7.7.0.4) to ‘coverity’, or better, create a
|
||||
symlink:
|
||||
|
||||
```sh
|
||||
```
|
||||
ln -s cov-analysis-linux64-7.7.0.4 coverity
|
||||
```
|
||||
|
||||
|
@@ -16,21 +16,6 @@ all your email addresses you intend to use in the context of coreboot
|
||||
development so that commits with your email address in them are associated with
|
||||
you properly.
|
||||
|
||||
Below is a list of its SSH host keys and fingerprints.
|
||||
```Bash
|
||||
[review.coreboot.org]:29418 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAvNDn8qGHlWM/5ndFltStlg3QTc8xvGOgyjxxZByhMZx8LVE4cfgF38WP3euq0avyFy7gAJNghHorXpYKoOzuQPn2WNi5QhyGsUhg7ZJz9hC7Z2gqxxsZF3E7rku4Uj9sN7hWx9fBngxD4z2tP4y/18FTT5XTMcC3Q2sBCOLM0XVAO5R/nb2GO3d27avy+sanKAFEwJHnZ996IoTlU8JJFyi1Y6g30dC2K75oFgCtzntxf++wvrkkKPa+CFQub8fp20shat9WwX9kXjpRjt/Yv9LgqFCaI5ztJvWXicAmbgghGVzbzz4GoSjjF9cxxJF//KTmNb4iGQqmP3Olm27xuw==
|
||||
|
||||
[review.coreboot.org]:29418 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBzlwf/bFejt4EEz1QmbNOfK/HN1NtdcefrRs5Gs42uGnIvjxsff+vEF3//jCTvFPadoy3DrPsbQB3ioQAcYppk=
|
||||
|
||||
[review.coreboot.org]:29418 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOC3Z32gc+1rJXhKX+SW0vESlXR/h/mhcxd+62B1PWC2
|
||||
```
|
||||
|
||||
```Bash
|
||||
2048 SHA256:WW5prF7YE3MTnkRIxLklr9Gxddj9s5BZKUqWJF5dnTg review.coreboot.org:29418 (RSA)
|
||||
256 SHA256:IuLv/DgrBtVn36eMP1zFD0ISAl3IxIoCeiRms6UDhZc review.coreboot.org:29418 (ECDSA)
|
||||
256 SHA256:QFZieVHy8dCRl9tDib6qiwELnfa7SVU4ZWJ5VrXoC8k review.coreboot.org:29418 (ED25519)
|
||||
```
|
||||
|
||||
### https push access
|
||||
When using the https URLs to git repositories, you can push with the "HTTP
|
||||
Credentials" you can have Gerrit generate for you on that page. By default,
|
||||
|
@@ -4,7 +4,7 @@
|
||||
|
||||
[Flashmap](https://code.google.com/p/flashmap) (FMAP) is a binary format to
|
||||
describe partitions in a flash chip. It was added to coreboot to support the
|
||||
requirements of ChromiumOS firmware but then was also used in other scenarios
|
||||
requirements of Chromium OS firmware but then was also used in other scenarios
|
||||
where precise placement of data in flash was necessary, or for data that is
|
||||
written to at runtime, as CBFS is considered too fragile for such situations.
|
||||
The Flashmap implementation inside coreboot is the de facto standard today.
|
||||
|
@@ -8,8 +8,8 @@ BIOS image to be used across a wide variety of devices which may have key differ
|
||||
otherwise similar enough to use the same coreboot build target.
|
||||
|
||||
The initial implementation is designed to take advantage of a bitmask returned by the Embedded
|
||||
Controller on Google ChromeOS devices which allows the manufacturer to use the same firmware
|
||||
image across multiple devices by selecting various options at runtime. See the ChromiumOS
|
||||
Controller on Google Chrome OS devices which allows the manufacturer to use the same firmware
|
||||
image across multiple devices by selecting various options at runtime. See the Chromium OS
|
||||
[Firmware Config][1] documentation for more information.
|
||||
|
||||
This firmware configuration interface differs from the CMOS option interface in that this
|
||||
@@ -91,7 +91,7 @@ file in CBFS use the value it contains when matching fields and options.
|
||||
|
||||
### Embedded Controller
|
||||
|
||||
Google ChromeOS devices support an Embedded Controller interface for reading and writing the
|
||||
Google Chrome OS devices support an Embedded Controller interface for reading and writing the
|
||||
firmware configuration value, along with other board-specific information. It is possible for
|
||||
coreboot to read this value at boot on systems that support this feature.
|
||||
|
||||
@@ -101,9 +101,9 @@ possible by enabling the CBFS source and coreboot will look in CBFS first for a
|
||||
before asking the embedded controller.
|
||||
|
||||
It is also possible to adjust the value in the embedded controller *(after disabling write
|
||||
protection)* with the `ectool` command in a ChromeOS environment.
|
||||
protection)* with the `ectool` command in a Chrome OS environment.
|
||||
|
||||
For more information on the firmware configuration field on ChromeOS devices see the Chromium
|
||||
For more information on the firmware configuration field on Chrome OS devices see the Chromium
|
||||
documentation for [Firmware Config][1] and [Board Info][2].
|
||||
|
||||
[1]: http://chromium.googlesource.com/chromiumos/docs/+/master/design_docs/firmware_config.md
|
||||
|
@@ -134,7 +134,7 @@ SPI_ROM1 header while the board is off and disconnected from power. There
|
||||
seems to be a diode that prevents the external programmer from powering the
|
||||
whole board.
|
||||
|
||||
The signal assignment on the header is identical to the pinout of the flash
|
||||
The signal assigment on the header is identical to the pinout of the flash
|
||||
chip. The pinout diagram below is valid when the PCI slots are on the left
|
||||
and the CPU is on the right. Note that HOLD# and WP# must be pulled high
|
||||
(to VCC) to be able to flash the chip.
|
||||
|
@@ -30,7 +30,6 @@ This section contains documentation about coreboot on specific mainboards.
|
||||
- [P8H77-V](asus/p8h77-v.md)
|
||||
- [P8Z77-M Pro](asus/p8z77-m_pro.md)
|
||||
- [P8Z77-V](asus/p8z77-v.md)
|
||||
- [wifigo_v1](asus/wifigo_v1.md)
|
||||
|
||||
## Cavium
|
||||
|
||||
@@ -181,12 +180,10 @@ The boards in this section are not real mainboards, but emulators.
|
||||
|
||||
## Star Labs Systems
|
||||
|
||||
- [LabTop Mk III](starlabs/labtop_kbl.md)
|
||||
- [LabTop Mk IV](starlabs/labtop_cml.md)
|
||||
- [StarLite Mk III](starlabs/lite_glk.md)
|
||||
- [StarLite Mk IV](starlabs/lite_glkr.md)
|
||||
- [StarBook Mk V](starlabs/starbook_tgl.md)
|
||||
- [Flashing devices](starlabs/common/flashing.md)
|
||||
|
||||
## Supermicro
|
||||
|
||||
|
@@ -16,7 +16,7 @@ fwupdmgr --version
|
||||
```
|
||||
|
||||
This will show the version number. **1.5.6** or greater will work.
|
||||

|
||||

|
||||
On Ubuntu 20.04, Ubuntu 20.10, Linux Mint 20.1 and elementaryOS 6, fwupd 1.5.6 can be installed from our PPA with the below terminal commands:
|
||||
|
||||
```
|
||||
@@ -40,7 +40,7 @@ BIOS Lock must be disabled when switching from the standard AMI (American Megatr
|
||||
2\. When the BIOS settings load, use the arrow keys to navigate to the **Advanced** tab\. Here you will see **BIOS Lock**\.
|
||||
3\. Press `Enter` to change this setting from **Enabled** to **Disabled**
|
||||
|
||||

|
||||

|
||||
|
||||
4\. Next, press the `F10` key to **Save & Exit** and then `Enter` to confirm.
|
||||
|
||||
@@ -61,7 +61,7 @@ fwupdmgr switch-branch
|
||||
```
|
||||
|
||||
You can then select which branch you would like to use, by typing in the corresponding number:
|
||||

|
||||

|
||||
You will be prompted to confirm, press `y` to continue or `n` to cancel.
|
||||
|
||||
Once the switch has been completed, you will be prompted to restart.
|
||||
|
@@ -1,83 +0,0 @@
|
||||
# Star LabTop Mk III
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU (full processor specs available at https://ark.intel.com)
|
||||
- Intel i7-8550u (Kaby Lake Refresh)
|
||||
- EC
|
||||
- ITE IT8987E
|
||||
- Backlit Keyboard, with standard PS/2 keycodes and SCI hotkeys
|
||||
- Battery
|
||||
- Charger, using AC adapter or USB-C PD
|
||||
- Suspend / resume
|
||||
- GPU
|
||||
- Intel UHD Graphics 620
|
||||
- GOP driver is recommended, VBT is provided
|
||||
- eDP 13-inch 1920x1080 LCD
|
||||
- HDMI video
|
||||
- USB-C DisplayPort video
|
||||
- Memory
|
||||
- 8GB on-board
|
||||
- Networking
|
||||
- 8265 PCIe WiFi / Bluetooth soldered to PCBA
|
||||
- Sound
|
||||
- Realtek ALC256
|
||||
- Internal speakers
|
||||
- Internal microphone
|
||||
- Combined headphone / microphone 3.5-mm jack
|
||||
- HDMI audio
|
||||
- USB-C DisplayPort audio
|
||||
- Storage
|
||||
- M.2 PCIe SSD
|
||||
- RTS5129 MicroSD card reader
|
||||
- USB
|
||||
- 1280x720 CCD camera
|
||||
- USB 3.1 Gen 2 Type-C (left)
|
||||
- USB 3.1 Gen 2 Type-A (left)
|
||||
- USB 3.1 Gen 1 Type-A (right)
|
||||
|
||||
## Building coreboot
|
||||
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* Intel Management Engine firmware (me.bin)
|
||||
|
||||
The below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_labtop_kbl
|
||||
make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Vendor | Gigadevice |
|
||||
+---------------------+------------+
|
||||
| Model | 25Q128JVSQ |
|
||||
+---------------------+------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
|
||||
Please see [here](../common/flashing.md) for instructions on how to flash with fwupd.
|
@@ -3,7 +3,7 @@
|
||||
All Haswell boards supported by coreboot currently require a proprietary
|
||||
blob in order to initialise the DRAM and a few other components. The
|
||||
blob, named `mrc.bin`, largely consists of Intel's memory reference code
|
||||
(MRC), but it has been tailored specifically for ChromeOS. It is just
|
||||
(MRC), but it has been tailored specifically for Chrome OS. It is just
|
||||
under 200 KiB in size. Another name for `mrc.bin` is the system agent
|
||||
binary.
|
||||
|
||||
|
@@ -1899,7 +1899,7 @@ Please handle with care!
|
||||
+===========+==================================================================+
|
||||
| 0:7| PDWN_idle_counter, This defines the rank indle period in DCLK |
|
||||
| | cycles that causes power-down entrance. The minimum value |
|
||||
| | should be greater than or equal to the worst roundtrip time |
|
||||
| | should be greater then or equal to the worst roundtrip time |
|
||||
| | plus burst length. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 8:10| PDWN_mode, selects the mode of power-down: |
|
||||
|
@@ -11,17 +11,9 @@ payload or can be made to work as one.
|
||||
|
||||
[SeaBIOS](https://www.seabios.org) is an open source implementation of
|
||||
the PCBIOS API that exists since the original IBM PC and was extended
|
||||
since. While originally written for emulators such as QEMU, it can be built
|
||||
as a coreboot payload. It supports executing Option ROMs in a more complete
|
||||
fashion than coreboot. It also supports Multiboot.
|
||||
|
||||
When chainloaded from GRUB2, the following menuentry could be used:
|
||||
|
||||
menuentry "SeaBIOS" --unrestricted {
|
||||
root=(cbfsdisk)
|
||||
multiboot /img/seabios
|
||||
module /vgaroms/seavgabios.bin
|
||||
}
|
||||
since. While originally written for emulators such as QEMU, it can be made
|
||||
to work as a coreboot payload and all the necessary code is in SeaBIOS'
|
||||
mainline code.
|
||||
|
||||
## Tianocore
|
||||
|
||||
@@ -59,4 +51,4 @@ updates, but only works on a limited amount of mainboards.
|
||||
For more details have a look at [heads-wiki].
|
||||
|
||||
[Heads]: https://github.com/osresearch/heads
|
||||
[heads-wiki]: http://osresearch.net/
|
||||
[heads-wiki]: http://osresearch.net/
|
@@ -1,326 +0,0 @@
|
||||
# Platforms supported on branches
|
||||
|
||||
For one reason or another, platforms have been deleted from the master
|
||||
branch at times in the past. Early on, there was no real policy on
|
||||
removing boards. Now the policy is that boards will only be removed if
|
||||
they're causing issues in the tree or if they're preventing progress.
|
||||
|
||||
This does not mean that these boards are gone forever. The release or
|
||||
commit prior to where they were removed can be checked out, and the
|
||||
boards can still be built there and updated in a release branch if
|
||||
desired.
|
||||
|
||||
Currently, [jenkins](https://qa.coreboot.org), our continuous
|
||||
integration system is configured to build the 4.11, 4.12, 4.14, 4.15,
|
||||
and 4.16 branches. Builders for other branches can be created on
|
||||
request. Likewise, some releases are only marked with tags, and
|
||||
branches would need to be created to push new code to. These branches
|
||||
can also be created on request.
|
||||
|
||||
Patches can be backported from the master branch to any of these other
|
||||
branches as needed. The coreboot project will take care of backporting
|
||||
critical security fixes, but other patches will need to handled by
|
||||
anyone using that release.
|
||||
|
||||
## [4.16 Release](coreboot-4.16-relnotes.md)
|
||||
Branch created, builder configured
|
||||
|
||||
* No platforms maintained on this release
|
||||
|
||||
|
||||
## [4.15 Release](coreboot-4.15-relnotes.md)
|
||||
Branch created, builder configured
|
||||
|
||||
* No platforms maintained on this release
|
||||
|
||||
|
||||
## [4.14 Release](coreboot-4.14-relnotes.md)
|
||||
Branch created, builder configured
|
||||
|
||||
* No platforms maintained on this release
|
||||
|
||||
|
||||
## [4.13 Release](coreboot-4.13-relnotes.md)
|
||||
Tag only
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| intel/cannonlake_rvp | INTEL_CANNONLAKE | 2017-07-19 | eval |
|
||||
|
||||
|
||||
## [4.12 Release](coreboot-4.12-relnotes.md)
|
||||
|
||||
Branch created, builder configured
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| bap/ode_e21XX | AMD_PI_00730F01 | 2016-07-30 | eval |
|
||||
| lippert/toucan-af | AMD_FAMILY14 | 2013-03-02 | half |
|
||||
| ocp/sonorapass | INTEL_COOPERLAKE_SP | 2020-05-01 | server |
|
||||
|
||||
|
||||
## [4.11 Release](coreboot-4.11-relnotes.md)
|
||||
|
||||
Branch created, builder configured
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| adi/rcc-dff | INTEL_FSP_RANGELEY | 2016-06-08 | eval |
|
||||
| advansus/a785e-i | AMD_AMDFAM10 | 2011-05-07 | mini |
|
||||
| amd/bettong | AMD_PI_00660F01 | 2015-06-23 | eval |
|
||||
| amd/bimini_fam10 | AMD_AMDFAM10 | 2011-01-01 | eval |
|
||||
| amd/db-ft3b-lc | AMD_PI_00730F01 | 2016-07-20 | eval |
|
||||
| amd/gardenia | AMD_STONEYRIDGE_FP4 | 2016-12-16 | eval |
|
||||
| amd/lamar | AMD_PI_00630F01 | 2015-04-23 | eval |
|
||||
| amd/mahogany_fam10 | AMD_AMDFAM10 | 2010-03-16 | eval |
|
||||
| amd/olivehillplus | AMD_PI_00730F01 | 2014-09-04 | eval |
|
||||
| amd/serengeti_cheetah_fam10 | AMD_AMDFAM10 | 2009-10-09 | server |
|
||||
| amd/tilapia_fam10 | AMD_AMDFAM10 | 2010-04-23 | eval |
|
||||
| amd/torpedo | AMD_FAMILY12 | 2011-06-28 | eval |
|
||||
| asus/kcma-d8 | AMD_AMDFAM10 | 2016-02-05 | server |
|
||||
| asus/kfsn4-dre | AMD_AMDFAM10 | 2015-01-28 | server |
|
||||
| asus/kgpe-d16 | AMD_AMDFAM10 | 2015-10-28 | server |
|
||||
| asus/m4a785-m | AMD_AMDFAM10 | 2010-09-13 | desktop |
|
||||
| asus/m4a785t-m | AMD_AMDFAM10 | 2011-12-02 | desktop |
|
||||
| asus/m4a78-em | AMD_AMDFAM10 | 2010-12-06 | desktop |
|
||||
| asus/m5a88-v | AMD_AMDFAM10 | 2011-10-28 | desktop |
|
||||
| avalue/eax-785e | AMD_AMDFAM10 | 2011-09-14 | desktop |
|
||||
| esd/atom15 | INTEL_FSP_BAYTRAIL | 2015-12-04 | sbc |
|
||||
| facebook/watson | INTEL_FSP_BROADWELL_DE | 2018-06-26 | server |
|
||||
| gigabyte/ma785gm | AMD_AMDFAM10 | 2012-04-23 | desktop |
|
||||
| gigabyte/ma785gmt | AMD_AMDFAM10 | 2010-08-17 | desktop |
|
||||
| gigabyte/ma78gm | AMD_AMDFAM10 | 2010-08-17 | desktop |
|
||||
| google/urara | IMGTEC_PISTACHIO | 2015-03-27 | eval |
|
||||
| hp/dl165_g6_fam10 | AMD_AMDFAM10 | 2010-09-24 | server |
|
||||
| iei/kino-780am2-fam10 | AMD_AMDFAM10 | 2010-09-13 | half |
|
||||
| intel/bayleybay_fsp | INTEL_FSP_BAYTRAIL | 2014-05-30 | eval |
|
||||
| intel/camelbackmountain_fsp | INTEL_FSP_BROADWELL_DE | 2016-04-15 | eval |
|
||||
| intel/littleplains | INTEL_FSP_RANGELEY | 2015-11-30 | eval |
|
||||
| intel/minnowmax | INTEL_FSP_BAYTRAIL | 2014-08-11 | sbc |
|
||||
| intel/mohonpeak | INTEL_FSP_RANGELEY | 2014-07-30 | eval |
|
||||
| jetway/pa78vm5 | AMD_AMDFAM10 | 2010-08-17 | desktop |
|
||||
| msi/ms9652_fam10 | AMD_AMDFAM10 | 2010-03-01 | desktop |
|
||||
| ocp/monolake | INTEL_FSP_BROADWELL_DE | 2018-05-05 | server |
|
||||
| ocp/wedge100s | INTEL_FSP_BROADWELL_DE | 2018-05-05 | server |
|
||||
| opencellular/rotundu | INTEL_FSP_BAYTRAIL | 2018-06-26 | sbc |
|
||||
| siemens/mc_bdx1 | INTEL_FSP_BROADWELL_DE | 2016-04-29 | misc |
|
||||
| siemens/mc_tcu3 | INTEL_FSP_BAYTRAIL | 2015-03-05 | misc |
|
||||
| siemens/mc_tcu3 | INTEL_FSP_BAYTRAIL_MD | 2015-03-05 | misc |
|
||||
| supermicro/h8dmr_fam10 | AMD_AMDFAM10 | 2009-10-09 | server |
|
||||
| supermicro/h8qme_fam10 | AMD_AMDFAM10 | 2010-02-03 | server |
|
||||
| supermicro/h8scm_fam10 | AMD_AMDFAM10 | 2011-03-28 | server |
|
||||
| tyan/s2912_fam10 | AMD_AMDFAM10 | 2009-10-08 | server |
|
||||
| via/epia-m850 | VIA_NANO | 2013-06-10 | mini |
|
||||
| via/epia-m850 | VIA_VX900 | 2013-06-10 | mini |
|
||||
|
||||
|
||||
## [4.10 Release](coreboot-4.10-relnotes.md)
|
||||
Branch created
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| cubietech/cubieboard | ALLWINNER_A10 | 2014-01-08 | sbc |
|
||||
|
||||
|
||||
## [4.9 Release](coreboot-4.9-relnotes.md)
|
||||
Tag only
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| pcengines/alix1c | AMD_GEODE_LX | 2009-10-08 | half |
|
||||
| pcengines/alix1c | AMD_LX | 2009-10-08 | half |
|
||||
| pcengines/alix2d | AMD_GEODE_LX | 2010-08-31 | half |
|
||||
| pcengines/alix2d | AMD_LX | 2010-08-31 | half |
|
||||
|
||||
|
||||
## [4.8.1 Release](coreboot-4.8.1-relnotes.md)
|
||||
Branch created
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| aaeon/pfm-540i_revb | AMD_GEODE_LX | 2011-06-29 | half |
|
||||
| amd/db800 | AMD_GEODE_LX | 2009-10-09 | eval |
|
||||
| amd/dbm690t | AMD_AMDK8 | 2009-10-09 | eval |
|
||||
| amd/f2950 | AMD_GEODE_LX | 2016-07-17 | mini |
|
||||
| amd/mahogany | AMD_AMDK8 | 2010-03-16 | eval |
|
||||
| amd/norwich | AMD_GEODE_LX | 2009-10-09 | eval |
|
||||
| amd/pistachio | AMD_AMDK8 | 2009-10-09 | eval |
|
||||
| amd/serengeti_cheetah | AMD_AMDK8 | 2009-08-12 | server |
|
||||
| artecgroup/dbe61 | AMD_GEODE_LX | 2009-10-08 | settop |
|
||||
| asrock/939a785gmh | AMD_AMDK8 | 2010-04-05 | desktop |
|
||||
| asus/a8n_e | AMD_AMDK8 | 2009-10-09 | desktop |
|
||||
| asus/a8v-e_deluxe | AMD_AMDK8 | 2010-11-14 | desktop |
|
||||
| asus/a8v-e_se | AMD_AMDK8 | 2009-10-09 | desktop |
|
||||
| asus/k8v-x | AMD_AMDK8 | 2011-12-02 | desktop |
|
||||
| asus/kfsn4-dre_k8 | AMD_AMDK8 | 2015-10-30 | server |
|
||||
| asus/m2n-e | AMD_AMDK8 | 2010-12-13 | desktop |
|
||||
| asus/m2v | AMD_AMDK8 | 2010-11-07 | desktop |
|
||||
| asus/m2v-mx_se | AMD_AMDK8 | 2009-08-26 | desktop |
|
||||
| bachmann/ot200 | AMD_GEODE_LX | 2012-07-13 | settop |
|
||||
| bcom/winnetp680 | VIA_C7 | 2009-10-07 | settop |
|
||||
| broadcom/blast | AMD_AMDK8 | 2009-10-09 | eval |
|
||||
| digitallogic/msm800sev | AMD_GEODE_LX | 2009-10-09 | half |
|
||||
| gigabyte/ga_2761gxdk | AMD_AMDK8 | 2009-10-07 | desktop |
|
||||
| gigabyte/m57sli | AMD_AMDK8 | 2009-10-03 | desktop |
|
||||
| google/purin | BROADCOM_CYGNUS | 2015-04-17 | eval |
|
||||
| google/rotor | MARVELL_MVMAP2315 | 2016-09-13 | laptop |
|
||||
| google/zoombini | INTEL_CANNONLAKE | 2017-09-28 | laptop |
|
||||
| hp/dl145_g1 | AMD_AMDK8 | 2010-08-20 | server |
|
||||
| hp/dl145_g3 | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| iei/pcisa-lx-800-r10 | AMD_GEODE_LX | 2009-10-08 | half |
|
||||
| iei/pm-lx2-800-r10 | AMD_GEODE_LX | 2012-10-28 | half |
|
||||
| iei/pm-lx-800-r11 | AMD_GEODE_LX | 2012-07-06 | half |
|
||||
| intel/cougar_canyon2 | INTEL_FSP_IVYBRIDGE | 2013-12-04 | eval |
|
||||
| intel/stargo2 | INTEL_FSP_IVYBRIDGE | 2015-11-10 | eval |
|
||||
| iwill/dk8_htx | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| jetway/j7f2 | VIA_C7 | 2014-01-19 | mini |
|
||||
| kontron/kt690 | AMD_AMDK8 | 2009-10-15 | mini |
|
||||
| lippert/hurricane-lx | AMD_GEODE_LX | 2010-09-10 | half |
|
||||
| lippert/literunner-lx | AMD_GEODE_LX | 2010-09-07 | half |
|
||||
| lippert/roadrunner-lx | AMD_GEODE_LX | 2009-10-08 | half |
|
||||
| lippert/spacerunner-lx | AMD_GEODE_LX | 2009-10-08 | half |
|
||||
| lowrisc/nexys4ddr | LOWRISC_LOWRISC | 2016-10-28 | eval |
|
||||
| msi/ms7135 | AMD_AMDK8 | 2009-10-07 | desktop |
|
||||
| msi/ms7260 | AMD_AMDK8 | 2009-10-07 | desktop |
|
||||
| msi/ms9185 | AMD_AMDK8 | 2009-10-07 | server |
|
||||
| msi/ms9282 | AMD_AMDK8 | 2009-10-07 | server |
|
||||
| nvidia/l1_2pvv | AMD_AMDK8 | 2009-10-07 | eval |
|
||||
| siemens/sitemp_g1p1 | AMD_AMDK8 | 2011-05-11 | half |
|
||||
| sunw/ultra40 | AMD_AMDK8 | 2009-09-25 | desktop |
|
||||
| sunw/ultra40m2 | AMD_AMDK8 | 2015-11-10 | desktop |
|
||||
| supermicro/h8dme | AMD_AMDK8 | 2009-09-25 | server |
|
||||
| supermicro/h8dmr | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| technexion/tim5690 | AMD_AMDK8 | 2009-10-13 | half |
|
||||
| technexion/tim8690 | AMD_AMDK8 | 2009-10-08 | half |
|
||||
| traverse/geos | AMD_GEODE_LX | 2010-05-20 | half |
|
||||
| tyan/s2912 | AMD_AMDK8 | 2009-10-08 | server |
|
||||
| via/epia-cn | VIA_C7 | 2009-09-25 | mini |
|
||||
| via/epia-m700 | VIA_C7 | 2009-09-25 | mini |
|
||||
| via/pc2500e | VIA_C7 | 2009-09-25 | mini |
|
||||
| via/vt8454c | VIA_C7 | 2009-08-20 | eval |
|
||||
| winent/mb6047 | AMD_AMDK8 | 2013-10-19 | half |
|
||||
| winent/pl6064 | AMD_GEODE_LX | 2010-02-24 | desktop |
|
||||
| winnet/g170 | VIA_C7 | 2017-08-28 | mini |
|
||||
|
||||
|
||||
## [4.7 Release](coreboot-4.7-relnotes.md)
|
||||
Tag only
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| abit/be6-ii_v2_0 | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| amd/dinar | AMD_FAMILY15 | 2012-02-17 | eval |
|
||||
| amd/rumba | AMD_GEODE_GX2 | 2009-08-29 | half |
|
||||
| asus/dsbf | INTEL_I5000 | 2012-07-14 | server |
|
||||
| asus/mew-am | INTEL_I82810 | 2009-08-28 | desktop |
|
||||
| asus/mew-vm | INTEL_I82810 | 2009-08-28 | desktop |
|
||||
| a-trend/atc-6220 | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| a-trend/atc-6240 | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| azza/pt-6ibd | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| biostar/m6tba | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| compaq/deskpro_en_sff_p600 | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| dmp/vortex86ex | DMP_VORTEX86EX | 2013-07-05 | sbc |
|
||||
| ecs/p6iwp-fe | INTEL_I82810 | 2010-06-09 | desktop |
|
||||
| gigabyte/ga-6bxc | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| gigabyte/ga-6bxe | INTEL_I440BX | 2010-05-14 | desktop |
|
||||
| hp/e_vectra_p2706t | INTEL_I82810 | 2009-10-20 | desktop |
|
||||
| intel/d810e2cb | INTEL_I82810 | 2010-06-21 | desktop |
|
||||
| intel/eagleheights | INTEL_I3100 | 2009-09-25 | eval |
|
||||
| intel/mtarvon | INTEL_I3100 | 2009-09-25 | eval |
|
||||
| intel/truxton | INTEL_I3100 | 2009-09-25 | eval |
|
||||
| iwave/iWRainbowG6 | INTEL_SCH | 2010-12-18 | half |
|
||||
| lanner/em8510 | INTEL_I855 | 2010-08-30 | desktop |
|
||||
| lippert/frontrunner | AMD_GEODE_GX2 | 2009-10-08 | half |
|
||||
| mitac/6513wu | INTEL_I82810 | 2009-08-28 | desktop |
|
||||
| msi/ms6119 | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| msi/ms6147 | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| msi/ms6156 | INTEL_I440BX | 2009-10-13 | desktop |
|
||||
| msi/ms6178 | INTEL_I82810 | 2009-08-28 | desktop |
|
||||
| nec/powermate2000 | INTEL_I82810 | 2009-08-28 | desktop |
|
||||
| nokia/ip530 | INTEL_I440BX | 2010-04-19 | server |
|
||||
| rca/rm4100 | INTEL_I82830 | 2009-10-07 | settop |
|
||||
| soyo/sy-6ba-plus-iii | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| supermicro/h8qgi | AMD_FAMILY15 | 2011-07-22 | server |
|
||||
| supermicro/h8scm | AMD_FAMILY15 | 2012-11-30 | server |
|
||||
| supermicro/x7db8 | INTEL_I5000 | 2012-06-23 | server |
|
||||
| thomson/ip1000 | INTEL_I82830 | 2009-10-08 | settop |
|
||||
| tyan/s1846 | INTEL_I440BX | 2009-08-26 | desktop |
|
||||
| tyan/s8226 | AMD_FAMILY15 | 2012-10-04 | server |
|
||||
| wyse/s50 | AMD_GEODE_GX2 | 2010-05-08 | settop |
|
||||
|
||||
|
||||
## [4.6](coreboot-4.6-relnotes.md)
|
||||
Tag only
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| bifferos/bifferboard | RDC_R8610 | 2012-03-27 | half |
|
||||
| google/cosmos | MARVELL_BG4CD | 2015-04-09 | eval |
|
||||
| intel/bakersport_fsp | INTEL_FSP_BAYTRAIL | 2014-08-11 | eval |
|
||||
|
||||
|
||||
## [4.5](coreboot-4.5-relnotes.md)
|
||||
Tag only
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| google/enguarde | INTEL_BAYTRAIL | 2016-09-21 | laptop |
|
||||
| google/falco | INTEL_HASWELL | 2013-11-25 | laptop |
|
||||
| google/guado | INTEL_BROADWELL | 2016-01-12 | half |
|
||||
| google/ninja | INTEL_BAYTRAIL | 2016-05-31 | half |
|
||||
| google/panther | INTEL_HASWELL | 2014-07-12 | half |
|
||||
| google/peppy | INTEL_HASWELL | 2013-11-25 | laptop |
|
||||
| google/rikku | INTEL_BROADWELL | 2016-06-16 | half |
|
||||
| google/samus | INTEL_BROADWELL | 2014-08-29 | laptop |
|
||||
| google/tidus | INTEL_BROADWELL | 2016-01-21 | half |
|
||||
|
||||
|
||||
## [4.4](coreboot-4.4-relnotes.md)
|
||||
Branch created
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| google/bolt | INTEL_HASWELL | 2013-12-12 | eval |
|
||||
| google/rush | NVIDIA_TEGRA132 | 2015-01-26 | eval |
|
||||
| google/rush_ryu | NVIDIA_TEGRA132 | 2015-03-05 | eval |
|
||||
| google/slippy | INTEL_HASWELL | 2013-11-24 | eval |
|
||||
| intel/amenia | INTEL_APOLLOLAKE | 2016-04-20 | eval |
|
||||
|
||||
|
||||
## [4.3](coreboot-4.3-relnotes.md)
|
||||
Branch created
|
||||
|
||||
* No platforms maintained on this release
|
||||
|
||||
|
||||
## [4.2](coreboot-4.2-relnotes.md)
|
||||
Branch created
|
||||
|
||||
| Vendor/Board | Processor | Date added | Brd type |
|
||||
|-----------------------------|------------------------|------------|----------|
|
||||
| arima/hdama | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| digitallogic/adl855pc | INTEL_I855 | 2009-10-09 | half |
|
||||
| ibm/e325 | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| ibm/e326 | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| intel/sklrvp | INTEL_SKYLAKE | 2015-07-17 | eval |
|
||||
| iwill/dk8s2 | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| iwill/dk8x | AMD_AMDK8 | 2009-10-09 | server |
|
||||
| newisys/khepri | AMD_AMDK8 | 2009-10-07 | server |
|
||||
| tyan/s2735 | INTEL_E7501 | 2009-10-08 | server |
|
||||
| tyan/s2850 | AMD_AMDK8 | 2009-09-25 | server |
|
||||
| tyan/s2875 | AMD_AMDK8 | 2009-09-25 | desktop |
|
||||
| tyan/s2880 | AMD_AMDK8 | 2009-10-08 | server |
|
||||
| tyan/s2881 | AMD_AMDK8 | 2009-09-23 | server |
|
||||
| tyan/s2882 | AMD_AMDK8 | 2009-10-08 | server |
|
||||
| tyan/s2885 | AMD_AMDK8 | 2009-10-08 | desktop |
|
||||
| tyan/s2891 | AMD_AMDK8 | 2009-09-22 | server |
|
||||
| tyan/s2892 | AMD_AMDK8 | 2009-09-22 | server |
|
||||
| tyan/s2895 | AMD_AMDK8 | 2009-09-22 | desktop |
|
||||
| tyan/s4880 | AMD_AMDK8 | 2009-10-08 | server |
|
||||
| tyan/s4882 | AMD_AMDK8 | 2009-10-08 | server |
|
||||
|
||||
|
||||
## [4.1](coreboot-4.1-relnotes.md)
|
||||
Branch Created
|
||||
|
||||
* No platforms maintained on this release
|
@@ -132,7 +132,7 @@ HECI based on Intel Core processors from Skylake to Alder Lake. State is
|
||||
set based on a CMOS value of `me_state`. A value of `0` will result in a
|
||||
(CS)ME state of `0` (working) and value of `1` will result in a (CS)ME
|
||||
state of `3` (disabled). For an example CMOS layout and more info, see
|
||||
[cse.c](https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/soc/intel/common/block/cse/cse.c).
|
||||
[cse.c](../../src/soc/intel/common/block/cse/cse.c).
|
||||
|
||||
|
||||
### Add [AMD] apcb_v3_edit tool
|
||||
|
@@ -1,345 +1,19 @@
|
||||
coreboot 4.17
|
||||
========================================================================
|
||||
Upcoming release - coreboot 4.17
|
||||
================================
|
||||
|
||||
The coreboot 4.17 release was done on June 3, 2022.
|
||||
The 4.17 release is planned for May, 2022.
|
||||
|
||||
Since the 4.16 release, we've had over 1300 new commits by around 150
|
||||
contributors. Of those people, roughly 15 were first-time contributors.
|
||||
We are continuing the quarterly release cadence in order to enable others to
|
||||
release quarterly on a fresher version of coreboot.
|
||||
|
||||
As always, we appreciate everyone who has contributed and done the hard
|
||||
work to make the coreboot project successful.
|
||||
Update this document with changes that should be in the release notes.
|
||||
|
||||
* Please use Markdown.
|
||||
* See the past few release notes for the general format.
|
||||
* The chip and board additions and removals will be updated right
|
||||
before the release, so those do not need to be added.
|
||||
|
||||
Major Bugfixes in this release
|
||||
------------------------------
|
||||
* [CVE-2022-29264](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29264)
|
||||
Significant changes
|
||||
-------------------
|
||||
|
||||
|
||||
New Mainboards
|
||||
--------------
|
||||
|
||||
* Clevo L140MU / L141MU / L142MU
|
||||
* Dell Precision T1650
|
||||
* Google Craask
|
||||
* Google Gelarshie
|
||||
* Google Kuldax
|
||||
* Google Mithrax
|
||||
* Google Osiris
|
||||
* HP Z220 CMT Workstation
|
||||
* Star Labs LabTop Mk III (i7-8550u)
|
||||
* Star Labs LabTop Mk IV (i3-10110U and i7-10710U)
|
||||
* Star Labs Lite Mk III (N5000)
|
||||
* Star Labs Lite Mk IV (N5030)
|
||||
|
||||
|
||||
Removed Mainboards
|
||||
------------------
|
||||
|
||||
* Google Deltan
|
||||
* Google Deltaur
|
||||
|
||||
Significant or interesting changes
|
||||
----------------------------------
|
||||
|
||||
These changes are a few that were selected as a sampling of particularly
|
||||
interesting commits.
|
||||
|
||||
|
||||
### CBMEM init hooks changed
|
||||
|
||||
Instead of having per stage x_CBMEM_INIT_HOOK, we now have only 2 hooks:
|
||||
* CBMEM_CREATION_HOOK: Used only in the first stage that creates cbmem,
|
||||
typically romstage. For instance code that migrates data from cache
|
||||
as ram to dram would use this hook.
|
||||
* CBMEM_READY_HOOK: Used in every stage that has cbmem. An example would
|
||||
be initializing the cbmem console by appending to what previous stages
|
||||
logged.
|
||||
The reason for this change is improved flexibility with regards to which
|
||||
stage initializes cbmem.
|
||||
|
||||
|
||||
### Payloads
|
||||
|
||||
* SeaBIOS: Update stable release from 1.14.0 to 1.16.0
|
||||
* iPXE: Update stable release from 2019.3 to 2022.1
|
||||
* Add "GRUB2 atop SeaBIOS" aka "SeaGRUB" option, which builds GRUB2 as a
|
||||
secondary payload for SeaBIOS with GRUB2 set as the default boot
|
||||
entry. This allows GRUB2 to use BIOS callbacks provided by SeaBIOS as
|
||||
a fallback method to access hardware that the native GRUB2 payload
|
||||
cannot access.
|
||||
* Add option to build SeaBIOS and GRUB2 as secondary payloads
|
||||
* Add new coreDOOM payload. See commit message below.
|
||||
|
||||
|
||||
### payloads/external: Add support for coreDOOM payload
|
||||
|
||||
coreDOOM is a port of DOOM to libpayload, based on the doomgeneric
|
||||
source port. It renders the game to the coreboot linear framebuffer,
|
||||
and loads WAD files from CBFS.
|
||||
|
||||
|
||||
### cpu/x86/smm_module_load: Rewrite setup_stub
|
||||
|
||||
This code was hard to read as it did too much and had a lot of state
|
||||
to keep track of.
|
||||
|
||||
It also looks like the staggered entry points were first copied and
|
||||
only later the parameters of the first stub were filled in. This
|
||||
means that only the BSP stub is actually jumping to the permanent
|
||||
smihandler. On the APs the stub would jump to wherever c_handler
|
||||
happens to point to, which is likely 0. This effectively means that on
|
||||
APs it's likely easy to have arbitrary code execution in SMM which is a
|
||||
security problem.
|
||||
|
||||
Note: This patch fixes CVE-2022-29264 for the 4.17 release.
|
||||
|
||||
|
||||
### cpu/x86/smm_module_loader.c: Rewrite setup
|
||||
|
||||
This code is much easier to read if one does not have to keep track of
|
||||
mutable variables.
|
||||
|
||||
This also fixes the alignment code on the TSEG smihandler setup code.
|
||||
It was aligning the code upwards instead of downwards which would cause
|
||||
it to encroach a part of the save state.
|
||||
|
||||
|
||||
### cpu/x86/smm: Add sinkhole mitigation to relocatable smmstub
|
||||
|
||||
The sinkhole exploit exists in placing the lapic base such that it
|
||||
messes with GDT. This can be mitigated by checking the lapic MSR
|
||||
against the current program counter.
|
||||
|
||||
|
||||
### cpu/x86/64bit: Generate static page tables from an assembly file
|
||||
|
||||
This removes the need for a tool to generate simple identity pages.
|
||||
Future patches will link this page table directly into the stages on
|
||||
some platforms so having an assembly file makes a lot of sense.
|
||||
|
||||
This also optimizes the size of the page of each 4K page by placing
|
||||
the PDPE_table below the PDE.
|
||||
|
||||
|
||||
### cpu/x86/smm,lib/cbmem_console: Enable CBMEMC when using DEBUG_SMI
|
||||
|
||||
This change will allow the SMI handler to write to the cbmem console
|
||||
buffer. Normally SMIs can only be debugged using some kind of serial
|
||||
port (UART). By storing the SMI logs into cbmem we can debug SMIs using
|
||||
'cbmem -1'. Now that these logs are available to the OS we could also
|
||||
verify there were no errors in the SMI handler.
|
||||
|
||||
Since SMM can write to all of DRAM, we can't trust any pointers
|
||||
provided by cbmem after the OS has booted. For this reason we store the
|
||||
cbmem console pointer as part of the SMM runtime parameters. The cbmem
|
||||
console is implemented as a circular buffer so it will never write
|
||||
outside of this area.
|
||||
|
||||
|
||||
### security/tpm/crtm: Add a function to measure the bootblock on SoC level
|
||||
|
||||
On platforms where the bootblock is not included in CBFS anymore
|
||||
because it is part of another firmware section (IFWI or a different
|
||||
CBFS), the CRTM measurement fails.
|
||||
|
||||
This patch adds a new function to provide a way at SoC level to measure
|
||||
the bootblock. Following patches will add functionality to retrieve the
|
||||
bootblock from the SoC related location and measure it from there.
|
||||
In this way the really executed code will be measured.
|
||||
|
||||
|
||||
### soc/amd/common/block/psp: Add platform secure boot support
|
||||
|
||||
Add Platform Secure Boot (PSB) enablement via the PSP if it is not
|
||||
already enabled. Upon receiving psb command, PSP will program PSB fuses
|
||||
as long as BIOS signing key token is valid.
|
||||
Refer to the AMD PSB user guide doc# 56654, Revision# 1.00.
|
||||
Unfortunately this document is only available with NDA customers.
|
||||
|
||||
|
||||
### drivers/intel/fsp2_0: Add native implementation for FSP Debug Handler
|
||||
|
||||
This patch implements coreboot native debug handler to manage the FSP
|
||||
event messages.
|
||||
|
||||
'FSP Event Handlers' feature introduced in FSP to generate event
|
||||
messages to aid in the debugging of firmware issues. This eliminates
|
||||
the need for FSP to directly write debug messages to the UART and FSP
|
||||
might not need to know the board related UART port configuration.
|
||||
Instead FSP signals the bootloader to inform it of a new debug message.
|
||||
This allows the coreboot to provide board specific methods of reporting
|
||||
debug messages, example: legacy UART or LPSS UART etc.
|
||||
|
||||
This implementation has several advantages as:
|
||||
1. FSP relies on XIP 'DebugLib' driver even while printing FSP-S debug
|
||||
messages, hence, without ROM being cached, post 'romstage' would
|
||||
results into sluggish boot with FSP debug enabled.
|
||||
This patch utilities coreboot native debug implementation which is
|
||||
XIP during FSP-M and relocatable to DRAM based resource for FSP-S.
|
||||
|
||||
2. This patch simplifies the FSP DebugLib implementation and remove the
|
||||
need to have serial port library. Instead coreboot 'printk' can be
|
||||
used for display FSP serial messages. Additionally, unifies the debug
|
||||
library between coreboot and FSP.
|
||||
|
||||
3. This patch is also useful to get debug prints even with FSP
|
||||
non-serial image (refer to 'Note' below) as FSP PEIMs are now
|
||||
leveraging coreboot debug library instead FSP 'NULL' DebugLib
|
||||
reference for release build.
|
||||
|
||||
4. Can optimize the FSP binary size by removing the DebugLib dependency
|
||||
from most of FSP PEIMs, for example: on Alder Lake FSP-M debug binary
|
||||
size is reduced by ~100KB+ and FSP-S debug library size is also
|
||||
reduced by ~300KB+ (FSP-S debug and release binary size is exactly
|
||||
same with this code changes). The total savings is ~400KB for each
|
||||
FSP copy, and in case of Chrome AP firmware with 3 copies, the total
|
||||
savings would be 400KB * 3 = ~1.2MB.
|
||||
|
||||
Note: Need to modify FSP source code to remove 'MDEPKG_NDEBUG' as
|
||||
compilation flag for release build and generate FSP binary with non-NULL
|
||||
FSP debug wrapper module injected (to allow FSP event handler to execute
|
||||
even with FSP non-serial image) in the final FSP.fd.
|
||||
|
||||
|
||||
### security/tpm: Add vendor-specific tis functions to read/write TPM regs
|
||||
|
||||
In order to abstract bus-specific logic from TPM logic, the prototype
|
||||
for two vendor-specific tis functions are added in this
|
||||
patch. tis_vendor_read() can be used to read directly from TPM
|
||||
registers, and tis_vendor_write() can be used to write directly to TPM
|
||||
registers.
|
||||
|
||||
|
||||
### arch/x86: Add support for catching null dereferences through debug regs
|
||||
|
||||
This commit adds support for catching null dereferences and execution
|
||||
through x86's debug registers. This is particularly useful when running
|
||||
32-bit coreboot as paging is not enabled to catch these through page
|
||||
faults. This commit adds three new configs to support this feature:
|
||||
DEBUG_HW_BREAKPOINTS, DEBUG_NULL_DEREF_BREAKPOINTS and
|
||||
DEBUG_NULL_DEREF_HALT.
|
||||
|
||||
|
||||
### drivers/i2c/generic: Add support for i2c device detection
|
||||
|
||||
Add 'detect' flag which can be attached to devices which may or may not
|
||||
be present at runtime, and for which coreboot should probe the i2c bus
|
||||
to confirm device presence prior to adding an entry for it in the SSDT.
|
||||
|
||||
This is useful for boards which may utilize touchpads/touchscreens from
|
||||
multiple vendors, so that only the device(s) present are added to the
|
||||
SSDT. This relieves the burden from the OS to detect/probe if a device
|
||||
is actually present and allows the OS to trust the ACPI _STA value.
|
||||
|
||||
|
||||
### util/cbmem: Add FlameGraph-compatible timestamps output
|
||||
|
||||
Flame graphs are used to visualize hierarchical data, like call stacks.
|
||||
Timestamps collected by coreboot can be processed to resemble
|
||||
profiler-like output, and thus can be feed to flame graph generation
|
||||
tools.
|
||||
|
||||
Generating flame graph using https://github.com/brendangregg/FlameGraph:
|
||||
```
|
||||
cbmem -S > trace.txt
|
||||
FlameGraph/flamegraph.pl --flamechart trace.txt > output.svg
|
||||
```
|
||||
|
||||
|
||||
### src/console/Kconfig: Add option to disable loglevel prefix
|
||||
|
||||
This patch adds an option to disable loglevel prefixes. This patch helps
|
||||
to achieve clear messages when low loglevel is used and very few
|
||||
messages are displayed on a terminal. This option also allows to
|
||||
maintain compatibility with log readers and continuous integration
|
||||
systems that depend on fixed log content.
|
||||
|
||||
If the code contains:
|
||||
printk(BIOS_DEBUG, "This is a debug message!\n")
|
||||
it will show as:
|
||||
[DEBUG] This is a debug message!
|
||||
but if the Kconfig contains:
|
||||
CONFIG_CONSOLE_USE_LOGLEVEL_PREFIX=n
|
||||
the same message will show up as
|
||||
This is a debug message!
|
||||
|
||||
|
||||
### util/cbmem: add an option to append timestamp
|
||||
|
||||
Add an option to the cbmem utility that can be used to append an entry
|
||||
to the cbmem timestamp table from userspace. This is useful for
|
||||
bookkeeping of post-coreboot timing information while still being able
|
||||
to use cbmem-based tooling for processing the generated data.
|
||||
|
||||
|
||||
`-a | --add-timestamp ID: append timestamp with ID\n`
|
||||
|
||||
|
||||
Additional changes
|
||||
------------------
|
||||
|
||||
The following are changes across a number of patches, or changes worth
|
||||
noting, but not needing a full description.
|
||||
|
||||
* As always, general documentation, code cleanup, and refactoring
|
||||
* Remove doxygen config files and targets
|
||||
* Get clang compile working for all x86 platforms
|
||||
* Work on updating checkpatch to match the current Linux version
|
||||
* Timestamps: Rename timestamps to make names more consistent
|
||||
* Continue updating ACPI code to ASL 2.0
|
||||
* Remove redundant or unnecessary headers from C files
|
||||
* arch/x86/acpi_bert_storage.c: Use a common implementation
|
||||
* Postcar stage improvements
|
||||
* arch/x86/acpi: Consolidate POST code handling
|
||||
* intel/common: Enable ROM caching in ramstage
|
||||
* vendorcode/amd/agesa: Fix improper use of .data (const is important)
|
||||
* sandybridge & gm45: Support setting PCI bars above 4G
|
||||
|
||||
|
||||
Plans for Code Deprecation
|
||||
--------------------------
|
||||
|
||||
|
||||
### Intel Icelake
|
||||
|
||||
Intel Icelake is unmaintained. Also, the only user of this platform ever was
|
||||
the CRB board. From the looks of it the code never was ready for production as
|
||||
only engineering sample CPUIDs are supported.
|
||||
|
||||
Thus, to reduce the maintanence overhead for the community, it is deprecated
|
||||
from this release on and support for the following components will be dropped
|
||||
with the release 4.19.
|
||||
|
||||
* Intel Icelake SoC
|
||||
* Intel Icelake RVP mainboard
|
||||
|
||||
|
||||
### LEGACY_SMP_INIT
|
||||
|
||||
As of release 4.18 (August 2022) we plan to deprecate LEGACY_SMP_INIT.
|
||||
This also includes the codepath for SMM_ASEG. This code is used to start
|
||||
APs and do some feature programming on each AP, but also set up SMM.
|
||||
This has largely been superseded by PARALLEL_MP, which should be able to
|
||||
cover all use cases of LEGACY_SMP_INIT, with little code changes. The
|
||||
reason for deprecation is that having 2 codepaths to do the virtually
|
||||
the same increases maintenance burden on the community a lot, while also
|
||||
being rather confusing.
|
||||
|
||||
No platforms in the tree have any hardware limitations that would block
|
||||
migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase.
|
||||
|
||||
|
||||
Statistics
|
||||
----------
|
||||
|
||||
- Total Commits: 1305
|
||||
- Average Commits per day: 13.42
|
||||
- Total lines added: 51422
|
||||
- Average lines added per commit: 39.40
|
||||
- Number of patches adding more than 100 lines: 59
|
||||
- Average lines added per small commit: 24.73
|
||||
- Total lines removed: 66206
|
||||
- Average lines removed per commit: 50.73
|
||||
- Total difference between added and removed: -14784
|
||||
- Total authors: 146
|
||||
- New authors: 17
|
||||
### Add significant changes here
|
||||
|
@@ -1,56 +0,0 @@
|
||||
Upcoming release - coreboot 4.18
|
||||
================================
|
||||
|
||||
The 4.18 release is planned for August 2022.
|
||||
|
||||
Update this document with changes that should be in the release notes.
|
||||
|
||||
* Please use Markdown.
|
||||
* See the past few release notes for the general format.
|
||||
* The chip and board additions and removals will be updated right
|
||||
before the release, so those do not need to be added.
|
||||
|
||||
Significant changes
|
||||
-------------------
|
||||
|
||||
### Add significant changes here
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Plans for Code Deprecation
|
||||
--------------------------
|
||||
|
||||
|
||||
### Intel Icelake
|
||||
|
||||
Intel Icelake code will be removed following the 4.19 release, planned
|
||||
for November 2022. This consists of the Intel Icelake SOC and Intel
|
||||
Icelake RVP mainboard
|
||||
|
||||
Intel Icelake is unmaintained. Also, the only user of this platform ever
|
||||
was the CRB board. From the looks of it the code never was ready for
|
||||
production as only engineering sample CPUIDs are supported. This reduces
|
||||
the maintanence overhead for the coreboot project.
|
||||
|
||||
|
||||
### LEGACY_SMP_INIT
|
||||
|
||||
Legacy SMP init will be removed from the coreboot master branch
|
||||
immediately following this release. Anyone looking for the latest
|
||||
version of the code should find it on the 4.18 branch.
|
||||
|
||||
This also includes the codepath for SMM_ASEG. This code is used to start
|
||||
APs and do some feature programming on each AP, but also set up SMM.
|
||||
This has largely been superseded by PARALLEL_MP, which should be able to
|
||||
cover all use cases of LEGACY_SMP_INIT, with little code changes. The
|
||||
reason for deprecation is that having 2 codepaths to do the virtually
|
||||
the same increases maintenance burden on the community a lot, while also
|
||||
being rather confusing.
|
@@ -3,7 +3,7 @@
|
||||
## Upcoming release
|
||||
|
||||
Please add to the release notes as changes are added:
|
||||
* [4.18 - Aug 2022](coreboot-4.18-relnotes.md)
|
||||
* [4.17 - May 2022](coreboot-4.17-relnotes.md)
|
||||
|
||||
The [checklist] contains instructions to ensure that a release covers all
|
||||
important things and provides a reliable format for tarballs, branch
|
||||
@@ -15,7 +15,6 @@ important is taken care of.
|
||||
|
||||
## Previous releases
|
||||
|
||||
* [4.17 - May 2022](coreboot-4.17-relnotes.md)
|
||||
* [4.16 - Feb 2022](coreboot-4.16-relnotes.md)
|
||||
* [4.15 - November 2021](coreboot-4.15-relnotes.md)
|
||||
* [4.14 - May 2021](coreboot-4.14-relnotes.md)
|
||||
|
@@ -176,6 +176,7 @@ CMOS, the EC, or in a read/write area of the SPI flash device.
|
||||
Select one of the following:
|
||||
|
||||
* `VBOOT_VBNV_CMOS`
|
||||
* `VBOOT_VBNV_EC`
|
||||
* `VBOOT_VBNV_FLASH`
|
||||
|
||||
More non-volatile storage features may be found in `security/vboot/Kconfig`.
|
||||
@@ -328,7 +329,7 @@ Google's Chromebooks have some special features:
|
||||
### Developer Mode
|
||||
|
||||
Developer mode allows the user to use coreboot to boot another operating system.
|
||||
This may be a another (beta) version of ChromeOS, or another flavor of
|
||||
This may be a another (beta) version of Chrome OS, or another flavor of
|
||||
GNU/Linux. Use of developer mode does not void the system warranty. Upon entry
|
||||
into developer mode, all locally saved data on the system is lost.
|
||||
This prevents someone from entering developer mode to subvert the system
|
||||
|
@@ -73,6 +73,8 @@
|
||||
- Ultima (Lenovo Yoga 11e G3)
|
||||
- Wizpig
|
||||
- Daisy (Samsung Chromebook (2012))
|
||||
- Deltan
|
||||
- Deltaur
|
||||
- Drallion
|
||||
- Eve (Google Pixelbook)
|
||||
- Fizz
|
||||
|
0
Documentation/soc/amd/amdblobs_license.md
Normal file → Executable file
0
Documentation/soc/amd/amdblobs_license.md
Normal file → Executable file
0
Documentation/soc/amd/family17h.md
Normal file → Executable file
0
Documentation/soc/amd/family17h.md
Normal file → Executable file
0
Documentation/soc/amd/psp_integration.md
Normal file → Executable file
0
Documentation/soc/amd/psp_integration.md
Normal file → Executable file
@@ -8,7 +8,7 @@ power transition flows.
|
||||
|
||||
## Problem Statement
|
||||
|
||||
Currently, on ChromiumOS Systems, CSE region is not updatable. So, new CSE FW
|
||||
Currently, on Chromium OS Systems, CSE region is not updatable. So, new CSE FW
|
||||
versions that are released by Intel to address important functional and security
|
||||
bugs post-product launch will not be available to the end-user. Hence, the proposed
|
||||
solution allows in-field CSE FW update to propagate those bug fixes
|
||||
|
@@ -51,6 +51,6 @@ option in order to perform SGX and C6DRAM enabling.
|
||||
Typically all platforms supported by FSP 2.1 specification will have
|
||||
external PPI service feature implemented.
|
||||
|
||||
## References
|
||||
[References]
|
||||
- [PPI](../fsp/ppi/ppi.md)
|
||||
- [MP Service PPI](../fsp/ppi/mp_service_ppi.md)
|
||||
|
@@ -3,7 +3,7 @@ Rebuilding coreboot image generation
|
||||
|
||||
Current situation
|
||||
-----------------
|
||||
ChromeOS (CrOS) probably has the most complex image bundling process in the
|
||||
Chrome OS (CrOS) probably has the most complex image bundling process in the
|
||||
coreboot ecosystem. To make CrOS features more accessible to the wider
|
||||
coreboot community, we want to move these capabilities into upstream
|
||||
coreboot’s build system.
|
||||
@@ -21,7 +21,7 @@ putting more data (eg. the bitmap data, keys) as raw data into other fmap
|
||||
regions.
|
||||
|
||||
With the recent addition of more files to CBFS, both on the coreboot side
|
||||
(dsdt, FSP, and so on) and with ChromeOS specifics (eg. more files describing
|
||||
(dsdt, FSP, and so on) and with Chrome OS specifics (eg. more files describing
|
||||
boot screens) we either need to expand the scope of bundle\_firmware or move
|
||||
the capability to build complex images to upstream coreboot’s build system.
|
||||
This document proposes to do the latter and outlines how this could be
|
||||
@@ -41,14 +41,14 @@ images:
|
||||
variable to guarantee success if there’s enough room for the files. While that
|
||||
could be added, that becomes more make macro work indistinguishable from magic
|
||||
that people fail to understand, break and with good reason complain about
|
||||
to work around such issues, ChromeOS firmware uses a custom tool with even
|
||||
to work around such issues, Chrome OS firmware uses a custom tool with even
|
||||
more special cases to finally build the image it needs. If coreboot upstream
|
||||
is to support vboot, it should also be powerful enough not to need magic tools
|
||||
that only live within downstream projects.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
A complete ChromeOS coreboot image consists of (depending on the device)
|
||||
A complete Chrome OS coreboot image consists of (depending on the device)
|
||||
* platform specific data in raw fmap regions (eg IFD, ME firmware),
|
||||
* the bootblock (coming from the bootblock),
|
||||
* three copies of coreboot, consisting of the stages (verstage, romstage,
|
||||
@@ -68,7 +68,7 @@ using a yet to be implemented switching scheme based on fmaps) consists of
|
||||
* payload plus data (with each of the coreboot copies),
|
||||
|
||||
Since a single platform is potentially built with different payload
|
||||
configurations (eg. modding a Chromebook to not use the verified ChromeOS
|
||||
configurations (eg. modding a Chromebook to not use the verified Chrome OS
|
||||
boot scheme), some concerns need to be kept separate:
|
||||
* Platform requirements that have nothing to do with the payload or boot schemes
|
||||
* IFD, ME, … need to copied to the right place
|
||||
@@ -111,11 +111,11 @@ Boot method manifest
|
||||
--------------------
|
||||
The boot method manifest can subdivide the BIOS region, eg. using it directly
|
||||
(for coreboot’s “simple” bootblock), splitting it in two (for coreboot’s
|
||||
fallback/normal) or in many parts (for ChromeOS, which requires two CBFS
|
||||
fallback/normal) or in many parts (for Chrome OS, which requires two CBFS
|
||||
regions, one for GBB, several for VPD, …).
|
||||
It also specifies which of the file lists specified earlier belong in which
|
||||
region (eg. with verstage verifying romstage, verstage needs to be only in
|
||||
ChromeOS’ RO region, while romstage belongs in RO and both RW regions).
|
||||
Chrome OS’ RO region, while romstage belongs in RO and both RW regions).
|
||||
It can also specify a post processing step that is executed before the
|
||||
chipset’s.
|
||||
|
||||
@@ -148,7 +148,7 @@ It specifies an IFD region, an ME, and the BIOS region. After the image is
|
||||
built, the entire image needs to be processed (although the tool likely works
|
||||
only on a small part of it)
|
||||
|
||||
It’s built in a ChromeOS-like configuration (simplified at places to avoid
|
||||
It’s built in a Chrome OS-like configuration (simplified at places to avoid
|
||||
distracting from the important parts), so it has three CBFS regions, and
|
||||
several data regions for its own purpose (similar to GBB, FWID, VPD, …). After
|
||||
the regions are filled, one data region must be post-processed to contain
|
||||
|
@@ -2,179 +2,118 @@ Tutorial, part 1: Starting from scratch
|
||||
===========================================
|
||||
|
||||
This tutorial will guide you through the process of setting up a working
|
||||
coreboot toolchain. In same cases you will find specific instructions
|
||||
for Debian (apt-get), Fedora (dnf) and Arch Linux (pacman) based package
|
||||
management systems. Use the instructions according to your system.
|
||||
|
||||
**Note: Summaries of each of the steps are at the end of the document.**
|
||||
|
||||
coreboot toolchain. In same cases you will find specific instructions for Debian (apt-get),
|
||||
Fedora (dnf) and Arch Linux (pacman) based package management systems. Use the
|
||||
instructions according to your system.
|
||||
|
||||
Download, configure, and build coreboot
|
||||
---------------------------------------
|
||||
|
||||
|
||||
### Step 1 - Install tools and libraries needed for coreboot
|
||||
|
||||
Debian based distros:
|
||||
`sudo apt-get install -y bison build-essential curl flex git gnat`
|
||||
`libncurses5-dev m4 zlib1g-dev`
|
||||
|
||||
Arch based distros:
|
||||
`sudo pacman -S base-devel curl git gcc-ada ncurses zlib`
|
||||
|
||||
Redhat based distros:
|
||||
`sudo dnf install git make gcc-gnat flex bison xz bzip2 gcc g++`
|
||||
`ncurses-devel wget zlib-devel patch`
|
||||
|
||||
$ sudo apt-get install -y bison build-essential curl flex git gnat libncurses5-dev m4 zlib1g-dev
|
||||
$ sudo pacman -S base-devel curl git gcc-ada ncurses zlib
|
||||
$ sudo dnf install git make gcc-gnat flex bison xz bzip2 gcc g++ ncurses-devel wget zlib-devel patch
|
||||
|
||||
### Step 2 - Download coreboot source tree
|
||||
|
||||
```Bash
|
||||
git clone https://review.coreboot.org/coreboot
|
||||
cd coreboot
|
||||
```
|
||||
|
||||
|
||||
$ git clone https://review.coreboot.org/coreboot
|
||||
$ cd coreboot
|
||||
|
||||
### Step 3 - Build the coreboot toolchain
|
||||
|
||||
Please note that this can take a significant amount of time. Use `CPUS=`
|
||||
to specify number of `make` jobs to run in parallel.
|
||||
Please note that this can take a significant amount of time. Use `CPUS=` to
|
||||
specify number of `make` jobs to run in parallel.
|
||||
|
||||
This will list toolchain options and supported architectures:
|
||||
|
||||
```Bash
|
||||
make help_toolchain
|
||||
```
|
||||
$ make help_toolchain
|
||||
|
||||
Here are some examples:
|
||||
|
||||
```Bash
|
||||
make crossgcc-i386 CPUS=$(nproc) # build i386 toolchain
|
||||
make crossgcc-aarch64 CPUS=$(nproc) # build Aarch64 toolchain
|
||||
make crossgcc-riscv CPUS=$(nproc) # build RISC-V toolchain
|
||||
```
|
||||
$ make crossgcc-i386 CPUS=$(nproc) # build i386 toolchain
|
||||
$ make crossgcc-aarch64 CPUS=$(nproc) # build Aarch64 toolchain
|
||||
$ make crossgcc-riscv CPUS=$(nproc) # build RISC-V toolchain
|
||||
|
||||
Note that the i386 toolchain is currently used for all x86 platforms,
|
||||
including x86_64.
|
||||
|
||||
Also note that you can possibly use your system toolchain, but the
|
||||
results are not reproducible, and may have issues, so this is not
|
||||
recommended. See step 5 to use your system toolchain.
|
||||
Note that the i386 toolchain is currently used for all x86 platforms, including
|
||||
x86_64.
|
||||
|
||||
Also note that you can possibly use your system toolchain, but the results are
|
||||
not reproducible, and may have issues, so this is not recommended. See step 5
|
||||
to use your system toolchain.
|
||||
|
||||
### Step 4 - Build the payload - coreinfo
|
||||
|
||||
```Bash
|
||||
make -C payloads/coreinfo olddefconfig
|
||||
make -C payloads/coreinfo
|
||||
```
|
||||
|
||||
$ make -C payloads/coreinfo olddefconfig
|
||||
$ make -C payloads/coreinfo
|
||||
|
||||
### Step 5 - Configure the build
|
||||
|
||||
##### Configure your mainboard
|
||||
|
||||
```Bash
|
||||
make menuconfig
|
||||
```
|
||||
|
||||
Do the next steps in the menu:
|
||||
|
||||
```Text
|
||||
select 'Mainboard' menu
|
||||
Beside 'Mainboard vendor' should be '(Emulation)'
|
||||
Beside 'Mainboard model' should be 'QEMU x86 i440fx/piix4'
|
||||
select < Exit >
|
||||
```
|
||||
|
||||
$ make menuconfig
|
||||
select 'Mainboard' menu
|
||||
Beside 'Mainboard vendor' should be '(Emulation)'
|
||||
Beside 'Mainboard model' should be 'QEMU x86 i440fx/piix4'
|
||||
select < Exit >
|
||||
These should be the default selections, so if anything else was set, run
|
||||
`make distclean` to remove your old config file and start over.
|
||||
|
||||
##### Optionally use your system toolchain (Again, not recommended)
|
||||
|
||||
```Text
|
||||
select 'General Setup' menu
|
||||
select 'Allow building with any toolchain'
|
||||
select < Exit >
|
||||
```
|
||||
select 'General Setup' menu
|
||||
select 'Allow building with any toolchain'
|
||||
select < Exit >
|
||||
|
||||
##### Select the payload
|
||||
|
||||
```Text
|
||||
select 'Payload' menu
|
||||
select 'Add a Payload'
|
||||
choose 'An Elf executable payload'
|
||||
select 'Payload path and filename'
|
||||
enter 'payloads/coreinfo/build/coreinfo.elf'
|
||||
select < Exit >
|
||||
select < Exit >
|
||||
select < Yes >
|
||||
```
|
||||
select 'Payload' menu
|
||||
select 'Add a Payload'
|
||||
choose 'An Elf executable payload'
|
||||
select 'Payload path and filename'
|
||||
enter 'payloads/coreinfo/build/coreinfo.elf'
|
||||
select < Exit >
|
||||
select < Exit >
|
||||
select < Yes >
|
||||
|
||||
##### Check your configuration (optional step):
|
||||
|
||||
```Bash
|
||||
make savedefconfig
|
||||
cat defconfig
|
||||
```
|
||||
$ make savedefconfig
|
||||
$ cat defconfig
|
||||
|
||||
There should only be two lines (or 3 if you're using the system
|
||||
toolchain):
|
||||
There should only be two lines (or 3 if you're using the system toolchain):
|
||||
|
||||
```Text
|
||||
CONFIG_PAYLOAD_ELF=y
|
||||
CONFIG_PAYLOAD_FILE="payloads/coreinfo/build/coreinfo.elf"
|
||||
```
|
||||
CONFIG_PAYLOAD_ELF=y
|
||||
CONFIG_PAYLOAD_FILE="payloads/coreinfo/build/coreinfo.elf"
|
||||
|
||||
### Step 6 - build coreboot
|
||||
|
||||
```Bash
|
||||
make
|
||||
```
|
||||
$ make
|
||||
|
||||
At the end of the build, you should see:
|
||||
|
||||
`Build emulation/qemu-i440fx (QEMU x86 i440fx/piix4)``
|
||||
|
||||
This means your build was successful. The output from the build is in
|
||||
the build directory. build/coreboot.rom is the full rom file.
|
||||
Build emulation/qemu-i440fx (QEMU x86 i440fx/piix4)
|
||||
|
||||
This means your build was successful. The output from the build is in the build
|
||||
directory. build/coreboot.rom is the full rom file.
|
||||
|
||||
Test the image using QEMU
|
||||
-------------------------
|
||||
|
||||
|
||||
### Step 7 - Install QEMU
|
||||
|
||||
* Debian: `sudo apt-get install -y qemu`
|
||||
* Arch: `sudo pacman -S qemu`
|
||||
* Redhat: `sudo dnf install qemu`
|
||||
|
||||
$ sudo apt-get install -y qemu
|
||||
$ sudo pacman -S qemu
|
||||
$ sudo dnf install qemu
|
||||
|
||||
### Step 8 - Run QEMU
|
||||
|
||||
Start QEMU, and point it to the ROM you just built:
|
||||
|
||||
```Bash
|
||||
qemu-system-x86_64 -bios build/coreboot.rom -serial stdio
|
||||
```
|
||||
|
||||
You should see the serial output of coreboot in the original console
|
||||
window, and a new window will appear running the coreinfo payload.
|
||||
$ qemu-system-x86_64 -bios build/coreboot.rom -serial stdio
|
||||
|
||||
You should see the serial output of coreboot in the original console window, and
|
||||
a new window will appear running the coreinfo payload.
|
||||
|
||||
Summary
|
||||
-------
|
||||
|
||||
|
||||
### Step 1 summary - Install tools and libraries needed for coreboot
|
||||
|
||||
Depending on your distribution you have installed the minimum additional
|
||||
software requirements to continue with downloading and building
|
||||
coreboot. Not every distribution has the tools, that would be required,
|
||||
installed by default. In the following we shortly introduce the purpose
|
||||
of the installed packages:
|
||||
software requirements to continue with downloading and building coreboot.
|
||||
Not every distribution has the tools, that would be required,
|
||||
installed by default. In the following we shortly introduce the purpose of the
|
||||
installed packages:
|
||||
|
||||
* `build-essential` or `base-devel` are the basic tools for building software.
|
||||
* `git` is needed to download coreboot from the coreboot git repository.
|
||||
@@ -183,89 +122,71 @@ of the installed packages:
|
||||
are needed to build the coreboot toolchain. `gcc` and `gnat` have to be
|
||||
of the same version.
|
||||
|
||||
If you started with a different distribution or package management
|
||||
system you might need to install other packages. Most likely they are
|
||||
named slightly different. If that is the case for you, we'd like to
|
||||
encourage you to contribute to the project and submit a pull request
|
||||
with an update for this documentation for your system.
|
||||
|
||||
If you started with a different distribution or package management system you
|
||||
might need to install other packages. Most likely they are named slightly
|
||||
different. If that is the case for you, we'd like to encourage you to contribute
|
||||
to the project and submit a pull request with an update for this documentation
|
||||
for your system.
|
||||
|
||||
### Step 2 summary - Download coreboot source tree
|
||||
|
||||
This will download a 'read-only' copy of the coreboot tree. This just
|
||||
means that if you made changes to the coreboot tree, you couldn't
|
||||
immediately contribute them back to the community. To pull a copy of
|
||||
coreboot that would allow you to contribute back, you would first need
|
||||
to sign up for an account on gerrit.
|
||||
|
||||
This will download a 'read-only' copy of the coreboot tree. This just means
|
||||
that if you made changes to the coreboot tree, you couldn't immediately
|
||||
contribute them back to the community. To pull a copy of coreboot that would
|
||||
allow you to contribute back, you would first need to sign up for an account on
|
||||
gerrit.
|
||||
|
||||
### Step 3 summary - Build the coreboot toolchain.
|
||||
|
||||
This builds one of the coreboot cross-compiler toolchains for X86
|
||||
platforms. Because of the variability of compilers and the other
|
||||
required tools between the various operating systems that coreboot can
|
||||
be built on, coreboot supplies and uses its own cross-compiler toolchain
|
||||
to build the binaries that end up as part of the coreboot ROM. The
|
||||
toolchain provided by the operating system (the 'host toolchain') is
|
||||
used to build various tools that will run on the local system during the
|
||||
build process.
|
||||
|
||||
This builds one of the coreboot cross-compiler toolchains for X86 platforms.
|
||||
Because of the variability of compilers and the other required tools between
|
||||
the various operating systems that coreboot can be built on, coreboot supplies
|
||||
and uses its own cross-compiler toolchain to build the binaries that end up as
|
||||
part of the coreboot ROM. The toolchain provided by the operating system (the
|
||||
'host toolchain') is used to build various tools that will run on the local
|
||||
system during the build process.
|
||||
|
||||
### Step 4 summary - Build the payload
|
||||
|
||||
To actually do anything useful with coreboot, you need to build a
|
||||
payload to include into the rom. The idea behind coreboot is that it
|
||||
does the minimum amount possible before passing control of the machine
|
||||
to a payload. There are various payloads such as grub or SeaBIOS that
|
||||
are typically used to boot the operating system. Instead, we used
|
||||
coreinfo, a small demonstration payload that allows the user to look at
|
||||
various things such as memory and the contents of the coreboot file
|
||||
system (CBFS) - the pieces that make up the coreboot rom.
|
||||
|
||||
To actually do anything useful with coreboot, you need to build a payload to
|
||||
include into the rom. The idea behind coreboot is that it does the minimum amount
|
||||
possible before passing control of the machine to a payload. There are various
|
||||
payloads such as grub or SeaBIOS that are typically used to boot the operating
|
||||
system. Instead, we used coreinfo, a small demonstration payload that allows the
|
||||
user to look at various things such as memory and the contents of the coreboot
|
||||
file system (CBFS) - the pieces that make up the coreboot rom.
|
||||
|
||||
### Step 5 summary - Configure the build
|
||||
|
||||
This step configures coreboot's build options using the menuconfig
|
||||
interface to Kconfig. Kconfig is the same configuration program used by
|
||||
the linux kernel. It allows you to enable, disable, and change various
|
||||
values to control the coreboot build process, including which
|
||||
mainboard(motherboard) to use, which toolchain to use, and how the
|
||||
runtime debug console should be presented and saved. Anytime you change
|
||||
mainboards in Kconfig, you should always run `make distclean` before
|
||||
running `make menuconfig`. Due to the way that Kconfig works, values
|
||||
will be kept from the previous mainboard if you skip the clean step.
|
||||
This leads to a hybrid configuration which may or may not work as
|
||||
expected.
|
||||
|
||||
This step configures coreboot's build options using the menuconfig interface to
|
||||
Kconfig. Kconfig is the same configuration program used by the linux kernel. It
|
||||
allows you to enable, disable, and change various values to control the coreboot
|
||||
build process, including which mainboard(motherboard) to use, which toolchain to
|
||||
use, and how the runtime debug console should be presented and saved.
|
||||
Anytime you change mainboards in Kconfig, you should always run `make distclean`
|
||||
before running `make menuconfig`. Due to the way that Kconfig works, values will
|
||||
be kept from the previous mainboard if you skip the clean step. This leads to a
|
||||
hybrid configuration which may or may not work as expected.
|
||||
|
||||
### Step 6 summary - Build coreboot
|
||||
|
||||
You may notice that a number of other pieces are downloaded at the
|
||||
beginning of the build process. These are the git submodules used in
|
||||
various coreboot builds. By default, the _blobs_ submodule is not
|
||||
downloaded. This git submodule may be required for other builds for
|
||||
microcode or other binaries. To enable downloading this submodule,
|
||||
select the option "Allow use of binary-only repository" in the "General
|
||||
Setup" menu of Kconfig This attempts to build the coreboot rom. The rom
|
||||
file itself ends up in the build directory as 'coreboot.rom'. At the end
|
||||
of the build process, the build displayed the contents of the rom file.
|
||||
|
||||
You may notice that a number of other pieces are downloaded at the beginning of
|
||||
the build process. These are the git submodules used in various coreboot builds.
|
||||
By default, the _blobs_ submodule is not downloaded. This git submodule may be
|
||||
required for other builds for microcode or other binaries. To enable downloading
|
||||
this submodule, select the option "Allow use of binary-only repository" in the
|
||||
"General Setup" menu of Kconfig
|
||||
This attempts to build the coreboot rom. The rom file itself ends up in the
|
||||
build directory as 'coreboot.rom'. At the end of the build process, the build
|
||||
displayed the contents of the rom file.
|
||||
|
||||
### Step 7 summary - Install QEMU
|
||||
|
||||
QEMU is a processor emulator which we can use to show the coreboot boot
|
||||
process in a virtualised environment.
|
||||
|
||||
|
||||
### Step 8 summary - Run QEMU
|
||||
|
||||
Here's the command line instruction broken down:
|
||||
* `qemu-system-x86_64`
|
||||
This starts the QEMU emulator with the i440FX host PCI bridge and PIIX3
|
||||
PCI to ISA bridge.
|
||||
This starts the QEMU emulator with the i440FX host PCI bridge and PIIX3 PCI to
|
||||
ISA bridge.
|
||||
* `-bios build/coreboot.rom`
|
||||
Use the coreboot rom image that we just built. If this flag is left out,
|
||||
the standard SeaBIOS image that comes with QEMU is used.
|
||||
Use the coreboot rom image that we just built. If this flag is left out, the
|
||||
standard SeaBIOS image that comes with QEMU is used.
|
||||
* `-serial stdio`
|
||||
Send the serial output to the console. This allows you to view the
|
||||
coreboot boot log.
|
||||
Send the serial output to the console. This allows you to view the coreboot
|
||||
boot log.
|
||||
|
@@ -4,29 +4,28 @@
|
||||
|
||||
If you already have an account, skip to Step 2.
|
||||
|
||||
Otherwise, go to <https://review.coreboot.org> in your preferred web
|
||||
browser. Select **Sign in** in the upper right corner.
|
||||
Otherwise, go to <https://review.coreboot.org> in your preferred web browser.
|
||||
Select **Sign in** in the upper right corner.
|
||||
|
||||
Select the appropriate sign-in. For example, if you have a Google
|
||||
account, select **Google OAuth2** (gerrit-oauth-provider plugin).
|
||||
**Note:** Your username for the account will be the username of the
|
||||
account you used to sign-in with. (ex. your Google username).
|
||||
Select the appropriate sign-in. For example, if you have a Google account,
|
||||
select **Google OAuth2** (gerrit-oauth-provider plugin). **Note:** Your
|
||||
username for the account will be the username of the account you used to
|
||||
sign-in with. (ex. your Google username).
|
||||
|
||||
## Step 2a: Set up SSH keys
|
||||
|
||||
If you prefer to use an HTTP password instead, skip to Step 2b.
|
||||
|
||||
If you do not have an SSH key set up on your account already (as is the
|
||||
case with a newly created account), follow the instructions below;
|
||||
otherwise, doing so could overwrite an existing key.
|
||||
If you do not have an SSH key set up on your account already (as is the case
|
||||
with a newly created account), follow the instructions below; otherwise,
|
||||
doing so could overwrite an existing key.
|
||||
|
||||
In a terminal, run `ssh-keygen -t ed25519` and confirm the default path
|
||||
`.ssh/id_ed25519`.
|
||||
|
||||
Make a passphrase -- remember this phrase. It will be needed whenever
|
||||
you use this public key. **Note:** You might want to use a short
|
||||
password, or forego the password altogether as you will be using it very
|
||||
often.
|
||||
Make a passphrase -- remember this phrase. It will be needed whenever you use
|
||||
this public key. **Note:** You might want to use a short password, or
|
||||
forego the password altogether as you will be using it very often.
|
||||
|
||||
Copy the content of `.ssh/id_ed25519.pub` (notice the ".pub" suffix
|
||||
as you need to send the public key) into the textbox "New SSH Key" at
|
||||
@@ -34,19 +33,17 @@ https://review.coreboot.org/settings/#SSHKeys and save it.
|
||||
|
||||
## Step 2b: Set up an HTTP Password
|
||||
|
||||
Alternatively, instead of using SSH keys, you can use an HTTP password.
|
||||
To do so, after you select your name and click on **Settings** on the
|
||||
left-hand side, rather than selecting **SSH Public Keys**, select **HTTP
|
||||
Password**.
|
||||
Alternatively, instead of using SSH keys, you can use an HTTP password. To do so,
|
||||
after you select your name and click on **Settings** on the left-hand side, rather
|
||||
than selecting **SSH Public Keys**, select **HTTP Password**.
|
||||
|
||||
Click **Generate Password**. This should fill the "Password" box with a
|
||||
password. Copy the password, and add the following to your
|
||||
`$HOME/.netrc` file:
|
||||
Click **Generate Password**. This should fill the "Password" box with a password. Copy
|
||||
the password, and add the following to your `$HOME/.netrc` file:
|
||||
|
||||
machine review.coreboot.org login YourUserNameHere password YourPasswordHere
|
||||
|
||||
where YourUserNameHere is your username, and YourPasswordHere is the
|
||||
password you just generated.
|
||||
where YourUserNameHere is your username, and YourPasswordHere is the password you
|
||||
just generated.
|
||||
|
||||
If your system is behind a snooping HTTPS proxy, you might also have to
|
||||
make its SSL certificate known to curl, a system specific operation.
|
||||
@@ -58,28 +55,26 @@ certificate verification in git:
|
||||
The `--global` argument sets it for all git transfers of your local
|
||||
user, `false` means not to validate the certificate.
|
||||
|
||||
If that still doesn't allow you to pull or push changes to the server,
|
||||
the proxy is likely tampering with the data stream, in which case
|
||||
there's nothing we can do.
|
||||
If that still doesn't allow you to pull or push changes to the server, the
|
||||
proxy is likely tampering with the data stream, in which case there's nothing
|
||||
we can do.
|
||||
|
||||
## Step 3: Clone coreboot and configure it for submitting patches
|
||||
|
||||
On Gerrit, click on the **Browse** tab in the upper left corner and
|
||||
select **Repositories**. From the listing, select the "coreboot" repo.
|
||||
You may have to click the next page arrow at the bottom a few times to
|
||||
find it.
|
||||
On Gerrit, click on the **Browse** tab in the upper left corner and select
|
||||
**Repositories**. From the listing, select the "coreboot" repo. You may have
|
||||
to click the next page arrow at the bottom a few times to find it.
|
||||
|
||||
If you are using SSH keys, select **ssh** from the tabs under "Project
|
||||
coreboot" and run the "clone with commit-msg hook" command that's
|
||||
provided. This should prompt you for your id_rsa passphrase, if you
|
||||
previously set one.
|
||||
coreboot" and run the "clone with commit-msg hook" command that's provided.
|
||||
This should prompt you for your id_rsa passphrase, if you previously set one.
|
||||
|
||||
**Note:** if the **ssh** option is not showing, check that you have a
|
||||
username set. Click the profile picture at the top right and select
|
||||
**User Settings**, then set your username in the **Profile** section.
|
||||
**Note:** if the **ssh** option is not showing, check that you have a username
|
||||
set. Click the profile picture at the top right and select **User Settings**,
|
||||
then set your username in the **Profile** section.
|
||||
|
||||
If you are using HTTP, instead, select **http** from the tabs under
|
||||
"Project coreboot" and run the command that appears.
|
||||
If you are using HTTP, instead, select **http** from the tabs under "Project coreboot"
|
||||
and run the command that appears.
|
||||
|
||||
Now is a good time to configure your global git identity, if you haven't
|
||||
already.
|
||||
@@ -87,32 +82,30 @@ already.
|
||||
git config --global user.name "Your Name"
|
||||
git config --global user.email "Your Email"
|
||||
|
||||
Finally, enter the local git repository and set up repository specific
|
||||
hooks and other configurations.
|
||||
Finally, enter the local git repository and set up repository specific hooks
|
||||
and other configurations.
|
||||
|
||||
cd coreboot
|
||||
make gitconfig
|
||||
|
||||
## Step 4: Submit a commit
|
||||
|
||||
An easy first commit to make is fixing existing checkpatch errors and
|
||||
warnings in the source files. To see errors that are already present,
|
||||
build the files in the repository by running `make lint` in the coreboot
|
||||
directory. Alternatively, if you want to run `make lint` on a specific
|
||||
directory, run:
|
||||
An easy first commit to make is fixing existing checkpatch errors and warnings
|
||||
in the source files. To see errors that are already present, build the files in
|
||||
the repository by running `make lint` in the coreboot directory. Alternatively,
|
||||
if you want to run `make lint` on a specific directory, run:
|
||||
|
||||
util/lint/lint-007-checkpatch <filepath>
|
||||
|
||||
where `filepath` is the filepath of the directory (ex.
|
||||
`src/cpu/amd/car`).
|
||||
where `filepath` is the filepath of the directory (ex. `src/cpu/amd/car`).
|
||||
|
||||
Any changes made to files under the src directory are made locally,
|
||||
and can be submitted for review.
|
||||
|
||||
Once you finish making your desired changes, use the command line to
|
||||
stage and submit your changes. An alternative and potentially easier way
|
||||
to stage and submit commits is to use git cola, a graphical user
|
||||
interface for git. For instructions on how to do so, skip to Step 4b.
|
||||
Once you finish making your desired changes, use the command line to stage
|
||||
and submit your changes. An alternative and potentially easier way to stage
|
||||
and submit commits is to use git cola, a graphical user interface for git. For
|
||||
instructions on how to do so, skip to Step 4b.
|
||||
|
||||
## Step 4a: Use the command line to stage and submit a commit
|
||||
|
||||
@@ -126,21 +119,20 @@ To commit the change, run
|
||||
|
||||
git commit -s
|
||||
|
||||
**Note:** The -s adds a signed-off-by line by the committer. Your commit
|
||||
should be signed off with your name and email (i.e. **Your Name**
|
||||
**\<Your Email\>**, based on what you set with git config earlier).
|
||||
**Note:** The -s adds a signed-off-by line by the committer. Your commit should be
|
||||
signed off with your name and email (i.e. **Your Name** **\<Your Email\>**, based on
|
||||
what you set with git config earlier).
|
||||
|
||||
Running git commit first checks for any errors and warnings using lint.
|
||||
If there are any, you must go back and fix them before submitting your
|
||||
commit. You can do so by making the necessary changes, and then staging
|
||||
your commit again.
|
||||
Running git commit first checks for any errors and warnings using lint. If
|
||||
there are any, you must go back and fix them before submitting your commit.
|
||||
You can do so by making the necessary changes, and then staging your commit again.
|
||||
|
||||
When there are no errors or warnings, your default text editor will
|
||||
open. This is where you will write your commit message.
|
||||
When there are no errors or warnings, your default text editor will open.
|
||||
This is where you will write your commit message.
|
||||
|
||||
The first line of your commit message is your commit summary. This is a
|
||||
brief one-line description of what you changed in the files using the
|
||||
template below:
|
||||
The first line of your commit message is your commit summary. This is a brief
|
||||
one-line description of what you changed in the files using the template
|
||||
below:
|
||||
|
||||
<filepath>: Short description
|
||||
|
||||
@@ -151,30 +143,29 @@ For example,
|
||||
**Note:** It is good practice to use present tense in your descriptions
|
||||
and do not punctuate your summary.
|
||||
|
||||
Then hit Enter. The next paragraph should be a more in-depth explanation
|
||||
of the changes you've made to the files. Again, it is good practice to
|
||||
use present tense. Ex.
|
||||
Then hit Enter. The next paragraph should be a more in-depth explanation of the
|
||||
changes you've made to the files. Again, it is good practice to use present
|
||||
tense. Ex.
|
||||
|
||||
Fix space prohibited between function name and open parenthesis,
|
||||
line over 80 characters, unnecessary braces for single statement
|
||||
blocks, space required before open brace errors and warnings.
|
||||
line over 80 characters, unnecessary braces for single statement blocks,
|
||||
space required before open brace errors and warnings.
|
||||
|
||||
When you have finished writing your commit message, save and exit the
|
||||
text editor. You have finished committing your change. If, after
|
||||
submitting your commit, you wish to make changes to it, running `git
|
||||
commit --amend` allows you to take back your commit and amend it.
|
||||
When you have finished writing your commit message, save and exit the text
|
||||
editor. You have finished committing your change. If, after submitting your
|
||||
commit, you wish to make changes to it, running `git commit --amend` allows
|
||||
you to take back your commit and amend it.
|
||||
|
||||
When you are done with your commit, run `git push` to push your commit
|
||||
to coreboot.org. **Note:** To submit as a private patch, use `git push
|
||||
origin HEAD:refs/for/master%private`. Submitting as a private patch
|
||||
means that your commit will be on review.coreboot.org, but is only
|
||||
visible to yourself and those you add as reviewers. This mode isn't
|
||||
perfect: Somebody who knows the commit ID can still fetch the change and
|
||||
everything it refers (e.g. parent commits).
|
||||
When you are done with your commit, run `git push` to push your commit to
|
||||
coreboot.org. **Note:** To submit as a private patch, use
|
||||
`git push origin HEAD:refs/for/master%private`. Submitting as a private patch
|
||||
means that your commit will be on review.coreboot.org, but is only visible to
|
||||
yourself and those you add as reviewers. This mode isn't perfect: Somebody who
|
||||
knows the commit ID can still fetch the change and everything it refers (e.g.
|
||||
parent commits).
|
||||
|
||||
This has been a quick primer on how to submit a change to Gerrit for
|
||||
review using git. You may wish to review the [Gerrit code review
|
||||
workflow
|
||||
This has been a quick primer on how to submit a change to Gerrit for review
|
||||
using git. You may wish to review the [Gerrit code review workflow
|
||||
documentation](https://gerrit-review.googlesource.com/Documentation/intro-user.html#code-review),
|
||||
especially if you plan to work on multiple changes at the same time.
|
||||
|
||||
@@ -205,14 +196,14 @@ in-depth explanation of the changes you've made to the files. Again, it
|
||||
is good practice to use present tense. Ex.
|
||||
|
||||
Fix space prohibited between function name and open parenthesis,
|
||||
line over 80 characters, unnecessary braces for single statement
|
||||
blocks, space required before open brace errors and warnings.
|
||||
line over 80 characters, unnecessary braces for single statement blocks,
|
||||
space required before open brace errors and warnings.
|
||||
|
||||
Then press Enter two times to move the cursor to below your description.
|
||||
To the left of the text boxes, there is an icon with an downward arrow.
|
||||
Press the arrow and select "Sign Off." Make sure that you are signing
|
||||
off with your name and email (i.e. **Your Name** **\<Your Email\>**,
|
||||
based on what you set with git config earlier).
|
||||
Press the arrow and select "Sign Off." Make sure that you are signing off
|
||||
with your name and email (i.e. **Your Name** **\<Your Email\>**, based on what
|
||||
you set with git config earlier).
|
||||
|
||||
Now, review each of your changes and mark either individual changes or
|
||||
an entire file as Ready to Commit by marking it as 'Staged'. To do
|
||||
@@ -243,11 +234,11 @@ and the commit succeeds, move to the command line and run `git push`.
|
||||
|
||||
Your commits can now be seen on review.coreboot.org if you select "Your"
|
||||
and click on "Changes" and can be reviewed by others. Your code will
|
||||
first be reviewed by build bot (Jenkins), which will either give you a
|
||||
warning or verify a successful build; if so, your commit will receive a
|
||||
+1. Other users may also give your commit +1. For a commit to be merged,
|
||||
it needs to receive a +2. **Note:** A +1 and a +1 does not make a +2.
|
||||
Only certain users can give a +2.
|
||||
first be reviewed by build bot (Jenkins), which will either give you a warning
|
||||
or verify a successful build; if so, your commit will receive a +1. Other
|
||||
users may also give your commit +1. For a commit to be merged, it needs
|
||||
to receive a +2. **Note:** A +1 and a +1 does not make a +2. Only certain users
|
||||
can give a +2.
|
||||
|
||||
## Step 6 (optional): bash-git-prompt
|
||||
|
||||
@@ -264,11 +255,9 @@ as this one is specific to bash.
|
||||
Alternatively, follow the instructions below:
|
||||
Run the following two commands in the command line:
|
||||
|
||||
```Bash
|
||||
cd
|
||||
git clone https://github.com/magicmonty/bash-git-prompt.git \
|
||||
.bash-git-prompt --depth=1
|
||||
```
|
||||
cd
|
||||
git clone https://github.com/magicmonty/bash-git-prompt.git .bash-git-prompt --depth=1
|
||||
|
||||
**Note:** cd will change your directory to your home directory, so the
|
||||
git clone command will be run there.
|
||||
|
||||
@@ -280,38 +269,36 @@ Finally, open the `~/.bashrc` file and append the following two lines:
|
||||
Now, whenever you are in a git repository, it will continuously display
|
||||
its state.
|
||||
|
||||
There also are additional configurations that you can change depending
|
||||
on your preferences. If you wish to do so, look at the "All configs for
|
||||
.bashrc" section on <https://github.com/magicmonty/bash-git-prompt>.
|
||||
Listed in that section are various lines that you can copy, uncomment
|
||||
and add to your .bashrc file to change the configurations. Example
|
||||
configurations include avoid fetching remote status, and supporting
|
||||
versions of Git older than 1.7.10.
|
||||
There also are additional configurations that you can change depending on your
|
||||
preferences. If you wish to do so, look at the "All configs for .bashrc" section
|
||||
on <https://github.com/magicmonty/bash-git-prompt>. Listed in that section are
|
||||
various lines that you can copy, uncomment and add to your .bashrc file to
|
||||
change the configurations. Example configurations include avoid fetching remote
|
||||
status, and supporting versions of Git older than 1.7.10.
|
||||
|
||||
## Appendix: Miscellaneous Advice
|
||||
|
||||
### Updating a commit after running git push:
|
||||
|
||||
Suppose you would like to update a commit that has already been pushed
|
||||
to the remote repository. If the commit you wish to update is the most
|
||||
recent commit you have made, after making your desired changes, stage
|
||||
the files (either using git add or in git cola), and amend the commit.
|
||||
To do so, if you are using the command line, run `git commit --amend`.
|
||||
If you are using git cola, click on the gear icon located on the upper
|
||||
left side under **Commit** and select **Amend Last Commit** in the drop
|
||||
down menu. Then, stage the files you have changed, commit the changes,
|
||||
and run git push to push the changes to the remote repository. Your
|
||||
change should be reflected in Gerrit as a new patch set.
|
||||
Suppose you would like to update a commit that has already been pushed to the
|
||||
remote repository. If the commit you wish to update is the most recent
|
||||
commit you have made, after making your desired changes, stage the files
|
||||
(either using git add or in git cola), and amend the commit. To do so,
|
||||
if you are using the command line, run `git commit --amend`. If you are
|
||||
using git cola, click on the gear icon located on the upper left side under
|
||||
**Commit** and select **Amend Last Commit** in the drop down menu. Then, stage
|
||||
the files you have changed, commit the changes, and run git push to push the
|
||||
changes to the remote repository. Your change should be reflected in Gerrit as
|
||||
a new patch set.
|
||||
|
||||
If, however, the commit you wish to update is not the most recent commit
|
||||
you have made, you will first need to checkout that commit. To do so,
|
||||
find the URL of the commit on <https://review.coreboot.org> and go to
|
||||
that page; if the commit is one that you previously pushed, it can be
|
||||
found by selecting **My** and then **Changes** in the upper left corner.
|
||||
To checkout this commit, in the upper right corner, click on
|
||||
**Download**, and copy the command listed next to checkout by clicking
|
||||
**Copy to clipboard**. Then, run the copied command in your coreboot
|
||||
repository. Now, the last commit should be the most recent commit to
|
||||
that patch; to update it, make your desired changes, stage the files,
|
||||
then amend and push the commit using the instructions in the above
|
||||
If, however, the commit you wish to update is not the most recent commit you
|
||||
have made, you will first need to checkout that commit. To do so, find the
|
||||
URL of the commit on <https://review.coreboot.org> and go to that page; if
|
||||
the commit is one that you previously pushed, it can be found by selecting
|
||||
**My** and then **Changes** in the upper left corner. To checkout this commit,
|
||||
in the upper right corner, click on **Download**, and copy the command listed
|
||||
next to checkout by clicking **Copy to clipboard**. Then, run the copied
|
||||
command in your coreboot repository. Now, the last commit should be the most
|
||||
recent commit to that patch; to update it, make your desired changes, stage
|
||||
the files, then amend and push the commit using the instructions in the above
|
||||
paragraph.
|
||||
|
@@ -1,32 +1,31 @@
|
||||
# Writing unit tests for coreboot
|
||||
|
||||
## Introduction
|
||||
General thoughts about unit testing coreboot can be found in [Unit
|
||||
testing coreboot](../technotes/2020-03-unit-testing-coreboot.md).
|
||||
Additionally, [code coverage](../technotes/2021-05-code-coverage.md)
|
||||
support is available for unit tests.
|
||||
General thoughts about unit testing coreboot can be found in
|
||||
[Unit testing coreboot](../technotes/2020-03-unit-testing-coreboot.md).
|
||||
Additionally, [code coverage](../technotes/2021-05-code-coverage.md) support
|
||||
is available for unit tests.
|
||||
|
||||
This document aims to guide developers through the process of adding and
|
||||
writing unit tests for coreboot modules.
|
||||
This document aims to guide developers through the process of adding and writing
|
||||
unit tests for coreboot modules.
|
||||
|
||||
As an example of unit under test, `src/device/i2c.c` (referred hereafter
|
||||
as UUT "Unit Under Test") will be used. This is simple module, thus it
|
||||
should be easy for the reader to focus solely on the testing logic,
|
||||
without the need to spend too much time on digging deeply into the
|
||||
source code details and flow of operations. That being said, a good
|
||||
understanding of what the unit under test is doing is crucial for
|
||||
writing unit tests.
|
||||
As an example of unit under test, `src/device/i2c.c` (referred hereafter as UUT
|
||||
"Unit Under Test") will be used. This is simple module, thus it should be easy
|
||||
for the reader to focus solely on the testing logic, without the need to spend
|
||||
too much time on digging deeply into the source code details and flow of
|
||||
operations. That being said, a good understanding of what the unit under test is
|
||||
doing is crucial for writing unit tests.
|
||||
|
||||
This tutorial should also be helpful for developers who want to follow
|
||||
[TDD](https://en.wikipedia.org/wiki/Test-driven_development). Even
|
||||
though TDD has a different work flow of building tests first, followed
|
||||
by the code that satisfies them, the process of writing tests and adding
|
||||
them to the tree is the same.
|
||||
[TDD](https://en.wikipedia.org/wiki/Test-driven_development). Even though TDD
|
||||
has a different work flow of building tests first, followed by the code that
|
||||
satisfies them, the process of writing tests and adding them to the tree is the
|
||||
same.
|
||||
|
||||
## Analysis of unit under test First of all, it is necessary to
|
||||
precisely establish what we want to test in a particular module. Usually
|
||||
this will be an externally exposed API, which can be used by other
|
||||
modules.
|
||||
## Analysis of unit under test
|
||||
First of all, it is necessary to precisely establish what we want to test in a
|
||||
particular module. Usually this will be an externally exposed API, which can be
|
||||
used by other modules.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
@@ -35,70 +34,66 @@ modules.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int i2c_read_field(unsigned int bus, uint8_t chip, uint8_t reg,
|
||||
uint8_t *data, uint8_t mask, uint8_t shift)
|
||||
int i2c_write_field(unsigned int bus, uint8_t chip, uint8_t reg,
|
||||
uint8_t data, uint8_t mask, uint8_t shift)
|
||||
int i2c_read_field(unsigned int bus, uint8_t chip, uint8_t reg, uint8_t *data,
|
||||
uint8_t mask, uint8_t shift)
|
||||
int i2c_write_field(unsigned int bus, uint8_t chip, uint8_t reg, uint8_t data,
|
||||
uint8_t mask, uint8_t shift)
|
||||
|
||||
For sake of simplicity, let's focus on `i2c_read_field` in this
|
||||
document.
|
||||
For sake of simplicity, let's focus on `i2c_read_field` in this document.
|
||||
```
|
||||
|
||||
Once the API is defined, the next question is __what__ this API is doing
|
||||
(or what it will be doing in case of TDD). In other words, what outputs
|
||||
we are expecting from particular functions, when providing particular
|
||||
input parameters.
|
||||
Once the API is defined, the next question is __what__ this API is doing (or
|
||||
what it will be doing in case of TDD). In other words, what outputs we are
|
||||
expecting from particular functions, when providing particular input parameters.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int i2c_read_field(unsigned int bus, uint8_t chip, uint8_t reg,
|
||||
uint8_t *data, uint8_t mask, uint8_t shift)
|
||||
int i2c_read_field(unsigned int bus, uint8_t chip, uint8_t reg, uint8_t *data,
|
||||
uint8_t mask, uint8_t shift)
|
||||
|
||||
This is a method which means to read content of register `reg` from
|
||||
i2c device on i2c `bus` and slave address `chip`, applying bit `mask`
|
||||
and offset `shift` to it. Returned data should be placed in `data`.
|
||||
This is a method which means to read content of register `reg` from i2c device
|
||||
on i2c `bus` and slave address `chip`, applying bit `mask` and offset `shift`
|
||||
to it. Returned data should be placed in `data`.
|
||||
```
|
||||
|
||||
The next step is to determine all external dependencies of UUT in order
|
||||
to mock them out. Usually we want to isolate the UUT as much as
|
||||
possible, so that the test result depends __only__ on the behavior of
|
||||
UUT and not on the other modules. While some software dependencies may
|
||||
be hard to be mock (for example due to complicated dependencies) and
|
||||
thus should be simply linked into the test binaries, all hardware
|
||||
dependencies need to be mocked out, since in the user-space host
|
||||
environment, targets hardware is not available.
|
||||
The next step is to determine all external dependencies of UUT in order to mock
|
||||
them out. Usually we want to isolate the UUT as much as possible, so that the
|
||||
test result depends __only__ on the behavior of UUT and not on the other
|
||||
modules. While some software dependencies may be hard to be mock (for example
|
||||
due to complicated dependencies) and thus should be simply linked into the test
|
||||
binaries, all hardware dependencies need to be mocked out, since in the
|
||||
user-space host environment, targets hardware is not available.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
|
||||
`i2c_read_field` is calling `i2c_readb`, which eventually invokes
|
||||
`i2c_transfer`. This method simply calls `platform_i2c_transfer`. The
|
||||
last function in the chain is a hardware-touching one, and defined
|
||||
separately for different SOCs. It is responsible for issuing
|
||||
transactions on the i2c bus. For the purpose of writing unit test,
|
||||
we should mock this function.
|
||||
`i2c_transfer`. This method simply calls `platform_i2c_transfer`. The last
|
||||
function in the chain is a hardware-touching one, and defined separately for
|
||||
different SOCs. It is responsible for issuing transactions on the i2c bus.
|
||||
For the purpose of writing unit test, we should mock this function.
|
||||
```
|
||||
|
||||
## Adding new tests
|
||||
In order to keep the tree clean, the `tests/` directory should mimic the
|
||||
`src/` directory, so that test harness code is placed in a location
|
||||
corresponding to UUT. Furthermore, the naming convention is to add the
|
||||
suffix `-test` to the UUT name when creating a new test harness file.
|
||||
In order to keep the tree clean, the `tests/` directory should mimic the `src/`
|
||||
directory, so that test harness code is placed in a location corresponding to
|
||||
UUT. Furthermore, the naming convention is to add the suffix `-test` to the UUT
|
||||
name when creating a new test harness file.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
|
||||
Considering that UUT is `src/device/i2c.c`, test file should be named
|
||||
`tests/device/i2c-test.c`. When adding a new test file, it needs to
|
||||
be registered with the coreboot unit testing infrastructure.
|
||||
`tests/device/i2c-test.c`. When adding a new test file, it needs to be
|
||||
registered with the coreboot unit testing infrastructure.
|
||||
```
|
||||
|
||||
Every directory under `tests/` should contain a Makefile.inc, similar to
|
||||
what can be seen under the `src/`. Register a new test in Makefile.inc,
|
||||
by __appending__ test name to the `tests-y` variable.
|
||||
Every directory under `tests/` should contain a Makefile.inc, similar to what
|
||||
can be seen under the `src/`. Register a new test in Makefile.inc, by
|
||||
__appending__ test name to the `tests-y` variable.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
@@ -108,11 +103,10 @@ by __appending__ test name to the `tests-y` variable.
|
||||
tests-y += i2c-test
|
||||
```
|
||||
|
||||
Next step is to list all source files, which should be linked together
|
||||
in order to create test binary. Usually a tests requires only two files
|
||||
- UUT and test harness code, but sometimes more is needed to provide the
|
||||
test environment. Source files are registered in `<test_name>-srcs`
|
||||
variable.
|
||||
Next step is to list all source files, which should be linked together in order
|
||||
to create test binary. Usually a tests requires only two files - UUT and test
|
||||
harness code, but sometimes more is needed to provide the test environment.
|
||||
Source files are registered in `<test_name>-srcs` variable.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
@@ -123,10 +117,9 @@ variable.
|
||||
i2c-test-srcs += src/device/i2c.c
|
||||
```
|
||||
|
||||
Above minimal configuration is a basis for further work. One can try to
|
||||
build and run test binary either by invoking `make
|
||||
tests/<test_dir>/<test_name>` or by running all unit tests (whole suite)
|
||||
for coreboot `make unit-tests`.
|
||||
Above minimal configuration is a basis for further work. One can try to build
|
||||
and run test binary either by invoking `make tests/<test_dir>/<test_name>` or by
|
||||
running all unit tests (whole suite) for coreboot `make unit-tests`.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
@@ -142,34 +135,31 @@ for coreboot `make unit-tests`.
|
||||
make unit-tests
|
||||
```
|
||||
|
||||
When trying to build test binary, one can often see linker complains
|
||||
about `undefined reference` to couple of symbols. This is one of
|
||||
solutions to determine all external dependencies of UUT - iteratively
|
||||
build test and resolve errors one by one. At this step, developer should
|
||||
decide either it's better to add an extra module to provide necessary
|
||||
definitions or rather mock such dependency. Quick guide through adding
|
||||
mocks is provided later in this doc.
|
||||
When trying to build test binary, one can often see linker complains about
|
||||
`undefined reference` to couple of symbols. This is one of solutions to
|
||||
determine all external dependencies of UUT - iteratively build test and resolve
|
||||
errors one by one. At this step, developer should decide either it's better to
|
||||
add an extra module to provide necessary definitions or rather mock such
|
||||
dependency. Quick guide through adding mocks is provided later in this doc.
|
||||
|
||||
## Writing new tests
|
||||
In coreboot, [Cmocka](https://cmocka.org/) is used as unit test
|
||||
framework. The project has exhaustive [API
|
||||
documentation](https://api.cmocka.org/). Let's see how we may
|
||||
incorporate it when writing tests.
|
||||
In coreboot, [Cmocka](https://cmocka.org/) is used as unit test framework. The
|
||||
project has exhaustive [API documentation](https://api.cmocka.org/). Let's see
|
||||
how we may incorporate it when writing tests.
|
||||
|
||||
### Assertions
|
||||
Testing the UUT consists of calling the functions in the UUT and
|
||||
comparing the returned values to the expected values. Cmocka implements
|
||||
[a set of assert
|
||||
macros](https://api.cmocka.org/group__cmocka__asserts.html) to compare a
|
||||
value with an expected value. If the two values do not match, the test
|
||||
Testing the UUT consists of calling the functions in the UUT and comparing the
|
||||
returned values to the expected values. Cmocka implements
|
||||
[a set of assert macros](https://api.cmocka.org/group__cmocka__asserts.html) to
|
||||
compare a value with an expected value. If the two values do not match, the test
|
||||
fails with an error message.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
|
||||
In our example, the simplest test is to call UUT for reading our fake
|
||||
devices registers and do all calculation in the test harness itself.
|
||||
At the end, let's compare integers with `assert_int_equal`.
|
||||
In our example, the simplest test is to call UUT for reading our fake devices
|
||||
registers and do all calculation in the test harness itself. At the end, let's
|
||||
compare integers with `assert_int_equal`.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
@@ -201,25 +191,24 @@ fails with an error message.
|
||||
### Mocks
|
||||
|
||||
#### Overview
|
||||
Many coreboot modules are low level software that touch hardware
|
||||
directly. Because of this, one of the most important and challenging
|
||||
part of writing tests is to design and implement mocks. A mock is a
|
||||
software component which implements the API of another component so that
|
||||
the test can verify that certain functions are called (or not called),
|
||||
verify the parameters passed to those functions, and specify the return
|
||||
values from those functions. Mocks are especially useful when the API to
|
||||
be implemented is one that accesses hardware components.
|
||||
Many coreboot modules are low level software that touch hardware directly.
|
||||
Because of this, one of the most important and challenging part of
|
||||
writing tests is to design and implement mocks. A mock is a software component
|
||||
which implements the API of another component so that the test can verify that
|
||||
certain functions are called (or not called), verify the parameters passed to
|
||||
those functions, and specify the return values from those functions. Mocks are
|
||||
especially useful when the API to be implemented is one that accesses hardware
|
||||
components.
|
||||
|
||||
When writing a mock, the developer implements the same API as the module
|
||||
being mocked. Such a mock may, for example, register a set of driver
|
||||
methods. Behind this API, there is usually a simulation of real
|
||||
hardware.
|
||||
When writing a mock, the developer implements the same API as the module being
|
||||
mocked. Such a mock may, for example, register a set of driver methods. Behind
|
||||
this API, there is usually a simulation of real hardware.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
|
||||
For purpose of our i2c test, we may introduce two i2c devices with
|
||||
set of registers, which simply are structs in memory.
|
||||
For purpose of our i2c test, we may introduce two i2c devices with set of
|
||||
registers, which simply are structs in memory.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
@@ -277,17 +266,16 @@ hardware.
|
||||
};
|
||||
```
|
||||
|
||||
Cmocka uses a feature that gcc provides for breaking dependencies at the
|
||||
link time. It is possible to override implementation of some function,
|
||||
with the method from test harness. This allows test harness to take
|
||||
control of execution from binary (during the execution of test), and
|
||||
stimulate UUT as required without changing the source code.
|
||||
Cmocka uses a feature that gcc provides for breaking dependencies at the link
|
||||
time. It is possible to override implementation of some function, with the
|
||||
method from test harness. This allows test harness to take control of execution
|
||||
from binary (during the execution of test), and stimulate UUT as required
|
||||
without changing the source code.
|
||||
|
||||
coreboot unit test infrastructure supports overriding of functions at
|
||||
link time. This is as simple as adding a `name_of_function` to be
|
||||
mocked into <test_name>-mocks variable in Makefile.inc. The result is
|
||||
that the test's implementation of that function is called instead of
|
||||
coreboot's.
|
||||
coreboot unit test infrastructure supports overriding of functions at link time.
|
||||
This is as simple as adding a `name_of_function` to be mocked into
|
||||
<test_name>-mocks variable in Makefile.inc. The result is that the test's
|
||||
implementation of that function is called instead of coreboot's.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
@@ -296,45 +284,44 @@ coreboot's.
|
||||
|
||||
i2c-test-mocks += platform_i2c_transfer
|
||||
|
||||
Now, dev can write own implementation of `platform_i2c_transfer`.
|
||||
This implementation instead of accessing real i2c bus, will
|
||||
write/read from fake structs.
|
||||
Now, dev can write own implementation of `platform_i2c_transfer`. This
|
||||
implementation instead of accessing real i2c bus, will write/read from
|
||||
fake structs.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
int platform_i2c_transfer(unsigned int bus, struct i2c_msg
|
||||
*segments, int count)
|
||||
int platform_i2c_transfer(unsigned int bus, struct i2c_msg *segments,
|
||||
int count)
|
||||
{
|
||||
}
|
||||
```
|
||||
|
||||
#### Checking mock's arguments
|
||||
A test can verify the parameters provided by the UUT to the mock
|
||||
function. The developer may also verify that number of calls to mock is
|
||||
correct and the order of calls to particular mocks is as expected (See
|
||||
[this](https://api.cmocka.org/group__cmocka__call__order.html)). The
|
||||
Cmocka macros for checking parameters are described
|
||||
[here](https://api.cmocka.org/group__cmocka__param.html). In general, in
|
||||
mock function, one makes a call to `check_expected(<param_name>)` and in
|
||||
the corresponding test function, `expect*()` macro, with description
|
||||
which parameter in which mock should have particular value, or be inside
|
||||
a described range.
|
||||
A test can verify the parameters provided by the UUT to the mock function. The
|
||||
developer may also verify that number of calls to mock is correct and the order
|
||||
of calls to particular mocks is as expected (See
|
||||
[this](https://api.cmocka.org/group__cmocka__call__order.html)). The Cmocka
|
||||
macros for checking parameters are described
|
||||
[here](https://api.cmocka.org/group__cmocka__param.html). In general, in mock
|
||||
function, one makes a call to `check_expected(<param_name>)` and in the
|
||||
corresponding test function, `expect*()` macro, with description which parameter
|
||||
in which mock should have particular value, or be inside a described range.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
|
||||
In our example, we may want to check that `platform_i2c_transfer` is
|
||||
fed with number of segments bigger than 0, each segment has flags
|
||||
which are in supported range and each segment has buf which is
|
||||
non-NULL. We are expecting such values for _every_ call, thus the
|
||||
last parameter in `expect*` macros is -1.
|
||||
In our example, we may want to check that `platform_i2c_transfer` is fed with
|
||||
number of segments bigger than 0, each segment has flags which are in
|
||||
supported range and each segment has buf which is non-NULL. We are expecting
|
||||
such values for _every_ call, thus the last parameter in `expect*` macros is
|
||||
-1.
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
static void mock_expect_params_platform_i2c_transfer(void)
|
||||
{
|
||||
unsigned long int expected_flags[] = {0, I2C_M_RD,
|
||||
I2C_M_TEN, I2C_M_RECV_LEN, I2C_M_NOSTART};
|
||||
unsigned long int expected_flags[] = {0, I2C_M_RD, I2C_M_TEN,
|
||||
I2C_M_RECV_LEN, I2C_M_NOSTART};
|
||||
|
||||
/* Flags should always be only within supported range */
|
||||
expect_in_set_count(platform_i2c_transfer, segments->flags,
|
||||
@@ -343,8 +330,8 @@ a described range.
|
||||
expect_not_value_count(platform_i2c_transfer, segments->buf,
|
||||
NULL, -1);
|
||||
|
||||
expect_in_range_count(platform_i2c_transfer, count, 1,
|
||||
INT_MAX, -1);
|
||||
expect_in_range_count(platform_i2c_transfer, count, 1, INT_MAX,
|
||||
-1);
|
||||
}
|
||||
|
||||
And the checks below should be added to our mock
|
||||
@@ -360,11 +347,11 @@ a described range.
|
||||
```
|
||||
|
||||
#### Instrument mocks
|
||||
It is possible for the test function to instrument what the mock will
|
||||
return to the UUT. This can be done by using the `will_return*()` and
|
||||
`mock()` macros. These are described in [the Mock Object
|
||||
section](https://api.cmocka.org/group__cmocka__mock.html) of the Cmocka
|
||||
API documentation.
|
||||
It is possible for the test function to instrument what the mock will return to
|
||||
the UUT. This can be done by using the `will_return*()` and `mock()` macros.
|
||||
These are described in
|
||||
[the Mock Object section](https://api.cmocka.org/group__cmocka__mock.html) of
|
||||
the Cmocka API documentation.
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: Example
|
||||
@@ -374,18 +361,17 @@ API documentation.
|
||||
```
|
||||
|
||||
### Test runner
|
||||
Finally, the developer needs to implement the test `main()` function.
|
||||
All tests should be registered there and cmocka test runner invoked. All
|
||||
methods for invoking Cmocka test are described
|
||||
Finally, the developer needs to implement the test `main()` function. All tests
|
||||
should be registered there and cmocka test runner invoked. All methods for
|
||||
invoking Cmocka test are described
|
||||
[here](https://api.cmocka.org/group__cmocka__exec.html).
|
||||
|
||||
```eval_rst
|
||||
.. admonition:: i2c-test example
|
||||
|
||||
We don't need any extra setup and teardown functions for i2c-test, so
|
||||
let's simply register test for `i2c_read_field` and return from main
|
||||
value which is output of Cmocka's runner (it returns number of tests
|
||||
that failed).
|
||||
We don't need any extra setup and teardown functions for i2c-test, so let's
|
||||
simply register test for `i2c_read_field` and return from main value which is
|
||||
output of Cmocka's runner (it returns number of tests that failed).
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
@@ -1,36 +1,19 @@
|
||||
|
||||
[//]: # ( DO NOT EDIT - AUTOGENERATED FILE )
|
||||
|
||||
[//]: # ( RUN 'util/util_readme/util_readme.sh' to regenerate )
|
||||
|
||||
# Utilities
|
||||
|
||||
## List of utils
|
||||
|
||||
_Scripts and programs found in the coreboot `./util` directory_
|
||||
|
||||
* __abuild__ - coreboot autobuild script builds coreboot images for all
|
||||
available targets. `bash`
|
||||
* __acpi__ - Walk through all ACPI tables with their addresses. `bash`
|
||||
* __amdfwtool__ - Create AMD Firmware combination `C`
|
||||
* __amdtools__ Various tools for AMD processors
|
||||
* _update_efs_spi_speed_ - Change SPI speed in binary. `Bash`
|
||||
* Tools to compare extended K8 memory settings.
|
||||
* _k8-compare-pci-space.pl_ - Shows differences between values
|
||||
in PCI space and the default value. `Perl`
|
||||
* _k8-interpret-extended-memory-settings.pl_ - Shows
|
||||
differences between memory controller values and the default value.
|
||||
`Perl`
|
||||
* _k8-read-mem-settings.sh_ - Makes data files understood by
|
||||
the k8-interpret-extended-memory-settings script. `Bash`
|
||||
* _parse-bkdg.pl_ - Make bkdg.data file used by above scripts.
|
||||
`Perl`
|
||||
* _example_input_ - Sample input for the above scripts. `Text`
|
||||
* __amdtools__ - A set of tools to compare extended) K8 memory
|
||||
settings. `Perl`
|
||||
* __apcb__ - AMD PSP Control Block tools
|
||||
* _apcb_edit.py_ - This tool allows patching an existing APCB
|
||||
binary with specific SPDs and GPIO selection pins. `Python3`
|
||||
* _apcb_v3_edit.py_ - This tool allows patching an existing
|
||||
APCB v3 binary with up to 16 specific SPDs. `Python3`
|
||||
* _apcb_v3_edit.py_ - This tool allows patching an existing APCB V3
|
||||
binary with specific SPDs. `Python3`
|
||||
* __archive__ - Concatenate files and create an archive `C`
|
||||
* __autoport__ - Automated porting coreboot to Sandy Bridge/Ivy Bridge
|
||||
platforms `Go`
|
||||
@@ -42,42 +25,42 @@ status repository `Bash` `Go`
|
||||
* __cavium__ - Devicetree_convert Tool to convert a DTB to a static C
|
||||
file `Python`
|
||||
* __cbfstool__
|
||||
* _cbfstool_ - For manipulating CBFS file `C`
|
||||
* [_cbfstool_](cbfstool/index.md) - For manipulating CBFS file
|
||||
`C`
|
||||
* _fmaptool_ - Converts plaintext fmd files into fmap blobs `C`
|
||||
* _rmodtool_ - Creates rmodules `C`
|
||||
* _ifwitool_ - For manipulating IFWI `C`
|
||||
* __cbmem__ - CBMEM parser to read e.g. timestamps and console log `C`
|
||||
* __chromeos__ - These scripts can be used to access ChromeOS
|
||||
* __chromeos__ - These scripts can be used to access Chrome OS
|
||||
resources, for example to extract System Agent reference code and other
|
||||
blobs (e.g. mrc.bin, refcode, VGA option roms) from a ChromeOS
|
||||
blobs (e.g. mrc.bin, refcode, VGA option roms) from a Chrome OS
|
||||
recovery image. `C`
|
||||
* __crossgcc__ - A cross toolchain builder for -elf toolchains (ie. no
|
||||
libc support) `Bash`
|
||||
libc support)
|
||||
* __docker__ - Dockerfiles for _coreboot-sdk_, _coreboot-jenkins-node_,
|
||||
_coreboot.org-status_ and _docs.coreboot.org_ `Make`
|
||||
_coreboot.org-status_ and _docs.coreboot.org_
|
||||
* __dtd_parser__ - DTD structure parser `Python2`
|
||||
* __ectool__ - Dumps the RAM of a laptop's Embedded/Environmental
|
||||
Controller (EC). `C`
|
||||
* __exynos__ - Computes and fills Exynos ROM checksum (for BL1 or BL2).
|
||||
`Python3`
|
||||
* __find_usbdebug__ - Help find USB debug ports `Bash`
|
||||
* __find_usbdebug__ - Help find USB debug ports
|
||||
* __futility__ - Firmware utility for signing ChromeOS images `Make`
|
||||
* __fuzz-tests__ - Create test cases that crash the jpeg code. `C`
|
||||
* __genbuild_h__ - Generate build system definitions `Shell`
|
||||
* __gitconfig__ - Initialize git repository submodules install git
|
||||
hooks `Bash`
|
||||
* __ifdtool__ - Extract and dump Intel Firmware Descriptor information
|
||||
`C`
|
||||
* [__ifdtool__](ifdtool/index.md) - Extract and dump Intel Firmware
|
||||
Descriptor information `C`
|
||||
* __intelmetool__ - Dump interesting things about Management Engine
|
||||
even if hidden `C`
|
||||
* __intelp2m__ - convert the configuration DW0/1 registers value from
|
||||
an inteltool dump to coreboot macros. `go`
|
||||
* __intelp2m__ - Intel Pad to Macro (intelp2m) converter 'Go'
|
||||
* __inteltool__ - Provides information about the Intel CPU/chipset
|
||||
hardware configuration (register contents, MSRs, etc). `C`
|
||||
* __intelvbttool__ - Parse VBT from VGA BIOS `C`
|
||||
* __ipqheader__
|
||||
* _createxbl.py_ - Concatenates XBL segments into one ELF image
|
||||
`Python`
|
||||
* _createxbl.py_ - Concatenates XBL segments into one ELF
|
||||
image `Python`
|
||||
* _ipqheader.py_ - Returns a packed MBN header image with the
|
||||
specified base and size `Python`
|
||||
* _mbncat.py_ - Generate ipq8064 uber SBL `Python`
|
||||
@@ -88,8 +71,6 @@ firmware of many HP laptops with 8051-based SMSC KBC1098/KBC1126
|
||||
embedded controller and insert them to the firmware image. `C`
|
||||
* __kconfig__ - Build system `Make`
|
||||
* __lint__ - Source linter and linting rules `Shell`
|
||||
* __liveiso__ - A script and NixOS configuration files to create an ISO
|
||||
image for testing purposes and for working on firmware. `Bash`
|
||||
* __mainboard__ - mainboard specific scripts
|
||||
* _google_ - Directory for google mainboard specific scripts
|
||||
* __marvell__ - Add U-Boot boot loader for Marvell ARMADA38X `C`
|
||||
@@ -101,12 +82,14 @@ partial deblobbing of Intel ME/TXE firmware images `Python`
|
||||
* __nvidia__ - nvidia blob parsers
|
||||
* __nvramtool__ - Reads and writes coreboot parameters and displaying
|
||||
information from the coreboot table in CMOS/NVRAM. `C`
|
||||
* __pgtblgen__ - Generates page tables based on fixed physical address.
|
||||
`C`
|
||||
* __pmh7tool__ - Dumps, reads and writes PMH7 registers on Lenovo
|
||||
ThinkPads. PMH7 is used for switching on and off the power of some
|
||||
devices on the board such as dGPU. `C`
|
||||
* __post__ - Userspace utility that can be used to test POST cards. `C`
|
||||
* __qemu__ - Makefile & comprehensive default config for QEMU Q35
|
||||
emulation `Make`
|
||||
emulation
|
||||
* __qualcomm__ - CMM script to debug Qualcomm coreboot environments.
|
||||
`CMM`
|
||||
* __release__ - Generate coreboot release `Bash`
|
||||
@@ -123,7 +106,7 @@ command line `Bash`
|
||||
* _cross-repo-cherrypick_ - Pull in patches from another tree
|
||||
from a gerrit repository. `Shell`
|
||||
* _decode_spd.sh_ - Decodes Serial Presence Detect (SPD) files
|
||||
into various human readable formats. `Bash`
|
||||
into various human readable formats.
|
||||
* _dts-to-fmd.sh_ -Converts a depthcharge fmap.dts into an
|
||||
fmaptool compatible .fmd format `Bash`
|
||||
* _find-unused-kconfig-symbols.sh_ - Points out Kconfig
|
||||
@@ -144,6 +127,12 @@ file `Perl`
|
||||
* __spdtool__ - Dumps SPD ROMs from a given blob to separate files
|
||||
using known patterns and reserved bits. Useful for analysing firmware
|
||||
that holds SPDs on boards that have soldered down DRAM. `python`
|
||||
* __spd_tools__ - Tools for generating SPD files for DDR4 memory used
|
||||
in platforms with memory down configuration.
|
||||
* _gen_spd.go_ - Generates de-duplicated SPD files using a
|
||||
global memory part list provided by the mainboard in JSON format. `Go`
|
||||
* _gen_part_id.go_ - Allocates DRAM strap IDs for different
|
||||
DDR4 memory parts used by the board. `Go`
|
||||
* __spkmodem_recv__ - Decode spkmodem signals `C`
|
||||
* __superiotool__ - A user-space utility to detect Super I/O of a
|
||||
mainboard and provide detailed information about the register contents
|
||||
@@ -163,11 +152,10 @@ the documentation `Bash`
|
||||
`Go`
|
||||
* __xcompile__ - Cross compile setup `Bash`
|
||||
|
||||
## In depth documentation
|
||||
|
||||
* [cbfstool](util/cbfstool/index.md)
|
||||
* [ifdtool](util/ifdtool/index.md)
|
||||
* [intelp2m](util/intelp2m/index.md)
|
||||
## In depth documentation
|
||||
|
||||
* [ifdtool](ifdtool/index.md)
|
||||
|
||||
## Generated documentation
|
||||
|
||||
|
@@ -1,210 +0,0 @@
|
||||
Intel Pad to Macro (intelp2m) converter
|
||||
=======================================
|
||||
|
||||
This utility allows one to convert the configuration DW0/1 register
|
||||
values from an inteltool dump to coreboot macros.
|
||||
|
||||
```bash
|
||||
cd util/intelp2m
|
||||
make
|
||||
./intelp2m -h
|
||||
./intelp2m -file /path/to/inteltool.log
|
||||
```
|
||||
|
||||
### Platforms
|
||||
|
||||
It is possible to use templates for parsing inteltool.log files.
|
||||
To specify such a pattern, use the option `-t <template number>`.
|
||||
|
||||
```text
|
||||
-t
|
||||
template type number
|
||||
0 - inteltool.log (default)
|
||||
1 - gpio.h
|
||||
2 - your template
|
||||
```
|
||||
|
||||
For example, using template type 1, you can parse gpio.h from an
|
||||
existing board in the coreboot project.
|
||||
|
||||
```bash
|
||||
./intelp2m -t 1 -file coreboot/src/mainboard/yourboard/gpio.h
|
||||
```
|
||||
|
||||
You can also add a template to 'parser/template.go' for your file type
|
||||
with the configuration of the pads.
|
||||
|
||||
platform type is set using the -p option (Sunrise by default):
|
||||
|
||||
```text
|
||||
-p string
|
||||
set up a platform
|
||||
snr - Sunrise PCH with Skylake/Kaby Lake CPU
|
||||
lbg - Lewisburg PCH with Xeon SP CPU
|
||||
apl - Apollo Lake SoC
|
||||
cnl - CannonLake-LP or Whiskeylake/Coffeelake/Cometlake-U SoC
|
||||
adl - AlderLake PCH
|
||||
(default "snr")
|
||||
```
|
||||
|
||||
```bash
|
||||
./intelp2m -p <platform> -file path/to/inteltool.log
|
||||
```
|
||||
|
||||
### Packages
|
||||
|
||||
![][pckgs]
|
||||
|
||||
[pckgs]: gopackages.png
|
||||
|
||||
### Bit fields in macros
|
||||
|
||||
Use the `-fld=cb` option to only generate a sequence of bit fields in
|
||||
a new macro:
|
||||
|
||||
```bash
|
||||
./intelp2m -fld cb -p apl -file ../apollo-inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
_PAD_CFG_STRUCT(GPIO_37, PAD_FUNC(NF1) | PAD_TRIG(OFF) | PAD_TRIG(OFF), \
|
||||
PAD_PULL(DN_20K)), /* LPSS_UART0_TXD */
|
||||
```
|
||||
|
||||
### Raw DW0, DW1 register value
|
||||
|
||||
To generate the gpio.c with raw PAD_CFG_DW0 and PAD_CFG_DW1 register
|
||||
values you need to use the -fld=raw option:
|
||||
|
||||
```bash
|
||||
./intelp2m -fld raw -file /path/to/inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
_PAD_CFG_STRUCT(GPP_A10, 0x44000500, 0x00000000),
|
||||
```
|
||||
|
||||
```bash
|
||||
./intelp2m -iiii -fld raw -file /path/to/inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
/* GPP_A10 - CLKOUT_LPC1 */
|
||||
/* DW0: 0x44000500, DW1: 0x00000000 */
|
||||
/* DW0: 0x04000100 - IGNORED */
|
||||
/* PAD_CFG_NF(GPP_A10, NONE, DEEP, NF1), */
|
||||
_PAD_CFG_STRUCT(GPP_A10, 0x44000500, 0x00000000),
|
||||
```
|
||||
|
||||
### Macro Check
|
||||
|
||||
After generating the macro, the utility checks all used
|
||||
fields of the configuration registers. If some field has been
|
||||
ignored, the utility generates field macros. To not check
|
||||
macros, use the -n option:
|
||||
|
||||
```bash
|
||||
./intelp2m -n -file /path/to/inteltool.log
|
||||
```
|
||||
|
||||
In this case, some fields of the configuration registers
|
||||
DW0 will be ignored.
|
||||
|
||||
```c
|
||||
PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_38, UP_20K, DEEP, NF1, HIZCRx1, DISPUPD),
|
||||
PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_39, UP_20K, DEEP, NF1, TxLASTRxE, DISPUPD),
|
||||
```
|
||||
|
||||
### Information level
|
||||
|
||||
The utility can generate additional information about the bit
|
||||
fields of the DW0 and DW1 configuration registers. Using the
|
||||
options -i, -ii, -iii, -iiii you can set the info level from
|
||||
1 to 4:
|
||||
|
||||
```bash
|
||||
./intelp2m -i -file /path/to/inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
_PAD_CFG_STRUCT(GPIO_39, PAD_FUNC(NF1) | PAD_RESET(DEEP) | PAD_TRIG(OFF),\
|
||||
PAD_PULL(UP_20K) | PAD_IOSTERM(DISPUPD)), /* LPSS_UART0_TXD */
|
||||
```
|
||||
|
||||
```bash
|
||||
./intelp2m -ii -file /path/to/inteltool.log
|
||||
./intelp2m -iii -file /path/to/inteltool.log
|
||||
./intelp2m -iiii -file /path/to/inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
/* GPIO_39 - LPSS_UART0_TXD */
|
||||
/* DW0: 0x44000400, DW1: 0x00003100 */ --> (ii)
|
||||
/* DW0 : PAD_TRIG(OFF) - IGNORED */ --> (iii)
|
||||
/* PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_39, UP_20K, DEEP, NF1, TxLASTRxE,
|
||||
DISPUPD), */ --> (iiii)
|
||||
_PAD_CFG_STRUCT(GPIO_39, PAD_FUNC(NF1) | PAD_RESET(DEEP) | PAD_TRIG(OFF),
|
||||
PAD_PULL(UP_20K) | PAD_IOSTERM(DISPUPD)),
|
||||
```
|
||||
|
||||
If the -n switch was used and macros was generated without checking:
|
||||
```c
|
||||
/* GPIO_39 - LPSS_UART0_TXD */ --> (i)
|
||||
/* DW0: 0x44000400, DW1: 0x00003100 */ --> (ii)
|
||||
/* DW0: PAD_TRIG(OFF) - IGNORED */ --> (iii)
|
||||
/* _PAD_CFG_STRUCT(GPIO_39, PAD_FUNC(NF1) | PAD_RESET(DEEP) |
|
||||
PAD_TRIG(OFF), PAD_PULL(UP_20K) | PAD_IOSTERM(DISPUPD)), */ --> (iiii)
|
||||
PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_39, UP_20K, DEEP, NF1, TxLASTRxE, \
|
||||
DISPUPD),
|
||||
```
|
||||
|
||||
### Ignoring Fields
|
||||
|
||||
Utilities can generate the _PAD_CFG_STRUCT macro and exclude fields
|
||||
from it that are not in the corresponding PAD_CFG_*() macro:
|
||||
|
||||
```bash
|
||||
./intelp2m -iiii -fld cb -ign -file /path/to/inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
/* GPIO_39 - LPSS_UART0_TXD */
|
||||
/* DW0: 0x44000400, DW1: 0x00003100 */
|
||||
/* DW0: PAD_TRIG(OFF) - IGNORED */
|
||||
/* PAD_CFG_NF_IOSSTATE_IOSTERM(GPIO_39, UP_20K, DEEP, NF1,
|
||||
TxLASTRxE, DISPUPD), */
|
||||
_PAD_CFG_STRUCT(GPIO_39, PAD_FUNC(NF1) | PAD_RESET(DEEP), \
|
||||
PAD_PULL(UP_20K) | PAD_IOSTERM(DISPUPD)),
|
||||
```
|
||||
|
||||
### FSP-style macro
|
||||
|
||||
The utility allows one to generate macros that include fsp/edk2-platform
|
||||
style bitfields:
|
||||
|
||||
```bash
|
||||
./intelp2m -i -fld fsp -p lbg -file ../crb-inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
{ GPIO_SKL_H_GPP_A12, { GpioPadModeGpio, GpioHostOwnAcpi, GpioDirInInvOut,
|
||||
GpioOutLow, GpioIntSci | GpioIntLvlEdgDis, GpioResetNormal, GpioTermNone,
|
||||
GpioPadConfigLock }, /* GPIO */
|
||||
```
|
||||
|
||||
```bash
|
||||
./intelp2m -iiii -fld fsp -p lbg -file ../crb-inteltool.log
|
||||
```
|
||||
|
||||
```c
|
||||
/* GPP_A12 - GPIO */
|
||||
/* DW0: 0x80880102, DW1: 0x00000000 */
|
||||
/* PAD_CFG_GPI_SCI(GPP_A12, NONE, PLTRST, LEVEL, INVERT), */
|
||||
{ GPIO_SKL_H_GPP_A12, { GpioPadModeGpio, GpioHostOwnAcpi, GpioDirInInvOut,
|
||||
GpioOutLow, GpioIntSci | GpioIntLvlEdgDis, GpioResetNormal, GpioTermNone,
|
||||
GpioPadConfigLock },
|
||||
```
|
||||
|
||||
### Supported Chipsets
|
||||
|
||||
Sunrise PCH, Lewisburg PCH, Apollo Lake SoC, CannonLake-LP SoCs
|
@@ -7,17 +7,17 @@ Copyright © 2012 Intel Corporation
|
||||
Copyright 2012 Red Hat Inc.
|
||||
Copyright 2013 Google Inc.
|
||||
Copyright 2014 Google Inc.
|
||||
Copyright 2014 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright 2014 The Chromium OS Authors. All rights reserved.
|
||||
Copyright 2015 Google Inc.
|
||||
Copyright 2015, Google Inc.
|
||||
Copyright 2016 Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
||||
Copyright 2016 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright 2016 The Chromium OS Authors. All rights reserved.
|
||||
Copyright 2017-2019 Eltan B.V.
|
||||
Copyright 2017 Google Inc.
|
||||
Copyright 2018 Generated Code
|
||||
Copyright 2018-present Facebook, Inc.
|
||||
Copyright 2019 9Elements Agency GmbH <patrick.rudolph@9elements.com>
|
||||
Copyright 2019 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright 2019 The Chromium OS Authors. All rights reserved.
|
||||
Copyright (C) 2002 David S. Peterson. All rights reserved.
|
||||
Copyright (c) 2003-2016 Cavium Inc. (support@cavium.com). All rights
|
||||
Copyright (c) 2003-2017 Cavium Inc. (support@cavium.com). All rights
|
||||
@@ -35,7 +35,7 @@ Copyright (c) 2010-2017, The Regents of the University of California
|
||||
Copyright (c) 2010, Code Aurora Forum. All rights reserved.
|
||||
Copyright (C) 2010 coresystems GmbH
|
||||
Copyright (c) 2010 Per Odlund <per.odlund@armagedon.se>
|
||||
Copyright (c) 2010 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright (c) 2010 The Chromium OS Authors. All rights reserved.
|
||||
Copyright (c) 2011-2012, Code Aurora Forum. All rights reserved.
|
||||
Copyright (c) 2011-2012 The Linux Foundation. All rights reserved.
|
||||
Copyright (c) 2011-2012, The Linux Foundation. All rights reserved.
|
||||
@@ -52,14 +52,14 @@ Copyright (c) 2012, 2016-2019 Advanced Micro Devices, Inc.
|
||||
Copyright (c) 2012-2019 The Linux Foundation. All rights reserved.
|
||||
Copyright (c) 2012-2019 The Linux Foundation. All rights reserved.*
|
||||
Copyright (c) 2012, Code Aurora Forum. All rights reserved.
|
||||
Copyright (c) 2012 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright (c) 2012 The Chromium OS Authors. All rights reserved.
|
||||
Copyright (c) 2012 The Linux Foundation. All rights reserved.
|
||||
Copyright (c) 2012 The Linux Foundation. All rights reserved.*
|
||||
Copyright (c) 2013-2014, ARM Limited and Contributors. All rights reserved.
|
||||
Copyright (c) 2013-2015 Intel Corporation.
|
||||
Copyright (c) 2013-2017 Intel Corporation.
|
||||
Copyright (C) 2013 Google Inc.
|
||||
Copyright (c) 2013 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright (c) 2013 The Chromium OS Authors. All rights reserved.
|
||||
Copyright (c) 2013 The Linux Foundation. All rights reserved.
|
||||
Copyright (c) 2013, The Regents of the University of California (Regents).
|
||||
Copyright (C) 2014 - 2015, 2019 The Linux Foundation. All rights reserved.
|
||||
@@ -69,14 +69,14 @@ Copyright (C) 2014 - 2016 The Linux Foundation. All rights reserved.
|
||||
Copyright (c) 2014 Google Inc.
|
||||
Copyright (C) 2014 Google Inc.
|
||||
Copyright (c) 2014 Google Inc. All rights reserved.
|
||||
Copyright (c) 2014 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright (c) 2014 The Chromium OS Authors. All rights reserved.
|
||||
Copyright (C) 2014 The Linux Foundation. All rights reserved.
|
||||
Copyright (C) 2015-2016 Intel Corporation.
|
||||
Copyright (C) 2015-2016, Intel Corporation
|
||||
Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
|
||||
Copyright (C) 2015 Google Inc.
|
||||
Copyright (c) 2015, Intel Corporation. All rights reserved.
|
||||
Copyright (c) 2015 The ChromiumOS Authors. All rights reserved.
|
||||
Copyright (c) 2015 The Chromium OS Authors. All rights reserved.
|
||||
Copyright (C) 2015 The Linux Foundation. All rights reserved.
|
||||
Copyright (c) 2015, The Linux Foundation. All rights reserved.
|
||||
Copyright (C) 2015 Timothy Pearson <tpearson@raptorengineeringinc.com>, Raptor Engineering
|
||||
|
18
MAINTAINERS
18
MAINTAINERS
@@ -417,13 +417,6 @@ F: src/mainboard/protectli/
|
||||
|
||||
|
||||
|
||||
PRODRIVE ATLAS MAINBOARD
|
||||
M: Angel Pons <th3fanbus@gmail.com>
|
||||
M: Christian Walter <christian.walter@9elements.com>
|
||||
M: Lean Sheng Tan <sheng.tan@9elements.com>
|
||||
S: Maintained
|
||||
F: src/mainboard/prodrive/atlas/
|
||||
|
||||
PRODRIVE HERMES MAINBOARD
|
||||
M: Christian Walter <christian.walter@9elements.com>
|
||||
M: Patrick Rudolph <patrick.rudolph@9elements.com>
|
||||
@@ -620,7 +613,6 @@ M: Felix Held <felix-coreboot@felixheld.de>
|
||||
M: Jason Glenesk <jason.glenesk@gmail.com>
|
||||
M: Raul E Rangel <rrangel@chromium.org>
|
||||
M: Fred Reitberger <reitbergerfred@gmail.com>
|
||||
M: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
||||
S: Maintained
|
||||
F: src/soc/amd/cezanne/
|
||||
F: src/vendorcode/amd/fsp/cezanne/
|
||||
@@ -631,7 +623,6 @@ M: Felix Held <felix-coreboot@felixheld.de>
|
||||
M: Jason Glenesk <jason.glenesk@gmail.com>
|
||||
M: Raul E Rangel <rrangel@chromium.org>
|
||||
M: Fred Reitberger <reitbergerfred@gmail.com>
|
||||
M: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
||||
S: Maintained
|
||||
F: src/soc/amd/common/
|
||||
|
||||
@@ -641,7 +632,6 @@ M: Felix Held <felix-coreboot@felixheld.de>
|
||||
M: Jason Glenesk <jason.glenesk@gmail.com>
|
||||
M: Raul E Rangel <rrangel@chromium.org>
|
||||
M: Fred Reitberger <reitbergerfred@gmail.com>
|
||||
M: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
||||
S: Maintained
|
||||
F: src/soc/amd/picasso/
|
||||
F: src/vendorcode/amd/fsp/picasso/
|
||||
@@ -652,7 +642,6 @@ M: Felix Held <felix-coreboot@felixheld.de>
|
||||
M: Jason Glenesk <jason.glenesk@gmail.com>
|
||||
M: Raul E Rangel <rrangel@chromium.org>
|
||||
M: Fred Reitberger <reitbergerfred@gmail.com>
|
||||
M: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
||||
S: Maintained
|
||||
F: src/soc/amd/sabrina/
|
||||
F: src/vendorcode/amd/fsp/sabrina/
|
||||
@@ -660,7 +649,6 @@ F: src/vendorcode/amd/fsp/sabrina/
|
||||
AMD Stoneyridge
|
||||
M: Marshall Dawson <marshalldawson3rd@gmail.com>
|
||||
M: Felix Held <felix-coreboot@felixheld.de>
|
||||
M: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
|
||||
S: Odd Fixes
|
||||
F: src/soc/amd/stoneyridge/
|
||||
|
||||
@@ -690,12 +678,6 @@ M: Mariusz Szafranski <mariuszx.szafranski@intel.com>
|
||||
S: Maintained
|
||||
F: src/soc/intel/denverton_ns/
|
||||
|
||||
INTEL ELKHARTLAKE SOC
|
||||
M: Lean Sheng Tan <sheng.tan@9elements.com>
|
||||
M: Werner Zeh <werner.zeh@siemens.com>
|
||||
S: Maintained
|
||||
F: src/soc/intel/elkhartlake/
|
||||
|
||||
INTEL TIGERLAKE SOC
|
||||
M: Tim Wawrzynczak <twawrzynczak@chromium.org>
|
||||
S: Maintained
|
||||
|
51
Makefile
51
Makefile
@@ -31,7 +31,6 @@ KCONFIG_TRISTATE := $(obj)/tristate.conf
|
||||
KCONFIG_NEGATIVES := 1
|
||||
KCONFIG_STRICT := 1
|
||||
KCONFIG_PACKAGE := CB.Config
|
||||
KCONFIG_MAKEFILE_REAL ?= $(objk)/Makefile.real
|
||||
|
||||
COREBOOT_EXPORTS += KCONFIG_CONFIG KCONFIG_AUTOHEADER KCONFIG_AUTOCONFIG
|
||||
COREBOOT_EXPORTS += KCONFIG_DEPENDENCIES KCONFIG_SPLITCONFIG KCONFIG_TRISTATE
|
||||
@@ -45,7 +44,6 @@ CONFIG_SHELL := sh
|
||||
KBUILD_DEFCONFIG := configs/defconfig
|
||||
UNAME_RELEASE := $(shell uname -r)
|
||||
HAVE_DOTCONFIG := $(wildcard $(DOTCONFIG))
|
||||
HAVE_KCONFIG_MAKEFILE_REAL := $(wildcard $(KCONFIG_MAKEFILE_REAL))
|
||||
MAKEFLAGS += -rR --no-print-directory
|
||||
|
||||
# Make is silent per default, but 'make V=1' will show all compiler calls.
|
||||
@@ -66,6 +64,9 @@ HOSTCXXFLAGS := -g
|
||||
|
||||
PREPROCESS_ONLY := -E -P -x assembler-with-cpp -undef -I .
|
||||
|
||||
DOXYGEN := doxygen
|
||||
DOXYGEN_OUTPUT_DIR := doxygen
|
||||
|
||||
export $(COREBOOT_EXPORTS)
|
||||
|
||||
all: real-all
|
||||
@@ -76,6 +77,8 @@ help_coreboot help::
|
||||
@echo ' all - Build coreboot'
|
||||
@echo ' clean - Remove coreboot build artifacts'
|
||||
@echo ' distclean - Remove build artifacts and config files'
|
||||
@echo ' doxygen - Build doxygen documentation for coreboot'
|
||||
@echo ' doxyplatform - Build doxygen documentation for the current platform'
|
||||
@echo ' sphinx - Build sphinx documentation for coreboot'
|
||||
@echo ' sphinx-lint - Build sphinx documenttion for coreboot with warnings as errors'
|
||||
@echo ' filelist - Show files used in current build'
|
||||
@@ -89,20 +92,14 @@ help_coreboot help::
|
||||
# Order _does_ matter for pattern rules.
|
||||
include $(srck)/Makefile.inc
|
||||
|
||||
# The cases where we don't need fully populated $(obj) lists:
|
||||
# Three cases where we don't need fully populated $(obj) lists:
|
||||
# 1. when no .config exists
|
||||
# 2. When no $(obj)/util/kconfig/Makefile.real exists and we're building tools
|
||||
# 3. when make config (in any flavour) is run
|
||||
# 4. when make distclean is run
|
||||
# 2. when make config (in any flavour) is run
|
||||
# 3. when make distclean is run
|
||||
# Don't waste time on reading all Makefile.incs in these cases
|
||||
ifeq ($(strip $(HAVE_DOTCONFIG)),)
|
||||
NOCOMPILE:=1
|
||||
endif
|
||||
ifeq ($(strip $(HAVE_KCONFIG_MAKEFILE_REAL)),)
|
||||
ifneq ($(MAKECMDGOALS),tools)
|
||||
NOCOMPILE:=1
|
||||
endif
|
||||
endif
|
||||
ifneq ($(MAKECMDGOALS),)
|
||||
ifneq ($(filter %config %clean cross% clang iasl lint% help% what-jenkins-does,$(MAKECMDGOALS)),)
|
||||
NOCOMPILE:=1
|
||||
@@ -144,11 +141,9 @@ include $(TOPLEVEL)/util/testing/Makefile.inc
|
||||
-include $(TOPLEVEL)/site-local/Makefile.inc
|
||||
include $(TOPLEVEL)/tests/Makefile.inc
|
||||
real-all:
|
||||
@echo "Error: Trying to build, but NOCOMPILE is set." >&2
|
||||
@echo " Please file a bug with the following information:"
|
||||
@echo "- MAKECMDGOALS: $(MAKECMDGOALS)" >&2
|
||||
@echo "- HAVE_DOTCONFIG: $(HAVE_DOTCONFIG)" >&2
|
||||
@echo "- HAVE_KCONFIG_MAKEFILE_REAL: $(HAVE_KCONFIG_MAKEFILE_REAL)" >&2
|
||||
@echo "Error: Expected config file ($(DOTCONFIG)) not present." >&2
|
||||
@echo "Please specify a config file or run 'make menuconfig' to" >&2
|
||||
@echo "generate a new config file." >&2
|
||||
@exit 1
|
||||
else
|
||||
|
||||
@@ -455,7 +450,27 @@ sphinx:
|
||||
sphinx-lint:
|
||||
$(MAKE) SPHINXOPTS=-W -C Documentation -f Makefile.sphinx html
|
||||
|
||||
clean-for-update:
|
||||
doxy: doxygen
|
||||
doxygen:
|
||||
$(DOXYGEN) Documentation/Doxyfile.coreboot
|
||||
|
||||
doxygen_simple:
|
||||
$(DOXYGEN) Documentation/Doxyfile.coreboot_simple
|
||||
|
||||
doxyplatform doxygen_platform: $(obj)/project_filelist.txt
|
||||
echo
|
||||
echo "Building doxygen documentation for $(CONFIG_MAINBOARD_PART_NUMBER)"
|
||||
export DOXYGEN_OUTPUT_DIR="$$( echo $(DOXYGEN_OUTPUT_DIR)/$(call strip_quotes, $(CONFIG_MAINBOARD_VENDOR))_$(call strip_quotes, $(CONFIG_MAINBOARD_PART_NUMBER)) | sed 's|[^A-Za-z0-9/]|_|g' )"; \
|
||||
mkdir -p "$$DOXYGEN_OUTPUT_DIR"; \
|
||||
export DOXYFILES="$$(cat $(obj)/project_filelist.txt | grep -v '\.ld$$' | sed 's/\.aml/\.dsl/' | tr '\n' ' ')"; \
|
||||
export DOXYGEN_PLATFORM="$(call strip_quotes, $(CONFIG_MAINBOARD_DIR)) \($(call strip_quotes, $(CONFIG_MAINBOARD_PART_NUMBER))\) version $(KERNELVERSION)"; \
|
||||
$(DOXYGEN) Documentation/doxygen/Doxyfile.coreboot_platform
|
||||
|
||||
doxyclean: doxygen-clean
|
||||
doxygen-clean:
|
||||
rm -rf $(DOXYGEN_OUTPUT_DIR)
|
||||
|
||||
clean-for-update: doxygen-clean
|
||||
rm -rf $(obj) .xcompile
|
||||
|
||||
clean: clean-for-update clean-utils clean-payloads
|
||||
@@ -481,5 +496,5 @@ distclean: clean clean-ctags clean-cscope distclean-payloads distclean-utils
|
||||
rm -rf coreboot-builds coreboot-builds-chromeos
|
||||
rm -f abuild*.xml junit.xml* util/lint/junit.xml
|
||||
|
||||
.PHONY: $(PHONY) clean clean-for-update clean-cscope cscope distclean sphinx sphinx-lint
|
||||
.PHONY: $(PHONY) clean clean-for-update clean-cscope cscope distclean doxygen doxy doxygen_simple sphinx sphinx-lint
|
||||
.PHONY: ctags-project cscope-project clean-ctags
|
||||
|
61
Makefile.inc
61
Makefile.inc
@@ -190,33 +190,30 @@ ramstage-generic-ccopts += -D__RAMSTAGE__
|
||||
ifeq ($(CONFIG_COVERAGE),y)
|
||||
ramstage-c-ccopts += -fprofile-arcs -ftest-coverage
|
||||
endif
|
||||
ifneq ($(GIT),)
|
||||
ifneq ($(UPDATED_SUBMODULES),1)
|
||||
$(info Updating git submodules.)
|
||||
# try to fetch non-optional submodules if the source is under git
|
||||
forgetthis:=$(shell git submodule update --init $(quiet_errors))
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init $(quiet_errors)))
|
||||
# Checkout Cmocka repository
|
||||
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/cmocka $(quiet_errors))
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init --checkout 3rdparty/cmocka $(quiet_errors)))
|
||||
ifeq ($(CONFIG_USE_BLOBS),y)
|
||||
# These items are necessary because each has update=none in .gitmodules. They are ignored
|
||||
# until expressly requested and enabled with --checkout
|
||||
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/blobs $(quiet_errors))
|
||||
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/intel-microcode $(quiet_errors))
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init --checkout 3rdparty/blobs $(quiet_errors)))
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init --checkout 3rdparty/intel-microcode $(quiet_errors)))
|
||||
ifeq ($(CONFIG_FSP_USE_REPO),y)
|
||||
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/fsp $(quiet_errors))
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init --checkout 3rdparty/fsp $(quiet_errors)))
|
||||
endif
|
||||
ifeq ($(CONFIG_USE_AMD_BLOBS),y)
|
||||
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/amd_blobs $(quiet_errors))
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init --checkout 3rdparty/amd_blobs $(quiet_errors)))
|
||||
endif
|
||||
ifeq ($(CONFIG_USE_QC_BLOBS),y)
|
||||
forgetthis:=$(shell git submodule update --init --checkout 3rdparty/qc_blobs $(quiet_errors))
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init --checkout 3rdparty/qc_blobs $(quiet_errors)))
|
||||
endif
|
||||
endif
|
||||
UPDATED_SUBMODULES:=1
|
||||
COREBOOT_EXPORTS += UPDATED_SUBMODULES
|
||||
|
||||
endif
|
||||
endif # GIT != ""
|
||||
|
||||
postcar-c-deps:=$$(OPTION_TABLE_H)
|
||||
ramstage-c-deps:=$$(OPTION_TABLE_H)
|
||||
@@ -273,7 +270,7 @@ EMPTY_RESOURCE_TEMPLATE_WARNING = 3150
|
||||
# For existing ASL code, ignore this warnings
|
||||
IASL_MISSING_DEPENDENCY = 3141
|
||||
|
||||
IASL_WARNINGS_LIST = $(EMPTY_RESOURCE_TEMPLATE_WARNING)
|
||||
IASL_WARNINGS_LIST = $(EMPTY_RESOURCE_TEMPLATE_WARNING) $(REDUNDANT_OFFSET_REMARK)
|
||||
|
||||
ifeq ($(CONFIG_IGNORE_IASL_MISSING_DEPENDENCY),y)
|
||||
IASL_WARNINGS_LIST += $(IASL_MISSING_DEPENDENCY)
|
||||
@@ -343,7 +340,7 @@ cbfs-files-processor-struct= \
|
||||
$(eval $(2): $(1) $(obj)/build.h $(obj)/fmap_config.h $(KCONFIG_AUTOHEADER); \
|
||||
printf " CC+STRIP $(1)\n"; \
|
||||
$(CC_ramstage) -MMD $(CPPFLAGS_ramstage) $(CFLAGS_ramstage) --param asan-globals=0 $$(ramstage-c-ccopts) -include $(KCONFIG_AUTOHEADER) -MT $(2) -o $(2).tmp -c $(1) && \
|
||||
$(OBJCOPY_ramstage) -O binary --only-section='.data*' --only-section='.bss*' --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \
|
||||
$(OBJCOPY_ramstage) -O binary --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \
|
||||
rm -f $(2).tmp) \
|
||||
$(eval DEPENDENCIES += $(2).d)
|
||||
|
||||
@@ -1103,19 +1100,38 @@ ifeq ($(CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK),y)
|
||||
TS_OPTIONS := -j $(CONFIG_INTEL_TOP_SWAP_BOOTBLOCK_SIZE)
|
||||
endif
|
||||
|
||||
ifneq ($(CONFIG_ARCH_X86),y)
|
||||
add_bootblock = $(CBFSTOOL) $(1) write -u -r BOOTBLOCK -f $(2)
|
||||
endif
|
||||
|
||||
# coreboot.pre doesn't follow the standard Make conventions. It gets modified
|
||||
# by multiple rules, and thus we can't compute the dependencies correctly.
|
||||
$(shell rm -f $(obj)/coreboot.pre)
|
||||
|
||||
ifneq ($(CONFIG_UPDATE_IMAGE),y)
|
||||
$(obj)/coreboot.pre: $$(prebuilt-files) $(CBFSTOOL) $(obj)/fmap.fmap $(obj)/fmap.desc $(objcbfs)/bootblock.bin
|
||||
$(obj)/coreboot.pre: $(objcbfs)/bootblock.bin $$(prebuilt-files) $(CBFSTOOL) $(obj)/fmap.fmap $(obj)/fmap.desc
|
||||
$(CBFSTOOL) $@.tmp create -M $(obj)/fmap.fmap -r $(shell cat $(obj)/fmap.desc)
|
||||
printf " BOOTBLOCK\n"
|
||||
$(call add_bootblock,$@.tmp,$(objcbfs)/bootblock.bin)
|
||||
ifeq ($(CONFIG_ARCH_X86),y)
|
||||
$(CBFSTOOL) $@.tmp add \
|
||||
-f $(objcbfs)/bootblock.bin \
|
||||
-n bootblock \
|
||||
-t bootblock \
|
||||
$(TXTIBB) \
|
||||
-b -$(call file-size,$(objcbfs)/bootblock.bin) $(cbfs-autogen-attributes) \
|
||||
$(TS_OPTIONS) \
|
||||
$(CBFSTOOL_ADD_CMD_OPTIONS)
|
||||
else # ifeq ($(CONFIG_ARCH_X86),y)
|
||||
$(CBFSTOOL) $@.tmp write -u \
|
||||
-r BOOTBLOCK \
|
||||
-f $(objcbfs)/bootblock.bin
|
||||
# make space for the CBFS master header pointer. "ptr_" is just
|
||||
# arbitrary 4 bytes that will be overwritten by add-master-header.
|
||||
printf "ptr_" > $@.tmp.2
|
||||
$(CBFSTOOL) $@.tmp add \
|
||||
-f $@.tmp.2 \
|
||||
-n "header pointer" \
|
||||
-t "cbfs header" \
|
||||
-b -4 \
|
||||
$(CBFSTOOL_ADD_CMD_OPTIONS)
|
||||
rm -f $@.tmp.2
|
||||
endif # ifeq ($(CONFIG_ARCH_X86),y)
|
||||
$(CBFSTOOL) $@.tmp add-master-header $(TS_OPTIONS) $(CBFSTOOL_ADD_CMD_OPTIONS)
|
||||
$(prebuild-files) true
|
||||
mv $@.tmp $@
|
||||
else # ifneq ($(CONFIG_UPDATE_IMAGE),y)
|
||||
@@ -1165,13 +1181,6 @@ endif # CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE
|
||||
$(CBFSTOOL) $@ layout
|
||||
@printf " CBFSPRINT $(subst $(obj)/,,$(@))\n\n"
|
||||
$(CBFSTOOL) $@ print -r $(subst $(spc),$(comma),$(all-regions))
|
||||
ifeq ($(CONFIG_CBFS_VERIFICATION),y)
|
||||
line=$$($(CBFSTOOL) $@ print -kv 2>/dev/null | grep -F '[CBFS VERIFICATION (COREBOOT)]') ;\
|
||||
if ! printf "$$line" | grep -q 'fully valid'; then \
|
||||
echo "CBFS verification error: $$line" ;\
|
||||
exit 1 ;\
|
||||
fi
|
||||
endif # CONFIG_CBFS_VERIFICATION
|
||||
|
||||
cbfs-files-y += $(CONFIG_CBFS_PREFIX)/romstage
|
||||
$(CONFIG_CBFS_PREFIX)/romstage-file := $(objcbfs)/romstage.elf
|
||||
|
@@ -54,7 +54,8 @@ Build Requirements
|
||||
|
||||
Optional:
|
||||
|
||||
* gdb (for better debugging facilities on some targets)
|
||||
* doxygen (for generating/viewing documentation)
|
||||
* gdb (for better debugging facilities on some targets)
|
||||
* ncurses (for `make menuconfig` and `make nconfig`)
|
||||
* flex and bison (for regenerating parsers)
|
||||
|
||||
|
@@ -7,7 +7,7 @@ CONFIG_SPI_FLASH_SMM=y
|
||||
CONFIG_USE_BLOBS=y
|
||||
CONFIG_ANY_TOOLCHAIN=y
|
||||
|
||||
# ChromeOS
|
||||
# Chrome OS
|
||||
CONFIG_CHROMEOS=y
|
||||
CONFIG_HAS_RECOVERY_MRC_CACHE=y
|
||||
CONFIG_MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN=y
|
||||
|
@@ -12,4 +12,3 @@ CONFIG_DEBUG_BOOT_STATE=y
|
||||
CONFIG_DEBUG_ADA_CODE=y
|
||||
CONFIG_H8_FN_KEY_AS_VBOOT_RECOVERY_SW=y
|
||||
CONFIG_VBOOT=y
|
||||
CONFIG_USE_EXP_X86_64_SUPPORT=y
|
||||
|
@@ -1,19 +0,0 @@
|
||||
CONFIG_VENDOR_MSI=y
|
||||
CONFIG_CBFS_SIZE=0x1000000
|
||||
CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000
|
||||
CONFIG_TIANOCORE_BOOT_TIMEOUT=3
|
||||
CONFIG_BOARD_MSI_Z690_A_PRO_WIFI_DDR4=y
|
||||
CONFIG_POWER_STATE_OFF_AFTER_FAILURE=y
|
||||
CONFIG_PCIEXP_HOTPLUG=y
|
||||
CONFIG_PCIEXP_HOTPLUG_PREFETCH_MEM_BELOW_4G=y
|
||||
CONFIG_DEFAULT_CONSOLE_LOGLEVEL_0=y
|
||||
CONFIG_POST_DEVICE_PCI_PCIE=y
|
||||
CONFIG_POST_IO_PORT=0x80
|
||||
CONFIG_PAYLOAD_TIANOCORE=y
|
||||
CONFIG_TIANOCORE_REPOSITORY="https://github.com/Dasharo/edk2.git"
|
||||
CONFIG_TIANOCORE_TAG_OR_REV="origin/dasharo"
|
||||
CONFIG_TIANOCORE_CBMEM_LOGGING=y
|
||||
CONFIG_TIANOCORE_FOLLOW_BGRT_SPEC=y
|
||||
CONFIG_TIANOCORE_SD_MMC_TIMEOUT=1000
|
||||
CONFIG_TPM2=y
|
||||
CONFIG_TPM_MEASURED_BOOT=y
|
@@ -11,5 +11,3 @@ CONFIG_SMMSTORE_V2=y
|
||||
CONFIG_DEFAULT_CONSOLE_LOGLEVEL_3=y
|
||||
CONFIG_POST_DEVICE_LPC=y
|
||||
CONFIG_MAINBOARD_SERIAL_NUMBER="N/A"
|
||||
CONFIG_PCIEXP_SUPPORT_RESIZABLE_BARS=y
|
||||
CONFIG_PCIEXP_DEFAULT_MAX_RESIZABLE_BAR_BITS=36
|
||||
|
@@ -121,15 +121,6 @@ config COREINFO_SECONDARY_PAYLOAD
|
||||
coreinfo can be loaded as a secondary payload under SeaBIOS, GRUB,
|
||||
or any other payload that can load additional payloads.
|
||||
|
||||
config GRUB2_SECONDARY_PAYLOAD
|
||||
bool "Load GRUB2 as a secondary payload"
|
||||
default n
|
||||
depends on !PAYLOAD_GRUB2
|
||||
select PAYLOAD_BUILD_GRUB2
|
||||
help
|
||||
GRUB2 can be loaded as a secondary payload under SeaBIOS or any
|
||||
other payload that can load additional payloads.
|
||||
|
||||
config MEMTEST_SECONDARY_PAYLOAD
|
||||
bool "Load Memtest86+ as a secondary payload"
|
||||
default n
|
||||
@@ -146,17 +137,6 @@ config NVRAMCUI_SECONDARY_PAYLOAD
|
||||
nvramcui can be loaded as a secondary payload under SeaBIOS, GRUB,
|
||||
or any other payload that can load additional payloads.
|
||||
|
||||
config SEABIOS_SECONDARY_PAYLOAD
|
||||
bool "Load SeaBIOS as a secondary payload"
|
||||
default n
|
||||
depends on ARCH_X86
|
||||
depends on !PAYLOAD_SEABIOS
|
||||
depends on !PAYLOAD_SEAGRUB
|
||||
select PAYLOAD_BUILD_SEABIOS
|
||||
help
|
||||
SeaBIOS can be loaded as a secondary payload under GRUB or any
|
||||
other payload that can load additional payloads.
|
||||
|
||||
config TINT_SECONDARY_PAYLOAD
|
||||
bool "Load tint as a secondary payload"
|
||||
default n
|
||||
@@ -165,16 +145,6 @@ config TINT_SECONDARY_PAYLOAD
|
||||
tint can be loaded as a secondary payload under SeaBIOS, GRUB,
|
||||
or any other payload that can load additional payloads.
|
||||
|
||||
config COREDOOM_SECONDARY_PAYLOAD
|
||||
bool "Load coreDOOM as a secondary payload"
|
||||
default n
|
||||
depends on ARCH_X86
|
||||
help
|
||||
coreDOOM can be loaded as a secondary payload under SeaBIOS, GRUB,
|
||||
or any other payload that can load additional payloads. Requires a
|
||||
linear framebuffer. If built as a secondary payload for SeaBIOS, the
|
||||
generated VGA BIOS option rom is also required.
|
||||
|
||||
source "payloads/external/*/Kconfig.secondary"
|
||||
|
||||
endmenu # "Secondary Payloads"
|
||||
|
@@ -29,7 +29,6 @@ payloads/external/GRUB2 \
|
||||
payloads/external/LinuxBoot \
|
||||
payloads/external/Yabits \
|
||||
payloads/external/skiboot \
|
||||
payloads/external/coreDOOM \
|
||||
|
||||
force-payload:
|
||||
|
||||
|
@@ -186,6 +186,7 @@ static int parse_header(void *addr, int len)
|
||||
switch (rec->tag) {
|
||||
case CB_TAG_FORWARD:
|
||||
return parse_header((void *)(unsigned long)((struct cb_forward *)rec)->forward, 1);
|
||||
break;
|
||||
case CB_TAG_MEMORY:
|
||||
parse_memory(ptr);
|
||||
break;
|
||||
|
33
payloads/external/GRUB2/Kconfig
vendored
33
payloads/external/GRUB2/Kconfig
vendored
@@ -1,15 +1,5 @@
|
||||
config PAYLOAD_BUILD_GRUB2
|
||||
bool
|
||||
|
||||
if PAYLOAD_GRUB2
|
||||
|
||||
config PAYLOAD_FILE
|
||||
default "payloads/external/GRUB2/grub2/build/default_payload.elf"
|
||||
|
||||
endif
|
||||
|
||||
if PAYLOAD_BUILD_GRUB2
|
||||
|
||||
choice
|
||||
prompt "GRUB2 version"
|
||||
default GRUB2_STABLE
|
||||
@@ -52,9 +42,12 @@ config GRUB2_EXTRA_MODULES
|
||||
* gfxmenu for graphical menus (you'll need a theme as well)
|
||||
* gfxterm_background for setting background
|
||||
|
||||
config PAYLOAD_FILE
|
||||
default "payloads/external/GRUB2/grub2/build/default_payload.elf"
|
||||
|
||||
config GRUB2_INCLUDE_RUNTIME_CONFIG_FILE
|
||||
bool "Include GRUB2 runtime config file into ROM image"
|
||||
depends on PAYLOAD_BUILD_GRUB2
|
||||
depends on PAYLOAD_GRUB2
|
||||
default n
|
||||
help
|
||||
The GRUB2 payload reads its runtime configuration file from etc/grub.cfg
|
||||
@@ -79,21 +72,3 @@ config GRUB2_RUNTIME_CONFIG_FILE
|
||||
The path of the GRUB2 runtime configuration file to be added to CBFS.
|
||||
|
||||
endif
|
||||
|
||||
if PAYLOAD_SEAGRUB
|
||||
|
||||
config PAYLOAD_FILE
|
||||
default "payloads/external/SeaBIOS/seabios/out/bios.bin.elf"
|
||||
|
||||
config SEABIOS_BOOTORDER_FILE
|
||||
default "payloads/external/GRUB2/bootorder-seagrub"
|
||||
|
||||
config SEAGRUB_ALLOW_SEABIOS_BOOTMENU
|
||||
bool "Allow to access SeaBIOS boot menu before launching GRUB"
|
||||
help
|
||||
Enable this to allow the access to the boot menu of SeaBIOS. It
|
||||
increases the flexibility but allows to entirely bypass GRUB, along
|
||||
with all secure mechanism implemented in its runtime config.
|
||||
Please use this with caution.
|
||||
|
||||
endif
|
||||
|
13
payloads/external/GRUB2/Kconfig.name
vendored
13
payloads/external/GRUB2/Kconfig.name
vendored
@@ -1,22 +1,9 @@
|
||||
config PAYLOAD_GRUB2
|
||||
bool "GRUB2"
|
||||
depends on ARCH_X86 || ARCH_ARM
|
||||
select PAYLOAD_BUILD_GRUB2
|
||||
help
|
||||
Select this option if you want to build a coreboot image
|
||||
with a GRUB2 payload. If you don't know what this is
|
||||
about, just leave it enabled.
|
||||
|
||||
See https://coreboot.org/Payloads for more information.
|
||||
|
||||
config PAYLOAD_SEAGRUB
|
||||
bool "GRUB2 atop SeaBIOS"
|
||||
depends on ARCH_X86
|
||||
select PAYLOAD_BUILD_SEABIOS
|
||||
select GRUB2_SECONDARY_PAYLOAD
|
||||
help
|
||||
Select this option if you want to build a coreboot image
|
||||
with a GRUB2 payload running atop SeaBIOS to improve its
|
||||
hardware compatibility.
|
||||
|
||||
See https://coreboot.org/Payloads for more information.
|
||||
|
1
payloads/external/GRUB2/bootorder-seagrub
vendored
1
payloads/external/GRUB2/bootorder-seagrub
vendored
@@ -1 +0,0 @@
|
||||
/rom@img/grub2
|
55
payloads/external/LinuxBoot/Kconfig
vendored
55
payloads/external/LinuxBoot/Kconfig
vendored
@@ -258,61 +258,6 @@ config LINUXBOOT_UROOT_COMMANDS
|
||||
List of additional modules to include,
|
||||
separated by space. (default "boot coreboot-app")
|
||||
|
||||
if LINUXBOOT_UROOT_MAIN
|
||||
|
||||
choice
|
||||
prompt "Choose a specific bootloader"
|
||||
default SPECIFIC_BOOTLOADER_SYSTEMBOOT
|
||||
help
|
||||
Specify a bootloader which starts after u-root init. It will be a symlink
|
||||
to /bin/uinit. Default: systemboot
|
||||
|
||||
config SPECIFIC_BOOTLOADER_NONE
|
||||
bool "none"
|
||||
help
|
||||
Leave u-root to decide which bootloaders to load first after init, if
|
||||
any at all. Most likely u-root will start into the defined u-root shell.
|
||||
|
||||
config SPECIFIC_BOOTLOADER_SYSTEMBOOT
|
||||
bool "systemboot"
|
||||
help
|
||||
If systemboot has been used as a bootloader wrapper in the past,
|
||||
enable this option. It will invoke -uinitcmd=systemboot and result in
|
||||
a BIOS/UEFI BDS boot behavior.
|
||||
|
||||
config SPECIFIC_BOOTLOADER_BOOT2
|
||||
bool "boot2"
|
||||
|
||||
config SPECIFIC_BOOTLOADER_PXEBOOT
|
||||
bool "pxeboot"
|
||||
|
||||
config SPECIFIC_BOOTLOADER_STBOOT
|
||||
bool "stboot"
|
||||
|
||||
config SPECIFIC_BOOTLOADER_CUSTOM
|
||||
bool "custom"
|
||||
|
||||
endchoice
|
||||
|
||||
config SPECIFIC_BOOTLOADER_CUSTOM_CMD
|
||||
string "Specify a custom program to start"
|
||||
depends on SPECIFIC_BOOTLOADER_CUSTOM
|
||||
help
|
||||
This option will symlink the input to /bin/unit which will set it as the
|
||||
first boot program after the u-root init. Program flags are not
|
||||
symlinkable.
|
||||
|
||||
config LINUXBOOT_UROOT_UINITCMD
|
||||
string
|
||||
default "" if SPECIFIC_BOOTLOADER_NONE
|
||||
default "systemboot" if SPECIFIC_BOOTLOADER_SYSTEMBOOT
|
||||
default "boot2" if SPECIFIC_BOOTLOADER_BOOT2
|
||||
default "pxeboot" if SPECIFIC_BOOTLOADER_PXEBOOT
|
||||
default "stboot" if SPECIFIC_BOOTLOADER_STBOOT
|
||||
default SPECIFIC_BOOTLOADER_CUSTOM_CMD if SPECIFIC_BOOTLOADER_CUSTOM
|
||||
|
||||
endif #LINUXBOOT_UROOT_MAIN
|
||||
|
||||
endif #LINUXBOOT_UROOT
|
||||
|
||||
endif #LINUXBOOT_BUILD_INITRAMFS
|
||||
|
4
payloads/external/LinuxBoot/Makefile
vendored
4
payloads/external/LinuxBoot/Makefile
vendored
@@ -1,6 +1,7 @@
|
||||
## SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
project_dir=linuxboot
|
||||
kernel_dir=$(project_dir)/kernel
|
||||
|
||||
unexport $(COREBOOT_EXPORTS)
|
||||
|
||||
@@ -51,10 +52,9 @@ endif
|
||||
linuxboot: kernel initramfs_compressed
|
||||
|
||||
clean:
|
||||
rm -rf $(project_dir)/kernel*
|
||||
if [ -d "$(kernel_dir)" ]; then rm -rf $(kernel_dir); fi
|
||||
rm -f $(project_dir)/u-root
|
||||
rm -f $(project_dir)/initramfs*
|
||||
rm -f $(project_dir)/bzImage
|
||||
|
||||
distclean:
|
||||
rm -rf $(project_dir)
|
||||
|
15
payloads/external/LinuxBoot/targets/u-root.mk
vendored
15
payloads/external/LinuxBoot/targets/u-root.mk
vendored
@@ -15,7 +15,6 @@ go_version_minor=$(shell echo $(go_version) | sed -nr 's/^([0-9]+)\.([0-9]+)\.?
|
||||
|
||||
uroot_args+=-build=$(CONFIG_LINUXBOOT_UROOT_FORMAT)
|
||||
uroot_args+=-initcmd $(CONFIG_LINUXBOOT_UROOT_INITCMD)
|
||||
uroot_args+=-uinitcmd=$(CONFIG_LINUXBOOT_UROOT_UINITCMD)
|
||||
uroot_args+=-defaultsh $(CONFIG_LINUXBOOT_UROOT_SHELL)
|
||||
ifneq (CONFIG_LINUXBOOT_UROOT_FILES,)
|
||||
uroot_args+=$(foreach file,$(CONFIG_LINUXBOOT_UROOT_FILES),-files $(PWD)/$(file))
|
||||
@@ -41,11 +40,11 @@ endif
|
||||
get: version
|
||||
if [ -d "$(go_path_dir)/src/$(uroot_package)" ]; then \
|
||||
git -C $(go_path_dir)/src/$(uroot_package) checkout --quiet main; \
|
||||
git -C $(go_path_dir)/src/$(uroot_package) pull || \
|
||||
echo -e "\n<<Pulling u-root package from GitHub failed>>\n"; \
|
||||
GOPATH=$(go_path_dir) go get -d -u -v $(uroot_package) || \
|
||||
echo -e "\n<<u-root package update failed>>\n"; \
|
||||
else \
|
||||
git clone https://${uroot_package} ${go_path_dir}/src/${uroot_package} || \
|
||||
(echo -e "\n<<Failed to clone u-root package. Please check your internet access>>\n" && \
|
||||
GOPATH=$(go_path_dir) go get -d -u -v $(uroot_package) || \
|
||||
(echo -e "\n<<failed to get u-root package. Please check your internet access>>\n" && \
|
||||
exit 1); \
|
||||
fi
|
||||
|
||||
@@ -53,12 +52,10 @@ checkout: get
|
||||
git -C $(go_path_dir)/src/$(uroot_package) checkout --quiet $(CONFIG_LINUXBOOT_UROOT_VERSION)
|
||||
|
||||
build: checkout
|
||||
cd ${go_path_dir}/src/${uroot_package}; \
|
||||
go build -o ${uroot_bin} .
|
||||
GOPATH=$(go_path_dir) go build -o $(uroot_bin) $(uroot_package)
|
||||
|
||||
u-root: build
|
||||
GOARCH=$(ARCH-y) $(uroot_bin) \
|
||||
-uroot-source ${go_path_dir}/src/${uroot_package} \
|
||||
GOARCH=$(ARCH-y) GOPATH=$(go_path_dir) $(uroot_bin) \
|
||||
$(uroot_args) -o $(project_dir)/initramfs_u-root.cpio $(uroot_cmds)
|
||||
|
||||
.PHONY: all u-root build checkout get version
|
||||
|
58
payloads/external/Makefile.inc
vendored
58
payloads/external/Makefile.inc
vendored
@@ -1,7 +1,7 @@
|
||||
## SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
# set up payload config and version files for later inclusion
|
||||
ifeq ($(CONFIG_PAYLOAD_BUILD_SEABIOS),y)
|
||||
ifeq ($(CONFIG_PAYLOAD_SEABIOS),y)
|
||||
PAYLOAD_CONFIG=payloads/external/SeaBIOS/seabios/.config
|
||||
PAYLOAD_VERSION=payloads/external/SeaBIOS/seabios/out/autoversion.h
|
||||
endif
|
||||
@@ -61,8 +61,7 @@ etc/grub.cfg-required := the GRUB runtime configuration file ($(CONFIG_GRUB2_RUN
|
||||
# SeaBIOS
|
||||
|
||||
SEABIOS_CC_OFFSET=$(if $(filter %ccache,$(HOSTCC)),2,1)
|
||||
SEABIOS_TARGET_PATH=payloads/external/SeaBIOS/seabios/out/bios.bin.elf
|
||||
$(SEABIOS_TARGET_PATH): $(DOTCONFIG)
|
||||
payloads/external/SeaBIOS/seabios/out/bios.bin.elf: $(DOTCONFIG)
|
||||
$(MAKE) -C payloads/external/SeaBIOS \
|
||||
HOSTCC="$(HOSTCC)" \
|
||||
CC=$(word $(SEABIOS_CC_OFFSET),$(CC_x86_32)) \
|
||||
@@ -89,14 +88,9 @@ $(SEABIOS_TARGET_PATH): $(DOTCONFIG)
|
||||
CONFIG_CONSOLE_UART_BASE_ADDRESS=$(CONFIG_CONSOLE_UART_BASE_ADDRESS) \
|
||||
CONFIG_SEABIOS_HARDWARE_IRQ=$(CONFIG_SEABIOS_HARDWARE_IRQ)
|
||||
|
||||
payloads/external/SeaBIOS/seabios/out/vgabios.bin: $(SEABIOS_TARGET_PATH)
|
||||
payloads/external/SeaBIOS/seabios/.config: $(SEABIOS_TARGET_PATH)
|
||||
payloads/external/SeaBIOS/seabios/out/autoversion.h: $(SEABIOS_TARGET_PATH)
|
||||
|
||||
cbfs-files-$(CONFIG_SEABIOS_SECONDARY_PAYLOAD) += img/seabios
|
||||
img/seabios-file := $(SEABIOS_TARGET_PATH)
|
||||
img/seabios-type := payload
|
||||
img/seabios-compression := $(CBFS_SECONDARY_PAYLOAD_COMPRESS_FLAG)
|
||||
payloads/external/SeaBIOS/seabios/out/vgabios.bin: payloads/external/SeaBIOS/seabios/out/bios.bin.elf
|
||||
payloads/external/SeaBIOS/seabios/.config: payloads/external/SeaBIOS/seabios/out/bios.bin.elf
|
||||
payloads/external/SeaBIOS/seabios/out/autoversion.h: payloads/external/SeaBIOS/seabios/out/bios.bin.elf
|
||||
|
||||
# add a SeaBIOS bootorder file
|
||||
ifneq ($(strip $(CONFIG_SEABIOS_BOOTORDER_FILE)),)
|
||||
@@ -128,18 +122,6 @@ $(call add_intermediate, seabios_thread_optionroms, $(CBFSTOOL))
|
||||
$(CBFSTOOL) $< add-int -i 2 -n etc/threads
|
||||
endif
|
||||
|
||||
ifeq ($(CONFIG_PAYLOAD_SEAGRUB),y)
|
||||
ifneq ($(CONFIG_SEAGRUB_ALLOW_SEABIOS_BOOTMENU),y)
|
||||
$(call add_intermediate, seabios_bootmenu, $(CBFSTOOL))
|
||||
@printf " SeaBIOS Disable boot menu\n"
|
||||
$(if $(CONFIG_UPDATE_IMAGE),-$(CBFSTOOL) $< remove -n etc/show-boot-menu 2>/dev/null)
|
||||
$(CBFSTOOL) $< add-int -i 0 -n etc/show-boot-menu
|
||||
else
|
||||
$(call add_intermediate, seabios_bootmenu, $(CBFSTOOL))
|
||||
$(if $(CONFIG_UPDATE_IMAGE),-$(CBFSTOOL) $< remove -n etc/show-boot-menu 2>/dev/null)
|
||||
endif
|
||||
endif
|
||||
|
||||
# Depthcharge
|
||||
|
||||
payloads/external/depthcharge/depthcharge/build/depthcharge.elf depthcharge: $(DOTCONFIG) $(CBFSTOOL)
|
||||
@@ -162,8 +144,6 @@ $(obj)/UEFIPAYLOAD.fd tianocore: $(DOTCONFIG)
|
||||
CONFIG_TIANOCORE_TAG_OR_REV=$(CONFIG_TIANOCORE_TAG_OR_REV) \
|
||||
CONFIG_TIANOCORE_UEFIPAYLOAD=$(CONFIG_TIANOCORE_UEFIPAYLOAD) \
|
||||
CONFIG_TIANOCORE_UPSTREAM=$(CONFIG_TIANOCORE_UPSTREAM) \
|
||||
CONFIG_TIANOCORE_CUSTOM=$(CONFIG_TIANOCORE_CUSTOM) \
|
||||
CONFIG_TIANOCORE_CUSTOM_BUILD_PARAMS=$(CONFIG_TIANOCORE_CUSTOM_BUILD_PARAMS) \
|
||||
CONFIG_TIANOCORE_COREBOOTPAYLOAD=$(CONFIG_TIANOCORE_COREBOOTPAYLOAD) \
|
||||
CONFIG_TIANOCORE_DEBUG=$(CONFIG_TIANOCORE_DEBUG) \
|
||||
CONFIG_TIANOCORE_RELEASE=$(CONFIG_TIANOCORE_RELEASE) \
|
||||
@@ -176,11 +156,9 @@ $(obj)/UEFIPAYLOAD.fd tianocore: $(DOTCONFIG)
|
||||
CONFIG_TIANOCORE_HAVE_EFI_SHELL=$(CONFIG_TIANOCORE_HAVE_EFI_SHELL) \
|
||||
CONFIG_TIANOCORE_PRIORITIZE_INTERNAL=$(CONFIG_TIANOCORE_PRIORITIZE_INTERNAL) \
|
||||
CONFIG_TIANOCORE_PS2_SUPPORT=$(CONFIG_TIANOCORE_PS2_SUPPORT) \
|
||||
CONFIG_TIANOCORE_SERIAL_SUPPORT=$(TIANOCORE_SERIAL_SUPPORT) \
|
||||
CONFIG_TIANOCORE_SD_MMC_TIMEOUT=$(CONFIG_TIANOCORE_SD_MMC_TIMEOUT) \
|
||||
CONFIG_TIANOCORE_USE_8254_TIMER=$(CONFIG_TIANOCORE_USE_8254_TIMER) \
|
||||
CONFIG_ECAM_MMCONF_BASE_ADDRESS=$(CONFIG_ECAM_MMCONF_BASE_ADDRESS) \
|
||||
CONFIG_ECAM_MMCONF_LENGTH=$(CONFIG_ECAM_MMCONF_LENGTH) \
|
||||
GCC_CC_x86_32=$(GCC_CC_x86_32) \
|
||||
GCC_CC_x86_64=$(GCC_CC_x86_64) \
|
||||
GCC_CC_arm=$(GCC_CC_arm) \
|
||||
@@ -211,13 +189,6 @@ payloads/external/FILO/filo/build/version.h: filo
|
||||
|
||||
# Grub
|
||||
|
||||
GRUB_TARGET_PATH=payloads/external/GRUB2/grub2/build/default_payload.elf
|
||||
|
||||
cbfs-files-$(CONFIG_GRUB2_SECONDARY_PAYLOAD) += img/grub2
|
||||
img/grub2-file := $(GRUB_TARGET_PATH)
|
||||
img/grub2-type := payload
|
||||
img/grub2-compression := $(CBFS_SECONDARY_PAYLOAD_COMPRESS_FLAG)
|
||||
|
||||
grub2: $(obj)/config.h
|
||||
$(MAKE) -C payloads/external/GRUB2 \
|
||||
HOSTCC="$(HOSTCC)" \
|
||||
@@ -230,7 +201,7 @@ grub2: $(obj)/config.h
|
||||
CONFIG_GRUB2_REVISION_ID=$(CONFIG_GRUB2_REVISION_ID) \
|
||||
CONFIG_GRUB2_EXTRA_MODULES=$(CONFIG_GRUB2_EXTRA_MODULES)
|
||||
|
||||
$(GRUB_TARGET_PATH): grub2
|
||||
payloads/external/GRUB2/grub2/build/default_payload.elf: grub2
|
||||
|
||||
# U-Boot
|
||||
|
||||
@@ -345,7 +316,6 @@ linuxboot:
|
||||
CONFIG_LINUXBOOT_UROOT_VERSION=$(CONFIG_LINUXBOOT_UROOT_VERSION) \
|
||||
CONFIG_LINUXBOOT_UROOT_FORMAT=$(CONFIG_LINUXBOOT_UROOT_FORMAT) \
|
||||
CONFIG_LINUXBOOT_UROOT_INITCMD=$(CONFIG_LINUXBOOT_UROOT_INITCMD) \
|
||||
CONFIG_LINUXBOOT_UROOT_UINITCMD=$(CONFIG_LINUXBOOT_UROOT_UINITCMD)\
|
||||
CONFIG_LINUXBOOT_UROOT_SHELL=$(CONFIG_LINUXBOOT_UROOT_SHELL) \
|
||||
CONFIG_LINUXBOOT_UROOT_COMMANDS=$(CONFIG_LINUXBOOT_UROOT_COMMANDS) \
|
||||
CONFIG_LINUXBOOT_UROOT_FILES=$(CONFIG_LINUXBOOT_UROOT_FILES) \
|
||||
@@ -377,19 +347,3 @@ payloads/external/skiboot/build/skiboot.elf:
|
||||
$(MAKE) -C payloads/external/skiboot all \
|
||||
CONFIG_SKIBOOT_GIT_REPO=$(CONFIG_SKIBOOT_GIT_REPO) \
|
||||
CONFIG_SKIBOOT_REVISION=$(CONFIG_SKIBOOT_REVISION)
|
||||
# COREDOOM
|
||||
|
||||
payloads/external/coreDOOM/coredoom/doomgeneric/coredoom.elf coredoom:
|
||||
$(MAKE) -C payloads/external/coreDOOM
|
||||
|
||||
cbfs-files-$(CONFIG_COREDOOM_SECONDARY_PAYLOAD) += img/coreDOOM
|
||||
img/coreDOOM-file := payloads/external/coreDOOM/coredoom/doomgeneric/coredoom.elf
|
||||
img/coreDOOM-type := payload
|
||||
img/coreDOOM-compression := $(CBFS_SECONDARY_PAYLOAD_COMPRESS_FLAG)
|
||||
# WAD file
|
||||
ifneq ($(strip $(CONFIG_COREDOOM_WAD_FILE)),)
|
||||
cbfs-files-y += doom.wad
|
||||
doom.wad-file := $(strip $(CONFIG_COREDOOM_WAD_FILE))
|
||||
doom.wad-type := raw
|
||||
doom.wad-compression := $(CBFS_SECONDARY_PAYLOAD_COMPRESS_FLAG)
|
||||
endif
|
||||
|
14
payloads/external/SeaBIOS/Kconfig
vendored
14
payloads/external/SeaBIOS/Kconfig
vendored
@@ -1,15 +1,5 @@
|
||||
config PAYLOAD_BUILD_SEABIOS
|
||||
bool
|
||||
|
||||
if PAYLOAD_SEABIOS
|
||||
|
||||
config PAYLOAD_FILE
|
||||
default "payloads/external/SeaBIOS/seabios/out/bios.bin.elf"
|
||||
|
||||
endif
|
||||
|
||||
if PAYLOAD_BUILD_SEABIOS
|
||||
|
||||
choice
|
||||
prompt "SeaBIOS version"
|
||||
default SEABIOS_STABLE
|
||||
@@ -74,7 +64,6 @@ config SEABIOS_HARDWARE_IRQ
|
||||
config SEABIOS_VGA_COREBOOT
|
||||
prompt "Include generated option rom that implements legacy VGA BIOS compatibility"
|
||||
default y if !VENDOR_EMULATION
|
||||
default y if COREDOOM_SECONDARY_PAYLOAD
|
||||
depends on !VGA_ROM_RUN && (VGA_TEXT_FRAMEBUFFER || LINEAR_FRAMEBUFFER)
|
||||
bool
|
||||
help
|
||||
@@ -125,6 +114,9 @@ config SEABIOS_SERCON_PORT_ADDR
|
||||
|
||||
By default primary console UART defined by TTYS0_BASE is used.
|
||||
|
||||
config PAYLOAD_FILE
|
||||
default "payloads/external/SeaBIOS/seabios/out/bios.bin.elf"
|
||||
|
||||
config PAYLOAD_VGABIOS_FILE
|
||||
string
|
||||
depends on SEABIOS_VGA_COREBOOT
|
||||
|
1
payloads/external/SeaBIOS/Kconfig.name
vendored
1
payloads/external/SeaBIOS/Kconfig.name
vendored
@@ -1,7 +1,6 @@
|
||||
config PAYLOAD_SEABIOS
|
||||
bool "SeaBIOS"
|
||||
depends on ARCH_X86
|
||||
select PAYLOAD_BUILD_SEABIOS
|
||||
help
|
||||
Select this option if you want to build a coreboot image
|
||||
with a SeaBIOS payload. If you don't know what this is
|
||||
|
25
payloads/external/coreDOOM/Kconfig.secondary
vendored
25
payloads/external/coreDOOM/Kconfig.secondary
vendored
@@ -1,25 +0,0 @@
|
||||
if COREDOOM_SECONDARY_PAYLOAD
|
||||
|
||||
config COREDOOM_WAD_FILE
|
||||
string "DOOM WAD file"
|
||||
depends on COREDOOM_SECONDARY_PAYLOAD
|
||||
default "doom.wad"
|
||||
help
|
||||
Add a WAD file to be loaded by coreDOOM.
|
||||
|
||||
A WAD file contains all the game data for the Doom-engine, and
|
||||
is required to play the game.
|
||||
|
||||
A list of the WAD files included in the official games can be
|
||||
found here: https://doomwiki.org/wiki/IWAD
|
||||
These WADs can be extracted from copies of the game that you
|
||||
own, and the shareware WADs may be freely downloaded from the
|
||||
internet.
|
||||
|
||||
For a completely free (as in freedom) experience, the Freedoom
|
||||
project (https://freedoom.github.io) provides original game
|
||||
content under the BSD license. Other WADs not mentioned here are
|
||||
also available and may be found from various sources such as
|
||||
the internet and copies of other games using the Doom engine.
|
||||
|
||||
endif
|
34
payloads/external/coreDOOM/Makefile
vendored
34
payloads/external/coreDOOM/Makefile
vendored
@@ -1,34 +0,0 @@
|
||||
## SPDX-License-Identifier: GPL-2.0-only
|
||||
project_git_repo=https://github.com/nic3-14159/coreDOOM.git
|
||||
project_dir=coredoom
|
||||
|
||||
unexport KCONFIG_AUTOHEADER
|
||||
unexport KCONFIG_AUTOCONFIG
|
||||
unexport KCONFIG_DEPENDENCIES
|
||||
unexport KCONFIG_SPLITCONFIG
|
||||
unexport KCONFIG_TRISTATE
|
||||
unexport KCONFIG_NEGATIVES
|
||||
|
||||
all: coredoom
|
||||
|
||||
checkout:
|
||||
test -d coredoom || \
|
||||
git clone $(project_git_repo) $(project_dir)
|
||||
cd $(project_dir) && \
|
||||
git checkout libpayload_port
|
||||
|
||||
coredoom: libpayload
|
||||
$(MAKE) -C $(project_dir)/doomgeneric
|
||||
|
||||
libpayload: checkout
|
||||
cp libpayload-config ../../libpayload/.config && \
|
||||
cd ../../libpayload && $(MAKE) olddefconfig && $(MAKE) && \
|
||||
$(MAKE) DESTDIR=../external/coreDOOM/coredoom/doomgeneric install
|
||||
|
||||
clean:
|
||||
test -d coredoom && $(MAKE) -C coredoom/doomgeneric clean || exit 0
|
||||
|
||||
distclean:
|
||||
rm -rf coredoom
|
||||
|
||||
.PHONY: checkout coredoom clean distclean
|
13
payloads/external/coreDOOM/libpayload-config
vendored
13
payloads/external/coreDOOM/libpayload-config
vendored
@@ -1,13 +0,0 @@
|
||||
# CONFIG_LP_MULTIBOOT is not set
|
||||
CONFIG_LP_HEAP_SIZE=67108864
|
||||
CONFIG_LP_STACK_SIZE=16384
|
||||
CONFIG_LP_BASE_ADDRESS=0x00100000
|
||||
# CONFIG_LP_CURSES is not set
|
||||
CONFIG_LP_SERIAL_IOBASE=0x3f8
|
||||
CONFIG_LP_COREBOOT_VIDEO_CONSOLE=y
|
||||
# CONFIG_LP_PCI is not set
|
||||
# CONFIG_LP_NVRAM is not set
|
||||
CONFIG_LP_TIMER_GENERIC_REG=0x0
|
||||
CONFIG_LP_TIMER_GENERIC_HIGH_REG=0x0
|
||||
# CONFIG_LP_STORAGE is not set
|
||||
# CONFIG_LP_USB_MSC is not set
|
27
payloads/external/tianocore/Kconfig
vendored
27
payloads/external/tianocore/Kconfig
vendored
@@ -79,7 +79,7 @@ config TIANOCORE_RELEASE
|
||||
|
||||
endchoice
|
||||
|
||||
if TIANOCORE_UEFIPAYLOAD || TIANOCORE_CUSTOM || TIANOCORE_UPSTREAM
|
||||
if TIANOCORE_UEFIPAYLOAD
|
||||
|
||||
config TIANOCORE_ABOVE_4G_MEMORY
|
||||
bool "Enable above 4G memory"
|
||||
@@ -169,19 +169,11 @@ config TIANOCORE_PS2_SUPPORT
|
||||
Include support for PS/2 keyboards
|
||||
|
||||
config TIANOCORE_SD_MMC_TIMEOUT
|
||||
int "Timeout in ms for initializing SD and eMMC devices"
|
||||
default 10
|
||||
int "Timeout in μs for initializing SD Card reader"
|
||||
default 1000
|
||||
help
|
||||
The amount of time allowed to initialize the SD Card reader and/or eMMC drive.
|
||||
Most only require 10ms, but certain readers can take 1s.
|
||||
|
||||
config TIANOCORE_SERIAL_SUPPORT
|
||||
bool "Support serial output"
|
||||
default y if TIANOCORE_DEBUG
|
||||
default n
|
||||
help
|
||||
Enable serial port output in edk2. Serial output limits the performance of edk2's
|
||||
FrontPage.
|
||||
Most only require 1000μs, but certain readers can take 1000000μs.
|
||||
|
||||
endif
|
||||
|
||||
@@ -194,15 +186,4 @@ config TIANOCORE_USE_8254_TIMER
|
||||
|
||||
endif
|
||||
|
||||
if TIANOCORE_CUSTOM
|
||||
|
||||
config TIANOCORE_CUSTOM_BUILD_PARAMS
|
||||
string "TianoCore additional custom build parameters"
|
||||
help
|
||||
Custom TianoCore forks may have different sets of parameters passed
|
||||
to build command. You may specify additional parameters to the custom
|
||||
TianoCore build
|
||||
|
||||
endif
|
||||
|
||||
endif
|
||||
|
44
payloads/external/tianocore/Makefile
vendored
44
payloads/external/tianocore/Makefile
vendored
@@ -36,22 +36,10 @@ endif
|
||||
ifeq ($(CONFIG_TIANOCORE_RELEASE),y)
|
||||
BUILD_STR += -b RELEASE
|
||||
endif
|
||||
# DISABLE_SERIAL_TERMINAL = FALSE
|
||||
ifneq ($(CONFIG_TIANOCORE_SERIAL_SUPPORT),y)
|
||||
BUILD_STR += -D DISABLE_SERIAL_TERMINAL=TRUE
|
||||
endif
|
||||
# FOLLOW_BGRT_SPEC = FALSE
|
||||
ifeq ($(CONFIG_TIANOCORE_FOLLOW_BGRT_SPEC),y)
|
||||
BUILD_STR += -D FOLLOW_BGRT_SPEC=TRUE
|
||||
endif
|
||||
# PCIE_BASE_ADDRESS = 0
|
||||
ifneq ($(CONFIG_ECAM_MMCONF_LENGTH),)
|
||||
BUILD_STR += --pcd gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress=$(CONFIG_ECAM_MMCONF_BASE_ADDRESS)
|
||||
endif
|
||||
# PCIE_BASE_LENGTH = 0
|
||||
ifneq ($(CONFIG_ECAM_MMCONF_LENGTH),)
|
||||
BUILD_STR += --pcd gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize=$(CONFIG_ECAM_MMCONF_LENGTH)
|
||||
endif
|
||||
# PRIORITIZE_INTERNAL = FALSE
|
||||
ifeq ($(CONFIG_TIANOCORE_PRIORITIZE_INTERNAL),y)
|
||||
BUILD_STR += -D PRIORITIZE_INTERNAL=TRUE
|
||||
@@ -78,21 +66,12 @@ BUILD_STR += -D USE_CBMEM_FOR_CONSOLE=TRUE
|
||||
endif
|
||||
# SD_MMC_TIMEOUT = 1000000
|
||||
ifneq ($(CONFIG_TIANOCORE_SD_MMC_TIMEOUT),)
|
||||
BUILD_STR += -D SD_MMC_TIMEOUT=$(call int-multiply, $(CONFIG_TIANOCORE_SD_MMC_TIMEOUT) 1000)
|
||||
BUILD_STR += -D SD_MMC_TIMEOUT=$(CONFIG_TIANOCORE_SD_MMC_TIMEOUT)
|
||||
endif
|
||||
#
|
||||
# EDKII has the below PCDs that are revalant to coreboot:
|
||||
#
|
||||
# Allows EDKII to use the full framebuffer
|
||||
BUILD_STR += --pcd gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow=0
|
||||
BUILD_STR += --pcd gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn=0
|
||||
BUILD_STR += --pcd gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow=0
|
||||
BUILD_STR += --pcd gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutColumn=0
|
||||
#
|
||||
# The below are legacy options only available in CorebootPayloadPkg:
|
||||
#
|
||||
# PCIE_BASE = 0
|
||||
ifeq ($(CONFIG_TIANOCORE_COREBOOTPAYLOAD),y)
|
||||
ifneq ($(CONFIG_ECAM_MMCONF_BASE_ADDRESS),)
|
||||
BUILD_STR += -D PCIE_BASE=$(CONFIG_ECAM_MMCONF_BASE_ADDRESS)
|
||||
endif
|
||||
@@ -100,16 +79,9 @@ endif
|
||||
ifeq ($(CONFIG_TIANOCORE_USE_8254_TIMER),y)
|
||||
BUILD_STR += -D USE_HPET_TIMER=TRUE
|
||||
endif
|
||||
endif # CONFIG_TIANOCORE_COREBOOTPAYLOAD
|
||||
|
||||
bootloader = $(word 8,$(subst /, ,$(BUILD_STR)))
|
||||
|
||||
ifeq ($(CONFIG_TIANOCORE_CUSTOM),y)
|
||||
ifneq ($(CONFIG_TIANOCORE_CUSTOM_BUILD_PARAMS),)
|
||||
BUILD_STR += $(CONFIG_TIANOCORE_CUSTOM_BUILD_PARAMS)
|
||||
endif
|
||||
endif
|
||||
|
||||
all: clean build
|
||||
|
||||
$(project_dir):
|
||||
@@ -128,7 +100,7 @@ update: $(project_dir)
|
||||
echo " $(CONFIG_TIANOCORE_TAG_OR_REV) is not a valid git reference"; \
|
||||
exit 1; \
|
||||
fi; \
|
||||
if git status --ignore-submodules=dirty | grep -q clean; then \
|
||||
if git status --ignore-submodules=dirty | grep -qv clean; then \
|
||||
echo " Checking out $(project_name) revision $(CONFIG_TIANOCORE_TAG_OR_REV)"; \
|
||||
git checkout --detach $(CONFIG_TIANOCORE_TAG_OR_REV) -f; \
|
||||
else \
|
||||
@@ -148,18 +120,8 @@ checktools:
|
||||
( echo " Not found."; echo "Error: Please install nasm."; exit 1 )
|
||||
|
||||
build: update checktools
|
||||
echo " ##### $(project_name) Build Summary #####"
|
||||
echo " Repository: $(CONFIG_TIANOCORE_REPOSITORY)"
|
||||
echo " Branch: $(CONFIG_TIANOCORE_TAG_OR_REV)"
|
||||
echo " $(BUILD_STR)" | \
|
||||
sed 's/-/\n /g' | sort | sed \
|
||||
-e 's/a /Architecture: /g' \
|
||||
-e 's/b /Release: /g' \
|
||||
-e 's/D /Option: /g' \
|
||||
-e 's/p /Payload: /g' \
|
||||
-e 's/q /Build: Quiet/' \
|
||||
-e 's/t /Toolchain: /'
|
||||
unset CC; $(MAKE) -C $(project_dir)/BaseTools 2>&1
|
||||
echo " build $(project_name) $(CONFIG_TIANOCORE_TAG_OR_REV)"
|
||||
if [ -n "$(CONFIG_TIANOCORE_BOOTSPLASH_FILE)" ]; then \
|
||||
echo " Copying custom bootsplash image"; \
|
||||
case "$(CONFIG_TIANOCORE_BOOTSPLASH_FILE)" in \
|
||||
|
0
payloads/external/tianocore/tools_def.txt
vendored
Normal file → Executable file
0
payloads/external/tianocore/tools_def.txt
vendored
Normal file → Executable file
@@ -56,10 +56,10 @@ config DEVELOPER
|
||||
libpayload developers.
|
||||
|
||||
config CHROMEOS
|
||||
bool "ChromeOS Options"
|
||||
bool "Chrome OS Options"
|
||||
default n
|
||||
help
|
||||
Select configuration defaults appropriate for ChromeOS boards.
|
||||
Select configuration defaults appropriate for Chrome OS boards.
|
||||
|
||||
choice
|
||||
prompt "Compiler to use"
|
||||
@@ -404,19 +404,8 @@ menu "Drivers"
|
||||
|
||||
config PCI
|
||||
bool "Support for PCI devices"
|
||||
default y if ARCH_X86
|
||||
default n
|
||||
|
||||
config PCI_IO_OPS
|
||||
bool "Support for PCI devices with port IO"
|
||||
depends on PCI && IO_ADDRESS_SPACE
|
||||
default y if ARCH_X86
|
||||
default n
|
||||
|
||||
config PCIE_MEDIATEK
|
||||
bool "Support for PCIe devices on MediaTek platforms"
|
||||
depends on PCI && !PCI_IO_OPS
|
||||
default n
|
||||
depends on ARCH_X86 # for now
|
||||
default y
|
||||
|
||||
config NVRAM
|
||||
bool "Support for reading/writing NVRAM bytes"
|
||||
|
@@ -28,13 +28,6 @@
|
||||
## SUCH DAMAGE.
|
||||
##
|
||||
|
||||
ifneq ($(NOCOMPILE),1)
|
||||
GIT:=$(shell git -C "$(top)" rev-parse --git-dir 1>/dev/null 2>&1 \
|
||||
&& command -v git)
|
||||
else
|
||||
GIT:=
|
||||
endif
|
||||
|
||||
export KERNELVERSION := 0.2.0
|
||||
|
||||
ARCHDIR-$(CONFIG_LP_ARCH_ARM) := arm
|
||||
@@ -67,8 +60,7 @@ subdirs-$(CONFIG_LP_LZ4) += liblz4
|
||||
subdirs-$(CONFIG_LP_VBOOT_LIB) += vboot
|
||||
|
||||
INCLUDES := -Iinclude -Iinclude/$(ARCHDIR-y) -I$(obj)
|
||||
INCLUDES += -include include/kconfig.h
|
||||
INCLUDES += -include $(coreboottop)/src/commonlib/bsd/include/commonlib/bsd/compiler.h
|
||||
INCLUDES += -include include/kconfig.h -include include/compiler.h
|
||||
INCLUDES += -I$(coreboottop)/src/commonlib/bsd/include
|
||||
INCLUDES += -I$(VBOOT_SOURCE)/firmware/include
|
||||
|
||||
@@ -83,10 +75,6 @@ ifeq ($(CONFIG_LP_LTO),y)
|
||||
CFLAGS += -flto
|
||||
endif
|
||||
|
||||
# Some of the commonlib cbfs headers include vboot headers, so initialize the
|
||||
# submodule in case we are building a payload outside the main coreboot build
|
||||
forgetthis:=$(if $(GIT),$(shell git submodule update --init ../../3rdparty/vboot $(quiet_errors)))
|
||||
|
||||
$(obj)/libpayload.config: $(DOTCONFIG)
|
||||
cp $< $@
|
||||
|
||||
|
@@ -36,7 +36,7 @@ ARCH ?=
|
||||
OBJS ?=
|
||||
CCACHE ?=
|
||||
|
||||
CFLAGS = $(CFLAGS_$(ARCH))
|
||||
CFLAGS = $(GCC_CFLAGS_$(ARCH))
|
||||
CFLAGS += -Os -ffreestanding
|
||||
CFLAGS += -Wall -Wextra -Wmissing-prototypes -Wvla -Werror
|
||||
|
||||
@@ -56,8 +56,6 @@ export V
|
||||
|
||||
ifeq ($(filter %clean,$(MAKECMDGOALS)),)
|
||||
|
||||
-include $(LIBPAYLOAD_DOTCONFIG)
|
||||
|
||||
xcompile := $(obj)/xcompile
|
||||
xcompile_script := $(LIBPAYLOAD_SRC)/../../util/xcompile/xcompile
|
||||
|
||||
@@ -124,26 +122,26 @@ LIBPAYLOAD_OPTS += DOTCONFIG="$(LIBPAYLOAD_DOTCONFIG)"
|
||||
LIBPAYLOAD_OPTS += CONFIG_=CONFIG_LP_
|
||||
LIBPAYLOAD_OPTS += $(if $(CCACHE),CONFIG_LP_CCACHE=y)
|
||||
|
||||
ifneq ($(LIBPAYLOAD_DEFCONFIG),)
|
||||
$(LIBPAYLOAD_DOTCONFIG): $(LIBPAYLOAD_DEFCONFIG)
|
||||
defconfig: lp-defconfig
|
||||
lp-defconfig: $(LIBPAYLOAD_DOTCONFIG)
|
||||
$(LIBPAYLOAD_DOTCONFIG): $(LIBPAYLOAD_DEFCONFIG) | $(PAYLOAD_DEPS)
|
||||
$(MAKE) -C $(LIBPAYLOAD_SRC) $(LIBPAYLOAD_OPTS) \
|
||||
KBUILD_DEFCONFIG=$(LIBPAYLOAD_DEFCONFIG) defconfig
|
||||
endif
|
||||
|
||||
$(LIBPAYLOAD_CONFIG_H): $(LIBPAYLOAD_DOTCONFIG)
|
||||
$(MAKE) -C $(LIBPAYLOAD_SRC) $(LIBPAYLOAD_OPTS) $(LIBPAYLOAD_CONFIG_H)
|
||||
|
||||
force-relay:
|
||||
oldconfig: lp-oldconfig
|
||||
lp-oldconfig:
|
||||
[ ! -f $(LIBPAYLOAD_DOTCONFIG) ] || \
|
||||
$(MAKE) -C $(LIBPAYLOAD_SRC) $(LIBPAYLOAD_OPTS) oldconfig
|
||||
|
||||
lp-%: force-relay
|
||||
$(MAKE) -C $(LIBPAYLOAD_SRC) $(LIBPAYLOAD_OPTS) $*
|
||||
|
||||
$(LIBPAYLOAD): force-relay | $(LIBPAYLOAD_CONFIG_H)
|
||||
$(LIBPAYLOAD): lp-defconfig | $(LIBPAYLOAD_CONFIG_H)
|
||||
$(MAKE) -C $(LIBPAYLOAD_SRC) $(LIBPAYLOAD_OPTS)
|
||||
|
||||
$(shell mkdir -p $(sort $(dir $(OBJS))))
|
||||
|
||||
.PHONY: force-relay
|
||||
.PHONY: oldconfig lp-oldconfig defconfig lp-defconfig
|
||||
|
||||
else # %clean,$(MAKECMDGOALS)
|
||||
|
||||
|
@@ -1,6 +1,6 @@
|
||||
/*
|
||||
* Copyright (C) 1991,1992,1993,1997,1998,2003, 2005 Free Software Foundation, Inc.
|
||||
* Copyright (c) 2011 The ChromiumOS Authors.
|
||||
* Copyright (c) 2011 The Chromium OS Authors.
|
||||
*
|
||||
* This program is free software; you can redistribute it and/or
|
||||
* modify it under the terms of the GNU General Public License as
|
||||
|
@@ -168,11 +168,9 @@ if [ $_LIBDIR = $_OBJ ]; then
|
||||
_CFLAGS="$_CFLAGS -I$BASE/../curses"
|
||||
fi
|
||||
|
||||
_CFLAGS="$_CFLAGS -include $BASE/../../../src/commonlib/bsd/include/commonlib/bsd/compiler.h"
|
||||
_CFLAGS="$_CFLAGS -I$BASE/../../../src/commonlib/bsd/include"
|
||||
_CFLAGS="$_CFLAGS -I$BASE/../../../3rdparty/vboot/firmware/include"
|
||||
else
|
||||
_CFLAGS="$_CFLAGS -include $BASE/../include/commonlib/bsd/compiler.h"
|
||||
_CFLAGS="$_CFLAGS -I$_VBOOTINCDIR"
|
||||
fi
|
||||
|
||||
@@ -181,7 +179,7 @@ fi
|
||||
trygccoption -fno-stack-protector
|
||||
[ $? -eq 0 ] && _CFLAGS="$_CFLAGS -fno-stack-protector"
|
||||
|
||||
_CFLAGS="$_CFLAGS -include $BASE/../include/kconfig.h"
|
||||
_CFLAGS="$_CFLAGS -include $BASE/../include/kconfig.h -include $BASE/../include/compiler.h"
|
||||
_CFLAGS="$_CFLAGS -I`$DEFAULT_CC $_ARCHEXTRA -print-search-dirs | head -n 1 | cut -d' ' -f2`include"
|
||||
|
||||
if [ "$CONFIG_LP_VBOOT_LIB" = y ]; then
|
||||
|
@@ -28,15 +28,7 @@
|
||||
## SUCH DAMAGE.
|
||||
##
|
||||
|
||||
libc-$(CONFIG_LP_PCI) += pci_ops.c
|
||||
|
||||
ifeq ($(CONFIG_LP_PCI_IO_OPS),y)
|
||||
libc-$(CONFIG_LP_PCI) += pci_io_ops.c
|
||||
else
|
||||
libc-$(CONFIG_LP_PCI) += pci_map_bus_ops.c
|
||||
endif
|
||||
|
||||
libc-$(CONFIG_LP_PCIE_MEDIATEK) += pcie_mediatek.c
|
||||
libc-$(CONFIG_LP_PCI) += pci.c
|
||||
|
||||
libc-$(CONFIG_LP_SPEAKER) += speaker.c
|
||||
|
||||
|
@@ -30,6 +30,42 @@
|
||||
#include <libpayload.h>
|
||||
#include <pci.h>
|
||||
|
||||
u8 pci_read_config8(pcidev_t device, u16 reg)
|
||||
{
|
||||
outl(device | (reg & ~3), 0xCF8);
|
||||
return inb(0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
u16 pci_read_config16(pcidev_t device, u16 reg)
|
||||
{
|
||||
outl(device | (reg & ~3), 0xCF8);
|
||||
return inw(0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
u32 pci_read_config32(pcidev_t device, u16 reg)
|
||||
{
|
||||
outl(device | (reg & ~3), 0xCF8);
|
||||
return inl(0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
void pci_write_config8(pcidev_t device, u16 reg, u8 val)
|
||||
{
|
||||
outl(device | (reg & ~3), 0xCF8);
|
||||
outb(val, 0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
void pci_write_config16(pcidev_t device, u16 reg, u16 val)
|
||||
{
|
||||
outl(device | (reg & ~3), 0xCF8);
|
||||
outw(val, 0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
void pci_write_config32(pcidev_t device, u16 reg, u32 val)
|
||||
{
|
||||
outl(device | (reg & ~3), 0xCF8);
|
||||
outl(val, 0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
static int find_on_bus(int bus, unsigned short vid, unsigned short did,
|
||||
pcidev_t * dev)
|
||||
{
|
@@ -1,67 +0,0 @@
|
||||
/*
|
||||
*
|
||||
* Copyright (C) 2008 Advanced Micro Devices, Inc.
|
||||
* Copyright (C) 2008 coresystems GmbH
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
* are met:
|
||||
* 1. Redistributions of source code must retain the above copyright
|
||||
* notice, this list of conditions and the following disclaimer.
|
||||
* 2. Redistributions in binary form must reproduce the above copyright
|
||||
* notice, this list of conditions and the following disclaimer in the
|
||||
* documentation and/or other materials provided with the distribution.
|
||||
* 3. The name of the author may not be used to endorse or promote products
|
||||
* derived from this software without specific prior written permission.
|
||||
*
|
||||
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
|
||||
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
|
||||
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
||||
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
||||
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
||||
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
||||
* SUCH DAMAGE.
|
||||
*/
|
||||
|
||||
#include <libpayload.h>
|
||||
#include <pci.h>
|
||||
|
||||
u8 pci_read_config8(pcidev_t dev, u16 reg)
|
||||
{
|
||||
outl(dev | (reg & ~3), 0xCF8);
|
||||
return inb(0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
u16 pci_read_config16(pcidev_t dev, u16 reg)
|
||||
{
|
||||
outl(dev | (reg & ~3), 0xCF8);
|
||||
return inw(0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
u32 pci_read_config32(pcidev_t dev, u16 reg)
|
||||
{
|
||||
outl(dev | (reg & ~3), 0xCF8);
|
||||
return inl(0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
void pci_write_config8(pcidev_t dev, u16 reg, u8 val)
|
||||
{
|
||||
outl(dev | (reg & ~3), 0xCF8);
|
||||
outb(val, 0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
void pci_write_config16(pcidev_t dev, u16 reg, u16 val)
|
||||
{
|
||||
outl(dev | (reg & ~3), 0xCF8);
|
||||
outw(val, 0xCFC + (reg & 3));
|
||||
}
|
||||
|
||||
void pci_write_config32(pcidev_t dev, u16 reg, u32 val)
|
||||
{
|
||||
outl(dev | (reg & ~3), 0xCF8);
|
||||
outl(val, 0xCFC + (reg & 3));
|
||||
}
|
@@ -1,46 +0,0 @@
|
||||
/* SPDX-License-Identifier: GPL-2.0-only */
|
||||
|
||||
#include <libpayload.h>
|
||||
#include <pci.h>
|
||||
|
||||
u8 pci_read_config8(pcidev_t dev, u16 reg)
|
||||
{
|
||||
uintptr_t cfg_base = pci_map_bus(dev);
|
||||
|
||||
return read8((void *)(cfg_base | reg));
|
||||
}
|
||||
|
||||
u16 pci_read_config16(pcidev_t dev, u16 reg)
|
||||
{
|
||||
uintptr_t cfg_base = pci_map_bus(dev);
|
||||
|
||||
return read16((void *)(cfg_base | (reg & ~1)));
|
||||
}
|
||||
|
||||
u32 pci_read_config32(pcidev_t dev, u16 reg)
|
||||
{
|
||||
uintptr_t cfg_base = pci_map_bus(dev);
|
||||
|
||||
return read32((void *)(cfg_base | (reg & ~3)));
|
||||
}
|
||||
|
||||
void pci_write_config8(pcidev_t dev, u16 reg, u8 val)
|
||||
{
|
||||
uintptr_t cfg_base = pci_map_bus(dev);
|
||||
|
||||
write8((void *)(cfg_base | reg), val);
|
||||
}
|
||||
|
||||
void pci_write_config16(pcidev_t dev, u16 reg, u16 val)
|
||||
{
|
||||
uintptr_t cfg_base = pci_map_bus(dev);
|
||||
|
||||
write16((void *)(cfg_base | (reg & ~1)), val);
|
||||
}
|
||||
|
||||
void pci_write_config32(pcidev_t dev, u16 reg, u32 val)
|
||||
{
|
||||
uintptr_t cfg_base = pci_map_bus(dev);
|
||||
|
||||
write32((void *)(cfg_base | (reg & ~3)), val);
|
||||
}
|
@@ -1,20 +0,0 @@
|
||||
/* SPDX-License-Identifier: GPL-2.0-only */
|
||||
|
||||
#include <libpayload.h>
|
||||
#include <pci.h>
|
||||
|
||||
#define PCIE_CFGNUM_REG 0x140
|
||||
#define PCIE_CFG_DEVFN(devfn) ((devfn) & GENMASK(7, 0))
|
||||
#define PCIE_CFG_BUS(bus) (((bus) << 8) & GENMASK(15, 8))
|
||||
#define PCIE_CFG_OFFSET_ADDR 0x1000
|
||||
#define PCIE_CFG_HEADER(bus, devfn) \
|
||||
(PCIE_CFG_BUS(bus) | PCIE_CFG_DEVFN(devfn))
|
||||
|
||||
uintptr_t pci_map_bus(pcidev_t dev)
|
||||
{
|
||||
u32 devfn = (PCI_SLOT(dev) << 3) | PCI_FUNC(dev);
|
||||
u32 val = PCIE_CFG_HEADER(PCI_BUS(dev), devfn);
|
||||
write32((void *)(lib_sysinfo.pcie_ctrl_base + PCIE_CFGNUM_REG), val);
|
||||
|
||||
return lib_sysinfo.pcie_ctrl_base + PCIE_CFG_OFFSET_ADDR;
|
||||
}
|
@@ -1,5 +1,5 @@
|
||||
/*
|
||||
* Copyright (c) 2014 ChromiumOS authors
|
||||
* Copyright (c) 2014 Chromium OS authors
|
||||
*/
|
||||
|
||||
#include <libpayload.h>
|
||||
|
@@ -147,7 +147,7 @@ static void nvme_detach_device(struct storage_dev *dev)
|
||||
if (delete_admin_queues(nvme))
|
||||
printf("NVME ERROR: Failed to delete admin queues\n");
|
||||
|
||||
write32(nvme->config + 0x14, 0);
|
||||
write32(nvme->config + 0x1c, 0);
|
||||
|
||||
int status, timeout = (read64(nvme->config) >> 24 & 0xff) * 500;
|
||||
do {
|
||||
@@ -321,7 +321,7 @@ static void nvme_init(pcidev_t dev)
|
||||
|
||||
void *pci_bar0 = phys_to_virt(pci_read_config32(dev, 0x10) & ~0x3ff);
|
||||
|
||||
if (!(read64(pci_bar0) >> 37 & 0x01)) {
|
||||
if (!(((read64(pci_bar0) >> 37) & 0xff) == 0x01)) {
|
||||
printf("NVMe ERROR: PCIe device does not support the NVMe command set\n");
|
||||
return;
|
||||
}
|
||||
@@ -341,39 +341,39 @@ static void nvme_init(pcidev_t dev)
|
||||
|
||||
if (!nvme->prp_list) {
|
||||
printf("NVMe ERROR: Failed to allocate buffer for PRP list\n");
|
||||
goto _free_abort;
|
||||
goto abort;
|
||||
}
|
||||
|
||||
const uint32_t cc = NVME_CC_EN | NVME_CC_CSS | NVME_CC_MPS | NVME_CC_AMS | NVME_CC_SHN
|
||||
| NVME_CC_IOSQES | NVME_CC_IOCQES;
|
||||
|
||||
write32(nvme->config + 0x14, 0);
|
||||
write32(nvme->config + 0x1c, 0);
|
||||
|
||||
int status, timeout = (read64(nvme->config) >> 24 & 0xff) * 500;
|
||||
do {
|
||||
status = read32(nvme->config + 0x1c) & 0x3;
|
||||
if (status == 0x2) {
|
||||
printf("NVMe ERROR: Failed to disable controller. FATAL ERROR\n");
|
||||
goto _free_abort;
|
||||
goto abort;
|
||||
}
|
||||
if (timeout < 0) {
|
||||
printf("NVMe ERROR: Failed to disable controller. Timeout.\n");
|
||||
goto _free_abort;
|
||||
goto abort;
|
||||
}
|
||||
timeout -= 10;
|
||||
mdelay(10);
|
||||
} while (status != 0x0);
|
||||
if (create_admin_queues(nvme))
|
||||
goto _free_abort;
|
||||
goto abort;
|
||||
write32(nvme->config + 0x14, cc);
|
||||
|
||||
timeout = (read64(nvme->config) >> 24 & 0xff) * 500;
|
||||
do {
|
||||
status = read32(nvme->config + 0x1c) & 0x3;
|
||||
if (status == 0x2)
|
||||
goto _delete_admin_abort;
|
||||
goto abort;
|
||||
if (timeout < 0)
|
||||
goto _delete_admin_abort;
|
||||
goto abort;
|
||||
timeout -= 10;
|
||||
mdelay(10);
|
||||
} while (status != 0x1);
|
||||
@@ -381,21 +381,20 @@ static void nvme_init(pcidev_t dev)
|
||||
uint16_t command = pci_read_config16(dev, PCI_COMMAND);
|
||||
pci_write_config16(dev, PCI_COMMAND, command | PCI_COMMAND_MASTER);
|
||||
if (create_io_completion_queue(nvme))
|
||||
goto _delete_admin_abort;
|
||||
goto abort;
|
||||
if (create_io_submission_queue(nvme))
|
||||
goto _delete_completion_abort;
|
||||
goto abort;
|
||||
storage_attach_device((storage_dev_t *)nvme);
|
||||
printf("NVMe init done.\n");
|
||||
return;
|
||||
|
||||
_delete_completion_abort:
|
||||
abort:
|
||||
printf("NVMe init failed.\n");
|
||||
delete_io_submission_queue(nvme);
|
||||
delete_io_completion_queue(nvme);
|
||||
_delete_admin_abort:
|
||||
delete_admin_queues(nvme);
|
||||
_free_abort:
|
||||
free(nvme->prp_list);
|
||||
free(nvme);
|
||||
printf("NVMe init failed.\n");
|
||||
}
|
||||
|
||||
void nvme_initialize(struct pci_dev *dev)
|
||||
|
@@ -33,7 +33,7 @@
|
||||
*
|
||||
*/
|
||||
|
||||
#ifndef __ARCH_BARRIER_H__
|
||||
#ifndef __ARCH_BARRIER_H_
|
||||
#define __ARCH_BARRIER_H__
|
||||
|
||||
#include <arch/cache.h>
|
||||
|
@@ -33,7 +33,7 @@
|
||||
*
|
||||
*/
|
||||
|
||||
#ifndef __ARCH_BARRIER_H__
|
||||
#ifndef __ARCH_BARRIER_H_
|
||||
#define __ARCH_BARRIER_H__
|
||||
|
||||
#include <arch/cache.h>
|
||||
|
53
payloads/libpayload/include/compiler.h
Normal file
53
payloads/libpayload/include/compiler.h
Normal file
@@ -0,0 +1,53 @@
|
||||
/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0-only */
|
||||
|
||||
#ifndef _COMMONLIB_BSD_COMPILER_H_
|
||||
#define _COMMONLIB_BSD_COMPILER_H_
|
||||
|
||||
#ifndef __packed
|
||||
#if defined(__WIN32) || defined(__WIN64)
|
||||
#define __packed __attribute__((gcc_struct, packed))
|
||||
#else
|
||||
#define __packed __attribute__((packed))
|
||||
#endif
|
||||
#endif
|
||||
|
||||
#ifndef __aligned
|
||||
#define __aligned(x) __attribute__((aligned(x)))
|
||||
#endif
|
||||
|
||||
#ifndef __always_unused
|
||||
#define __always_unused __attribute__((unused))
|
||||
#endif
|
||||
|
||||
#ifndef __must_check
|
||||
#define __must_check __attribute__((warn_unused_result))
|
||||
#endif
|
||||
|
||||
#ifndef __weak
|
||||
#define __weak __attribute__((weak))
|
||||
#endif
|
||||
|
||||
#ifndef __noreturn
|
||||
#define __noreturn __attribute__((noreturn))
|
||||
#endif
|
||||
|
||||
#ifndef __always_inline
|
||||
#define __always_inline inline __attribute__((always_inline))
|
||||
#endif
|
||||
|
||||
/* This evaluates to the type of the first expression, unless that is constant
|
||||
in which case it evalutates to the type of the second. This is useful when
|
||||
assigning macro parameters to temporary variables, because that would
|
||||
normally circumvent the special loosened type promotion rules for integer
|
||||
literals. By using this macro, the promotion can happen at the time the
|
||||
literal is assigned to the temporary variable. If the literal doesn't fit in
|
||||
the chosen type, -Werror=overflow will catch it, so this should be safe. */
|
||||
#define __TYPEOF_UNLESS_CONST(expr, fallback_expr) __typeof__( \
|
||||
__builtin_choose_expr(__builtin_constant_p(expr), fallback_expr, expr))
|
||||
|
||||
/* This creates a unique local variable name for use in macros. */
|
||||
#define __TMPNAME_3(i) __tmpname_##i
|
||||
#define __TMPNAME_2(i) __TMPNAME_3(i)
|
||||
#define __TMPNAME __TMPNAME_2(__COUNTER__)
|
||||
|
||||
#endif
|
@@ -84,7 +84,6 @@ enum {
|
||||
CB_TAG_ACPI_CNVS = 0x0041,
|
||||
CB_TAG_TYPE_C_INFO = 0x0042,
|
||||
CB_TAG_ACPI_RSDP = 0x0043,
|
||||
CB_TAG_PCIE = 0x0044,
|
||||
CB_TAG_CMOS_OPTION_TABLE = 0x00c8,
|
||||
CB_TAG_OPTION = 0x00c9,
|
||||
CB_TAG_OPTION_ENUM = 0x00ca,
|
||||
@@ -266,12 +265,6 @@ struct cb_gpios {
|
||||
struct cb_gpio gpios[0];
|
||||
};
|
||||
|
||||
struct cb_pcie {
|
||||
uint32_t tag;
|
||||
uint32_t size;
|
||||
cb_uint64_t ctrl_base; /* Base address of PCIe controller */
|
||||
};
|
||||
|
||||
struct lb_range {
|
||||
uint32_t tag;
|
||||
uint32_t size;
|
||||
|
@@ -1,6 +1,6 @@
|
||||
/*
|
||||
*
|
||||
* Copyright (c) 2012 The ChromiumOS Authors.
|
||||
* Copyright (c) 2012 The Chromium OS Authors.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
|
@@ -1,6 +1,6 @@
|
||||
/*
|
||||
*
|
||||
* Copyright (c) 2012 The ChromiumOS Authors.
|
||||
* Copyright (c) 2012 The Chromium OS Authors.
|
||||
*
|
||||
* Redistribution and use in source and binary forms, with or without
|
||||
* modification, are permitted provided that the following conditions
|
||||
|
@@ -45,7 +45,6 @@
|
||||
#include <stdbool.h>
|
||||
#include <libpayload-config.h>
|
||||
#include <cbgfx.h>
|
||||
#include <commonlib/bsd/elog.h>
|
||||
#include <commonlib/bsd/fmap_serialized.h>
|
||||
#include <commonlib/bsd/helpers.h>
|
||||
#include <commonlib/bsd/mem_chip_info.h>
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user