Compare commits
22 Commits
Author | SHA1 | Date | |
---|---|---|---|
|
0e7f0928f3 | ||
|
b29e5075e1 | ||
|
5ca32c0855 | ||
|
69ac9be039 | ||
|
e60b69f461 | ||
|
d5999adedc | ||
|
6455edb1b5 | ||
|
a80b0ef9a8 | ||
|
1842e2a7f4 | ||
|
33ea3e837d | ||
|
1d8832b3ed | ||
|
5d03264046 | ||
|
3fab7d1d91 | ||
|
fc189a3339 | ||
|
9e635d2c87 | ||
|
70f3ad9dc5 | ||
|
1cc43cf180 | ||
|
d37873beae | ||
|
c3a2c48bf6 | ||
|
fc7fecf7c8 | ||
|
020fb66698 | ||
|
891cc9a939 |
@@ -7,7 +7,7 @@ AllowShortIfStatementsOnASingleLine: false
|
||||
IndentCaseLabels: false
|
||||
SortIncludes: false
|
||||
ContinuationIndentWidth: 8
|
||||
ColumnLimit: 96
|
||||
ColumnLimit: 0
|
||||
AlwaysBreakBeforeMultilineStrings: true
|
||||
AllowShortLoopsOnASingleLine: false
|
||||
AllowShortFunctionsOnASingleLine: false
|
||||
|
24
.gitmodules
vendored
@@ -1,36 +1,28 @@
|
||||
[submodule "3rdparty/blobs"]
|
||||
path = 3rdparty/blobs
|
||||
url = ../blobs.git
|
||||
url = https://github.com/coreboot/blobs.git
|
||||
update = none
|
||||
ignore = dirty
|
||||
[submodule "util/nvidia-cbootimage"]
|
||||
path = util/nvidia/cbootimage
|
||||
url = ../nvidia-cbootimage.git
|
||||
url = https://github.com/coreboot/nvidia-cbootimage.git
|
||||
[submodule "vboot"]
|
||||
path = 3rdparty/vboot
|
||||
url = ../vboot.git
|
||||
url = https://github.com/coreboot/vboot.git
|
||||
[submodule "arm-trusted-firmware"]
|
||||
path = 3rdparty/arm-trusted-firmware
|
||||
url = ../arm-trusted-firmware.git
|
||||
url = https://github.com/coreboot/arm-trusted-firmware.git
|
||||
[submodule "3rdparty/chromeec"]
|
||||
path = 3rdparty/chromeec
|
||||
url = ../chrome-ec.git
|
||||
url = https://github.com/coreboot/chrome-ec.git
|
||||
[submodule "libhwbase"]
|
||||
path = 3rdparty/libhwbase
|
||||
url = ../libhwbase.git
|
||||
url = https://github.com/coreboot/libhwbase.git
|
||||
[submodule "libgfxinit"]
|
||||
path = 3rdparty/libgfxinit
|
||||
url = ../libgfxinit.git
|
||||
url = https://github.com/coreboot/libgfxinit.git
|
||||
[submodule "3rdparty/fsp"]
|
||||
path = 3rdparty/fsp
|
||||
url = ../fsp.git
|
||||
update = none
|
||||
ignore = dirty
|
||||
[submodule "opensbi"]
|
||||
path = 3rdparty/opensbi
|
||||
url = ../opensbi.git
|
||||
[submodule "intel-microcode"]
|
||||
path = 3rdparty/intel-microcode
|
||||
url = ../intel-microcode.git
|
||||
url = https://github.com/coreboot/fsp.git
|
||||
update = none
|
||||
ignore = dirty
|
||||
|
2
3rdparty/blobs
vendored
2
3rdparty/fsp
vendored
1
3rdparty/intel-microcode
vendored
2
3rdparty/libgfxinit
vendored
2
3rdparty/libhwbase
vendored
1
3rdparty/opensbi
vendored
2
3rdparty/vboot
vendored
@@ -29,6 +29,7 @@
|
||||
</li>
|
||||
<li><a target="_blank" href="SoC/soc.html">SoC</a> support</li>
|
||||
<li><a target="_blank" href="Board/board.html">Board</a> support</li>
|
||||
<li><a target="_blank" href="vboot.html">Verified Boot (vboot)</a> support</li>
|
||||
</ul>
|
||||
|
||||
|
||||
|
402
Documentation/Intel/vboot.html
Normal file
@@ -0,0 +1,402 @@
|
||||
<!DOCTYPE html>
|
||||
<html>
|
||||
<head>
|
||||
<title>vboot - Verified Boot Support</title>
|
||||
</head>
|
||||
<body>
|
||||
|
||||
<h1>vboot - Verified Boot Support</h1>
|
||||
|
||||
<p>
|
||||
Google's verified boot support consists of:
|
||||
</p>
|
||||
<ul>
|
||||
<li>A root of trust</li>
|
||||
<li>Special firmware layout</li>
|
||||
<li>Firmware verification</li>
|
||||
<li>Firmware measurements</li>
|
||||
<li>A firmware update mechanism</li>
|
||||
<li>Specific build flags</li>
|
||||
<li>Signing the coreboot image</li>
|
||||
</ul>
|
||||
|
||||
Google's vboot verifies the firmware and places measurements
|
||||
within the TPM.
|
||||
|
||||
<hr>
|
||||
<h2>Root of Trust</h2>
|
||||
<p>
|
||||
When using vboot, the root-of-trust is basically the read-only portion of the
|
||||
SPI flash. The following items factor into the trust equation:
|
||||
</p>
|
||||
<ul>
|
||||
<li>The GCC compiler must reliably translate the code into machine code
|
||||
without inserting any additional code (virus, backdoor, etc.)
|
||||
</li>
|
||||
<li>The CPU must reliably execute the reset sequence and instructions as
|
||||
documented by the CPU manufacturer.
|
||||
</li>
|
||||
<li>The SPI flash must provide only the code programmed into it to the CPU
|
||||
without providing any alternative reset vector or code sequence.
|
||||
</li>
|
||||
<li>The SPI flash must honor the write-protect input and protect the
|
||||
specified portion of the SPI flash from all erase and write accesses.
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The firmware is typically protected using the write-protect pin on the SPI
|
||||
flash part and setting some of the write-protect bits in the status register
|
||||
during manufacturing. The protected area is platform specific and for x86
|
||||
platforms is typically 1/4th of the SPI flash
|
||||
part size. Because this portion of the SPI flash is hardware write protected,
|
||||
it is not possible to update this portion of the SPI flash in the field,
|
||||
without altering the system to eliminate the ground connection to the SPI flash
|
||||
write-protect pin. Without hardware modifications, this portion of the SPI
|
||||
flash maintains the manufactured state during the system's lifetime.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<h2>Firmware Layout</h2>
|
||||
<p>
|
||||
Several sections are added to the firmware layout to support vboot:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Read-only section</li>
|
||||
<li>Google Binary Blob (GBB) area</li>
|
||||
<li>Read/write section A</li>
|
||||
<li>Read/write section B</li>
|
||||
</ul>
|
||||
<p>
|
||||
The following sections describe the various portions of the flash layout.
|
||||
</p>
|
||||
|
||||
<h3>Read-Only Section</h3>
|
||||
<p>
|
||||
The read-only section contains a coreboot file system (CBFS) that contains all
|
||||
of the boot firmware necessary to perform recovery for the system. This
|
||||
firmware is typically protected using the write-protect pin on the SPI flash
|
||||
part and setting some of the write-protect bits in the status register during
|
||||
manufacturing. The protected area is typically 1/4th of the SPI flash part
|
||||
size and must cover the entire read-only section which consists of:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Vital Product Data (VPD) area</li>
|
||||
<li>Firmware ID area</li>
|
||||
<li>Google Binary Blob (GBB) area</li>
|
||||
<li>coreboot file system containing read-only recovery firmware</li>
|
||||
</ul>
|
||||
|
||||
<h3>Google Binary Blob (GBB) Area</h3>
|
||||
<p>
|
||||
The GBB area is part of the read-only section. This area contains a 4096 or
|
||||
8192 bit public root RSA key that is used to verify the VBLOCK area to obtain
|
||||
the firmware signing key.
|
||||
</p>
|
||||
|
||||
<h3>Recovery Firmware</h3>
|
||||
<p>
|
||||
The recovery firmware is contained within a coreboot file system and consists
|
||||
of:
|
||||
</p>
|
||||
<ul>
|
||||
<li>reset vector</li>
|
||||
<li>bootblock</li>
|
||||
<li>verstage</li>
|
||||
<li>romstage</li>
|
||||
<li>postcar</li>
|
||||
<li>ramstage</li>
|
||||
<li>payload</li>
|
||||
<li>flash map file</li>
|
||||
<li>config file</li>
|
||||
<li>processor specific files:
|
||||
<ul>
|
||||
<li>Microcode</li>
|
||||
<li>fspm.bin</li>
|
||||
<li>fsps.bin</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The recovery firmware is written during manufacturing and typically contains
|
||||
code to write the storage device (eMMC device or hard disk). The recovery
|
||||
image is usually contained on a socketed device such as a USB flash drive or
|
||||
an SD card. Depending upon the payload firmware doing the recovery, it may
|
||||
be possible for the user to interact with the system to specify the recovery
|
||||
image path. Part of the recovery is also to write the A and B areas of the
|
||||
SPI flash device to boot the system.
|
||||
</p>
|
||||
|
||||
|
||||
<h3>Read/Write Section</h3>
|
||||
|
||||
<p>
|
||||
The read/write sections contain an area which contains the firmware signing
|
||||
key and signature and an area containing a coreboot file system with a subset
|
||||
of the firmware. The firmware files in FW_MAIN_A and FW_MAIN_B are:
|
||||
</p>
|
||||
<ul>
|
||||
<li>romstage</li>
|
||||
<li>postcar</li>
|
||||
<li>ramstage</li>
|
||||
<li>payload</li>
|
||||
<li>config file</li>
|
||||
<li>processor specific files:
|
||||
<ul>
|
||||
<li>Microcode</li>
|
||||
<li>fspm.bin</li>
|
||||
<li>fsps.bin</li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The firmware subset enables most issues to be fixed in the field with firmware
|
||||
updates. The firmware files handle memory and most of silicon initialization.
|
||||
These files also produce the tables which get passed to the operating system.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<h2>Firmware Updates</h2>
|
||||
<p>
|
||||
The read/write sections exist in one of three states:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Invalid</li>
|
||||
<li>Ready to boot</li>
|
||||
<li>Successfully booted</li>
|
||||
</ul>
|
||||
|
||||
<table border="1">
|
||||
<tr bgcolor="#ffc0c0">
|
||||
<td>
|
||||
Where is this state information written?
|
||||
<br/>CMOS?
|
||||
<br/>RW_NVRAM?
|
||||
<br/>RW_FWID_*
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
Firmware updates are handled by the operating system by writing any read/write
|
||||
section that is not in the "successfully booted" state. Upon the next reboot,
|
||||
vboot determines the section to boot. If it finds one in the "ready to boot"
|
||||
state then it attempts to boot using that section. If the boot fails then
|
||||
vboot marks the section as invalid and attempts to fall back to a read/write
|
||||
section in the "successfully booted" state. If vboot is not able to find a
|
||||
section in the "successfully booted" state then vboot enters recovery mode.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Only the operating system is able to transition a section from the "ready to
|
||||
boot" state to the "successfully booted" state. The transition is typically
|
||||
done after the operating system has been running for a while indicating
|
||||
that successful boot was possible and the operating system is stable.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Note that as long as the SPI write protection is in place then the system is
|
||||
always recoverable. If the flash update fails then the system will continue
|
||||
to boot using the previous read/write area. The same is true if coreboot
|
||||
passes control to the payload or the operating system and then the boot fails.
|
||||
In the worst case, the SPI flash gets totally corrupted in which case vboot
|
||||
fails the signature checks and enters recovery mode. There are no times where
|
||||
the SPI flash is exposed and the reset vector or part of the recovery firmware
|
||||
gets corrupted.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<h2>Build Flags</h2>
|
||||
<p>
|
||||
The following Kconfig values need to be selected to enable vboot:
|
||||
</p>
|
||||
<ul>
|
||||
<li>COLLECT_TIMESTAMPS</li>
|
||||
<li>VBOOT</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
The starting stage needs to be specified by selecting either
|
||||
VBOOT_STARTS_IN_BOOTBLOCK or VBOOT_STARTS_IN_ROMSTAGE.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If vboot starts in bootblock then vboot may be built as a separate stage by
|
||||
selecting VBOOT_SEPARATE_VERSTAGE. Additionally, if static RAM is too small
|
||||
to fit both verstage and romstage then selecting VBOOT_RETURN_FROM_VERSTAGE
|
||||
enables bootblock to reuse the RAM occupied by verstage for romstage.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Non-volatile flash is needed for vboot operation. This flash area may be in
|
||||
CMOS, the EC, or in a read/write area of the SPI flash device. Select one of
|
||||
the following:
|
||||
</p>
|
||||
<ul>
|
||||
<li>VBOOT_VBNV_CMOS</li>
|
||||
<li>VBOOT_VBNV_EC</li>
|
||||
<li>VBOOT_VBNV_FLASH</li>
|
||||
</ul>
|
||||
<p>
|
||||
More non-volatile storage features may be found in src/vboot/Kconfig.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
A TPM is also required for vboot operation. TPMs are available in
|
||||
drivers/i2c/tpm and drivers/pc80/tpm.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
In addition to adding the coreboot files into the read-only region, enabling
|
||||
vboot causes the build script to add the read/write files into coreboot file
|
||||
systems in FW_MAIN_A and FW_MAIN_B.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<h2>Signing the coreboot Image</h2>
|
||||
<p>
|
||||
The following command script is an example of how to sign the coreboot image file.
|
||||
This script is used on the Intel Galileo board and creates the GBB area and
|
||||
inserts it into the coreboot image. It also updates the VBLOCK areas with the
|
||||
firmware signing key and the signature for the FW_MAIN firmware. More details
|
||||
are available in 3rdparty/vboot/README.
|
||||
</p>
|
||||
|
||||
<pre><code>#!/bin/sh
|
||||
#
|
||||
# The necessary tools were built and installed using the following commands:
|
||||
#
|
||||
# pushd 3rdparty/vboot
|
||||
# make
|
||||
# sudo make install
|
||||
# popd
|
||||
#
|
||||
# The keys were made using the following command
|
||||
#
|
||||
# 3rdparty/vboot/scripts/keygeneration/create_new_keys.sh \
|
||||
# --4k --4k-root --output $PWD/keys
|
||||
#
|
||||
#
|
||||
# The "magic" numbers below are derived from the GBB section in
|
||||
# src/mainboard/intel/galileo/vboot.fmd.
|
||||
#
|
||||
# GBB Header Size: 0x80
|
||||
# GBB Offset: 0x611000, 4KiB block number: 1553 (0x611)
|
||||
# GBB Length: 0x7f000, 4KiB blocks: 127 (0x7f)
|
||||
# COREBOOT Offset: 0x690000, 4KiB block number: 1680 (0x690)
|
||||
# COREBOOT Length: 0x170000, 4KiB blocks: 368 (0x170)
|
||||
#
|
||||
# 0x7f000 (GBB Length) = 0x80 + 0x100 + 0x1000 + 0x7ce80 + 0x1000
|
||||
#
|
||||
# Create the GBB area blob
|
||||
# Parameters: hwid_size,rootkey_size,bmpfv_size,recoverykey_size
|
||||
#
|
||||
gbb_utility -c 0x100,0x1000,0x7ce80,0x1000 gbb.blob
|
||||
|
||||
#
|
||||
# Copy from the start of the flash to the GBB region into the signed flash
|
||||
# image.
|
||||
#
|
||||
# 1553 * 4096 = 0x611 * 0x1000 = 0x611000, size of area before GBB
|
||||
#
|
||||
dd conv=fdatasync ibs=4096 obs=4096 count=1553 \
|
||||
if=build/coreboot.rom of=build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Append the empty GBB area to the coreboot.rom image.
|
||||
#
|
||||
# 1553 * 4096 = 0x611 * 0x1000 = 0x611000, offset to GBB
|
||||
#
|
||||
dd conv=fdatasync obs=4096 obs=4096 seek=1553 if=gbb.blob \
|
||||
of=build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Append the rest of the read-only region into the signed flash image.
|
||||
#
|
||||
# 1680 * 4096 = 0x690 * 0x1000 = 0x690000, offset to COREBOOT area
|
||||
# 368 * 4096 = 0x170 * 0x1000 = 0x170000, length of COREBOOT area
|
||||
#
|
||||
dd conv=fdatasync ibs=4096 obs=4096 skip=1680 seek=1680 count=368 \
|
||||
if=build/coreboot.rom of=build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Insert the HWID and public root and recovery RSA keys into the GBB area.
|
||||
#
|
||||
gbb_utility \
|
||||
--set --hwid='Galileo' \
|
||||
-r $PWD/keys/recovery_key.vbpubk \
|
||||
-k $PWD/keys/root_key.vbpubk \
|
||||
build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Sign the read/write firmware areas with the private signing key and update
|
||||
# the VBLOCK_A and VBLOCK_B regions.
|
||||
#
|
||||
3rdparty/vboot/scripts/image_signing/sign_firmware.sh \
|
||||
build/coreboot.signed.rom \
|
||||
$PWD/keys \
|
||||
build/coreboot.signed.rom
|
||||
</code></pre>
|
||||
|
||||
<hr>
|
||||
<h2>Boot Flow</h2>
|
||||
<p>
|
||||
The reset vector exist in the read-only area and points to the bootblock entry
|
||||
point. The only copy of the bootblock exists in the read-only area of the SPI
|
||||
flash. Verstage may be part of the bootblock or a separate stage. If separate
|
||||
then the bootblock loads verstage from the read-only area and transfers control
|
||||
to it.
|
||||
</p>
|
||||
|
||||
<p>
|
||||
Upon first boot, verstage attempts to verify the read/write section A. It gets
|
||||
the public root key from the GBB area and uses that to verify the VBLOCK area
|
||||
in read-write section A. If the VBLOCK area is valid then it extracts the
|
||||
firmware signing key (1024-8192 bits) and uses that to verify the FW_MAIN_A
|
||||
area of read/write section A. If the verification is successful then verstage
|
||||
instructs coreboot to use the coreboot file system in read/write section A for
|
||||
the contents of the remaining boot firmware (romstage, postcar, ramstage and
|
||||
the payload).
|
||||
</p>
|
||||
|
||||
<p>
|
||||
If verification fails for the read/write area and the other read/write area is
|
||||
not valid vboot falls back to the read-only area to boot into system recovery.
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<h2>Chromebook Special Features</h2>
|
||||
<p>
|
||||
Google's Chromebooks have some special features:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Developer mode</li>
|
||||
<li>Write-protect screw</li>
|
||||
</ul>
|
||||
|
||||
<h3>Developer Mode</h3>
|
||||
<p>
|
||||
Developer mode allows the user to use coreboot to boot another operating system.
|
||||
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
|
||||
security to access files on the local system or cloud.
|
||||
</p>
|
||||
|
||||
<h3>Write Protect Screw</h3>
|
||||
<p>
|
||||
Chromebooks have a write-protect screw which provides the ground to the
|
||||
write-protect pin of the SPI flash. Google specifically did this to allow
|
||||
the manufacturing line and advanced developers to re-write the entire SPI flash
|
||||
part. Once the screw is removed, any firmware may be placed on the device.
|
||||
However, accessing this screw requires opening the case and voids the system
|
||||
warranty!
|
||||
</p>
|
||||
|
||||
<hr>
|
||||
<p>Modified: 2 May 2017</p>
|
||||
</body>
|
||||
</html>
|
@@ -16,12 +16,6 @@ This is an (incomplete) list of POST codes emitted by coreboot v4.
|
||||
0x66 Devices have been enumerated
|
||||
0x88 Devices have been configured
|
||||
0x89 Devices have been enabled
|
||||
0xe0 Boot media (e.g. SPI ROM) is corrupt
|
||||
0xe1 Resource stored within CBFS is corrupt
|
||||
0xe2 Vendor binary (e.g. FSP) generated a fatal error
|
||||
0xe3 RAM could not be initialized
|
||||
0xe4 Critical hardware component could not initialize
|
||||
0xe5 Video subsystem failed to initialize
|
||||
0xf8 Entry into elf boot
|
||||
0xf3 Jumping to payload
|
||||
|
||||
|
@@ -8,9 +8,8 @@ listed as consumable is subject to change without notice.
|
||||
## Background and Usage
|
||||
|
||||
coreboot passes information to downstream users using coreboot tables. These
|
||||
table definitions can be found in
|
||||
`./src/commonlib/include/commonlib/coreboot_tables.h` and
|
||||
`./payloads/libpayload/include/coreboot_tables.h` respectively within coreboot
|
||||
table definitions can be found in src/include/boot/coreboot_tables.h and
|
||||
payloads/libpayload/include/coreboot_tables.h respectively within coreboot
|
||||
and libpayload. One of the most vital and important pieces of information
|
||||
found within these tables is the memory map of the system indicating
|
||||
available and reserved memory.
|
@@ -15,7 +15,7 @@ Payloads run from the ramstage are started in S mode, and trap delegation
|
||||
will have been done. These payloads rely on the SBI and can not replace it.
|
||||
|
||||
## Stage handoff protocol
|
||||
On entry to a stage or payload (including SELF payloads),
|
||||
On entry to a stage or payload,
|
||||
* all harts are running.
|
||||
* A0 is the hart ID.
|
||||
* A1 is the pointer to the Flattened Device Tree (FDT).
|
||||
|
@@ -2,8 +2,6 @@
|
||||
|
||||
This section contains documentation about coreboot on x86 architecture.
|
||||
|
||||
* [x86 PAE support](pae.md)
|
||||
|
||||
## State of x86_64 support
|
||||
At the moment there's no single board that supports x86_64 or to be exact
|
||||
`ARCH_RAMSTAGE_X86_64` and `ARCH_ROMSTAGE_X86_64`.
|
||||
|
@@ -1,15 +0,0 @@
|
||||
# x86_32 PAE documentation
|
||||
|
||||
Due to missing x86_64 support it's required to use PAE enabled x86_32 code.
|
||||
The corresponding functions can be found in ``src/cpu/x86/pae/``.
|
||||
|
||||
## Memory clearing helper functions
|
||||
|
||||
To clear all DRAM on request of the
|
||||
[Security API](../../security/memory_clearing.md), a helper function can be used
|
||||
called `memset_pae`.
|
||||
The function has additional requirements in contrast to `memset`, and has more
|
||||
overhead as it uses virtual memory to access memory above 4GiB.
|
||||
Memory is cleared in 2MiB chunks, which might take a while.
|
||||
|
||||
Make sure to enable caches through MTRRs, otherwise `memset_pae` will be slow!
|
@@ -22,30 +22,19 @@ Refrain from insulting anyone or the group they belong to. Remember that
|
||||
people might be sensitive to other things than you are.
|
||||
|
||||
Most of our community members are not native English speakers, thus
|
||||
misunderstandings can (and do) happen. Assume that others are friendly
|
||||
and may have picked less-than-stellar wording by accident as long as
|
||||
you possibly can.
|
||||
misunderstandings can (and do) happen. Always assume that others are
|
||||
friendly and may have picked less-than-stellar wording by accident.
|
||||
|
||||
## Reporting Issues
|
||||
|
||||
If you have a grievance due to conduct in this community, we're sorry
|
||||
that you have had a bad experience, and we want to hear about it so
|
||||
we can resolve the situation.
|
||||
|
||||
Please contact members of our arbitration team (listed below) promptly
|
||||
and directly, in person (if available) or by email: They will listen
|
||||
to you and react in a timely fashion.
|
||||
|
||||
If you feel uncomfortable, please don't wait it out, ask for help,
|
||||
so we can work on setting things right.
|
||||
If you have a grievance due to conduct in this community, we want to hear
|
||||
about it so we can handle the situation. Please contact our arbitration
|
||||
team directly: They will listen to you and react in a timely fashion.
|
||||
|
||||
For transparency there is no alias or private mailing list address for
|
||||
you to reach out to, since we want to make sure that you know who will
|
||||
and who won't read your message.
|
||||
(and who won't) read your message.
|
||||
|
||||
However since people might be on travel or otherwise be unavailable
|
||||
at times, please reach out to multiple persons at once, especially
|
||||
when using email.
|
||||
However since people might be on travel or otherwise be unavailable at
|
||||
times, consider reaching out to multiple persons.
|
||||
|
||||
The team will treat your messages confidential as far as the law permits.
|
||||
For the purpose of knowing what law applies, the list provides the usual
|
||||
@@ -84,10 +73,15 @@ immediately.
|
||||
If a community member engages in unacceptable behavior, the community
|
||||
organizers may take any action they deem appropriate, up to and including
|
||||
a temporary ban or permanent expulsion from the community without warning
|
||||
(and without refund in the case of a paid event).
|
||||
(and without refund in the case of a paid event). Community organizers
|
||||
can be part of the arbitration team, or organizers of events and online
|
||||
communities.
|
||||
|
||||
## If You Witness or Are Subject to Unacceptable Behavior
|
||||
|
||||
If you are subject to or witness unacceptable behavior, or have any other
|
||||
concerns, please notify someone from the arbitration team immediately.
|
||||
|
||||
Community organizers can be members of the arbitration team, or organizers
|
||||
of events and online communities.
|
||||
|
||||
## Addressing Grievances
|
||||
|
||||
@@ -108,7 +102,7 @@ Our arbitration team consists of the following people
|
||||
* Stefan Reinauer <stefan.reinauer@coreboot.org> (USA)
|
||||
* Patrick Georgi <patrick@coreboot.org> (Germany)
|
||||
* Ronald Minnich <rminnich@coreboot.org> (USA)
|
||||
* Martin Roth <martin@coreboot.org> (USA)
|
||||
* Marc Jones <mjones@coreboot.org> (USA)
|
||||
|
||||
## License and attribution
|
||||
|
||||
|
@@ -29,12 +29,6 @@ Provide packages/installers of our compiler toolchain for Linux distros,
|
||||
Windows, Mac OS. For Windows, this should also include the environment
|
||||
(shell, make, ...).
|
||||
|
||||
The scripts to generate these packages should be usable on a Linux
|
||||
host, as that's what we're using for our automated build testing system
|
||||
that we could extend to provide current packages going forward. This
|
||||
might include automating some virtualization system (eg. QEMU or CrosVM) for
|
||||
non-Linux builds or Docker for different Linux distributions.
|
||||
|
||||
### Requirements
|
||||
* coreboot knowledge: Should know how to build coreboot images and where
|
||||
the compiler comes into play in our build system.
|
||||
@@ -84,7 +78,6 @@ code doesn't entirely break these architectures
|
||||
hardware is available.
|
||||
|
||||
### Mentors
|
||||
* Patrick Georgi <patrick@georgi.software>
|
||||
|
||||
## Add Kernel Address Sanitizer functionality to coreboot
|
||||
The Kernel Address Sanitizer (KASAN) is a runtime dynamic memory error detector.
|
||||
@@ -152,52 +145,3 @@ their bug reports.
|
||||
|
||||
### Mentors
|
||||
* Patrick Georgi <patrick@georgi.software>
|
||||
|
||||
## Make coreboot coverity clean
|
||||
coreboot and several other of our projects are automatically tested
|
||||
using Synopsys' free "Coverity Scan" service. While some fare pretty
|
||||
good, like [em100](https://scan.coverity.com/projects/em100) at 0 known
|
||||
defects, there are still many open issues in other projects, most notably
|
||||
[coreboot](https://scan.coverity.com/projects/coreboot) itself (which
|
||||
is also the largest codebase).
|
||||
|
||||
Not all of the reports are actual issues, but the project benefits a
|
||||
lot if the list of unhandled reports is down to 0 because that provides
|
||||
a baseline when future changes reintroduce new issues: it's easier to
|
||||
triage and handle a list of 5 issues rather than more than 350.
|
||||
|
||||
This project would be going through all reports and handling them
|
||||
appropriately: Figure out if reports are valid or not and mark them
|
||||
as such. For valid reports, provide patches to fix the underlying issue.
|
||||
|
||||
### Mentors
|
||||
* Patrick Georgi <patrick@georgi.software>
|
||||
|
||||
## Extend Ghidra to support analysis of firmware images
|
||||
[Ghidra](https://ghidra-sre.org) is a recently released cross-platform
|
||||
disassembler and decompiler that is extensible through plugins. Make it
|
||||
useful for firmware related work: Automatically parse formats (eg. by
|
||||
integrating UEFITool, cbfstool, decompressors), automatically identify
|
||||
16/32/64bit code on x86/amd64, etc.
|
||||
|
||||
## Learn hardware behavior from I/O and memory access logs
|
||||
[SerialICE](https://www.serialice.com) is a tool to trace the behavior of
|
||||
executable code like firmware images. One result of that is a long log file
|
||||
containing the accesses to hardware resources.
|
||||
|
||||
It would be useful to have a tool that assists a developer-analyst in deriving
|
||||
knowledge about hardware from such logs. This likely can't be entirely
|
||||
automatic, but a tool that finds patterns and can propagate them across the
|
||||
log (incrementially raising the log from plain I/O accesses to a high-level
|
||||
description of driver behavior) would be of great use.
|
||||
|
||||
This is a research-heavy project.
|
||||
|
||||
### Requirements
|
||||
* Driver knowledge: Somebody working on this should be familiar with
|
||||
how hardware works (eg. MMIO based register access, index/data port
|
||||
accesses) and how to read data sheets.
|
||||
* Machine Learning: ML techniques may be useful to find structure in traces.
|
||||
|
||||
### Mentors
|
||||
* Ron Minnich <rminnich@google.com>
|
||||
|
@@ -1,7 +0,0 @@
|
||||
# Platform indenpendend drivers documentation
|
||||
|
||||
The drivers can be found in `src/drivers`. They are intended for onboard
|
||||
and plugin devices, significantly reducing integration complexity and
|
||||
they allow to easily reuse existing code accross platforms.
|
||||
|
||||
* [IPMI KCS](ipmi_kcs.md)
|
@@ -1,47 +0,0 @@
|
||||
# IPMI KCS driver
|
||||
|
||||
The driver can be found in `src/drivers/ipmi/`. It works with BMC that provide
|
||||
a KCS I/O interface as specified in the [IPMI] standard.
|
||||
|
||||
The driver detects the IPMI version, reserves the I/O space in coreboot's
|
||||
resource allocator and writes the required ACPI and SMBIOS tables.
|
||||
|
||||
## For developers
|
||||
|
||||
To use the driver, select the `IPMI_KCS` Kconfig and add the following PNP
|
||||
device under the LPC bridge device (in example for the KCS at 0xca2):
|
||||
|
||||
```
|
||||
chip drivers/ipmi
|
||||
device pnp ca2.0 on end # IPMI KCS
|
||||
end
|
||||
```
|
||||
|
||||
**Note:** The I/O base address needs to be aligned to 2.
|
||||
|
||||
The following registers can be set:
|
||||
|
||||
* `have_nv_storage`
|
||||
* Boolean
|
||||
* If true `nv_storage_device_address` will be added to SMBIOS type 38.
|
||||
* `nv_storage_device_address`
|
||||
* Integer
|
||||
* The NV storage address as defined in SMBIOS spec for type 38.
|
||||
* `bmc_i2c_address`
|
||||
* Integer
|
||||
* The i2c address of the BMC. zero if not applicable.
|
||||
* `have_apic`
|
||||
* Boolean
|
||||
* If true the `apic_interrupt` will be added to SPMI table.
|
||||
* `apic_interrupt`
|
||||
* Integer
|
||||
* The APIC interrupt used to notify about a change on the KCS.
|
||||
* `have_gpe`
|
||||
* Boolean
|
||||
* If true the `gpe_interrupt` will be added to SPMI table.
|
||||
* `gpe_interrupt`
|
||||
* Integer
|
||||
* The bit in GPE (SCI) used to notify about a change on the KCS.
|
||||
|
||||
|
||||
[IPMI]: https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
|
@@ -1,105 +0,0 @@
|
||||
# coreboot architecture
|
||||
|
||||
## Overwiew
|
||||
![][architecture]
|
||||
|
||||
[architecture]: comparision_coreboot_uefi.svg
|
||||
|
||||
## Stages
|
||||
coreboot consists of multiple stages that are compiled as separate binaries and
|
||||
are inserted into the CBFS with custom compression. The bootblock usually doesn't
|
||||
have compression while the ramstage and payload are compressed with LZMA.
|
||||
|
||||
Each stage loads the next stage a given address (possibly decompressing it).
|
||||
|
||||
Some stages are relocatable and can be placed anywhere in DRAM. Those stages are
|
||||
usually cached in CBMEM for faster loading times on ACPI S3 resume.
|
||||
|
||||
Supported stage compressions:
|
||||
* none
|
||||
* LZ4
|
||||
* LZMA
|
||||
|
||||
## bootblock
|
||||
The bootblock is the first stage executed after CPU reset. It is written in
|
||||
assembly language and its main task is to set up everything for a C-environment:
|
||||
|
||||
Common tasks:
|
||||
|
||||
* Cache-As-RAM for heap and stack
|
||||
* Set stack pointer
|
||||
* Clear memory for BSS
|
||||
* Decompress and load the next stage
|
||||
|
||||
On x86 platforms that includes:
|
||||
|
||||
* Microcode updates
|
||||
* Timer init
|
||||
* Switching from 16-bit real-mode to 32-bit protected mode
|
||||
|
||||
The bootblock loads the romstage or the verstage if verified boot is enabled.
|
||||
|
||||
### Cache-As-Ram
|
||||
The *Cache-As-Ram*, also called Non-Eviction mode, or *CAR* allows to use the
|
||||
CPU cache like regular SRAM. This is particullary usefull for high level
|
||||
languages like `C`, which need RAM for heap and stack.
|
||||
|
||||
The CAR needs to be activated using vendor specific CPU instructions.
|
||||
|
||||
The following stages run when Cache-As-Ram is active:
|
||||
* bootblock
|
||||
* romstage
|
||||
* verstage
|
||||
* postcar
|
||||
|
||||
## verstage
|
||||
The verstage is where the root-of-trust starts. It's assumed that
|
||||
it cannot be overwritten in-field (together with the public key) and
|
||||
it starts at the very beginning of the boot process.
|
||||
The verstage installs a hook to verify a file before it's loaded from
|
||||
CBFS or a partition before it's accessed.
|
||||
|
||||
The verified boot mechanism allows trusted in-field firmware updates
|
||||
combined with a fail-safe recovery mode.
|
||||
|
||||
## romstage
|
||||
The romstage initializes the DRAM and prepares everything for device init.
|
||||
|
||||
Common tasks:
|
||||
|
||||
* Early device init
|
||||
* DRAM init
|
||||
|
||||
## postcar
|
||||
To leave the CAR setup and run code from regular DRAM the postcar-stage tears
|
||||
down CAR and loads the ramstage. Compared to other stages it's minimal in size.
|
||||
|
||||
## ramstage
|
||||
|
||||
The ramstage does the main device init:
|
||||
|
||||
* PCI device init
|
||||
* On-chip device init
|
||||
* TPM init (if not done by verstage)
|
||||
* Graphics init (optional)
|
||||
* CPU init (like set up SMM)
|
||||
|
||||
After initialization tables are written to inform the payload or operating system
|
||||
about the current hardware existance and state. That includes:
|
||||
|
||||
* ACPI tables (x86 specific)
|
||||
* SMBIOS tables (x86 specific)
|
||||
* coreboot tables
|
||||
* devicetree updates (ARM specific)
|
||||
|
||||
It also does hardware and firmware lockdown:
|
||||
* Write-protection of boot media
|
||||
* Lock security related registers
|
||||
* Lock SMM mode (x86 specific)
|
||||
|
||||
## payload
|
||||
The payload is the software that is run after coreboot is done. It resides in
|
||||
the CBFS and there's no possibility to choose it at runtime.
|
||||
|
||||
For more details have a look at [payloads](../payloads.md).
|
||||
|
@@ -1,176 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
|
||||
<svg width="55cm" height="28cm" viewBox="62 37 1088 559" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="63.296" y="74.0258" width="1085.8" height="520.893"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="63.296" y="74.0258" width="1085.8" height="520.893"/>
|
||||
</g>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 4; stroke: #000000" x1="242.613" y1="107.463" x2="242.698" y2="492.591"/>
|
||||
<g>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 4; stroke: #000000" x1="234.964" y1="477.053" x2="1135.15" y2="478.109"/>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 4; stroke: #000000" points="1124.61,485.597 1139.62,478.114 1124.63,470.597 "/>
|
||||
</g>
|
||||
<text font-size="22.5778" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="482.342" y="58.1574">
|
||||
<tspan x="482.342" y="58.1574">Platform Initialization Firmware Phases</tspan>
|
||||
</text>
|
||||
<text font-size="16.9333" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="98.4514" y="435.714">
|
||||
<tspan x="98.4514" y="435.714">EDK II - stages</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="1073.49" y="499.998">
|
||||
<tspan x="1073.49" y="499.998">time</tspan>
|
||||
</text>
|
||||
<text font-size="16.9333" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="82.8266" y="330.476">
|
||||
<tspan x="82.8266" y="330.476">coreboot - stages</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #faff94" x="250.501" y="404.247" width="130.432" height="69.1471"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="250.501" y="404.247" width="130.432" height="69.1471"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="315.718" y="434.72">
|
||||
<tspan x="315.718" y="434.72">Security</tspan>
|
||||
<tspan x="315.718" y="450.72">(SEC)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #faff94" x="383.033" y="404.781" width="282.702" height="69"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="383.033" y="404.781" width="282.702" height="69"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="524.384" y="427.181">
|
||||
<tspan x="524.384" y="427.181">Pre-EFI</tspan>
|
||||
<tspan x="524.384" y="443.181">Initialization Environment</tspan>
|
||||
<tspan x="524.384" y="459.181">(PEI)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #faff94" x="668.027" y="405.317" width="269.244" height="69"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="668.027" y="405.317" width="269.244" height="69"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="802.649" y="427.717">
|
||||
<tspan x="802.649" y="427.717">Driver Execution</tspan>
|
||||
<tspan x="802.649" y="443.717">Environment</tspan>
|
||||
<tspan x="802.649" y="459.717">(DXE)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #faff94" x="939.541" y="405.727" width="178.75" height="69"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="939.541" y="405.727" width="178.75" height="69"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="1028.92" y="436.127">
|
||||
<tspan x="1028.92" y="436.127">Boot Device Selection</tspan>
|
||||
<tspan x="1028.92" y="452.127">(BDS)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="254.747" y="291.309" width="125.314" height="69.1471"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="254.747" y="291.309" width="125.314" height="69.1471"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="317.404" y="329.782">
|
||||
<tspan x="317.404" y="329.782">bootblock</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="476.354" y="290.735" width="89.65" height="69.1471"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="476.354" y="290.735" width="89.65" height="69.1471"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="521.179" y="329.209">
|
||||
<tspan x="521.179" y="329.209">romstage</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="382.317" y="291.011" width="92.1" height="69.1471"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="382.317" y="291.011" width="92.1" height="69.1471"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="428.367" y="321.485">
|
||||
<tspan x="428.367" y="321.485">verstage</tspan>
|
||||
<tspan x="428.367" y="337.485">(optional)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="567.853" y="290.99" width="98.5152" height="69.1471"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="567.853" y="290.99" width="98.5152" height="69.1471"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="617.11" y="321.464">
|
||||
<tspan x="617.11" y="321.464">postcar</tspan>
|
||||
<tspan x="617.11" y="337.464">(x86 only)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="667.529" y="281.527" width="168.747" height="37"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="667.529" y="281.527" width="168.747" height="37"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="751.903" y="303.927">
|
||||
<tspan x="751.903" y="303.927">ramstage</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="667.84" y="321.487" width="167.519" height="53"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="667.84" y="321.487" width="167.519" height="53"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="751.6" y="343.887">
|
||||
<tspan x="751.6" y="343.887">SMM</tspan>
|
||||
<tspan x="751.6" y="359.887">(x86 only)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="941.841" y="283.151" width="171.98" height="69.1471"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="941.841" y="283.151" width="171.98" height="69.1471"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="1027.83" y="321.624">
|
||||
<tspan x="1027.83" y="321.624">payload</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #d8e5e5" x="253.112" y="209.178" width="82.7" height="27"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="253.112" y="209.178" width="82.7" height="27"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="294.462" y="226.578">
|
||||
<tspan x="294.462" y="226.578">Assembly</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00c800" x="318.155" y="129.267" width="283.43" height="27"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="318.155" y="129.267" width="283.43" height="27"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="459.87" y="146.667">
|
||||
<tspan x="459.87" y="146.667">Cache-As-RAM</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ff8484" x="506.676" y="159.67" width="599.421" height="27"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="506.676" y="159.67" width="599.421" height="27"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="806.387" y="177.07">
|
||||
<tspan x="806.387" y="177.07">DRAM</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="175.046" y1="392.926" x2="1113.82" y2="391.893"/>
|
||||
<text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="387.045" y="241.637">
|
||||
<tspan x="387.045" y="241.637"></tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="337.438" y="209.383" width="618.831" height="27"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="337.438" y="209.383" width="618.831" height="27"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="646.853" y="226.783">
|
||||
<tspan x="646.853" y="226.783">C</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #f6c7c7" x="667.35" y="238.912" width="170.3" height="27"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="667.35" y="238.912" width="170.3" height="27"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="752.5" y="256.312">
|
||||
<tspan x="752.5" y="256.312">ADA SPARK (x86 only)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text font-size="16.9333" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="84.2481" y="233.28">
|
||||
<tspan x="84.2481" y="233.28">coreboot</tspan>
|
||||
<tspan x="84.2481" y="254.446">source languages</tspan>
|
||||
</text>
|
||||
<text font-size="16.9333" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="86.5008" y="153.786">
|
||||
<tspan x="86.5008" y="153.786">code/heap</tspan>
|
||||
<tspan x="86.5008" y="174.953">memory location </tspan>
|
||||
</text>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="175.483" y1="273.35" x2="1109.07" y2="273.582"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="176.24" y1="192.463" x2="1109.66" y2="192.132"/>
|
||||
<g>
|
||||
<rect style="fill: #90c9ff" x="838.583" y="281.963" width="100.3" height="53"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" x="838.583" y="281.963" width="100.3" height="53"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="888.733" y="304.363">
|
||||
<tspan x="888.733" y="304.363">BL31</tspan>
|
||||
<tspan x="888.733" y="320.363">(ARM only)</tspan>
|
||||
</text>
|
||||
</g>
|
||||
<text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="209.772" y="508.772">
|
||||
<tspan x="209.772" y="508.772">Power on</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="941.939" y="210.26" width="22.4641" height="25.1384"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ffffff" x="941.939" y="210.26" width="22.4641" height="25.1384"/>
|
||||
</g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" d="M 955.029 209.941 C 967.678,210.1 946.349,230.772 955.598,237.021"/>
|
||||
</svg>
|
Before Width: | Height: | Size: 12 KiB |
@@ -1,6 +1,5 @@
|
||||
# Getting Started
|
||||
|
||||
* [coreboot architecture](architecture.md)
|
||||
* [Build System](build_system.md)
|
||||
* [Submodules](submodules.md)
|
||||
* [Kconfig](kconfig.md)
|
||||
|
@@ -1132,7 +1132,7 @@ the symbol is only inside of an if/endif block where the if expression evaluates
|
||||
as false, the symbol STILL gets defined in the config.h file (though not in the
|
||||
.config file).
|
||||
|
||||
Use \#if CONFIG(SYMBOL) to be sure (it returns false for undefined symbols
|
||||
Use \#if IS_ENABLED(CONFIG_*) to be sure (it returns false for undefined symbols
|
||||
and defined-to-0 symbols alike).
|
||||
|
||||
|
||||
@@ -1165,6 +1165,8 @@ saved .config file. As always, a 'select' statement overrides any specified
|
||||
- coreboot has added the glob operator '*' for the 'source' keyword.
|
||||
- coreboot’s Kconfig always defines variables except for strings. In other
|
||||
Kconfig implementations, bools set to false/0/no are not defined.
|
||||
- IS_ENABLED() is ‘false’ for undefined variables and ‘0’ variables. In Linux
|
||||
(where the macro comes from) it’s ‘true’ as soon as the variable is defined.
|
||||
- coreboot’s version of Kconfig adds the KCONFIG_STRICT environment variable to
|
||||
error out if there are any issues in the Kconfig files. In the Linux kernel,
|
||||
Kconfig will generate a warning, but will still output an updated .config or
|
||||
|
@@ -100,25 +100,11 @@ If you do only reference the document, but do not include it in any toctree,
|
||||
you'll see the following warning:
|
||||
**WARNING: document isn't included in any toctree**
|
||||
|
||||
## CSV
|
||||
|
||||
You can import CSV files and let sphinx automatically convert them to human
|
||||
readable tables, using the following reStructuredText snipped:
|
||||
|
||||
```eval_rst
|
||||
.. csv-table::
|
||||
:header: "Key", "Value"
|
||||
:file: keyvalues.csv
|
||||
```
|
||||
|
||||
Of course this can only be done from a markdown file that is included in the
|
||||
TOC tree.
|
||||
|
||||
[coreboot]: https://coreboot.org
|
||||
[Documentation]: https://review.coreboot.org/cgit/coreboot.git/tree/Documentation
|
||||
[shpinx-autobuild]: https://github.com/GaretJax/sphinx-autobuild
|
||||
[guide]: http://www.sphinx-doc.org/en/stable/install.html
|
||||
[Sphinx]: http://www.sphinx-doc.org/en/master/
|
||||
[Markdown Guide]: https://www.markdownguide.org/
|
||||
[Gerrit Guidelines]: gerrit_guidelines.md
|
||||
[Gerrit Guidelines]: https://doc.coreboot.org/gerrit_guidelines.html
|
||||
[review.coreboot.org]: https://review.coreboot.org
|
||||
|
@@ -1,64 +0,0 @@
|
||||
Display Panel Specifics
|
||||
=======================
|
||||
|
||||
Timing Parameters
|
||||
-----------------
|
||||
|
||||
From the binary file `edid` in the sys filesystem on Linux, the panel can be
|
||||
identified. The exact path may differ slightly. Here is an example:
|
||||
|
||||
```sh
|
||||
$ strings /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/edid
|
||||
@0 5
|
||||
LG Display
|
||||
LP140WF3-SPD1
|
||||
```
|
||||
|
||||
To figure out the timing parameters, refer to the [Intel Programmer's Reference
|
||||
Manuals](https://01.org/linuxgraphics/documentation/hardware-specification-prms)
|
||||
and try to find the datasheet of the panel using the information from `edid`.
|
||||
In the example above, you would search for `LP140WF3-SPD1`. Find a table listing
|
||||
the power sequence timing parameters, which are usually named T[N] and also
|
||||
referenced in Intel's respective registers listing. You need the values for
|
||||
`PP_ON_DELAYS`, `PP_OFF_DELAYS` and `PP_DIVISOR` for your `devicetree.cb`:
|
||||
|
||||
```eval_rst
|
||||
+-----------------------------+---------------------------------------+-----+
|
||||
| Intel docs | devicetree.cb | eDP |
|
||||
+-----------------------------+---------------------------------------+-----+
|
||||
| Power up delay | `gpu_panel_power_up_delay` | T3 |
|
||||
+-----------------------------+---------------------------------------+-----+
|
||||
| Power on to backlight on | `gpu_panel_power_backlight_on_delay` | T7 |
|
||||
+-----------------------------+---------------------------------------+-----+
|
||||
| Power Down delay | `gpu_panel_power_down_delay` | T10 |
|
||||
+-----------------------------+---------------------------------------+-----+
|
||||
| Backlight off to power down | `gpu_panel_power_backlight_off_delay` | T9 |
|
||||
+-----------------------------+---------------------------------------+-----+
|
||||
| Power Cycle Delay | `gpu_panel_power_cycle_delay` | T12 |
|
||||
+-----------------------------+---------------------------------------+-----+
|
||||
```
|
||||
|
||||
Intel GPU Tools and VBT
|
||||
-----------------------
|
||||
|
||||
The Intel GPU tools are in a package called either `intel-gpu-tools` or
|
||||
`igt-gpu-tools` in most distributions of Linux-based operating systems.
|
||||
In the coreboot `util/` directory, you can find `intelvbttool`.
|
||||
|
||||
From a running system, you can dump the register values directly:
|
||||
```sh
|
||||
$ intel_reg dump --all | grep PCH_PP
|
||||
PCH_PP_STATUS (0x000c7200): 0x80000008
|
||||
PCH_PP_CONTROL (0x000c7204): 0x00000007
|
||||
PCH_PP_ON_DELAYS (0x000c7208): 0x07d00001
|
||||
PCH_PP_OFF_DELAYS (0x000c720c): 0x01f40001
|
||||
PCH_PP_DIVISOR (0x000c7210): 0x0004af06
|
||||
```
|
||||
|
||||
You can obtain the timing values from a VBT (Video BIOS Table), which you can
|
||||
dump from a vendor UEFI image:
|
||||
```sh
|
||||
$ intel_vbt_decode data.vbt | grep T3
|
||||
Power Sequence: T3 2000 T7 10 T9 2000 T10 500 T12 5000
|
||||
T3 optimization: no
|
||||
```
|
@@ -48,16 +48,13 @@ follows:
|
||||
|
||||
* `lightup_ok`: returns whether the initialization succeeded `1` or
|
||||
failed `0`. Currently, only the case that no display
|
||||
could be found counts as failure. A failure at a
|
||||
later stage (e.g. failure to train a DP) is not
|
||||
propagated.
|
||||
could be found counts as failure. A failure at a la-
|
||||
ter stage (e.g. failure to train a DP) is not propa-
|
||||
gated.
|
||||
|
||||
GMA: Per Board Configuration
|
||||
----------------------------
|
||||
|
||||
In order to set up the display panel, see the
|
||||
[display panel-specific documentation](/gfx/display-panel.md).
|
||||
|
||||
There are a few Kconfig symbols to consider. To indicate that a
|
||||
board can initialize graphics through *libgfxinit*:
|
||||
|
||||
|
@@ -167,21 +167,20 @@ Contents:
|
||||
* [Code of Conduct](community/code_of_conduct.md)
|
||||
* [Community forums](community/forums.md)
|
||||
* [coreboot at conferences](community/conferences.md)
|
||||
* [Security](security.md)
|
||||
* [Payloads](payloads.md)
|
||||
* [Distributions](distributions.md)
|
||||
* [Timestamps](timestamp.md)
|
||||
* [Intel IFD Binary Extraction](Binary_Extraction.md)
|
||||
* [Dealing with Untrusted Input in SMM](technotes/2017-02-dealing-with-untrusted-input-in-smm.md)
|
||||
* [ABI data consumption](abi-data-consumption.md)
|
||||
* [GPIO toggling in ACPI AML](acpi/gpio.md)
|
||||
* [Native Graphics Initialization with libgfxinit](gfx/libgfxinit.md)
|
||||
* [Display panel-specific documentation](gfx/display-panel.md)
|
||||
* [Architecture-specific documentation](arch/index.md)
|
||||
* [Platform independend drivers documentation](drivers/index.md)
|
||||
* [Northbridge-specific documentation](northbridge/index.md)
|
||||
* [System on Chip-specific documentation](soc/index.md)
|
||||
* [Mainboard-specific documentation](mainboard/index.md)
|
||||
* [Payload-specific documentation](lib/payloads/index.md)
|
||||
* [Library-specific documentation](lib/index.md)
|
||||
* [Security](security/index.md)
|
||||
* [SuperIO-specific documentation](superio/index.md)
|
||||
* [Vendorcode-specific documentation](vendorcode/index.md)
|
||||
* [Utilities](util.md)
|
||||
|
@@ -1,5 +1,5 @@
|
||||
coreboot Lesson 1: Starting from scratch
|
||||
========================================
|
||||
coreboot lesson 1 - Starting from scratch
|
||||
=========================================
|
||||
|
||||
From a fresh Ubuntu 16.04 or 18.04 install, here are all the steps required for
|
||||
a very basic build:
|
||||
|
@@ -5,10 +5,10 @@
|
||||
If you already have an account, skip to Part 2.
|
||||
|
||||
Otherwise, go to <https://review.coreboot.org> in your preferred web browser.
|
||||
Select **Sign in** in the upper right corner.
|
||||
Select **Register** 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
|
||||
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).
|
||||
|
||||
@@ -17,7 +17,7 @@ sign-in with. (ex. your Google username).
|
||||
If you prefer to use an HTTP password instead, skip to Part 2b.
|
||||
|
||||
For the most up-to-date instructions on how to set up SSH keys with Gerrit go to
|
||||
<https://gerrit-documentation.storage.googleapis.com/Documentation/2.14.2/user-upload.html#configure_ssh>
|
||||
<https://gerrit-documentation.storage.googleapis.com/Documentation/2.14.2/user-upload.html#configure_ssh)>
|
||||
and follow the instructions there. Then, skip to Part 3.
|
||||
|
||||
Additionally, that section of the Web site provides explanation on starting
|
||||
@@ -35,13 +35,13 @@ doing so could overwrite an existing key.
|
||||
In the upper right corner, select your name and click on **Settings**.
|
||||
Select **SSH Public Keys** on the left-hand side.
|
||||
|
||||
In a terminal, run `ssh-keygen` and confirm the default path `.ssh/id_rsa`.
|
||||
In a terminal, run "ssh-keygen" and confirm the default path ".ssh/id_rsa".
|
||||
|
||||
Make a passphrase -- remember this phrase. It will be needed whenever you use
|
||||
this RSA Public Key. **Note:** You might want to use a short password, or
|
||||
forego the password altogether as you will be using it very often.
|
||||
|
||||
Open `id_rsa.pub`, copy all contents and paste into the textbox under
|
||||
Open "id_rsa.pub", copy all contents and paste into the textbox under
|
||||
"Add SSH Public Key" in the https://review.coreboot.org webpage.
|
||||
|
||||
## Part 2b: Setting up an HTTP Password
|
||||
@@ -51,7 +51,7 @@ after you select your name and click on **Settings** on the left-hand side, rath
|
||||
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:
|
||||
the password, and add the following to your $HOME/.netrc file:
|
||||
|
||||
machine review.coreboot.org login YourUserNameHere password YourPasswordHere
|
||||
|
||||
@@ -68,12 +68,8 @@ 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.
|
||||
|
||||
**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.
|
||||
and run the command that appears
|
||||
|
||||
Now is a good time to configure your global git identity, if you haven't
|
||||
already.
|
||||
@@ -91,13 +87,13 @@ and other configurations.
|
||||
|
||||
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:
|
||||
the repository by running 'make lint' in the coreboot directory. Alternatively,
|
||||
if you want to run 'make lint' on a specific directory, run:
|
||||
|
||||
for file in $(git ls-files | grep <filepath>); do \
|
||||
for file in $(git ls-files | grep src/amd/quadcore); do \
|
||||
util/lint/checkpatch.pl --file $file --terse; done
|
||||
|
||||
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.
|
||||
@@ -120,7 +116,7 @@ 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
|
||||
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
|
||||
@@ -134,31 +130,26 @@ 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
|
||||
|
||||
For example,
|
||||
|
||||
cpu/amd/pi/00630F01: Fix checkpatch warnings and errors
|
||||
|
||||
<filepath>: Short description
|
||||
*ex. cpu/amd/pi/00630F01: Fix checkpatch warnings and errors*
|
||||
**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.
|
||||
|
||||
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.
|
||||
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.*
|
||||
|
||||
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
|
||||
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
|
||||
When you are done with your commit, run 'git push' to push your commit to
|
||||
coreboot.org. **Note:** To submit as a draft, use
|
||||
`git push origin HEAD:refs/drafts/master`. Submitting as a draft means that
|
||||
'git push origin HEAD:refs/drafts/master' Submitting as a draft means that
|
||||
your commit will be on coreboot.org, but is only visible to those you add
|
||||
as reviewers.
|
||||
|
||||
@@ -170,37 +161,32 @@ especially if you plan to work on multiple changes at the same time.
|
||||
## Part 4b: Using git cola to stage and submit a commit
|
||||
|
||||
If git cola is not installed on your machine, see
|
||||
<https://git-cola.github.io/downloads.html> for download instructions.
|
||||
https://git-cola.github.io/downloads.html for download instructions.
|
||||
|
||||
After making some edits to src files, rather than run `git add`, run
|
||||
`git cola` from the command line. You should see all of the files
|
||||
After making some edits to src files, rather than run "git add," run
|
||||
'git cola' from the command line. You should see all of the files
|
||||
edited under "Modified".
|
||||
|
||||
In the textbox labeled "Commit summary" provide a brief one-line
|
||||
description of what you changed in the files according to the template
|
||||
below:
|
||||
|
||||
<filepath>: Short description
|
||||
|
||||
For example,
|
||||
|
||||
cpu/amd/pi/00630F01: Fix checkpatch warnings and errors
|
||||
|
||||
<filepath>: Short description
|
||||
*ex. cpu/amd/pi/00630F01: Fix checkpatch warnings and errors*
|
||||
**Note:** It is good practice to use present tense in your descriptions
|
||||
and do not punctuate your short description.
|
||||
|
||||
In the larger text box labeled 'Extended description...' provide 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.
|
||||
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.*
|
||||
|
||||
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
|
||||
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
|
||||
@@ -226,30 +212,30 @@ Note: Be sure to add any other changes that haven't already been
|
||||
explained in the extended description.
|
||||
|
||||
When ready, select 'Commit' again. Once all errors have been satisfied
|
||||
and the commit succeeds, move to the command line and run `git push`.
|
||||
**Note:** To submit as a draft, use `git push origin HEAD:refs/drafts/master`.
|
||||
and the commit succeeds, move to the command line and run 'git push'.
|
||||
**Note:** To submit as a draft, use 'git push origin HEAD:refs/drafts/master'
|
||||
Submitting as a draft means that your commit will be on coreboot.org, but is
|
||||
only visible to those you add as reviewers.
|
||||
|
||||
## Part 5: Getting your commit reviewed
|
||||
|
||||
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
|
||||
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
|
||||
to receive a +2.**Note:** A +1 and a +1 does not make a +2. Only certain users
|
||||
can give a +2.
|
||||
|
||||
## Part 6 (optional): bash-git-prompt
|
||||
|
||||
To help make it easier to understand the state of the git repository
|
||||
without running `git status` or `git log`, there is a way to make the
|
||||
without running 'git status' or 'git log', there is a way to make the
|
||||
command line show the status of the repository at every point. This
|
||||
is through bash-git-prompt.
|
||||
|
||||
Instructions for installing this are found at:
|
||||
<https://github.com/magicmonty/bash-git-prompt>.
|
||||
https://github.com/magicmonty/bash-git-prompt
|
||||
**Note:** Feel free to search for different versions of git prompt,
|
||||
as this one is specific to bash.
|
||||
|
||||
@@ -262,7 +248,7 @@ Run the following two commands in the command line:
|
||||
**Note:** cd will change your directory to your home directory, so the
|
||||
git clone command will be run there.
|
||||
|
||||
Finally, open the `~/.bashrc` file and append the following two lines:
|
||||
Finally, open the ~/.bashrc file and append the following two lines:
|
||||
|
||||
GIT_PROMPT_ONLY_IN_REPO=1
|
||||
source ~/.bash-git-prompt/gitprompt.sh
|
||||
@@ -272,7 +258,7 @@ 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
|
||||
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.
|
||||
@@ -285,7 +271,7 @@ 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
|
||||
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
|
||||
|
@@ -1,153 +0,0 @@
|
||||
# Flashmap and Flashmap Descriptor in coreboot
|
||||
|
||||
## Flashmap
|
||||
|
||||
[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 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.
|
||||
|
||||
Flashmap partitions the image into clearly delimited sections and some of those
|
||||
sections may be CBFSes that can hold arbitrary-length files (at least one, the
|
||||
default CBFS, called `COREBOOT`). General guidance is that everything with
|
||||
strict layout requirements (e.g. must be aligned to erase blocks or
|
||||
something else) should have its own Flashmap section, and everything else should
|
||||
normally go into CBFS.
|
||||
|
||||
The Flashmap itself starts with a header `struct fmap` and followed by a list of
|
||||
section descriptions in `strcut fmap_area`.
|
||||
|
||||
### Header
|
||||
The header `struct fmap` has following fields:
|
||||
* `signature`: 8 characters as `"__FMAP__"`.
|
||||
* `ver_major`: one byte for major version (currently only 1).
|
||||
* `ver_minor`: one byte for minor version (current value is 1).
|
||||
* `base`: 64 bit integer for the address of the firmware binary.
|
||||
* `size`: 32 bit integer for the size of firmware binary in bytes.
|
||||
* `name`: 32 characters for the name of the firmware binary.
|
||||
* `nareas`: 16 bit integer for the number of area definitions (i.e., how many
|
||||
sections are in this firmware image) following the header.
|
||||
|
||||
### Area Definition
|
||||
The section is defined by `struct fmap_area` with following fields:
|
||||
* `offset`: 32 bit integer for where the area starts (relative to `base` in
|
||||
header).
|
||||
* `size`: 32 bit integer for the size of area in bytes.
|
||||
* `name`: 32 characters for a descriptive name of this area. Should be unique to
|
||||
all sections inside same Flashmap.
|
||||
* `flags`: 16 bit integer for attributes of this area (see below).
|
||||
|
||||
### Area Flags
|
||||
Currently the defined values for `flags` in `struct fmap_area` are:
|
||||
* `FMAP_AREA_PRESERVE`: suggesting the section should be preserved when
|
||||
updating firmware, usually for product data like serial number, MAC address,
|
||||
or calibration and cache data.
|
||||
* `FMAP_AREA_STATIC`: Not really used today.
|
||||
* `FMAP_AREA_COMPRESSED`: Not really used today.
|
||||
* `FMAP_AREA_RO`: Not really used today.
|
||||
|
||||
### FMAP section
|
||||
The whole Flashmap (`struct fmap` and list of `struct fmap_area`) should be
|
||||
stored in a standalone section named as `FMAP` (which should be also described
|
||||
by the Flashmap itself in `struct fmap_area`). There's no restriction for where
|
||||
it should be located (or how large), but usually we need to do a linear or
|
||||
binary search on whole firmware binary image to find Flashmap so a properly
|
||||
aligned address would be better.
|
||||
|
||||
### COREBOOT section
|
||||
coreboot firmware images (`coreboot.rom`) should have at least one Flashmap
|
||||
section that is reserved for CBFS. Usually it is named as `COREBOOT`.
|
||||
|
||||
## Flashmap Descriptor
|
||||
|
||||
Since coreboot is starting to use a "partition" of Flashmap to describe the
|
||||
flash chip layout (both at runtime and when flashing a new image onto a
|
||||
chip), the project needs a reasonably expressive plain text format for
|
||||
representing such sections in the source tree.
|
||||
|
||||
Flashmap Descriptor (FMD) is a [language and
|
||||
compiler](https://chromium-review.googlesource.com/#/c/255031) inside coreboot
|
||||
utility folder that can be used to generate final firmware images (i.e.
|
||||
`coreboot.rom`) formatted by Flashmap.
|
||||
|
||||
The FMD implementation is in coreboot `utils/cbfstool` folder. Here's an
|
||||
informal language description:
|
||||
|
||||
```
|
||||
# <line comment>
|
||||
<image name>[@<memory-mapped address>] <image size> {
|
||||
<section name>[(flags)][@<offset from start of image>] [<section size>] [{
|
||||
<subsection name>[@<offset from start of parent section>] [<subsection size>] [{
|
||||
# Sections can be nested as deeply as desired
|
||||
<subsubsection name>[(flags)][@...] [...] [{...}]
|
||||
}]
|
||||
[<subsection name>[(flags)][@...] [...] [{...}]]
|
||||
# There can be many subsections at each level of nesting: they will be inserted
|
||||
# sequentially, and although gaps are allowed, any provided offsets are always
|
||||
# relative to the closest parent node's and must be strictly increasing with neither
|
||||
# overlapping nor degenerate-size sections.
|
||||
}]
|
||||
}
|
||||
```
|
||||
|
||||
Note that the above example contains a few symbols that are actually meta
|
||||
syntax, and therefore have neither meaning nor place in a real file. The `<.*>`s
|
||||
indicate placeholders for parameters:
|
||||
|
||||
* The names are strings, which are provided as single-word (no white space)
|
||||
groups of syntactically unimportant symbols (i.e. every thing except `@`, `{`,
|
||||
and `}`): they are not surrounded by quotes or any other form of delimiter.
|
||||
* The other fields are non-negative integers, which may be given as decimal or
|
||||
hexadecimal; in either case, a `K`, `M`, or `G` may be appended (without
|
||||
intermediate white space) as a multiplier.
|
||||
* Comments consist of anything one manages to enter, provided it doesn't start a
|
||||
new line.
|
||||
|
||||
The `[.*]`s indicate that a portion of the file could be omitted altogether:
|
||||
|
||||
* Just because something is noted as optional doesn't mean it is in every case:
|
||||
the answer might actually depend on which other information is---or
|
||||
isn't---provided.
|
||||
* The "flag" specifies the attribute or type for given section. The most
|
||||
important supported flag is "CBFS", which indicates the section will contain
|
||||
a CBFS structure.
|
||||
* In particular, it is only legal to place a (CBFS) flag on a leaf section; that
|
||||
is, choosing to add child sections excludes the possibility of putting a CBFS
|
||||
in their parent. Such flags are only used to decide where CBFS empty file
|
||||
headers should be created, and do not result in the storage of any additional
|
||||
metadata in the resulting FMAP section.
|
||||
|
||||
Additionally, it's important to note these properties of the overall file and
|
||||
its values:
|
||||
|
||||
* Other than within would-be strings and numbers, white space is ignored. It
|
||||
goes without saying that such power comes with responsibility, which is why
|
||||
this sentence is here.
|
||||
* Although the `section name` must be globally unique, one of them may (but is
|
||||
not required to) match the image name.
|
||||
* It is a syntax error to supply a number (besides 0) that begins with the
|
||||
character `0`, as there is no intention of adding octals to the mix.
|
||||
* The image's memory address should be present on (and only on) layouts for
|
||||
memory-mapped chips.
|
||||
* Although it may be evident from above, all `section` offsets are relative only
|
||||
to the immediate parent. There is no way to include an absolute offset (i.e.
|
||||
from the beginning of flash), which means that it is "safe" to reorder the
|
||||
sections within a particular level of nesting, as long as the change doesn't
|
||||
cause their positions and sizes to necessitate overlap or zero sizes.
|
||||
* A `section` with omitted offset is assumed to start at as low a position as
|
||||
possible (with no consideration of alignment) and one with omitted size is
|
||||
assumed to fill the remaining space until the next sibling or before the end
|
||||
of its parent.
|
||||
* It's fine to omit any `section`'s offset, size, or both, provided its position
|
||||
and size are still unambiguous in the context of its *sibling* sections and
|
||||
its parent's *size*. In particular, knowledge of one .*section 's children or
|
||||
the `section`s' common parent's siblings will not be used for this purpose.
|
||||
* Although `section`s are not required to have children, the flash chip as a
|
||||
whole must have at least one.
|
||||
* Though the braces after `section`s may be omitted for those that have no
|
||||
children, if they are present, they must contain at least one child.
|
||||
|
||||
To see the formal description of the language, please refer to the Lex and Yacc
|
||||
files: `fmd_scanner.l` and `fmd_scanner.y`.
|
@@ -1,9 +0,0 @@
|
||||
# Library-specific documentation
|
||||
|
||||
This section contains documentation about coreboot internal technical
|
||||
information and libraries.
|
||||
|
||||
## Structure and layout
|
||||
- [Flashmap and Flashmap Descriptor](flashmap.md)
|
||||
- [ABI data consumption](abi-data-consumption.md)
|
||||
- [Timestamps](timestamp.md)
|
@@ -1,136 +0,0 @@
|
||||
# ASRock H110M-DVS
|
||||
|
||||
This page describes how to run coreboot on the [ASRock H110M-DVS].
|
||||
|
||||
## Required proprietary blobs
|
||||
|
||||
Mainboard is based on Intel Skylake/Kaby Lake processor and H110 Chipset.
|
||||
Intel company provides [Firmware Support Package (2.0)](../../soc/intel/fsp/index.md)
|
||||
(intel FSP 2.0) to initialize this generation silicon. Please see this
|
||||
[document](../../soc/intel/code_development_model/code_development_model.md).
|
||||
|
||||
FSP Information:
|
||||
|
||||
```eval_rst
|
||||
+-----------------------------+-------------------+-------------------+
|
||||
| FSP Project Name | Directory | Specification |
|
||||
+-----------------------------+-------------------+-------------------+
|
||||
| 7th Generation Intel® Core™ | KabylakeFspBinPkg | 2.0 |
|
||||
| processors and chipsets | | |
|
||||
| (formerly Kaby Lake) | | |
|
||||
+-----------------------------+-------------------+-------------------+
|
||||
```
|
||||
|
||||
## Building coreboot
|
||||
|
||||
The following steps set the default parameters for this board to build a
|
||||
fully working image:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
touch .config
|
||||
./util/scripts/config --enable VENDOR_ASROCK
|
||||
./util/scripts/config --enable BOARD_ASROCK_H110M_DVS
|
||||
./util/scripts/config --enable CONFIG_ADD_FSP_BINARIES
|
||||
./util/scripts/config --enable CONFIG_FSP_USE_REPO
|
||||
./util/scripts/config --set-str REALTEK_8168_MACADDRESS "xx:xx:xx:xx:xx:xx"
|
||||
make olddefconfig
|
||||
```
|
||||
|
||||
However, it is strongly advised to use `make menuconfig` afterwards
|
||||
(or instead), so that you can see all of the settings.
|
||||
|
||||
Use the following command to disable the serial console if debugging
|
||||
output is not required:
|
||||
|
||||
```bash
|
||||
./util/scripts/config --disable CONSOLE_SERIAL
|
||||
```
|
||||
|
||||
However, a more flexible method is to change the console log level from
|
||||
within an OS using `util/nvramtool`, or with the `nvramcui` payload.
|
||||
|
||||
Now, run `make` to build the coreboot image.
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash can be accessed using [flashrom]. By default, only
|
||||
the BIOS region of the flash is writable. If you wish to change any
|
||||
other region, such as the Management Engine or firmware descriptor, then
|
||||
an external programmer is required (unless you find a clever way around
|
||||
the flash protection). More information about this [here](../../flash_tutorial/index.md).
|
||||
|
||||
### External programming
|
||||
|
||||
The flash chip is a 8 MiB socketed DIP-8 chip. Specifically, it's a
|
||||
Macronix MX25L6473E, whose datasheet can be found [here][MX25L6473E].
|
||||
The chip is located to the bottom right-hand side of the board. For
|
||||
a precise location, refer to section 1.3 (Motherboard Layout) of the
|
||||
[H110M-DVS manual], where the chip is labelled "64Mb BIOS". Take note of
|
||||
the chip's orientation, remove it from its socket, and flash it with
|
||||
an external programmer. For reference, the notch in the chip should be
|
||||
facing towards the bottom of the board.
|
||||
|
||||
## Known issues
|
||||
|
||||
- The VGA port doesn't work. Discrete graphic card is used as primary
|
||||
device for display output (if CONFIG_ONBOARD_VGA_IS_PRIMARY is not
|
||||
set). Dynamic switching between iGPU and PEG is not yet supported.
|
||||
|
||||
- SuperIO GPIO pin is used to reset Realtek chip. However, since the
|
||||
Logical Device 7 (GPIO6, GPIO7, GPIO8) is not initialized, the network
|
||||
chip is in a reset state all the time.
|
||||
|
||||
## Untested
|
||||
|
||||
- parallel port
|
||||
- PS/2 keyboard
|
||||
- PS/2 mouse
|
||||
- EHCI debug
|
||||
- TPM
|
||||
- infrared module
|
||||
- chassis intrusion header
|
||||
- chassis speaker header
|
||||
|
||||
## Working
|
||||
|
||||
- integrated graphics init with libgfxinit (see [Known issues](#known-issues))
|
||||
- PCIe x1
|
||||
- PEG x16 Gen3
|
||||
- SATA
|
||||
- USB
|
||||
- serial port
|
||||
- onboard audio
|
||||
- using `me_cleaner`
|
||||
- using `flashrom`
|
||||
|
||||
## TODO
|
||||
|
||||
- NCT6791D GPIOs
|
||||
- onboard network (see [Known issues](#known-issues))
|
||||
- S3 suspend/resume
|
||||
- Wake-on-LAN
|
||||
- hardware monitor
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Skylake/Kaby Lake (LGA1151) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| PCH | Intel Sunrise Point H110 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | Nuvoton NCT6791D |
|
||||
+------------------+--------------------------------------------------+
|
||||
| EC | None |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[ASRock H110M-DVS]: https://www.asrock.com/mb/Intel/H110M-DVS%20R2.0/
|
||||
[MX25L6473E]: http://www.macronix.com/Lists/Datasheet/Attachments/7380/MX25L6473E,%203V,%2064Mb,%20v1.4.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
||||
[H110M-DVS manual]: http://asrock.pc.cdn.bitgravity.com/Manual/H110M-DVS%20R2.0.pdf
|
@@ -1,198 +0,0 @@
|
||||
# ASUS F2A85-M
|
||||
|
||||
This page describes how to run coreboot on the [ASUS F2A85-M].
|
||||
|
||||
## Variants
|
||||
- ASUS F2A85-M - Working
|
||||
- ASUS F2A85-M LE - Working
|
||||
- ASUS F2A85-M PRO - Working
|
||||
- ASUS F2A85-M2 - Working
|
||||
- ASUS F2A85-M/CSM - Unsure if WIP.
|
||||
|
||||
## Technology
|
||||
|
||||
Both "Trinity" and "Richland" desktop processing units are working,
|
||||
the CPU architecture in these CPUs/APUs is [Piledriver],
|
||||
and their GPU is [TeraScale 3] (VLIW4-based).
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| F2A85-M | |
|
||||
+------------------+--------------------------------------------------+
|
||||
| DDR voltage IC | Nuvoton NCT3933U (AUX SMBUS 0x15) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Network | Realtek RTL8111F |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | Integrated into CPU with IMC and GPU (APUs only) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | Hudson-D4 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Sound IC | Realtek ALC887 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | ITE 8603E |
|
||||
+------------------+--------------------------------------------------+
|
||||
| VRM controller | DIGI VRM ASP1106 (Rebranded RT8894A - SMBUS 0x20)|
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| F2A85-M LE | |
|
||||
+------------------+--------------------------------------------------+
|
||||
| DDR voltage IC | Nuvoton NCT3933U (AUX SMBUS 0x15 - unconfirmed) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Network | Realtek RTL8111F |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | Integrated into CPU with IMC and GPU(APUs only) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | Hudson-D4 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Sound IC | Realtek ALC887 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | ITE 8623E |
|
||||
+------------------+--------------------------------------------------+
|
||||
| VRM controller | DIGI VRM ASP1106 (Rebranded RT8894A - SMBUS 0x20)|
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| F2A85-M PRO | |
|
||||
+------------------+--------------------------------------------------+
|
||||
| DDR voltage IC | Nuvoton NCT3933U (?) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Network | Realtek RTL8111F - Not working |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | Integrated into CPU with IMC and GPU(APUs only) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | Hudson-D4 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Sound IC | Realtek ALC887 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | Nuvoton NCT6779D |
|
||||
+------------------+--------------------------------------------------+
|
||||
| VRM controller | DIGI VRM ASP1107 |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | yes |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q64F |
|
||||
+---------------------+------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+------------+
|
||||
| Package | DIP-8 |
|
||||
+---------------------+------------+
|
||||
| Write protection | no |
|
||||
+---------------------+------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash can be accessed using [flashrom].
|
||||
UEFI builds that allow flash chip access:
|
||||
> v5016 is untested, but expected to work as well
|
||||
> v5018
|
||||
> v5103
|
||||
> v5104
|
||||
> v5107
|
||||
> v5202
|
||||
> v6002
|
||||
> v6004
|
||||
> v6102
|
||||
> v6402
|
||||
> v6404 (requires downgrading to v6402 to flash coreboot)
|
||||
> v6501 (requires downgrading to v6402 to flash coreboot)
|
||||
> v6502 (requires downgrading to v6402 to flash coreboot)
|
||||
|
||||
Build v6502, v6501 and v6404 do not allow access to the flash chip.
|
||||
Fortunately it is possible to downgrade build v6502, v6501, v6404 to v6402, with EZFlash.
|
||||
Downgrading is done by downloading build v6402 from ASUS' F2A85-M download page
|
||||
and copying it to (the root directory of) a FAT32 formatted USB flash drive.
|
||||
Enter the EFI setup, switch to advanced mode if necessary,
|
||||
open the 'Tool' tab and select "ASUS EZ Flash 2 Utility".
|
||||
|
||||
## Integrated graphics
|
||||
|
||||
### Option 1: Retrieve the VGA optionrom from the vendor EFI binary by running:
|
||||
|
||||
# dd if=/dev/mem of=vgabios.bin bs=1k count=64 skip=768
|
||||
|
||||
### Option 2: Extract from the vendor binary
|
||||
|
||||
Download the BIOS from the Support section at [ASUS F2A85-M].
|
||||
Using MMTool Aptio (versions 4.5.0 and 5.0.0):
|
||||
- Load image, click on 'Extract tab'
|
||||
- Select the 'export path' and 'link present' options
|
||||
- Choose option ROM '1002,9900' and click on 'Extract'
|
||||
|
||||
This version is usable for all the GPUs.
|
||||
> 1002,9901 Trinity (Radeon HD 7660D)
|
||||
> 1002,9904 Trinity (Radeon HD 7560D)
|
||||
> 1002,990c Richland (Radeon HD 8670D)
|
||||
> 1002,990e Richland (Radeon HD 8570D)
|
||||
> 1002,9991 Trinity (Radeon HD 7540D)
|
||||
> 1002,9993 Trinity (Radeon HD 7480D)
|
||||
> 1002,9996 Richland (Radeon HD 8470D)
|
||||
> 1002,9998 Richland (Radeon HD 8370D)
|
||||
> 1002,999d Richland (Radeon HD 8550D)
|
||||
|
||||
## Known issues
|
||||
|
||||
- buggy USB 3.0 controller (works fine as 2.0 port)
|
||||
- reboot, poweroff, S3 suspend/resume (broken since 4.8.1)
|
||||
|
||||
## Known issues (untested because of non-working ACPI sleep)
|
||||
|
||||
- blink in suspend mode (GP43, program LDN7 F8=23 and blink with F9=2 for 1s blinks)
|
||||
- fix immediate resume after suspend (perhaps PCIe STS needs to be cleared)
|
||||
- fix resume with USB3.0 used (perhaps there is a bug in resume.c)
|
||||
|
||||
## Untested
|
||||
|
||||
- audio over HDMI
|
||||
- IOMMU
|
||||
- PS/2 mouse
|
||||
|
||||
## TODOs
|
||||
|
||||
- manage to use one ATOMBIOS for all the integrated GPUs
|
||||
|
||||
## Working
|
||||
|
||||
- ACPI
|
||||
- CPU frequency scaling
|
||||
- flashrom under coreboot
|
||||
- Gigabit Ethernet
|
||||
- Hardware monitor
|
||||
- Integrated graphics
|
||||
- KVM
|
||||
- Onboard audio
|
||||
- PCIe
|
||||
- PS/2 keyboard
|
||||
- SATA
|
||||
- Serial port
|
||||
- SuperIO based fan control
|
||||
- USB (XHCI is buggy)
|
||||
|
||||
## Extra resources
|
||||
|
||||
- [Board manual]
|
||||
- Flash chip datasheet [W25Q64FV]
|
||||
|
||||
[ASUS F2A85-M]: https://www.asus.com/Motherboards/F2A85M/
|
||||
[Board manual]: https://dlcdnets.asus.com/pub/ASUS/mb/SocketFM2/F2A85-M/E8005_F2A85-M.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
||||
[Piledriver]: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29#APU_lines
|
||||
[TeraScale 3]: https://en.wikipedia.org/wiki/TeraScale_%28microarchitecture%29#TeraScale_3
|
||||
[W25Q64FV]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
|
Before Width: | Height: | Size: 68 KiB |
@@ -1,103 +0,0 @@
|
||||
# ASUS P8H61-M Pro
|
||||
|
||||
This page describes how to run coreboot on the [ASUS P8H61-M Pro].
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | yes |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q32BV |
|
||||
+---------------------+------------+
|
||||
| Size | 4 MiB |
|
||||
+---------------------+------------+
|
||||
| Package | DIP-8 |
|
||||
+---------------------+------------+
|
||||
| Write protection | no |
|
||||
+---------------------+------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
The flash IC is located right next to one of the SATA ports:
|
||||

|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash can be accessed using [flashrom]. By default, only
|
||||
the BIOS region of the flash is writable. If you wish to change any
|
||||
other region (Management Engine or flash descriptor), then an external
|
||||
programmer is required.
|
||||
|
||||
The following command may be used to flash coreboot:
|
||||
|
||||
```
|
||||
$ sudo flashrom --noverify-all --ifd -i bios -p internal -w coreboot.rom
|
||||
```
|
||||
|
||||
The use of `--noverify-all` is required since the Management Engine
|
||||
region is not readable even by the host.
|
||||
|
||||
## Known issues
|
||||
|
||||
- There is no automatic, OS-independent fan control. This is because
|
||||
the super I/O hardware monitor can only obtain valid CPU temperature
|
||||
readings from the PECI agent, whose complete initialisation is not
|
||||
publicly documented. The `coretemp` driver can still be used for
|
||||
accurate CPU temperature readings.
|
||||
|
||||
- me_cleaner breaks LPC bus and attached components!
|
||||
- PS/2 mouse doesn't work
|
||||
|
||||
## Untested
|
||||
|
||||
- parallel port
|
||||
- EHCI debug
|
||||
- S/PDIF audio
|
||||
|
||||
## Working
|
||||
|
||||
- PS/2 keyboard
|
||||
- PCIe graphics
|
||||
- USB
|
||||
- Gigabit Ethernet
|
||||
- Integrated graphics
|
||||
- SATA
|
||||
- Serial port
|
||||
- hardware monitor (see [Known issues](#known-issues) for caveats)
|
||||
- front panel audio
|
||||
- Native raminit (2 x 2GB, DDR3-1333)
|
||||
- Native graphics init (libgfxinit)
|
||||
- Wake-on-LAN
|
||||
- TPM on TPM-header
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | :doc:`../../northbridge/intel/sandybridge/index` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | bd82x6x |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | model_206ax |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | Nuvoton NCT6776 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| EC | None |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Extra resources
|
||||
|
||||
- [Flash chip datasheet][W25Q32BV]
|
||||
|
||||
[ASUS P8H61-M Pro]: https://www.asus.com/Motherboards/P8H61M_Pro/
|
||||
[W25Q32BV]: https://www.winbond.com/resource-files/w25q32bv_revi_100413_wo_automotive.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
Before Width: | Height: | Size: 96 KiB |
@@ -1,168 +0,0 @@
|
||||
# ASUS P8Z77-M Pro
|
||||
|
||||
This page describes how to run coreboot on the [ASUS P8Z77-M Pro]
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+----------------+
|
||||
| Type | Value |
|
||||
+=====================+================+
|
||||
| Socketed flash | yes |
|
||||
+---------------------+----------------+
|
||||
| Model | W25Q64FVA1Q |
|
||||
+---------------------+----------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+----------------+
|
||||
| Package | DIP-8 |
|
||||
+---------------------+----------------+
|
||||
| Write protection | yes |
|
||||
+---------------------+----------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+----------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+----------------+
|
||||
```
|
||||
|
||||
The flash IC is located right next to one of the SATA ports:
|
||||

|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash cannot be written because Asus disables BIOSWE and
|
||||
enables BLE/SMM_BWP flags in BIOS_CNTL for their latest bioses.
|
||||
An external programmer is required. You must flash standalone,
|
||||
flashing in-circuit doesn't work. The flash chip is socketed, so it's
|
||||
easy to remove and reflash.
|
||||
|
||||
## Working
|
||||
|
||||
- PS/2 keyboard with SeaBIOS & Tianocore (in Mint 18.3/19.1)
|
||||
|
||||
- Rear/front headphones connector audio & mic
|
||||
|
||||
- S3 Suspend to RAM (tested with OS installed in a HDD/SSD and also with a
|
||||
Mint 18.3/19.1 LiveUSB pendrive connected to USB3/USB2), but please
|
||||
see [Known issues]
|
||||
|
||||
- USB2 on rear (tested mouse/keyboard plugged there. Also, booting with
|
||||
a Mint 18./19.1 LiveUSB works ok)
|
||||
|
||||
- USB3 (Z77's and Asmedia's works, but please see [Known issues])
|
||||
|
||||
- Gigabit Ethernet (RTL8111F)
|
||||
|
||||
- SATA3, SATA2 and eSATA (tested on all ports, hot-swap and TCG OPAL working)
|
||||
(Blue SATA2) (Blue SATA2) (White SATA3) (Red eSATA SATA3 rear)
|
||||
port 3 port 5 port 1 port 8
|
||||
port 4 port 6 port 2 port 7
|
||||
|
||||
- NVME SSD boot on PCIe-x16/x8/4x slot using Tianocore
|
||||
(tested with M.2-to-PCIe adapter and a M.2 Samsung EVO 970 SSD)
|
||||
|
||||
- CPU Temp sensors (tested PSensor on linux + HWINFO64 on Win10)
|
||||
|
||||
- TPM on TPM-header (tested tpm-tools with Asus TPM 1.2 Infineon SLB9635TT12)
|
||||
|
||||
- Native raminit and also MRC.bin(systemagent-r6.bin) memory initialization
|
||||
(please see [Native raminit compatibility] and [MRC memory compatibility])
|
||||
|
||||
- Integrated graphics with both libgfxinit and the Intel Video BIOS OpROM
|
||||
(VGA/DVI-D/HDMI tested and working)
|
||||
|
||||
- 1x PCIe GPU in PCIe-16x/8x/4x slots (tested using Zotac GeForce GTX
|
||||
750Ti and FirePro W5100 under Mint 18.3/19.1)
|
||||
|
||||
## Known issues
|
||||
|
||||
- The rear's USB3s on bottom (closest to the PCB) have problems booting or
|
||||
being used before the OS loads. For better compatibility, please use
|
||||
the Z77's ones above the Ethernet connector or the Asmedia's top one
|
||||
|
||||
- After S3 suspend, some USB3 connectors on rear seem not to work
|
||||
|
||||
- At the moment, the power led does not blink when entering S3 state
|
||||
|
||||
- Currently, we have not setup the SuperIO's Hardware Monitor (HWM),
|
||||
so only the CPU sensors are reported
|
||||
|
||||
- If you use the MRC.bin, the NVRAM variable gfx_uma_size may be ignored
|
||||
as IGP's UMA could be reconfigured by the blob
|
||||
|
||||
- Using TianoCore + a PCIe GPU under Windows crashes with an
|
||||
ACPI_BIOS_ERROR fatal code, not sure why. Using just the IGP
|
||||
works perfectly
|
||||
|
||||
- Under Windows 10, if you experiment problems with PS/2 devices, change
|
||||
HKLM\SYSTEM\CurrentControlSet\Services\i8042prt->Start from '3' to '1'
|
||||
|
||||
## Untested
|
||||
|
||||
- EHCI debugging
|
||||
- S/PDIF audio
|
||||
- Wake-on-LAN
|
||||
- Serial port
|
||||
|
||||
## Not working
|
||||
|
||||
- PS/2 keyboard in Win10 using Tianocore (please see [Known issues])
|
||||
- PS/2 mouse using Tianocore
|
||||
- PCIe graphics card on Windows and Tianocore (throws critical ACPI_BIOS_ERROR)
|
||||
|
||||
## Native raminit compatibility
|
||||
|
||||
- GSkill F3-2133C10D-16GAB(XMP,1.60v) 2x8GB kit works at 1333Mhz instead
|
||||
of XMP 2133Mhz
|
||||
|
||||
- Team Xtreem TXD38G2133HC9NDC01(XMP,1.50v) 2x4GB kit works at 1600Mhz
|
||||
instead of XMP 2133Mhz
|
||||
|
||||
- Kingston KVR1066D3N7K2/4G(JEDEC,1.50v) 2x4GB kit works at 1066Mhz
|
||||
but the board only detects half its RAM, because those DIMMs have
|
||||
Double Sided(DS) chips and seems only Single Sided(SS) ones are
|
||||
fully detected
|
||||
|
||||
- GSkill F3-10666CL9T2-24GBRL(JEDEC,1.50v) 6x4GB kit (4 DIMMs used)
|
||||
works perfectly at full speed (1333Mhz)
|
||||
|
||||
## MRC memory compatibility
|
||||
|
||||
- GSkill F3-2133C10D-16GAB(XMP,1.60v) 2x8GB kit works at 1333Mhz
|
||||
instead of XMP 2133Mhz
|
||||
|
||||
- Team Xtreem TXD38G2133HC9NDC01(XMP,1.50v) 2x4GB kit works at
|
||||
1600Mhz instead of XMP 2133Mhz
|
||||
|
||||
- Kingston KVR1066D3N7K2/4G(JEDEC,1.50v) 2x4GB kit works at 1066Mhz
|
||||
but the board only detects half its RAM, as those DIMMs have
|
||||
Double Sided(DS) chips and seems only Single Sided(SS) ones are
|
||||
fully detected
|
||||
|
||||
- GSkill F3-10666CL9T2-24GBRL(JEDEC,1.50v) 6x4GB kit (4 DIMMs used)
|
||||
works perfectly at full speed (1333Mhz)
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | :doc:`../../northbridge/intel/sandybridge/index` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | bd82x6x |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | model_206ax |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | Nuvoton NCT6779D |
|
||||
+------------------+--------------------------------------------------+
|
||||
| EC | None |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Extra resources
|
||||
|
||||
- [Flash chip datasheet][W25Q64FVA1Q]
|
||||
|
||||
[ASUS P8Z88-M Pro]: https://www.asus.com/Motherboards/P8Z77M_PRO/
|
||||
[W25Q64FVA1Q]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
@@ -1,83 +0,0 @@
|
||||
# Facebook FBG-1701
|
||||
|
||||
This page describes how to run coreboot on the Facebook FBG1701.
|
||||
|
||||
FBG1701 are assembled with different onboard memory modules:
|
||||
Rev 1.0 Onboard Samsung K4B8G1646D-MYKO memory
|
||||
Rev 1.1 and 1.2 Onboard Micron MT41K512M16HA-125A memory
|
||||
|
||||
Use make menuconfig to configure `onboard memory manufacturer` in Mainboard
|
||||
menu.
|
||||
|
||||
## Required blobs
|
||||
|
||||
This board currently requires:
|
||||
fsp blob 3rdparty/fsp/BraswellFspBinPkg/FspBin/BSWFSP.fd
|
||||
Microcode Intel Braswell cpuid 1046C4 version 410
|
||||
(Used pre-build binary retrieved from Intel site)
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash can be accessed using [flashrom].
|
||||
|
||||
### External programming
|
||||
|
||||
The system has an internal flash chip which is a 8 MiB soldered SOIC-8 chip.
|
||||
This chip is located to the top middle side of the board. It's located
|
||||
between SoC and Q7 connector. Use clip (or solder wires) to program
|
||||
the chip.
|
||||
Specifically, it's a Winbond W25Q64FW (1.8V), whose datasheet can be found
|
||||
[here][W25Q64FW].
|
||||
|
||||
The system has an external flash chip which is a 8 MiB soldered SOIC-8 chip.
|
||||
This chip is located in the middle of carrier board close to the flex cable
|
||||
connection.
|
||||
Specifically, it's a Winbond W25Q64FV (3.3V), whose datasheet can be found
|
||||
[here][W25Q64FV].
|
||||
|
||||
## Known issues
|
||||
|
||||
- None
|
||||
|
||||
## Untested
|
||||
|
||||
- hardware monitor
|
||||
- SDIO
|
||||
- Full Embedded Controller support
|
||||
|
||||
## Working
|
||||
|
||||
- USB
|
||||
- Gigabit Ethernet
|
||||
- integrated graphics
|
||||
- flashrom
|
||||
- external graphics
|
||||
- PCIe
|
||||
- eMMC
|
||||
- SATA
|
||||
- serial port
|
||||
- SMBus
|
||||
- HDA
|
||||
- initialization with FSP MR2
|
||||
- SeaBIOS payload
|
||||
- Embedded Linux (Ubuntu 4.15+)
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| SoC | Intel Atom Processor N3710 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Braswell (N3710) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O, EC | ITE8256 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[W25Q64FW]: https://www.winbond.com/resource-files/w25q64fw%20revn%2005182017%20sfdp.pdf
|
||||
[W25Q64FV]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
@@ -1,82 +0,0 @@
|
||||
# HP EliteBook 8760w
|
||||
|
||||
This page describes how to run coreboot on the [HP EliteBook 8760w].
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q64.V |
|
||||
+---------------------+------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+------------+
|
||||
| Write protection | no |
|
||||
+---------------------+------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+------------+
|
||||
| In circuit flashing | yes |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
## Required proprietary blobs
|
||||
|
||||
- Intel Firmware Descriptor, ME and GbE firmware
|
||||
- EC: please read [EliteBook Series](elitebook_series)
|
||||
|
||||
## Flashing instructions
|
||||
|
||||
HP EliteBook 8760w has an 8MB SOIC-8 flash chip on the bottom of the
|
||||
mainboard. You just need to remove the service cover, and use an SOIC-8
|
||||
clip to read and flash the chip.
|
||||
|
||||

|
||||
|
||||
## Untested
|
||||
|
||||
- dock: serial port, parallel port, ...
|
||||
- TPM
|
||||
- S3 suspend/resume
|
||||
- Gigabit Ethernet
|
||||
|
||||
## Working
|
||||
|
||||
- i7-2630QM, 0+4G+8G+0
|
||||
- i7-3720QM, 8G+8G+8G+8G
|
||||
- Arch Linux boot from SeaBIOS payload
|
||||
- EHCI debug: the port is at the right side, next to the charging port
|
||||
- SATA
|
||||
- eSATA
|
||||
- USB2 and USB3
|
||||
- keyboard, touchpad, trackpad
|
||||
- WLAN
|
||||
- WWAN
|
||||
- EC ACPI
|
||||
- Using `me_cleaner`
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | :doc:`../../northbridge/intel/sandybridge/index` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | bd82x6x |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | model_206ax |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | SMSC LPC47n217 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| EC | SMSC KBC1126 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[HP EliteBook 8760w]: https://support.hp.com/us-en/product/hp-elitebook-8760w-mobile-workstation/5071180
|
Before Width: | Height: | Size: 54 KiB |
@@ -1,111 +0,0 @@
|
||||
# HP EliteBook series
|
||||
|
||||
This document is about HP EliteBook series laptops up to Ivy Bridge era
|
||||
which use SMSC KBC1126 as embedded controller.
|
||||
|
||||
## EC
|
||||
|
||||
SMSC KBC1098/KBC1126 has been used in HP EliteBooks for many generations.
|
||||
They use similar EC firmware that will load other code and data from the
|
||||
SPI flash chip, so we need to put some firmware blobs to the coreboot image.
|
||||
|
||||
The following document takes EliteBook 2760p as an example.
|
||||
|
||||
First, you need to extract the blobs needed by EC firmware using util/kbc1126.
|
||||
You can extract them from your backup firmware image, or firmware update
|
||||
provided by HP with [unar] as follows:
|
||||
|
||||
```bash
|
||||
wget https://ftp.hp.com/pub/softpaq/sp79501-80000/sp79710.exe
|
||||
unar sp79710.exe
|
||||
${COREBOOT_DIR}/util/kbc1126/kbc1126_ec_dump sp79710/Rompaq/68SOU.BIN
|
||||
mv 68SOU.BIN.fw1 ${COREBOOT_DIR}/2760p-fw1.bin
|
||||
mv 68SOU.BIN.fw2 ${COREBOOT_DIR}/2760p-fw2.bin
|
||||
```
|
||||
|
||||
When you config coreboot, select:
|
||||
|
||||
```text
|
||||
Chipset --->
|
||||
[*] Add firmware images for KBC1126 EC
|
||||
(2760p-fw1.bin) KBC1126 firmware #1 path and filename
|
||||
(2760p-fw2.bin) KBC1126 filename #2 path and filename
|
||||
```
|
||||
|
||||
## Super I/O
|
||||
|
||||
EliteBook 8000 series laptops have SMSC LPC47n217 Super I/O to provide
|
||||
a serial port and a parallel port, you can debug the laptop via this
|
||||
serial port.
|
||||
|
||||
## porting
|
||||
|
||||
To port coreboot to an HP EliteBook laptop, you need to do the following:
|
||||
|
||||
- select Kconfig option `EC_HP_KBC1126`
|
||||
- select Kconfig option `SUPERIO_SMSC_LPC47N217` if there is LPC47n217 Super I/O
|
||||
- initialize EC and Super I/O in romstage
|
||||
- add EC and Super I/O support to devicetree.cb
|
||||
|
||||
To get the related values for EC in devicetree.cb, you need to extract the EFI
|
||||
module EcThermalInit from the vendor UEFI firmware with [UEFITool]. Usually,
|
||||
`ec_data_port`, `ec_cmd_port` and `ec_ctrl_reg` has the following values:
|
||||
|
||||
- For xx60 series: 0x60, 0x64, 0xca
|
||||
- For xx70 series: 0x62, 0x66, 0x81
|
||||
|
||||
You can use [radare2] and the following [r2pipe] Python script to find
|
||||
these values from the EcThermalInit EFI module:
|
||||
|
||||
```python
|
||||
#!/usr/bin/env python
|
||||
|
||||
# install radare2 and use `pip3 install --user r2pipe` to install r2pipe
|
||||
|
||||
import r2pipe
|
||||
import sys
|
||||
|
||||
if len(sys.argv) < 2:
|
||||
fn = "ecthermalinit.efi"
|
||||
else:
|
||||
fn = sys.argv[1]
|
||||
|
||||
r2 = r2pipe.open(fn)
|
||||
r2.cmd("aa")
|
||||
entryf = r2.cmdj("pdfj")
|
||||
|
||||
for insn in entryf["ops"]:
|
||||
if "lea r8" in insn["opcode"]:
|
||||
_callback = insn["ptr"]
|
||||
break
|
||||
|
||||
r2.cmd("af @ {}".format(_callback))
|
||||
callbackf_insns = r2.cmdj("pdfj @ {}".format(_callback))["ops"]
|
||||
|
||||
def find_port(addr):
|
||||
ops = r2.cmdj("pdfj @ {}".format(addr))["ops"]
|
||||
for insn in ops:
|
||||
if "lea r8d" in insn["opcode"]:
|
||||
return insn["ptr"]
|
||||
|
||||
ctrl_reg_found = False
|
||||
|
||||
for i in range(0, len(callbackf_insns)):
|
||||
if not ctrl_reg_found and "mov cl" in callbackf_insns[i]["opcode"]:
|
||||
ctrl_reg_found = True
|
||||
ctrl_reg = callbackf_insns[i]["ptr"]
|
||||
print("ec_ctrl_reg = 0x%02x" % ctrl_reg)
|
||||
cmd_port = find_port(callbackf_insns[i+1]["jump"])
|
||||
data_port = find_port(callbackf_insns[i+3]["jump"])
|
||||
print("ec_cmd_port = 0x%02x\nec_data_port = 0x%02x" % (cmd_port, data_port))
|
||||
|
||||
if "mov bl" in callbackf_insns[i]["opcode"]:
|
||||
ctrl_value = callbackf_insns[i]["ptr"]
|
||||
print("ec_fan_ctrl_value = 0x%02x" % ctrl_value)
|
||||
```
|
||||
|
||||
|
||||
[unar]: https://theunarchiver.com/command-line
|
||||
[UEFITool]: https://github.com/LongSoft/UEFITool
|
||||
[radare2]: https://radare.org/
|
||||
[r2pipe]: https://github.com/radare/radare2-r2pipe
|
@@ -1,70 +0,0 @@
|
||||
# HP Z220 SFF Workstation
|
||||
|
||||
This page describes how to run coreboot on the [HP Z220 SFF Workstation] desktop
|
||||
from [HP].
|
||||
|
||||
## TODO
|
||||
|
||||
The following things are still missing from this coreboot port:
|
||||
|
||||
- Extended HWM reporting
|
||||
- Advanced LED control
|
||||
- Advanced power configuration in S3
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+-------------+
|
||||
| Type | Value |
|
||||
+=====================+=============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+-------------+
|
||||
| Model | N25Q128..3E |
|
||||
+---------------------+-------------+
|
||||
| Size | 16 MiB |
|
||||
+---------------------+-------------+
|
||||
| In circuit flashing | yes |
|
||||
+---------------------+-------------+
|
||||
| Package | SOIC-16 |
|
||||
+---------------------+-------------+
|
||||
| Write protection | No |
|
||||
+---------------------+-------------+
|
||||
| Dual BIOS feature | No |
|
||||
+---------------------+-------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+-------------+
|
||||
```
|
||||
|
||||
### Internal programming
|
||||
|
||||
The SPI flash can be accessed using [flashrom].
|
||||
|
||||
### External programming
|
||||
|
||||
External programming with an SPI adapter and [flashrom] does work, but it powers the
|
||||
whole southbridge complex. You need to supply enough current through the programming adapter.
|
||||
|
||||
If you want to use a SOIC pomona test clip, you have to cut the 2nd DRAM DIMM holder,
|
||||
as otherwise there's not enough space near the flash.
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | :doc:`../../northbridge/intel/sandybridge/index` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | bd82x6x |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | model_206ax |
|
||||
+------------------+--------------------------------------------------+
|
||||
| SuperIO | :doc:`../../superio/nuvoton/npcd378` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| EC | |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel ME |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[HP Z220 SFF Workstation]: https://support.hp.com/za-en/document/c03386950
|
||||
[HP]: https://www.hp.com/
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
@@ -4,15 +4,11 @@ This section contains documentation about coreboot on specific mainboards.
|
||||
|
||||
## ASUS
|
||||
|
||||
- [F2A85-M](asus/f2a85-m.md)
|
||||
- [P8H61-M LX](asus/p8h61-m_lx.md)
|
||||
- [P8H61-M Pro](asus/p8h61-m_pro.md)
|
||||
- [P8Z77-M Pro](asus/p8z77-m_pro.md)
|
||||
|
||||
## ASRock
|
||||
|
||||
- [H81M-HDS](asrock/h81m-hds.md)
|
||||
- [H110M-DVS](asrock/h110m-dvs.md)
|
||||
|
||||
## Cavium
|
||||
|
||||
@@ -31,10 +27,6 @@ The boards in this section are not real mainboards, but emulators.
|
||||
- [IceLake RVP](intel/icelake_rvp.md)
|
||||
- [KBLRVP11](intel/kblrvp11.md)
|
||||
|
||||
## Facebook
|
||||
|
||||
- [FBG-1701](facebook/fbg1701.md)
|
||||
|
||||
## Foxconn
|
||||
|
||||
- [D41S](foxconn/d41s.md)
|
||||
@@ -50,29 +42,17 @@ The boards in this section are not real mainboards, but emulators.
|
||||
## Open Cellular
|
||||
|
||||
- [Elgon](opencellular/elgon.md)
|
||||
- [Rotundu](opencellular/rotundu.md)
|
||||
|
||||
## HP
|
||||
|
||||
- [Compaq 8200 Elite SFF](hp/compaq_8200_sff.md)
|
||||
- [Z220 Workstation SFF](hp/z220_sff.md)
|
||||
|
||||
### EliteBook series
|
||||
|
||||
- [EliteBook common](hp/elitebook_series.md)
|
||||
- [EliteBook 8760w](hp/8760w.md)
|
||||
|
||||
## Lenovo
|
||||
|
||||
- [Mainboard codenames](lenovo/codenames.md)
|
||||
- [Hardware Maintenance Manual of ThinkPads](lenovo/thinkpad_hmm.md)
|
||||
- [T4xx common](lenovo/t4xx_series.md)
|
||||
- [X2xx common](lenovo/x2xx_series.md)
|
||||
|
||||
## Portwell
|
||||
|
||||
- [PQ7-M107](portwell/pq7-m107.md)
|
||||
|
||||
### Sandy Bridge series
|
||||
|
||||
- [T420](lenovo/t420.md)
|
||||
@@ -87,22 +67,6 @@ The boards in this section are not real mainboards, but emulators.
|
||||
- [T430 / T530 / X230 / W530 common](lenovo/xx30_series.md)
|
||||
- [T431s](lenovo/t431s.md)
|
||||
|
||||
## MSI
|
||||
|
||||
- [MS-7707](msi/ms7707/ms7707.md)
|
||||
|
||||
## PC Engines
|
||||
|
||||
- [APU2](pcengines/apu2.md)
|
||||
|
||||
## Roda
|
||||
|
||||
- [RK9 Flash Header](roda/rk9/flash_header.md)
|
||||
|
||||
## PC Engines
|
||||
|
||||
- [APU1](pcengines/apu1.md)
|
||||
|
||||
## SiFive
|
||||
|
||||
- [SiFive HiFive Unleashed](sifive/hifive-unleashed.md)
|
||||
@@ -110,7 +74,3 @@ The boards in this section are not real mainboards, but emulators.
|
||||
## Supermicro
|
||||
|
||||
- [X10SLM+-F](supermicro/x10slm-f.md)
|
||||
|
||||
## UP
|
||||
|
||||
- [Squared](up/squared/index.md)
|
||||
|
@@ -1,7 +0,0 @@
|
||||
# Lenovo mainboard codenames
|
||||
|
||||
```eval_rst
|
||||
.. csv-table::
|
||||
:header: "Marketing name", "Development codename"
|
||||
:file: codenames.csv
|
||||
```
|
Before Width: | Height: | Size: 235 KiB |
Before Width: | Height: | Size: 147 KiB |
Before Width: | Height: | Size: 81 KiB |
Before Width: | Height: | Size: 38 KiB |
@@ -1,34 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<svg width="10cm" height="8cm" version="1.1" viewBox="265 -156 186 159" xmlns="http://www.w3.org/2000/svg" xmlns:cc="http://creativecommons.org/ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
|
||||
<metadata>
|
||||
<rdf:RDF>
|
||||
<cc:Work rdf:about="">
|
||||
<dc:format>image/svg+xml</dc:format>
|
||||
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
|
||||
<dc:title/>
|
||||
</cc:Work>
|
||||
</rdf:RDF>
|
||||
</metadata>
|
||||
<rect x="308" y="-152" width="49.1" height="30.5" fill="#fff"/>
|
||||
<rect x="308" y="-152" width="49.1" height="30.5" fill="none" stroke="#000" stroke-width="2"/>
|
||||
<text x="332.45999" y="-134.83099" fill="#000000" font-family="sans-serif" font-size="6.77px" text-anchor="middle"><tspan x="332.45999" y="-134.83099">IFD</tspan></text>
|
||||
<rect x="308" y="-60.7" width="49.1" height="59.8" fill="#fff"/>
|
||||
<text x="332.46002" y="-30.227913" fill="#000000" font-family="sans-serif" font-size="6.77px" text-anchor="middle"><tspan x="332.46002" y="-30.227913">BIOS</tspan></text>
|
||||
<rect x="308" y="-60.7" width="49.1" height="59.8" fill="none" stroke="#000" stroke-width="2"/>
|
||||
<rect x="308" y="-91.6" width="49.1" height="30.9" fill="#fff"/>
|
||||
<rect x="308" y="-91.6" width="49.1" height="30.9" fill="none" stroke="#000" stroke-width="2"/>
|
||||
<text x="332.45999" y="-74.099892" fill="#000000" font-family="sans-serif" font-size="6.77px" text-anchor="middle"><tspan x="332.45999" y="-74.099892">ME</tspan></text>
|
||||
<rect x="308" y="-122" width="49.1" height="30.5" fill="#fff"/>
|
||||
<rect x="308" y="-122" width="49.1" height="30.5" fill="none" stroke="#000" stroke-width="2"/>
|
||||
<text x="332.45999" y="-104.3643" fill="#000000" font-family="sans-serif" font-size="6.77px" text-anchor="middle"><tspan x="332.45999" y="-104.3643">GBE</tspan></text>
|
||||
<g font-family="sans-serif" font-size="6.77px">
|
||||
<text x="265.96799" y="-149.20799"><tspan x="265.96799" y="-149.20799">0x000000</tspan></text>
|
||||
<text x="266.362" y="-120.102"><tspan x="266.362" y="-120.102">0x001000</tspan></text>
|
||||
<text x="266.16199" y="-88.897202"><tspan x="266.16199" y="-88.897202">0x003000</tspan></text>
|
||||
<text x="266.14401" y="-59.324112"><tspan x="266.14401" y="-59.324112">0x200000</tspan></text>
|
||||
<text x="266.32599" y="-1.1522589"><tspan x="266.32599" y="-1.1522589">0x400000</tspan></text>
|
||||
</g>
|
||||
<path d="m381-151c21 0-1.5 77.5 19.8 78.5" fill="none" stroke="#000"/>
|
||||
<path d="m381-0.763c13.9 0 5.64-72 19.5-72" fill="none" stroke="#000"/>
|
||||
<text x="406.12701" y="-68.513" fill="#000000" font-family="sans-serif" font-size="10.2px"><tspan x="406.12701" y="-68.513">Flash</tspan></text>
|
||||
</svg>
|
Before Width: | Height: | Size: 2.6 KiB |
@@ -1,112 +0,0 @@
|
||||
# MSI MS-7707 V1.1
|
||||
|
||||
* MSI MS-7707 V1.1 (Medion OEM Akoya P4385D MSN10014555)
|
||||
* SandyBridge Intel P67 (BD82x6x)
|
||||
* Winbond 25Q32BV (4MB)
|
||||
* Fintek F71808A SuperIO
|
||||
* Intel 82579V Gigabit
|
||||
* NEC uPD720200 USB 3.0 Host Controller
|
||||
* IME 7.0.4.1197
|
||||
|
||||
## Flash chip (Winbond 25Q32BV)
|
||||
```eval_rst
|
||||
+---------------------+--------------------+
|
||||
| Type | Value |
|
||||
+=====================+====================+
|
||||
| Size | 4 MiB |
|
||||
+---------------------+--------------------+
|
||||
| BIOS range | 2 MiB |
|
||||
+---------------------+--------------------+
|
||||
| Write protection | Yes (via jumper) |
|
||||
+---------------------+--------------------+
|
||||
| Header | Yes (JSPI1) |
|
||||
+---------------------+--------------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+--------------------+
|
||||
| In circuit flashing | Yes |
|
||||
+---------------------+--------------------+
|
||||
| Internal flashing | Yes |
|
||||
+---------------------+--------------------+
|
||||
| Socketed flash | No |
|
||||
+---------------------+--------------------+
|
||||
| Dual BIOS feature | No |
|
||||
+---------------------+--------------------+
|
||||
| ME removable | Yes |
|
||||
+---------------------+--------------------+
|
||||
```
|
||||
|
||||
## Installation instructions
|
||||
* The standard method is to only flash the 2MiB BIOS region. In that case it's
|
||||
not needed to extract blobs from vendor firmware and internal flashing is
|
||||
sufficient.
|
||||
* To flash the whole chip (e.g. to disable ME) blobs are needed to build
|
||||
coreboot. Blobs can be extracted with util/ifdtool from 4MiB full dump image
|
||||
(see below). Its recommended to include the VGA BIOS as well (4MiB write only).
|
||||
Kconfig is prepared already if it gets enabled (path and 8086,0102).
|
||||
```
|
||||
coreboot/3rdparty/blobs/mainboard/msi/ms7707
|
||||
├── descriptor.bin
|
||||
├── gbe.bin
|
||||
├── me.bin
|
||||
└── vgabios.bin
|
||||
```
|
||||
* Never write a full 4MiB image if blobs are not included. The generated
|
||||
coreboot.rom file is always 4MiB but the 2MiB flash command below will only
|
||||
flash the last 2MiB (BIOS) block.
|
||||
* The J1-Jumper sets the 'Flash Descriptor Override Strap-Pin' and enables
|
||||
full 4MiB access for internal flasher (read and write).
|
||||
* **Write BIOS-range** (2MiB) with J1-Jumper=off (as on picture/default
|
||||
position):
|
||||
```
|
||||
flashrom -p internal:ich_spi_force=yes --noverify-all --ifd -i bios -w coreboot.rom
|
||||
```
|
||||
* **Read full dump** (4MiB) with J1-jumper=on:
|
||||
```
|
||||
flashrom -p internal -r original.rom
|
||||
```
|
||||
* **Write full dump** (4MiB) with J1-Jumper=on:
|
||||
```
|
||||
flashrom -p internal -w coreboot.rom
|
||||
```
|
||||
* After successful flashing turn main power off, wait some seconds to drain
|
||||
the capacitors, pull the battery and set the JBAT (clrcmos) jumper for some
|
||||
seconds. Setting the jumper alone is not enough (the Fintek is VBAT backed).
|
||||
Put all back in place and restart the board. It might need 1-2 AC power cycles
|
||||
to reinitialize (running at full fan speed - don't panic).
|
||||
* External flashing has been tested with RPi2 without main power connected.
|
||||
3.3V provided by RPi2. Read more about flashing methods [here](https://doc.coreboot.org/flash_tutorial/index.html).
|
||||
* In case of going back to proprietary BIOS create/save cmos settings as early
|
||||
as possible (do not leave BIOS on first start without saving settings).
|
||||
The BIOS might corrupt nvram (not cmos!) and leave the system in a dead state
|
||||
that needs an external flasher to revive. If stuck, reset the Fintek (see
|
||||
above) and restart the system several times and/or try setting J1 to
|
||||
temporarily disable ME.
|
||||
|
||||

|
||||
|
||||
* The JSPI1 header (5×2 2.0mm pitch pin header) for external flashing is
|
||||
directly connected to the flash chip. Additional 3.3V to /HOLD and /WP is not
|
||||
needed (internally re-routed already).
|
||||
|
||||

|
||||
|
||||

|
||||
|
||||

|
||||
|
||||
## Flash layout
|
||||
|
||||
* The 4MiB flashrom is divided into 4 sections:
|
||||
|
||||
![][flashlayout]
|
||||
|
||||
## Links
|
||||
|
||||
- [BIOS ROM]
|
||||
- [Fintek F71808A datasheet]
|
||||
- [Winbond 25Q32BV datasheet]
|
||||
|
||||
[BIOS ROM]: https://www.medion.com/de/servicebackend/_lightbox/treiber_details.php?did=9744
|
||||
[Winbond 25Q32BV datasheet]: https://www.winbond.com/resource-files/w25q32bv_revi_100413_wo_automotive.pdf
|
||||
[Fintek F71808A datasheet]: https://www.alldatasheet.com/datasheet-pdf/pdf/459069/FINTEK/F71808A.html
|
||||
[flashlayout]: flashlayout.svg
|
@@ -1,76 +0,0 @@
|
||||
# Rutundu
|
||||
|
||||
This page describes how to run coreboot on the [Rotundu] compute board
|
||||
from [OpenCellular].
|
||||
|
||||
## TODO
|
||||
|
||||
* Configure UART
|
||||
* EC interface
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q128 |
|
||||
+---------------------+------------+
|
||||
| Size | 16 MiB |
|
||||
+---------------------+------------+
|
||||
| In circuit flashing | yes |
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+------------+
|
||||
| Write protection | No |
|
||||
+---------------------+------------+
|
||||
| Dual BIOS feature | No |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
### Internal programming
|
||||
|
||||
The SPI flash can be accessed using [flashrom].
|
||||
|
||||
### External programming
|
||||
|
||||
The GBCv1 board does have a pinheader to flash the SOIC-8 in circuit.
|
||||
Directly connecting a Pomona test-clip on the flash is also possible.
|
||||
|
||||
**Closeup view of SOIC-8 flash IC**
|
||||
|
||||
![][rotundu_flash]
|
||||
|
||||
[rotundu_flash]: rotundu_flash.jpg
|
||||
|
||||
**SPI header**
|
||||
|
||||
![][rotundu_header2]
|
||||
|
||||
[rotundu_header2]: rotundu_header2.jpg
|
||||
|
||||
**SPI header pinout**
|
||||
|
||||
Dediprog compatible pinout.
|
||||
|
||||
![][rotundu_j16]
|
||||
|
||||
[rotundu_j16]: rotundu_j16.png
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| SoC | Intel Baytrail |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel ME |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[Rotundu]: https://github.com/Telecominfraproject/OpenCellular
|
||||
[OpenCellular]: https://code.fb.com/connectivity/introducing-opencellular-an-open-source-wireless-access-platform/
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
Before Width: | Height: | Size: 92 KiB |
Before Width: | Height: | Size: 55 KiB |
Before Width: | Height: | Size: 20 KiB |
@@ -1,97 +0,0 @@
|
||||
# PC Engines APU1
|
||||
|
||||
This page describes how to run coreboot on PC Engines APU1 platform.
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------+--------------------------------------------------------+
|
||||
| CPU | AMD G series T40E APU |
|
||||
+------------+--------------------------------------------------------+
|
||||
| CPU core | 1 GHz dual core (Bobcat core) with 64 bit support |
|
||||
| | 32K data + 32K instruction + 512KB L2 cache per core |
|
||||
+------------+--------------------------------------------------------+
|
||||
| DRAM | 2 or 4 GB DDR3-1066 DRAM |
|
||||
+------------+--------------------------------------------------------+
|
||||
| Boot | From SD card, USB, mSATA, SATA |
|
||||
+------------+--------------------------------------------------------+
|
||||
| Power | 6 to 12W of 12V power |
|
||||
+------------+--------------------------------------------------------+
|
||||
| Firmware | coreboot with support for iPXE and USB boot |
|
||||
+------------+--------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+--------------------------+
|
||||
| Type | Value |
|
||||
+=====================+==========================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+--------------------------+
|
||||
| Model | MX25L1606E |
|
||||
+---------------------+--------------------------+
|
||||
| Size | 2 MiB |
|
||||
+---------------------+--------------------------+
|
||||
| Package | SOP-8 |
|
||||
+---------------------+--------------------------+
|
||||
| Write protection | jumper on WP# pin |
|
||||
+---------------------+--------------------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+--------------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+--------------------------+
|
||||
```
|
||||
|
||||
### Internal programming
|
||||
|
||||
The SPI flash can be accessed using [flashrom]. It is important to execute
|
||||
command with a `-c <chipname>` argument:
|
||||
|
||||
flashrom -p internal -c "MX25L1606E" -w coreboot.rom
|
||||
|
||||
### External programming
|
||||
|
||||
**IMPORTANT**: When programming SPI flash, first you need to enter apu1 in S5
|
||||
(Soft-off) power state. S5 state can be forced by shorting power button pin on
|
||||
J2 header.
|
||||
|
||||
The external access to flash chip is available through standard SOP-8 clip or
|
||||
SOP-8 header next to the flash chip on the board. Notice that not all boards
|
||||
have a header soldered down originally. Hence, there could be an empty slot with
|
||||
8 eyelets, so you can solder down a header on your own. The SPI flash chip and
|
||||
SPI header are marked in the picture below. Also there is SPI header pin layout
|
||||
included. Notice, that signatures at the schematic can be ambiguous:
|
||||
- J12 SPIDI = U35 SO = MISO
|
||||
- J12 SPIDO = U35 SI = MOSI
|
||||
|
||||
There is no restrictions as to the programmer device. It is only recommended to
|
||||
flash firmware without supplying power. External programming can be performed,
|
||||
for example using OrangePi and Armbian. You can exploit linux_spi driver which
|
||||
provide communication with SPI devices. Example command to program SPI flash
|
||||
with OrangePi using linux_spi:
|
||||
|
||||
flashrom -w coreboot.rom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000 -c
|
||||
"MX25L1606E"
|
||||
|
||||
|
||||
**apu1 platform with marked in SPI header and SPI flash chip**
|
||||
|
||||
![][apu1c1_flash]
|
||||
|
||||
**SPI header pin layout**
|
||||
|
||||
![][spi_header]
|
||||
|
||||
|
||||
### Schematics
|
||||
|
||||
PC Engines APU platform schematics are available for free on PC Engines official
|
||||
site. Depending on the configuration:
|
||||
[apu1c](https://www.pcengines.ch/schema/apu1c.pdf) and
|
||||
[apu1d](https://www.pcengines.ch/schema/apu1d.pdf).
|
||||
|
||||
|
||||
[apu1c1_flash]: apu1c1.jpg
|
||||
[spi_header]: apu1_spi.jpg
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
Before Width: | Height: | Size: 25 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 44 KiB |
@@ -1,116 +0,0 @@
|
||||
# PC Engines APU2
|
||||
|
||||
This page describes how to run coreboot on PC Engines APU2 platform.
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------+---------------------------------------------------------------+
|
||||
| CPU | AMD G series GX-412TC |
|
||||
+------------+---------------------------------------------------------------+
|
||||
| CPU core | 1 GHz quad Puma core with 64 bit support |
|
||||
| | 32K data + 32K instruction cache per core, shared 2MB L2 cache|
|
||||
+------------+---------------------------------------------------------------+
|
||||
| DRAM | 2 or 4 GB DDR3-1333 DRAM |
|
||||
+------------+---------------------------------------------------------------+
|
||||
| Boot | From SD card, USB, mSATA SSD, SATA |
|
||||
+------------+---------------------------------------------------------------+
|
||||
| Power | 6 to 12W of 12V power |
|
||||
+------------+---------------------------------------------------------------+
|
||||
| Firmware | coreboot with support for iPXE and USB boot |
|
||||
+------------+---------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Required proprietary blobs
|
||||
|
||||
To build working coreboot image some blobs are needed.
|
||||
|
||||
```eval_rst
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
| Binary file | Apply | Required / Optional |
|
||||
+=================+=================================+=====================+
|
||||
| amdfw.rom* | AMD Platform Security Processor | Required |
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
| AGESA.bin | AGESA Platform Initialization | Required |
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
| xhci.bin | AMD XHCI controller | Optional |
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
```
|
||||
(\*) - package containing all required blobs for PSP. Directory, in which all
|
||||
blobs are listed and available is: *3rdparty/southbridge/amd/avalon/PSP*
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+--------------------------+
|
||||
| Type | Value |
|
||||
+=====================+==========================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+--------------------------+
|
||||
| Model | W25Q64 |
|
||||
+---------------------+--------------------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+--------------------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+--------------------------+
|
||||
| Write protection | jumper on WP# pin* |
|
||||
+---------------------+--------------------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+--------------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+--------------------------+
|
||||
```
|
||||
(\*) - It is used in normal SPI mode, but can be dangerous when using Quad SPI
|
||||
Flash. Then, pull-down resistors should be considered rather than jumper.
|
||||
|
||||
### Internal programming
|
||||
|
||||
The SPI flash can be accessed using [flashrom].
|
||||
|
||||
flashrom -p internal -w coreboot.rom
|
||||
|
||||
### External programming
|
||||
|
||||
**IMPORTANT**: When programming SPI flash, first you need to enter apu2 in S5
|
||||
(Soft-off) power state. S5 state can be forced by shorting power button pin on
|
||||
J2 header.
|
||||
|
||||
The external access to flash chip is available through standard SOP-8 clip or
|
||||
SOP-8 header next to the flash chip on the board. Notice that not all boards
|
||||
have a header soldered down originally. Hence, there could be an empty slot with
|
||||
8 eyelets, so you can solder down a header on your own. The SPI flash chip and
|
||||
SPI header are marked in the picture below. Also there is SPI header and SPI
|
||||
flash pin layout included. Depend on using header or clip there are important
|
||||
rules:
|
||||
- using header J6 - don't connect 1,7,8 pins
|
||||
- using clip U23 - don't connect 3,7,8 pins
|
||||
|
||||
Also signatures at the schematic can be ambiguous:
|
||||
- J6 SPIDI = U23 SO = MISO
|
||||
- J6 SPIDO = U23 SI = MOSI
|
||||
|
||||
There is no restrictions as to the programmer device. It is only recommended to
|
||||
flash firmware without supplying power. External programming can be performed,
|
||||
for example using OrangePi and Armbian. You can exploit linux_spi driver which
|
||||
provides communication with SPI devices. Example command to program SPI flash
|
||||
with OrangePi using linux_spi:
|
||||
|
||||
flashrom -f -w coreboot.rom -p linux_spi:dev=/dev/spidev1.0,spispeed=16000
|
||||
|
||||
**apu2 platform with marked in SPI header and SPI flash chip**
|
||||
|
||||
![][apu2_flash]
|
||||
|
||||
**SPI header pin layout**
|
||||
|
||||
![][spi_header]
|
||||
|
||||
## Schematics
|
||||
|
||||
PC Engines APU2 [platform schematics](https://pcengines.ch/schema/apu2d.pdf)
|
||||
are available for free on PC Engines official site. Both configurations
|
||||
(2GB/4GB) have the same PCB and schematic.
|
||||
|
||||
[apu2_flash]: apu2.jpg
|
||||
[spi_header]: apu2_spi.jpg
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
Before Width: | Height: | Size: 22 KiB |
@@ -1,79 +0,0 @@
|
||||
# Portwell PQ7-M107
|
||||
|
||||
This page describes how to run coreboot on the [Portwell PQ7-M107].
|
||||
|
||||
PQ7-M107 are assembled with different onboard memory modules:
|
||||
Rev 1.0 Onboard Samsung K4B8G1646D-MYKO memory
|
||||
Rev 1.1 and 1.2 Onboard Micron MT41K512M16HA-125A memory
|
||||
|
||||
Use 'make menuconfig' to configure `onboard memory manufacture` in Mainboard
|
||||
menu.
|
||||
|
||||
## Required blobs
|
||||
|
||||
This board currently requires:
|
||||
fsp blob 3rdparty/fsp/BraswellFspBinPkg/FspBin/BSWFSP.fd
|
||||
Microcode Intel Braswell cpuid 1046C4 version 410
|
||||
(Used pre-built binary retrieved from Intel site)
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash can be accessed using [flashrom].
|
||||
|
||||
### External programming
|
||||
|
||||
The system has an internal flash chip which is a 8 MiB soldered SOIC-8 chip.
|
||||
This chip is located on the top middle side of the board. It's located
|
||||
between SoC and Q7 connector. Use clip (or solder wires) to program
|
||||
the chip.
|
||||
Specifically, it's a Winbond W25Q64FW (1.8V), whose datasheet can be found
|
||||
[here][W25Q64FW].
|
||||
|
||||
## Known issues
|
||||
|
||||
- The PQ7 module contains Q7 connector only. Depending on the carrier
|
||||
serial/video/pcie ports might be available.
|
||||
|
||||
## Untested
|
||||
|
||||
- hardware monitor
|
||||
- SDIO
|
||||
- Full Embedded Controller support
|
||||
|
||||
## Working (using carrier)
|
||||
|
||||
- USB
|
||||
- Gigabit Ethernet
|
||||
- integrated graphics
|
||||
- flashrom
|
||||
- external graphics
|
||||
- PCIe
|
||||
- eMMC
|
||||
- SATA
|
||||
- serial port
|
||||
- SMbus
|
||||
- HDA (codec on carrier)
|
||||
- initialization with FSP MR2
|
||||
- SeaBIOS payload (version rel-1.11.0-44-g7961917)
|
||||
- Embedded Linux (Ubuntu 4.15+)
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| SoC | Intel Atom Processor N3710 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Braswell (N3710) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O, EC | ITE8256 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[Portwell PQ7-M107]: http://portwell.com/products/detail.php?CUSTCHAR1=PQ7-M107
|
||||
[W25Q64FW]: https://www.winbond.com/resource-files/w25q64fw%20revn%2005182017%20sfdp.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
||||
[Board manual]: www.portwell.com/pdf/embedded/PQ7-M107.pdf
|
@@ -1,23 +0,0 @@
|
||||
Roda RK9 Flash Header
|
||||
=====================
|
||||
|
||||
There is a 5x2 pin, 1.27mm pitch header *J1* south of the BIOS flash. It
|
||||
follows the pinout of the Dediprog adaptor board:
|
||||
|
||||
+------+
|
||||
| 1 2 | 1: HOLD 2 2: CS 2
|
||||
| 3 4 | 3: CS 1 4: VCC
|
||||
| 5 6 | 5: MISO 6: HOLD 1
|
||||
| 7 8 | 7: 8: CLK
|
||||
| 9 10 | 9: GND 10: MOSI
|
||||
+------+
|
||||
|
||||
Pins 3 to 10 directly map to the regular SPI flash pinout.
|
||||
|
||||
There is also a *JP17* around. Ideally, it should be closed during
|
||||
programming (isolates the SPI bus from the southbridge):
|
||||
|
||||
+---+
|
||||
| 1 | 1: SF100-I/O3
|
||||
| 2 | 2: GND
|
||||
+---+
|
@@ -12,13 +12,15 @@ For general setup instructions, please refer to the [Getting Started Guide].
|
||||
The following things are still missing from this coreboot port:
|
||||
|
||||
- Support running romstage from flash (fix stack) to support boot mode 1
|
||||
- CBMEM support
|
||||
- FU540 clock configuration
|
||||
- FU540 RAM init
|
||||
- Placing the ramstage in DRAM
|
||||
- Starting the U54 cores
|
||||
- FU540 PIN configuration and GPIO access macros
|
||||
- Provide serial number to payload (e.g. in device tree)
|
||||
- Implement instruction emulation
|
||||
- Support for booting Linux on RISC-V
|
||||
- Add support to run OpenSBI payload in m-mode
|
||||
- SMP support in trap handler
|
||||
|
||||
|
||||
## Configuration
|
||||
|
||||
|
Before Width: | Height: | Size: 48 KiB |
@@ -1,126 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
|
||||
<svg width="14cm" height="10cm" viewBox="399 -216 262 199" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="460" y="-20">
|
||||
<tspan x="460" y="-20">40 pin GPIO header</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="520" y="-175.575">
|
||||
<tspan x="520" y="-175.575">GND</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="560" y="-203.575">
|
||||
<tspan x="560" y="-203.575">UART1</tspan>
|
||||
<tspan x="560" y="-187.575">TX</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="600" y="-183.575">
|
||||
<tspan x="600" y="-183.575">UART1</tspan>
|
||||
<tspan x="600" y="-167.575">RX</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="400" y="-140" width="260" height="100"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="400" y="-140" width="260" height="100"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="420" y="-120" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="420" y="-120" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="420" y="-80" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="420" y="-80" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="500" y="-120" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="500" y="-120" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="500" y="-80" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="500" y="-80" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="460" y="-120" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="460" y="-120" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="460" y="-80" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="460" y="-80" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="540" y="-120" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="540" y="-120" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="540" y="-80" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="540" y="-80" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="580" y="-120" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="580" y="-120" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="580" y="-80" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="580" y="-80" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="620" y="-120" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="620" y="-120" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="620" y="-80" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="620" y="-80" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="420,-40 420,-49 "/>
|
||||
<polygon style="fill: #000000" points="425,-49 420,-59 415,-49 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="425,-49 420,-59 415,-49 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="430" y="-65.575">
|
||||
<tspan x="430" y="-65.575">1</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="470" y="-105.575">
|
||||
<tspan x="470" y="-105.575">4</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="430" y="-105.575">
|
||||
<tspan x="430" y="-105.575">2</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="470" y="-65.575">
|
||||
<tspan x="470" y="-65.575">3</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="510" y="-65.575">
|
||||
<tspan x="510" y="-65.575">5</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="550" y="-65.575">
|
||||
<tspan x="550" y="-65.575">7</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="550" y="-105.575">
|
||||
<tspan x="550" y="-105.575">8</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="510" y="-105.575">
|
||||
<tspan x="510" y="-105.575">6</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="590" y="-65.575">
|
||||
<tspan x="590" y="-65.575">9</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="630" y="-65.575">
|
||||
<tspan x="630" y="-65.575">11</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="630" y="-105.575">
|
||||
<tspan x="630" y="-105.575">12</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="590" y="-105.575">
|
||||
<tspan x="590" y="-105.575">10</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="520,-160 520,-131 "/>
|
||||
<polygon style="fill: #000000" points="515,-131 520,-121 525,-131 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="515,-131 520,-121 525,-131 "/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="560,-180 560,-131 "/>
|
||||
<polygon style="fill: #000000" points="555,-131 560,-121 565,-131 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="555,-131 560,-121 565,-131 "/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="600,-160 600,-131 "/>
|
||||
<polygon style="fill: #000000" points="595,-131 600,-121 605,-131 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="595,-131 600,-121 605,-131 "/>
|
||||
</g>
|
||||
</svg>
|
Before Width: | Height: | Size: 7.4 KiB |
@@ -1,112 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
|
||||
<svg width="22cm" height="9cm" viewBox="416 112 425 163" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="420" y="140" width="420" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="420" y="140" width="420" height="60"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="440" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="440" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="480" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="480" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="520" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="520" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="560" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="560" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="600" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="600" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="640" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="640" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="680" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="680" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="720" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="720" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="760" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="760" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="800" y="160" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="800" y="160" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="820,140 820,149 "/>
|
||||
<polygon style="fill: #000000" points="815,149 820,159 825,149 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="815,149 820,159 825,149 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="810" y="174.425">
|
||||
<tspan x="810" y="174.425">1</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="770" y="174.425">
|
||||
<tspan x="770" y="174.425">2</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="650" y="174.425">
|
||||
<tspan x="650" y="174.425">5</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="690" y="174.425">
|
||||
<tspan x="690" y="174.425">4</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="730" y="174.425">
|
||||
<tspan x="730" y="174.425">3</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="610" y="174.425">
|
||||
<tspan x="610" y="174.425">6</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="490" y="174.425">
|
||||
<tspan x="490" y="174.425">9</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="530" y="174.425">
|
||||
<tspan x="530" y="174.425">8</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="570" y="174.425">
|
||||
<tspan x="570" y="174.425">7</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="450" y="174.425">
|
||||
<tspan x="450" y="174.425">10</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="520" y="264.425">
|
||||
<tspan x="520" y="264.425">GND</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="480" y="236.425">
|
||||
<tspan x="480" y="236.425">UART0</tspan>
|
||||
<tspan x="480" y="252.425">RX</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="440" y="256.425">
|
||||
<tspan x="440" y="256.425">UART0</tspan>
|
||||
<tspan x="440" y="272.425">TX</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="440,240 440,191 "/>
|
||||
<polygon style="fill: #000000" points="445,191 440,181 435,191 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="445,191 440,181 435,191 "/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="480,220 480,191 "/>
|
||||
<polygon style="fill: #000000" points="485,191 480,181 475,191 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="485,191 480,181 475,191 "/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="520,240 520,191 "/>
|
||||
<polygon style="fill: #000000" points="525,191 520,181 515,191 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="525,191 520,181 515,191 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="640" y="124.425">
|
||||
<tspan x="640" y="124.425">10 pin UART0/USB2 header (CN16)</tspan>
|
||||
</text>
|
||||
</svg>
|
Before Width: | Height: | Size: 6.6 KiB |
@@ -1,165 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
|
||||
<svg width="14cm" height="12cm" viewBox="294 -68 267 236" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="300" y="0" width="260" height="99"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="300" y="0" width="260" height="99"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="320" y="20" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="320" y="20" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="360" y="20" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="360" y="20" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="400" y="20" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="400" y="20" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="440" y="20" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="440" y="20" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="480" y="20" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="480" y="20" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="520" y="20" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="520" y="20" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="320" y="60" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="320" y="60" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="360" y="60" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="360" y="60" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="400" y="60" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="400" y="60" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="440" y="60" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="440" y="60" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="480" y="60" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="480" y="60" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #00ff00" x="520" y="60" width="20" height="20"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="520" y="60" width="20" height="20"/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="540,0 540,9 "/>
|
||||
<polygon style="fill: #000000" points="535,9 540,19 545,9 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="535,9 540,19 545,9 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="370" y="34.425">
|
||||
<tspan x="370" y="34.425">9</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="450" y="34.425">
|
||||
<tspan x="450" y="34.425">5</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="410" y="34.425">
|
||||
<tspan x="410" y="34.425">7</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="410" y="74.425">
|
||||
<tspan x="410" y="74.425">8</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="530" y="34.425">
|
||||
<tspan x="530" y="34.425">1</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="490" y="74.425">
|
||||
<tspan x="490" y="74.425">4</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="490" y="34.425">
|
||||
<tspan x="490" y="34.425">3</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="530" y="74.425">
|
||||
<tspan x="530" y="74.425">2</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="450" y="74.425">
|
||||
<tspan x="450" y="74.425">6</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="330" y="34.425">
|
||||
<tspan x="330" y="34.425">11</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="330" y="74.425">
|
||||
<tspan x="330" y="74.425">12</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="370" y="74.425">
|
||||
<tspan x="370" y="74.425">10</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:700" x="420" y="-20">
|
||||
<tspan x="420" y="-20">SPI header (CN22)</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="520,140 520,91 "/>
|
||||
<polygon style="fill: #000000" points="525,91 520,81 515,91 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="525,91 520,81 515,91 "/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="360,140 360,91 "/>
|
||||
<polygon style="fill: #000000" points="365,91 360,81 355,91 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="365,91 360,81 355,91 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="360" y="164.425">
|
||||
<tspan x="360" y="164.425">GND</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="520" y="164.425">
|
||||
<tspan x="520" y="164.425">GND</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="400,120 400,91 "/>
|
||||
<polygon style="fill: #000000" points="405,91 400,81 395,91 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="405,91 400,81 395,91 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="400" y="144.425">
|
||||
<tspan x="400" y="144.425">MISO</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="480,120 480,91 "/>
|
||||
<polygon style="fill: #000000" points="485,91 480,81 475,91 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="485,91 480,81 475,91 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="480" y="136.425">
|
||||
<tspan x="480" y="136.425">VCC</tspan>
|
||||
<tspan x="480" y="152.425">1.8V</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="320" y="144.425">
|
||||
<tspan x="320" y="144.425">#HOLD</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="320,120 320,91 "/>
|
||||
<polygon style="fill: #000000" points="325,91 320,81 315,91 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="325,91 320,81 315,91 "/>
|
||||
</g>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="400,-40 400,9 "/>
|
||||
<polygon style="fill: #000000" points="395,9 400,19 405,9 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="395,9 400,19 405,9 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="400" y="-55.575">
|
||||
<tspan x="400" y="-55.575">CLK</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<polyline style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="320,-20 320,9 "/>
|
||||
<polygon style="fill: #000000" points="315,9 320,19 325,9 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="315,9 320,19 325,9 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="320" y="-35.575">
|
||||
<tspan x="320" y="-35.575">MOSI</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="440" y1="140" x2="440" y2="91"/>
|
||||
<polygon style="fill: #000000" points="445,91 440,81 435,91 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="445,91 440,81 435,91 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="440" y="164.238">
|
||||
<tspan x="440" y="164.238">#CS</tspan>
|
||||
</text>
|
||||
</svg>
|
Before Width: | Height: | Size: 9.6 KiB |
@@ -1,169 +0,0 @@
|
||||
# Squared
|
||||
|
||||
## Overview
|
||||
### Top
|
||||
![][overview_top]
|
||||
|
||||
### Bottom
|
||||
![][overview_bottom]
|
||||
|
||||
* **Legend**
|
||||
* [BLUE][header_cn16_link]: UART0 / USB connector
|
||||
* [GREEN][header_gpio_link]: UART1 / GPIO header
|
||||
* [RED][header_cn22_link]: SPI header
|
||||
* YELLOW: Indicates pin 1
|
||||
|
||||
## Mainboard components
|
||||
### Platform
|
||||
```eval_rst
|
||||
+------------------+----------------------------------+
|
||||
| CPU | Intel Atom, Celeron, Pentium |
|
||||
+------------------+----------------------------------+
|
||||
| PCH | Intel Apollo Lake |
|
||||
+------------------+----------------------------------+
|
||||
| EC / Super IO | N/A |
|
||||
+------------------+----------------------------------+
|
||||
| Coprocessor | Intel TXE 3.0 |
|
||||
+------------------+----------------------------------+
|
||||
```
|
||||
|
||||
### Flash chip
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Vendor | Winbond |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q128FW |
|
||||
+---------------------+------------+
|
||||
| Voltage | 1.8V |
|
||||
+---------------------+------------+
|
||||
| Size | 16 MiB |
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+------------+
|
||||
| Write protection | No |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | No |
|
||||
+---------------------+------------+
|
||||
| In curcuit flashing | Yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
### Debugging
|
||||
#### UART0 (CN16)
|
||||
This connector is located on the **bottom** side (see [here][overview_bottom_link]).
|
||||
![][header_cn16]
|
||||
|
||||
|
||||
#### UART1 (GPIO header)
|
||||
The GPIO header is located on the **bottom** side (see [here][overview_bottom_link]).
|
||||
![][header_gpio]
|
||||
|
||||
## Building and flashing coreboot
|
||||
### Using the SPI header
|
||||
The SPI header is located on the **bottom** side (see [here][overview_bottom_link]).
|
||||
![][header_cn22]
|
||||
|
||||
### Preperations
|
||||
In order to build coreboot, it's neccessary to extract some files from the vendor firmware. Make sure that you have a fully working dump.
|
||||
```bash
|
||||
[upsquared]$ ls
|
||||
firmware_vendor.rom
|
||||
```
|
||||
|
||||
```bash
|
||||
[upsquared]$ mkdir extracted && cd extracted
|
||||
[extracted]$ ifdtool -x ../firmware_vendor.rom
|
||||
File ../firmware_vendor.rom is 16777216 bytes
|
||||
Peculiar firmware descriptor, assuming Ibex Peak compatibility.
|
||||
Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
|
||||
Flash Region 1 (BIOS): 00001000 - 00efefff
|
||||
Flash Region 2 (Intel ME): 07fff000 - 00000fff (unused)
|
||||
Flash Region 3 (GbE): 07fff000 - 00000fff (unused)
|
||||
Flash Region 4 (Platform Data): 07fff000 - 00000fff (unused)
|
||||
Flash Region 5 (Reserved): 00eff000 - 00ffefff
|
||||
Flash Region 6 (Reserved): 07fff000 - 00000fff (unused)
|
||||
Flash Region 7 (Reserved): 07fff000 - 00000fff (unused)
|
||||
Flash Region 8 (EC): 07fff000 - 00000fff (unused)
|
||||
```
|
||||
|
||||
```bash
|
||||
flashregion_0_flashdescriptor.bin
|
||||
flashregion_1_bios.bin
|
||||
flashregion_5_reserved.bin
|
||||
```
|
||||
|
||||
### Clean up
|
||||
```bash
|
||||
[coreboot]$ make distclean
|
||||
```
|
||||
|
||||
### Configuring
|
||||
```bash
|
||||
[coreboot]$ touch .config
|
||||
[coreboot]$ ./util/scripts/config --enable VENDOR_UP
|
||||
[coreboot]$ ./util/scripts/config --enable BOARD_UP_SQUARED
|
||||
[coreboot]$ ./util/scripts/config --enable NEED_IFWI
|
||||
[coreboot]$ ./util/scripts/config --enable HAVE_IFD_BIN
|
||||
[coreboot]$ ./util/scripts/config --set-str IFWI_FILE_NAME "<flashregion_1_bios.bin>"
|
||||
[coreboot]$ ./util/scripts/config --set-str IFD_BIN_PATH "<flashregion_0_flashdescriptor.bin>"
|
||||
[coreboot]$ make olddefconfig
|
||||
```
|
||||
|
||||
### Building
|
||||
```bash
|
||||
[coreboot]$ make
|
||||
```
|
||||
|
||||
Now you should have a working and ready to use coreboot build at `build/coreboot.rom`.
|
||||
|
||||
### Flashing
|
||||
```bash
|
||||
[coreboot]$ flashrom -p <your_programmer> -w build/coreboot.rom
|
||||
```
|
||||
|
||||
## Board status
|
||||
### Working
|
||||
- bootblock, romstage, ramstage
|
||||
- Serial console UART0, UART1
|
||||
- SPI flash console
|
||||
- iGPU init with libgfxinit
|
||||
- LAN1, LAN2
|
||||
- USB2, USB3
|
||||
- HDMI, DisplayPort
|
||||
- eMMC
|
||||
- flashing with flashrom externally
|
||||
|
||||
### Work in progress
|
||||
- Documentation
|
||||
- ACPI
|
||||
|
||||
### Not working / Known issues
|
||||
- Generally SeaBIOS works, but it can't find the CBFS region and therefore it can't load seavgabios. This is because of changes at the Apollolake platform.
|
||||
|
||||
### Untested
|
||||
- GPIO pin header
|
||||
- 60 pin EXHAT
|
||||
- Camera interface
|
||||
- MIPI-CSI2 2-lane (2MP)
|
||||
- MIPI-CSI2 4-lane (8MP)
|
||||
- SATA3
|
||||
- USB3 OTG
|
||||
- embedded DisplayPort
|
||||
- M.2 slot
|
||||
- mini PCIe
|
||||
- flashing with flashrom internally using Linux
|
||||
|
||||
|
||||
[header_cn16]: header_cn16_10pin_uart0.svg
|
||||
[header_cn16_link]: #uart0-cn16
|
||||
[header_cn22]: header_cn22_12pin_spi.svg
|
||||
[header_cn22_link]: #using-the-spi-header
|
||||
[header_gpio]: header_40pin_gpio_uart1.svg
|
||||
[header_gpio_link]: #uart1-gpio-header
|
||||
[overview_top]: top.jpg
|
||||
[overview_bottom]: bottom.jpg
|
||||
[overview_bottom_link]: #bottom
|
Before Width: | Height: | Size: 33 KiB |
@@ -27,83 +27,6 @@ Now, place `mrc.bin` in the root of the coreboot directory.
|
||||
Alternatively, place `mrc.bin` anywhere you want, and set `MRC_FILE` to
|
||||
its location when building coreboot.
|
||||
|
||||
## SPD Addresses
|
||||
|
||||
When porting a board from vendor firmware, the SPD addresses can be obtained
|
||||
through `i2c-tools`, which can be found in many GNU/Linux distributions. A more
|
||||
[detailed description](https://hannuhartikainen.fi/blog/hacking-ddr3-spd/) of
|
||||
the procedure and beyond can be found in
|
||||
[Hannu Hartikainen's blog](https://hannuhartikainen.fi).
|
||||
|
||||
First load the kernel modules:
|
||||
|
||||
```bash
|
||||
modprobe i2c-dev
|
||||
modprobe eeprom
|
||||
```
|
||||
|
||||
Find the SMBus and the addresses of the DIMM's EEPROMs (example output):
|
||||
```bash
|
||||
$ decode-dimms | grep Decoding
|
||||
Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/7-0050
|
||||
Decoding EEPROM: /sys/bus/i2c/drivers/eeprom/7-0052
|
||||
```
|
||||
|
||||
Alternatively, look at the sys filesystem:
|
||||
```bash
|
||||
$ ls -l /sys/bus/i2c/drivers/eeprom/
|
||||
total 0
|
||||
lrwxrwxrwx 1 root root 0 Apr 4 01:46 6-0050 -> ../../../../devices/pci0000:00/0000:00:02.0/drm/card0/card0-eDP-1/i2c-6/6-0050/
|
||||
lrwxrwxrwx 1 root root 0 Apr 4 01:46 7-0050 -> ../../../../devices/pci0000:00/0000:00:1f.3/i2c-7/7-0050/
|
||||
lrwxrwxrwx 1 root root 0 Apr 4 01:46 7-0052 -> ../../../../devices/pci0000:00/0000:00:1f.3/i2c-7/7-0052/
|
||||
--w------- 1 root root 4096 Apr 4 01:47 bind
|
||||
lrwxrwxrwx 1 root root 0 Apr 4 01:47 module -> ../../../../module/eeprom/
|
||||
--w------- 1 root root 4096 Apr 4 01:46 uevent
|
||||
--w------- 1 root root 4096 Apr 4 01:47 unbind
|
||||
```
|
||||
|
||||
The correct I2C bus is 7 in this case, and the EEPROMs are at `0x50` and `0x52`.
|
||||
Note that the above values are actually hex values.
|
||||
|
||||
You can check the correctness of the SMBus and the addresses of the EEPROMs via
|
||||
`i2cdetect`:
|
||||
|
||||
```bash
|
||||
$ i2cdetect -l
|
||||
i2c-3 unknown i915 gmbus dpc N/A
|
||||
i2c-1 unknown i915 gmbus vga N/A
|
||||
i2c-6 unknown DPDDC-A N/A
|
||||
i2c-4 unknown i915 gmbus dpb N/A
|
||||
i2c-2 unknown i915 gmbus panel N/A
|
||||
i2c-0 unknown i915 gmbus ssc N/A
|
||||
i2c-7 unknown SMBus I801 adapter at f040 N/A
|
||||
i2c-5 unknown i915 gmbus dpd N/A
|
||||
```
|
||||
|
||||
Probing the SMBus:
|
||||
|
||||
```bash
|
||||
$ i2cdetect -r 7
|
||||
WARNING! This program can confuse your I2C bus, cause data loss and worse!
|
||||
I will probe file /dev/i2c-7 using receive byte commands.
|
||||
I will probe address range 0x03-0x77.
|
||||
Continue? [Y/n]
|
||||
0 1 2 3 4 5 6 7 8 9 a b c d e f
|
||||
00: -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
30: 30 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
40: -- -- -- -- 44 -- -- -- -- -- -- -- -- -- -- --
|
||||
50: UU -- UU -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
|
||||
70: -- -- -- -- -- -- -- --
|
||||
```
|
||||
|
||||
The SPD addresses need to be left-shifted by 1 for `mrc.bin`, i.e., multiplied
|
||||
by 2. For example, if the addresses read through `i2c-tools` when booted from
|
||||
vendor firmware are `0x50` and `0x52`, the correct values would be `0xa0` and
|
||||
`0xa4`. This is because the I2C addresses are 7 bits long.
|
||||
|
||||
## ECC DRAM
|
||||
|
||||
When `mrc.bin` has finished executing, ECC is active on the channels
|
||||
|
@@ -6,4 +6,3 @@ This section contains documentation about coreboot on specific Intel "Sandy Brid
|
||||
|
||||
- [Native Ram Initialization](nri.md)
|
||||
- [RAM initialization feature matrix](nri_features.md)
|
||||
- [ME Cleaner](me_cleaner.md)
|
||||
|
@@ -1,20 +0,0 @@
|
||||
# ME Cleaner
|
||||
It's possible to 'clean' the ME partition within the flash medium as part
|
||||
of the build process. While cleaning as much code as possible is removed
|
||||
from the ME firmware partition. In this state the ME errors out and doesn't
|
||||
operate any more.
|
||||
|
||||
**Using a 'cleaned' ME partition may lead to issues and its use should be
|
||||
carefully evaulated.**
|
||||
|
||||
## Observations with 'cleaned' ME
|
||||
|
||||
* Instable LPC bus
|
||||
* SuperIO is malfunctioning
|
||||
* TPM is malfunctioning
|
||||
* Random system shutdowns on high bus activity
|
||||
|
||||
## Filing bug reports
|
||||
|
||||
Always test with unmodified IFD and ME section before reporting bugs to the
|
||||
coreboot project.
|
5
Documentation/security.md
Normal file
@@ -0,0 +1,5 @@
|
||||
# Security
|
||||
|
||||
## Google VBoot2 Measured boot extension
|
||||
|
||||
- [Measured Boot](vboot/measured_boot.md)
|
@@ -1,15 +0,0 @@
|
||||
# Security
|
||||
|
||||
This section describes documentation about the security architecture of coreboot.
|
||||
|
||||
## Vendor
|
||||
|
||||
- [Verified Boot](vboot/index.md)
|
||||
- [Measured Boot](vboot/measured_boot.md)
|
||||
- [Memory clearing](memory_clearing.md)
|
||||
|
||||
## Intel TXT
|
||||
|
||||
- [Intel TXT in general](intel/txt.md)
|
||||
- [Intel TXT Initial Boot Block](intel/txt_ibb.md)
|
||||
- [Intel Authenticated Code Modules](intel/acm.md)
|
@@ -1,57 +0,0 @@
|
||||
# Intel Authenticated Code Modules
|
||||
|
||||
The Authenticated Code Modules (ACMs) are Intel digitally signed modules
|
||||
that contain code to be run before the traditional x86 CPU reset vector.
|
||||
The ACMs can be invoked at runtime through the GETSEC instruction, too.
|
||||
|
||||
A platform that wants to use Intel TXT must use two ACMs:
|
||||
1. BIOS ACM
|
||||
* The BIOS ACM must be present in the boot flash.
|
||||
* The BIOS ACM must be referenced by the [FIT].
|
||||
2. SINIT ACM
|
||||
* The SINIT ACM isn't referenced by the [FIT].
|
||||
* The SINIT ACM should be provided by the boot firmware, but bootloaders
|
||||
like [TBOOT] are able to load them from the filesystem as well.
|
||||
|
||||
## Retrieving ACMs
|
||||
|
||||
The ACMs can be downloaded on Intel's website:
|
||||
[Intel Trusted Execution Technology](https://software.intel.com/en-us/articles/intel-trusted-execution-technology)
|
||||
|
||||
If you want to extract the BLOB from vendor firmware you can search for the
|
||||
string ``LCP_POLICY_DATA`` or ``TXT``.
|
||||
|
||||
## Header
|
||||
|
||||
Every ACM has a fixed size header:
|
||||
|
||||
```c
|
||||
/*
|
||||
* ACM Header v0.0 without dynamic part
|
||||
* Chapter A.1
|
||||
* Intel TXT Software Development Guide (Document: 315168-015)
|
||||
*/
|
||||
struct acm_header_v0 {
|
||||
uint16_t module_type;
|
||||
uint16_t module_sub_type;
|
||||
uint32_t header_len;
|
||||
uint16_t header_version[2];
|
||||
uint16_t chipset_id;
|
||||
uint16_t flags;
|
||||
uint32_t module_vendor;
|
||||
uint32_t date;
|
||||
uint32_t size;
|
||||
uint16_t txt_svn;
|
||||
uint16_t se_svn;
|
||||
uint32_t code_control;
|
||||
uint32_t error_entry_point;
|
||||
uint32_t gdt_limit;
|
||||
uint32_t gdt_ptr;
|
||||
uint32_t seg_sel;
|
||||
uint32_t entry_point;
|
||||
uint8_t reserved2[63];
|
||||
} __packed;
|
||||
```
|
||||
|
||||
[FIT]: ../../soc/intel/fit.md
|
||||
[TBOOT]: https://sourceforge.net/p/tboot/wiki/Home/
|
@@ -1,153 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
|
||||
<svg width="16cm" height="36cm" viewBox="522 318 306 714" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="523.768" y="829.25" width="296.25" height="201.75"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="523.768" y="829.25" width="296.25" height="201.75"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="689.334" y="321.666" width="72.375" height="269.168"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="689.334" y="321.666" width="72.375" height="269.168"/>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="725.522" y="460.15">
|
||||
<tspan x="725.522" y="460.15"></tspan>
|
||||
</text>
|
||||
</g>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="686.166" y1="352" x2="781.166" y2="352"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="685.8" y1="334.434" x2="780.8" y2="334.434"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="682.8" y1="410.934" x2="777.8" y2="410.934"/>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" d="M 684.5,342.584 A 30.4704,30.4704 0 0 0 676.673,403.011"/>
|
||||
<polygon style="fill: #0000ff" points="679.632,403.321 675.608,405.273 676.632,403.285 675.656,401.273 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" points="679.632,403.321 675.608,405.273 676.632,403.285 675.656,401.273 "/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.75" y="367" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.75" y="367" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<text font-size="5.64444" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="653" y="323.334">
|
||||
<tspan x="653" y="323.334">4 GiB </tspan>
|
||||
</text>
|
||||
<text font-size="7.90222" style="fill: #0000ff;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="707.958" y="348.25">
|
||||
<tspan x="707.958" y="348.25">FIT Ptr</tspan>
|
||||
</text>
|
||||
<text font-size="7.90222" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="692.934" y="330.55">
|
||||
<tspan x="692.934" y="330.55">IA32 reset vec</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.684" y="415.25" width="60.2083" height="41.5333"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x="694.684" y="415.25" width="60.2083" height="41.5333"/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" d="M 654.458,327 A 65.5176,65.5176 0 0 0 675.175,449.031"/>
|
||||
<polygon style="fill: #ff0000" points="678.138,449.469 673.953,451.045 675.154,449.159 674.366,447.066 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" points="678.138,449.469 673.953,451.045 675.154,449.159 674.366,447.066 "/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.934" y="462.5" width="60.2083" height="28.7474"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x="694.934" y="462.5" width="60.2083" height="28.7474"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="695.434" y="518.45" width="60.2083" height="12.134"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #00ff00" x="695.434" y="518.45" width="60.2083" height="12.134"/>
|
||||
</g>
|
||||
<text font-size="6.77333" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="708.208" y="479.25">
|
||||
<tspan x="708.208" y="479.25">BIOS ACM</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="707.184" y="432.25">
|
||||
<tspan x="707.184" y="432.25">BOOTBLOCK</tspan>
|
||||
<tspan x="707.184" y="440.717">CODE</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #00ff00;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="714.934" y="527">
|
||||
<tspan x="714.934" y="527">uCode</tspan>
|
||||
</text>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x1="655.186" y1="327.12" x2="687.728" y2="326.952"/>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.684" y="377.45" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.684" y="377.45" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.75" y="387.95" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.75" y="387.95" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.684" y="398.4" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.684" y="398.4" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="691.018" y="588.75" width="68.5" height="4.25"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="691.018" y="588.75" width="68.5" height="4.25"/>
|
||||
</g>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="689.334" y1="590.834" x2="689.018" y2="509.25"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="683.092" y1="493.9" x2="778.092" y2="493.9"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="682.592" y1="459.4" x2="777.592" y2="459.4"/>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="695.776" y="533.91" width="60.2083" height="12.134"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #00ff00" x="695.776" y="533.91" width="60.2083" height="12.134"/>
|
||||
</g>
|
||||
<text font-size="6.77333" style="fill: #00ff00;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="714.026" y="542.21">
|
||||
<tspan x="714.026" y="542.21">uCode</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="695.276" y="497.072" width="60.2083" height="15.675"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x="695.276" y="497.072" width="60.2083" height="15.675"/>
|
||||
</g>
|
||||
<text font-size="6.77333" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="715.276" y="546.122">
|
||||
<tspan x="715.276" y="546.122"></tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="695.776" y="551.072" width="60.2083" height="15.3485"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x="695.776" y="551.072" width="60.2083" height="15.3485"/>
|
||||
</g>
|
||||
<text font-size="6.77333" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="705.1" y="506.148">
|
||||
<tspan x="705.1" y="506.148">verstage</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="719.35" y="561.32">
|
||||
<tspan x="719.35" y="561.32">FSP</tspan>
|
||||
</text>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="682.1" y1="515.408" x2="777.1" y2="515.408"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="682.85" y1="548.738" x2="777.85" y2="548.738"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="789.75" y1="322.584" x2="789.75" y2="458.408"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="789.5" y1="457.908" x2="783" y2="457.908"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="789.6" y1="322.508" x2="783.1" y2="322.508"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="789.75" y1="493.226" x2="790.1" y2="513.834"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="789.85" y1="513.334" x2="783.35" y2="513.334"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="790.2" y1="493.934" x2="783.7" y2="493.934"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="789.65" y1="549.094" x2="790" y2="569.7"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="789.75" y1="569.2" x2="783.25" y2="569.2"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" x1="790.1" y1="549.8" x2="783.6" y2="549.8"/>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 2; stroke: #ff8484" d="M 753.708,392.75 A 49.3538,49.3538 0 0 0 783.042,393.053"/>
|
||||
<polygon style="fill: #ffffff" points="784.252,395.824 787.724,391.442 782.136,391.293 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" points="784.252,395.824 787.724,391.442 782.136,391.293 "/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 2; stroke: #ff8484" d="M 796.338,500.253 A 63.4678,63.4678 0 0 0 754.892,382.7"/>
|
||||
<polygon style="fill: #ffffff" points="795.536,498.321 791.972,502.627 797.555,502.895 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" points="795.536,498.321 791.972,502.627 797.555,502.895 "/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke-dasharray: 2; stroke: #ff8484" d="M 795.51,554.953 A 86.6963,86.6963 0 0 0 754.892,403.65"/>
|
||||
<polygon style="fill: #ffffff" points="794.249,553.15 791.641,558.095 797.162,557.214 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ff8484" points="794.249,553.15 791.641,558.095 797.162,557.214 "/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #ff8484;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="792.75" y="458.584">
|
||||
<tspan x="792.75" y="458.584">IBB</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #ff8484;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="792" y="516.808">
|
||||
<tspan x="792" y="516.808">IBB</tspan>
|
||||
</text>
|
||||
<text font-size="12.8" style="fill: #ff8484;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="791.75" y="571.384">
|
||||
<tspan x="791.75" y="571.384">IBB</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #0000ff;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="713.25" y="394.834">
|
||||
<tspan x="713.25" y="394.834">type 7</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #0000ff;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="713" y="384.958">
|
||||
<tspan x="713" y="384.958">type 7</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #0000ff;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="713.25" y="405.458">
|
||||
<tspan x="713.25" y="405.458">type 7</tspan>
|
||||
</text>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 689.334 590.834 C 714.206,590.834 736.628,598.912 761.5,598.912"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="761.71" y1="590.834" x2="761.5" y2="599.412"/>
|
||||
</svg>
|
Before Width: | Height: | Size: 12 KiB |
@@ -1,117 +0,0 @@
|
||||
# Intel Trusted Execution Technology
|
||||
|
||||
Intel TXT allows
|
||||
1. Attestation of the authenticity of a platform and its operating system.
|
||||
2. Assuring that an authentic operating system starts in a
|
||||
trusted environment, which can then be considered trusted.
|
||||
3. Providing of a trusted operating system with additional
|
||||
security capabilities not available to an unproven one.
|
||||
|
||||
Intel TXT requirements:
|
||||
|
||||
1. Intel TXT requires a **TPM** to measure parts of the firmware before it's
|
||||
run on the BSP.
|
||||
2. Intel TXT requires signed **Authenticated Code Modules** ([ACM]s), provided
|
||||
by Intel.
|
||||
3. Intel TXT requires **CPU and Chipset** support (supported since
|
||||
Intel Core 2 Duo/ICH9).
|
||||
|
||||
## Authenticated Code Modules
|
||||
|
||||
The ACMs are Intel digitally signed modules that contain code to be run
|
||||
before the traditional x86 CPU reset vector.
|
||||
|
||||
More details can be found here: [Intel ACM].
|
||||
|
||||
## Modified bootflow with Intel TXT
|
||||
|
||||
With Intel TXT the first instruction executed on the BSP isn't the
|
||||
*reset vector*, but the [Intel ACM].
|
||||
It initializes the TPM and measures parts of the firmware, the IBB.
|
||||
|
||||
### Marking the Initial Boot Block
|
||||
|
||||
Individual files in the CBFS can be marked as IBB.
|
||||
|
||||
More details can be found in the [Intel TXT IBB] chapter.
|
||||
|
||||
### Measurements
|
||||
The IBBs (Initial Boot Blocks) are measured into TPM's PCR0 by the BIOS [ACM]
|
||||
before the CPU reset vector is executed. To indentify the regions that need
|
||||
to be measured, the [FIT] contains one ore multiple *Type 7* entries, that
|
||||
point to the IBBs.
|
||||
|
||||
### Authentication
|
||||
|
||||
After the IBBs have been measured, the ACM decides if the boot firmware is
|
||||
trusted. There exists two validation modes:
|
||||
1. HASH Autopromotion
|
||||
* Uses a known good HASH stored in TPM NVRAM
|
||||
* Doesn't allow to boot a fallback IBB
|
||||
2. Signed BIOS policy
|
||||
* Uses a signed policy stored in flash containing multiple HASHes
|
||||
* The public key HASH of BIOS policy is burned into TPM by manufacturer
|
||||
* Can be updated by firmware
|
||||
* Allows to boot a fallback IBB
|
||||
|
||||
At the moment only *Autopromotion mode* is implemented and tested well.
|
||||
|
||||
In the next step the ACM terminates and the regular x86 CPU reset vector
|
||||
is being executed on the BSP.
|
||||
|
||||
### Protecting Secrets in Memory
|
||||
|
||||
Intel TXT sets the `Secrets in Memory` bit, whenever the launch of the SINIT
|
||||
ACM was successful.
|
||||
The bit is reset when leaving the *MLE* by a regular shutdown or by removing
|
||||
the CMOS battery.
|
||||
|
||||
When `Secrets in Memory` bit is set and the IBB isn't trusted, the memory
|
||||
controller won't be unlocked, resulting in a platform that cannot access DRAM.
|
||||
|
||||
When `Secrets in Memory` bit is set and the IBB is trusted, the memory
|
||||
controller will be unlocked, and it's the responsibility of the firmware to
|
||||
[clear all DRAM] and wipe any secrets of the MLE.
|
||||
The platform will be reset after all DRAM has been wiped and will boot
|
||||
with the `Secrets in Memory` bit cleared.
|
||||
|
||||
### Configuring protected regions for SINIT ACM
|
||||
|
||||
The memory regions used by the SINIT ACM need to be prepared and protected
|
||||
against DMA attacks.
|
||||
The SINIT ACM as well as the SINIT handoff data are placed in memory.
|
||||
|
||||
### Locking TXT register
|
||||
|
||||
As last step the TXT registers are locked.
|
||||
|
||||
Whenever the SINIT ACM is invoked, it verifies that the hardware is in the
|
||||
correct state. If it's not the SINIT ACM will reset the platform.
|
||||
|
||||
## For developers
|
||||
### Configuring Intel TXT in Kconfig
|
||||
Enable ``TEE_INTEL_TXT`` and set the following:
|
||||
|
||||
``TEE_INTEL_TXT_BIOSACM_FILE`` to the path of the BIOS ACM provided by Intel
|
||||
|
||||
``TEE_INTEL_TXT_SINITACM_FILE`` to the path of the SINIT ACM provided by Intel
|
||||
### Print TXT status as early as possible
|
||||
Add platform code to print the TXT status as early as possible, as the register
|
||||
is cleared on cold reset.
|
||||
|
||||
## References
|
||||
More information can be found here:
|
||||
* [Intel TXT Software Development Guide]
|
||||
* [Intel TXT enabling]
|
||||
* [FIT]
|
||||
* [Intel TXT Lab Handout]
|
||||
|
||||
[Intel TXT IBB]: txt_ibb.md
|
||||
[FIT]: ../../soc/intel/fit.md
|
||||
[Intel ACM]: acm.md
|
||||
[ACM]: acm.md
|
||||
[FIT table]: ../../soc/intel/fit.md
|
||||
[clear all DRAM]: ../memory_clearing.md
|
||||
[Intel TXT Lab Handout]: https://downloadmirror.intel.com/18931/eng/Intel%20TXT%20LAB%20Handout.pdf
|
||||
[Intel TXT Software Development Guide]: https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf
|
||||
[Intel TXT enabling]: https://www.intel.com/content/dam/www/public/us/en/documents/guides/txt-enabling-guide.pdf
|
@@ -1,39 +0,0 @@
|
||||
# Intel TXT Initial Boot Block
|
||||
|
||||
The Initial Boot Block (IBB) consists out of one or more files in the CBFS.
|
||||
|
||||
## Constraints
|
||||
|
||||
The IBB must follow the following constrains:
|
||||
* One IBB must contain the reset vector as well as the [FIT table].
|
||||
* The IBB should be as small as possible.
|
||||
* The IBBs must not overlap each other.
|
||||
* The IBB might overlap with microcode.
|
||||
* The IBB must not overlap the BIOS ACM.
|
||||
* The IBB size must be a multiple of 16.
|
||||
* Either one of the following:
|
||||
* The IBB must be able to train the main system memory and clear all secrets.
|
||||
* If the IBB cannot train the main system memory it must verify the code
|
||||
that can train the main system memory and is able to clear all secrets.
|
||||
|
||||
## Identification
|
||||
|
||||
To add the IBBs to the [FIT], all CBFS files are added using the `cbfstool`
|
||||
with the `--ibb` flag set.
|
||||
The flags sets the CBFS file attribute tag to LE `' IBB'`.
|
||||
|
||||
The make system in turn adds all those files to the [FIT] as type 7.
|
||||
|
||||
## Intel TXT measurements
|
||||
|
||||
Each IBB is measured and extended into PCR0 by [Intel TXT], before the CPU
|
||||
reset vector is executed.
|
||||
The IBBs are measured in the order they are listed in the [FIT].
|
||||
|
||||
## FIT schematic
|
||||
|
||||
![][fit_ibb]
|
||||
|
||||
[fit_ibb]: fit_ibb.svg
|
||||
[FIT]: ../../soc/intel/fit.md
|
||||
[Intel TXT]: txt.md
|
@@ -1,48 +0,0 @@
|
||||
# Memory clearing
|
||||
|
||||
The main memory on computer platforms in high security environments contains
|
||||
sensible data. On unexpected reboot the data might persist and could be
|
||||
read by a malicious application in the bootflow or userspace.
|
||||
|
||||
In order to prevent leaking information from pre-reset, the boot firmware can
|
||||
clear the main system memory on boot, wiping all information.
|
||||
|
||||
A common API indicates if the main memory has to be cleared. That could be
|
||||
on user request or by a Trusted Execution Environment indicating that secrets
|
||||
are in memory.
|
||||
|
||||
As every platform has different bring-up mechanisms and memory-layouts, every
|
||||
The device must indicate support for memory clearing as part of the boot
|
||||
process.
|
||||
|
||||
## Requirements
|
||||
|
||||
1. The platform must clear all platform memory (DRAM) if requested
|
||||
2. Code that is placed in DRAM might be skipped (as workaround)
|
||||
3. Stack that is placed in DRAM might be skipped (as workaround)
|
||||
4. All DRAM is cleared with zeros
|
||||
|
||||
## Implementation
|
||||
|
||||
A platform that supports memory clearing selects Kconfig
|
||||
``PLATFORM_HAS_DRAM_CLEAR`` and calls
|
||||
|
||||
```C
|
||||
bool security_clear_dram_request(void);
|
||||
```
|
||||
|
||||
to detect if memory should be cleared.
|
||||
|
||||
The memory is cleared in ramstage as part of `DEV_INIT` stage. It's possible to
|
||||
clear it earlier on some platforms, but on x86 MTRRs needs to be programmed
|
||||
first, which happens in `DEV_INIT`.
|
||||
|
||||
Without MTRRs (and caches enabled) clearing memory takes multiple seconds.
|
||||
## Exceptions
|
||||
|
||||
As some platforms place code and stack in DRAM (FSP1.0), the regions can be
|
||||
skipped.
|
||||
|
||||
## Architecture specific implementations
|
||||
|
||||
* [x86 PAE](../arch/x86/pae.md)
|
@@ -1,324 +0,0 @@
|
||||
# vboot - Verified Boot Support
|
||||
|
||||
Google's verified boot support consists of:
|
||||
|
||||
* A root of trust
|
||||
* Special firmware layout
|
||||
* Firmware verification
|
||||
* Firmware measurements
|
||||
* A firmware update mechanism
|
||||
* Specific build flags
|
||||
* Signing the coreboot image
|
||||
|
||||
Google's vboot verifies the firmware and places measurements within the TPM.
|
||||
|
||||
***
|
||||
|
||||
## Root of Trust
|
||||
|
||||
When using vboot, the root-of-trust is basically the read-only portion of the
|
||||
SPI flash. The following items factor into the trust equation:
|
||||
|
||||
* The GCC compiler must reliably translate the code into machine code
|
||||
without inserting any additional code (virus, backdoor, etc.)
|
||||
* The CPU must reliably execute the reset sequence and instructions as
|
||||
documented by the CPU manufacturer.
|
||||
* The SPI flash must provide only the code programmed into it to the CPU
|
||||
without providing any alternative reset vector or code sequence.
|
||||
* The SPI flash must honor the write-protect input and protect the specified
|
||||
portion of the SPI flash from all erase and write accesses.
|
||||
|
||||
The firmware is typically protected using the write-protect pin on the SPI
|
||||
flash part and setting some of the write-protect bits in the status register
|
||||
during manufacturing. The protected area is platform specific and for x86
|
||||
platforms is typically 1/4th of the SPI flash part size.
|
||||
Because this portion of the SPI flash is hardware write protected, it is not
|
||||
possible to update this portion of the SPI flash in the field, without altering
|
||||
the system to eliminate the ground connection to the SPI flash write-protect pin.
|
||||
Without hardware modifications, this portion of the SPI flash maintains the
|
||||
manufactured state during the system's lifetime.
|
||||
|
||||
***
|
||||
|
||||
## Firmware Layout
|
||||
|
||||
Several sections are added to the firmware layout to support vboot:
|
||||
|
||||
* Read-only section
|
||||
* Google Binary Blob (GBB) area
|
||||
* Read/write section A
|
||||
* Read/write section B
|
||||
|
||||
The following sections describe the various portions of the flash layout.
|
||||
|
||||
### Read-Only Section
|
||||
|
||||
The read-only section contains a coreboot file system (CBFS) that contains all
|
||||
of the boot firmware necessary to perform recovery for the system. This firmware
|
||||
is typically protected using the write-protect pin on the SPI flash part and
|
||||
setting some of the write-protect bits in the status register during
|
||||
manufacturing.
|
||||
The protected area is typically 1/4th of the SPI flash part size and must cover
|
||||
the entire read-only section which consists of:
|
||||
|
||||
* Vital Product Data (VPD) area
|
||||
* Firmware ID area
|
||||
* Google Binary Blob (GBB) area
|
||||
* coreboot file system containing read-only recovery firmware
|
||||
|
||||
### Google Binary Blob (GBB) Area
|
||||
|
||||
The GBB area is part of the read-only section. This area contains a 4096 or 8192
|
||||
bit public root RSA key that is used to verify the *VBLOCK* area to obtain the
|
||||
firmware signing key.
|
||||
|
||||
### Recovery Firmware
|
||||
|
||||
The recovery firmware is contained within a coreboot file system and consists of:
|
||||
|
||||
* reset vector
|
||||
* bootblock
|
||||
* verstage
|
||||
* romstage
|
||||
* postcar
|
||||
* ramstage
|
||||
* payload
|
||||
* flash map file
|
||||
* config file
|
||||
* processor specific files:
|
||||
* Microcode
|
||||
* fspm.bin
|
||||
* fsps.bin
|
||||
|
||||
The recovery firmware is written during manufacturing and typically contains
|
||||
code to write the storage device (eMMC device or hard disk). The recovery image
|
||||
is usually contained on a socketed device such as a USB flash drive or an
|
||||
SD card. Depending upon the payload firmware doing the recovery, it may be
|
||||
possible for the user to interact with the system to specify the recovery
|
||||
image path. Part of the recovery is also to write the A and B areas of the SPI
|
||||
flash device to boot the system.
|
||||
|
||||
### Read/Write Section
|
||||
|
||||
The read/write sections contain an area which contains the firmware signing
|
||||
key and signature and an area containing a coreboot file system with a subset
|
||||
of the firmware. The firmware files in *FW_MAIN_A* and *FW_MAIN_B* are:
|
||||
|
||||
* romstage
|
||||
* postcar
|
||||
* ramstage
|
||||
* payload
|
||||
* config file
|
||||
* processor specific files:
|
||||
* Microcode
|
||||
* fspm.bin
|
||||
* fsps.bin
|
||||
|
||||
The firmware subset enables most issues to be fixed in the field with firmware
|
||||
updates. The firmware files handle memory and most of silicon initialization.
|
||||
These files also produce the tables which get passed to the operating system.
|
||||
|
||||
***
|
||||
|
||||
## Firmware Updates
|
||||
|
||||
The read/write sections exist in one of three states:
|
||||
|
||||
* Invalid
|
||||
* Ready to boot
|
||||
* Successfully booted
|
||||
|
||||
|
||||
Firmware updates are handled by the operating system by writing any read/write
|
||||
section that is not in the "successfully booted" state. Upon the next reboot,
|
||||
vboot determines the section to boot. If it finds one in the "ready to boot"
|
||||
state then it attempts to boot using that section. If the boot fails then
|
||||
vboot marks the section as invalid and attempts to fall back to a read/write
|
||||
section in the "successfully booted" state. If vboot is not able to find a
|
||||
section in the "successfully booted" state then vboot enters recovery mode.
|
||||
|
||||
Only the operating system is able to transition a section from the
|
||||
"ready to boot" state to the "successfully booted" state.
|
||||
The transition is typically done after the operating system has been running
|
||||
for a while indicating that successful boot was possible and the operating
|
||||
system is stable.
|
||||
|
||||
Note that as long as the SPI write protection is in place then the system
|
||||
is always recoverable. If the flash update fails then the system will continue
|
||||
to boot using the previous read/write area. The same is true if coreboot passes
|
||||
control to the payload or the operating system and then the boot fails. In the
|
||||
worst case, the SPI flash gets totally corrupted in which case vboot fails the
|
||||
signature checks and enters recovery mode. There are no times where the SPI
|
||||
flash is exposed and the reset vector or part of the recovery firmware gets
|
||||
corrupted.
|
||||
|
||||
***
|
||||
|
||||
## Build Flags
|
||||
|
||||
The following *Kconfig* values need to be selected to enable vboot:
|
||||
|
||||
* COLLECT_TIMESTAMPS
|
||||
* VBOOT
|
||||
|
||||
The starting stage needs to be specified by selecting either
|
||||
VBOOT_STARTS_IN_BOOTBLOCK or VBOOT_STARTS_IN_ROMSTAGE.
|
||||
|
||||
If vboot starts in bootblock then vboot may be built as a separate stage by
|
||||
selecting `VBOOT_SEPARATE_VERSTAGE`. Additionally, if static RAM is too small
|
||||
to fit both verstage and romstage then selecting `VBOOT_RETURN_FROM_VERSTAGE`
|
||||
enables bootblock to reuse the RAM occupied by verstage for romstage.
|
||||
|
||||
Non-volatile flash is needed for vboot operation. This flash area may be in
|
||||
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`.
|
||||
|
||||
A TPM is also required for vboot operation.
|
||||
TPMs are available in `drivers/i2c/tpm` and `drivers/pc80/tpm`.
|
||||
|
||||
In addition to adding the coreboot files into the read-only region,
|
||||
enabling vboot causes the build script to add the read/write files into
|
||||
coreboot file systems in *FW_MAIN_A* and *FW_MAIN_B*.
|
||||
|
||||
***
|
||||
|
||||
## Signing the coreboot Image
|
||||
|
||||
The following command script is an example of how to sign the coreboot image
|
||||
file. This script is used on the Intel Galileo board and creates the *GBB* area
|
||||
and inserts it into the coreboot image. It also updates the *VBLOCK* areas with
|
||||
the firmware signing key and the signature for the *FW_MAIN* firmware.
|
||||
More details are available in `3rdparty/vboot/README`.
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
#
|
||||
# The necessary tools were built and installed using the following commands:
|
||||
#
|
||||
# pushd 3rdparty/vboot
|
||||
# make
|
||||
# sudo make install
|
||||
# popd
|
||||
#
|
||||
# The keys were made using the following command
|
||||
#
|
||||
# 3rdparty/vboot/scripts/keygeneration/create_new_keys.sh \
|
||||
# --4k --4k-root --output $PWD/keys
|
||||
#
|
||||
#
|
||||
# The "magic" numbers below are derived from the GBB section in
|
||||
# src/mainboard/intel/galileo/vboot.fmd.
|
||||
#
|
||||
# GBB Header Size: 0x80
|
||||
# GBB Offset: 0x611000, 4KiB block number: 1553 (0x611)
|
||||
# GBB Length: 0x7f000, 4KiB blocks: 127 (0x7f)
|
||||
# COREBOOT Offset: 0x690000, 4KiB block number: 1680 (0x690)
|
||||
# COREBOOT Length: 0x170000, 4KiB blocks: 368 (0x170)
|
||||
#
|
||||
# 0x7f000 (GBB Length) = 0x80 + 0x100 + 0x1000 + 0x7ce80 + 0x1000
|
||||
#
|
||||
# Create the GBB area blob
|
||||
# Parameters: hwid_size,rootkey_size,bmpfv_size,recoverykey_size
|
||||
#
|
||||
gbb_utility -c 0x100,0x1000,0x7ce80,0x1000 gbb.blob
|
||||
|
||||
#
|
||||
# Copy from the start of the flash to the GBB region into the signed flash
|
||||
# image.
|
||||
#
|
||||
# 1553 * 4096 = 0x611 * 0x1000 = 0x611000, size of area before GBB
|
||||
#
|
||||
dd conv=fdatasync ibs=4096 obs=4096 count=1553 \
|
||||
if=build/coreboot.rom of=build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Append the empty GBB area to the coreboot.rom image.
|
||||
#
|
||||
# 1553 * 4096 = 0x611 * 0x1000 = 0x611000, offset to GBB
|
||||
#
|
||||
dd conv=fdatasync obs=4096 obs=4096 seek=1553 if=gbb.blob \
|
||||
of=build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Append the rest of the read-only region into the signed flash image.
|
||||
#
|
||||
# 1680 * 4096 = 0x690 * 0x1000 = 0x690000, offset to COREBOOT area
|
||||
# 368 * 4096 = 0x170 * 0x1000 = 0x170000, length of COREBOOT area
|
||||
#
|
||||
dd conv=fdatasync ibs=4096 obs=4096 skip=1680 seek=1680 count=368 \
|
||||
if=build/coreboot.rom of=build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Insert the HWID and public root and recovery RSA keys into the GBB area.
|
||||
#
|
||||
gbb_utility \
|
||||
--set --hwid='Galileo' \
|
||||
-r $PWD/keys/recovery_key.vbpubk \
|
||||
-k $PWD/keys/root_key.vbpubk \
|
||||
build/coreboot.signed.rom
|
||||
|
||||
#
|
||||
# Sign the read/write firmware areas with the private signing key and update
|
||||
# the VBLOCK_A and VBLOCK_B regions.
|
||||
#
|
||||
3rdparty/vboot/scripts/image_signing/sign_firmware.sh \
|
||||
build/coreboot.signed.rom \
|
||||
$PWD/keys \
|
||||
build/coreboot.signed.rom
|
||||
```
|
||||
|
||||
***
|
||||
|
||||
## Boot Flow
|
||||
|
||||
The reset vector exist in the read-only area and points to the bootblock
|
||||
entry point. The only copy of the bootblock exists in the read-only area
|
||||
of the SPI flash. Verstage may be part of the bootblock or a separate stage.
|
||||
If separate then the bootblock loads verstage from the read-only area and
|
||||
transfers control to it.
|
||||
|
||||
Upon first boot, verstage attempts to verify the read/write section A.
|
||||
It gets the public root key from the GBB area and uses that to verify the
|
||||
*VBLOCK* area in read-write section A. If the *VBLOCK* area is valid then it
|
||||
extracts the firmware signing key (1024-8192 bits) and uses that to verify
|
||||
the *FW_MAIN_A* area of read/write section A. If the verification is successful
|
||||
then verstage instructs coreboot to use the coreboot file system in read/write
|
||||
section A for the contents of the remaining boot firmware (romstage, postcar,
|
||||
ramstage and the payload).
|
||||
|
||||
If verification fails for the read/write area and the other read/write area is
|
||||
not valid vboot falls back to the read-only area to boot into system recovery.
|
||||
|
||||
***
|
||||
|
||||
## Chromebook Special Features
|
||||
|
||||
Google's Chromebooks have some special features:
|
||||
|
||||
* Developer mode
|
||||
* Write-protect screw
|
||||
|
||||
### Developer Mode
|
||||
|
||||
Developer mode allows the user to use coreboot to boot another operating system.
|
||||
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
|
||||
security to access files on the local system or cloud.
|
||||
|
||||
### Write Protect Screw
|
||||
|
||||
Chromebooks have a write-protect screw which provides the ground to the
|
||||
write-protect pin of the SPI flash.
|
||||
Google specifically did this to allow the manufacturing line and advanced
|
||||
developers to re-write the entire SPI flash part. Once the screw is removed,
|
||||
any firmware may be placed on the device.
|
||||
However, accessing this screw requires opening the case and voids the
|
||||
system warranty!
|
@@ -1,8 +1,6 @@
|
||||
# Measured Boot
|
||||
coreboot measured boot is implemented as Google Verified Boot extension. This
|
||||
means in order to use it, vboot needs to be available for your platform. The
|
||||
goal of this implementation is to implement an easy to understand and
|
||||
transparent measured boot mechanism.
|
||||
means in order to use it, vboot needs to be available for your platform.
|
||||
|
||||
## IBB/CRTM
|
||||
The "Initial Boot Block" or "Core Root of Trust for Measurement" is the first
|
||||
@@ -23,85 +21,10 @@ measured boot extension because of platform constraints.
|
||||
The "Static Root of Trust for Measurement" is the easiest way doing measurements
|
||||
by measuring code before it is loaded.
|
||||
|
||||
### Measurements
|
||||
SRTM mode measurements are done starting with the IBB as root of trust.
|
||||
Only CBFS contents are measured at the moment.
|
||||
|
||||
#### CBFS files (stages, blobs)
|
||||
* CBFS data is measured as raw data before decompression happens.
|
||||
* CBFS header is excluded from measurements.
|
||||
* Measurements are stored in PCR 2.
|
||||
|
||||
#### Runtime Data
|
||||
* CBFS data which changes by external input dynamically. Never stays the same.
|
||||
* It is identified by VBOOT_MEASURED_BOOT_RUNTIME_DATA kconfig option and
|
||||
measured into a different PCR 3 in order to avoid PCR pre-calculation issues.
|
||||
|
||||
![][srtm]
|
||||
|
||||
[srtm]: srtm.png
|
||||
|
||||
### TCPA eventlog
|
||||
coreboot makes use of its own TCPA log implementation. Normally the eventlog
|
||||
specification can be found via the TCG homepage:
|
||||
|
||||
[UEFI Specification](https://trustedcomputinggroup.org/resource/tcg-efi-platform-specification/)
|
||||
|
||||
[BIOS Specification](https://www.trustedcomputinggroup.org/wp-content/uploads/TCG_PCClientImplementation_1-21_1_00.pdf)
|
||||
|
||||
Both of them are not representing firmware measurements in a generalized way.
|
||||
Therefore we have to implement our own solution.
|
||||
|
||||
We decided to provide an easy to understand TCPA log which can be read out
|
||||
from the operating system and firmware itself.
|
||||
|
||||
#### Table Format
|
||||
The first column describes the PCR index used for measurement.
|
||||
The second column is the hash of the raw data. The third column contains
|
||||
the hash algorithm used in the operation. The last column provides
|
||||
information about what is measured. First the namespace from where the data
|
||||
came from, CBFS or FMAP, then the name used to look up the data
|
||||
(region or file name).
|
||||
|
||||
#### Example:
|
||||
```bash
|
||||
PCR-2 e8f2b57c9ec5ea06d1bbd3240a753974d4c3e7c8cd305c20a8ea26eed906dc89 SHA256 [FMAP: COREBOOT CBFS: bootblock]
|
||||
PCR-2 309a5fcb231d3a39127de2521792f332f9a69e05675ec52535d2dcded756dc19 SHA256 [FMAP: COREBOOT CBFS: fallback/verstage]
|
||||
PCR-2 0fbba07a833d4dcfc7024eaf313661a0ba8f80a05c6d29b8801c612e10e60dee SHA256 [FMAP: RO_VPD]
|
||||
PCR-2 431681113ed44cbf6f68a12c6e5687e901052f1d728a4777b2ad36e559962047 SHA256 [FMAP: GBB]
|
||||
PCR-2 f47a8ec3e9aff2318d896942282ad4fe37d6391c82914f54a5da8a37de1300c6 SHA256 [FMAP: SI_DESC]
|
||||
PCR-3 237f6f567f8597dbdff0a00690d34d21616af0dbe434b9a2d432b136c012765f SHA256 [FMAP: SI_ME]
|
||||
PCR-2 7d2c7ac4888bfd75cd5f56e8d61f69595121183afc81556c876732fd3782c62f SHA256 [FMAP: SI_GBE]
|
||||
PCR-0 62571891215b4efc1ceab744ce59dd0b66ea6f73 SHA1 [GBB flags]
|
||||
PCR-1 a66c8c2cda246d332d0c2025b6266e1e23c89410051002f46bfad1c9265f43d0 SHA256 [GBB HWID]
|
||||
PCR-2 ceca357524caf8fc73f5fa130f05a75293031962af884e18990d281eb259f5ff SHA256 [FMAP: FW_MAIN_B CBFS: fallback/romstage]
|
||||
PCR-2 548a097604e0a975de76f98b04c7f0b0ddec03883dd69179e47a784704a1c571 SHA256 [FMAP: FW_MAIN_B CBFS: fspm.bin]
|
||||
PCR-2 1e86b27008818244c221df2436b0113bd20a86ec6ec9d8259defe87f45d2f604 SHA256 [FMAP: FW_MAIN_B CBFS: spd2.bin]
|
||||
PCR-2 05d78005fcfc9edd4ca5625f11b1f49991d17bdb7cee33b72e722bc785db55ae SHA256 [FMAP: FW_MAIN_B CBFS: fallback/postcar]
|
||||
PCR-2 c13e95829af12a584046f1a6f3e1f6e4af691209324cfeeec573633399384141 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/ramstage]
|
||||
PCR-2 a6ec2761b597abd252dba2a7237140ef4a5a8e0d47cad8afb65fa16314413401 SHA256 [FMAP: FW_MAIN_B CBFS: cpu_microcode_blob.bin]
|
||||
PCR-2 c81ffa40df0b6cd6cfde4f476d452a1f6f2217bc96a3b98a4fa4a037ee7039cf SHA256 [FMAP: FW_MAIN_B CBFS: fsps.bin]
|
||||
PCR-2 4e95f57bbf3c6627eb1c72be9c48df3aaa8e6da4f5f63d85e554cf6803505609 SHA256 [FMAP: FW_MAIN_B CBFS: vbt.bin]
|
||||
PCR-3 b7663f611ecf8637a59d72f623ae92a456c30377d4175e96021c85362f0323c8 SHA256 [FMAP: RW_NVRAM]
|
||||
PCR-2 178561f046e2adbc621b12b47d65be82756128e2a1fe5116b53ef3637da700e8 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/dsdt.aml]
|
||||
PCR-2 091706f5fce3eb123dd9b96c15a9dcc459a694f5e5a86e7bf6064b819a8575c7 SHA256 [FMAP: FW_MAIN_B CBFS: fallback/payload]
|
||||
```
|
||||
|
||||
#### Dump TCPA eventlog in the OS:
|
||||
```bash
|
||||
cbmem -L
|
||||
```
|
||||
|
||||
#### Get CBFS file and print the hash
|
||||
```bash
|
||||
cbfstool coreboot.rom extract -r COREBOOT -n fallback/romstage -U -f /dev/stdout | sha256sum
|
||||
```
|
||||
|
||||
#### Get FMAP partition and print the hash
|
||||
```bash
|
||||
cbfstool coreboot.rom read -n SI_ME -f /dev/stdout | sha256sum
|
||||
```
|
||||
|
||||
## DRTM Mode
|
||||
The "Dynamic Root of Trust for Measurement" is realised by platform features
|
||||
like Intel TXT or Boot Guard. The features provide a way of loading a signed
|
||||
@@ -119,21 +42,17 @@ PCR-7 are left empty.
|
||||
|
||||
### PCR-0
|
||||
_Hash:_ SHA1
|
||||
|
||||
_Description:_ Google VBoot GBB flags.
|
||||
|
||||
### PCR-1
|
||||
_Hash:_ SHA1/SHA256
|
||||
|
||||
_Description:_ Google VBoot GBB HWID.
|
||||
|
||||
### PCR-2
|
||||
_Hash:_ SHA1/SHA256
|
||||
|
||||
_Description:_ Core Root of Trust for Measurement which includes all stages,
|
||||
data and blobs.
|
||||
|
||||
### PCR-3
|
||||
_Hash:_ SHA1/SHA256
|
||||
|
||||
_Description:_ Runtime data like hwinfo.hex or MRC cache.
|
||||
|
@@ -1,224 +0,0 @@
|
||||
# AMD Family 17h in coreboot
|
||||
|
||||
## Abstract
|
||||
|
||||
Beginning with Family 17h products (a.k.a. “Zen” cores), AMD
|
||||
changed their paradigm for initializing the system and this requires
|
||||
major modifications to the execution flow of coreboot. This file
|
||||
discusses the new boot flow, and challenges, and the tradeoffs of the
|
||||
initial port into coreboot.
|
||||
|
||||
## Introduction
|
||||
|
||||
Family 17h products are x86-based designs. This documentation assumes
|
||||
familiarity with x86, its reset state and its early initialization
|
||||
requirements.
|
||||
|
||||
To the extent necessary, the role of the Platform Security Processor
|
||||
(a.k.a. PSP) in system initialization is addressed here. AMD has
|
||||
historically required an NDA for access to the PSP
|
||||
specification<sup>1</sup>. coreboot relies on util/amdfwtool to build
|
||||
the structures and add various other firmware to the final image. The
|
||||
Family 17h PSP design guide adds a new BIOS Directory Table, similar to
|
||||
the PSP Directory Table.
|
||||
|
||||
Support in coreboot for modern AMD products is based on AMD’s
|
||||
reference code: AMD Generic Encapsulated Software Architecture
|
||||
(AGESA<sup>TM</sup>). AGESA contains the technology for enabling DRAM,
|
||||
configuring proprietary core logic, assistance with generating ACPI
|
||||
tables, and other features.
|
||||
|
||||
AGESA for products earlier than Family 17h is known as v5 or
|
||||
Arch2008<sup>2</sup>. Also note that coreboot currently contains both
|
||||
open source AGESA and closed source implementations (binaryPI) compiled
|
||||
from AGESA.
|
||||
|
||||
The first AMD Family 17h device ported to coreboot is codenamed
|
||||
“Picasso”<sup>3</sup>, and will be added to soc/amd/picasso.
|
||||
|
||||
## Additional Definitions
|
||||
|
||||
* PSP, Platform Security Processor: Onboard ARM processor that runs
|
||||
alongside the main x86 processor; may be viewed as analogous to the
|
||||
Intel<sup>R</sup> Management Engine
|
||||
* FCH, Fusion Control Hub, the logical southbridge within the SOC
|
||||
* ABL - AGESA Bootloader - Processor initialization code that runs on
|
||||
the PSP
|
||||
* PSP Directory Table - A structured list of pointers to PSP firmware
|
||||
and other controller binaries
|
||||
* BIOS Directory Table - A structured list of pointers to BIOS
|
||||
related firmware images
|
||||
* Embedded Firmware Structure - Signature and pointers used by the
|
||||
PSP to locate the PSP Directory Table and BIOS Directory Table; these
|
||||
items are generated during coreboot build and are located in the SPI ROM
|
||||
* Verstage - The code to verify the firmware contained in the
|
||||
writable section of the SPI ROM
|
||||
* APCB - AMD PSP Customization Block - A binary containing PSP and
|
||||
system configuration preferences (analogous to v5 BUILDOPT_ options),
|
||||
and generated by APCBTool to be added to coreboot/utils later
|
||||
* APOB - AGESA PSP Output Buffer - A buffer in main memory for
|
||||
storing AGESA BootLoader output. There are no plans for this to be
|
||||
parsed by coreboot
|
||||
|
||||
## Problem Statements
|
||||
|
||||
AMD has ported early AGESA features to the PSP, which now discovers,
|
||||
enables and trains DRAM. Unlike any other x86 device in coreboot, a
|
||||
Picasso system has DRAM online prior to the first instruction fetch.
|
||||
|
||||
Cache-as-RAM (CAR) is no longer a supportable feature in AMD hardware.
|
||||
Early code expecting CAR behavior <span
|
||||
style="text-decoration:underline;">must</span> account for writes
|
||||
escaping the L2 cache and going to DRAM.
|
||||
|
||||
Without any practical need for CAR, or DRAM initialization, coreboot
|
||||
should arguably skip bootblock and romstage, and possibly use ramstage
|
||||
as the BIOS image. This approach presents a number of challenges:
|
||||
|
||||
* At the entry of ramstage, x86 processors are in flat protected
|
||||
mode. Picasso’s initial state is nearly identical to any other x86
|
||||
at reset, except its CS shadow register’s base and limit put its
|
||||
execution within DRAM, not at 0xfffffff0. Picasso requires initial
|
||||
programming and entry into protected mode prior to ramstage.
|
||||
* coreboot expects cbmem initialization during romstage.
|
||||
|
||||
AGESA supporting Picasso is now at v9. Unlike Arch2008, which defines
|
||||
granular entry points for easy inclusion to a legacy BIOS, v9 is
|
||||
rewritten for compilation into a UEFI. The source follows UEFI
|
||||
standards, i.e. assumes the presence of UEFI phases, implements
|
||||
dependency expressions, much functionality is rewritten as libraries,
|
||||
etc. It would, in no way, fit into the v5 model used in coreboot.
|
||||
|
||||
* For the foreseeable future, AGESA source will distributed only
|
||||
under NDA.
|
||||
|
||||
## Basic Pre-x86 Boot Flow
|
||||
|
||||
The following steps occur prior to x86 processor operation.
|
||||
|
||||
* System power on
|
||||
* PSP executes immutable on-chip boot ROM
|
||||
* PSP locates the Embedded Firmware Table and PSP Directory Table in
|
||||
the SPI ROM
|
||||
* PSP verifies and executes the PSP off-chip bootloader
|
||||
* ChromeOS systems:
|
||||
* Off-chip bootloader attempts to locate verstage via the RO BIOS
|
||||
Directory Table
|
||||
* If verstage is not found, booting continues with ABLs below
|
||||
* Verstage initializes, setting up GPIOs, UART if needed,
|
||||
communication path to the EC, and the SPI controller for direct access
|
||||
to the flash device.
|
||||
* Verstage verifies the RW sections (as is typically performed by
|
||||
the main processor)
|
||||
* Verstage locates the Embedded Firmware Directory within the
|
||||
verified FMAP section and passes a pointer to the PSP bootloader. If
|
||||
the verification fails, it passes a pointer to the RO header to the
|
||||
bootloader.
|
||||
* PSP parses the PSP Directory Table to find the ABLs and executes
|
||||
them
|
||||
* An ABL parses the APCB for system configuration preferences
|
||||
* An ABL initializes system main memory, locates the compressed BIOS
|
||||
image in the SPI ROM, and decompresses it into DRAM
|
||||
* An ABL writes the APOB to DRAM for consumption by the x86-based
|
||||
AGESA
|
||||
* PSP releases the x86 processor from reset. The x86 core fetches
|
||||
and executes instructions from the reset vector
|
||||
|
||||
## Picasso Reset Vector and First Instructions
|
||||
|
||||
As mentioned above, prior to releasing the x86 main core from reset,
|
||||
the PSP decompresses a BIOS image into DRAM. The PSP uses a specific
|
||||
BIOS Directory Table entry type to determine the source address (in
|
||||
flash), the destination address (in DRAM), and the destination size.
|
||||
The decompressed image is at the top of the destination region. The
|
||||
PSP then
|
||||
|
||||
Calculates the x86 reset vector as
|
||||
|
||||
reset_vector = dest_addr + dest_size - 0x10
|
||||
|
||||
Sets x86 CS descriptor shadow register to
|
||||
|
||||
base = dest_addr + dest_size - 0x10000
|
||||
limit = 0xffff
|
||||
|
||||
Like all x86 devices, the main core is allowed to begin executing
|
||||
instructions with
|
||||
|
||||
CS:IP = 0xf000:0xfff0
|
||||
|
||||
For example, assume the BIOS Directory Table indicates
|
||||
|
||||
destination = 0x9b00000
|
||||
size = 0x300000
|
||||
|
||||
… then the BIOS image is placed at the topmost position the region
|
||||
0x9b00000-0x9dfffff and
|
||||
|
||||
reset_vector = 0x9dffff0
|
||||
CS_shdw_base = 0x9df0000
|
||||
CS:IP = 0xf000:0xfff0
|
||||
|
||||
Although the x86 behaves as though it began executing at 0xfffffff0
|
||||
i.e. 0xf000:0xfff0, the initial GDT load must use the physical address
|
||||
of the table and not the typical CS-centric address. And, the first
|
||||
jump to protected mode must jump to the physical address in DRAM. Any
|
||||
code that is position-dependent must be linked to run at the final
|
||||
destination.
|
||||
|
||||
## Initial coreboot Implementation
|
||||
|
||||
Supporting Picasso doesn’t fit well with many of the coreboot
|
||||
assumptions. Initial porting shall attempt to fit within existing
|
||||
coreboot paradigms and make minimal changes to common code.
|
||||
|
||||
### CAR and bootblock
|
||||
|
||||
The coreboot bootblock contains features Picasso doesn’t require or
|
||||
can’t use, and is assumed to execute in an unusable location.
|
||||
Picasso’s requirement for bootblock in coreboot will be eliminated.
|
||||
|
||||
### Hybrid romstage
|
||||
|
||||
Picasso’s x86 reset state doesn’t meet the coreboot expectations
|
||||
for jumping directly to ramstage. The primary feature of romstage is
|
||||
also not needed, however there are other important features that are
|
||||
typically in romstage that Picasso does need.
|
||||
|
||||
The romstage architecture is designed around the presence of CAR.
|
||||
Several features implement ROMSTAGE_CBMEM_INIT_HOOK, expecting to move
|
||||
data from CAR to cbmem. The hybrid romstage consumes DRAM for the
|
||||
purpose of implementing the expected CAR storage. This region as well
|
||||
as the DRAM where romstage is decompressed must be reserved and
|
||||
unavailable to the OS.
|
||||
|
||||
The initial Picasso port implements a hybrid romstage that contains the
|
||||
first instruction fetched at the reset vector. It minimally configures
|
||||
flat protected mode, initializes cbmem, then loads the next stage.
|
||||
Future work will consider breaking the dependencies mentioned above
|
||||
and/or potentially loading ramstage directly from the PSP.
|
||||
|
||||
## AGESA v9 on Picasso
|
||||
|
||||
Due to the current inability to publish AGESA source, a pre-built
|
||||
binary solution remains a requirement. The rewrite from v5 to v9 for
|
||||
direct inclusion into UEFI source makes modifying it for conforming to
|
||||
the existing v5 interface impractical.
|
||||
|
||||
Given the UEFI nature of modern AGESA, and the existing open source
|
||||
work from Intel, Picasso shall support AGESA via an FSP-like prebuilt
|
||||
image. The Intel Firmware Support Package<sup>4</sup> combines
|
||||
reference code with EDK II source to create a modular image with
|
||||
discoverable entry points. coreboot source already contains knowledge
|
||||
of FSP, how to parse it, integrate it, and how to communicate with it.
|
||||
|
||||
## Footnotes
|
||||
|
||||
1. “AMD Platform Security Processor BIOS Architecture Design Guide
|
||||
for AMD Family 17h Processors” (PID #55758) and “AMD Platform
|
||||
Security Processor BIOS Architecture Design Guide” (PID #54267) for
|
||||
earlier products
|
||||
2. [https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf](https://www.amd.com/system/files/TechDocs/44065_Arch2008.pdf)
|
||||
3. [https://en.wikichip.org/wiki/amd/cores/picasso](https://en.wikichip.org/wiki/amd/cores/picasso)
|
||||
4. [https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html](https://www.intel.com/content/www/us/en/intelligent-systems/intel-firmware-support-package/intel-fsp-overview.html)
|
||||
|
@@ -1,8 +0,0 @@
|
||||
# AMD SOC-specific documentation
|
||||
|
||||
This section contains documentation about coreboot on specific AMD SOCs.
|
||||
|
||||
## Technology
|
||||
|
||||
- [Family 17h](family17h.md)
|
||||
|
@@ -4,6 +4,5 @@ This section contains documentation about coreboot on specific SOCs.
|
||||
|
||||
## Vendor
|
||||
|
||||
- [AMD](amd/index.md)
|
||||
- [Cavium](cavium/index.md)
|
||||
- [Intel](intel/index.md)
|
||||
|
@@ -1,122 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
|
||||
<svg width="38cm" height="18cm" viewBox="118 98 744 344" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="620" y="100" width="180" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="620" y="100" width="180" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="710" y="134.425">
|
||||
<tspan x="710" y="134.425">DEVICE_EXTENSION</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="300" y="100" width="320" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="300" y="100" width="320" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="460" y="134.425">
|
||||
<tspan x="460" y="134.425">BIOS</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="240" y="100" width="60" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="240" y="100" width="60" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="270" y="134.425">
|
||||
<tspan x="270" y="134.425">IFD</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="200" y="240" width="80" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="200" y="240" width="80" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="240" y="274.425">
|
||||
<tspan x="240" y="274.425">IFWI</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 200 240 C 200,160 460,220 460,169.736"/>
|
||||
<polygon style="fill: #000000" points="460,162.236 465,172.236 460,169.736 455,172.236 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="460,162.236 465,172.236 460,169.736 455,172.236 "/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 700 240 C 700,160 460,220 460,169.736"/>
|
||||
<polygon style="fill: #000000" points="460,162.236 465,172.236 460,169.736 455,172.236 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="460,162.236 465,172.236 460,169.736 455,172.236 "/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="800" y="100" width="60" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="800" y="100" width="60" height="60"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="320" y="380" width="60" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="320" y="380" width="60" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="350" y="414.425">
|
||||
<tspan x="350" y="414.425">FMAP</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="440" y="380" width="100" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="440" y="380" width="100" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="490" y="414.425">
|
||||
<tspan x="490" y="414.425">CONSOLE</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="540" y="380" width="160" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="540" y="380" width="160" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="620" y="414.425">
|
||||
<tspan x="620" y="414.425">COREBOOT(CBFS)</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="700" y="380" width="140" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="700" y="380" width="140" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="770" y="414.425">
|
||||
<tspan x="770" y="414.425">BIOS_UNUSABLE</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="380" y="380" width="60" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="380" y="380" width="60" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="410" y="414.425">
|
||||
<tspan x="410" y="414.425">MRC</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="280" y="240" width="420" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="280" y="240" width="420" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="490" y="274.425">
|
||||
<tspan x="490" y="274.425">OBB</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 320 380 C 320,300 490,360 490,311"/>
|
||||
<polygon style="fill: #000000" points="495,311 490,301 485,311 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="495,311 490,301 485,311 "/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 840 380 C 840,300 490,360 490,311"/>
|
||||
<polygon style="fill: #000000" points="495,311 490,301 485,311 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="495,311 490,301 485,311 "/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="120" y="380" width="60" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="120" y="380" width="60" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="150" y="414.425">
|
||||
<tspan x="150" y="414.425">TXE</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="180" y="380" width="120" height="60"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 3; stroke: #000000" x="180" y="380" width="120" height="60"/>
|
||||
</g>
|
||||
<text font-size="12.8" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:700" x="240" y="414.425">
|
||||
<tspan x="240" y="414.425">BOOTBLOCK</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 300 380 C 300,320 240,360 240,311"/>
|
||||
<polygon style="fill: #000000" points="245,311 240,301 235,311 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="245,311 240,301 235,311 "/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 120 380 C 120,320 240,360 240,311"/>
|
||||
<polygon style="fill: #000000" points="245,311 240,301 235,311 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" points="245,311 240,301 235,311 "/>
|
||||
</g>
|
||||
</svg>
|
Before Width: | Height: | Size: 7.3 KiB |
@@ -1,17 +0,0 @@
|
||||
# Apollolake
|
||||
## SPI flash layout
|
||||
|
||||
![][apl_flash_layout]
|
||||
|
||||
With Apollolake Intel invented another flash layout for x86 firmware called IFWI (Intel FirmWare Image).
|
||||
|
||||
Usually on x86 platforms the bootblock is stored at the end of the bios region
|
||||
and the Intel ME / TXE has its own IFD region. On Apollolake both have been
|
||||
moved into the IFWI region, which is a subregion of "BIOS", since it allows to
|
||||
store multiple firmware components.
|
||||
|
||||
The IFWI region can be manipulated by `ifwitool`.
|
||||
|
||||
[apl_flash_layout]: flash_layout.svg
|
||||
|
||||
|
@@ -1,60 +0,0 @@
|
||||
# Intel Firmware Interface Table
|
||||
|
||||
The FIT allows to run code before the actual IA32 reset vector is executed
|
||||
by the CPU. The FIT resides in the BIOS region (usually near the reset vector)
|
||||
and is pointed to by the FIT pointer residing at `0xFFFFFFC0`.
|
||||
|
||||
## Table layout
|
||||
The table consists of blocks each 16 bytes in size.
|
||||
The first is called *FIT header* the other are called *FIT entry*.
|
||||
|
||||
![FIT in x86 memory map][fit]
|
||||
|
||||
[fit]: fit.svg
|
||||
|
||||
## Fit types
|
||||
|
||||
Each entry has a *type* that give the other bits in the entry a different
|
||||
meaning. The following types are known:
|
||||
|
||||
```eval_rst
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| no. | Description |
|
||||
+===========+==================================================================+
|
||||
| 0x0 | HEADER. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x1 | MICROCODE. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x2 | STARTUP_ACM. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x7 | BIOS_STARTUP_MODULE. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x8 | TPM_POLICY. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x9 | BIOS_POLICY. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0xa | TXT_POLICY. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0xb | KEY_MANIFEST. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0xc | BOOT_POLICY_MANIFEST. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x10 | CSE_SECURE_BOOT. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x2d | TXTSX_POLICY. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x2f | JMP_DEBUG_POLICY. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
| 0x7f | SKIP. |
|
||||
+-----------+------------------------------------------------------------------+
|
||||
```
|
||||
|
||||
## Usage in coreboot
|
||||
|
||||
The most common usage of FIT is to use *Type1* to update microcode before
|
||||
execution of the IA32 reset vector happens.
|
||||
|
||||
## References
|
||||
|
||||
* [Intel TXT LAB handout](https://downloadmirror.intel.com/18931/eng/Intel%20TXT%20LAB%20Handout.pdf)
|
||||
* [FIT bios specification](https://www.intel.com/content/dam/www/public/us/en/documents/guides/fit-bios-specification.pdf)
|
@@ -1,132 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/PR-SVG-20010719/DTD/svg10.dtd">
|
||||
<svg width="15cm" height="11cm" viewBox="520 311 299 204" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="521.518" y="312.25" width="296.25" height="201.75"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="521.518" y="312.25" width="296.25" height="201.75"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="689.333" y="321.667" width="72.375" height="173.833"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="689.333" y="321.667" width="72.375" height="173.833"/>
|
||||
<text font-size="12.7998" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="725.521" y="412.483">
|
||||
<tspan x="725.521" y="412.483"></tspan>
|
||||
</text>
|
||||
</g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 603.917 320.833 C 593.071,320.833 601.631,407 590.785,407"/>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 601.667 493.833 C 590.821,493.833 600.131,407.75 589.285,407.75"/>
|
||||
<text font-size="12.7998" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="520.833" y="412">
|
||||
<tspan x="520.833" y="412">bootblock</tspan>
|
||||
</text>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="686.167" y1="352" x2="781.167" y2="352"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="685.8" y1="334.433" x2="780.8" y2="334.433"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="682.8" y1="410.933" x2="777.8" y2="410.933"/>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" d="M 652.833,345.667 A 30.938,30.938 0 0 0 647.806,407.306"/>
|
||||
<polygon style="fill: #0000ff" points="650.775,407.521 646.813,409.595 647.775,407.577 646.738,405.596 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" points="650.775,407.521 646.813,409.595 647.775,407.577 646.738,405.596 "/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.75" y="367" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.75" y="367" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<text font-size="5.64436" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="653" y="323.333">
|
||||
<tspan x="653" y="323.333">4 GiB </tspan>
|
||||
</text>
|
||||
<text font-size="5.64436" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="651.967" y="336.017">
|
||||
<tspan x="651.967" y="336.017">4 GiB - 10h </tspan>
|
||||
</text>
|
||||
<text font-size="5.64436" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="653.633" y="410.183">
|
||||
<tspan x="653.633" y="410.183">4 GiB - x </tspan>
|
||||
</text>
|
||||
<text font-size="5.64436" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="650.967" y="353.183">
|
||||
<tspan x="650.967" y="353.183">4 GiB - 40 h </tspan>
|
||||
</text>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x1="652.458" y1="346" x2="685" y2="345.833"/>
|
||||
<text font-size="7.90222" style="fill: #0000ff;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="707.958" y="348.25">
|
||||
<tspan x="707.958" y="348.25">FIT Ptr</tspan>
|
||||
</text>
|
||||
<text font-size="7.90222" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="692.933" y="330.55">
|
||||
<tspan x="692.933" y="330.55">IA32 reset vec</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="693.183" y="449.25" width="60.2083" height="41.5333"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x="693.183" y="449.25" width="60.2083" height="41.5333"/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" d="M 655.208,326.75 A 61.4124,61.4124 0 0 0 645.824,444.152"/>
|
||||
<polygon style="fill: #ff0000" points="648.64,445.169 644.228,445.895 645.775,444.281 645.412,442.075 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" points="648.64,445.169 644.228,445.895 645.775,444.281 645.412,442.075 "/>
|
||||
</g>
|
||||
<text font-size="5.64436" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="653.683" y="449.95">
|
||||
<tspan x="653.683" y="449.95">4 GiB - z </tspan>
|
||||
</text>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="693.683" y="432" width="60.2083" height="12"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x="693.683" y="432" width="60.2083" height="12"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="693.933" y="416.2" width="60.2083" height="12"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #00ff00" x="693.933" y="416.2" width="60.2083" height="12"/>
|
||||
</g>
|
||||
<text font-size="5.64436" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="653.183" y="432.2">
|
||||
<tspan x="653.183" y="432.2">4 GiB - y </tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="717.208" y="440">
|
||||
<tspan x="717.208" y="440">ACM</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #ff0000;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="706.433" y="467">
|
||||
<tspan x="706.433" y="467">BOOTBLOCK</tspan>
|
||||
<tspan x="706.433" y="475.467">CODE</tspan>
|
||||
</text>
|
||||
<text font-size="6.77333" style="fill: #00ff00;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="714.183" y="424.25">
|
||||
<tspan x="714.183" y="424.25">uCode</tspan>
|
||||
</text>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #ff0000" x1="655.186" y1="327.119" x2="687.728" y2="326.953"/>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.683" y="377.45" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.683" y="377.45" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.75" y="387.95" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.75" y="387.95" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="694.683" y="398.4" width="60.2083" height="10.5"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #0000ff" x="694.683" y="398.4" width="60.2083" height="10.5"/>
|
||||
</g>
|
||||
<text font-size="5.64444" style="fill: #0000ff;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="706.433" y="406.25">
|
||||
<tspan x="706.433" y="406.25">FIT header</tspan>
|
||||
</text>
|
||||
<text font-size="5.64444" style="fill: #0000ff;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="703.933" y="394.95">
|
||||
<tspan x="703.933" y="394.95">Type1 entry</tspan>
|
||||
</text>
|
||||
<text font-size="5.64444" style="fill: #0000ff;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="703.933" y="384.7">
|
||||
<tspan x="703.933" y="384.7">Type2 entry</tspan>
|
||||
</text>
|
||||
<text font-size="5.64444" style="fill: #0000ff;text-anchor:start;font-family:monospace;font-style:normal;font-weight:normal" x="703.683" y="373.95">
|
||||
<tspan x="703.683" y="373.95">Type7 entry</tspan>
|
||||
</text>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #90c9ff" d="M 769.4,417.215 A 13.2412,13.2412 0 0 0 763.208,391.5"/>
|
||||
<polygon style="fill: #90c9ff" points="766.576,417.768 770.608,415.832 769.576,417.816 770.544,419.831 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #90c9ff" points="766.576,417.768 770.608,415.832 769.576,417.816 770.544,419.831 "/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #90c9ff" d="M 770.292,433.842 A 27.5949,27.5949 0 0 0 763.458,381.5"/>
|
||||
<polygon style="fill: #90c9ff" points="767.533,434.943 770.831,431.923 770.418,434.12 771.929,435.769 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #90c9ff" points="767.533,434.943 770.831,431.923 770.418,434.12 771.929,435.769 "/>
|
||||
</g>
|
||||
<g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #90c9ff" d="M 772.011,446.947 A 41.791,41.791 0 0 0 763.458,372.5"/>
|
||||
<polygon style="fill: #90c9ff" points="769.453,448.489 772.095,444.881 772.12,447.117 773.924,448.438 "/>
|
||||
<polygon style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #90c9ff" points="769.453,448.489 772.095,444.881 772.12,447.117 773.924,448.438 "/>
|
||||
</g>
|
||||
<g>
|
||||
<rect style="fill: #ffffff" x="691.268" y="493.5" width="68.5" height="4.25"/>
|
||||
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="691.268" y="493.5" width="68.5" height="4.25"/>
|
||||
</g>
|
||||
<path style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" d="M 689.768 510.25 C 714.502,510.25 736.534,494.5 761.268,494.5"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x1="689.333" y1="495.5" x2="689.018" y2="509.25"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="683.343" y1="430.9" x2="778.343" y2="430.9"/>
|
||||
<line style="fill: none; fill-opacity:0; stroke-width: 1; stroke-dasharray: 4; stroke: #000000" x1="682.843" y1="447.4" x2="777.843" y2="447.4"/>
|
||||
</svg>
|
Before Width: | Height: | Size: 9.7 KiB |
@@ -1,60 +0,0 @@
|
||||
# Intel Firmware Support Package (FSP)-specific documentation
|
||||
|
||||
This section contains documentation about Intel-FSP in public domain.
|
||||
|
||||
## Bugs
|
||||
As Intel doesn't even list known bugs, they are collected here until
|
||||
those are fixed. If possible a workaround is described here as well.
|
||||
|
||||
### BroadwellDEFsp
|
||||
|
||||
* IA32_FEATURE_CONTROL MSR is locked in FSP-M
|
||||
* Release MR2
|
||||
* Writing the MSR is required in ramstage for Intel TXT
|
||||
* Workaround: none
|
||||
* Issue on public tracker: [Issue 10]
|
||||
|
||||
* FSP-S asserts if the thermal PCI device 00:1f.6 is disabled
|
||||
* Release MR2
|
||||
* FSP expects the PCI device to be enabled
|
||||
* FSP expects BARs to be properly assigned
|
||||
* Workaround: Don't disable this PCI device
|
||||
* Issue on public tracker: [Issue 13]
|
||||
|
||||
### KabylakeFsp
|
||||
* MfgId and ModulePartNum in the DIMM_INFO struct are empty
|
||||
* Release 3.7.1
|
||||
* Those values are typically consumed by SMBIOS type 17
|
||||
* Workaround: none
|
||||
* Issue on public tracker: [Issue 22]
|
||||
|
||||
### BraswellFsp
|
||||
* Internal UART can't be disabled using PcdEnableHsuart*
|
||||
* Release MR2
|
||||
* Workaround: Disable internal UART manually after calling FSP
|
||||
* Issue on public tracker: [Issue 10]
|
||||
|
||||
|
||||
## Open Source Intel FSP specification
|
||||
|
||||
* [About Intel FSP](https://firmware.intel.com/learn/fsp/about-intel-fsp)
|
||||
|
||||
* [FSP Specification 1.0](https://www.intel.in/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec.pdf)
|
||||
|
||||
* [FSP Specification 1.1](https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf)
|
||||
|
||||
* [FSP Specification 2.0](https://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf)
|
||||
|
||||
## Additional Features in FSP 2.1 specification
|
||||
|
||||
- [PPI](ppi/ppi.md)
|
||||
|
||||
## Official bugtracker
|
||||
|
||||
- [IntelFSP/FSP](https://github.com/IntelFsp/FSP/issues)
|
||||
|
||||
[Issue 10]: https://github.com/IntelFsp/FSP/issues/10
|
||||
[Issue 13]: https://github.com/IntelFsp/FSP/issues/13
|
||||
[Issue 15]: https://github.com/IntelFsp/FSP/issues/15
|
||||
[Issue 22]: https://github.com/IntelFsp/FSP/issues/22
|
||||
|
@@ -1,14 +0,0 @@
|
||||
# PEIM to PEIM Interface (PPI)
|
||||
|
||||
This section is intended to document the purpose of creating PPI service
|
||||
inside coreboot space to perform some specific operation related to CPU,
|
||||
chipset using Intel FSP. This feature is added into FSP specification 2.1
|
||||
where FSP should be able to locate PPI, published by boot firmware and
|
||||
able to execute the same in FSP's context.
|
||||
|
||||
* [What is PPI](https://www.intel.com/content/dam/www/public/us/en/documents/reference-guides/efi-pei-cis-v09.pdf)
|
||||
|
||||
## List of PPI service
|
||||
|
||||
### Publish MP Service PPI from boot firmware (coreboot) to initialize CPU
|
||||
- [MP Service PPI](mp_service_ppi.md)
|