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

.gitignore

@@ -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

AUTHORS

@@ -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
-
+Zachary Yedidia
-
-
-# Directories transferred
-src/acpi
-src/arch
-src/commonlib
-src/console
-src/cpu
-src/device
-src/drivers
-src/superio

Documentation/Intel/SoC/soc.html

@@ -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>

Documentation/acpi/devicetree.md

@@ -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``.

Documentation/acpi/gpio.md

@@ -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

Documentation/acpi/index.md

@@ -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)
 

Documentation/contributing/documentation_ideas.md

@@ -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
+

Documentation/contributing/project_ideas.md

@@ -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>

Documentation/drivers/smmstore.md

@@ -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

Documentation/flash_tutorial/int_flashrom.md

@@ -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.
 
 

Documentation/getting_started/gpio.md

@@ -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

Documentation/gfx/libgfxinit.md

@@ -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
+power sequencer). Therefore, each system with an integrated panel
-or LVDS as the internal port, if any:
+should set `GFX_GMA_PANEL_1_PORT` to the respective port, e.g.:
 
-    select GFX_GMA_INTERNAL_IS_EDP	# the default, or
+    config GFX_GMA_PANEL_1_PORT
-    select GFX_GMA_INTERNAL_IS_LVDS
+            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. It defines `ports` as follows:
-eDP and LVDS can be enabled. 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

Documentation/ifdtool/layout.md

@@ -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|
+```eval_rst
-|---|---|---|---|
++------------+------------------+-----------+-------------------------------------------+
-|0|Flash Descriptor|SI_DESC|Always the top 4KB of flash|
+| IFD Region | IFD Region name  | FMAP Name | Notes                                     |
-|1|BIOS|SI_BIOS|This is the region that contains coreboot|
+| index      |                  |           |                                           |
-|2|Intel ME|SI_ME||
++============+==================+===========+===========================================+
-|3|Gigabit Ethernet|SI_GBE||
+| 0          | Flash Descriptor | SI_DESC   | Always the top 4KB of flash               |
-|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|
+| 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
 

Documentation/index.md

@@ -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)

Documentation/mainboard/51nb/x210.md

@@ -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.
+

Documentation/mainboard/asrock/h110m-dvs.md

@@ -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
 ```

Documentation/mainboard/asus/p8z77-m_pro.md

@@ -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

Documentation/mainboard/hp/8760w.md

@@ -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

Documentation/mainboard/hp/hp_kbc1126_laptops.md

@@ -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.
+## EC firmware extraction and coreboot building
-They use similar EC firmware that will load other code and data from the
-SPI flash chip, so we need to put some firmware blobs to the coreboot image.
 
 The following document takes EliteBook 2760p as an example.
 
@@ -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
+To port coreboot to an HP laptop with KBC1126, you need to do the
-a serial port and a parallel port, you can debug the laptop via this
+following:
-serial port.
-
-## porting
-
-To port coreboot to an HP EliteBook laptop, you need to do the following:
 
 - select Kconfig option `EC_HP_KBC1126`
-- select Kconfig option `SUPERIO_SMSC_LPC47N217` if there is LPC47n217 Super I/O
+- 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 EliteBook xx60 series: 0x60, 0x64, 0xca
-- For xx70 series: 0x62, 0x66, 0x81
+- 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:

Documentation/mainboard/index.md

@@ -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)
+- [T420 / T520 / X220 / T420s / W520 common](lenovo/Sandy_Bridge_series.md)
-- [x1](lenovo/x1.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)

Documentation/mainboard/lenovo/Ivy_Bridge_series.md

@@ -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

Documentation/mainboard/lenovo/Sandy_Bridge_series.md

@@ -33,9 +33,7 @@
   usable by coreboot.
 * ROM chip size should be set to 8MiB.
 
-```eval_rst
+Please also have a look at the [flashing tutorial]
-Please also have a look at :doc:`../../flash_tutorial/index`.
-```
 
 ## 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

