CHANGELOG.md

@@ -12,6 +12,12 @@ 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.2] - 2021-12-27
+### Changed
+- rebased with official coreboot repository commit 3990da0b
+- disabled SMM
+- enabled parallel AP initialization for apu2-6 for faster boot time
+
 ## [v4.15.0.1] - 2021-11-26
 ### Changed
 - rebased with official coreboot repository commit 6973a3e7

Documentation/distributions.md

@@ -24,6 +24,13 @@ 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).
 
+### Star Labs
+
+[Star Labs](https://starlabs.systems/) offers a range of laptops designed and
+built specifically for Linux that are available with coreboot firmware. They
+use Tianocore as the payload and include an NVRAM option to disable the
+Intel Management Engine.
+
 ### System76
 
 [System76](https://system76.com/) manufactures Linux laptops, desktops, and

Documentation/getting_started/gerrit_guidelines.md

@@ -193,8 +193,10 @@ the wip flag:
 * When pushing patches that are not for submission, these should be marked
 as such. This can be done in the title ‘[DONOTSUBMIT]’, or can be pushed as
 private changes, so that only explicitly added reviewers will see them. These
-sorts of patches are frequently posted as ideas or RFCs for the community
-to look at. To push a private change, use the command:
+sorts of patches are frequently posted as ideas or RFCs for the community to
+look at. Note that private changes can still be fetched from Gerrit by anybody
+who knows their commit ID, so don't use this for sensitive changes. To push
+a private change, use the command:
         git push origin HEAD:refs/for/master%private
 
 * Multiple push options can be combined:

Documentation/mainboard/facebook/fbg1701.md

@@ -5,10 +5,7 @@ This page describes how to run coreboot on the Facebook FBG1701.
 FBG1701 are assembled with different onboard memory modules:
 	Rev 1.0	Onboard Samsung K4B8G1646D-MYKO memory
 	Rev 1.1 and 1.2	Onboard Micron MT41K512M16HA-125A memory
-	Rev 1.3	Onboard Kingston B5116ECMDXGGB memory
-
-Use make menuconfig to configure `onboard memory manufacturer Samsung` in
-Mainboard menu.
+	Rev 1.3 and 1.4 Onboard Kingston B5116ECMDXGGB memory
 
 ## Required blobs
 

Documentation/mainboard/index.md

@@ -172,6 +172,10 @@ The boards in this section are not real mainboards, but emulators.
 
 - [SiFive HiFive Unleashed](sifive/hifive-unleashed.md)
 
+## Star Labs Systems
+
+- [StarBook Mk V](starlabs/starbook_tgl.md)
+
 ## Supermicro
 
 - [X10SLM+-F](supermicro/x10slm-f.md)

Documentation/mainboard/starlabs/starbook_tgl.md

@@ -0,0 +1,154 @@
+# StarBook Mk V
+
+## Specs
+
+- CPU (full processor specs available at https://ark.intel.com)
+    - Intel i7-1165G7 (Tiger Lake)
+    - Intel i3-1110G4 (Tiger Lake)
+- EC
+    - ITE IT5570E
+    - Backlit Keyboard, with standard PS/2 keycodes and SCI hotkeys
+    - Battery
+    - Charger, using AC adapter or USB-C PD
+    - Suspend / resume
+- GPU
+    - Intel® Iris® Xe Graphics
+    - GOP driver is recommended, VBT is provided
+    - eDP 14-inch 1920x1080 LCD
+    - HDMI video
+    - USB-C DisplayPort video
+- Memory
+    - 2 x DDR4 SODIMM
+- Networking
+    - AX201 2230 WiFi / Bluetooth
+- Sound
+    - Realtek ALC256
+    - Internal speakers
+    - Internal microphone
+    - Combined headphone / microphone 3.5-mm jack
+    - HDMI audio
+    - USB-C DisplayPort audio
+- Storage
+    - M.2 PCIe SSD
+    - RTS5129 MicroSD card reader
+- USB
+    - 1280x720 CCD camera
+    - Thunderbolt 4.0 (left)
+    - USB 3.1 Gen 2 Type-A (left)
+    - USB 3.1 Gen 1 Type-A (right)
+    - USB 2.0 Type-A (right)
+
+## Building coreboot
+
+### Preliminaries
+
+Prior to building coreboot the following files are required:
+* Intel Flash Descriptor file (descriptor.bin)
+* Intel Management Engine firmware (me.bin)
+* ITE Embedded Controller firmware (ec.bin)
+
+The files listed below are optional:
+- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
+
+These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
+
+### Build
+
+The following commands will build a working image:
+
+```bash
+make distclean
+make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_starbook_tgl
+make
+```
+
+## Flashing coreboot
+
+```eval_rst
++---------------------+------------+
+| Type                | Value      |
++=====================+============+
+| Socketed flash      | no         |
++---------------------+------------+
+| Vendor              | Winbond    |
++---------------------+------------+
+| Model               | 25Q128JVSQ |
++---------------------+------------+
+| Size                | 16 MiB     |
++---------------------+------------+
+| Package             | SOIC-8     |
++---------------------+------------+
+| Internal flashing   | yes        |
++---------------------+------------+
+| External flashing   | yes        |
++---------------------+------------+
+
+#### **Requirements:**
+
+* fwupd version 1.5.6 or later
+* The battery must be charged to at least 30%
+* The charger must be connected (either USB-C or DC Jack)
+* BIOS Lock must be disabled
+* Supported Linux distribution (Ubuntu 20.04 +, Linux Mint 20.1 + elementaryOS 6 +, Manjaro 21+)
+
+**fwupd 1.5.6 or later**
+To check the version of **fwupd** you have installed, open a terminal window and enter the below command:
+
+```
+fwupdmgr --version
+```
+
+This will show the version number. **1.5.6** or greater will work.
+![fwupd version](fwupdVersion.png)
+On Ubuntu 20.04, Ubuntu 20.10, Linux Mint 20.1 and elementaryOS 6, fwupd 1.5.6 can be installed from our PPA with the below terminal commands:
+
+```
+sudo add-apt-repository ppa:starlabs/ppa
+sudo apt update
+sudo apt install fwupd
+```
+
+On Manjaro:
+
+```
+sudo pacman -Sy fwupd-git flashrom-starlabs
+```
+
+Instructions for other distributions will be added once fwupd 1.5.6 is available. If you are not using one of the distributions listed above, it is possible to install coreboot using a Live USB.
+
+**Disable BIOS Lock**
+BIOS Lock must be disabled when switching from the standard AMI (American Megatrends Inc.) firmware to coreboot. To disable BIOS Lock:
+
+1\. Start with your LabTop turned off\. Turn it on whilst holding the **F2** key to access the BIOS settings.
+2\. When the BIOS settings load, use the arrow keys to navigate to the **Advanced** tab\. Here you will see **BIOS Lock**\.
+3\. Press `Enter` to change this setting from **Enabled** to **Disabled**
+
+![Disable BIOS Lock](BiosLock.jpg)
+
+4\. Next, press the `F10` key to **Save & Exit** and then `Enter` to confirm.
+
+#### **Switching Branch**
+
+Switching branch refers to changing from AMI firmware to coreboot, or vice versa.
+
+First, check for new firmware files with the below terminal command:
+
+```
+fwupdmgr refresh --force
+```
+
+Then, to change branch, enter the below terminal command:
+
+```
+fwupdmgr switch-branch
+```
+
+You can then select which branch you would like to use, by typing in the corresponding number:
+![Switch Branch](SwitchBranch.png)
+You will be prompted to confirm, press `y` to continue or `n` to cancel.
+
+Once the switch has been completed, you will be prompted to restart.
+
+The next reboot can take up to **5 minutes,** do not interrupt this process or disconnect the charger. Once the reboot is complete, that's it - you'll continue to receive updates for whichever branch you are using.
+
+You can switch branch at any time.

Documentation/releases/coreboot-4.16-relnotes.md

@@ -17,3 +17,10 @@ Significant changes
 -------------------
 
 ### Add significant changes here
+
+### Option to disable Intel Management Engine
+Disable the Intel (CS)Management Engine via HECI based on Intel Core processors
+from Skylake to Alderlake. State is set baed on a cmos value of `me_state`. A
+value of `0` will result in a (CS)ME state of `0` (working) and value of `1`
+will result in a (CS)ME state of `3` (disabled). For an example cmos layout and
+more info, see [cse.c](../../src/soc/intel/common/block/cse/cse.c).

Documentation/releases/index.md

@@ -23,6 +23,11 @@ names etc.
 
 * [checklist](checklist.md)
 
+For release related communications consider using a template so everything
+important is taken care of.
+
+* [templates](templates.md)
+
 Upcoming release
 ----------------
 

Documentation/releases/templates.md

@@ -0,0 +1,83 @@
+# Communication templates related to release management
+
+## Deprecation notices
+
+Deprecation notices are part of release notes to act as a warning: at some
+point in the future some part of coreboot gets removed. That point must be
+at least 6 months after the release of the notice and it must be right after
+some release: That is, the specified release must still contain the part in
+question while one git commit later it might be removed.
+
+The usual reason is progress: Infrastructure module X has been replaced by
+infrastructure module X+1. Removing X helps keep the sources manageable
+and likely opens opportunities to improve the codebase even more.
+Sometimes everything using some module has been converted to its successor
+already and it's natural for such modules to be removed. Even then it might
+be useful to add an entry to the release notes to make everybody aware of
+such a change, for maintainers of incomplete boards that they might keep in
+their local trees and also to give credit to the developers of that change.
+
+However this template isn't about such cases. Sometimes the tree contains
+mainboards that rely on X and can't be easily migrated to X+1, often because
+no active developer has access to these mainboards, and that is where this
+type of deprecation notice comes in:
+
+A deprecation notice shall outline what is being removed, when it is planned
+for removal (always directly _after_ a future release so it remains clear when
+something is part of coreboot and when it isn't anymore) and which devices
+would be affected at the time of writing. Since past deprecation notices have
+been read as "we plan to remove mainboards A, B, and C", sparking outrage
+with the devoted users of A, B, or C, some care is necessary to make clear
+which parts are slated for removal and which parts are merely consequences
+if no action is taken. Or put differently: It should be obvious that besides
+the deprecation plan, there is a call to action to save a couple of devices
+from becoming officially unsupported.
+
+As such, consider the following template when announcing a deprecation:
+
+### The Thing to remove
+
+A short description of the Thing slated for removal.
+
+A short rationale why it's being removed (e.g. new and better Thing exists
+in parallel; new Thing already demonstrated to work in this many releases;
+removing Thing enables this or that improvement)
+
+Timeline: Announced here, Thing will be removed right after the release X
+months out (where X >= 6)
+
+#### Call to action
+
+Removing Thing requires work on a number of (boards, chipsets, …) that didn't
+make the switch yet. The work approximately looks like this: (e.g. pointers to
+commits where a board has been successfully migrated from Thing to new Thing).
+
+Working on migrating away from Thing involves (hardware components, coreboot
+systems, …) 1, 2, and 3. It's difficult to do on the remaining devices because
+...
+
+Parts of the tree that need work to become independent of Thing.
+ - chipset A
+   - board A1
+   - board A2
+ - chipset B
+   - board B1
+
+We prefer to move them along, but if we don't see any maintenance in our tree
+we'll have to assume that there's no more interest in these platforms. As a
+consequence these devices either have to work without Thing by the removal
+date or they will be removed together with Thing. (side note: these removals
+aren't the law, so if there's work in progress to move boards off X and a
+roadmap that makes it probable to succeed, just not within the announced
+deprecation timeline, we can still decide to postpone the actual removal by
+one release. This needn't be put in the release notes themselves though or
+it might encourage people to look for simple escape hatches.)
+
+(If there are developers offering to write patches: )
+There are developers interested in helping move these forward but they can't
+test any changes for lack of equipment. If you have an affected device and
+can run tests on it, please reach out to developers α, β, and γ.
+
+(Otherwise maybe something more generic like this: )
+If you want to take this on, the coreboot developer community will try to
+help you: Reach out through one of our [forums](../community/forums.md).

Documentation/tutorial/part2.md

@@ -12,37 +12,24 @@ 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).
 
-## Step 2a: Set up RSA Private/Public Key
+## Step 2a: Set up SSH keys
 
 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 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
-frequently uploading changes.
-
-If you instead prefer to have review.coreboot.org specific instructions,
-follow the steps below. Note that this particular section may have the
-most up-to-date instructions.
-
-If you do not have an RSA key set up on your account already (as is the case
+If you do not have an SSH key set up on your account already (as is the case
 with a newly created account), follow the instructions below; otherwise,
 doing so could overwrite an existing key.
 
-In the upper right corner, select your name and click on **Settings**.
-Select **SSH Public Keys** on the left-hand side.
-
-In a terminal, run `ssh-keygen` and confirm the default path `.ssh/id_rsa`.
+In a terminal, run `ssh-keygen -t ed25519` and confirm the default path
+`.ssh/id_ed25519`.
 
 Make a passphrase -- remember this phrase. It will be needed whenever you use
-this RSA Public Key. **Note:** You might want to use a short password, or
+this public key. **Note:** You might want to use a short password, or
 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.
+Copy the content of `.ssh/id_ed25519.pub` (notice the ".pub" suffix
+as you need to send the public key) into the textbox "New SSH Key" at
+https://review.coreboot.org/settings/#SSHKeys and save it.
 
 ## Step 2b: Set up an HTTP Password
 
@@ -173,7 +160,9 @@ When you are done with your commit, run `git push` to push your commit to
 coreboot.org. **Note:** To submit as a private patch, use
 `git push origin HEAD:refs/for/master%private`. Submitting as a private patch
 means that your commit will be on review.coreboot.org, but is only visible to
-yourself and those you add as reviewers.
+yourself and those you add as reviewers. This mode isn't perfect: Somebody who
+knows the commit ID can still fetch the change and everything it refers (e.g.
+parent commits).
 
 This has been a quick primer on how to submit a change to Gerrit for review
 using git. You may wish to review the [Gerrit code review workflow