Showing 1,591 changed files with 14,001 additions and 62,776 deletions.
diff --git a/3rdparty/fsp b/3rdparty/fsp
diff --git a/3rdparty/vboot b/3rdparty/vboot
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -13,6 +13,14 @@ Please use [pce-fw-builder](https://github.com/pcengines/pce-fw-builder)
 
 ## [Unreleased]
 
+## [v4.11.0.2] - 2019-12-30
+### Changed
+- rebased with official coreboot repository commit 536799d
+- [updated sortbootorder to v4.6.16](https://github.com/pcengines/sortbootorder/blob/master/CHANGELOG.md#v4616---2019-12-30)
+
+### Added
+- IOMMU runtime configuration (IOMMU is disabled by default)
+
 ## [v4.11.0.1] - 2019-12-08
 ### Changed
 - rebased with official coreboot repository commit 9f56eed
@@ -356,7 +364,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.1...develop
+[Unreleased]: https://github.com/pcengines/coreboot/compare/v4.11.0.2...develop
+[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
 [v4.10.0.2]: https://github.com/pcengines/coreboot/compare/v4.10.0.1...v4.10.0.2

diff --git a/Documentation/acpi/index.md b/Documentation/acpi/index.md
@@ -0,0 +1,11 @@
+# ACPI-specific documentation
+
+This section contains documentation about coreboot on ACPI.
+
+## GPIO
+
+- [GPIO toggling in ACPI AML](gpio.md)
+
+## devicetree
+
+- [Adding devices to a device tree](devicetree.md)
diff --git a/Documentation/conf.py b/Documentation/conf.py
@@ -25,6 +25,8 @@
 # The short X.Y version.
 version = release.split("-")[0]
 
+extensions = ['sphinxcontrib.ditaa']
+
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
 #

diff --git a/Documentation/index.md b/Documentation/index.md
@@ -171,20 +171,19 @@ Contents:
 * [Payloads](payloads.md)
 * [Distributions](distributions.md)
 * [Technotes](technotes/index.md)
-* [GPIO toggling in ACPI AML](acpi/gpio.md)
-* [Adding devices to a device tree](acpi/devicetree.md)
+* [ACPI](acpi/index.md)
 * [Native Graphics Initialization with libgfxinit](gfx/libgfxinit.md)
-* [Display panel-specific documentation](gfx/display-panel.md)
-* [Architecture-specific documentation](arch/index.md)
-* [Platform independend drivers documentation](drivers/index.md)
-* [Northbridge-specific documentation](northbridge/index.md)
-* [System on Chip-specific documentation](soc/index.md)
-* [Mainboard-specific documentation](mainboard/index.md)
-* [Payload-specific documentation](lib/payloads/index.md)
-* [Library-specific documentation](lib/index.md)
+* [Display panel](gfx/display-panel.md)
+* [CPU Architecture](arch/index.md)
+* [Platform independent drivers](drivers/index.md)
+* [Northbridge](northbridge/index.md)
+* [System on Chip](soc/index.md)
+* [Mainboard](mainboard/index.md)
+* [Payloads](lib/payloads/index.md)
+* [Libraries](lib/index.md)
 * [Security](security/index.md)
-* [SuperIO-specific documentation](superio/index.md)
-* [Vendorcode-specific documentation](vendorcode/index.md)
+* [SuperIO](superio/index.md)
+* [Vendorcode](vendorcode/index.md)
 * [Utilities](util.md)
 * [Release notes for past releases](releases/index.md)
 * [Flashing firmware tutorial](flash_tutorial/index.md)
diff --git a/Documentation/mainboard/facebook/fbg1701.md b/Documentation/mainboard/facebook/fbg1701.md
@@ -72,7 +72,7 @@ Specifically, it's a Winbond W25Q64FV (3.3V), whose datasheet can be found
 +------------------+--------------------------------------------------+
 | CPU              | Intel Braswell (N3710)                           |
 +------------------+--------------------------------------------------+
-| Super I/O, EC    | ITE8256                                          |
+| Super I/O, EC    | ITE8528                                          |
 +------------------+--------------------------------------------------+
 | Coprocessor      | Intel Management Engine                          |
 +------------------+--------------------------------------------------+

diff --git a/Documentation/mainboard/facebook/monolith.md b/Documentation/mainboard/facebook/monolith.md
@@ -2,8 +2,8 @@
 
 This page describes how to run coreboot on the Facebook Monolith.
 
-Please note: the coreboot implementation for this boards is in it's Alpha state and isn't fully 
-tested yet.
+Please note: the coreboot implementation for this boards is in its
+Alpha state and isn't fully tested yet.
 
 ## Required blobs
 
@@ -63,11 +63,11 @@ output.
 
 ```eval_rst
 +------------------+--------------------------------------------------+
-| SoC              | Intel Kaby Lake U                                 |
+| SoC              | Intel Kaby Lake U                                |
 +------------------+--------------------------------------------------+
 | CPU              | Intel i3-7100U                                   |
 +------------------+--------------------------------------------------+
-| Super I/O, EC    | ITE8256                                          |
+| Super I/O, EC    | ITE8528                                          |
 +------------------+--------------------------------------------------+
 | Coprocessor      | Intel Management Engine                          |
 +------------------+--------------------------------------------------+

diff --git a/Documentation/mainboard/gigabyte/ga-h61m-s2pv.md b/Documentation/mainboard/gigabyte/ga-h61m-s2pv.md
@@ -39,27 +39,23 @@ leave the backup chip untouched.
 
 The original IFD defines the BIOS region as the whole flash chip. While this is
 not an issue if flashing a complete image, it confuses flashrom and trashes the
-flash chip's contents when using the --ifd option. However, this can be easily
-fixed by reading the IFD with flashrom, editing the correct values into it with
-ifdtool and then reflashing it.
-
-Create a layout.txt with the following contents:
+flash chip's contents when using the `--ifd` option. A possible workaround is
+to create a `layout.txt` file with a non-overlapping BIOS region:
 
 	00000000:00000fff fd
 	00180000:003fffff bios
 	00001000:0017ffff me
 
-After that, simply run:
+After that, use flashrom with the new layout file. For example, to create a
+backup of the BIOS region and then flash a `coreboot.rom`, do:
 
 ```bash
-sudo flashrom -p internal --ifd -i fd -r ifd.rom
-ifdtool -n layout.txt ifd.rom
-sudo flashrom -p internal --ifd -i fd -w ifd.rom.new
+sudo flashrom -p internal -l layout.txt -i bios -r backup.rom
+sudo flashrom -p internal -l layout.txt -i bios -w coreboot.rom
 ```
 
-After flashing, power cycle the computer to ensure the new IFD is being used.
-If only a reboot is done, the old IFD layout is still seen by flashrom, even if
-the IFD on the flash chip is correctly defining the new region layout.
+Modifying the IFD so that the BIOS region does not overlap would work as well.
+However, this makes DualBIOS unable to recover from a bad flash for some reason.
 
 ## Technology
 

diff --git a/Documentation/mainboard/portwell/pq7-m107.md b/Documentation/mainboard/portwell/pq7-m107.md
@@ -67,7 +67,7 @@ serial/video/pcie ports might be available.
 +------------------+--------------------------------------------------+
 | CPU              | Intel Braswell (N3710)                           |
 +------------------+--------------------------------------------------+
-| Super I/O, EC    | ITE8256                                          |
+| Super I/O, EC    | ITE8528                                          |
 +------------------+--------------------------------------------------+
 | Coprocessor      | Intel Management Engine                          |
 +------------------+--------------------------------------------------+

diff --git a/Documentation/releases/checklist.md b/Documentation/releases/checklist.md
@@ -49,31 +49,34 @@ be more frequent than was needed, so we scaled it back to twice a year.
 ## Checklist
 ### ~2 weeks prior to release
 - [ ] Announce upcoming release to mailing list, ask people to test and
-      to update release notes
+      to update release notes.
 
 ### ~1 week prior to release
 - [ ] Send reminder email to mailing list, ask for people to test,
-      and to update the release notes
-- [ ] Update the topic in the irc channel with the date of the upcoming
-      release
+      and to update the release notes.
+- [ ] Update the topic in the IRC channel with the date of the upcoming
+      release.
+- [ ] If there are any deprecations announced for the following release,
+      make sure that a list of currently affected boards and chipsets is
+      part of the release notes.
 - [ ] Finalize release notes (as much as possible), without specifying
-      release commit ids
+      release commit ids.
 
 ### Day of release
 - [ ] Select a commit ID to base the release upon, announce to IRC,
       ask for testing.
-- [ ] Test the commit selected for release
-- [ ] Update release notes with actual commit id, push to repo
-- [ ] Run release script
-- [ ] Test the release from the actual release tarballs
-- [ ] Push signed Tag to repo
-- [ ] Announce that the release tag is done on IRC
+- [ ] Test the commit selected for release.
+- [ ] Update release notes with actual commit id, push to repo.
+- [ ] Run release script.
+- [ ] Test the release from the actual release tarballs.
+- [ ] Push signed Tag to repo.
+- [ ] Announce that the release tag is done on IRC.
 - [ ] Upload release files to web server
-- [ ] Upload crossgcc sources to web server
-- [ ] Update download page to point to files, push to repo
+- [ ] Upload crossgcc sources to web server.
+- [ ] Update download page to point to files, push to repo.
 - [ ] Write and publish blog post with release notes.
-- [ ] Update the topic in the irc channel that the release is done.
-- [ ] Announce the release to the mailing list
+- [ ] Update the topic in the IRC channel that the release is done.
+- [ ] Announce the release to the mailing list.
 
 ## Pre-Release tasks
 Announce the upcoming release to the mailing list release 2 weeks ahead
@@ -99,7 +102,7 @@ to have in the release.  The release was based on the final of those
 patches to be pulled in.
 
 When a release candidate has been selected, announce the commit ID to
-the #coreboot irc channel, and request that it get some testing, just
+the #coreboot IRC channel, and request that it get some testing, just
 to make sure that everything is sane.
 
 ## Generate the release

diff --git a/Documentation/superio/common/ssdt.md b/Documentation/superio/common/ssdt.md
@@ -45,12 +45,33 @@ chip superio/common
 end
 ```
 
+## Automatically generated methods
+
+The following methods are generated for each SuperIO:
+## AMTX()
+Acquire the global mutex and enter config mode.
+It's called this at the begining of an atomic operation to make sure
+no other ACPI code messes with the config space while working on it.
+
+## RMTX()
+Exit config mode and release the global mutex.
+It's called at the end of an atomic operation.
+
+## SLDN(Arg0)
+Selects the (virtual) LDN given as Arg0.
+This method isn't guarded with the global mutex.
+
+## DLDN(Arg0)
+Disables the (virtual) LDN given as Arg0.
+This method aquires the global mutex.
+
+## QLDN(Arg0)
+Queries the state of the (virtual) LDN given as Arg0.
+This method quires the global mutex.
+
 ## TODO
 
 1) Add ACPI HIDs to every SuperIO driver
-2) Don't guess ACPI HID of LDNs if it's known
-3) Add "enter config" and "exit config" bytes
-4) Generate support methods that allow
+2) Generate support methods that allow
    * Setting resource settings at runtime
    * Getting resource settings at runtime
