Showing 8,972 changed files with 37,453 additions and 60,687 deletions.
diff --git a/.gitmodules b/.gitmodules
@@ -42,3 +42,7 @@
 	url = https://review.coreboot.org/amd_blobs.git
 	update = none
 	ignore = dirty
+[submodule "3rdparty/cmocka"]
+	path = 3rdparty/cmocka
+	url = https://review.coreboot.org/cmocka.git
+	update = none
diff --git a/3rdparty/amd_blobs b/3rdparty/amd_blobs
diff --git a/3rdparty/cmocka b/3rdparty/cmocka
diff --git a/3rdparty/intel-microcode b/3rdparty/intel-microcode
diff --git a/3rdparty/libgfxinit b/3rdparty/libgfxinit
diff --git a/3rdparty/vboot b/3rdparty/vboot
diff --git a/AUTHORS b/AUTHORS
@@ -43,19 +43,22 @@ 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
+David S. Peterson
 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
@@ -76,6 +79,7 @@ Free Software Foundation, Inc.
 Freescale Semiconductor, Inc.
 Gary Jennejohn
 George Trudeau
+Gerald Van Baren
 Gerd Hoffmann
 Gergely Kiss
 Google LLC
@@ -91,6 +95,7 @@ Idwer Vollering
 Igor Pavlov
 Imagination Technologies
 Infineon Technologies
+InKi Dae
 Intel Corporation
 Iru Cai
 Isaku Yamahata
@@ -135,6 +140,7 @@ Marvell Semiconductor Inc.
 Matt DeVillier
 Maxim Polyakov
 MediaTek Inc.
+Michael Brunner
 Michael Schroeder
 Michael Niewöhner
 Mika Westerberg
@@ -163,6 +169,7 @@ Paulo Alcantara
 Pavel Sayekat
 PC Engines GmbH
 Per Odlund
+Peter Korsgaard
 Peter Stuge
 Philipp Degler
 Philipp Deppenwiese

diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -13,6 +13,16 @@ Please use [pce-fw-builder](https://github.com/pcengines/pce-fw-builder)
 
 ## [Unreleased]
 
+## [v4.12.0.1] - 2020-05-29
+### Changed
+- rebased with official coreboot repository commit 8952d1c
+- Memtest86+ revision updated to 0b756257276729c1a12bc1d95e7a1f044894bda2
+
+### Fixed
+- [random coreboot hangs on apu1](https://github.com/pcengines/coreboot/issues/394)
+- [AGESA assertion errors on apu1](https://github.com/pcengines/coreboot/issues/397)
+
+
 ## [v4.11.0.6] - 2020-04-26
 ### Changed
 - rebased with official coreboot repository commit d6f7ec5
@@ -412,7 +422,8 @@ redundant code which was similar for APU2/3/5 boards.
 - turn off D4 and D5 leds on boot
 - enable power on after power failure
 
-[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.11.0.6...develop
+[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.12.0.1...develop
+[v4.12.0.1]: https://github.com/pcengines/coreboot/compare/v4.11.0.6...v4.12.0.1
 [v4.11.0.6]: https://github.com/pcengines/coreboot/compare/v4.11.0.5...v4.11.0.6
 [v4.11.0.5]: https://github.com/pcengines/coreboot/compare/v4.11.0.4...v4.11.0.5
 [v4.11.0.4]: https://github.com/pcengines/coreboot/compare/v4.11.0.3...v4.11.0.4

diff --git a/Documentation/Intel/SoC/soc.html b/Documentation/Intel/SoC/soc.html
@@ -657,7 +657,7 @@ <h3>FADT</h3>
   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>

diff --git a/Documentation/acpi/devicetree.md b/Documentation/acpi/devicetree.md
@@ -23,7 +23,7 @@ write the ASL (ACPI Source Language) code yourself.
 ## Device drivers
 
 Let's take a look at an example entry from
-``src/mainboard/google/hatch/variant/hatch/overridetree.cb``:
+``src/mainboard/google/hatch/variants/hatch/overridetree.cb``:
 
 ```
 device pci 15.0 on
@@ -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``.

diff --git a/Documentation/contributing/documentation_ideas.md b/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
+
diff --git a/Documentation/drivers/index.md b/Documentation/drivers/index.md
@@ -6,3 +6,4 @@ they allow to easily reuse existing code accross platforms.
 
 * [IPMI KCS](ipmi_kcs.md)
 * [SMMSTORE](smmstore.md)
+* [SoundWire](soundwire.md)
diff --git a/Documentation/drivers/smmstore.md b/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