sravan/system76-coreboot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into system76

Browse Source
This commit is contained in:
Jeremy Soller
2020-05-09 12:56:34 -06:00
parent 0f11811ab7 29fbfcc472
commit f208e51e57
8610 changed files with 89314 additions and 139502 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.gitignore vendored
View File

@@ -54,11 +54,13 @@ util/crossgcc/xgcc
site-local
*.\#
*.a
*.bin
*.debug
!Kconfig.debug
*.elf
*.o
*.o.d
*.out
*.pyc
*.sw[po]
@@ -115,11 +117,9 @@ util/nvramtool/.dependencies
util/nvramtool/nvramtool
util/optionlist/Options.wiki
util/pmh7tool/pmh7tool
util/romcc/build
util/runfw/googlesnow
util/superiotool/superiotool
util/vgabios/testbios
util/viatool/viatool
util/autoport/autoport
util/kbc1126/kbc1126_ec_dump
util/kbc1126/kbc1126_ec_insert

2
3rdparty/intel-microcode vendored

Submodule 3rdparty/intel-microcode updated: 1dd14da6d1...33b7b2f381

2
3rdparty/libgfxinit vendored

Submodule 3rdparty/libgfxinit updated: fe7985f2a0...cdbfce2757

2
3rdparty/vboot vendored

Submodule 3rdparty/vboot updated: 0e97e25e85...3aab301473

118
AUTHORS
View File

@@ -8,78 +8,141 @@
# To see a list of contributors: git log --pretty=format:%an | sort | uniq
# For patches adding or removing a name: git log -i -S "NAME" --source --all
3mdeb Embedded Systems Consulting
9elements Agency GmbH
Abhinav Hardikar
Advanced Computing Lab, LANL
Advanced Micro Devices, Inc.
AdaCore
AG Electronics Ltd.
Alex Thiessen
Alex Züpke
Alexander Couzens
Alexandru Gagniuc
Analog Devices Inc.
Analogix Semiconductor
Andre Heider
Andriy Gapon
Andy Fleming
Angel Pons
Anton Kochkov
ARM Limited and Contributors
Arthur Heymans
Asami Doi
ASPEED Technology Inc.
Atheros Corporation
Atmel Corporation
BAP - Bruhnspace Advanced Projects
Bill Xie
Bitland Tech Inc.
Boris Barbulovski
Carl-Daniel Hailfinger
Cavium Inc.
Christoph Grenz
Code Aurora Forum
coresystems GmbH
Corey Osgood
Curt Brune
Custom Ideas
Damien Zammit
Dave Airlie
David Brownell
David Greenman
David Hendricks
David Mosberger-Tang
David Mueller
Denis 'GNUtoo' Carikli
Denis Dowling
DENX Software Engineering
Derek Waldner
Digital Design Corporation
DMP Electronics Inc.
Donghwa Lee
Drew Eckhardt
Dynon Avionics
Edward O'Callaghan
Egbert Eich
ELSOFT AG
Eltan B.V
Elyes Haouas
Eric Biederman
Eswar Nallusamy
Evgeny Zinoviev
Fabian Kunkel
Fabrice Bellard
Facebook, Inc.
Felix Held
Felix Singer
Frederic Potter
Free Software Foundation, Inc.
Freescale Semiconductor, Inc.
Gary Jennejohn
George Trudeau
Gerald Van Baren
Gerd Hoffmann
Gergely Kiss
Google LLC
Greg Watson
Guennadi Liakhovetski
Hal Martin
HardenedLinux
Hewlett-Packard Development Company, L.P.
Hewlett Packard Enterprise Development LP
Huaqin Telecom Inc.
IBM Corporation
Idwer Vollering
Igor Pavlov
Imagination Technologies
Infineon Technologies
InKi Dae
Intel Corporation
Iru Cai
Isaku Yamahata
Ivan Vatlin
James Ye
Jason Zhao
Joe Pillow
Johanna Schander
Jonas 'Sortie' Termansen
Jonathan A. Kollasch
Jonathan Neuschäfer
Jordan Crouse
Joseph Smith
Keith Hui
Keith Packard
Kevin Cody-Little
Kevin O'Connor
Kontron Europe GmbH
Kshitij
Kyösti Mälkki
Leah Rowe
Lei Wen
Li-Ta Lo
Libra Li
Libretrend LDA
Linaro Limited
Linus Torvalds
Linux Networx, Inc.
LiPPERT ADLINK Technology GmbH
Lubomir Rintel
Luc Verhaegen
Maciej Matuszczyk
Marc Bertens
Marc Jones
Marek Vasut
Marius Gröger
Martin Mares
Martin Renters
Martin Roth
Marvell International Ltd.
Marvell Semiconductor Inc.
Matt DeVillier
Maxim Polyakov
MediaTek Inc.
Michael Brunner
Michael Schroeder
Michael Niewöhner
Mika Westerberg
Mondrian Nuessle
MontaVista Software, Inc.
Myles Watson
@@ -87,69 +150,96 @@ Network Appliance Inc.
Nicholas Sielicki
Nick Barker
Nico Huber
Nico Rikken
Nicola Corna
Nils Jacobs
Nir Tzachar
Nokia Corporation
NVIDIA Corporation
Olivier Langlois
Ollie Lo
Omar Pakker
Online SAS
Orion Technologies, LLC
Patrick Georgi
Patrick Rudolph
Pattrick Hueper
Paulo Alcantara
Pavel Sayekat
PC Engines GmbH
Per Odlund
Peter Korsgaard
Peter Stuge
Philipp Degler
Philipp Deppenwiese
Philipp Hug
Protectli
Purism SPC
Qualcomm Technologies
Raptor Engineering, LLC
Red Hat Inc
Red Hat, Inc
Reinhard Meyer
Renze Nicolai
Richard Spiegel
Richard Woodruff
Rob Landley
Robert Reeves
Robinson P. Tryon
Rockchip, Inc.
Romain Lievin
Roman Zippel
Ronald G. Minnich
Rudolf Marek
Russell King
Ruud Schramp
Sage Electronic Engineering, LLC
Sam Ravnborg
Samsung Electronics
Samuel Holland
SciTech Software, Inc.
Sebastian Grzywna
secunet Security Networks AG
Sencore Inc
Sergej Ivanov
Siemens AG
SiFive, Inc
Silicon Integrated System Corporation
Silverback ltd.
Silverback Ltd.
Stefan Reinauer
Stefan Tauner
Steve Magnani
Steve Shenton
ST Microelectronics
SUSE LINUX AG
Sven Schnelle
Syed Mohammed Khasim
System76
Texas Instruments
The Android Open Source Project
The ChromiumOS Authors
The Linux Foundation
The Regents of the University of California
Thomas Winischhofer
Timothy Pearson
Tobias Diedrich
Tristan Corrick
Tungsten Graphics, Inc.
Tyan Computer Corp.
ucRobotics Inc.
University of Heidelberg
Uwe Hermann
VIA Technologies, Inc
Vikram Narayanan
Vipin Kumar
Vladimir Serbinenko
Vlado Cibic
Wang Qing Pei
Ward Vandewege
Wilbert Duijvenvoorde
Win Enterprises
Wiwynn Corp.
Wolfgang Denk
YADRO
Yann Collet
Yinghai Lu
# Directories transferred
src/acpi
src/arch
src/commonlib
src/console
src/cpu
src/device
src/drivers
src/superio
Zachary Yedidia

2
Documentation/Intel/SoC/soc.html
View File

@@ -657,7 +657,7 @@ Use the following steps to debug the call to TempRamInit:
The EDK2 data structure is defined in
MdeModulePkg/Include/IndustryStandard/<a target="_blank" href="https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/Acpi61.h#l111">Acpi61.h</a>
The coreboot data structure is defined in
src/arch/x86/include/arch/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/include/arch/acpi.h;hb=HEAD#l237">acpi.h</a>
src/arch/x86/include/arch/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/include/acpi/acpi.h;hb=HEAD#l237">acpi.h</a>
</p>
<ol>

2
Documentation/acpi/devicetree.md
View File

