Showing 1,153 changed files with 18,845 additions and 17,048 deletions.
diff --git a/3rdparty/amd_blobs b/3rdparty/amd_blobs
diff --git a/3rdparty/vboot b/3rdparty/vboot
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -13,6 +13,11 @@ Please use [pce-fw-builder](https://github.com/pcengines/pce-fw-builder)
 
 ## [Unreleased]
 
+## [v4.11.0.3] - 2020-01-29
+### Changed
+- rebased with official coreboot repository commit 536799d
+- [updated sortbootorder to v4.6.17](https://github.com/pcengines/sortbootorder/blob/master/CHANGELOG.md#v4617---2020-01-28)
+
 ## [v4.11.0.2] - 2019-12-30
 ### Changed
 - rebased with official coreboot repository commit 536799d
@@ -364,7 +369,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.2...develop
+[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.11.0.3...develop
+[v4.11.0.3]: https://github.com/pcengines/coreboot/compare/v4.11.0.2...v4.11.0.3
 [v4.11.0.2]: https://github.com/pcengines/coreboot/compare/v4.11.0.1...v4.11.0.2
 [v4.11.0.1]: https://github.com/pcengines/coreboot/compare/v4.10.0.3...v4.11.0.1
 [v4.10.0.3]: https://github.com/pcengines/coreboot/compare/v4.10.0.2...v4.10.0.3

diff --git a/Documentation/acpi/index.md b/Documentation/acpi/index.md
@@ -2,6 +2,8 @@
 
 This section contains documentation about coreboot on ACPI.
 
+- [SSDT UID generation](uid.md)
+
 ## GPIO
 
 - [GPIO toggling in ACPI AML](gpio.md)

diff --git a/Documentation/acpi/uid.md b/Documentation/acpi/uid.md
@@ -0,0 +1,14 @@
+# ACPI SSDT \_UID generation
+
+According to the ACPI spec:
+
+> The _UID must be unique across all devices with either a common _HID or _CID.
+
+
+When generating SSDTs in coreboot the independent drivers don't know
+which \_UID is already in use for a specific \_HID or \_CID. To generate
+unique \_UIDs the ACPI device's path is hashed and used as ID. As every ACPI
+device has a different path, the hash will be also different for every device.
+
+Windows 10 verifies all devices with the same \_HID or \_CID and makes
+sure that no \_UID is duplicated. If it is it'll BSOD.
diff --git a/Documentation/getting_started/gpio.md b/Documentation/getting_started/gpio.md
@@ -0,0 +1,136 @@
+# Configuring a mainboard's GPIOs in coreboot
+
+## Introduction
+
+Every mainboard needs to appropriately configure its General Purpose Inputs /
+Outputs (GPIOs). There are many facets of this issue, including which boot
+stage a GPIO might need to be configured.
+
+## Boot stages
+
+Typically, coreboot does most of its non-memory related initialization work in
+ramstage, when DRAM is available for use. Hence, the bulk of a mainboard's GPIOs
+are configured in this stage. However, some boards might need a few GPIOs
+configured before that; think of memory strapping pins which indicate what kind
+of DRAM is installed. These pins might need to be read before initializing the
+memory, so these GPIOs are then typically configured in bootblock or romstage.
+
+## Configuration
+
+Most mainboards will have a ``gpio.c`` file in their mainboard directory. This
+file typically contains tables which describe the configuration of the GPIO
+registers. Since these registers could be different on a per-SoC or per
+SoC-family basis, you may need to consult the datasheet for your SoC to find out
+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
+ones that are board-specific go into each variant's ``gpio.c`` file.
+
+## Intel SoCs
+
+Many newer Intel SoCs share a common IP block for GPIOs, and that commonality
+has been taken advantage of in coreboot, which has a large set of macros that
+can be used to describe the configuration of each GPIO pad. This file lives in
+``src/soc/intel/common/block/include/intelblocks/gpio_defs.h``.
+
+### Older Intel SoCs
+
+Baytrail and Braswell, for example, simply expect the mainboard to supply a
+callback, `mainboard_get_gpios` which returns an array of `struct soc_gpio`
+objects, defining the configuration of each pin.
+
+### AMD SoCs
+
+Some AMD SoCs use a list of `struct soc_amd_gpio` objects to define the
+register values configuring each pin, similar to Intel.
+
+### Register details
+
+GPIO configuration registers typically control properties such as:
+1. Input / Output
+2. Pullups / Pulldowns
+3. Termination
+4. Tx / Rx Disable
+5. Which reset signal to use
+6. Native Function / IO
+7. Interrupts
+    * IRQ routing (e.g. on x86, APIC, SCI, SMI)
+    * Edge or Level Triggered
+    * Active High or Active Low
+8. Debouncing
+
+## Configuring GPIOs for pre-ramstage
+
+coreboot provides for several SoC-specific and mainboard-specific callbacks at
+specific points in time, such as bootblock-early, bootblock, romstage entry,
+pre-silicon init, pre-RAM init, or post-RAM init. The GPIOs that are
+configured in either bootblock or romstage, depending on when they are needed,
+are denoted the "early" GPIOs. Some mainboard will use
+``bootblock_mainboard_init()`` to configure their early GPIOs, and this is
+probably a good place to start. Many mainboards will declare their GPIO
+configuration as structs, i.e. (Intel),
+
+```C
+struct pad_config {
+    /* offset of pad within community */
+        int             pad;
+    /* Pad config data corresponding to DW0, DW1,.... */
+        uint32_t        pad_config[GPIO_NUM_PAD_CFG_REGS];
+};
+```
+
+and will usually place these in an array, one for each pad to be configured.
+Mainboards using Intel SoCs can use a library which combines common
+configurations together into a set of macros, e.g.,
+
+```C
+    /* Native function configuration */
+    #define PAD_CFG_NF(pad, pull, rst, func)
+    /*
+     * Set native function with RX Level/Edge configuration and disable
+     * input/output buffer if necessary
+     */
+    #define PAD_CFG_NF_BUF_TRIG(pad, pull, rst, func, bufdis, trig)
+    /* General purpose output, no pullup/down. */
+    #define PAD_CFG_GPO(pad, val, rst)
+    /* General purpose output, with termination specified */
+    #define PAD_CFG_TERM_GPO(pad, val, pull, rst)
+    /* General purpose output, no pullup/down. */
+    #define PAD_CFG_GPO_GPIO_DRIVER(pad, val, rst, pull)
+    /* General purpose input */
+    #define PAD_CFG_GPI(pad, pull, rst)
+```
+etc.
+
+## Configuring GPIOs for ramstage and beyond...
+
+In ramstage, most mainboards will configure the rest of their GPIOs for the
+function they will be performing while the device is active. The goal is the
+same as above in bootblock; another ``static const`` array is created, and the
+rest of the GPIO registers are programmed.
+
+In the baseboard/variant model described above, the baseboard will provide the
+configuration for the GPIOs which are configured identically between variants,
+and will provide a mechanism for a variant to override the baseboard's
+configuration. This is usually done via two tables: the baseboard table and the
+variant's override table.
+
+This configuration is often hooked into the mainboard's `enable_dev` callback,
+defined in its `struct chip_operations`.
+
+## Potential issues (gotchas!)
+
+There are a couple of configurations that you need to especially careful about,
+as they can have a large impact on your mainboard.
+
+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.
diff --git a/Documentation/getting_started/index.md b/Documentation/getting_started/index.md
@@ -7,3 +7,4 @@
 * [Gerrit Guidelines](gerrit_guidelines.md)
 * [Documentation License](license.md)
 * [Writing Documentation](writing_documentation.md)
+* [Setting up GPIOs](gpio.md)
diff --git a/Documentation/getting_started/writing_documentation.md b/Documentation/getting_started/writing_documentation.md
@@ -42,8 +42,25 @@ Please follow this official [guide] to install sphinx.
 You will also need python-recommonmark for sphinx to be able to handle
 markdown documentation.
 
-The recommended version is sphinx 1.7.7, sphinx_rtd_theme 0.4.1 and
-recommonmark 0.4.0.
+Since some Linux distributions don't package every needed sphinx extension,
+the installation via pip in a venv is recommended. You'll need these python3
+modules:
+
+* sphinx
+* recommonmark
+* sphinx_rtd_theme
+* sphinxcontrib-ditaa
+
+The following combination of versions has been tested: sphinx 2.3.1,
+recommonmark 0.6.0, sphinx_rtd_theme 0.4.3 and sphinxcontrib-ditaa 0.7.
+
+Now change into the `Documentation` folder in the coreboot directory and run
+this command in there
+
+	make sphinx
+
+If no error occurs, you can find the generated HTML documentation in
+`Documentation/_build` now.
 
 ### Optional
 

diff --git a/Documentation/lib/payloads/fit.md b/Documentation/lib/payloads/fit.md
@@ -58,7 +58,7 @@ Supported compression algorithms:
 The config entries contain a compatible string, that is used to find a
 matching config.
 
-The following mainboard specific funtions provide the BOARDID and SKUID:
+The following mainboard specific functions provide the BOARDID and SKUID:
 
 ```c
 uint32_t board_id(void);

diff --git a/Documentation/mainboard/asus/p5q.md b/Documentation/mainboard/asus/p5q.md
@@ -0,0 +1,77 @@
+# ASUS P5Q
+
+This page describes how to run coreboot on the [ASUS P5Q] desktop board.
+
+## TODO
+
+The following things are working in this coreboot port:
+
++ PCI slots
++ PCI-e slots
++ Onboard Ethernet
++ USB
++ Onboard sound card
++ PS/2 keyboard
++ All 4 DIMM slots
++ S3 suspend and resume
++ Red SATA ports
+
+The following things are still missing from this coreboot port:
+
++ PS/2 mouse support
++ PATA aka IDE (because of buggy IDE controller)
++ Fan control (will be working on 100% power)
++ TPM module (support not implemented)
+
+The following things are untested on this coreboot port:
+
++ S/PDIF
++ CD Audio In
++ Floppy disk drive
++ FireWire: PCI device shows up and driver loads, no further test
+
+
+## Flashing coreboot
+
+```eval_rst
++-------------------+----------------+
+| Type              | Value          |
++===================+================+
+| Socketed flash    | Yes            |
++-------------------+----------------+
+| Model             | MX25L8005      |
++-------------------+----------------+
+| Size              | 1 MiB          |
++-------------------+----------------+
+| Package           | Socketed DIP-8 |
++-------------------+----------------+
+| Write protection  | No             |
++-------------------+----------------+
+| Dual BIOS feature | No             |
++-------------------+----------------+
+| Internal flashing | Yes            |
++-------------------+----------------+
+```
+
+You can flash coreboot into your motherboard using [this guide].
+
+## Technology
+
+```eval_rst
++------------------+---------------------------------------------------+
+| Northbridge      | Intel P45 (called x4x in coreboot code)           |
++------------------+---------------------------------------------------+
+| Southbridge      | Intel ICH10R (called i82801jx in coreboot code)   |
++------------------+---------------------------------------------------+
+| CPU (LGA775)     | Model f4x, f6x, 6fx, 1067x (Pentium 4, d, Core 2) |
++------------------+---------------------------------------------------+
+| SuperIO          | Winbond W83667HG                                  |
++------------------+---------------------------------------------------+
+| Coprocessor      | No                                                |
++------------------+---------------------------------------------------+
+| Clockgen (CK505) | ICS 9LPRS918JKLF                                  |
++------------------+---------------------------------------------------+
+```
+
+[ASUS P5Q]: https://www.asus.com/Motherboards/P5Q
+[this guide]: https://doc.coreboot.org/flash_tutorial/int_flashrom.html
diff --git a/Documentation/mainboard/index.md b/Documentation/mainboard/index.md
@@ -13,6 +13,7 @@ This section contains documentation about coreboot on specific mainboards.
 ## ASUS
 
 - [F2A85-M](asus/f2a85-m.md)
+- [P5Q](asus/p5q.md)
 - [P8H61-M LX](asus/p8h61-m_lx.md)
 - [P8H61-M Pro](asus/p8h61-m_pro.md)
 - [P8Z77-M Pro](asus/p8z77-m_pro.md)
@@ -126,6 +127,7 @@ The boards in this section are not real mainboards, but emulators.
 
 - [X10SLM+-F](supermicro/x10slm-f.md)
 - [X11 LGA1151 series](supermicro/x11-lga1151-series/x11-lga1151-series.md)
+- [Flashing using the BMC](supermicro/flashing_on_vendorbmc.md)
 
 ## UP
 

diff --git a/Documentation/mainboard/lenovo/x301_kb_removed.jpg b/Documentation/mainboard/lenovo/x301_kb_removed.jpg
diff --git a/Documentation/mainboard/supermicro/flashing_on_vendorbmc.md b/Documentation/mainboard/supermicro/flashing_on_vendorbmc.md
@@ -0,0 +1,32 @@
+# Flashing coreboot using SMC IPMI (BMC) firmware
+
+## Metadata
+In order to flash anything to the "BIOS" IC, it needs to contain a valid
+BIOSINFO struct.
+
+The BIOSINFO struct contains a `$FID` marker at the beginning and is
+128 bytes in total. Besides the *BoardID* it contains the *firmware version*
+and *build date*. The BMC verifies that the BoardID is correct and refuses to
+flash if it's not.
+
+The struct has no checksum or cryptographic protection.
+
+## The smcinfobios tool
+
+The smcbiosinfo tool can be found in `util/supermicro/smcbiosinfo`.
+
+It parses the `build/build.h` header to get the current coreboot version and
+build timestamp.
+The *board ID* is passed as command line argument.
+
+It will place a file in CBFS called `smcbiosinfo.bin`, which is then found
+by the vendor tools. The file contains the struct described above.
+
+## Flashing using SMCIPMItool
+
+You can use the *SMCIPMITool* to remotely flash the BIOS:
+
+`SMCIPMITool <remote BMC IP> <user> <password> bios update build/coreboot.rom`
+
+Make sure that the ME isn't in recovery mode, otherwise you get an error
+message on updating the BIOS.