Documentation/mainboard/lenovo/codenames.csv

@@ -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

Documentation/mainboard/lenovo/flashlayout_Sandy_Bridge_stripped_me.svg

@@ -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>

Documentation/mainboard/lenovo/ivb_internal_flashing.md

@@ -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):

Documentation/mainboard/lenovo/montevina_series.md

@@ -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.

Documentation/mainboard/lenovo/t420.md

@@ -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
-
+the general [flashing tutorial].
-```eval_rst
-:doc:`../../flash_tutorial/ext_power`
-```
 
 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

Documentation/mainboard/lenovo/t430.md

@@ -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
+the general [flashing tutorial].
-:doc:`../../flash_tutorial/ext_power`
-```
 
 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

Documentation/mainboard/lenovo/t431s.md

@@ -26,9 +26,7 @@ the programmer.
 
 ![t431s_programming](t431s_programming.jpg)
 
-```eval_rst
+The general [flashing tutorial] has more details.
-:doc:`../../flash_tutorial/ext_power`
-```
 
 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

Documentation/mainboard/lenovo/t440p.md

@@ -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
-
+- The dGPU does not currently work in Windows.
-## Untested
-
-- the dGPU model
 
 ## 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

Documentation/mainboard/lenovo/vboot.md

@@ -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

Documentation/mainboard/lenovo/w530.md

@@ -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
+the general [flashing tutorial].
-:doc:`../../flash_tutorial/ext_power`
-```
 
 ### 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

Documentation/mainboard/lenovo/x1.md

@@ -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
-
+the general [flashing tutorial].
-```eval_rst
-:doc:`../../flash_tutorial/ext_power`
-```
 
 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

Documentation/mainboard/lenovo/x301.md

@@ -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)
+- MACRONIX_MX25L6405 (0xc2, 0x2017)
-    -WINBOND_NEX_W25X64 (0xef, 0x3017)
+- WINBOND_NEX_W25X64 (0xef, 0x3017)
-    -ATMEL_AT25DF641 (0x1f, 0x4800)
+- ATMEL_AT25DF641 (0x1f, 0x4800)
+
+The general [flashing tutorial] has more details.
 
-```eval_rst
-:doc:`../../flash_tutorial/ext_power`
-```
 Tested:
-    - CPU Core 2 Duo U9400
+- Core 2 Duo U9400 CPU
-    - Slotted DIMM 4GiB*2 from samsung
+- Slotted DIMM 4GiB*2 from Samsung
-    - Camera
+- Camera
-    - pci-e slots
+- PCI-e slots
-    - sata and usb2
+- SATA and USB2
-    - libgfxinit-based graphic init
+- libgfxinit-based graphics init
-    - NVRAM options for North and South bridges
+- NVRAM options for North and South bridges
-    - Sound
+- Sound
-    - Thinkpad EC
+- ThinkPad EC
-    - S3
+- S3
-    - Linux 4.19.67-2 within Debian GNU/Linux stable, loaded from
+- Linux 4.19.67-2 within Debian GNU/Linux stable, loaded from
-      Linux payload (Heads) and Seabios.
+  Linux payload (Heads) and SeaBIOS.
+
+
+[flashing tutorial]: ../../flash_tutorial/ext_power.md
+

Documentation/mainboard/libretrend/lt1000.md

@@ -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/

Documentation/mainboard/msi/ms7707/ms7707.md

@@ -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

Documentation/mainboard/protectli/fw2b_fw4b.md

@@ -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

Documentation/mainboard/protectli/fw6.md

@@ -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

Documentation/northbridge/intel/sandybridge/me_cleaner.md

@@ -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

Documentation/payloads.md

@@ -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/

Documentation/releases/checklist.md

@@ -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.

Documentation/releases/coreboot-4.11-relnotes.md

@@ -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

Documentation/releases/coreboot-4.12-relnotes.md

@@ -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
 -------------------
 