-   * Disabling LDNs at runtime
diff --git a/Documentation/tutorial/part1.md b/Documentation/tutorial/part1.md
@@ -15,7 +15,7 @@ Download, configure, and build coreboot
     $ cd coreboot
 
 ### Step 3 - Build the coreboot toolchain
-Please note that this can take a significant amount of time
+Please note that this can take a significant amount of time.
 
     $ make crossgcc-i386 CPUS=$(nproc)
 
@@ -53,7 +53,7 @@ These should be the default selections, so if anything else was set, run
        select < Exit >
        select < Yes >
 
-##### check your configuration (optional step):
+##### Check your configuration (optional step):
 
     $ make savedefconfig
     $ cat defconfig

diff --git a/Documentation/tutorial/part2.md b/Documentation/tutorial/part2.md
@@ -1,8 +1,8 @@
 # Tutorial, part 2: Submitting a patch to coreboot.org
 
-## Part 1: Setting up an account at coreboot.org
+## Step 1: Set up an account at coreboot.org
 
-If you already have an account, skip to Part 2.
+If you already have an account, skip to Step 2.
 
 Otherwise, go to <https://review.coreboot.org> in your preferred web browser.
 Select **Sign in** in the upper right corner.
@@ -12,13 +12,13 @@ select **Google OAuth2** (gerrit-oauth-provider plugin). **Note:** Your
 username for the account will be the username of the account you used to
 sign-in with. (ex. your Google username).
 
