Showing 1,817 changed files with 38,870 additions and 26,047 deletions.
diff --git a/.gitlab-ci/regression.sh b/.gitlab-ci/regression.sh
@@ -2,7 +2,6 @@
 
 git clone https://$GITLAB_ROBOT_USERNAME:$GITLAB_ROBOT_TOKEN@$TESTS_REPO_GIT
 cd $TESTS_REPO_DIR
-git checkout a20523022bdd6ecdb419bc952f866babce77a179
 
 sed -i 's+git@gitlab.com:3mdeb/rte/rtectrl-rest-api.git+https://'$GITLAB_ROBOT_USERNAME':'$GITLAB_ROBOT_TOKEN'@gitlab.com/3mdeb/rte/rtectrl-rest-api.git+' .gitmodules
 sed -i 's+git@gitlab.com:3mdeb/rte/snipeit-rest-api.git+https://'$GITLAB_ROBOT_USERNAME':'$GITLAB_ROBOT_TOKEN'@gitlab.com/3mdeb/rte/snipeit-rest-api.git+' .gitmodules

diff --git a/3rdparty/amd_blobs b/3rdparty/amd_blobs
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -12,6 +12,14 @@ official [coreboot repository](https://review.coreboot.org/cgit/coreboot.git)
 Please use [pce-fw-builder](https://github.com/pcengines/pce-fw-builder)
 
 ## [Unreleased]
+## [v4.15.0.1] - 2021-11-26
+### Changed
+- rebased with official coreboot repository commit 6973a3e7
+
+## [v4.14.0.6] - 2021-10-29
+### Changed
+- rebased with official coreboot repository commit d06c0917
+
 ## [v4.14.0.5] - 2021-10-08
 ### Changed
 - rebased with official coreboot repository commit d4c55353

diff --git a/Documentation/RFC/chip.tex b/Documentation/RFC/chip.tex
@@ -7,7 +7,7 @@
 
 \section{Scope}
 This document defines how LinuxBIOS programmers can specify chips that
-are used, specified, and initalized. The current scope is for superio
+are used, specified, and initialized. The current scope is for superio
 chips, but the architecture should allow for specification of other chips such
 as southbridges. Multiple chips of same or different type are supported.
 

diff --git a/Documentation/acpi/devicetree.md b/Documentation/acpi/devicetree.md
@@ -5,7 +5,7 @@
 ACPI exposes a platform-independent interface for operating systems to perform
 power management and other platform-level functions.  Some operating systems
 also use ACPI to enumerate devices that are not immediately discoverable, such
-as those behind I2C or SPI busses (in contrast to PCI).  This document discusses
+as those behind I2C or SPI buses (in contrast to PCI).  This document discusses
 the way that coreboot uses the concept of a "device tree" to generate ACPI
 tables for usage by the operating system.
 

diff --git a/Documentation/acpi/gpio.md b/Documentation/acpi/gpio.md
@@ -84,15 +84,6 @@ the raw Rx gpio value.
 
 ## Implementation Details
 
-ACPI library in coreboot will provide weak definitions for all the
-above functions with error messages indicating that these functions
-are being used. This allows drivers to conditionally make use of GPIOs
-based on device-tree entries or any other config option. It is
-recommended that the SoC code in coreboot should provide
-implementations of all the above functions generating ACPI AML code
-irrespective of them being used in any driver. This allows mainboards
-to use any drivers and take advantage of this common infrastructure.
-
 Platforms are restricted to using Local5, Local6 and Local7 variables
 only in implementations of the above functions. Any AML methods called
 by the above functions do not have any such restrictions on use of

diff --git a/Documentation/arch/x86/index.md b/Documentation/arch/x86/index.md
@@ -92,6 +92,6 @@ Here's a list of known issues:
   page tables in ROM will be loaded and used, which breaks code and data as
   the page table doesn't contain the expected data. This in turn leads to
   undefined behaviour whenever the 'wrong' address is being read.
-* Disabling paging in compability mode crashes the CPU.
-* Returning from long mode to compability mode crashes the CPU.
+* Disabling paging in compatibility mode crashes the CPU.
+* Returning from long mode to compatibility mode crashes the CPU.
 * Entering long mode crashes on AMD host platforms.
diff --git a/Documentation/community/forums.md b/Documentation/community/forums.md
@@ -17,7 +17,9 @@ We also have a real time chat room on [IRC](ircs://irc.libera.chat/#coreboot),
 also bridged to [Matrix](https://matrix.to/#/#coreboot:libera.chat) and a
 [Discord](https://discord.gg/JqT8NM5Zbg) presence. You can also find us on
 [OSF Slack](https://osfw.slack.com/), which has channels on many open source
-firmware related topics.
+firmware related topics. Slack requires that people come from specific domains
+or are explicitly invited. To work around that, there's an
+[invite bot](https://slack.osfw.dev/) to let people in.
 
 ## Fortnightly coreboot leadership meeting
 

diff --git a/Documentation/conf.py b/Documentation/conf.py
@@ -185,7 +185,7 @@
 enable_auto_toc_tree = True
 
 class MyCommonMarkParser(CommonMarkParser):
-    # remove this hack once upsteam RecommonMark supports inline code
+    # remove this hack once upstream RecommonMark supports inline code
     def visit_code(self, mdnode):
         from docutils import nodes
         n = nodes.literal(mdnode.literal, mdnode.literal)

diff --git a/Documentation/contributing/coding_style.md b/Documentation/contributing/coding_style.md
@@ -1,6 +1,6 @@
 # Coding Style
 
-This is a short document describing the preferred coding style for the
+This document describes the preferred C coding style for the
 coreboot project. It is in many ways exactly the same as the Linux
 kernel coding style. In fact, most of this document has been copied from
 the [Linux kernel coding style](http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodingStyle?id=HEAD)
@@ -801,7 +801,7 @@ There are a LOT of cpu cycles that can go into these 5 milliseconds.
 
 A reasonable rule of thumb is to not put inline at functions that have
 more than 3 lines of code in them. An exception to this rule are the
-cases where a parameter is known to be a compiletime constant, and as a
+cases where a parameter is known to be a compile time constant, and as a
 result of this constantness you *know* the compiler will be able to
 optimize most of your function away at compile time. For a good example
 of this later case, see the kmalloc() inline function.

diff --git a/Documentation/contributing/project_ideas.md b/Documentation/contributing/project_ideas.md
@@ -202,9 +202,9 @@ 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.
+for management tasks and new board status uploads.
 
-At least one older test result should be keept in the database.
+At least one older test result should be kept 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

diff --git a/Documentation/distributions.md b/Documentation/distributions.md
@@ -17,11 +17,6 @@ running on the Embedded Controller (EC) – a small microcontroller which provid
 functions like battery management, keyboard support, and sensor interfacing –
 is open source as well.
 
-### Libretrend
-
-[Libretrend](https://libretrend.com) sells the Librebox, a NUC-like PC which
-ships with coreboot firmware.
-
 ### PC Engines APUs
 
 [PC Engines](https://pcengines.ch) designs and sells embedded PC hardware that

diff --git a/Documentation/drivers/index.md b/Documentation/drivers/index.md
@@ -2,7 +2,7 @@
 
 The drivers can be found in `src/drivers`. They are intended for onboard
 and plugin devices, significantly reducing integration complexity and
-they allow to easily reuse existing code accross platforms.
+they allow to easily reuse existing code across platforms.
 
 * [Intel DPTF](dptf.md)
 * [IPMI KCS](ipmi_kcs.md)

diff --git a/Documentation/flash_tutorial/index.md b/Documentation/flash_tutorial/index.md
@@ -7,7 +7,7 @@ flash IC.
 
 ## Contents
 
-* [Flashing internaly](int_flashrom.md)
+* [Flashing internally](int_flashrom.md)
 * [Flashing firmware standalone](ext_standalone.md)
 * [Flashing firmware externally supplying direct power](ext_power.md)
 * [Flashing firmware externally without supplying direct power](no_ext_power.md)

diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt
@@ -19,7 +19,7 @@ time). The file gcov-io.c is unchanged.
 +#define BITS_PER_UNIT 8
 +#define LONG_LONG_TYPE_SIZE 64
 +
-+/* There are many gcc_assertions. Set the vaule to 1 if we want a warning
++/* There are many gcc_assertions. Set the value to 1 if we want a warning
 +   message if the assertion fails.  */
 +#ifndef ENABLE_ASSERT_CHECKING
 +#define ENABLE_ASSERT_CHECKING 1

diff --git a/Documentation/getting_started/architecture.md b/Documentation/getting_started/architecture.md
@@ -41,7 +41,7 @@ The bootblock loads the romstage or the verstage if verified boot is enabled.
 
 ### Cache-As-Ram
 The *Cache-As-Ram*, also called Non-Eviction mode, or *CAR* allows to use the
-CPU cache like regular SRAM. This is particullary usefull for high level
+CPU cache like regular SRAM. This is particullary useful for high level
 languages like `C`, which need RAM for heap and stack.
 
 The CAR needs to be activated using vendor specific CPU instructions.
@@ -85,7 +85,7 @@ The ramstage does the main device init:
 * CPU init (like set up SMM)
 
 After initialization tables are written to inform the payload or operating system
-about the current hardware existance and state. That includes:
+about the current hardware existence and state. That includes:
 
 * ACPI tables (x86 specific)
 * SMBIOS tables (x86 specific)

diff --git a/Documentation/getting_started/writing_documentation.md b/Documentation/getting_started/writing_documentation.md
@@ -6,7 +6,7 @@
 That said please always try to write documentation! One problem in the
 firmware development is the missing documentation. In this document
 you will get a brief introduction how to write, submit and publish
-documenation to coreboot.
+documentation to coreboot.
 
 ## Preparations
 

diff --git a/Documentation/index.md b/Documentation/index.md
@@ -45,6 +45,12 @@ to the payload), but it's also a value that is deeply ingrained in the
 project. We fearlessly rip out parts of the architecture and remodel it
 when a better way of doing the same was identified.
 
+That said, since there are attempts to coerce coreboot to move in various
+directions by outside "standardization", long-established practices of
+coreboot as well as aligned projects can be documented as best practices,
+making them standards in their own right. However we reserve the right to
+retire them as the landscape shifts around us.
+
 ### One tree for everything
 
 Another difference to various other firmware projects is that we try

diff --git a/Documentation/lib/payloads/fit.md b/Documentation/lib/payloads/fit.md
@@ -25,7 +25,7 @@ The section must be named in order to be found by the FIT parser:
 
 ## Architecture specifics
 
-The FIT parser needs architecure support.
+The FIT parser needs architecture support.
 
 ### aarch32
 The source code can be found in `src/arch/arm/fit_payload.c`.

diff --git a/Documentation/lib/timestamp.md b/Documentation/lib/timestamp.md
@@ -99,7 +99,7 @@ exist and an entry structure to hold variable number of entries.
 
 ### entries
 
-This field holds the details of each timestamp entry, upto a maximum
+This field holds the details of each timestamp entry, up to a maximum
 of `MAX_TIMESTAMP_CACHE` which is defined as 16 entries. Each entry is
 defined by:
 

diff --git a/Documentation/mainboard/amd/padmelon/padmelon.md b/Documentation/mainboard/amd/padmelon/padmelon.md
@@ -43,7 +43,7 @@ Three items are marked in this picture
 +---------------------+--------------------+
 | Size                | 8 MiB              |
 +---------------------+--------------------+
-| Flash programing    | dediprog header    |
+| Flash programming   | dediprog header    |
 +---------------------+--------------------+
 | Package             | SOIC-8             |
 +---------------------+--------------------+

diff --git a/Documentation/mainboard/emulation/qemu-aarch64.md b/Documentation/mainboard/emulation/qemu-aarch64.md
@@ -1,5 +1,5 @@
 # QEMU AArch64 emulator
-This page discribes how to build and run coreboot for QEMU/AArch64.
+This page describes how to build and run coreboot for QEMU/AArch64.
 You can use LinuxBoot via `make menuconfig` or an arbitrary FIT image
 as a payload for QEMU/AArch64.
 

diff --git a/Documentation/mainboard/index.md b/Documentation/mainboard/index.md
@@ -182,15 +182,19 @@ The boards in this section are not real mainboards, but emulators.
 
 - [Adder Workstation 1](system76/addw1.md)
 - [Adder Workstation 2](system76/addw2.md)
+- [Bonobo Workstation 14](system76/bonw14.md)
 - [Darter Pro 6](system76/darp6.md)
 - [Darter Pro 7](system76/darp7.md)
 - [Galago Pro 4](system76/galp4.md)
 - [Galago Pro 5](system76/galp5.md)
 - [Gazelle 15](system76/gaze15.md)
+- [Gazelle 16](system76/gaze16.md)
 - [Lemur Pro 9](system76/lemp9.md)
 - [Lemur Pro 10](system76/lemp10.md)
 - [Oryx Pro 5](system76/oryp5.md)
 - [Oryx Pro 6](system76/oryp6.md)
+- [Oryx Pro 7](system76/oryp7.md)
+- [Oryx Pro 8](system76/oryp8.md)
 
 ## Texas Instruments
 

diff --git a/Documentation/mainboard/lenovo/Ivy_Bridge_series.md b/Documentation/mainboard/lenovo/Ivy_Bridge_series.md
@@ -76,7 +76,7 @@ region. The update is then written into the EC once.
 
 [fl]: flashlayout_Ivy_Bridge.svg
 
-## Reducing Intel Managment Engine firmware size
+## Reducing Intel Management 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

diff --git a/Documentation/mainboard/lenovo/Sandy_Bridge_series.md b/Documentation/mainboard/lenovo/Sandy_Bridge_series.md
@@ -48,7 +48,7 @@ region. The update is then written into the EC once.
 
 [fl]: flashlayout_Sandy_Bridge.svg
 
-## Reducing Intel Managment Engine firmware size
+## Reducing Intel Management 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

diff --git a/Documentation/mainboard/lenovo/vboot.md b/Documentation/mainboard/lenovo/vboot.md
@@ -28,7 +28,7 @@ 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.
+default FMAP. They are missing the `B` partition, due to size constraints.
 You can still provide your own FMAP if you need `RO`+`A`+`B` partitions.
 
 ## CMOS

diff --git a/Documentation/mainboard/ocp/deltalake.md b/Documentation/mainboard/ocp/deltalake.md
@@ -7,15 +7,24 @@ Delta Lake server platform.
 
 OCP Delta Lake server platform is a component of multi-host server system
 Yosemite-V3. Both [Delta Lake server design spec] and [Yosemite-V3 design
-spec] were contributed to [OCP].
+spec] were [OCP] accepted.
+
+On the other hand, Wiwynn's Yosemite-V3 system and Delta Lake server product
+along with its OSF implementation, which is based on FSP/coreboot/LinuxBoot
+stack, was [OCP] accepted; For details, check:
+- [The OCP blog]
+- [The Wiwynn Press Release]
+- [The Wiwynn's Yosemite-V3 product in OCP market place]
+Wiwynn and 9Elements formed a partnership to offer the Wiwynn's Yosemite-V3
+product and OSF for it.
 
 Delta Lake server is a single socket Cooper Lake Scalable Processor (CPX-SP) server.
 Intel Cooper Lake Scalable Processor was launched in Q2 2020.
 
 Yosemite-V3 has multiple configurations. Depending on configurations, it may
 host up to 4 Delta Lake servers (blades) in one sled.
 
-The Yosemite-V3 system is in mass production. Facebook, Intel and partners
+The Yosemite-V3 system is in mass production. Meta, Intel and partners
 jointly develop Open System Firmware (OSF) solution on Delta Lake as an alternative
 solution. The OSF solution is based on FSP/coreboot/LinuxBoot stack. The
 OSF solution reached production quality for some use cases in July, 2021.
@@ -187,6 +196,9 @@ and [u-root] as initramfs.
 [OCP]: https://www.opencompute.org
 [Delta Lake server design spec]: https://www.opencompute.org/documents/delta-lake-1s-server-design-specification-1v05-pdf
 [Yosemite-V3 design spec]: https://www.opencompute.org/documents/ocp-yosemite-v3-platform-design-specification-1v16-pdf
+[The OCP blog]: https://www.opencompute.org/blog/open-system-firmware-for-ocp-server-deltalake-is-published
+[The Wiwynn Press Release]: https://www.prnewswire.com/news-releases/wiwynn-successfully-implemented-open-system-firmware-on-its-ocp-yosemite-v3-server-301417374.html?tc=eml_cleartime
+[The Wiwynn's Yosemite-V3 product in OCP market place]: https://www.opencompute.org/products/423/wiwynn-yosemite-v3-server
 [osf-builder]: https://github.com/facebookincubator/osf-builder
 [OCP virtual summit 2020]: https://www.opencompute.org/summit/virtual-summit/schedule
 [flashrom]: https://flashrom.org/Flashrom

diff --git a/Documentation/mainboard/ocp/tiogapass.md b/Documentation/mainboard/ocp/tiogapass.md
@@ -51,7 +51,7 @@ To connect to console through SOL (Serial Over Lan):
 
 ## Known issues / feature gaps
 - C6 state is not supported. Workaround is to disable C6 support through
-  target OS and Linuxboot kernel paramter, such as "cpuidle.off=1".
+  target OS and Linuxboot kernel parameter, such as "cpuidle.off=1".
 - SMI handlers are not implemented.
 - xSDT tables are not fully populated, such as processor/socket devices,
   PCIe bridge devices.