Documentation/releases/coreboot-4.5-relnotes.md

@@ -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)

Documentation/releases/coreboot-4.6-relnotes.md

@@ -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)

Documentation/releases/coreboot-4.8.1-relnotes.md

@@ -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
 -----------

Documentation/security/vboot/index.md

@@ -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

Documentation/security/vboot/list_vboot.md

@@ -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

Documentation/security/vboot/measured_boot.md

@@ -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

Documentation/soc/amd/psp_integration.md

@@ -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.
 
-    +--------------+---------------+------------------+----------------------------+
+```eval_rst
-    |  Field Name  |  Offset (Hex) |  Size (In Bytes) |    Description/Purpose     |
++--------------+---------------+------------------+----------------------------+
-    +--------------+---------------+------------------+----------------------------+
+|  Field Name  |  Offset (Hex) |  Size (In Bytes) |    Description/Purpose     |
-    |  Signature   | 0x00          | 4                | 0x55aa55aa                 |
++==============+===============+==================+============================+
-    |--------------|---------------|------------------|----------------------------|
+|  Signature   | 0x00          | 4                | 0x55aa55aa                 |
-    |  IMC FW      | 0x04          | 4                | Integrated Micro           |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | Controller: unsupported    |
+|  IMC FW      | 0x04          | 4                | Integrated Micro           |
-    |              |               |                  | but functional in some     |
+|              |               |                  | Controller: unsupported    |
-    |              |               |                  | systems                    |
+|              |               |                  | but functional in some     |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | systems                    |
-    | GbE FW       | 0x08          | 4                | Gigabit Ethernet           |
++--------------+---------------+------------------+----------------------------+
-    |--------------|---------------|------------------|----------------------------|
+| GbE FW       | 0x08          | 4                | Gigabit Ethernet           |
-    | xHCI FW      | 0x0c          | 4                | xHCI firmware              |
++--------------+---------------+------------------+----------------------------+
-    |--------------|---------------|------------------|----------------------------|
+| xHCI FW      | 0x0c          | 4                | xHCI firmware              |
-    | PSP Dir Tbl  | 0x10          | 4                | Pointer to PSP Directory   |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | Table (early devices)      |
+| 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   |
+| PSP Dir Tbl  | 0x14          | 4                | Pointer to PSP Directory   |
-    |              |               |                  | is combo capable)          |
+|              |               |                  | Table (later devices and   |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | is combo capable)          |
-    | BIOS Dir Tbl | 0x18          | 4                | Pointer to BIOS Directory  |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | Table for models n*        |
+| 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 | 0x1c          | 4                | Pointer to BIOS Directory  |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | Table for models nn        |
-    | BIOS Dir Tbl | 0x20          | 4                | Pointer to BIOS Directory  |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | Table for models nnn       |
+| 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
-
+```eval_rst
-    +--------------+---------------+------------------+----------------------------+
++--------------+---------------+------------------+----------------------------+
-    |  Field Name  |  Offset (Hex) |  Size (In Bytes) |    Description/Purpose     |
+|  Field Name  |  Offset (Hex) |  Size (In Bytes) |    Description/Purpose     |
-    +--------------+---------------+------------------+----------------------------+
++==============+===============+==================+============================+
-    | PSP Cookie   | 0x00          | 4                | PSP cookie "$PSP" to       |
+| PSP Cookie   | 0x00          | 4                | PSP cookie "$PSP" to       |
-    |              |               |                  | recognize the header.      |
+|              |               |                  | recognize the header.      |
-    |              |               |                  | Cookie “$PL2” for level 2  |
+|              |               |                  | Cookie “$PL2” for level 2  |
-    |--------------|---------------|------------------|----------------------------|
++--------------+---------------+------------------+----------------------------+
-    | Checksum     | 0x04          | 4                | 32-bit CRC value of header |
+| Checksum     | 0x04          | 4                | 32-bit CRC value of header |
-    |              |               |                  | below this field and       |
+|              |               |                  | below this field and       |
-    |              |               |                  | including all entries      |
+|              |               |                  | including all entries      |
-    |--------------|---------------|------------------|----------------------------|
++--------------+---------------+------------------+----------------------------+
-    | Total Entries| 0x08          | 4                | Number of PSP Directory    |
+| Total Entries| 0x08          | 4                | Number of PSP Directory    |
-    |              |               |                  | entries in the table       |
+|              |               |                  | entries in the table       |
-    |--------------|---------------|------------------|----------------------------|
++--------------+---------------+------------------+----------------------------+
-    | Reserved     | 0x0C          | 4                | Reserved - Set to zero     |
+| Reserved     | 0x0C          | 4                | Reserved - Set to zero     |
-    +--------------+---------------+------------------+----------------------------+
++--------------+---------------+------------------+----------------------------+
+```
 
 ### PSP Directory Table Entries
-
+```eval_rst
-    +--------------+---------------+------------------+----------------------------+
++--------------+---------------+------------------+----------------------------+
-    |  Field Name  |  Offset (Hex) |  Size (In Bits)  |    Description/Purpose     |
+|  Field Name  |  Offset (Hex) |  Size (In Bits)  |    Description/Purpose     |
-    +--------------+---------------+------------------+----------------------------+
++==============+===============+==================+============================+
-    | Type         | 0x00          | 8                | Entry type (see below)     |
+| Type         | 0x00          | 8                | Entry type (see below)     |
-    |--------------|---------------|------------------|----------------------------|
++--------------+---------------+------------------+----------------------------+
-    | Sub Program  | 0x01          | 8                | Specifies sub program      |
+| Sub Program  | 0x01          | 8                | Specifies sub program      |
-    |--------------|---------------|------------------|----------------------------|
++--------------+---------------+------------------+----------------------------+
-    | Reserved     | 0x02          | 16               | Reserved - set to 0        |
+| Reserved     | 0x02          | 16               | Reserved - set to 0        |
-    |--------------|---------------|------------------|----------------------------|
++--------------+---------------+------------------+----------------------------+
-    | Size         | 0x04          | 32               | Size of PSP entry in bytes |
+| Size         | 0x04          | 32               | Size of PSP entry in bytes |
-    |--------------|---------------|------------------|----------------------------|
++--------------+---------------+------------------+----------------------------+
-    | Location /   | 0x08          | 64               | Location: Physical Address |
+| Location /   | 0x08          | 64               | Location: Physical Address |
-    | Value        |               |                  | of SPIROM location where   |
+| Value        |               |                  | of SPIROM location where   |
-    |              |               |                  | corresponding PSP entry    |
+|              |               |                  | corresponding PSP entry    |
-    |              |               |                  | located.                   |
+|              |               |                  | located.                   |
-    |              |               |                  |                            |
+|              |               |                  |                            |
-    |              |               |                  | Value: 64-bit value for the|
+|              |               |                  | Value: 64-bit value for the|
-    |              |               |                  | PSP Entry                  |
+|              |               |                  | 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
 