-## Part 2a: Set up RSA Private/Public Key
+## Step 2a: Set up RSA Private/Public Key
 
-If you prefer to use an HTTP password instead, skip to Part 2b.
+If you prefer to use an HTTP password instead, skip to Step 2b.
 
 For the most up-to-date instructions on how to set up SSH keys with Gerrit go to
 <https://gerrit-documentation.storage.googleapis.com/Documentation/2.14.2/user-upload.html#configure_ssh>
-and follow the instructions there. Then, skip to Part 3.
+and follow the instructions there. Then, skip to Step 3.
 
 Additionally, that section of the Web site provides explanation on starting
 an ssh-agent, which may be particularly helpful for those who anticipate
@@ -44,7 +44,7 @@ forego the password altogether as you will be using it very often.
 Open `id_rsa.pub`, copy all contents and paste into the textbox under
 "Add SSH Public Key" in the https://review.coreboot.org webpage.
 
-## Part 2b: Setting up an HTTP Password
+## Step 2b: Set up an HTTP Password
 
 Alternatively, instead of using SSH keys, you can use an HTTP password. To do so,
 after you select your name and click on **Settings** on the left-hand side, rather
@@ -58,7 +58,21 @@ the password, and add the following to your `$HOME/.netrc` file:
 where YourUserNameHere is your username, and YourPasswordHere is the password you
 just generated.
 