@@ -157,7 +157,7 @@ Note that the ACPI_IRQ_WAKE_EDGE_LOW macro informs the platform that the GPIO
will be routed through SCI (ACPI's System Control Interrupt) for use as a wake
source. Also note that the IRQ names are SoC-specific, and you will need to
find the names in your SoC's header file. The ACPI_* macros are defined in
``src/arch/x86/include/arch/acpi_device.h``.
``src/arch/x86/include/acpi/acpi_device.h``.
Using a GPIO as an IRQ requires that it is configured in coreboot correctly.
This is often done in a mainboard-specific file named ``gpio.c``.

9
Documentation/acpi/gpio.md
View File

@@ -73,6 +73,15 @@ calling the platform specific acpigen_soc_{set,clear}_tx_gpio
functions internally. Thus, all the ACPI AML calling conventions for
the platform functions apply to these helper functions as well.
3. Get Rx GPIO
int acpigen_get_rx_gpio(struct acpi_gpio gpio)
This function takes as input, an struct acpi_gpio type and outputs
AML code to read the *logical* value of a gpio (after taking its
polarity into consideration), into the Local0 variable. It calls
the platform specific acpigen_soc_read_rx_gpio() to actually read
the raw Rx gpio value.
## Implementation Details
ACPI library in coreboot will provide weak definitions for all the

5
Documentation/acpi/index.md
View File

@@ -1,6 +1,9 @@
# ACPI-specific documentation
This section contains documentation about coreboot on ACPI.
This section contains documentation about coreboot on ACPI. coreboot dropped
backwards support for ACPI 1.0 and is only compatible to ACPI version 2.0 and
upwards.
- [SSDT UID generation](uid.md)

173
Documentation/contributing/documentation_ideas.md Normal file
View File

@@ -0,0 +1,173 @@
# Documentation Ideas
This section collects ideas to improve the coreboot documentation and
should serve as a pool of ideas for people who want to improve the current
documentation status of coreboot.
The main purpose of this document is to gather documentation ideas for technical
writers of the seasons of docs. Nevertheless anyone who wants to help improving
the current documentation situation can take one of the projects.
Each entry should outline what would be done, the benefit it brings
to the project, the pre-requisites, both in knowledge and parts. They
should also list people interested in supporting people who want to work
on them.
## Restructure Existing Documentation
The goal is to improve the user experience and structure the documentation more
logically. The current situation makes it very hard for beginners, but also for
experienced developers to find anything in the coreboot documentation.
One possible approach to restructure the documentation is to split it up such
that we divide the group of users into:
* (End-)users
Most probably users which _just_ want to use coreboot as fast as possible. This
section should include guidelines on how to build coreboot, how to flash coreboot
and also which hardware is currently supported.
* Developers
This section should more focus on the developer side-of-view. This section would
include how to get started developing coreboot, explaining the basic concepts of
coreboot and also give guideance on how to proceed after the first steps.
* Knowledge area
This section is very tighlight coupled to the developer section and might be merged
into it. The _Knowledge area_ can give a technical deep dive on various drivers,
technologies, etc.
* Community area
This section gives some room for the community: Youtube channels, conferences,
meetups, forums, chat, etc.
A [first approach](https://review.coreboot.org/c/coreboot/+/40327) has already been made here and might be a basis for the work.
Most of the documentation is already there, but scattered around the documentation
folder.
### Requirements
* Understanding on how a different groups of users might use the documentation area
* Basic understanding of how coreboot works (Can be worked out _on-the-fly_)
### Mentors
* christian.walter@9elements.com
* TBD
## Update Howto/Guides
An important part to involve new people in the project, either as developer or
as enduser, are guides and how-to's. There are already some guides which need
to be updated to work, and could also be extended to multiple platforms, like
Fedora or Arch-Linux. Also guidance for setting up coreboot with a Windows
environment would be helpful.
In addition, the vboot guidance needs an update/extensions, that the security
features within coreboot can be used by non-technical people.
For developers, how to debug coreboot and various debugging techniques need
documentation.
### Requirements
* Knowledge of virtual machines, how to install different OSs and set up the
toolchain on different operating systems
* Knowledge of debugging tools like gdb
### Mentors
* christian.walter@9elements.com
* TBD
## How to Support a New Board
coreboot benefits from running on as many platforms as possible. Therefore we
want to encourage new developers on porting existing hardware to coreboot.
Guidance for those new developers need to be made such that they are able to
take the first steps supporting new mainboards, when the SoC support already
exists. There should be a 'how-to' guide for this. Also what are common problems
and how to solve those.
### Requirements
* Knowledge of how to add support for a new mainboard in coreboot
### Mentors
* christian.walter@9elements.com
* TBD
## Payloads
The current documentation of the payloads is not very effective. There should be
more detailed documentation on the payloads that can be selected via the make
menuconfig within coreboot. Also the use-cases should be described in more
detail: When to use which payload? What are the benefits of using payload X over
Y in a specific use-case ?
In addition it should be made clear how additional functionality e.g. extend
LinuxBoot with more commands, can be achieved.
### Requirements
* Basic knowledge of the supported payloads like SeaBIOS, TinanoCore, LinuxBoot,
GRUB, Linux, ...
### Mentors
* christian.walter@9elements.com
* TBD
## coreboot Util Documentation
coreboot inherits a variaty of utilities. The current documentation only
provides a "one-liner" as an explanation. The list of util should be updated
with a more detailed explanation where possible. Also more "in-depths"
explanations should be added with examples if possible.
### Requirements
* coreboot utilities
### Mentors
* christian.walter@9elements.com
* TBD
## CBMEM Developer Guide
CBMEM is the API that provides memory buffers for the use at OS runtime. It's a
core component and thus should be documented. Dos, don'ts and pitfalls when
using CBMEM. This "in-depth" guide is clearly for developers.
### Requirements
* Deep understanding of coreboot's internals
### Mentors
* TBD
* TBD
## CBFS Developer Guide
CBFS is the in-flash filesystem that is used by coreboot. It's a core component
and thus should be documented. Update the existing CBFS.txt that still shows
version 1 of the implementation. A [first approach](https://review.coreboot.org/c/coreboot/+/33663/2)
has been made here.
This "in-depth" guide is clearly for developers.
### Requirements
* Deep understanding of coreboot's internals
### Mentors
* TBD
* TBD
## Region API Developer Guide
The region API is used by coreboot when dealing with memory mapped objects that
can be split into chunks. It's a core component and thus should be documented.
This "in-depth" guide is clearly for developers.
### Requirements
* Deep understanding of coreboot's internals
### Mentors
* TBD
* TBD

110
Documentation/contributing/project_ideas.md
View File

@@ -27,7 +27,9 @@ which is a bad experience when trying to build coreboot the first time.
Provide packages/installers of our compiler toolchain for Linux distros,
Windows, Mac OS. For Windows, this should also include the environment
(shell, make, ...).
(shell, make, ...). A student doesn't have to cover _all_ platforms, but
pick a set of systems that match their interest and knowledge and lay
out a plan on how to do this.
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
@@ -131,26 +133,6 @@ 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
@@ -158,6 +140,11 @@ useful for firmware related work: Automatically parse formats (eg. by
integrating UEFITool, cbfstool, decompressors), automatically identify
16/32/64bit code on x86/amd64, etc.
This has been done in 2019 with [some neat
features](https://github.com/al3xtjames/ghidra-firmware-utils) being
developed, but it may be possible to expand support for all kinds of firmware
analyses.
## 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
@@ -179,3 +166,84 @@ This is a research-heavy project.
### Mentors
* Ron Minnich <rminnich@google.com>
## Libpayload based memtest payload
[Memtest86+](https://www.memtest.org/) has some limitations: first and
foremost it only works on x86, while it can print to serial console the
GUI only works in legacy VGA mode.
This project would involve porting the memtest suite to libpayload and
build a payload around it.
### Requirements
* coreboot knowledge: Should know how to build coreboot images and
include payloads.
* other knowledge: Knowledge on how dram works is a plus.
* hardware requirements: Initial work can happen on qemu targets,
being able to test on coreboot supported hardware is a plus.
### Mentors
* TODO
## Fix POST code handling
coreboot supports writing POST codes to I/O port 80.
There are various Kconfigs that deal with POST codes, which don't have
effect on most platforms.
The code to send POST codes is scattered in C and Assembly, some use
functions, some use macros and others simply use the `outb` instruction.
The POST codes are duplicated between stages and aren't documented properly.
Tasks:
* Guard Kconfigs with a *depends on* to only show on supported platforms
* Remove duplicated Kconfigs
* Replace `outb(0x80, ...)` with calls to `post_code(...)`
* Update Documentation/POSTCODES
* Use defines from console/post_codes.h where possible
* Drop duplicated POST codes
* Make use of all possible 255 values
### Requirements
* knowledge in the coreboot build system and the concept of stages
* other knowledge: Little experience with C and x86 Assembly
* hardware requirements: Nothing special
### Mentors
* Patrick Rudolph <patrick.rudolph@9elements.com>
* Christian Walter <christian.walter@9elements.com>
## Board status replacement
The [Board status page](https://coreboot.org/status/board-status.html) allows
to see last working commit of a board. The page is generated by a cron job
that runs on a huge git repository.
Build an open source replacement written in Golang using existing tools
and libraries, consisting of a backend, a frontend and client side
scripts. The backend should connect to an SQL database with can be
controlled using a RESTful API. The RESTful API should have basic authentication
for managment tasks and new board status uploads.
At least one older test result should be keept in the database.
The frontend should use established UI libraries or frameworks (for example
Angular) to display the current board status, that is if it's working or not
and some details provided with the last test. If a board isn't working the last
working commit (if any) should be shown in addition to the broken one.
Provide a script/tool that allows to:
1. Push mainboard details from coreboot master CI
2. Push mainboard test results from authenticated users containing
* working
* commit hash
* bootlog (if any)
* dmesg (if it's booting)
* timestamps (if it's booting)
* coreboot config
### Requirements
* coreboot knowledge: Non-technical, needed to perform requirements analysis
* software knowledge: Golang, SQL for the backend, JS for the frontend
### Mentors
* Patrick Rudolph <patrick.rudolph@9elements.com>
* Christian Walter <christian.walter@9elements.com>

2
Documentation/drivers/smmstore.md
View File

@@ -22,7 +22,7 @@ The API provides append-only semantics for key/value pairs.
By default SMMSTORE will operate on a separate FMAP region called
`SMMSTORE`. The default generated FMAP will include such a region.
On systems with a locked FMAP, e.g. in an existing VBOOT setup
On systems with a locked FMAP, e.g. in an existing vboot setup
with a locked RO region, the option exists to add a cbfsfile
called `smm_store` in the `RW_LEGACY` (if CHROMEOS) or in the
`COREBOOT` FMAP regions. It is recommended for new builds using

2
Documentation/flash_tutorial/int_flashrom.md
View File

@@ -5,7 +5,7 @@
## Using flashrom
This method does only work on Linux, if it isn't locked down.
You may also need to boot with 'iomem=relaxed' in the kernel command
You may also need to boot with `iomem=relaxed` in the kernel command
line if CONFIG_IO_STRICT_DEVMEM is set.

2
Documentation/getting_started/gpio.md
View File

@@ -25,7 +25,7 @@ how to appropriately set these registers. In addition, some mainboards are
based on a baseboard/variant model, where several variant mainboards may share a
lot of their circuitry and ICs and the commonality between the boards is
collected into a virtual ``baseboard.`` In that case, the GPIOs which are shared
between multiple boards are placed in the baseboard's ``gpio.c` file, while the
between multiple boards are placed in the baseboard's ``gpio.c`` file, while the
ones that are board-specific go into each variant's ``gpio.c`` file.
## Intel SoCs

26
Documentation/gfx/libgfxinit.md
View File

@@ -65,11 +65,20 @@ board can initialize graphics through *libgfxinit*:
select MAINBOARD_HAS_LIBGFXINIT
Internal ports share some hardware blocks (e.g. backlight, panel
power sequencer). Therefore, each board has to select either eDP
or LVDS as the internal port, if any:
power sequencer). Therefore, each system with an integrated panel
should set `GFX_GMA_PANEL_1_PORT` to the respective port, e.g.:
select GFX_GMA_INTERNAL_IS_EDP # the default, or
select GFX_GMA_INTERNAL_IS_LVDS
config GFX_GMA_PANEL_1_PORT
default "DP3"
For the most common cases, LVDS and eDP, exists a shorthand, one
can select either:
select GFX_GMA_PANEL_1_ON_EDP # the default, or
select GFX_GMA_PANEL_1_ON_LVDS
Some newer chips feature a second block of panel control logic.
For this, `GFX_GMA_PANEL_2_PORT` can be set.
Boards with a DVI-I connector share the DDC (I2C) pins for both
analog and digital displays. In this case, *libgfxinit* needs to
@@ -96,7 +105,8 @@ You can select from the following Ports:
type Port_Type is
(Disabled, -- optionally terminates the list
Internal, -- either eDP or LVDS as selected in Kconfig
LVDS,
eDP,
DP1,
DP2,
DP3,
@@ -112,8 +122,7 @@ both DPx and HDMIx should be listed.
A good example is the mainboard Kontron/KTQM77, it features two
DP++ ports (DP2/HDMI2, DP3/HDMI3), one DVI-I port (HDMI1/Analog),
eDP and LVDS. Due to the constraints mentioned above, only one of
eDP and LVDS can be enabled. It defines `ports` as follows:
eDP and LVDS. It defines `ports` as follows:
ports : constant Port_List :=
(DP2,
@@ -122,7 +131,8 @@ eDP and LVDS can be enabled. It defines `ports` as follows:
HDMI2,
HDMI3,
Analog,
Internal,
LVDS,
eDP,
others => Disabled);
The `GMA.gfxinit()` procedure probes for display EDIDs in the

28
Documentation/ifdtool/layout.md
View File

@@ -14,14 +14,26 @@ The names of the IFD regions in the FMAP should follow the convention of
starting with the prefix `SI_` which stands for `silicon initialization` as a
way to categorize anything required by the SoC but not provided by coreboot.
|IFD Region index|IFD Region name|FMAP Name|Notes|
|---|---|---|---|
|0|Flash Descriptor|SI_DESC|Always the top 4KB of flash|
|1|BIOS|SI_BIOS|This is the region that contains coreboot|
|2|Intel ME|SI_ME||
|3|Gigabit Ethernet|SI_GBE||
|4|Platform Data|SI_PDR||
|8|EC Firmware|SI_EC|Most Chrome OS devices do not use this region; EC firmware is stored BIOS region of flash|
```eval_rst
+------------+------------------+-----------+-------------------------------------------+
| IFD Region | IFD Region name | FMAP Name | Notes |
| index | | | |
+============+==================+===========+===========================================+
| 0 | Flash Descriptor | SI_DESC | Always the top 4KB of flash |
+------------+------------------+-----------+-------------------------------------------+
| 1 | BIOS | SI_BIOS | This is the region that contains coreboot |
+------------+------------------+-----------+-------------------------------------------+
| 2 | Intel ME | SI_ME | |
+------------+------------------+-----------+-------------------------------------------+
| 3 | Gigabit Ethernet | SI_GBE | |
+------------+------------------+-----------+-------------------------------------------+
| 4 | Platform Data | SI_PDR | |
+------------+------------------+-----------+-------------------------------------------+
| 8 | EC Firmware | SI_EC | Most Chrome OS devices do not use this |
| | | | region; EC firmware is stored in BIOS |
| | | | region of flash |
+------------+------------------+-----------+-------------------------------------------+
```
## Validation

1
Documentation/index.md
View File

@@ -164,6 +164,7 @@ Contents:
* [Tutorial](tutorial/index.md)
* [Coding Style](coding_style.md)
* [Project Ideas](contributing/project_ideas.md)
* [Documentation Ideas](contributing/documentation_ideas.md)
* [Code of Conduct](community/code_of_conduct.md)
* [Community forums](community/forums.md)
* [Project services](community/services.md)

BIN
Documentation/mainboard/51nb/x210.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 48 KiB

46
Documentation/mainboard/51nb/x210.md Normal file
View File

@@ -0,0 +1,46 @@
# 51NB X210
## Extracting vendor EC firmware
EC firmware is included in the SPI image. To extract it, run:
```
dd bs=64K skip=32 count=1 if=bios.rom of=ec.bin
```
and ensure that you have a file that includes the string "Insyde Software Corp".
## Flashing instructions
This can be performed using the internal SPI controller, even when flashing
from stock firmware. Use `flashrom -p internal` and follow the appropriate
flashrom instructions to force it. Alternatively, external flashing has been
tested with Dediprog SF100 and SF600 and using a Beaglebone Black. The flash
is located on the upper side of the motherboard, below the keyboard
connector. It is circled in red here:
![](x210.jpg)
## Flashing a subset of the ROM
If you want to flash coreboot without extracting firmware blobs, you can
flash coreboot without overwriting those blobs. After building coreboot,
create a layout file with the following content:
```
00000000:001fffff me
00200000:0020ffff ec
00210000:007fffff main
```
and run flashrom with the `--layout rom.layout --image main` arguments. This
will flash the main firmware without overwriting the existing EC or ME
firmware.
## Working
All hardware features are believed to be working, although the SD reader is
untested. Note that certain hotkeys don't work (including the ThinkVantage
button) - this is a limitation of the EC firmware, and these keys also
generate no events under the stock vendor firmware.

2
Documentation/mainboard/asrock/h110m-dvs.md
View File

@@ -31,8 +31,6 @@ 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
```

6
Documentation/mainboard/asus/p8z77-m_pro.md
View File

@@ -1,6 +1,6 @@
# ASUS P8Z77-M Pro
# ASUS P8Z77-M PRO
This page describes how to run coreboot on the [ASUS P8Z77-M Pro]
This page describes how to run coreboot on the [ASUS P8Z77-M PRO]
## Flashing coreboot
@@ -163,6 +163,6 @@ easy to remove and reflash.
- [Flash chip datasheet][W25Q64FVA1Q]
[ASUS P8Z88-M Pro]: https://www.asus.com/Motherboards/P8Z77M_PRO/
[ASUS P8Z77-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

6
Documentation/mainboard/hp/8760w.md
View File

@@ -2,6 +2,9 @@
This page describes how to run coreboot on the [HP EliteBook 8760w].
The coreboot code for this laptop is still not merged, you need to
checkout the [code on gerrit] to build coreboot for the laptop.
## Flashing coreboot
```eval_rst
@@ -29,7 +32,7 @@ This page describes how to run coreboot on the [HP EliteBook 8760w].
## Required proprietary blobs
- Intel Firmware Descriptor, ME and GbE firmware
- EC: please read [EliteBook Series](elitebook_series)
- EC: please read [HP Laptops with KBC1126 Embedded Controller](hp_kbc1126_laptops)
## Flashing instructions
@@ -80,3 +83,4 @@ clip to read and flash the chip.
```
[HP EliteBook 8760w]: https://support.hp.com/us-en/product/hp-elitebook-8760w-mobile-workstation/5071180
[code on gerrit]: https://review.coreboot.org/c/coreboot/+/30936

30
Documentation/mainboard/hp/elitebook_series.md → Documentation/mainboard/hp/hp_kbc1126_laptops.md
View File

@@ -1,13 +1,14 @@
# HP EliteBook series
# HP Laptops with KBC1126 Embedded Controller
This document is about HP EliteBook series laptops up to Ivy Bridge era
which use SMSC KBC1126 as embedded controller.
## EC
SMSC KBC1126 (and older similar chips like KBC1098) has been used in
HP EliteBooks for many generations. BIOS and EC firmware share an SPI
flash chip in these laptops, so we need to put firmware blobs for the
EC to the coreboot image.
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.
## EC firmware extraction and coreboot building
The following document takes EliteBook 2760p as an example.
@@ -32,18 +33,15 @@ Chipset --->
(2760p-fw2.bin) KBC1126 filename #2 path and filename
```
## Super I/O
## Porting guide for HP laptops with KBC1126
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:
To port coreboot to an HP laptop with KBC1126, 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
- select Kconfig option `SUPERIO_SMSC_LPC47N217` if there is LPC47n217
Super I/O, usually in EliteBook 8000 series, which can be used for
debugging via serial port
- initialize EC and Super I/O in romstage
- add EC and Super I/O support to devicetree.cb
@@ -51,8 +49,8 @@ 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
- For EliteBook xx60 series: 0x60, 0x64, 0xca
- For EliteBook xx70 series: 0x62, 0x66, 0x81
You can use [radare2] and the following [r2pipe] Python script to find
these values from the EcThermalInit EFI module:

29
Documentation/mainboard/index.md
View File

@@ -2,6 +2,10 @@
This section contains documentation about coreboot on specific mainboards.
## 51NB
- [X210](51nb/x210.md)
## AMD
- [padmelon](amd/padmelon/padmelon.md)
@@ -54,7 +58,7 @@ The boards in this section are not real mainboards, but emulators.
### EliteBook series
- [EliteBook common](hp/elitebook_series.md)
- [HP Laptops with KBC1126 EC](hp/hp_kbc1126_laptops.md)
- [EliteBook 8760w](hp/8760w.md)
## Intel
@@ -70,27 +74,29 @@ The boards in this section are not real mainboards, but emulators.
- [R60](lenovo/r60.md)
- [T4xx common](lenovo/t4xx_series.md)
- [X2xx common](lenovo/x2xx_series.md)
- [vboot](lenovo/vboot.md)
### Nehalem series
### Arrandale series
- [T410](lenovo/t410.md)
### GM45 series
- [X200 / T400 / T500 / X301 common](lenovo/montevina_series.md)
- [X301](lenovo/x301.md)
### Sandy Bridge series
- [T420](lenovo/t420.md)
- [T420 / T520 / X220 / T420s / W520 common](lenovo/xx20_series.md)
- [x1](lenovo/x1.md)
- [T420 / T520 / X220 / T420s / W520 common](lenovo/Sandy_Bridge_series.md)
- [X1](lenovo/x1.md)
### Ivy Bridge series
- [T430](lenovo/t430.md)
- [T530](lenovo/w530.md)
- [W530](lenovo/w530.md)
- [T430 / T530 / X230 / W530 common](lenovo/xx30_series.md)
- [T430 / T530 / X230 / W530 common](lenovo/Ivy_Bridge_series.md)
- [T431s](lenovo/t431s.md)
- [Internal flashing](lenovo/ivb_internal_flashing.md)
@@ -98,6 +104,10 @@ The boards in this section are not real mainboards, but emulators.
- [T440p](lenovo/t440p.md)
## Libretrend
- [LT1000](libretrend/lt1000.md)
## MSI
- [MS-7707](msi/ms7707/ms7707.md)
@@ -116,6 +126,11 @@ The boards in this section are not real mainboards, but emulators.
- [PQ7-M107](portwell/pq7-m107.md)
## Protectli
- [FW2B / FW4B](protectli/fw2b_fw4b.md)
- [FW6A / FW6B / FW6C](protectli/fw6.md)
## Roda
- [RK9 Flash Header](roda/rk9/flash_header.md)
@@ -130,6 +145,10 @@ The boards in this section are not real mainboards, but emulators.
- [X11 LGA1151 series](supermicro/x11-lga1151-series/x11-lga1151-series.md)
- [Flashing using the BMC](supermicro/flashing_on_vendorbmc.md)
## System76
- [Lemur Pro](system76/lemp9.md)
## UP
- [Squared](up/squared/index.md)

19
Documentation/mainboard/lenovo/xx30_series.md → Documentation/mainboard/lenovo/Ivy_Bridge_series.md
View File

@@ -1,5 +1,7 @@
# Lenovo Ivy Bridge series
This information is valid for all supported models, except T430s and T431s.
## Flashing coreboot
```eval_rst
+---------------------+--------------------------------+
@@ -72,5 +74,20 @@ region. The update is then written into the EC once.
![][fl]
[fl]: flashlayout_xx30.svg
[fl]: flashlayout_Ivy_Bridge.svg
## Reducing Intel Managment Engine firmware size
It is possible to reduce the Intel ME firmware size to free additional
space for the `bios` region. This is usually referred to as *cleaning the ME* or
*stripping the ME*.
After reducing the Intel ME firmware size you must modify the original IFD,
[split the resulting coreboot ROM](#splitting-the-coreboot-rom) and then write
each ROM using an [external programmer].
Have a look at [me_cleaner] for more information.
Tests on Lenovo W530 showed no issues with a stripped and shrunken ME firmware.
[me_cleaner]: ../../northbridge/intel/sandybridge/me_cleaner.md
[external programmer]: ../../flash_tutorial/index.md

29
Documentation/mainboard/lenovo/xx20_series.md → Documentation/mainboard/lenovo/Sandy_Bridge_series.md
View File

@@ -33,9 +33,7 @@
usable by coreboot.
* ROM chip size should be set to 8MiB.
```eval_rst
Please also have a look at :doc:`../../flash_tutorial/index`.
```
Please also have a look at the [flashing tutorial]
## Flash layout
There's one 8MiB flash which contains IFD, GBE, ME and BIOS regions.
@@ -44,5 +42,28 @@ region. The update is then written into the EC once.
![][fl]
[fl]: flashlayout_xx20.svg
[fl]: flashlayout_Sandy_Bridge.svg
## Reducing Intel Managment Engine firmware size
It is possible to reduce the Intel ME firmware size to free additional
space for the `bios` region. This is usually referred to as *cleaning the ME* or
*stripping the ME*.
After reducing the Intel ME firmware size you must modify the original IFD
and then write a full ROM using an [external programmer].
Have a look at [me_cleaner] for more information.
Tests on Lenovo X220 showed no issues with a stripped ME firmware.
**Modified flash layout:**
![][fl2]
[fl2]: flashlayout_Sandy_Bridge_stripped_me.svg
The overall size of the `gbe`, `me,` `ifd` region is less than 128KiB, leaving
the remaining space for the `bios` partition.
[me_cleaner]: ../../northbridge/intel/sandybridge/me_cleaner.md
[external programmer]: ../../flash_tutorial/index.md

9
Documentation/mainboard/lenovo/codenames.csv
View File

@@ -1,4 +1,6 @@
t60,magi-5|magi-7|austin-3
t60,magi (dGPU) | lisa (iGPU)
z61m,BW2
z61t,BV2
t400,malibu-3
t400s,shinai
t410,nozomi-1
@@ -16,13 +18,18 @@ w510,kendo-1 workstation
w520,kendo-3 workstation
w530,kendo-4 workstation
w700,n-note
w701,n-note 3.0 (nico-3)
x1_carbon_gen1,genesis-1
x60,ks note
x61,ks note-3
x200,mocha-1
x200s,pecan-1
x200t,caramel-1
x201,mocha-3
x220,dasher-1
x220t,comet-1
x230,dasher-2
x230t,comet-2
x230s,rogue-1
x240,rogue-2
x300,kodachi
1 t60 magi-5|magi-7|austin-3 magi (dGPU) | lisa (iGPU)
2 z61m BW2
3 z61t BV2
4 t400 malibu-3 malibu-3
5 t400s shinai shinai
6 t410 nozomi-1 nozomi-1
18 w520 kendo-3 workstation kendo-3 workstation
19 w530 kendo-4 workstation kendo-4 workstation
20 w700 n-note n-note
21 w701 n-note 3.0 (nico-3)
22 x1_carbon_gen1 genesis-1 genesis-1
23 x60 ks note ks note
24 x61 ks note-3 ks note-3
25 x200 mocha-1 mocha-1
26 x200s pecan-1
27 x200t caramel-1
28 x201 mocha-3 mocha-3
29 x220 dasher-1 dasher-1
30 x220t comet-1
31 x230 dasher-2 dasher-2
32 x230t comet-2
33 x230s rogue-1 rogue-1
34 x240 rogue-2 rogue-2
35 x300 kodachi kodachi

0
Documentation/mainboard/lenovo/flashlayout_xx30.svg → Documentation/mainboard/lenovo/flashlayout_Ivy_Bridge.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 4.5 KiB

After

Width:  |  Height:  |  Size: 4.5 KiB

0
Documentation/mainboard/lenovo/flashlayout_xx20.svg → Documentation/mainboard/lenovo/flashlayout_Sandy_Bridge.svg
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 3.7 KiB

After

Width:  |  Height:  |  Size: 3.7 KiB

74
Documentation/mainboard/lenovo/flashlayout_Sandy_Bridge_stripped_me.svg Normal file
View File

@@ -0,0 +1,74 @@
<?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="9cm" height="8cm" viewBox="268 -156 168 158" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g>
<g>
<g>
<rect style="fill: #ffffff" x="307.888" y="-152.131" width="49.1438" height="30.4667"/>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="307.888" y="-152.131" width="49.1438" height="30.4667"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="307.888" y="-152.131" width="49.1438" height="30.4667"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="307.888" y="-152.131" width="49.1438" height="30.4667"/>
<text font-size="6.77323" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="332.46" y="-134.831">
<tspan x="332.46" y="-134.831">IFD</tspan>
</text>
</g>
<g>
<g>
<rect style="fill: #ffffff" x="307.934" y="-56.9106" width="49.1438" height="56.1492"/>
<rect style="fill: none; fill-opacity:0; stroke-width: 0.02; stroke: #ffffff" x="307.934" y="-56.9106" width="49.1438" height="56.1492"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 0.02; stroke: #ffffff" x="307.934" y="-56.9106" width="49.1438" height="56.1492"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="308.096" y="-57.559" width="49.1438" height="57.2839"/>
<text font-size="6.77323" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="332.182" y="-24.0245">
<tspan x="332.182" y="-24.0245">BIOS</tspan>
</text>
<g>
<g>
<g>
<rect style="fill: #ffffff" x="308" y="-121.59" width="49.1438" height="30.4667"/>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="308" y="-121.59" width="49.1438" height="30.4667"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="308" y="-121.59" width="49.1438" height="30.4667"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="308" y="-121.59" width="49.1438" height="30.4667"/>
<text font-size="6.77323" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="332.572" y="-104.29">
<tspan x="332.572" y="-104.29">GBE</tspan>
</text>
</g>
<text font-size="7.15705" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="268.961" y="-148.674">
<tspan x="268.961" y="-148.674">0x000000</tspan>
</text>
<text font-size="6.77323" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="269.152" y="-120.399">
<tspan x="269.152" y="-120.399">0x001000</tspan>
</text>
<text font-size="6.77323" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="269.155" y="-90.6472">
<tspan x="269.155" y="-90.6472">0x003000</tspan>
</text>
<text font-size="6.77323" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="269.461" y="-56.4289">
<tspan x="269.461" y="-56.4289">0x020000</tspan>
</text>
<text font-size="6.77323" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="270.008" y="0.198407">
<tspan x="270.008" y="0.198407">0x800000</tspan>
</text>
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" d="M 380.877 -151.013 C 401.876,-151.013 379.377,-73.513 400.627,-72.513"/>
<path style="fill: none; fill-opacity:0; stroke-width: 1; stroke: #000000" d="M 381.377 -0.763268 C 395.238,-0.763268 387.016,-72.763 400.877,-72.763"/>
<text font-size="6.77323" style="fill: #000000;text-anchor:start;font-family:sans-serif;font-style:normal;font-weight:normal" x="406.127" y="-68.513">
<tspan x="406.127" y="-68.513">Flash #0</tspan>
</text>
<g>
<g>
<g>
<rect style="fill: #ffffff" x="308.189" y="-90.5898" width="49.1438" height="33.4161"/>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="308.189" y="-90.5898" width="49.1438" height="33.4161"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #ffffff" x="308.189" y="-90.5898" width="49.1438" height="33.4161"/>
</g>
<rect style="fill: none; fill-opacity:0; stroke-width: 2; stroke: #000000" x="308.189" y="-90.5898" width="49.1438" height="32.8215"/>
<text font-size="6.77323" style="fill: #000000;text-anchor:middle;font-family:sans-serif;font-style:normal;font-weight:normal" x="331.572" y="-70.23">
<tspan x="331.572" y="-70.23">ME</tspan>
</text>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 4.9 KiB

2
Documentation/mainboard/lenovo/ivb_internal_flashing.md
View File

@@ -102,7 +102,7 @@ Replace the last line (`command.com`) with this (change path to the
Save the file, then unmount the partition:
sudo unmount /mnt
sudo umount /mnt
Write this image to a USB drive (replace `/dev/sdX` with your USB drive
device name):

164
Documentation/mainboard/lenovo/montevina_series.md Normal file
View File

@@ -0,0 +1,164 @@
# Lenovo X200 / T400 / T500 / X301 common
These models are sold with either 8 MiB or 4 MiB flash chip. You can identify
the chip in your machine through flashrom:
```console
# flashrom -p internal
```
Note that this does not allow you to determine whether the chip is in a SOIC-8
or a SOIC-16 package.
## Installing without ME firmware
```eval_rst
.. Note::
**ThinkPad R500** has slightly different flash layout (it doesn't have
``gbe`` region), so the process would be a little different for that model.
```
On Montevina machines it's possible to disable ME and remove its firmware from
SPI flash by modifying the flash descriptor. This also makes it possible to use
the flash region the ME used for `bios` region, allowing for much larger
payloads.
First of all create a backup of your ROM with an external programmer:
```console
# flashrom -p YOUR_PROGRAMMER -r backup.rom
```
Then, split the IFD regions into separate files with ifdtool. You will need
`flashregion_3_gbe.bin` later.
```console
$ ifdtool -x backup.rom
```
Now you need to patch the flash descriptor. You can either [modify the one from
your backup with **ifdtool**](#modifying-flash-descriptor-using-ifdtool), or
[generate a completely new one with **bincfg**](#creating-a-new-flash-descriptor-using-bincfg).
#### Modifying flash descriptor using ifdtool
Pick the layout according to your chip size from the table below and save it to
the `new_layout.txt` file:
```eval_rst
+---------------------------+---------------------------+---------------------------+
| 4 MB chip | 8 MB chip | 16 MB chip |
+===========================+===========================+===========================+
| .. code-block:: none | .. code-block:: none | .. code-block:: none |
| | | |
| 00000000:00000fff fd | 00000000:00000fff fd | 00000000:00000fff fd |
| 00001000:00002fff gbe | 00001000:00002fff gbe | 00001000:00002fff gbe |
| 00003000:003fffff bios | 00003000:007fffff bios | 00003000:01ffffff bios |
| 00fff000:00000fff pd | 00fff000:00000fff pd | 00fff000:00000fff pd |
| 00fff000:00000fff me | 00fff000:00000fff me | 00fff000:00000fff me |
+---------------------------+---------------------------+---------------------------+
```
The last two lines define `pd` and `me` regions of negative size. This way
ifdtool will mark those as unused.
Update regions in the flash descrpitor (it was extracted previously with
`ifdtool -x`):
```console
$ ifdtool -n new_layout.txt flashregion_0_flashdescriptor.bin
```
Set `MeDisable` bit in ICH0 and MCH0 straps:
```console
$ ifdtool -M 1 flashregion_0_flashdescriptor.bin.new
```
Delete previous descriptors and rename the final one:
```console
$ rm flashregion_0_flashdescriptor.bin
$ rm flashregion_0_flashdescriptor.bin.new
$ mv flashregion_0_flashdescriptor.bin.new.new flashregion_0_flashdescriptor.bin
```
Continue to the [Configuring coreboot](#configuring-coreboot) section.
#### Creating a new flash descriptor using bincfg
There is a tool to generate a modified flash descriptor called **bincfg**. Go to
`util/bincfg` and build it:
```console
$ cd util/bincfg
$ make
```
If your flash is not 8 MB, you need to change values of `flcomp_density1` and
`flreg1_limit` in the ifd-x200.set file according to following table:
```eval_rst
+-----------------+-------+-------+--------+
| | 4 MB | 8 MB | 16 MB |
+=================+=======+=======+========+
| flcomp_density1 | 0x3 | 0x4 | 0x5 |
+-----------------+-------+-------+--------+
| flreg1_limit | 0x3ff | 0x7ff | 0x1fff |
+-----------------+-------+-------+--------+
```
Then create the flash descriptor:
```console
$ ./bincfg ifd-x200.spec ifd-x200.set ifd.bin
```
#### Configuring coreboot
Now configure coreboot. You need to select correct chip size and specify paths
to flash descriptor and gbe dump.
```
Mainboard --->
ROM chip size (8192 KB (8 MB)) # According to your chip
(0x7fd000) Size of CBFS filesystem in ROM # or 0x3fd000 for 4 MB chip / 0x1ffd000 for 16 MB chip
Chipset --->
[*] Add Intel descriptor.bin file
# Note: if you used bincfg, specify path to generated util/bincfg/ifd.bin
(/path/to/flashregion_0_flashdescriptor.bin) Path and filename of the descriptor.bin file
[*] Add gigabit ethernet configuration
(/path/to/flashregion_3_gbe.bin) Path to gigabit ethernet configuration
```
Then build coreboot and flash whole `build/coreboot.rom` to the chip.
## Installing with ME firmware
To install coreboot and keep ME working, you don't need to do anything special
with the flash descriptor. Just flash only `bios` externally and don't touch any
other regions:
```console
# flashrom -p YOUR_PROGRAMMER -w coreboot.rom --ifd -i bios
```
## Flash layout
The flash layouts of the OEM firmware are as follows:
```eval_rst
+---------------------------------+---------------------------------+
| 4 MB chip | 8 MB chip |
+=================================+=================================+
| .. code-block:: none | .. code-block:: none |
| | |
| 00000000:00000fff fd | 00000000:00000fff fd |
| 00001000:001f5fff me | 00001000:005f5fff me |
| 001f6000:001f7fff gbe | 005f6000:005f7fff gbe |
| 001f8000:001fffff pd | 005f8000:005fffff pd |
| 00200000:003fffff bios | 00600000:007fffff bios |
| 00290000:002affff ec | 00690000:006affff ec |
| 003e0000:003fffff bootblock | 007e0000:007fffff bootblock |
+---------------------------------+---------------------------------+
```
On each boot of vendor BIOS `ec` area in flash is checked for having firmware
there, and if there is one, it proceedes to update firmware on H8S/2116 (when
both external power and main battery are attached). Once update is performed,
first 64 KB of `ec` area is erased. Visit
[thinkpad-ec repository](https://github.com/hamishcoleman/thinkpad-ec) to learn
more about how to extract EC firmware from vendor updates.

8
Documentation/mainboard/lenovo/t420.md
View File

@@ -14,12 +14,10 @@ W25Q64CVSIG. Do not rely on dots painted in the corner of the chip (such as
the blue dot pictured) to orient the pins!
For more details have a look at [T420 / T520 / X220 / T420s / W520 common] and
```eval_rst
:doc:`../../flash_tutorial/ext_power`
```
the general [flashing tutorial].
Steps to access the flash IC are described here [T4xx series].
[T4xx series]: t4xx_series.md
[T420 / T520 / X220 / T420s / W520 common]: xx20_series.md
[flashing tutorial]: ../../flash_tutorial/ext_power.md
[T420 / T520 / X220 / T420s / W520 common]: Sandy_Bridge_series.md

7
Documentation/mainboard/lenovo/t430.md
View File

@@ -5,11 +5,10 @@ You have to disassemble the whole device, as the flash ICs are on the bottom
of the mainboard.
For more details have a look at [T430 / T530 / X230 / T430s / W530 common] and
```eval_rst
:doc:`../../flash_tutorial/ext_power`
```
the general [flashing tutorial].
Steps to access the flash IC are described here [T4xx series].
[flashing tutorial]: ../../flash_tutorial/ext_power.md
[T4xx series]: t4xx_series.md
[T430 / T530 / X230 / T430s / W530 common]: xx30_series.md
[T430 / T530 / X230 / T430s / W530 common]: Ivy_Bridge_series.md

6
Documentation/mainboard/lenovo/t431s.md
View File

@@ -26,9 +26,7 @@ the programmer.
![t431s_programming](t431s_programming.jpg)
```eval_rst
:doc:`../../flash_tutorial/ext_power`
```
The general [flashing tutorial] has more details.
Currently, detecting the model of soldered RAM at runtime and loading
the corresponding SPD datum from CBFS is not implemented yet. You may
@@ -39,4 +37,4 @@ inteltool, and replace the content of the SPD hex with what is dumped.
I do not know how to find gpio ports for that, and SPD data stored in
vendor firmware.)
[T420 / T520 / X220 / T420s / W520 common]: xx20_series.md
[T420 / T520 / X220 / T420s / W520 common]: Sandy_Bridge_series.md

8
Documentation/mainboard/lenovo/t440p.md
View File

@@ -31,15 +31,10 @@ the laptop able to power on.
## Known Issues
- No audio output when using a headphone
- The touchpad is misconfigured, the 3 keys on top are all identified
as left button
- Cannot get the mainboard serial number from the mainboard: the OEM
UEFI firmware gets the serial number from an "emulated EEPROM" via
I/O port 0x1630/0x1634, but it's still unknown how to make it work
## Untested
- the dGPU model
- The dGPU does not currently work in Windows.
## Working
@@ -61,6 +56,7 @@ the laptop able to power on.
- CMOS options: wlan, trackpoint, fn_ctrl_swap
- internal flashing when IFD is unlocked
- using `me_cleaner`
- dGPU (must be enabled in CMOS options)
[Lenovo ThinkPad T440p]: https://pcsupport.lenovo.com/us/zh/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t440p
[Hardware Maintenance Manual]: https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles_pdf/t440p_hmm_en_sp40a25467_04.pdf

38
Documentation/mainboard/lenovo/vboot.md Normal file
View File

@@ -0,0 +1,38 @@
# Using coreboot's verified boot on Lenovo devices
By default a single instance of coreboot is present in the firmware flash,
no verification is done and the flash is not write-protected, so as to allow
firmware updates from the OS.
The verified boot mechanism also called [vboot] allows secure firmware
updates using an A/B partitioning scheme once enabled.
## Enabling vboot
You can enable [vboot] in Kconfig's *Security* section. Besides a verified
boot you can also enable a measured boot by setting
`CONFIG_VBOOT_MEASURED_BOOT`. Both options need a working TPM, which is
present on all recent Lenovo devices.
## Updating and recovery
As the A/B partition is writeable you can still update them from the OS.
By using the [vboot] mechanism you store a copy of coreboot in the `RO`
partition that acts as failsafe in case the regular firmware update, that
goes to the `A` or `B` partition fails.
**Note:** The `RO` partition isn't write-protected by default, therefore you
have to enable the protection in the security Kconfig menu by yourself.
On *Lenovo* devices you can enable the *Fn* key as recovery mode switch, by
enabling `CONFIG_H8_FN_KEY_AS_VBOOT_RECOVERY_SW`.
Holding the *Fn* at boot will then switch to the recovery image, allowing
to boot and flash a working image to the A/B partition.
## 8 MiB ROM limitation
*Lenovo* devices with 8 MiB ROM only have a `RO`+`A` partition enabled in the
default FMAP. They are missing the `B` partition, due to size constaints.
You can still provide your own FMAP if you need `RO`+`A`+`B` partitions.
## CMOS
[vboot] on *Lenovo* devices uses the CMOS to store configuration data, like
boot failures and the last successfully booted partition.
[vboot]: ../../security/vboot/index.md

7
Documentation/mainboard/lenovo/w530.md
View File

@@ -10,9 +10,7 @@ As all lines except /CS are shared between the flash ICs you can access
both with an external programmer.
For more details have a look at [T430 / T530 / X230 / T430s / W530 common] and
```eval_rst
:doc:`../../flash_tutorial/ext_power`
```
the general [flashing tutorial].
### After removing the keyboard and palm rest
![][w530-1]
@@ -24,4 +22,5 @@ For more details have a look at [T430 / T530 / X230 / T430s / W530 common] and
[w530-2]: w530-2.jpg
[T430 / T530 / X230 / T430s / W530 common]: xx30_series.md
[flashing tutorial]: ../../flash_tutorial/ext_power.md
[T430 / T530 / X230 / T430s / W530 common]: Ivy_Bridge_series.md

8
Documentation/mainboard/lenovo/x1.md
View File

@@ -13,12 +13,10 @@ The flash IC can be a SOIC-8 one or a WSON-8 one, and may be covered with
a piece of insulation tape.
For more details have a look at [T420 / T520 / X220 / T420s / W520 common] and
```eval_rst
:doc:`../../flash_tutorial/ext_power`
```
the general [flashing tutorial].
Steps to access the flash IC are described here [X2xx series].
[X2xx series]: x2xx_series.md
[T420 / T520 / X220 / T420s / W520 common]: xx20_series.md
[flashing tutorial]: ../../flash_tutorial/ext_power.md
[T420 / T520 / X220 / T420s / W520 common]: Sandy_Bridge_series.md

39
Documentation/mainboard/lenovo/x301.md
View File

@@ -22,23 +22,26 @@ SOIC-8 one (you might need to add the chip to the IFD VSCC list), as
what is done in the photo.
The vendor IFD VSCC list contains:
-MACRONIX_MX25L6405 (0xc2, 0x2017)
-WINBOND_NEX_W25X64 (0xef, 0x3017)
-ATMEL_AT25DF641 (0x1f, 0x4800)
- MACRONIX_MX25L6405 (0xc2, 0x2017)
- WINBOND_NEX_W25X64 (0xef, 0x3017)
- ATMEL_AT25DF641 (0x1f, 0x4800)
The general [flashing tutorial] has more details.
```eval_rst
:doc:`../../flash_tutorial/ext_power`
```
Tested:
- CPU Core 2 Duo U9400
- Slotted DIMM 4GiB*2 from samsung
- Camera
- pci-e slots
- sata and usb2
- libgfxinit-based graphic init
- NVRAM options for North and South bridges
- Sound
- Thinkpad EC
- S3
- Linux 4.19.67-2 within Debian GNU/Linux stable, loaded from
Linux payload (Heads) and Seabios.
- Core 2 Duo U9400 CPU
- Slotted DIMM 4GiB*2 from Samsung
- Camera
- PCI-e slots
- SATA and USB2
- libgfxinit-based graphics init
- NVRAM options for North and South bridges
- Sound
- ThinkPad EC
- S3
- Linux 4.19.67-2 within Debian GNU/Linux stable, loaded from
Linux payload (Heads) and SeaBIOS.
[flashing tutorial]: ../../flash_tutorial/ext_power.md

BIN
Documentation/mainboard/libretrend/lt1000.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 78 KiB

117
Documentation/mainboard/libretrend/lt1000.md Normal file
View File

@@ -0,0 +1,117 @@
# Libretrend LT1000
This page describes how to run coreboot on the [Libretrend LT1000] (aka
Librebox).
![](lt1000.jpg)
## Required proprietary blobs
To build a minimal working coreboot image some blobs are required (assuming
only the BIOS region is being modified).
```eval_rst
+-----------------+---------------------------------+---------------------+
| Binary file | Apply | Required / Optional |
+=================+=================================+=====================+
| FSP-M, FSP-S | Intel Firmware Support Package | Required |
+-----------------+---------------------------------+---------------------+
| microcode | CPU microcode | Required |
+-----------------+---------------------------------+---------------------+
```
FSP-M and FSP-S are obtained after splitting the Kaby Lake FSP binary (done
automatically by coreboot build system and included into the image) from the
*3rdparty/fsp* submodule.
Microcode updates are automatically included into the coreboot image by build
system from the *3rdparty/intel-microcode* submodule.
The mainboard code also contains a VBT file (version 1.00, BDB version 2.09)
which is automatically included into the image by coreboot build system.
## Flashing coreboot
### Internal programming
The main SPI flash can be accessed using [flashrom]. It is strongly advised to
flash only the BIOS region if not having an external programmer, see known
issues.
### 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 near the CPU fan,
between the DIMM slots and the M.2 disk. Use a clip (or solder the wires) to
program the chip. Specifically, it's a Winbond W25Q64FV (3.3V) -
[datasheet][W25Q64FV].
## Known issues
- Fastboot (MRC cache) is not working reliably (missing schematics for CPU to
DIMM wiring).
- Flashing ME region with already cleaned ME firmware may lead to platform not
booting, flashing full ME firmware is needed to recover.
- In order to have the USB device wake support from S3 state using the front
USB 3.0 ports, one has to move the jumper on DUSB1_PWR_SET header (it will
switch the power rails for the USB 3.0 ports).
- There are 6 unknown GPIO pins on the board.
## Untested
Not all mainboard's peripherals and functions were tested because of lack of
the cables or not being populated on the board case.
- LVDS header
- Onboard USB 2.0 and USB 3.0 headers
- Speakers and mic header
- SPDIF header
- Audio header
- PS/2 header
- LPT header
- CIR (infrared header)
- COM2 port RS485 mode (RS232/RS485 mode is controlled via jumper)
- SYS_FAN header
## Working
- USB
- Ethernet
- Integrated graphics (with libgfxinit) on VGA and HDMI ports
- flashrom
- PCIe
- NVMe
- WiFi and Bluetooth
- SATA
- Serial ports 1-6
- SMBus
- HDA (verbs not implemented yet, but works under GNU/Linux (4.15 tested))
- Initialization with KBL FSP 2.0
- SeaBIOS payload (version rel-1.13.0)
- TPM2 ([custom module] connected to LPC DEBUG header)
- Automatic fan control
- Platform boots with cleaned ME (MFS partition must be left on SPI flash)
## Technology
The platform contains an LR-i7S65T1 baseboard (LR-i7S65T2 with two NICs not
sold yet). More details on [baseboard site]. Unfortunately the board manual is
not publicly available.
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Core i7-6500U |
+------------------+--------------------------------------------------+
| PCH | Skylake-U Premium |
+------------------+--------------------------------------------------+
| Super I/O | ITE IT8786E |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Management Engine |
+------------------+--------------------------------------------------+
```
[Libretrend LT1000]: https://libretrend.com/specs/librebox/
[W25Q64FV]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
[flashrom]: https://flashrom.org/Flashrom
[baseboard site]: http://www.minicase.net/product_LR-i7S65T1.html
[custom module]: https://shop.3mdeb.com/product/tpm2-module-for-librebox/

2
Documentation/mainboard/msi/ms7707/ms7707.md
View File

@@ -75,7 +75,7 @@ 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
* 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

BIN
Documentation/mainboard/protectli/fw2b.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 51 KiB

128
Documentation/mainboard/protectli/fw2b_fw4b.md Normal file
View File

@@ -0,0 +1,128 @@
# Protectli Vault FW2B and FW4B
This page describes how to run coreboot on the [Protectli FW2B] and
[Protectli FW4B].
## Required proprietary blobs
To build a minimal working coreboot image some blobs are required (assuming
only the BIOS region is being modified).
```eval_rst
+-----------------+---------------------------------+---------------------+
| Binary file | Apply | Required / Optional |
+=================+=================================+=====================+
| FSP | Intel Firmware Support Package | Required |
+-----------------+---------------------------------+---------------------+
| microcode | CPU microcode | Required |
+-----------------+---------------------------------+---------------------+
| vgabios | VGA Option ROM | Optional |
+-----------------+---------------------------------+---------------------+
```
FSP is automatically added by coreboot build system into the image) from the
`3rdparty/fsp` submodule.
microcode updates are automatically included into the coreboot image by build
system from the `3rdparty/intel-microcode` submodule.
VGA Option ROM is not required to boot, but if one needs graphics in pre-OS
stage, it should be included.
## 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 bottom side of the case (the radiator side). One
has to remove all screws (in order): 4 top cover screws, 4 side cover screws
(one side is enough), 4 mainboard screws, 3 CPU screws (under the DIMM). Lift
up the mainboard and turn around it. The flash chip is near the mainboard edge
close to the Ethernet Controllers. Use a clip (or solder the wires) to program
the chip. **Watch out on the voltage, the SPI operates at 1.8V!** Specifically,
it's a Macronix MX25U6435F (1.8V) - [datasheet][MX25U6435F].
## Known issues
- After flashing with external programmer the board will not boot if flashed
the BIOS region only. For some reason it is required to flash whole image
along with TXE region.
- USB 3.0 ports get detected very late in SeaBIOS, it needs huge timeout
values in order to get the devices detected.
## Untested
Not all mainboard's peripherals and functions were tested because of lack of
the cables or not being populated on the board case.
- internal USB 2.0 header
## Working
- USB 3.0 front ports (SeaBIOS and Linux)
- 4 Ethernet ports (2 Ethernet ports on FW2B)
- 2 HDMI ports with VGA Option ROM
- 2 HDMI ports with libgfxinit
- flashrom
- PCIe WiFi
- SATA and mSATA
- Super I/O serial port 0 (RS232 via front RJ45 connector)
- SMBus (reading SPD from DIMMs)
- initialization with Braswell FSP
- SeaBIOS payload (version rel-1.13.0)
- booting Debian, Ubuntu, FreeBSD
## Not working
- mPCIe debug card connected to mSATA (mSATA slot has LPC signals routed,
however for some reason the debug card is not powered)
## Technology
The mainboard has two variants: FW2B and FW4B. They have different Braswell
SoC. The FW2B replaces 2 out of 4 Ethernet Controllers with 4 USB ports
connected via [FE1.1 USB 2.0 hub].
- FW2B:
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Celeron J3060 |
+------------------+--------------------------------------------------+
| PCH | Braswell |
+------------------+--------------------------------------------------+
| Super I/O | ITE IT8613E |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Trusted Execution Engine |
+------------------+--------------------------------------------------+
```
![](fw2b.jpg)
- FW4B:
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Celeron J3160 |
+------------------+--------------------------------------------------+
| PCH | Braswell |
+------------------+--------------------------------------------------+
| Super I/O | ITE IT8613E |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Trusted Execution Engine |
+------------------+--------------------------------------------------+
```
![](fw4b.jpg)
[Protectli FW2B]: https://protectli.com/vault-2-port/
[Protectli FW4B]: https://protectli.com/product/fw4b/
[MX25U6435F]: https://www.macronix.com/Lists/Datasheet/Attachments/7411/MX25U6435F,%201.8V,%2064Mb,%20v1.5.pdf
[FE1.1 USB 2.0 hub]: https://cdn-shop.adafruit.com/product-files/2991/FE1.1s+Data+Sheet+(Rev.+1.0).pdf
[flashrom]: https://flashrom.org/Flashrom

BIN
Documentation/mainboard/protectli/fw4b.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 58 KiB

BIN
Documentation/mainboard/protectli/fw6.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 49 KiB

137
Documentation/mainboard/protectli/fw6.md Normal file
View File

@@ -0,0 +1,137 @@
# Protectli Vault FW6 series
This page describes how to run coreboot on the [Protectli FW6].
![](fw6.jpg)
## Required proprietary blobs
To build a minimal working coreboot image some blobs are required (assuming
only the BIOS region is being modified).
```eval_rst
+-----------------+---------------------------------+---------------------+
| Binary file | Apply | Required / Optional |
+=================+=================================+=====================+
| FSP-M, FSP-S | Intel Firmware Support Package | Required |
+-----------------+---------------------------------+---------------------+
| microcode | CPU microcode | Required |
+-----------------+---------------------------------+---------------------+
| vgabios | VGA Option ROM | Optional |
+-----------------+---------------------------------+---------------------+
```
FSP-M and FSP-S are obtained after splitting the Kaby Lake FSP binary (done
automatically by the coreboot build system and included into the image) from
the `3rdparty/fsp` submodule.
Microcode updates are automatically included into the coreboot image by build
system from the `3rdparty/intel-microcode` submodule.
VGA Option ROM is not required to boot, but if one needs graphics in pre-OS
stage, it should be included (if not using libgfxinit).
## Flashing coreboot
### Internal programming
The main SPI flash can be accessed using [flashrom]. The first version
supporting the chipset is flashrom v1.1. Firmware an be easily flashed
with internal programmer (either BIOS region or full image).
### External programming
The system has an internal flash chip which is a 8 MiB soldered SOIC-8 chip.
This chip is located on the bottom side of the case (the radiator side). One
has to remove all screws (in order): 4 top cover screws, 4 side cover screws
(one side is enough), 4 mainboard screws, 4 CPU screws (under DIMMs). Lift up
the mainboard and turn around it. The flash chip is near the SoC on the DIMM
slots side. Use a clip (or solder the wires) to program the chip. Specifically,
it's a Macronix MX25L6406E (3.3V) -[datasheet][MX25L6406E].
## Known issues
- After flashing with external programmer it is always required to reset RTC
with jumper or disconnect coin cell temporarily. Only then the platform will
boot after flashing.
- FW6A does not always work reliably with all DIMMs. Linux happens to hang or
gives many panics. This issue was present also with vendor BIOS.
- Sometimes FSPMemoryInit return errors or hangs (especially with 2 DIMMs
connected). A workaround is to power cycle the board (even a few times) or
temporarily disconnect DIMM when platform is powered off.
- When using libgfxinit and SeaBIOS bootsplash, the red color is dim
## Untested
Not all mainboard's peripherals and functions were tested because of lack of
the cables or not being populated on the board case.
- Internal USB 2.0 headers
- Boot with cleaned ME
## Working
- USB 3.0 front ports (SeaBIOS and Linux)
- 6 Ethernet ports
- HDMI port with libgfxinit and VGA Option ROM
- flashrom
- PCIe WiFi
- SATA and mSATA
- Super I/O serial port 0 (RS232 via front RJ45 connector)
- SMBus (reading SPD from DIMMs)
- Initialization with KBL FSP 2.0 (with MemoryInit issues)
- SeaBIOS payload (version rel-1.12.1)
- Mini PCIe debug card connected to mSATA (mSATA slot has LPC signals routed)
- Reset switch
- Booting Debian, Ubuntu, FreeBSD
## Technology
There are 3 variants of FW6 boards: FW6A, FW6B and FW6C. They differ only in
used SoC.
- FW6A:
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Celeron 3865U |
+------------------+--------------------------------------------------+
| PCH | Kaby Lake U w/ iHDCP2.2 Base |
+------------------+--------------------------------------------------+
| Super I/O, EC | ITE IT8772E |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Management Engine |
+------------------+--------------------------------------------------+
```
- FW6B:
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Core i3-7100U |
+------------------+--------------------------------------------------+
| PCH | Kaby Lake U w/ iHDCP2.2 Premium |
+------------------+--------------------------------------------------+
| Super I/O, EC | ITE IT8772E |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Management Engine |
+------------------+--------------------------------------------------+
```
- FW6C:
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Core i5-7200U |
+------------------+--------------------------------------------------+
| PCH | Kaby Lake U w/ iHDCP2.2 Premium |
+------------------+--------------------------------------------------+
| Super I/O, EC | ITE IT8772E |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Management Engine |
+------------------+--------------------------------------------------+
```
[Protectli FW6]: https://protectli.com/vault-6-port/
[MX25L6406E]: https://www.macronix.com/Lists/Datasheet/Attachments/7370/MX25L6406E,%203V,%2064Mb,%20v1.9.pdf
[flashrom]: https://flashrom.org/Flashrom

66
Documentation/northbridge/intel/sandybridge/me_cleaner.md
View File

@@ -5,7 +5,7 @@ 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.**
carefully evaluated.**
## Observations with 'cleaned' ME
@@ -18,3 +18,67 @@ carefully evaulated.**
Always test with unmodified IFD and ME section before reporting bugs to the
coreboot project.
## Tutorial reducing the Intel ME firmware size
By default the cleaned ME firmware will still occupy the same space in
the firmware image. It's possible to change the firmware partition layout
and reclaim the space for the use by coreboot.
With the reduced Intel ME firmware the `ifd`, `gbe` and `me` regions require
less than 128 KiB of space in the ROM, which leaves the remaining for the
`bios` region.
This tutorial will guide you through the steps necessary.
### 1. Obtain a full ROM
You need a full and working ROM with a full Intel ME firmware.
### 2. Running me_cleaner
You need to run the *me_cleaner* on a full ROM, here called `fulldump.rom`:
The full ROM contains:
* IFD
* fully working Intel ME
* GbE (optional)
* BIOS (any firmware)
Running the command will generate two new files:
```console
./util/me_cleaner/me_cleaner.py -D patched_desciptor.bin -M stripped_me.bin fulldump.rom -t -r -S
```
The generated files are:
* a patched IFD called `patched_desciptor.bin`
* stripped Intel ME called `stripped_me.bin`
The patched IFD has the *AltMeDisable* bit set and a modified flash layout.
*Note:* coreboot allows to select `CONFIG_ME_CLEANER` as part of the
build-process, but that doesn't rework the flash layout, it only removes
files from ME and sets the *AltMeDisable*-bit.
### 3. Build coreboot
1. Now include the two new files from the previous step into coreboot's
build system.
2. Make sure to also increase the CBFS size
* 0x7E0000 for a 8MiB ROM
* 0xBE0000 for a 12MiB ROM
* 0xFE0000 for a 16MiB ROM
3. Make sure to **not** enable me_cleaner in Kconfig again as
you have already run it
### 4. Flashing the ROM
As you have modified the layout you need to write the **full ROM** to flash
using an [external programmer].
Make sure to include all partitions into the ROM:
* IFD
* EC (might be unused)
* GbE (might be unused)
* ME
* BIOS
[external programmer]: ../../../flash_tutorial/index.md

12
Documentation/payloads.md
View File

@@ -40,3 +40,15 @@ availability of well-tested, battle-hardened drivers (as compared to
firmware project drivers that often reinvent the wheel) and the ability to
define boot policy with familiar tools, no matter if those are shell scripts
or compiled userland programs written in C, Go or other programming languages.
## Heads
[Heads] is a distribution that bundles coreboot, Linux, busybox and custom
tools to provide reproducible ROMs. [Heads] aims to provide a secure and
flexible boot environment for laptops and servers.
It supports features like measured boot, kexec, GPG, OTP, TLS, firmware
updates, but only works on a limited amount of mainboards.
For more details have a look at [heads-wiki].
[Heads]: https://github.com/osresearch/heads
[heads-wiki]: http://osresearch.net/

1
Documentation/releases/checklist.md
View File

@@ -68,6 +68,7 @@ be more frequent than was needed, so we scaled it back to twice a year.
- [ ] Test the commit selected for release.
- [ ] Update release notes with actual commit id, push to repo.
- [ ] Run release script.
- [ ] Run vboot_list script.
- [ ] Test the release from the actual release tarballs.
- [ ] Push signed Tag to repo.
- [ ] Announce that the release tag is done on IRC.

2
Documentation/releases/coreboot-4.11-relnotes.md
View File

@@ -175,7 +175,7 @@ of becoming more generally useful.
Payload integration has been updated, coreinfo learned to cope with
UPPER CASE commands and libpayload knows how to deal with USB3 hubs.
### Added VBOOT support to the following platforms:
### Added vboot support to the following platforms:
* intel/gm45
* intel/nehalem

63
Documentation/releases/coreboot-4.12-relnotes.md
View File

@@ -10,6 +10,69 @@ notes.
* The chip and board additions and removals will be updated right
before the release, so those do not need to be added.
Deprecations
------------
For the 4.12 release a few features on x86 became mandatory. These are
relocatable ramstage, postcar stage and C_ENVIRONMENT_BOOTBLOCK.
### Relocatable ramstage
Relocatable stages are a feature implemented only on x86, where stages
can be relocated at runtime. This is used to place ramstage in a better
location that does not collide with memory the OS or the payload tends
to use. The rationale behind making this mandatory is that you always
want cbmem to be cached so it's a good location to run ramstage from.
It avoids using lower memory altogether so the OS can make use of it
and no backing up needs to happen on S3 resume.
### Postcar stage
With Postcar stage tearing down Cache-as-Ram is done in a separate
stage. This means that romstage has a clean program boundary and
that all variables in romstage can be accessed via their linked
addresses without runtime resolution. There is no need to link
global and static variables via the CAR\_GLOBAL macro and no need
to access them with car\_set/get\_var/ptr functions.
### C\_ENVIRONMENT\_BOOTBLOCK
Historically the bootblock on x86 platforms has been compiled with
romcc. This means that the generated code only uses CPU registers
and therefore no stack. This 20K+ LOC compiler is limited and hard
to maintain and so is the code that one has to write in that
environment. A different solution is to set up Cache-as-Ram in the
bootblock and run GCC compiled code in the bootblock. The advantages
are increased flexibility and consistency with other architectures as
well as other stages: e.g. printing to console is possible and
VBOOT can run before romstage, making romstage updatable via RW FMAP
regions.
### Platforms dropped from master
The following platforms did not implement those feature are dropped
from master to allow the master branch to move on:
- AMDFAM10
- all FSP1.0 platforms: BROADWELL_DE, FSP_BAYTRAIL, RANGELEY
- VIA VX900
- TODO (AMD?)
In particular on FSP1.0 it is impossible to implement POSTCAR stage.
The reason is that FSP1.0 relocates the CAR region to the HOB before
returning to coreboot. This means that after FSP returns to coreboot
accessing variables via their original address is not possible. One
way of obtaining that behavior would be to set up Cache-as-Ram again
(but with open source code) and copy the relocated data from the HOB
there. This solution is deemed too hacky. Maybe a lesson can be
learned from this: blobs should not interfere with the execution
environment, as this makes proper integration much harder.
### 4.11_branch
Given that some platforms supported by FSP1.0 are being produced and
popular, the 4.11 release was made into a branch in which further
development can happen.
Significant changes
-------------------

2
Documentation/releases/coreboot-4.5-relnotes.md
View File

@@ -73,7 +73,7 @@ Areas with significant updates
### Vendorcode
* AMD (14 commits) - Cleanup, add libagesa.a builds, remove unused code.
* Google (22 commits) - VBoot2 updates and cleanup
* Google (22 commits) - vboot2 updates and cleanup
* Intel (86 commits) - Add Intel FSP 2.0, update Broadwell DE support
### Payloads (37 commits)

4
Documentation/releases/coreboot-4.6-relnotes.md
View File

@@ -164,7 +164,7 @@ Drivers (29 commits)
* i2c/hid: Add generic I2C HID driver
* i2c/max98927: add i2c driver for Maxim 98927 codec
* i2c/wacom_ts: Add support for WCOM touchscreen device driver
* pc80/rtc: Check cmos checksum BEFORE reading cmos value
* pc80/rtc: Check CMOS checksum BEFORE reading CMOS value
* regulator: Add driver for handling GPIO-based fixed regulator
* storage: Add SD/MMC/eMMC driver based upon depthcharge
@@ -180,7 +180,7 @@ SuperIO (12 commits)
* Add 2 new chips
* Consolidate code to use common routines
Vboot (23 commits)
vboot (23 commits)
* Add support for recovery hash space in TPM
RISC-V (25 commits)

4
Documentation/releases/coreboot-4.8.1-relnotes.md
View File

@@ -40,7 +40,7 @@ possible
Lenovo mainboards
-----------------
* Started integration of VBT (Video Bios Table) binary files to
* Started integration of VBT (Video BIOS Table) binary files to
support native graphics initialisation
Internal changes
@@ -77,7 +77,7 @@ Security
--------
* Start of refactoring the TPM software stack
* Introduced coreboot security section in kconfig
* VBoot & TPM code moved into src/security
* vboot & TPM code moved into src/security
Intelmetool
-----------

6
Documentation/security/vboot/index.md
View File

@@ -12,6 +12,8 @@ Google's verified boot support consists of:
Google's vboot verifies the firmware and places measurements within the TPM.
- [List of supported Devices](list_vboot.md)
***
## Root of Trust
@@ -194,7 +196,7 @@ not into the read/write coreboot file systems in *FW_MAIN_A* and *FW_MAIN_B*.
**VBOOT_ENABLE_CBFS_FALLBACK**
Normally coreboot will use the active read/write coreboot file system for all
of it's file access when VBOOT is active and is not in recovery mode.
of it's file access when vboot is active and is not in recovery mode.
When the `VBOOT_ENABLE_CBFS_FALLBACK` option is enabled the cbfs file system will
first try to locate a file in the active read/write file system. If the file
@@ -229,7 +231,7 @@ More details are available in `3rdparty/vboot/README`.
# The keys were made using the following command
#
# 3rdparty/vboot/scripts/keygeneration/create_new_keys.sh \
# --4k --4k-root --output $PWD/keys
# --output $PWD/keys
#
#
# The "magic" numbers below are derived from the GBB section in

223
Documentation/security/vboot/list_vboot.md Normal file
View File

@@ -0,0 +1,223 @@
# vboot-enabled devices
## Emulation
- QEMU x86 i440fx/piix4 (aka qemu -M pc)
- QEMU x86 q35/ich9 (aka qemu -M q35, since v1.4)
## Facebook
- Facebook Monolith
## Google
- Auron_Paine (Acer C740 Chromebook)
- Auron_Yuna (Acer Chromebook 15 (C910/CB5-531))
- Buddy (Acer Chromebase 24)
- Gandof (Toshiba Chromebook 2 (2015))
- Lulu (Dell Chromebook 13 7310)
- Samus (Google Chromebook Pixel (2015))
- Mccloud (Acer Chromebox CXI)
- Monroe (LG Chromebase 22CV241 & 22CB25S)
- Panther (ASUS Chromebox CN60)
- Tricky (Dell Chromebox 3010)
- Zako (HP Chromebox G1)
- Butterfly (HP Pavilion Chromebook 14)
- Cheza
- Banon (Acer Chromebook 15 (CB3-532))
- Celes (Samsung Chromebook 3)
- Cyan (Acer Chromebook R11 (C738T))
- Edgar (Acer Chromebook 14 (CB3-431))
- Kefka (Dell Chromebook 11 3180/3189)
- Reks (Lenovo N22/N42 Chromebook)
- Relm
- Setzer (HP Chromebook 11 G5)
- Terra (ASUS Chromebook C202SA/C300SA/C301SA)
- Ultima (Lenovo Yoga 11e G3)
- Wizpig
- Daisy (Samsung Chromebook (2012))
- DragonEgg
- Drallion
- Eve (Google Pixelbook)
- Fizz
- Karma
- Endeavour
- Foster
- Gale (Google WiFi)
- Asuka (Dell Chromebook 13 3380)
- Caroline (Samsung Chromebook Pro)
- Cave (Asus Chromebook Flip C302SA)
- Chell (HP Chromebook 13 G1)
- Glados Skylake Reference Board
- Lars (Acer Chromebook 14 for Work (CP5-471))
- Sentry (Lenovo Thinkpad 13 Chromebook)
- Kevin (Samsung Chromebook Plus)
- Gru
- Bob (Asus Chromebook Flip C101PA)
- Scarlet
- Nefario
- Rainier
- Akemi
- Dratini
- Hatch
- Jinlon
- Kohaku
- Kindred
- Helios
- Mushu
- Palkia
- Nightfury
- Puff
- Helios_Diskswap
- Stryke
- Guado (ASUS Chromebox CN62)
- Jecht
- Rikku (Acer Chromebox CXI2)
- Tidus (Lenovo ThinkCentre Chromebox)
- Aleena
- Careena
- Grunt
- Liara
- Nuwani
- Treeya
- Kukui
- Krane
- Kodama
- Kakadu
- Flapjack
- Jacuzzi
- Juniper
- Kappa
- Damu
- Link (Google Chromebook Pixel (2013))
- Mistral
- Nyan
- Nyan Big (Acer Chromebook 13 (CB5-311))
- Nyan Blaze (HP Chromebook 14 G3)
- Oak
- Elm (Acer Chromebook R13)
- Hana (Lenovo N23 Yoga Chromebook)
- Parrot (Acer C7/C710 Chromebook)
- Peach Pit (Samsung Chromebook 2 11\")
- Atlas
- Poppy
- Nami
- Nautilus
- Nocturne
- Rammus
- Soraka
- Banjo (Acer Chromebook 15 (CB3-531))
- Candy (Dell Chromebook 11 3120)
- Clapper (Lenovo N20 Chromebook)
- Enguarde
- Glimmer (Lenovo ThinkPad 11e Chromebook)
- Gnawty (Acer Chromebook 11 (CB3-111/131,C730/C730E/C735))
- Heli (Haier Chromebook G2)
- Kip (HP Chromebook 11 G3 / G4 / G4 EE)
- Ninja (AOpen Chromebox Commercial)
- Orco (Lenovo 100S Chromebook)
- Quawks (ASUS Chromebook C300)
- Squawks (ASUS Chromebook C200)
- Rambi
- Sumo (AOpen Chromebase Commercial)
- Swanky (Toshiba Chromebook 2)
- Winky (Samsung Chromebook 2 (XE500C12))
- Reef/Electro (Acer Chromebook Spin 11 R751T)
- Pyro (Lenovo Thinkpad (Yoga) 11e Chromebook)
- Sand (Acer Chromebook 15 CB515-1HT/1H)
- Snappy (HP Chromebook x360 11 G1 EE)
- Nasher
- Coral
- Arcada
- Sarien
- Falco (HP Chromebook 14)
- Leon (Toshiba Chromebook)
- Peppy (Acer C720/C720P Chromebook)
- Wolf (Dell Chromebook 11)
- Smaug (Google Pixel C)
- Storm (OnHub Router TGR1900)
- Stout (Lenovo Thinkpad X131e Chromebook)
- Trogdor
- Veyron_Jaq (Haier Chromebook 11)
- Veyron_Jerry (Hisense Chromebook 11)
- Veyron_Mighty (Haier Chromebook 11(edu))
- Veyron_Minnie (ASUS Chromebook Flip C100)
- Veyron_Speedy (ASUS C201 Chromebook)
- Veyron_Mickey (Asus Chromebit CS10)
- Veyron_Rialto
## HP
- Z220 SFF Workstation
## Intel
- Basking Ridge CRB
- Cannonlake U LPDDR4 RVP
- Cannonlake Y LPDDR4 RVP
- Coffeelake U SO-DIMM DDR4 RVP
- Coffeelake H SO-DIMM DDR4 RVP11
- Whiskeylake U DDR4 RVP
- Coffeelake S U-DIMM DDR4 RVP8
- Cometlake U DDR4 RVP
- Emerald Lake 2 CRB
- Galileo
- Glkrvp
- Icelake U DDR4/LPDDR4 RVP
- Icelake Y LPDDR4 RVP
- Jasperlake DDR4/LPDDR4 RVP
- Jasperlake DDR4/LPDDR4 RVP with Chrome EC
- Kabylake LPDDR3 RVP3
- Kabylake DDR3L RVP7
- Kabylake DDR4 RVP8
- Kabylake DDR4 RVP11
- Kunimitsu
- Strago
- Tigerlake UP3 RVP
- Tigerlake UP4 RVP
- Whitetip Mountain 2 CRB
## Lenovo
- ThinkPad T400
- ThinkPad T500
- ThinkPad R400
- ThinkPad R500
- ThinkPad W500
- ThinkPad T410
- ThinkPad T420
- ThinkPad T420s
- ThinkPad T430
- ThinkPad T430s
- ThinkPad T431s
- ThinkPad T440p
- ThinkPad T520
- ThinkPad W520
- ThinkPad T530
- ThinkPad W530
- ThinkPad X131e
- ThinkPad X1 carbon gen 1
- ThinkPad X200 / X200s / X200t
- ThinkPad X301
- ThinkPad X201 / X201i / X201s / X201t
- ThinkPad X220
- ThinkPad X220i
- ThinkPad X1
- ThinkPad X230
- ThinkPad X230t
## OpenCellular
- Elgon (GBCv2)
## SAMSUNG
- Lumpy
- Stumpy
## Siemens
- MC APL1
- MC APL2
- MC APL3
- MC APL4
- MC APL5
- MC APL6
## Supermicro
- X11SSH-TF
- X11SSM-F
## UP
- Squared

4
Documentation/security/vboot/measured_boot.md
View File

@@ -120,12 +120,12 @@ PCR-7 are left empty.
### PCR-0
_Hash:_ SHA1
_Description:_ Google VBoot GBB flags.
_Description:_ Google vboot GBB flags.
### PCR-1
_Hash:_ SHA1/SHA256
_Description:_ Google VBoot GBB HWID.
_Description:_ Google vboot GBB HWID.
### PCR-2
_Hash:_ SHA1/SHA256

265
Documentation/soc/amd/psp_integration.md
View File

@@ -37,38 +37,40 @@ any of the eligible locations. Below are typical definitions within the
structure (for all families combined). Individual features supported vary by
family and model.
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bytes) | Description/Purpose |
+--------------+---------------+------------------+----------------------------+
| Signature | 0x00 | 4 | 0x55aa55aa |
|--------------|---------------|------------------|----------------------------|
| IMC FW | 0x04 | 4 | Integrated Micro |
| | | | Controller: unsupported |
| | | | but functional in some |
| | | | systems |
|--------------|---------------|------------------|----------------------------|
| GbE FW | 0x08 | 4 | Gigabit Ethernet |
|--------------|---------------|------------------|----------------------------|
| xHCI FW | 0x0c | 4 | xHCI firmware |
|--------------|---------------|------------------|----------------------------|
| PSP Dir Tbl | 0x10 | 4 | Pointer to PSP Directory |
| | | | Table (early devices) |
|--------------|---------------|------------------|----------------------------|
| PSP Dir Tbl | 0x14 | 4 | Pointer to PSP Directory |
| | | | Table (later devices and |
| | | | is combo capable) |
|--------------|---------------|------------------|----------------------------|
| BIOS Dir Tbl | 0x18 | 4 | Pointer to BIOS Directory |
| | | | Table for models n* |
|--------------|---------------|------------------|----------------------------|
| BIOS Dir Tbl | 0x1c | 4 | Pointer to BIOS Directory |
| | | | Table for models nn |
|--------------|---------------|------------------|----------------------------|
| BIOS Dir Tbl | 0x20 | 4 | Pointer to BIOS Directory |
| | | | Table for models nnn |
|--------------|---------------|------------------|----------------------------|
| … | | | ... |
+--------------+---------------+------------------+----------------------------+
```eval_rst
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bytes) | Description/Purpose |
+==============+===============+==================+============================+
| Signature | 0x00 | 4 | 0x55aa55aa |
+--------------+---------------+------------------+----------------------------+
| IMC FW | 0x04 | 4 | Integrated Micro |
| | | | Controller: unsupported |
| | | | but functional in some |
| | | | systems |
+--------------+---------------+------------------+----------------------------+
| GbE FW | 0x08 | 4 | Gigabit Ethernet |
+--------------+---------------+------------------+----------------------------+
| xHCI FW | 0x0c | 4 | xHCI firmware |
+--------------+---------------+------------------+----------------------------+
| PSP Dir Tbl | 0x10 | 4 | Pointer to PSP Directory |
| | | | Table (early devices) |
+--------------+---------------+------------------+----------------------------+
| PSP Dir Tbl | 0x14 | 4 | Pointer to PSP Directory |
| | | | Table (later devices and |
| | | | is combo capable) |
+--------------+---------------+------------------+----------------------------+
| BIOS Dir Tbl | 0x18 | 4 | Pointer to BIOS Directory |
| | | | Table for models n* |
+--------------+---------------+------------------+----------------------------+
| BIOS Dir Tbl | 0x1c | 4 | Pointer to BIOS Directory |
| | | | Table for models nn |
+--------------+---------------+------------------+----------------------------+
| BIOS Dir Tbl | 0x20 | 4 | Pointer to BIOS Directory |
| | | | Table for models nnn |
+--------------+---------------+------------------+----------------------------+
| … | | | ... |
+--------------+---------------+------------------+----------------------------+
```
* The Embedded Firmware Structure may support pointers to multiple generations
of devices, e.g. Family 17h Models 00h-0Fh, Family 17h Models 10h-1Fh, etc.
@@ -83,46 +85,47 @@ allowing secondary tables to be referenced by device ID. No coreboot
implementations currently use combo tables.
### PSP Directory Table Header
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bytes) | Description/Purpose |
+--------------+---------------+------------------+----------------------------+
| PSP Cookie | 0x00 | 4 | PSP cookie "$PSP" to |
| | | | recognize the header. |
| | | | Cookie “$PL2” for level 2 |
|--------------|---------------|------------------|----------------------------|
| Checksum | 0x04 | 4 | 32-bit CRC value of header |
| | | | below this field and |
| | | | including all entries |
|--------------|---------------|------------------|----------------------------|
| Total Entries| 0x08 | 4 | Number of PSP Directory |
| | | | entries in the table |
|--------------|---------------|------------------|----------------------------|
| Reserved | 0x0C | 4 | Reserved - Set to zero |
+--------------+---------------+------------------+----------------------------+
```eval_rst
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bytes) | Description/Purpose |
+==============+===============+==================+============================+
| PSP Cookie | 0x00 | 4 | PSP cookie "$PSP" to |
| | | | recognize the header. |
| | | | Cookie “$PL2” for level 2 |
+--------------+---------------+------------------+----------------------------+
| Checksum | 0x04 | 4 | 32-bit CRC value of header |
| | | | below this field and |
| | | | including all entries |
+--------------+---------------+------------------+----------------------------+
| Total Entries| 0x08 | 4 | Number of PSP Directory |
| | | | entries in the table |
+--------------+---------------+------------------+----------------------------+
| Reserved | 0x0C | 4 | Reserved - Set to zero |
+--------------+---------------+------------------+----------------------------+
```
### PSP Directory Table Entries
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bits) | Description/Purpose |
+--------------+---------------+------------------+----------------------------+
| Type | 0x00 | 8 | Entry type (see below) |
|--------------|---------------|------------------|----------------------------|
| Sub Program | 0x01 | 8 | Specifies sub program |
|--------------|---------------|------------------|----------------------------|
| Reserved | 0x02 | 16 | Reserved - set to 0 |
|--------------|---------------|------------------|----------------------------|
| Size | 0x04 | 32 | Size of PSP entry in bytes |
|--------------|---------------|------------------|----------------------------|
| Location / | 0x08 | 64 | Location: Physical Address |
| Value | | | of SPIROM location where |
| | | | corresponding PSP entry |
| | | | located. |
| | | | |
| | | | Value: 64-bit value for the|
| | | | PSP Entry |
+--------------+---------------+------------------+----------------------------+
```eval_rst
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bits) | Description/Purpose |
+==============+===============+==================+============================+
| Type | 0x00 | 8 | Entry type (see below) |
+--------------+---------------+------------------+----------------------------+
| Sub Program | 0x01 | 8 | Specifies sub program |
+--------------+---------------+------------------+----------------------------+
| Reserved | 0x02 | 16 | Reserved - set to 0 |
+--------------+---------------+------------------+----------------------------+
| Size | 0x04 | 32 | Size of PSP entry in bytes |
+--------------+---------------+------------------+----------------------------+
| Location / | 0x08 | 64 | Location: Physical Address |
| Value | | | of SPIROM location where |
| | | | corresponding PSP entry |
| | | | located. |
| | | | |
| | | | Value: 64-bit value for the|
| | | | PSP Entry |
+--------------+---------------+------------------+----------------------------+
```
### PSP Directory Table Types
**0x00**: AMD public key
@@ -248,68 +251,72 @@ The BIOS Directory table structure is slightly different from the PSP Directory:
### BIOS Directory Table Header
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bytes) | Description/Purpose |
+--------------+---------------+------------------+----------------------------+
| BIOS Cookie | 0x00 | 4 | BIOS cookie "$BHD" to |
| | | | recognize the header. |
| | | | Cookie “$BL2” for level 2 |
|--------------|---------------|------------------|----------------------------|
| Checksum | 0x04 | 4 | 32 bit CRC value of header |
| | | | below this field and |
| | | | including all entries |
|--------------|---------------|------------------|----------------------------|
| Total Entries| 0x08 | 4 | Number of BIOS Directory |
| | | | entries in the table |
|--------------|---------------|------------------|----------------------------|
| Reserved | 0x0C | 4 | Reserved - Set to zero |
+--------------+---------------+------------------+----------------------------+
```eval_rst
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bytes) | Description/Purpose |
+==============+===============+==================+============================+
| BIOS Cookie | 0x00 | 4 | BIOS cookie "$BHD" to |
| | | | recognize the header. |
| | | | Cookie “$BL2” for level 2 |
+--------------+---------------+------------------+----------------------------+
| Checksum | 0x04 | 4 | 32 bit CRC value of header |
| | | | below this field and |
| | | | including all entries |
+--------------+---------------+------------------+----------------------------+
| Total Entries| 0x08 | 4 | Number of BIOS Directory |
| | | | entries in the table |
+--------------+---------------+------------------+----------------------------+
| Reserved | 0x0C | 4 | Reserved - Set to zero |
+--------------+---------------+------------------+----------------------------+
```
### BIOS Directory Table Entries
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bits) | Description/Purpose |
+--------------+---------------+------------------+----------------------------+
| Type | 0x00 | 8 | Entry type (see below) |
|--------------|---------------|------------------|----------------------------|
| Region Type | 0x01 | 8 | Setup the memory region's |
| | | | security attribute for the |
| | | | BIOS entry |
|--------------|---------------|------------------|----------------------------|
| Reset Image | 0x02[0] | 1 | Boolean value to define the|
| | | | BIOS entry is a reset |
| | | | binary image |
|--------------|---------------|------------------|----------------------------|
| Copy Image | 0x02[1] | 1 | Define the binary image of |
| | | | the BIOS entry is for |
| | | | copying over to the memory |
| | | | region |
|--------------|---------------|------------------|----------------------------|
| Read Only | 0x02[2] | 1 | Setup the memory region for|
| | | | the BIOS entry to read only|
|--------------|---------------|------------------|----------------------------|
| Compressed | 0x02[3] | 1 | Compressed using zlib |
| | | | |
|--------------|---------------|------------------|----------------------------|
| Instance | 0x02[7:4] | 4 | Specify the Instance of an |
| | | | entry |
|--------------|---------------|------------------|----------------------------|
| SubProgram | 0x03[2:0] | 3 | Specify the SubProgram |
|--------------|---------------|------------------|----------------------------|
| Reserved | 0x03[7:3] | 5 | Reserved - Set to zero |
|--------------|---------------|------------------|----------------------------|
| Size | 0x04 | 32 | Memory Region Size |
|--------------|---------------|------------------|----------------------------|
| Source | 0x08 | 64 | Physical Address of SPIROM |
| Address | | | location where the data for|
| | | | the corresponding entry is |
| | | | located |
|--------------|---------------|------------------|----------------------------|
| Destination | 0x10 | 64 | Destination Address of |
| Address | | | memory location where the |
| | | | data for the corresponding |
| | | | BIOS Entry is copied |
+--------------+---------------+------------------+----------------------------+
```eval_rst
+--------------+---------------+------------------+----------------------------+
| Field Name | Offset (Hex) | Size (In Bits) | Description/Purpose |
+==============+===============+==================+============================+
| Type | 0x00 | 8 | Entry type (see below) |
+--------------+---------------+------------------+----------------------------+
| Region Type | 0x01 | 8 | Setup the memory region's |
| | | | security attribute for the |
| | | | BIOS entry |
+--------------+---------------+------------------+----------------------------+
| Reset Image | 0x02[0] | 1 | Boolean value to define the|
| | | | BIOS entry is a reset |
| | | | binary image |
+--------------+---------------+------------------+----------------------------+
| Copy Image | 0x02[1] | 1 | Define the binary image of |
| | | | the BIOS entry is for |
| | | | copying over to the memory |
| | | | region |
+--------------+---------------+------------------+----------------------------+
| Read Only | 0x02[2] | 1 | Setup the memory region for|
| | | | the BIOS entry to read only|
+--------------+---------------+------------------+----------------------------+
| Compressed | 0x02[3] | 1 | Compressed using zlib |
| | | | |
+--------------+---------------+------------------+----------------------------+
| Instance | 0x02[7:4] | 4 | Specify the Instance of an |
| | | | entry |
+--------------+---------------+------------------+----------------------------+
| SubProgram | 0x03[2:0] | 3 | Specify the SubProgram |
+--------------+---------------+------------------+----------------------------+
| Reserved | 0x03[7:3] | 5 | Reserved - Set to zero |
+--------------+---------------+------------------+----------------------------+
| Size | 0x04 | 32 | Memory Region Size |
+--------------+---------------+------------------+----------------------------+
| Source | 0x08 | 64 | Physical Address of SPIROM |
| Address | | | location where the data for|
| | | | the corresponding entry is |
| | | | located |
+--------------+---------------+------------------+----------------------------+
| Destination | 0x10 | 64 | Destination Address of |
| Address | | | memory location where the |
| | | | data for the corresponding |
| | | | BIOS Entry is copied |
+--------------+---------------+------------------+----------------------------+
```
### BIOS Directory Table Entry Types

2
Documentation/soc/intel/fit.md
View File

@@ -57,4 +57,4 @@ 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)
* [FIT BIOS specification](https://www.intel.com/content/dam/www/public/us/en/documents/guides/fit-bios-specification.pdf)

6
Documentation/soc/intel/fsp/index.md
View File

@@ -45,6 +45,11 @@ those are fixed. If possible a workaround is described here as well.
* Workaround: Disable internal UART manually after calling FSP
* Issue on public tracker: [Issue 10]
### CoffeeLakeFsp
* Disabling the internal graphics causes a crash in FSP-M
* 7.0.68.40 and older version
* Workaround: Set "tconfig->PanelPowerEnable = 0"
* Issue on public tracker: [Issue 49]
## Open Source Intel FSP specification
@@ -72,4 +77,5 @@ those are fixed. If possible a workaround is described here as well.
[Issue 22]: https://github.com/IntelFsp/FSP/issues/22
[Issue 35]: https://github.com/IntelFsp/FSP/issues/35
[Issue 41]: https://github.com/IntelFsp/FSP/issues/41
[Issue 49]: https://github.com/IntelFsp/FSP/issues/49

46
Documentation/superio/common/pnp.md
View File

@@ -15,13 +15,13 @@ specification is still the main reference though.
Super I/O chips connected via LPC to the southbridge usually have their
I/O-mapped configuration interface with a size of two bytes at the base
address 0x2e or 0x4e. Other PNP devices have their configuration
address `0x2e` or `0x4e`. Other PNP devices have their configuration
interface at other addresses.
The two byte registers allow access to an indirect 256 bytes big
register space that contains the configuration. By writing the index
to the lower byte (e.g. 0x2e), you can access the register contents at
that index by reading/writing the higher byte (e.g. 0x2f).
register space that contains the configuration. By writing the index to
the lower byte (e.g. `0x2e`), you can access the register contents at
that index by reading/writing the higher byte (e.g. `0x2f`).
To prevent accidental changes of the Super I/O (SIO) configuration,
the SIOs need a configuration mode unlock sequence. After changing the
@@ -31,18 +31,18 @@ the configuration mode lock sequence.
## Logical device numbers (LDN)
Each PNP device can contain multiple logical devices. The bytes from
0x00 to 0x2f in the indirect configuration register space are common
for all LDNs, but some SIO chips require a certain LDN to be selected
in order to write certain registers in there. An LDN gets selected by
writing the LDN number to the LDN select register 0x07. Registers 0x30
to 0xFF are specific to each LDN number.
`0x00` to `0x2f` in the indirect configuration register space are common
for all LDNs, but some SIO chips require a certain LDN to be selected in
order to write certain registers in there. An LDN gets selected by
writing the LDN number to the LDN select register `0x07`. Registers
`0x30` to `0xff` are specific to each LDN number.
coreboot encodes the physical LDN number in the lower byte of the LDN
number.
### Virtual logical device numbers
Register 0x30 is the LDN enable register and since it is an 8 bit
Register `0x30` is the LDN enable register and since it is an 8 bit
register, it can contain up to 8 enable bits for different parts of
the functionality of that logical device. To set a certain enable bit
in one physical LDN, the concept of virtual LDNs was introduced.
@@ -54,7 +54,7 @@ part in the lower 3 bits of the higher byte of the LDN number.
## I/O resources
Starting at register address 0x60, each LDN has 2 byte wide I/O base
Starting at register address `0x60`, each LDN has 2 byte wide I/O base
address registers. The size of an I/O resource is always a power of
two.
@@ -67,29 +67,29 @@ number of LSBs being zero, which can also be zero if the LSB is a one,
the resource has N address bits and a size of 2\*\*N bytes. The mask
address is also the highest possible address to map the I/O region.
A typical example for an I/O resource mask is 0x07f8 which is
0b0000011111111000 in binary notation. The three LSBs are zeros here,
A typical example for an I/O resource mask is `0x07f8` which is
`0b0000011111111000` in binary notation. The three LSBs are zeros here,
so it's an eight byte I/O resource with three address offset bits
inside the resource. The highest base address it can be mapped to is
0x07f8, so the region will end at 0x07ff.
`0x07f8`, so the region will end at `0x07ff`.
The Super I/O datasheets typically contain the information about the
I/O resource masks. On most Super I/O chips the mask can also be found
out by writing 0xffff to the corresponding I/O base address register
out by writing `0xffff` to the corresponding I/O base address register
and reading back the value; since the lowest and highest bits are
hard-wired to zero according to the I/O resource size and maximal
possible I/O address, this gives the mask.
## IRQ resources
Each physical LDN has up to two configurable interrupt request
register pairs 0x70, 0x71 and 0x72, 0x73. Each pair can be configured
to use a certain IRQ number. Writing 1 to 15 into the first register
Each physical LDN has up to two configurable interrupt request register
pairs `0x70`, `0x71` and `0x72`, `0x73`. Each pair can be configured to
use a certain IRQ number. Writing 1 to 15 into the first register
selects the IRQ number generated by the corresponding IRQ source and
enables IRQ generation; writing 0 to it disables the generation of
IRQs for the source. The second register selects the IRQ type (level
or edge) and IRQ level (high or low). For LPC SIOs the IRQ type is
hard-wired to edge.
enables IRQ generation; writing 0 to it disables the generation of IRQs
for the source. The second register selects the IRQ type (level or edge)
and IRQ level (high or low). For LPC SIOs the IRQ type is hard-wired to
edge.
On the LPC bus a shared SERIRQ line is used to signal IRQs to the
host; the IRQ number gets encoded by the number of LPC clock cycles
@@ -106,7 +106,7 @@ number. The quiet mode is often broken.
## DRQ resources
Each physical LDN has two legacy ISA-style DMA request channel
registers at 0x74 and 0x75. Those are only used for legacy devices
registers at `0x74` and `0x75`. Those are only used for legacy devices
like parallel printer ports or floppy disk controllers.
Each device using LPC legacy DMA needs its own LDMA line to the host.

1
Documentation/superio/index.md
View File

@@ -5,6 +5,7 @@ This section contains documentation about coreboot on specific SuperIOs.
## Nuvoton
- [NPCD378](nuvoton/npcd378.md)
- [NCT5539D](nuvoton/nct5539d.md)
## Common
- [PNP devices](common/pnp.md)

9
Documentation/superio/nuvoton/nct5539d.md Normal file
View File

@@ -0,0 +1,9 @@
# NCT5539D SuperIO
The SuperIO has the ID `0xd121` and the source can be found in
`src/superio/nuvoton/nct5539d/`.
## For developers
The SuperIO generates ACPI using the
[SSDT generator for generic SuperIOs](../common/ssdt.md).

319
Documentation/technotes/2020-03-unit-testing-coreboot.md Normal file
View File

@@ -0,0 +1,319 @@
# Unit testing coreboot
## Preface
First part of this document, Introduction, comprises disambiguation for what
unit testing is and what is not. This definition will be a basis for the whole
paper.
Next, Rationale, explains why to use unit testing and how coreboot specifically
may benefit from it.
This is followed by evaluation of different available free C unit test
frameworks. Firstly, collection of requirements is provided. Secondly, there is
a description of a few selected candidates. Finally, requirements are applied to
candidates to see if they might be a good fit.
Fourth part is a summary of evaluation, with proposal of unit test framework
for coreboot to be used.
Finally, Implementation proposal paragraph touches how build system and coreboot
codebase in general should be organized, in order to support unit testing. This
comprises couple of design considerations which need to be addressed.
## Introduction
A unit test is supposed to test a single unit of code in isolation. In C
language (in contrary to OOP) unit usually means a function. One may also
consider unit under test to be a single compilation unit which exposes some
API (set of functions). A function, talking to some external component can be
tested if this component can be mocked out.
In other words (looking from C compilation angle), there should be no extra
dependencies (executables) required beside unit under test and test harness in
order to compile unit test binary. Test harness, beside code examining a
routines, may comprise test framework implementation.
It is hard to apply this strict definition of unit test to firmware code in
practice, mostly due to constraints on speed of execution and size of final
executable. coreboot codebase often cannot be adjusted to be testable. Because
of this, coreboot unit testing subsystem should allow to include some additional
source object files beside unit under test. That being said, the default and
goal wherever possible, should be to isolate unit under test from other parts.
Unit testing is not an integration testing and it doesn't replace it. First of
all, integration tests cover larger set of components and interactions between
them. Positive integration test result gives more confidence than a positive
unit test does. Furthermore, unit tests are running on the build machine, while
integration tests usually are executed on the target (or simulator).
## Rationale
Considering above, what is the benefit of unit testing, especially keeping in
mind that coreboot is low-level firmware? Unit tests should be quick, thus may
be executed frequently during development process. It is much easier to build
and run a unit test on a build machine, than any integration test. This in turn
may be used by dev to gather extra confidence early during code development
process. Actually developer may even write unit tests earlier than the code -
see [TDD](https://en.wikipedia.org/wiki/Test-driven_development) concept.
That being said, unit testing embedded C code is a difficult task, due to
significant amount of dependencies on underlying hardware. Mocking can handle
some hardware dependencies. However, complex mocks make the unit test
susceptible to failing and can require significant development effort.
Writing unit tests for a code (both new and currently existing) may be favorable
for the code quality. It is not only about finding bugs, but in general - easily
testable code is a good code.
coreboot benefits the most from testing common libraries (lib/, commonlib/,
payloads/libpayload) and coreboot infrastructure (console/, device/, security/).
## Evaluation of unit testing frameworks
### Requirements
Requirements for unit testing frameworks:
* Easy to use
* Few dependencies
Standard C library is all we should need
* Isolation between tests
* Support for mocking
* Support for some machine parsable output
* Compiler similarity
Compiler for the host _must_ support the same language standards as the target
compiler. Ideally the same toolchain should be used for building firmware
executables and test binaries, however the host complier will be used to build
unit tests, whereas the coreboot toolchain will be used for building the
firmware executables. For some targets, the host compiler and the target
compiler could be the same, but this is not a requirement.
* Same language for tests and code
Unit tests will be written in C, because coreboot code is also written in C
### Desirables
* Easy to integrate with build system/build tools
Ideally JUnit-like XML output format for Jenkins
* Popularity is a plus
We want a larger community for a couple of reasons. Firstly, easier access to
people with knowledge and tutorials. Secondly, bug fixes for the top of tree
are more frequent and known issues are usually shorter in the pending state.
Last but not least, larger reviewer pool means better and easier upstream
improvements that we would like to submit.
* Extra features may be a plus
* Compatible license
This should not be a blocker, since test binaries are not distributed.
However ideally compatible with GPL.
* IDE integration
### Candidates
There is a lot of frameworks which allow unit testing C code
([list](https://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#C) from
Wikipedia). While not all of them were evaluated, because that would take an
excessive amount of time, couple of them were selected based on the good
opinions among C devs, popularity and fitting above criteria.
* [SputUnit](https://www.use-strict.de/sput-unit-testing/)
* [GoogleTest](https://github.com/google/googletest)
* [Cmocka](https://cmocka.org/)
* [Unity](http://www.throwtheswitch.org/unity) (CMock, Ceedling)
We looked at several other test frameworks, but decided not to do a full evaluation
for various reasons such as functionality, size of the developer community, or
compatibility.
### Evaluation
* [SputUnit](https://www.use-strict.de/sput-unit-testing/)
* Pros
* No dependencies, one header file to include - that’s all
* Pure C
* Very easy to use
* BSD license
* Cons
* Main repo doesn’t have support for generating JUnit XML reports for
Jenkins to consume - this feature is available only on the fork from
SputUnit called “Sput_report”. It makes it niche in a niche, so there are
some reservations whether support for this will be satisfactory
* No support for mocks
* Not too popular
* No automatic test registration
* [GoogleTest](https://github.com/google/googletest)
* Pros
* Automatic test registration
* Support for different output formats (including XML for Jenkins)
* Good support, widely used, the biggest and the most active community out
of all frameworks that were investigated
* Available as a package in the most common distributions
* Test fixtures easily available
* Well documented
* Easy to integrate with an IDE
* BSD license
* Cons
* Requires C++11 compiler
* To make most out of it (use GMock) C++ knowledge is required
* [Cmocka](https://cmocka.org/)
* Pros
* Self-contained, autonomous framework
* Pure C
* API is well documented
* Multiple output formats (including XML for Jenkins)
* Available as a package in the most common distributions
* Used in some popular open source projects (libssh, OpenVPN, Samba)
* Test fixtures available
* Support for exception handling
* Cons
* No automatic test registration
* It will require some effort to make it work from within an IDE
* Apache 2.0 license (not compatible with GPLv2)
* [Unity](http://www.throwtheswitch.org/unity) (CMock, Ceedling)
* Pros
* Pure C (Unity testing framework itself, not test runner)
* Support for different output formats (including XML for Jenkins)
* There are some (rather easy) hints how to use this from an IDE (e.g. Eclipse)
* MIT license
* Cons
* Test runner (Ceedling) is not written in C - uses Ruby
* Mocking/Exception handling functionalities are actually separate tools
* No automatic test registration
* Not too popular
### Summary & framework proposal
After research, we propose using the Cmocka unit test framework. Cmocka fulfills
all stated evaluation criteria. It is rather easy to use, doesn’t have extra
dependencies, written fully in C, allows for tests fixtures and some popular
open source projects already are using it. Cmocka also includes support for
mocks.
Cmocka's limitations, such as the lack of automatic test registration, are
considered minor issues that will require only minimal additional work from a
developer. At the same time, it may be worth to propose improvement to Cmocka
community or simply apply some extra wrapper with demanded functionality.
## Implementation
### Framework as a submodule or external package
Unit test frameworks may be either compiled from source (from a git submodule
under 3rdparty/) or pre-compiled as a package. The second option seems to be
easier to maintain, while at the same time may bring some unwanted consequences
(different version across distributions, frequent changes in API). It makes sense
to initially experiment with packages and check how it works. If this will
cause any issues, then it is always possible to switch to submodule approach.
### Integration with build system
To get the most out of unit testing framework, it should be integrated with
Jenkins automation server. Verification of all unit tests for new changes may
improve code reliability to some extent.
### Build configuration (Kconfig)
While building unit under test object file, it is necessary to apply some
configuration (config) just like when building usual firmware. For simplicity,
there will be one default tests .config `qemu_x86_i440fx` for all unit tests. At
the same time, some tests may require running with different values of particular
config. This should be handled by adding extra header, included after config.h.
This header will comprise #undef of old CONFIG values and #define of the
required value. When unit testing will be integrated with Jenkins, it may be
preferred to use every available config for periodic builds.
### Directory structure
Tests should be kept separate from the code, while at the same time it must be
easy to match code with test harness.
We create new directory for test files ($(toplevel)/tests/) and mimic the
structure of src/ directory.
Test object files (test harness, unit under tests and any additional executables
are stored under build/tests/<test_name> directory.
Below example shows how directory structure is organized for the two test cases:
tests/lib/string-test and tests/device/i2c-test:
```bash
├── src
│ ├── lib
│ │ ├── string.c <- unit under test
│ │
│ ├── device
│ ├── i2c.c
│
├── tests
│ ├── include
│ │ ├── mocks <- mock headers, which replace original headers
│ │
│ ├── Makefile.inc <- top Makefile for unit tests subsystem
│ ├── lib
│ │ ├── Makefile.inc
│ │ ├── string-test.c <- test code for src/lib/string.c
│ │ │
│ ├── device
│ │ ├── Makefile.inc
│ ├── i2c-test.c
│
├── build
│ ├── tests <-all test-related executables
├── config.h <- default config used for tests builds
├── lib
│ ├── string-test <- all string-test executables
│ │ ├── run <- final test binary
│ │ ├── tests <- all test harness executables
│ │ ├── lib
│ │ ├── string-test.o <-test harness executable
│ │ ├── src <- unit under test and other src executables
│ │ ├── lib
│ │ ├── string.o <- unit under test executable
├── device
├── i2c-test
├── run
├── tests
│ ├── device
│ ├── i2c-test.o
├── src
├── device
├── i2c.o
```
### Adding new tests
For purpose of this description, let's assume that we want to add a new unit test
for src/device/i2c.c module. Since this module is rather simple, it will be enough
to have only one test module.
Firstly (assuming there is no tests/device/Makefile.inc file) we need to create
Makefile.inc in main unit test module directory. Inside this Makefile.inc, one
need to register new test and can specify multiple different attributes for it.
```bash
# Register new test, by adding its name to tests variable
tests-y += i2c-test
# All attributes are defined by <test_name>-<attribute> variables
# <test_name>-srcs is used to register all input files (test harness, unit under
# test and others) for this particular test. Remember to add relative paths.
i2c-test-srcs += tests/device/i2c-test.c
i2c-test-srcs += src/device/i2c.c
# We can define extra cflags for this particular test
i2c-test-cflags += -DSOME_DEFINE=1
# For mocking out external dependencies (functions which cannot be resolved by
# linker), it is possible to register a mock function. To register new mock, it
# is enough to add function-to-be-mocked name to <test_name>-mocks variable.
i2c-test-mocks += platform_i2c_transfer
# Similar to coreboot concept, unit tests also runs in the context of stages.
# By default all unit tests are compiled to be ramstage executables. If one want
# to overwrite this setting, there is <test_name>-stage variable available.
i2c-test-stage:= bootblock
```
### Writing new tests
Full description of how to write unit tests and Cmocka API description is out of
the scope of this document. There are other documents related to this
[Cmocka API](https://api.cmocka.org/) and
[Mocks](https://lwn.net/Articles/558106/).

1
Documentation/technotes/index.md
View File

@@ -2,3 +2,4 @@
* [Dealing with Untrusted Input in SMM](2017-02-dealing-with-untrusted-input-in-smm.md)
* [Rebuilding coreboot image generation](2015-11-rebuilding-coreboot-image-generation.md)
* [Unit testing coreboot](2020-03-unit-testing-coreboot.md)

2
Documentation/tutorial/part1.md
View File

@@ -173,7 +173,7 @@ Here's the command line instruction broken down:
This starts the QEMU emulator with the i440FX host PCI bridge and PIIX3 PCI to
ISA bridge.
* `-bios build/coreboot.rom`
Use the bios rom image that we just built. If this flag is left out, the
Use the coreboot rom image that we just built. If this flag is left out, the
standard SeaBIOS image that comes with QEMU is used.
* `-serial stdio`
Send the serial output to the console. This allows you to view the coreboot

28
Documentation/util.md
View File

@@ -10,8 +10,6 @@ available targets. `bash`
* __amdtools__ - A set of tools to compare extended) K8 memory
settings. `Perl`
* __archive__ - Concatenate files and create an archive `C`
* __mksunxiboot__ - A simple tool to generate bootable image for sunxi
platform. `C`
* __autoport__ - Automated porting coreboot to Sandy Bridge/Ivy Bridge
platforms `Go`
* __bincfg__ - Compiler/Decompiler for data blobs with specs `Lex`
@@ -26,11 +24,11 @@ file `Python`
* _fmaptool_ - Converts plaintext fmd files into fmap blobs `C`
* _rmodtool_ - Creates rmodules `C`
* _ifwitool_ - For manipulating IFWI `C`
* __cbmem__ - Cbmem console log reader `C`
* __checklist__ - Board implementation checklist generator `Make`
* __chromeos__ - These scripts can be used to extract System Agent
reference code and other blobs (e.g. mrc.bin, refcode, VGA option roms)
from a Chrome OS recovery image. `C`
* __cbmem__ - CBMEM parser to read e.g. timestamps and console log `C`
* __chromeos__ - These scripts can be used to access Chrome OS
resources, for example to extract System Agent reference code and other
blobs (e.g. mrc.bin, refcode, VGA option roms) from a Chrome OS
recovery image. `C`
* __crossgcc__ - A cross toolchain builder for -elf toolchains (ie. no
libc support)
* __docker__ - Dockerfiles for _coreboot-sdk_, _coreboot-jenkins-node_,
@@ -62,8 +60,6 @@ specified base and size `Python`
* _mbncat.py_ - Generate ipq8064 uber SBL `Python`
* *mbn_tools.py* - Contains all MBN Utilities for image
generation `Python`
* __k8resdump__ - This program will dump the IO/memory/PCI resources
from the K8 memory controller `C`
* __kbc1126__ - Tools used to dump the two blobs from the factory
firmware of many HP laptops with 8051-based SMSC KBC1098/KBC1126
embedded controller and insert them to the firmware image. `C`
@@ -78,6 +74,8 @@ partial deblobbing of Intel ME/TXE firmware images `Python`
* __nvidia__ - nvidia blob parsers
* __nvramtool__ - Reads and writes coreboot parameters and displaying
information from the coreboot table in CMOS/NVRAM. `C`
* __pgtblgen__ - Generates page tables based on fixed physical address.
`C`
* __pmh7tool__ - Dumps, reads and writes PMH7 registers on Lenovo
ThinkPads. PMH7 is used for switching on and off the power of some
devices on the board such as dGPU. `C`
@@ -91,14 +89,14 @@ can be passed to SPIKE, the RISC-V reference emulator.`Bash`
* _sifive-gpt.py_ - Wraps the bootblock in a GPT partition for
SiFive's bootrom. `Python3`
* __rockchip__ - Generate Rockchip idblock bootloader. `Python2`
* __romcc__ - Compile a C source file generating a binary that does not
implicitly use RAM. `C`
* __sconfig__ - coreboot device tree compiler `Lex` `Yacc`
* __scripts__
* _config_ - Manipulate options in a .config file from the
command line `Bash`
* _cross-repo-cherrypick_ - Pull in patches from another tree
from a gerrit repository. `Shell`
* _decode_spd.sh_ - Decodes Serial Presence Detect (SPD) files
into various human readable formats.
* _dts-to-fmd.sh_ -Converts a depthcharge fmap.dts into an
fmaptool compatible .fmd format `Bash`
* _find-unused-kconfig-symbols.sh_ - Points out Kconfig
@@ -116,18 +114,22 @@ file `Perl`
* _ucode_h_to_bin.sh_ - Microcode conversion tool `Bash`
* _update_submodules_ - Check all submodules for updates `Bash`
* __showdevicetree__ - Compile and dump the device tree `C`
* __spdtool__ - Dumps SPD ROMs from a given blob to separate files
using known patterns and reserved bits. Useful for analysing firmware
that holds SPDs on boards that have soldered down DRAM. `python`
* __spkmodem_recv__ - Decode spkmodem signals `C`
* __superiotool__ - A user-space utility to detect Super I/O of a
mainboard and provide detailed information about the register contents
of the Super I/O. `C`
* __smcbiosinfo__ - Generates SMC biosinfo for BMC BIOS updates `C`
* __testing__ - coreboot test targets `Make`
* __uio_usbdebug__ - Debug coreboot's usbdebug driver inside a running
operating system (only Linux at this time). `C`
* __util_readme__ - Creates README.md of description files in `./util`
subdirectories `Bash`
* __vboot_list__ - Tools to generate a list of vboot enabled devices to
the documentation `Bash`
* __vgabios__ - emulated vga driver for qemu `C`
* __viatool__ - Extract certain configuration bits on VIA chipsets and
CPUs. `C`
* __x86__ - Generates 32-bit PAE page tables based on a CSV input file.
`Go`
* __xcompile__ - Cross compile setup `Bash`

42
MAINTAINERS
View File

@@ -198,10 +198,10 @@ M: Damien Zammit <damien@zamaudio.com>
S: Odd Fixes
F: src/mainboard/gigabyte/ga-g41m-es2l
GIGABYTE GA-H61M-S2PV MAINBOARD
GIGABYTE GA-H61M SERIES MAINBOARDS
M: Angel Pons <th3fanbus@gmail.com>
S: Maintained
F: src/mainboard/gigabyte/ga-h61m-s2pv
F: src/mainboard/gigabyte/ga-h61m-series
GOOGLE PANTHER MAINBOARD
M: Stefan Reinauer <stefan.reinauer@coreboot.org>
@@ -223,7 +223,7 @@ F: src/mainboard/google/slippy/
F: src/mainboard/google/stout/
OPENCELLULAR MAINBOARDS
M: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
M: Christian Walter <christian.walter@9elements.com>
M: Patrick Rudolph <patrick.rudolph@9elements.com>
S: Supported
F: src/mainboard/opencellular/elgon/
@@ -317,12 +317,24 @@ M: Vlado Cibic <vladocb@protonmail.com>
S: Maintained
F: src/mainboard/asus/p8z77-m_pro/
LIBRETREND LT1000 MAINBOARD
M: Piotr Król <piotr.krol@3mdeb.com>
M: Michał Żygowski <michal.zygowski@3mdeb.com>
S: Maintained
F: src/mainboard/libretrend/lt1000
PC ENGINES ALL MAINBOARDS
M: Piotr Król <piotr.krol@3mdeb.com>
M: Michał Żygowski <michal.zygowski@3mdeb.com>
S: Supported
F: src/mainboard/pcengines/
PROTECTLI ALL MAINBOARDS
M: Piotr Król <piotr.krol@3mdeb.com>
M: Michał Żygowski <michal.zygowski@3mdeb.com>
S: Maintained
F: src/mainboard/protectli/
SIEMENS MC_xxxx MAINBOARDS
M: Werner Zeh <werner.zeh@siemens.com>
S: Maintained
@@ -362,10 +374,6 @@ S: Supported
F: src/drivers/aspeed/common/
F: src/drivers/aspeed/ast2050/
ATI MACH64 Driver
S: Orphan
F: src/drivers/ati/mach64/
ABUILD
M: Patrick Georgi <patrick@georgi-clan.de>
M: Martin Roth <gaumless@gmail.com>
@@ -397,13 +405,10 @@ F: util/rockchip/
ORPHANED ARM SOCS
S: Orphaned
F: src/cpu/allwinner/
F: src/cpu/armltd/
F: src/cpu/ti/
F: src/soc/marvell/
F: src/soc/qualcomm/
F: src/soc/samsung/
F: util/arm_boot_tools/
F: util/exynos/
F: util/ipqheader/
@@ -443,7 +448,7 @@ M: Stefan Reinauer <stefan.reinauer@coreboot.org>
F: util/inteltool/
INTELMETOOL
M: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
M: Christian Walter <christian.walter@9elements.com>
F: util/intelmetool/
ME_CLEANER
@@ -505,15 +510,11 @@ F: src/drivers/uart/
NVRAM
F: util/nvramtool/
F: util/optionlist/
F: payloads/nvramcui/
LIBPAYLOAD
F: payloads/libpayload/
BAYOU PAYLOAD
F: payloads/bayou/
COREINFO PAYLOAD
F: payloads/coreinfo/
@@ -523,7 +524,7 @@ M: Martin Roth <gaumless@gmail.com>
F: payloads/external
LINUXBOOT PAYLOAD INTEGRATION
M: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
M: Christian Walter <christian.walter@9elements.com>
M: Marcello Sylvester Bauer <info@marcellobauer.com>
S: Supported
F: payloads/external/LinuxBoot
@@ -533,10 +534,9 @@ M: Aaron Durbin <adurbin@chromium.org>
F: src/security/vboot/
TPM SUPPORT
M: Philipp Deppenwiese <zaolin.daisuki@gmail.com>
M: Christian Walter <christian.walter@9elements.com>
S: Supported
F: src/drivers/*/tpm/
F: src/security/vboot/vboot_crtm.*
F: src/security/tpm
DOCKER
@@ -585,7 +585,7 @@ MISSING: ELOG
MISSING: SPI
# *** Infrastructure Owners***
# *** Infrastructure Owners ***
# This is intended to let people know who they should contact for issues with various infrastructure pieces.
# Hardware
# Owners: Stefan, Patrick
@@ -596,11 +596,11 @@ MISSING: SPI
# Backups:
# Website
# Owners: Martin, Philipp
# Owners: Martin
# Backups: Patrick, Stefan
# Documentation Website
# Owners: Patrick, Philipp
# Owners: Patrick
# Backups:
CODE OF CONDUCT

22
Makefile
View File

@@ -42,6 +42,8 @@ objutil ?= $(obj)/util
objk := $(objutil)/kconfig
absobj := $(abspath $(obj))
VBOOT_HOST_BUILD ?= $(abspath $(objutil)/vboot_lib)
COREBOOT_EXPORTS := COREBOOT_EXPORTS
COREBOOT_EXPORTS += top src srck obj objutil objk
@@ -82,6 +84,7 @@ Q:=@
ifneq ($(V),1)
ifneq ($(Q),)
.SILENT:
MAKEFLAGS += -s
endif
endif
@@ -138,6 +141,14 @@ NOMKDIR:=1
endif
endif
ifneq ($(filter %-test %-tests,$(MAKECMDGOALS)),)
ifneq ($(filter-out %-test %-tests, $(MAKECMDGOALS)),)
$(error Cannot mix unit-tests targets with other targets)
endif
UNIT_TEST:=1
NOCOMPILE:=
endif
.xcompile: util/xcompile/xcompile
rm -f $@
$< $(XGCCPATH) > $@.tmp
@@ -156,7 +167,9 @@ real-all:
@exit 1
else
ifneq ($(UNIT_TEST),1)
include $(DOTCONFIG)
endif
# in addition to the dependency below, create the file if it doesn't exist
# to silence stupid warnings about a file that would be generated anyway.
@@ -174,7 +187,9 @@ ifneq ($(CONFIG_MMX),y)
CFLAGS_x86_32 += -mno-mmx
endif
ifneq ($(UNIT_TEST),1)
include toolchain.inc
endif
strip_quotes = $(strip $(subst ",,$(subst \",,$(1))))
# fix makefile syntax highlighting after strip macro \" "))
@@ -273,7 +288,14 @@ evaluate_subdirs= \
# collect all object files eligible for building
subdirs:=$(TOPLEVEL)
postinclude-hooks :=
# Don't iterate through Makefile.incs under src/ when building tests
ifneq ($(UNIT_TEST),1)
$(eval $(call evaluate_subdirs))
else
include $(TOPLEVEL)/tests/Makefile.inc
endif
ifeq ($(FAILBUILD),1)
$(error cannot continue build)
endif

87
Makefile.inc
View File

@@ -293,7 +293,7 @@ $(obj)/$(1).aml: $(src)/mainboard/$(MAINBOARDDIR)/$(1).asl $(obj)/config.h
endef
#######################################################################
# Parse plaintext cmos defaults into binary format
# Parse plaintext CMOS defaults into binary format
# arg1: source file
# arg2: binary file name
cbfs-files-processor-nvramtool= \
@@ -421,6 +421,7 @@ CFLAGS_common += -pipe -g -nostdinc -std=gnu11
CFLAGS_common += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
CFLAGS_common += -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough
CFLAGS_common += -Wstrict-aliasing -Wshadow -Wdate-time -Wtype-limits -Wvla
CFLAGS_common += -Wlogical-op -Wduplicated-cond -Wdangling-else
CFLAGS_common += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer
CFLAGS_common += -ffunction-sections -fdata-sections -fno-pie
ifeq ($(CONFIG_COMPILER_GCC),y)
@@ -895,52 +896,42 @@ FMAP_BIOS_SIZE := $(call int-align-down, $(shell echo $(CONFIG_CBFS_SIZE) | tr A
# X86 CONSOLE FMAP region
#
# position, size and entry line of CONSOLE relative to BIOS_BASE, if enabled
FMAP_CONSOLE_BASE := 0
FMAP_CURRENT_BASE := 0
ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
FMAP_CONSOLE_BASE := $(FMAP_CURRENT_BASE)
FMAP_CONSOLE_SIZE := $(CONFIG_CONSOLE_SPI_FLASH_BUFFER_SIZE)
FMAP_CONSOLE_ENTRY := CONSOLE@$(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE)
else # ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
FMAP_CONSOLE_SIZE := 0
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE))
else
FMAP_CONSOLE_ENTRY :=
endif # ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
endif
#
# X86 RW_MRC_CACHE FMAP region
#
# position, size and entry line of MRC_CACHE relative to BIOS_BASE, if enabled
ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
FMAP_MRC_CACHE_BASE := $(call int-align, $(call int-add, $(FMAP_CONSOLE_BASE) \
$(FMAP_CONSOLE_SIZE)), 0x10000)
FMAP_MRC_CACHE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
FMAP_MRC_CACHE_SIZE := $(CONFIG_MRC_SETTINGS_CACHE_SIZE)
FMAP_MRC_CACHE_ENTRY := RW_MRC_CACHE@$(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE)
else # ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
FMAP_MRC_CACHE_BASE := 0
FMAP_MRC_CACHE_SIZE := 0
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE))
else
FMAP_MRC_CACHE_ENTRY :=
endif # ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
endif
#
# X86 SMMSTORE FMAP region
#
# position, size and entry line of SMMSTORE relative to BIOS_BASE, if enabled
ifeq ($(CONFIG_SMMSTORE),y)
FMAP_SMMSTORE_BASE := $(call int-align, $(call int-add, $(FMAP_CONSOLE_BASE) \
$(FMAP_CONSOLE_SIZE) $(FMAP_MRC_CACHE_SIZE)), 0x10000)
FMAP_SMMSTORE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
FMAP_SMMSTORE_SIZE := $(CONFIG_SMMSTORE_SIZE)
FMAP_SMMSTORE_ENTRY := SMMSTORE@$(FMAP_SMMSTORE_BASE) $(FMAP_SMMSTORE_SIZE)
else # ifeq ($(CONFIG_SMMSTORE),y)
FMAP_SMMSTORE_BASE := 0
FMAP_SMMSTORE_SIZE := 0
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_SMMSTORE_BASE) $(FMAP_SMMSTORE_SIZE))
else
FMAP_SMMSTORE_ENTRY :=
endif # ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
endif
#
# X86 FMAP region
#
#
# position, size
FMAP_FMAP_BASE := $(call int-add, $(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE) \
$(FMAP_MRC_CACHE_SIZE) $(FMAP_SMMSTORE_SIZE))
FMAP_FMAP_BASE := $(FMAP_CURRENT_BASE)
FMAP_FMAP_SIZE := 0x200
#
@@ -949,7 +940,9 @@ FMAP_FMAP_SIZE := 0x200
# position and size of CBFS, relative to BIOS_BASE
FMAP_CBFS_BASE := $(call int-add, $(FMAP_FMAP_BASE) $(FMAP_FMAP_SIZE))
FMAP_CBFS_SIZE := $(call int-subtract, $(FMAP_BIOS_SIZE) $(FMAP_CBFS_BASE))
else # ifeq ($(CONFIG_ARCH_X86),y)
DEFAULT_FLASHMAP:=$(top)/util/cbfstool/default.fmd
# entire flash
FMAP_ROM_ADDR := 0
@@ -960,49 +953,43 @@ FMAP_BIOS_BASE := 0
FMAP_BIOS_SIZE := $(CONFIG_CBFS_SIZE)
# position and size of flashmap, relative to BIOS_BASE
FMAP_FMAP_BASE := 0x20000
FMAP_FMAP_SIZE := 0x100
FMAP_FMAP_SIZE := 0x200
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_FMAP_BASE) $(FMAP_FMAP_SIZE))
#
# NON-X86 CONSOLE FMAP region
#
# position, size and entry line of CONSOLE relative to BIOS_BASE, if enabled
ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
FMAP_CONSOLE_BASE := $(call int-add, $(FMAP_FMAP_BASE) $(FMAP_FMAP_SIZE))
FMAP_CONSOLE_BASE := $(FMAP_CURRENT_BASE)
FMAP_CONSOLE_SIZE := $(CONFIG_CONSOLE_SPI_FLASH_BUFFER_SIZE)
FMAP_CONSOLE_ENTRY := CONSOLE@$(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE)
else # ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
FMAP_CONSOLE_BASE := 0
FMAP_CONSOLE_SIZE := 0
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE))
else
FMAP_CONSOLE_ENTRY :=
endif # ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
endif
#
# NON-X86 RW_MRC_CACHE FMAP region
#
# position, size and entry line of MRC_CACHE relative to BIOS_BASE, if enabled
ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
ifeq ($(CONFIG_CONSOLE_SPI_FLASH),y)
FMAP_MRC_CACHE_BASE := $(call int-align, $(call int-add, $(FMAP_CONSOLE_BASE) \
$(FMAP_CONSOLE_SIZE)), 0x10000)
else
FMAP_MRC_CACHE_BASE := $(call int-align, $(call int-add, $(FMAP_FMAP_BASE) \
$(FMAP_FMAP_SIZE)), 0x10000)
endif
FMAP_MRC_CACHE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
FMAP_MRC_CACHE_SIZE := $(CONFIG_MRC_SETTINGS_CACHE_SIZE)
FMAP_MRC_CACHE_ENTRY := RW_MRC_CACHE@$(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE)
else # ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
FMAP_MRC_CACHE_BASE := 0
FMAP_MRC_CACHE_SIZE := 0
FMAP_CURRENT_BASE := $(call int-add, $(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE))
else
FMAP_MRC_CACHE_ENTRY :=
endif # ifeq ($(CONFIG_CACHE_MRC_SETTINGS),y)
endif
#
# NON-X86 COREBOOT default cbfs FMAP region
#
# position and size of CBFS, relative to BIOS_BASE
FMAP_CBFS_BASE := $(call int-add,$(FMAP_FMAP_BASE) $(FMAP_FMAP_SIZE) $(FMAP_CONSOLE_SIZE) \
$(FMAP_MRC_CACHE_SIZE))
FMAP_CBFS_BASE := $(FMAP_CURRENT_BASE)
FMAP_CBFS_SIZE := $(call int-subtract,$(FMAP_BIOS_SIZE) $(FMAP_CBFS_BASE))
endif # ifeq ($(CONFIG_ARCH_X86),y)
$(obj)/fmap.fmd: $(top)/Makefile.inc $(DEFAULT_FLASHMAP) $(obj)/config.h
@@ -1110,7 +1097,12 @@ ifeq ($(CONFIG_SEABIOS_ADD_SERCON_PORT_FILE),y)
@printf " SeaBIOS Add sercon-port file\n"
$(CBFSTOOL) $@.tmp add-int -i $(CONFIG_SEABIOS_SERCON_PORT_ADDR) -n etc/sercon-port
endif
ifeq ($(CONFIG_SEABIOS_THREAD_OPTIONROMS),y)
@printf " SeaBIOS Thread optionroms\n"
$(CBFSTOOL) $@.tmp add-int -i 2 -n etc/threads
endif
ifeq ($(CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE),y)
ifneq ($(CONFIG_UPDATE_IMAGE),y) # never update the bootblock
ifeq ($(CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER),y)
@printf " UPDATE-FIT\n"
$(IFITTOOL) -f $@.tmp -a -n cpu_microcode_blob.bin -t 1 -s $(CONFIG_CPU_INTEL_NUM_FIT_ENTRIES) \
@@ -1145,7 +1137,8 @@ endif
endif
endif
endif # !CONFIG_UPDATE_IMAGE
endif # CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE
mv $@.tmp $@
@printf " CBFSLAYOUT $(subst $(obj)/,,$(@))\n\n"
$(CBFSTOOL) $@ layout

17
configs/builder/config.intel.cpx.crb Normal file
View File

@@ -0,0 +1,17 @@
# type this to get working .config:
# make defconfig KBUILD_DEFCONFIG=configs/builder/config.intel.cpx.crb
CONFIG_VENDOR_INTEL=y
CONFIG_BOARD_INTEL_CEDARISLAND_CRB=y
CONFIG_HAVE_IFD_BIN=y
CONFIG_HAVE_ME_BIN=y
CONFIG_DO_NOT_TOUCH_DESCRIPTOR_REGION=y
CONFIG_USE_CPU_MICROCODE_CBFS_BINS=y
CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
CONFIG_CPU_UCODE_BINARIES="site-local/cedarisland_crb/ucode-05-06-5a"
CONFIG_ADD_FSP_BINARIES=y
CONFIG_FSP_T_FILE="site-local/cedarisland_crb/Server_T.fd"
CONFIG_FSP_M_FILE="site-local/cedarisland_crb/Server_M.fd"
CONFIG_FSP_S_FILE="site-local/cedarisland_crb/Server_S.fd"
CONFIG_ME_BIN_PATH="site-local/cedarisland_crb/me.bin"
CONFIG_IFD_BIN_PATH="site-local/cedarisland_crb/descriptor.bin"

17
configs/builder/config.ocp.tiogapass Normal file
View File

@@ -0,0 +1,17 @@
# type this to get working .config:
# make defconfig KBUILD_DEFCONFIG=configs/builder/config.ocp.tiogapass
CONFIG_VENDOR_OCP=y
CONFIG_HAVE_IFD_BIN=y
CONFIG_HAVE_ME_BIN=y
CONFIG_DO_NOT_TOUCH_DESCRIPTOR_REGION=y
CONFIG_USE_CPU_MICROCODE_CBFS_BINS=y
CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
CONFIG_CPU_UCODE_BINARIES="3rdparty/intel-microcode/intel-ucode/06-55-04"
CONFIG_ADD_FSP_BINARIES=y
CONFIG_FSP_T_FILE="site-local/tiogapass/Server_T.fd"
CONFIG_FSP_M_FILE="site-local/tiogapass/Server_M.fd"
CONFIG_FSP_S_FILE="site-local/tiogapass/Server_S.fd"
CONFIG_ME_BIN_PATH="site-local/tiogapass/me.bin"
CONFIG_IFD_BIN_PATH="site-local/tiogapass/descriptor.bin"
CONFIG_USE_BLOBS=y

7
configs/config.emulation_qemu_aarch64_fit_support_timestamps Normal file
View File

@@ -0,0 +1,7 @@
CONFIG_COLLECT_TIMESTAMPS=y
CONFIG_TIMESTAMPS_ON_CONSOLE=y
CONFIG_MAINBOARD_VENDOR="Emulation"
CONFIG_CBFS_SIZE=0x1000000
CONFIG_BOARD_EMULATION_QEMU_AARCH64=y
CONFIG_COREBOOT_ROMSIZE_KB_16384=y
CONFIG_PAYLOAD_FIT_SUPPORT=y

0
configs/config.facebook_fbg1701 → configs/config.facebook_fbg1701.mboot_vboot
View File

1
configs/config.google_meep_cros
View File

@@ -14,7 +14,6 @@ CONFIG_MRC_CLEAR_NORMAL_CACHE_ON_RECOVERY_RETRAIN=y
# Event Logging
CONFIG_CMOS_POST=y
CONFIG_CMOS_POST_EXTRA=y
CONFIG_CMOS_POST_OFFSET=0x70
CONFIG_COLLECT_TIMESTAMPS=y
CONFIG_ELOG=y

4
configs/config.google_octopus_spi_flash_console Normal file
View File

@@ -0,0 +1,4 @@
CONFIG_VENDOR_GOOGLE=y
CONFIG_BOARD_GOOGLE_OCTOPUS=y
CONFIG_CONSOLE_SPI_FLASH=y
# CONFIG_VBOOT_MEASURED_BOOT is not set

1
configs/config.google_reef_cros
View File

@@ -10,5 +10,4 @@ CONFIG_SPI_FLASH_SMM=y
# CONFIG_CONSOLE_SERIAL is not set
CONFIG_CMOS_POST=y
CONFIG_CMOS_POST_OFFSET=0x70
CONFIG_CMOS_POST_EXTRA=y
CONFIG_PAYLOAD_NONE=y

2
configs/config.intel.cfl_rvp11_fsp_car → configs/config.intel_coffeelake_rvp11.fsp_car
View File

@@ -2,8 +2,6 @@ CONFIG_USE_BLOBS=y
CONFIG_VENDOR_INTEL=y
CONFIG_INTEL_GMA_VBT_FILE="3rdparty/fsp/CoffeeLakeFspBinPkg/SampleCode/Vbt/Vbt.bin"
CONFIG_BOARD_INTEL_COFFEELAKE_RVP11=y
CONFIG_ADD_FSP_BINARIES=y
CONFIG_USE_CANNONLAKE_FSP_CAR=y
CONFIG_RUN_FSP_GOP=y
CONFIG_FSP_USE_REPO=y
CONFIG_PAYLOAD_NONE=y

5
configs/config.libretrend_lt1000 Normal file
View File

@@ -0,0 +1,5 @@
CONFIG_VENDOR_LIBRETREND=y
CONFIG_POWER_STATE_OFF_AFTER_FAILURE=y
CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y
CONFIG_USER_TPM2=y
CONFIG_SEABIOS_ADD_SERCON_PORT_FILE=y

5
configs/config.ocp_tiogapass Normal file
View File

@@ -0,0 +1,5 @@
CONFIG_VENDOR_OCP=y
CONFIG_BOARD_OCP_TIOGAPASS=y
CONFIG_USE_CPU_MICROCODE_CBFS_BINS=y
CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_BINS=y
CONFIG_CPU_UCODE_BINARIES="3rdparty/intel-microcode/intel-ucode/06-55-04"

11
payloads/Kconfig
View File

@@ -57,10 +57,16 @@ config PAYLOAD_FILE
choice
prompt "Payload compression algorithm"
default COMPRESSED_PAYLOAD_LZMA
default COMPRESSED_PAYLOAD_NONE if PAYLOAD_LINUX || PAYLOAD_LINUXBOOT || PAYLOAD_FIT
depends on !PAYLOAD_NONE && !PAYLOAD_LINUX && !PAYLOAD_LINUXBOOT && !PAYLOAD_FIT
help
Choose the compression algorithm for the chosen payloads.
You can choose between LZMA and LZ4.
You can choose between None, LZMA, or LZ4.
config COMPRESSED_PAYLOAD_NONE
bool "Use no compression for payloads"
help
Do not compress the payload.
config COMPRESSED_PAYLOAD_LZMA
bool "Use LZMA compression for payloads"
@@ -126,7 +132,8 @@ config MEMTEST_SECONDARY_PAYLOAD
config NVRAMCUI_SECONDARY_PAYLOAD
bool "Load nvramcui as a secondary payload"
default n
depends on ARCH_X86
depends on ARCH_X86 && HAVE_OPTION_TABLE
select USE_OPTION_TABLE
help
nvramcui can be loaded as a secondary payload under SeaBIOS, GRUB,
or any other payload that can load additional payloads.

2
payloads/coreinfo/cpuinfo_module.c
View File

@@ -233,7 +233,7 @@ static int cpuinfo_module_redraw(WINDOW *win)
}
if (cpu_khz != 0)
mvwprintw(win, row++, 1, "CPU Speed: %d Mhz", cpu_khz / 1000);
mvwprintw(win, row++, 1, "CPU Speed: %d MHz", cpu_khz / 1000);
else
mvwprintw(win, row++, 1, "CPU Speed: Error");

7
payloads/external/GRUB2/Makefile vendored
View File

@@ -17,12 +17,13 @@ checkout:
echo " GIT GRUB2 $(NAME-y)"
test -d $(project_dir) || git clone $(project_git_repo) $(project_dir)
git -C $(project_dir) fetch
ifeq ("$(shell test -d $(project_dir) && \
(git -C $(project_dir) status --ignored=no --untracked-files=no --porcelain))",)
ifeq ($(shell test -d $(project_dir) && \
(git -C $(project_dir) status --ignored=no --untracked-files=no --porcelain)),)
git -C $(project_dir) checkout -f $(TAG-y)
else
echo "WARNING: index/tree not clean, skipping update / force checkout."
echo " Checkout manually with `git -C $(project_dir) checkout -f`."
echo " Checkout manually with "\
"\`git -C payloads/external/GRUB2/$(project_dir) checkout -f\`."
endif
grub2/build/config.h: $(CONFIG_DEP) | checkout

8
payloads/external/Makefile.inc vendored
View File

@@ -78,7 +78,7 @@ etc/grub.cfg-required := the GRUB runtime configuration file ($(CONFIG_GRUB2_RUN
# SeaBIOS
SEABIOS_CC_OFFSET=$(if $(filter %ccache,$(HOSTCC)),2,1)
payloads/external/SeaBIOS/seabios/out/bios.bin.elf seabios: $(DOTCONFIG)
payloads/external/SeaBIOS/seabios/out/bios.bin.elf: $(DOTCONFIG)
$(MAKE) -C payloads/external/SeaBIOS \
HOSTCC="$(HOSTCC)" \
CC=$(word $(SEABIOS_CC_OFFSET),$(CC_x86_32)) \
@@ -102,9 +102,10 @@ payloads/external/SeaBIOS/seabios/out/bios.bin.elf seabios: $(DOTCONFIG)
CONFIG_SEABIOS_DEBUG_LEVEL=$(CONFIG_SEABIOS_DEBUG_LEVEL) \
CONFIG_DRIVERS_UART_8250MEM_32=$(CONFIG_DRIVERS_UART_8250MEM_32) \
CONFIG_ENABLE_HSUART=$(CONFIG_ENABLE_HSUART) \
CONFIG_CONSOLE_UART_BASE_ADDRESS=$(CONFIG_CONSOLE_UART_BASE_ADDRESS)
CONFIG_CONSOLE_UART_BASE_ADDRESS=$(CONFIG_CONSOLE_UART_BASE_ADDRESS) \
CONFIG_SEABIOS_HARDWARE_IRQ=$(CONFIG_SEABIOS_HARDWARE_IRQ)
payloads/external/SeaBIOS/seabios/out/vgabios.bin: seabios
payloads/external/SeaBIOS/seabios/out/vgabios.bin: payloads/external/SeaBIOS/seabios/out/bios.bin.elf
payloads/external/SeaBIOS/seabios/.config: payloads/external/SeaBIOS/seabios/out/bios.bin.elf
payloads/external/SeaBIOS/seabios/out/autoversion.h: payloads/external/SeaBIOS/seabios/out/bios.bin.elf
@@ -263,6 +264,7 @@ payloads/external/iPXE/ipxe/ipxe.rom ipxe: $(DOTCONFIG) $(PXE_CONFIG_SCRIPT)
CONFIG_SCRIPT=$(PXE_CONFIG_SCRIPT) \
CONFIG_HAS_SCRIPT=$(CONFIG_PXE_ADD_SCRIPT) \
CONFIG_PXE_NO_PROMT=$(CONFIG_PXE_NO_PROMT) \
CONFIG_PXE_HAS_HTTPS=$(CONFIG_PXE_HAS_HTTPS) \
MFLAGS= MAKEFLAGS=
# LinuxBoot

12
payloads/external/SeaBIOS/Kconfig vendored
View File

@@ -51,6 +51,16 @@ config SEABIOS_THREAD_OPTIONROMS
variations during option ROM code execution. It is not
known if all option ROMs will behave properly with this option.
config SEABIOS_HARDWARE_IRQ
prompt "Hardware Interrupts"
default y
bool
help
Program and support hardware interrupts using the i8259
programmable interrupt controller (PIC). Deselected by
boards which would otherwise hang at the boot menu (eg,
google/rambi).
config SEABIOS_VGA_COREBOOT
prompt "Include generated option rom that implements legacy VGA BIOS compatibility"
default y if !VENDOR_EMULATION
@@ -125,7 +135,7 @@ config SEABIOS_DEBUG_LEVEL
level 1 - Basic output, interrupts 5, 18h, 19h, 40h, SMP, PNP, PMM
level 2 - AHCI, Floppy, Basic ps2, interrupts 11h, 12h, 14h, 17h
level 3 - bootsplash, initializations, SeaBIOS VGA BIOS interrupts
level 4 - bios tables, more optionrom
level 4 - BIOS tables, more optionrom
level 5 - Extra bootsplash, more XHCI
level 6 - ATA commands, extra optionrom
level 7 - extra ps2 commands, more OHCI & EHCI

3
payloads/external/SeaBIOS/Makefile vendored
View File

@@ -72,6 +72,9 @@ endif
ifneq ($(CONFIG_SEABIOS_DEBUG_LEVEL),-1)
echo "CONFIG_DEBUG_LEVEL=$(CONFIG_SEABIOS_DEBUG_LEVEL)" >> seabios/.config
endif
ifneq ($(CONFIG_SEABIOS_HARDWARE_IRQ),y)
echo "# CONFIG_HARDWARE_IRQ is not set" >> seabios/.config
endif
# This shows how to force a previously set .config option *off*
# echo "# CONFIG_SMBIOS is not set" >> seabios/.config
$(MAKE) -C seabios olddefconfig OUT=out/

5
payloads/external/depthcharge/Makefile vendored
View File

@@ -10,6 +10,7 @@ libpayload_dir=$(abspath $(CURDIR)/../../libpayload)
libpayload_install_dir=$(output_dir)/lp_$(BOARD)
VBOOT_SOURCE ?= $(abspath $(CURDIR)/../../../3rdparty/vboot)
EC_HEADERS ?= $(abspath $(CURDIR)/../../../3rdparty/chromeec/include)
TAG-$(DEPTHCHARGE_MASTER)=origin/master
TAG-$(DEPTHCHARGE_STABLE)=$(STABLE_COMMIT_ID)
@@ -79,13 +80,15 @@ config: $(project_dir)/.version_$(TAG-y) $(libpayload_install_dir)
cd $(project_dir) && \
$(MAKE) BOARD=$(BOARD) \
LIBPAYLOAD_DIR=$(libpayload_install_dir)/libpayload \
VB_SOURCE=$(VBOOT_SOURCE) defconfig
VB_SOURCE=$(VBOOT_SOURCE) \
EC_HEADERS=$(EC_HEADERS) defconfig
build: config
echo " MAKE $(project_name) $(TAG-y)"
$(MAKE) -C $(project_dir) depthcharge BOARD=$(BOARD) \
LIBPAYLOAD_DIR=$(libpayload_install_dir)/libpayload \
VB_SOURCE=$(VBOOT_SOURCE) \
EC_HEADERS=$(EC_HEADERS) \
PATH="$(abspath ../../../build/util/cbfstool):$$PATH"
clean:

8
payloads/external/iPXE/Kconfig vendored
View File

@@ -113,5 +113,13 @@ config PXE_SCRIPT
Uses the ipxe script instead showing the prompt:
"Press Ctrl-B to start iPXE..."
config PXE_HAS_HTTPS
bool "Enable HTTPS protocol"
default y
depends on BUILD_IPXE
help
Enable HTTPS protocol, which allows you to encrypt all communication
with a web server and to verify the server's identity
endmenu
endif

4
payloads/external/iPXE/Makefile vendored
View File

@@ -65,6 +65,10 @@ ifeq ($(CONFIG_PXE_NO_PROMT),y)
sed 's|#define\s*BANNER_TIMEOUT.*|#define BANNER_TIMEOUT 0|' "$(project_dir)/src/config/general.h" > "$(project_dir)/src/config/general.h.tmp"
mv "$(project_dir)/src/config/general.h.tmp" "$(project_dir)/src/config/general.h"
endif
ifeq ($(CONFIG_PXE_HAS_HTTPS),y)
sed 's|.*DOWNLOAD_PROTO_HTTPS|#define DOWNLOAD_PROTO_HTTPS|g' "$(project_dir)/src/config/general.h" > "$(project_dir)/src/config/general.h.tmp"
mv "$(project_dir)/src/config/general.h.tmp" "$(project_dir)/src/config/general.h"
endif
build: config $(CONFIG_SCRIPT)
ifeq ($(CONFIG_HAS_SCRIPT),y)

2
payloads/external/tianocore/Kconfig vendored
View File

@@ -83,7 +83,6 @@ config TIANOCORE_USE_8254_TIMER
config TIANOCORE_BOOTSPLASH_IMAGE
bool "Use a custom bootsplash image"
depends on TIANOCORE_COREBOOTPAYLOAD
help
Select this option if you have a bootsplash image that you would
like to be used. If this option is not selected, the default
@@ -92,7 +91,6 @@ config TIANOCORE_BOOTSPLASH_IMAGE
config TIANOCORE_BOOTSPLASH_FILE
string "Tianocore Bootsplash path and filename"
depends on TIANOCORE_BOOTSPLASH_IMAGE
depends on TIANOCORE_COREBOOTPAYLOAD
default "bootsplash.bmp"
help
The path and filename of the file to use as graphical bootsplash

21
payloads/external/tianocore/Makefile vendored
View File

@@ -24,10 +24,12 @@ upstream_git_repo=https://github.com/tianocore/edk2
ifeq ($(CONFIG_TIANOCORE_UEFIPAYLOAD),y)
bootloader=UefiPayloadPkg
build_flavor=-D BOOTLOADER=COREBOOT -D PCIE_BASE=$(CONFIG_MMCONF_BASE_ADDRESS)
logo_pkg=MdeModulePkg
build_flavor=-D BOOTLOADER=COREBOOT -D PCIE_BASE=$(CONFIG_MMCONF_BASE_ADDRESS) -DPS2_KEYBOARD_ENABLE
TAG=upstream/master
else
bootloader=CorebootPayloadPkg
logo_pkg=CorebootPayloadPkg
# STABLE revision is MrChromebox's coreboot framebuffer (coreboot_fb) branch
TAG=origin/$(project_git_branch)
endif
@@ -49,9 +51,9 @@ TIMER=-DUSE_HPET_TIMER
endif
ifeq ($(CONFIG_TIANOCORE_TARGET_IA32), y)
BUILD_STR=-a IA32 -t COREBOOT -p $(bootloader)/$(bootloader)Ia32.dsc -b $(BUILD_TYPE) $(TIMER) $(build_flavor)
BUILD_STR=-q -a IA32 -t COREBOOT -p $(bootloader)/$(bootloader)Ia32.dsc -b $(BUILD_TYPE) $(TIMER) $(build_flavor)
else
BUILD_STR=-a IA32 -a X64 -t COREBOOT -p $(bootloader)/$(bootloader)Ia32X64.dsc -b $(BUILD_TYPE) $(TIMER) $(build_flavor)
BUILD_STR=-q -a IA32 -a X64 -t COREBOOT -p $(bootloader)/$(bootloader)Ia32X64.dsc -b $(BUILD_TYPE) $(TIMER) $(build_flavor)
endif
all: clean build
@@ -70,12 +72,13 @@ update: $(project_dir)
echo " $(TAG) is not a valid git reference"; \
exit 1; \
fi; \
if git describe --all --dirty | grep -qv dirty; then \
if git status --ignore-submodules=dirty | grep -qv clean; then \
echo " Checking out $(project_name) revision $(TAG)"; \
git checkout --detach $(TAG); \
else \
echo " Working directory not clean; will not overwrite"; \
fi
fi; \
git submodule update --init --recursive
checktools:
echo "Checking uuid-dev..."
@@ -91,13 +94,13 @@ checktools:
build: update checktools
unset CC; $(MAKE) -C $(project_dir)/BaseTools
echo " build $(project_name) $(TAG)"
if [ -n $(CONFIG_TIANOCORE_BOOTSPLASH_FILE) ]; then \
if [ -n "$(CONFIG_TIANOCORE_BOOTSPLASH_FILE)" ]; then \
echo " Copying custom bootsplash image"; \
case "$(CONFIG_TIANOCORE_BOOTSPLASH_FILE)" in \
/*) cp $(CONFIG_TIANOCORE_BOOTSPLASH_FILE) \
$(project_dir)/CorebootPayloadPkg/Logo/Logo.bmp;; \
$(project_dir)/$(logo_pkg)/Logo/Logo.bmp;; \
*) cp $(top)/$(CONFIG_TIANOCORE_BOOTSPLASH_FILE) \
$(project_dir)/CorebootPayloadPkg/Logo/Logo.bmp;; \
$(project_dir)/$(logo_pkg)/Logo/Logo.bmp;; \
esac \
fi; \
cd $(project_dir); \
@@ -110,7 +113,7 @@ build: update checktools
fi; \
build $(BUILD_STR); \
mv $(project_dir)/Build/$(bootloader)*/*/FV/UEFIPAYLOAD.fd $(project_dir)/Build/UEFIPAYLOAD.fd; \
git checkout CorebootPayloadPkg/Logo/Logo.bmp > /dev/null 2>&1 || true
git checkout $(logo_pkg)/Logo/Logo.bmp > /dev/null 2>&1 || true
clean:
test -d $(project_dir) && (cd $(project_dir); rm -rf Build; rm -f Conf/tools_def.txt) || exit 0

12
payloads/libpayload/Kconfig
View File

@@ -257,6 +257,11 @@ config QCS405_SERIAL_CONSOLE
depends on SERIAL_CONSOLE
default n
config QUALCOMM_QUPV3_SERIAL_CONSOLE
bool "Qualcomm QUPV3 serial port driver"
depends on SERIAL_CONSOLE
default n
config PL011_SERIAL_CONSOLE
bool "PL011 compatible serial port driver"
depends on 8250_SERIAL_CONSOLE
@@ -315,6 +320,13 @@ config COREBOOT_VIDEO_CONSOLE
Say Y here if coreboot switched to a graphics mode and
your payload wants to use it.
config COREBOOT_VIDEO_CENTERED
bool "Center a classic 80x25 console on bigger screens"
depends on COREBOOT_VIDEO_CONSOLE
help
Say 'y' here if your payload is hardcoded to a 80x25 console. Otherwise
its output would look squeezed into the upper-left corner of the screen.
config FONT_SCALE_FACTOR
int "Scale factor for the included font"
depends on GEODELX_VIDEO_CONSOLE || COREBOOT_VIDEO_CONSOLE

15
payloads/libpayload/arch/arm64/cpu.S
View File

@@ -29,6 +29,7 @@
*/
#include <arch/asm.h>
#include <arch/lib_helpers.h>
.macro dcache_apply_all crm
dsb sy
@@ -96,3 +97,17 @@ ENDPROC(dcache_clean_all)
ENTRY(dcache_clean_invalidate_all)
dcache_apply_all crm=cisw
ENDPROC(dcache_clean_invalidate_all)
/* This must be implemented in assembly to ensure there are no accesses to
memory (e.g. the stack) in between disabling and flushing the cache. */
ENTRY(mmu_disable)
str x30, [sp, #-0x8]
mrs x0, sctlr_el2
mov x1, #~(SCTLR_C | SCTLR_M)
and x0, x0, x1
msr sctlr_el2, x0
isb
bl dcache_clean_invalidate_all
ldr x30, [sp, #-0x8]
ret
ENDPROC(mmu_disable)

4
payloads/libpayload/arch/arm64/head.S
View File

@@ -28,11 +28,15 @@
*/
#include <arch/asm.h>
#include <arch/lib_helpers.h>
/*
* Our entry point
*/
ENTRY(_entry)
/* Initialize SCTLR to intended state (icache and stack-alignment on) */
ldr w1, =(SCTLR_RES1 | SCTLR_I | SCTLR_SA)
msr sctlr_el2, x1
/* Save off the location of the coreboot tables */
ldr x1, 1f

24
payloads/libpayload/arch/arm64/mmu.c
View File

@@ -303,30 +303,6 @@ static uint32_t is_mmu_enabled(void)
return (sctlr & SCTLR_M);
}
/*
* Func: mmu_disable
* Desc: Invalidate caches and disable mmu
*/
void mmu_disable(void)
{
uint32_t sctlr;
sctlr = raw_read_sctlr_el2();
sctlr &= ~(SCTLR_C | SCTLR_M | SCTLR_I);
tlbiall_el2();
dcache_clean_invalidate_all();
dsb();
isb();
raw_write_sctlr_el2(sctlr);
dcache_clean_invalidate_all();
dsb();
isb();
}
/*
* Func: mmu_enable
* Desc: Initialize MAIR, TCR, TTBR and enable MMU by setting appropriate bits

8
payloads/libpayload/configs/config.bubs Normal file
View File

@@ -0,0 +1,8 @@
CONFIG_LP_CHROMEOS=y
CONFIG_LP_ARCH_ARM64=y
CONFIG_LP_TIMER_ARM64_ARCH=y
CONFIG_LP_SERIAL_CONSOLE=y
CONFIG_LP_QUALCOMM_QUPV3_SERIAL_CONSOLE=y
CONFIG_LP_USB=y
CONFIG_LP_USB_EHCI=y
CONFIG_LP_USB_XHCI=y

2
payloads/libpayload/configs/config.trogdor
View File

@@ -4,3 +4,5 @@ CONFIG_LP_TIMER_ARM64_ARCH=y
CONFIG_LP_USB=y
CONFIG_LP_USB_EHCI=y
CONFIG_LP_USB_XHCI=y
CONFIG_LP_SERIAL_CONSOLE=y
CONFIG_LP_QUALCOMM_QUPV3_SERIAL_CONSOLE=y

1
payloads/libpayload/drivers/Makefile.inc
View File

@@ -38,6 +38,7 @@ libc-$(CONFIG_LP_S5P_SERIAL_CONSOLE) += serial/s5p.c serial/serial.c
libc-$(CONFIG_LP_IPQ806X_SERIAL_CONSOLE) += serial/ipq806x.c serial/serial.c
libc-$(CONFIG_LP_IPQ40XX_SERIAL_CONSOLE) += serial/ipq40xx.c serial/serial.c
libc-$(CONFIG_LP_QCS405_SERIAL_CONSOLE) += serial/qcs405.c serial/serial.c
libc-$(CONFIG_LP_QUALCOMM_QUPV3_SERIAL_CONSOLE) += serial/qcom_qupv3_serial.c serial/serial.c
libc-$(CONFIG_LP_PC_KEYBOARD) += i8042/keyboard.c
libc-$(CONFIG_LP_PC_MOUSE) += i8042/mouse.c
libc-$(CONFIG_LP_PC_I8042) += i8042/i8042.c

Some files were not shown because too many files have changed in this diff Show More