-    +--------------+---------------+------------------+----------------------------+
+```eval_rst
-    |  Field Name  |  Offset (Hex) |  Size (In Bytes) |    Description/Purpose     |
++--------------+---------------+------------------+----------------------------+
-    +--------------+---------------+------------------+----------------------------+
+|  Field Name  |  Offset (Hex) |  Size (In Bytes) |    Description/Purpose     |
-    | BIOS Cookie  | 0x00          | 4                | BIOS cookie "$BHD" to      |
++==============+===============+==================+============================+
-    |              |               |                  | recognize the header.      |
+| BIOS Cookie  | 0x00          | 4                | BIOS cookie "$BHD" to      |
-    |              |               |                  | Cookie “$BL2” for level 2  |
+|              |               |                  | recognize the header.      |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | Cookie “$BL2” for level 2  |
-    | Checksum     | 0x04          | 4                | 32 bit CRC value of header |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | below this field and       |
+| Checksum     | 0x04          | 4                | 32 bit CRC value of header |
-    |              |               |                  | including all entries      |
+|              |               |                  | below this field and       |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | including all entries      |
-    | Total Entries| 0x08          | 4                | Number of BIOS Directory   |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | entries in the table       |
+| Total Entries| 0x08          | 4                | Number of BIOS Directory   |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | entries in the table       |
-    | Reserved     | 0x0C          | 4                | Reserved - Set to zero     |
++--------------+---------------+------------------+----------------------------+
-    +--------------+---------------+------------------+----------------------------+
+| Reserved     | 0x0C          | 4                | Reserved - Set to zero     |
++--------------+---------------+------------------+----------------------------+
+```
 
 ### BIOS Directory Table Entries
 
