Showing 1,176 changed files with 116,318 additions and 46,037 deletions.
diff --git a/.gitmodules b/.gitmodules
@@ -9,6 +9,7 @@
 [submodule "vboot"]
 	path = 3rdparty/vboot
 	url = https://review.coreboot.org/vboot.git
+	branch = main
 [submodule "arm-trusted-firmware"]
 	path = 3rdparty/arm-trusted-firmware
 	url = https://review.coreboot.org/arm-trusted-firmware.git

diff --git a/3rdparty/arm-trusted-firmware b/3rdparty/arm-trusted-firmware
diff --git a/3rdparty/intel-sec-tools b/3rdparty/intel-sec-tools
diff --git a/3rdparty/libgfxinit b/3rdparty/libgfxinit
diff --git a/3rdparty/qc_blobs b/3rdparty/qc_blobs
diff --git a/3rdparty/vboot b/3rdparty/vboot
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -4,14 +4,26 @@ Change log for PC Engines fork of coreboot
 Releases 4.0.x are based on PC Engines 20160304 release.
 Releases 4.5.x and 4.6.x are based on mainline support submitted in
 [this gerrit ref](https://review.coreboot.org/#/c/14138/).
-Releases 4.8.0.x/4.9.0.x are based on continuous synchronization with
+Releases 4.8.0.x/4.9.0.x and later are based on continuous synchronization with
 official [coreboot repository](https://review.coreboot.org/cgit/coreboot.git)
 
 ## Quick build instructions
 
 Please use [pce-fw-builder](https://github.com/pcengines/pce-fw-builder)
 
 ## [Unreleased]
+## [v4.14.0.1] - 2021-05-27
+### Changed
+- rebased with official coreboot repository commit 6a936fc
+- [updated sortbootorder to v4.6.21](https://github.com/pcengines/sortbootorder/blob/master/CHANGELOG.md#v4621---2021-05-27)
+- [updated SeaBIOS to rel-1.14.0.1](https://github.com/pcengines/seabios/blob/apu_support/CHANGELOG.md#rel-11401---2021-05-27)
+
+### Added
+- persistent bootorder and runtime configuration in separate FMAP region for
+  apu2-apu6 platforms
+
+### Fixed
+- inconsistent MTRRs warning in Linux
 
 ## [v4.13.0.6] - 2021-04-29
 ### Changed
@@ -496,7 +508,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.13.0.6...develop
+[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.14.0.1...develop
+[v4.14.0.1]: https://github.com/pcengines/coreboot/compare/v4.13.0.6...v4.14.0.1
 [v4.13.0.6]: https://github.com/pcengines/coreboot/compare/v4.13.0.5...v4.13.0.6
 [v4.13.0.5]: https://github.com/pcengines/coreboot/compare/v4.13.0.4...v4.13.0.5
 [v4.13.0.4]: https://github.com/pcengines/coreboot/compare/v4.13.0.3...v4.13.0.4

diff --git a/Documentation/acpi/devicetree.md b/Documentation/acpi/devicetree.md
@@ -65,7 +65,7 @@ Scope (\_SB.PCI0.I2C0)
                 0x0000002D,
             }
         })
-        Name (_S0W, 0x04)  // _S0W: S0 Device Wake State
+        Name (_S0W, ACPI_DEVICE_SLEEP_D3_HOT)  // _S0W: S0 Device Wake State
         Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
         {
             0x15, // GPE #21
@@ -196,7 +196,7 @@ for more details on ACPI methods)
 
 ### _S0W (S0 Device Wake State)
 _S0W indicates the deepest S0 sleep state this device can wake itself from,
-which in this case is 4, representing _D3cold_.
+which in this case is ACPI_DEVICE_SLEEP_D3_HOT, representing _D3hot_.
 
 ### _PRW (Power Resources for Wake)
 _PRW indicates the power resources and events required for wake.  There are no

diff --git a/Documentation/distributions.md b/Documentation/distributions.md
@@ -8,35 +8,41 @@ and those providing after-market firmware to extend the usefulness of devices.
 
 ## Hardware shipping with coreboot
 
-### Purism
-
-[Purism](https://www.puri.sm) sells laptops with a focus on user privacy and
-security; part of that effort is to minimize the amount of proprietary and/or
-binary code. Their laptops ship with a blob-free OS and coreboot firmware
-with a neutralized Intel Management Engine (ME) and SeaBIOS as the payload.
-
 ### ChromeOS Devices
 
 All ChromeOS devices ([Chromebooks](https://chromebookdb.com/), Chromeboxes,
 Chromebit, etc) released from 2012 onward use coreboot for their main system
 firmware. Additionally, starting with the 2013 Chromebook Pixel, the firmware
-running on the Embedded Controller (EC - a small microcontroller which provides
-functions like battery management, keyboard support, and sensor interfacing)
+running on the Embedded Controller (EC) – a small microcontroller which provides
+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
 ships with coreboot and support upstream maintenance for the devices through a
 third party, [3mdeb](https://3mdeb.com). They provide current and tested
 firmware binaries on [GitHub](https://pcengines.github.io).
 
+### System76
+
+[System76](https://system76.com/) manufactures Linux laptops, desktops, and
+servers. Some models are sold with [System76 Open
+Firmware](https://github.com/system76/firmware-open), an open source
+distribution of coreboot, EDK2, and System76 firmware applications.
+
+### Purism
+
+[Purism](https://www.puri.sm) sells laptops with a focus on user privacy and
+security; part of that effort is to minimize the amount of proprietary and/or
+binary code. Their laptops ship with a blob-free OS and coreboot firmware
+with a neutralized Intel Management Engine (ME) and SeaBIOS as the payload.
+
 ## After-market firmware
 
 ### Libreboot

diff --git a/Documentation/getting_started/gerrit_guidelines.md b/Documentation/getting_started/gerrit_guidelines.md
@@ -320,6 +320,47 @@ is criticising your code, but the whole idea is to get better code into our
 codebase. Again, this also applies in the other direction: review code,
 criticize code, but don’t make it personal.
 
+Gerrit user roles
+-----------------
+There are a few relevant roles a user can have on Gerrit:
+
+- The anonymous user can check out source code.
+- A registered user can also comment and give "+1" and "-1" code reviews.
+- A reviewer can also give "+2" code reviews.
+- A core developer can also give "-2" (that is, blocking) code reviews
+  and submit changes.
+
+Anybody can register an account on our instance, using either an
+OpenID provider or OAuth through GitHub or Google.
+
+The reviewer group is still quite open: Any core developer can add
+registered users to that group and should do so once some activity
+(commits, code reviews, and so on) has demonstrated rough knowledge
+of how we handle things.
+
+A core developer should be sufficiently well established in the
+community so that they feel comfortable when submitting good patches,
+when asking for improvements to less good patches and reasonably
+uncomfortable when -2'ing patches. They're typically the go-to
+person for _some_ part of the coreboot tree and ideally listed as its
+maintainer in our MAINTAINERS registry. To become part of this group,
+a candidate developer who already demonstrated proficiency with the
+code base as a reviewer should be nominated, by themselves or others,
+at the regular [coreboot leadership meetings](../community/forums.md)
+where a decision is made.
+
+Core developers are expected to use their privileges for the good of the
+project, which includes any of their own coreboot development but also beyond
+that. They should make sure that [ready changes] don't linger around needlessly
+just because their authors aren't well-connected with core developers but
+submit them if they went through review and generally look reasonable. They're
+also expected to help clean-up breakage as a result of their submissions.
+
+Since the project expects some activity by core developers, long-term absence
+(as in "years") can lead to removal from the group, which can easily be
+reversed after they come back.
 
 Requests for clarification and suggestions for updates to these guidelines
 should be sent to the coreboot mailing list at <coreboot@coreboot.org>.
+
+[ready changes]: https://review.coreboot.org/q/age:1d+project:coreboot+status:open+is:mergeable+label:All-Comments-Resolved%253Dok+label:Code-Review%253D2+-label:Code-Review%253C0+label:Verified%253D1+-label:Verified-1
diff --git a/Documentation/getting_started/gpio.md b/Documentation/getting_started/gpio.md
@@ -115,6 +115,44 @@ variant's override table.
 This configuration is often hooked into the mainboard's `enable_dev` callback,
 defined in its `struct chip_operations`.
 
+## Unconnected and unused pads
+
+In digital electronics, it is generally recommended to tie unconnected GPIOs to
+a defined signal like VCC or GND by setting their direction to output, adding an
+external pull resistor or configuring an internal pull resistor. This is done to
+prevent floating of the pin state, which can cause various issues like EMI,
+higher power usage due to continuously switching logic, etc.
+
+On Intel PCHs from Sunrise Point onwards, termination of unconnected GPIOs is
+explicitly not required, when the input buffer is disabled by setting the bit
+`GPIORXDIS` which effectively disconnects the pad from the internal logic. All
+pads defaulting to GPIO mode have this bit set. However, in the mainboard's
+GPIO configuration the macro `PAD_NC(pad, NONE)` can be used to explicitly
+configure a pad as unconnected.
+
+In case there are no schematics available for a board and the vendor set a
+pad to something like `GPIORXDIS=1`, `GPIOTXDIS=1` with an internal pull
+resistor, an unconnected or otherwise unused pad can be assumed. In this case it
+is recommended to keep the pull resistor, because the external circuit might
+rely on it.
+
+Unconnected pads defaulting to a native function (input and output) usually
+don't need to be configured as GPIO with the `GPIORXDIS` bit set. For clarity
+and documentation purpose the macro may be used as well for them.
+
+Some pads configured as native input function explicitly require external
+pull-ups when being unused, according to the PDGs:
+- eDP_HPD
+- SMBCLK/SMBDATA
+- SML0CLK/SML0DATA/SML0ALERT
+- SATAGP*
+
+When the board was designed correctly, nothing needs to be done for them
+explicitly, while using `PAD_NC(pad, NONE)` can act as documentation. If such a
+pad is missing the external pull resistor due to bad board design, the pad
+should be configured with `PAD_NC(pad, NONE)` anyway to disconnect it
+internally.
+
 ## Potential issues (gotchas!)
 
 There are a couple of configurations that you need to especially careful about,
@@ -124,11 +162,14 @@ The first is configuring a pin as an output, when it was designed to be an
 input. There is a real risk in this case of short-circuiting a component which
 could cause catastrophic failures, up to and including your mainboard!
 
-The other configuration option to watch out for deals with unconnected GPIOs.
-If no pullup or pulldown is declared with these, they may end up "floating",
-i.e., not at logical high or logical low. This can cause problems such as
-unwanted power consumption or not reading the pin correctly, if it was intended
-to be strapped.
+## Soft Straps
+
+Soft straps, that can be configured by the vendor in the Intel Flash Image Tool
+(FIT), can influence some pads' default mode. It is possible to select either a
+native function or GPIO mode for some pads on non-server SoCs, while on server
+SoCs most pads can be controlled. Thus, it is generally recommended to always
+configure all pads and don't just rely on the defaults mentioned in the
+datasheet(s) which might not reflect what the vendor configured.
 
 ## Pad-related known issues and workarounds
 

diff --git a/Documentation/lib/fw_config.md b/Documentation/lib/fw_config.md
@@ -121,12 +121,48 @@ Each field is defined by providing the field name and the start and end bit mark
 location in the bitmask.  Field names must be at least three characters long in order to
 satisfy the sconfig parser requirements and they must be unique with non-overlapping masks.
 
-    field <name> <start-bit> <end-bit> [option...] end
+	field <name> <start-bit> <end-bit> [option...] end
 
 For single-bit fields only one number is needed:
 
 	field <name> <bit> [option...] end
 
+A field definition can also contain multiple sets of bit masks, which can be dis-contiguous.
+They are treated as if they are contiguous when defining option values.  This allows for
+extending fields even after the bits after its current masks are occupied.
+
+	field <name> <start-bit0> <end-bit0> | <start-bit1> <end-bit1> | ...
+
+For example, if more audio options need to be supported:
+
+	field AUDIO 3 3
+		option AUDIO_0  0
+		option AUDIO_1  1
+	end
+	field OTHER 4 4
+		...
+	end
+
+the following can be done:
+
+	field AUDIO 3 3 | 5 5
+		option AUDIO_FOO   0
+		option AUDIO_BLAH  1
+		option AUDIO_BAR   2
+		option AUDIO_BAZ   3
+	end
+	field OTHER 4 4
+		...
+	end
+
+In that case, the AUDIO masks are extended like so:
+
+	#define FW_CONFIG_FIELD_AUDIO_MASK						0x28
+	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE	0x0
+	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH_VALUE	0x8
+	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE	0x20
+	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAz_VALUE	0x28
+
 Each `field` definition starts a new block that can be composed of zero or more field options,
 and it is terminated with `end`.
 

diff --git a/Documentation/mainboard/asus/p5q.md b/Documentation/mainboard/asus/p5q.md
@@ -2,9 +2,7 @@
 
 This page describes how to run coreboot on the [ASUS P5Q] desktop board.
 
-## TODO
-
-The following things are working in this coreboot port:
+## Working
 
 + PCI slots
 + PCI-e slots
@@ -15,20 +13,21 @@ The following things are working in this coreboot port:
 + All 4 DIMM slots
 + S3 suspend and resume
 + Red SATA ports
++ Fan control through the W83667HG chip
++ FireWire
 
-The following things are still missing from this coreboot port:
+## Not working
 
 + PS/2 mouse support
 + PATA aka IDE (because of buggy IDE controller)
-+ Fan control (will be working on 100% power)
++ Fan profiles with Q-Fan
 + TPM module (support not implemented)
 
-The following things are untested on this coreboot port:
+## Untested
 
 + S/PDIF
 + CD Audio In
 + Floppy disk drive
-+ FireWire: PCI device shows up and driver loads, no further test
 
 
 ## Flashing coreboot
@@ -73,5 +72,63 @@ You can flash coreboot into your motherboard using [this guide].
 +------------------+---------------------------------------------------+
 ```
 
+## Controlling fans
+
+With vendor firmware, the P5Q uses the ATK0110 ACPI device to control its fans
+according to the parameters configured in the BIOS setup menu. With coreboot,
+one can instead control the Super I/O directly as described in the
+[kernel docs]:
+
++ pwm1 controls fan1 (CHA_FAN1) and fan4 (CHA_FAN2)
++ pwm2 controls fan2 (CPU_FAN)
++ fan3 (PWR_FAN) cannot be controlled
++ temp1 (board) can be used to control fan1 and fan4
++ temp2 (CPU) can be used to control fan2
+
+### Manual fan speed
+
+These commands set the chassis fans to a constant speed:
+
+    # Use PWM output
+    echo 1 >/sys/class/hwmon/hwmon2/pwm1_mode
+    # Set to manual mode
+    echo 1 >/sys/class/hwmon/hwmon2/pwm1_enable
+    # Set relative speed: 0 (stop) to 255 (full)
+    echo 150 >/sys/class/hwmon/hwmon2/pwm1
+
+### Automatic fan speed
+
+The W83667HG can adjust fan speeds when things get too warm. These settings will
+control the chassis fans:
+
+    # Set to "Thermal Cruise" mode
+    echo 2 >/sys/class/hwmon/hwmon2/pwm1_enable
+    # Target temperature: 60°C
+    echo 60000 >/sys/class/hwmon/hwmon2/pwm1_target
+    # Minimum fan speed when spinning up
+    echo 135 >/sys/class/hwmon/hwmon2/pwm1_start_output
+    # Minimum fan speed when spinning down
+    echo 135 >/sys/class/hwmon/hwmon2/pwm1_stop_output
+    # Tolerance: 2°C
+    echo 2000 >/sys/class/hwmon/hwmon2/pwm1_tolerance
+    # Turn fans off after 600 seconds when below defined range
+    echo 600000 >/sys/class/hwmon/hwmon2/pwm1_stop_time
+
+You can also control the CPU fan with similar rules:
+
+    # Switch to "Thermal Cruise" mode
+    echo 2 >/sys/class/hwmon/hwmon2/pwm2_enable
+    # Target temperature: 55°C
+    echo 55000 >/sys/class/hwmon/hwmon2/pwm2_target
+    # Minimum fan speed when spinning down
+    echo 50 >/sys/class/hwmon/hwmon2/pwm2_stop_output
+    # Rate of fan speed change
+    echo 50 >/sys/class/hwmon/hwmon2/pwm2_step_output
+    # Maximum fan speed
+    echo 200 >/sys/class/hwmon/hwmon2/pwm2_max_output
+    # Tolerance: 2°C
+    echo 2000 >/sys/class/hwmon/hwmon2/pwm1_tolerance
+
 [ASUS P5Q]: https://www.asus.com/Motherboards/P5Q
 [this guide]: https://doc.coreboot.org/flash_tutorial/int_flashrom.html
+[kernel docs]: https://www.kernel.org/doc/Documentation/hwmon/w83627ehf.rst