-## Part 3: Clone coreboot and configure it for submitting patches
+If your system is behind a snooping HTTPS proxy, you might also have to
+make its SSL certificate known to curl, a system specific operation.
+If that's not possible for some reason, you can also disable SSL
+certificate verification in git:
+
+	git config [--global] http.sslVerify [true|false]
+
+The `--global` argument sets it for all git transfers of your local
+user, `false` means not to validate the certificate.
+
+If that still doesn't allow you to pull or push changes to the server, the
+proxy is likely tampering with the data stream, in which case there's nothing
+we can do.
+
+## Step 3: Clone coreboot and configure it for submitting patches
 
 On Gerrit, click on the **Browse** tab in the upper left corner and select
 **Repositories**. From the listing, select the "coreboot" repo. You may have
@@ -87,7 +101,7 @@ and other configurations.
 	cd coreboot
 	make gitconfig
 
-## Part 4: Submit a commit
+## Step 4: Submit a commit
 
 An easy first commit to make is fixing existing checkpatch errors and warnings
 in the source files. To see errors that are already present, build the files in
@@ -105,9 +119,9 @@ and can be submitted for review.
 Once you finish making your desired changes, use the command line to stage
 and submit your changes. An alternative and potentially easier way to stage
 and submit commits is to use git cola, a graphical user interface for git. For
-instructions on how to do so, skip to Part 4b.
+instructions on how to do so, skip to Step 4b.
 
-## Part 4a: Using the command line to stage and submit a commit
+## Step 4a: Use the command line to stage and submit a commit
 
 To use the command line to stage a commit, run
 
@@ -167,7 +181,7 @@ using git. You may wish to review the [Gerrit code review workflow
 documentation](https://gerrit-review.googlesource.com/Documentation/intro-user.html#code-review),
 especially if you plan to work on multiple changes at the same time.
 
-## Part 4b: Using git cola to stage and submit a commit
+## Step 4b: Use git cola to stage and submit a commit
 
 If git cola is not installed on your machine, see
 <https://git-cola.github.io/downloads.html> for download instructions.
@@ -228,7 +242,7 @@ explained in the extended description.
 When ready, select 'Commit' again. Once all errors have been satisfied
 and the commit succeeds, move to the command line and run `git push`.
 
-## Part 5: Getting your commit reviewed
+## Step 5: Let others review your commit
 
 Your commits can now be seen on review.coreboot.org if you select "Your"
 and click on "Changes" and can be reviewed by others. Your code will
@@ -238,7 +252,7 @@ users may also give your commit +1. For a commit to be merged, it needs
 to receive a +2. **Note:** A +1 and a +1 does not make a +2. Only certain users
 can give a +2.
 
-## Part 6 (optional): bash-git-prompt
+## Step 6 (optional): bash-git-prompt
 
 To help make it easier to understand the state of the git repository
 without running `git status` or `git log`, there is a way to make the