-    +--------------+---------------+------------------+----------------------------+
+```eval_rst
-    |  Field Name  |  Offset (Hex) |  Size (In Bits)  |    Description/Purpose     |
++--------------+---------------+------------------+----------------------------+
-    +--------------+---------------+------------------+----------------------------+
+|  Field Name  |  Offset (Hex) |  Size (In Bits)  |    Description/Purpose     |
-    | Type         | 0x00          | 8                | Entry type (see below)     |
++==============+===============+==================+============================+
-    |--------------|---------------|------------------|----------------------------|
+| Type         | 0x00          | 8                | Entry type (see below)     |
-    | Region Type  | 0x01          | 8                | Setup the memory region's  |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | security attribute for the |
+| Region Type  | 0x01          | 8                | Setup the memory region's  |
-    |              |               |                  | BIOS entry                 |
+|              |               |                  | security attribute for the |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | BIOS entry                 |
-    | Reset Image  | 0x02[0]       | 1                | Boolean value to define the|
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | BIOS entry is a reset      |
+| Reset Image  | 0x02[0]       | 1                | Boolean value to define the|
-    |              |               |                  | binary image               |
+|              |               |                  | BIOS entry is a reset      |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | binary image               |
-    | Copy Image   | 0x02[1]       | 1                | Define the binary image of |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | the BIOS entry is for      |
+| Copy Image   | 0x02[1]       | 1                | Define the binary image of |
-    |              |               |                  | copying over to the memory |
+|              |               |                  | the BIOS entry is for      |
-    |              |               |                  | region                     |
+|              |               |                  | copying over to the memory |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | region                     |
-    | Read Only    | 0x02[2]       | 1                | Setup the memory region for|
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | the BIOS entry to read only|
+| Read Only    | 0x02[2]       | 1                | Setup the memory region for|
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | the BIOS entry to read only|
-    | Compressed   | 0x02[3]       | 1                | Compressed using zlib      |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  |                            |
+| Compressed   | 0x02[3]       | 1                | Compressed using zlib      |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  |                            |
-    | Instance     | 0x02[7:4]     | 4                | Specify the Instance of an |
++--------------+---------------+------------------+----------------------------+
-    |              |               |                  | entry                      |
+| Instance     | 0x02[7:4]     | 4                | Specify the Instance of an |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | entry                      |
-    | SubProgram   | 0x03[2:0]     | 3                | Specify the SubProgram     |
++--------------+---------------+------------------+----------------------------+
-    |--------------|---------------|------------------|----------------------------|
+| SubProgram   | 0x03[2:0]     | 3                | Specify the SubProgram     |
-    | Reserved     | 0x03[7:3]     | 5                | Reserved - Set to zero     |
++--------------+---------------+------------------+----------------------------+
-    |--------------|---------------|------------------|----------------------------|
+| Reserved     | 0x03[7:3]     | 5                | Reserved - Set to zero     |
-    | Size         | 0x04          | 32               | Memory Region Size         |
++--------------+---------------+------------------+----------------------------+
-    |--------------|---------------|------------------|----------------------------|
+| Size         | 0x04          | 32               | Memory Region Size         |
-    | Source       | 0x08          | 64               | Physical Address of SPIROM |
++--------------+---------------+------------------+----------------------------+
-    | Address      |               |                  | location where the data for|
+| Source       | 0x08          | 64               | Physical Address of SPIROM |
-    |              |               |                  | the corresponding entry is |
+| Address      |               |                  | location where the data for|
-    |              |               |                  | located                    |
+|              |               |                  | the corresponding entry is |
-    |--------------|---------------|------------------|----------------------------|
+|              |               |                  | located                    |
-    | Destination  | 0x10          | 64               | Destination Address of     |
++--------------+---------------+------------------+----------------------------+
-    | Address      |               |                  | memory location where the  |
+| Destination  | 0x10          | 64               | Destination Address of     |
-    |              |               |                  | data for the corresponding |
+| Address      |               |                  | memory location where the  |
-    |              |               |                  | BIOS Entry is copied       |
+|              |               |                  | data for the corresponding |
-    +--------------+---------------+------------------+----------------------------+
+|              |               |                  | BIOS Entry is copied       |
++--------------+---------------+------------------+----------------------------+
+```
 
 ### BIOS Directory Table Entry Types
 

Documentation/soc/intel/fit.md

@@ -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)

Documentation/soc/intel/fsp/index.md

@@ -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
 

Documentation/superio/common/pnp.md

@@ -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
+register space that contains the configuration. By writing the index to
-to the lower byte (e.g. 0x2e), you can access the register contents at
+the lower byte (e.g. `0x2e`), you can access the register contents at
-that index by reading/writing the higher byte (e.g. 0x2f).
+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
+`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
+for all LDNs, but some SIO chips require a certain LDN to be selected in
-in order to write certain registers in there. An LDN gets selected by
+order to write certain registers in there. An LDN gets selected by
-writing the LDN number to the LDN select register 0x07. Registers 0x30
+writing the LDN number to the LDN select register `0x07`. Registers
-to 0xFF are specific to each LDN number.
+`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
+A typical example for an I/O resource mask is `0x07f8` which is
-0b0000011111111000 in binary notation. The three LSBs are zeros here,
+`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
+Each physical LDN has up to two configurable interrupt request register
-register pairs 0x70, 0x71 and 0x72, 0x73. Each pair can be configured
+pairs `0x70`, `0x71` and `0x72`, `0x73`. Each pair can be configured to
-to use a certain IRQ number. Writing 1 to 15 into the first register
+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
+enables IRQ generation; writing 0 to it disables the generation of IRQs
-IRQs for the source. The second register selects the IRQ type (level
+for the source. The second register selects the IRQ type (level or edge)
-or edge) and IRQ level (high or low). For LPC SIOs the IRQ type is
+and IRQ level (high or low). For LPC SIOs the IRQ type is hard-wired to
-hard-wired to edge.
+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.

Documentation/superio/index.md

@@ -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)

Documentation/superio/nuvoton/nct5539d.md

@@ -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).

Documentation/technotes/2020-03-unit-testing-coreboot.md

@@ -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/).

Documentation/technotes/index.md

@@ -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)

Documentation/tutorial/part1.md

@@ -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

Documentation/util.md

@@ -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`
+* __cbmem__ - CBMEM parser to read e.g. timestamps and console log `C`
-* __checklist__ - Board implementation checklist generator `Make`
+* __chromeos__ - These scripts can be used to access Chrome OS
-* __chromeos__ - These scripts can be used to extract System Agent
+resources, for example to extract System Agent reference code and other
-reference code and other blobs (e.g. mrc.bin, refcode, VGA option roms)
+blobs (e.g. mrc.bin, refcode, VGA option roms) from a Chrome OS
-from a Chrome OS recovery image. `C`
+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`

MAINTAINERS

@@ -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

Makefile

@@ -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

Makefile.inc

@@ -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_CURRENT_BASE := $(call int-add, $(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE))
-FMAP_CONSOLE_SIZE := 0
+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_MRC_CACHE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
-	$(FMAP_CONSOLE_SIZE)), 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_CURRENT_BASE := $(call int-add, $(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE))
-FMAP_MRC_CACHE_BASE := 0
+else
-FMAP_MRC_CACHE_SIZE := 0
 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_SMMSTORE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x10000)
-	$(FMAP_CONSOLE_SIZE) $(FMAP_MRC_CACHE_SIZE)), 0x10000)
 FMAP_SMMSTORE_SIZE := $(CONFIG_SMMSTORE_SIZE)
 FMAP_SMMSTORE_ENTRY := SMMSTORE@$(FMAP_SMMSTORE_BASE) $(FMAP_SMMSTORE_SIZE)
-else # ifeq ($(CONFIG_SMMSTORE),y)
+FMAP_CURRENT_BASE := $(call int-add, $(FMAP_SMMSTORE_BASE) $(FMAP_SMMSTORE_SIZE))
-FMAP_SMMSTORE_BASE := 0
+else
-FMAP_SMMSTORE_SIZE := 0
 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_FMAP_BASE := $(FMAP_CURRENT_BASE)
-	$(FMAP_MRC_CACHE_SIZE) $(FMAP_SMMSTORE_SIZE))
 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_CURRENT_BASE := $(call int-add, $(FMAP_CONSOLE_BASE) $(FMAP_CONSOLE_SIZE))
-FMAP_CONSOLE_BASE := 0
+else
-FMAP_CONSOLE_SIZE := 0
 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, $(FMAP_CURRENT_BASE), 0x10000)
-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_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_CURRENT_BASE := $(call int-add, $(FMAP_MRC_CACHE_BASE) $(FMAP_MRC_CACHE_SIZE))
-FMAP_MRC_CACHE_BASE := 0
+else
-FMAP_MRC_CACHE_SIZE := 0
 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_CBFS_BASE := $(FMAP_CURRENT_BASE)
-	$(FMAP_MRC_CACHE_SIZE))
 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

configs/builder/config.intel.cpx.crb

@@ -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"

configs/builder/config.ocp.tiogapass

@@ -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

configs/config.emulation_qemu_aarch64_fit_support_timestamps

@@ -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

configs/config.google_meep_cros

@@ -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

configs/config.google_octopus_spi_flash_console

@@ -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

configs/config.google_reef_cros

@@ -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

configs/config.intel_coffeelake_rvp11.fsp_car

@@ -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

configs/config.libretrend_lt1000

@@ -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

configs/config.ocp_tiogapass

@@ -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"

payloads/Kconfig

@@ -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.

payloads/coreinfo/cpuinfo_module.c

@@ -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");
 

payloads/external/GRUB2/Makefile

@@ -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) && \
+ifeq ($(shell test -d $(project_dir) && \
-	(git -C $(project_dir) status --ignored=no --untracked-files=no --porcelain))",)
+       (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

payloads/external/Makefile.inc

@@ -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

payloads/external/SeaBIOS/Kconfig

@@ -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

payloads/external/SeaBIOS/Makefile

@@ -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/

payloads/external/depthcharge/Makefile

@@ -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:

payloads/external/iPXE/Kconfig

@@ -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

payloads/external/iPXE/Makefile

@@ -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)

payloads/external/tianocore/Kconfig

@@ -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

payloads/external/tianocore/Makefile

@@ -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

payloads/libpayload/Kconfig

@@ -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

payloads/libpayload/arch/arm64/cpu.S

@@ -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)

payloads/libpayload/arch/arm64/head.S

@@ -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

payloads/libpayload/arch/arm64/mmu.c

@@ -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

payloads/libpayload/configs/config.bubs

@@ -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

payloads/libpayload/configs/config.trogdor

@@ -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

payloads/libpayload/drivers/Makefile.inc

@@ -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