WIP: lemp9 vboot support

Change-Id: I47fbc95a8bd242b4261f5fc52b073f0b2b6ab080

.checkpatch.conf

@@ -20,8 +20,6 @@
 --ignore SPDX_LICENSE_TAG
 --ignore UNDOCUMENTED_DT_STRING
 --ignore PRINTK_WITHOUT_KERN_LEVEL
---ignore ASSIGN_IN_IF
---ignore UNNECESSARY_ELSE
 
 # FILE_PATH_CHANGES seems to not be working correctly. It will
 # choke on added / deleted files even if the MAINTAINERS file
@@ -32,8 +30,5 @@
 # some commits unnecessarily.
 --ignore EXECUTE_PERMISSIONS
 
-# Exclude vendorcode directories that don't follow coreboot's coding style.
---exclude src/vendorcode/amd
---exclude src/vendorcode/cavium
---exclude src/vendorcode/intel
---exclude src/vendorcode/mediatek
+# Exclude the vendorcode directory
+--exclude src/vendorcode

.gitignore

@@ -1,3 +1,6 @@
+payloads/libpayload/install/
+payloads/nvramcui/build
+payloads/nvramcui/libpayload
 junit.xml
 abuild*.xml
 .config
@@ -8,8 +11,46 @@ defconfig
 .ccwrap
 build/
 coreboot-builds/
-coreboot-builds*/
-
+payloads/coreinfo/lpbuild/
+payloads/coreinfo/lp.config*
+payloads/external/depthcharge/depthcharge/
+payloads/external/FILO/filo/
+payloads/external/GRUB2/grub2/
+payloads/external/LinuxBoot/linuxboot/
+payloads/external/SeaBIOS/seabios/
+payloads/external/tianocore/tianocore/
+payloads/external/tint/tint/
+payloads/external/U-Boot/u-boot/
+payloads/external/Memtest86Plus/memtest86plus/
+payloads/external/iPXE/ipxe/
+util/crossgcc/acpica-unix-*/
+util/crossgcc/binutils-*/
+util/crossgcc/build-*BINUTILS/
+util/crossgcc/build-*EXPAT/
+util/crossgcc/build-*GCC/
+util/crossgcc/build-*GDB/
+util/crossgcc/build-*GMP/
+util/crossgcc/build-*LIBELF/
+util/crossgcc/build-*MPC/
+util/crossgcc/build-*MPFR/
+util/crossgcc/build-*PYTHON/
+util/crossgcc/build-*LVM/
+util/crossgcc/build-*IASL/
+util/crossgcc/expat-*/
+util/crossgcc/gcc-*/
+util/crossgcc/gdb-*/
+util/crossgcc/gmp-*/
+util/crossgcc/libelf-*/
+util/crossgcc/mingwrt-*/
+util/crossgcc/mpc-*/
+util/crossgcc/mpfr-*/
+util/crossgcc/Python-*/
+util/crossgcc/*.src/
+util/crossgcc/tarballs/
+util/crossgcc/w32api-*/
+util/crossgcc/xgcc/
+util/crossgcc/xgcc-*/
+util/crossgcc/xgcc
 site-local
 
 *.\#
@@ -18,15 +59,13 @@ site-local
 *.debug
 !Kconfig.debug
 *.elf
-*.fd
 *.o
 *.o.d
 *.out
 *.pyc
 *.sw[po]
 /*.rom
-.test
-.dependencies
+coreboot-builds*/
 
 # Development friendly files
 tags
@@ -36,9 +75,61 @@ tags
 xgcc/
 tarballs/
 
-# editor backup files, temporary files, IDE project files
+#
+# KDE editors create lots of backup files whenever
+# a file is edited, so just ignore them
 *~
 *.kate-swp
+# Ignore Kdevelop project file
 *.kdev4
 
+util/*/.dependencies
+util/*/.test
+util/amdfwtool/amdfwtool
+util/archive/archive
+util/bincfg/bincfg
+util/board_status/board-status
+util/bucts/bucts
+util/cbfstool/cbfs-compression-tool
+util/cbfstool/cbfstool
+util/cbfstool/fmaptool
+util/cbfstool/ifwitool
+util/cbfstool/rmodtool
+util/cbmem/.dependencies
+util/cbmem/cbmem
+util/dumpmmcr/dumpmmcr
+util/ectool/ectool
+util/futility/futility
+util/genprof/genprof
+util/getpir/getpir
+util/ifdtool/ifdtool
+util/intelmetool/intelmetool
+util/inteltool/.dependencies
+util/inteltool/inteltool
+util/intelvbttool/intelvbttool
+util/k8resdump/k8resdump
+util/lbtdump/lbtdump
+util/mptable/mptable
+util/msrtool/Makefile
+util/msrtool/Makefile.deps
+util/msrtool/msrtool
+util/nvramtool/.dependencies
+util/nvramtool/nvramtool
+util/optionlist/Options.wiki
+util/pmh7tool/pmh7tool
+util/runfw/googlesnow
+util/superiotool/superiotool
+util/vgabios/testbios
+util/autoport/autoport
+util/kbc1126/kbc1126_ec_dump
+util/kbc1126/kbc1126_ec_insert
+
+Documentation/*.aux
+Documentation/*.idx
+Documentation/*.log
+Documentation/*.toc
+Documentation/*.out
+Documentation/*.pdf
+Documentation/_build
+
 doxygen/*

.gitmodules

@@ -1,61 +1,53 @@
 [submodule "3rdparty/blobs"]
 	path = 3rdparty/blobs
-	url = ../blobs.git
+	url = https://review.coreboot.org/blobs.git
 	update = none
 	ignore = dirty
 [submodule "util/nvidia-cbootimage"]
 	path = util/nvidia/cbootimage
-	url = ../nvidia-cbootimage.git
+	url = https://review.coreboot.org/nvidia-cbootimage.git
 [submodule "vboot"]
 	path = 3rdparty/vboot
-	url = ../vboot.git
-	branch = main
+	url = https://review.coreboot.org/vboot.git
 [submodule "arm-trusted-firmware"]
 	path = 3rdparty/arm-trusted-firmware
-	url = ../arm-trusted-firmware.git
+	url = https://review.coreboot.org/arm-trusted-firmware.git
 [submodule "3rdparty/chromeec"]
 	path = 3rdparty/chromeec
-	url = ../chrome-ec.git
+	url = https://review.coreboot.org/chrome-ec.git
 [submodule "libhwbase"]
 	path = 3rdparty/libhwbase
-	url = ../libhwbase.git
+	url = https://review.coreboot.org/libhwbase.git
 [submodule "libgfxinit"]
 	path = 3rdparty/libgfxinit
-	url = ../libgfxinit.git
+	url = https://review.coreboot.org/libgfxinit.git
 [submodule "3rdparty/fsp"]
 	path = 3rdparty/fsp
-	url = ../fsp.git
+	url = https://review.coreboot.org/fsp.git
 	update = none
 	ignore = dirty
 [submodule "opensbi"]
 	path = 3rdparty/opensbi
-	url = ../opensbi.git
+	url = https://review.coreboot.org/opensbi.git
 [submodule "intel-microcode"]
 	path = 3rdparty/intel-microcode
-	url = ../intel-microcode.git
+	url = https://review.coreboot.org/intel-microcode.git
 	update = none
 	ignore = dirty
 [submodule "3rdparty/ffs"]
 	path = 3rdparty/ffs
-	url = ../ffs.git
+	url = https://review.coreboot.org/ffs.git
 [submodule "3rdparty/amd_blobs"]
 	path = 3rdparty/amd_blobs
-	url = ../amd_blobs
+	url = https://review.coreboot.org/amd_blobs.git
 	update = none
 	ignore = dirty
 [submodule "3rdparty/cmocka"]
 	path = 3rdparty/cmocka
-	url = ../cmocka.git
+	url = https://review.coreboot.org/cmocka.git
 	update = none
 [submodule "3rdparty/qc_blobs"]
 	path = 3rdparty/qc_blobs
-	url = ../qc_blobs.git
+	url = https://review.coreboot.org/qc_blobs.git
 	update = none
 	ignore = dirty
-[submodule "3rdparty/intel-sec-tools"]
-	path = 3rdparty/intel-sec-tools
-	url = ../9esec-security-tooling.git
-[submodule "3rdparty/stm"]
-	path = 3rdparty/stm
-	url = ../STM
-	branch = stmpe

Documentation/.gitignore

@@ -1,7 +0,0 @@
-*.aux
-*.idx
-*.log
-*.toc
-*.out
-*.pdf
-_build

Documentation/RFC/intel-gpio-cleanup.md

@@ -1,98 +0,0 @@
-# Background
-
-CB:31250 ("soc/intel/cannonlake: Configure GPIOs again after FSP-S is
-done") introduced a workaround in coreboot for `soc/intel/cannonlake`
-platforms to save and restore GPIO configuration performed by
-mainboard across call to FSP Silicon Init (FSP-S). This workaround was
-required because FSP-S was configuring GPIOs differently than
-mainboard resulting in boot and runtime issues because of
-misconfigured GPIOs. This issue was observed on `google/hatch`
-mainboard and was raised with Intel to get the FSP behavior
-fixed. Until the fix in FSP was available, this workaround was used to
-ensure that the mainboards can operate correctly and were not impacted
-by the GPIO misconfiguration in FSP-S.
-
-The issues observed on `google/hatch` mainboard were fixed by adding
-(if required) and initializing appropriate FSP UPDs. This UPD
-initialization ensured that FSP did not configure any GPIOs
-differently than the mainboard configuration. Fixes included:
- * CB:31375 ("soc/intel/cannonlake: Configure serial debug uart")
- * CB:31520 ("soc/intel/cannonlake: Assign FSP UPDs for HPD and Data/CLK of DDI ports")
- * CB:32176 ("mb/google/hatch: Update GPIO settings for SD card and SPI1 Chip select")
- * CB:34900 ("soc/intel/cnl: Add provision to configure SD controller write protect pin")
-
-With the above changes merged, it was verified on `google/hatch`
-mainboard that the workaround for GPIO reconfiguration was not
-needed. However, at the time, we missed dropping the workaround in
-'soc/intel/cannonlake`. Currently, this workaround is used by the
-following mainboards:
- * `google/drallion`
- * `google/sarien`
- * `purism/librem_cnl`
- * `system76/lemp9`
-
-As verified on `google/hatch`, FSP v1263 included all UPD additions
-that were required for addressing this issue.
-
-# Proposal
-
-* The workaround can be safely dropped from `soc/intel/cannonlake`
-  only after the above mainboards have verified that FSP-S does not
-  configure any pads differently than the mainboard in coreboot. Since
-  the fix included initialization of FSP UPDs correctly, the above
-  mainboards can use the following diff to check what pads change
-  after FSP-S has run:
-
-```
-diff --git a/src/soc/intel/common/block/gpio/gpio.c b/src/soc/intel/common/block/gpio/gpio.c
-index 28e78fb366..0cce41b316 100644
---- a/src/soc/intel/common/block/gpio/gpio.c
-+++ b/src/soc/intel/common/block/gpio/gpio.c
-@@ -303,10 +303,10 @@ static void gpio_configure_pad(const struct pad_config *cfg)
-                /* Patch GPIO settings for SoC specifically */
-                soc_pad_conf = soc_gpio_pad_config_fixup(cfg, i, soc_pad_conf);
- 
--               if (CONFIG(DEBUG_GPIO))
-+               if (soc_pad_conf != pad_conf)
-                        printk(BIOS_DEBUG,
--                       "gpio_padcfg [0x%02x, %02zd] DW%d [0x%08x : 0x%08x"
--                       " : 0x%08x]\n",
-+                       "%d: gpio_padcfg [0x%02x, %02zd] DW%d [0x%08x : 0x%08x"
-+                       " : 0x%08x]\n", cfg->pad,
-                        comm->port, relative_pad_in_comm(comm, cfg->pad), i,
-                        pad_conf,/* old value */
-                        cfg->pad_config[i],/* value passed from gpio table */
-```
-
-Depending upon the pads that are misconfigured by FSP-S, these
-mainboards will have to set UPDs appropriately. Once this is verified
-by the above mainboards, the workaround implemented in CB:31250 can be
-dropped.
-
-* The fix implemented in FSP/coreboot for `soc/intel/cannonlake`
-  platforms is not really the right long term solution for the
-  problem. Ideally, FSP should not be touching any GPIO configuration
-  and letting coreboot configure the pads as per mainboard
-  design. This recommendation was accepted and implemented by Intel
-  starting with Jasper Lake and Tiger Lake platforms using a single
-  UPD `GpioOverride` that coreboot can set so that FSP does not change
-  any GPIO configuration. However, this implementation is not
-  backported to any older platforms. Given the issues that we have
-  observed across different platforms, the second proposal is to:
-
-  - Add a Kconfig `CHECK_GPIO_CONFIG_CHANGES` that enables checks
-    in coreboot to stash GPIO pad configuration before various calls
-    to FSP and compares the configuration on return from FSP.
-  - This will have to be implemented as part of
-    drivers/intel/fsp/fsp2_0/ to check for the above config selection
-    and make callbacks `gpio_snapshot()` and `gpio_verify_snapshot()`
-    to identify and print information about pads that have changed
-    configuration after calls to FSP.
-  - This config can be kept disabled by default and mainboard
-    developers can enable them as and when required for debug.
-  - This will be helpful not just for the `soc/intel/cannonlake`
-    platforms that want to get rid of the above workaround, but also
-    for all future platforms using FSP to identify and catch any GPIO
-    misconfigurations that might slip in to any platforms (in case the
-    `GpioOverride` UPD is not honored by any code path within FSP).
-

Documentation/acpi/devicetree.md

@@ -30,7 +30,7 @@ device pci 15.0 on
 	chip drivers/i2c/generic
 		register "hid" = ""ELAN0000""
 		register "desc" = ""ELAN Touchpad""
-		register "irq" = "ACPI_IRQ_WAKE_LEVEL_LOW(GPP_A21_IRQ)"
+		register "irq" = "ACPI_IRQ_WAKE_EDGE_LOW(GPP_A21_IRQ)"
 		register "wake" = "GPE0_DW0_21"
 		device i2c 15 on end
 	end
@@ -60,12 +60,12 @@ Scope (\_SB.PCI0.I2C0)
             I2cSerialBusV2 (0x0015, ControllerInitiated, 400000,
                 AddressingMode7Bit, "\\_SB.PCI0.I2C0",
                 0x00, ResourceConsumer, , Exclusive, )
-            Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake, ,, )
+            Interrupt (ResourceConsumer, Edge, ActiveLow, ExclusiveAndWake, ,, )
             {
                 0x0000002D,
             }
         })
-        Name (_S0W, ACPI_DEVICE_SLEEP_D3_HOT)  // _S0W: S0 Device Wake State
+        Name (_S0W, 0x04)  // _S0W: S0 Device Wake State
         Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
         {
             0x15, // GPE #21
@@ -136,7 +136,7 @@ corresponds to **const char *desc** and in ASL:
 It also adds the interrupt,
 
 ```
-    Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake, ,, )
+    Interrupt (ResourceConsumer, Edge, ActiveLow, ExclusiveAndWake, ,, )
     {
         0x0000002D,
     }
@@ -145,15 +145,15 @@ It also adds the interrupt,
 which comes from:
 
 ```
-    register "irq" = "ACPI_IRQ_WAKE_LEVEL_LOW(GPP_A21_IRQ)"
+    register "irq" = "ACPI_IRQ_WAKE_EDGE_LOW(GPP_A21_IRQ)"
 ```
 
-The GPIO pin IRQ settings control the "Level", "ActiveLow", and
-"ExclusiveAndWake" settings seen above (level means it is a level-triggered
-interrupt as opposed to edge-triggered; active low means the interrupt is
-triggered when the signal is low).
+The GPIO pin IRQ settings control the "Edge", "ActiveLow", and
+"ExclusiveAndWake" settings seen above (edge means it is an edge-triggered
+interrupt as opposed to level-triggered; active low means the interrupt is
+triggered on a falling edge).
 
-Note that the ACPI_IRQ_WAKE_LEVEL_LOW macro informs the platform that the GPIO
+Note that the ACPI_IRQ_WAKE_EDGE_LOW macro informs the platform that the GPIO
 will be routed through SCI (ACPI's System Control Interrupt) for use as a wake
 source.  Also note that the IRQ names are SoC-specific, and you will need to
 find the names in your SoC's header file.  The ACPI_* macros are defined in
@@ -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 ACPI_DEVICE_SLEEP_D3_HOT, representing _D3hot_.
+which in this case is 4, representing _D3cold_.
 
 ### _PRW (Power Resources for Wake)
 _PRW indicates the power resources and events required for wake.  There are no

Documentation/acpi/gpio.md

@@ -159,6 +159,7 @@ for the GPIO.
 	 */
 	acpigen_write_if_and(Local5, TX_BIT);
 	acpigen_write_store_args(ONE_OP, LOCAL0_OP);
+	acpigen_pop_len();
 	acpigen_write_else();
 	acpigen_write_store_args(ZERO_OP, LOCAL0_OP);
 	acpigen_pop_len();

Documentation/arch/x86/index.md

@@ -5,21 +5,18 @@ This section contains documentation about coreboot on x86 architecture.
 * [x86 PAE support](pae.md)
 
 ## State of x86_64 support
-At the moment there's only experimental x86_64 support.
-The `emulation/qemu-i440fx` and `emulation/qemu-q35` boards do support
-*ARCH_RAMSTAGE_X86_64* , *ARCH_POSTCAR_X86_64* and *ARCH_ROMSTAGE_X86_64*.
+At the moment there's no single board that supports x86_64 or to be exact
+`ARCH_RAMSTAGE_X86_64` and `ARCH_ROMSTAGE_X86_64`.
 
-In order to add support for x86_64 the following assumptions were made:
+In order to add support for x86_64 the following assumptions are made:
 * The CPU supports long mode
 * All memory returned by malloc must be below 4GiB in physical memory
 * All code that is to be run must be below 4GiB in physical memory
 * The high dword of pointers is always zero
 * The reference implementation is qemu
 * The CPU supports 1GiB hugepages
-* x86 payloads are loaded below 4GiB in physical memory and are jumped
-  to in *protected mode*
 
-## Assumptions for all stages using the reference implementation
+## Assuptions for all stages using the reference implementation
 * 0-4GiB are identity mapped using 2MiB-pages as WB
 * Memory above 4GiB isn't accessible
 * page tables reside in memory mapped ROM
@@ -40,16 +37,18 @@ The page tables contains the following structure:
 
 At the moment *$n* is 4, which results in identity mapping the lower 4 GiB.
 
-## Basic x86_64 support
-Basic support for x86_64 has been implemented for QEMU mainboard target.
-
-## Reference implementation
-The reference implementation is
-* [QEMU i440fx](../../mainboard/emulation/qemu-i440fx.md)
-* [QEMU Q35](../../mainboard/emulation/qemu-q35.md)
-
-## TODO
-* Identity map memory above 4GiB in ramstage
+## Steps to add basic support for x86_64
+* Add x86_64 toolchain support - *DONE*
+* Fix compilation errors - *DONE*
+* Fix linker errors - *TODO*
+* Add x86_64 rmodule support - *DONE*
+* Add x86_64 exception handlers - *DONE*
+* Setup page tables for long mode - *DONE*
+* Add assembly code for long mode - *DONE*
+* Add assembly code for SMM - *DONE*
+* Add assembly code for postcar stage - *TODO*
+* Add assembly code to return to protected mode - *TODO*
+* Implement reference code for mainboard `emulation/qemu-q35` - *TODO*
 
 ## Future work
 
@@ -65,33 +64,3 @@ The reference implementation is
 * Test how well CAR works with x86_64 and paging
 * Improve mode switches
 * Test libgfxinit / VGA Option ROMs / FSP
-
-## Known bugs on real hardware
-
-According to Intel x86_64 mode hasn't been validated in CAR environments.
-Until now it could be verified on various Intel platforms and no issues have
-been found.
-
-## Known bugs on KVM enabled qemu
-
-The `x86_64` reference code runs fine in qemu soft-cpu, but has serious issues
-when using KVM mode on some machines. The workaround is to *not* place
-page-tables in ROM, as done in
-[CB:49228](https://review.coreboot.org/c/coreboot/+/49228).
-
-Here's a list of known issues:
-
-* After entering long mode, the FPU doesn't work anymore, including accessing
-  MMX registers. It works fine before entering long mode. It works fine when
-  switching back to protected mode. Other registers, like SSE registers, are
-  working fine.
-* Reading from virtual memory, when the page tables are stored in ROM, causes
-  the MMU to abort the "page table walking" mechanism when the lower address
-  bits of the virtual address to be translated have a specific pattern.
-  Instead of loading the correct physical page, the one containing the
-  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.
-* Entering long mode crashes on AMD host platforms.

Documentation/cbfstool/index.md

@@ -1,5 +0,0 @@
-# cbfstool
-
-Contents:
-
-* [Handling memory mapped boot media](mmap_windows.md)

Documentation/cbfstool/mmap_windows.md

@@ -1,77 +0,0 @@
-# cbfstool: Handling memory mapped boot media
-
-`cbfstool` is a utility used for managing coreboot file system (CBFS)
-components in a ROM image. x86 platforms are special since they have
-the SPI flash boot media memory mapped into host address space at
-runtime. This requires `cbfstool` to deal with two separate address
-spaces for any CBFS components that are eXecute-In-Place (XIP) - one
-is the SPI flash address space and other is the host address space
-where the SPI flash gets mapped.
-
-By default, all x86 platforms map a maximum of 16MiB of SPI flash at
-the top of 4G in host address space. If the flash is greater than
-16MiB, then only the top 16MiB of the flash is mapped in the host
-address space. If the flash is smaller than 16MiB, then the entire SPI
-flash is mapped at the top of 4G and the rest of the space remains
-unused.
-
-In more recent platforms like Tiger Lake (TGL), it is possible to map
-more than 16MiB of SPI flash. Since the host address space has legacy
-fixed device addresses mapped below `4G - 16M`, the SPI flash is split
-into separate windows when being mapped to the host address space.
-Default decode window of maximum 16MiB size still lives just below the
-4G boundary. The additional decode window is free to live in any
-available MMIO space that the SoC chooses.
-
-Following diagram shows different combinations of SPI flash being
-mapped into host address space when using multiple windows:
-
-![MMAP window combinations with different flash sizes][mmap_windows]
-
-*(a) SPI flash of size 16MiB (b) SPI flash smaller than 16MiB (c) SPI flash
-of size (16MiB+ext window size) (d) SPI flash smaller than (16MiB+ext
-window size)*
-
-The location of standard decode window is fixed in host address space
-`(4G - 16M) to 4G`. However, the platform is free to choose where the
-extended window lives in the host address space. Since `cbfstool`
-needs to know the exact location of the extended window, it allows the
-platform to pass in two parameters `ext-win-base` and `ext-win-size`
-that provide the base and the size of the extended window in host
-address space.
-
-`cbfstool` creates two memory map windows using the knowledge about the
-standard decode window and the information passed in by the platform
-about the extended decode window. These windows are useful in
-converting addresses from one space to another (flash space and host
-space) when dealing with XIP components.
-
-## Assumptions
-
-1. Top 16MiB is still decoded in the fixed decode window just below 4G
-   boundary.
-1. Rest of the SPI flash below the top 16MiB is mapped at the top of
-   the extended window. Even though the platform might support a
-   larger extended window, the SPI flash part used by the mainboard
-   might not be large enough to be mapped in the entire window. In
-   such cases, the mapping is assumed to be in the top part of the
-   extended window with the bottom part remaining unused.
-
-## Example
-
-If the platform supports extended window and the SPI flash size is
-greater, then `cbfstool` creates a mapping for the extended window as
-well.
-
-```
-ext_win_base = 0xF8000000
-ext_win_size = 32 * MiB
-ext_win_limit = ext_win_base + ext_win_size - 1 = 0xF9FFFFFF
-```
-
-If SPI flash is 32MiB, then top 16MiB is mapped from `0xFF000000 -
-0xFFFFFFFF` whereas the bottom 16MiB is mapped from `0xF9000000 -
-0xF9FFFFFF`. The extended window `0xF8000000 - 0xF8FFFFFF` remains
-unused.
-
-[mmap_windows]: mmap_windows.svg

Documentation/coding_style.md

@@ -5,26 +5,12 @@ 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)
 
-The guidelines in this file should be seen as a strong suggestion, and
-should overrule personal preference. But they may be ignored in
-individual instances when there are good practical reasons to do so, and
-reviewers are in agreement.
+Please at least consider the points made here.
 
-Any style questions that are not mentioned in here should be decided
-between the author and reviewers on a case-by-case basis. When modifying
-existing files, authors should try to match the prevalent style in that
-file -- otherwise, they should try to match similar existing files in
-coreboot.
+First off, I'd suggest printing out a copy of the GNU coding standards,
+and NOT read it. Burn them, it's a great symbolic gesture.
 
-Bulk style changes to existing code ("cleanup patches") should avoid
-changing existing style choices unless they actually violate this style
-guide, or there is broad consensus that the new version is an
-improvement. By default the style choices of the original author should
-be honored. (Note that `checkpatch.pl` is not part of this style guide,
-and neither is `clang-format`. These tools can be useful to find
-potential issues or simplify formatting in new submissions, but they
-were not designed to directly match this guide and may have false
-positives. They should not be bulk-applied to change existing code.)
+Anyway, here goes:
 
 ## Indentation
 
@@ -544,7 +530,7 @@ than desirable (in fact, they are worse than random typing - an infinite
 number of monkeys typing into GNU emacs would never make a good program).
 
 So, you can either get rid of GNU emacs, or change it to use saner values.
-To do the latter, you can stick the following in your .emacs file:
+To do the latter, you can stick the following in your .emacs file: 
 
 ```lisp
 (defun c-lineup-arglist-tabs-only (ignored)
@@ -848,53 +834,22 @@ subject to this rule. Generally they indicate failure by returning some
 out-of-range result. Typical examples would be functions that return
 pointers; they use NULL or the ERR_PTR mechanism to report failure.
 
-Headers and includes
----------------
+Don't re-invent the kernel macros
+----------------------------------
 
-Headers should always be included at the top of the file. Includes should
-always use the `#include <file.h>` notation, except for rare cases where a file
-in the same directory that is not part of a normal include path gets included
-(e.g. local headers in mainboard directories), which should use `#include
-"file.h"`. Local "file.h" includes should always come separately after all
-<file.h> includes.  Headers that can be included from both assembly files and
-.c files should keep all C code wrapped in `#ifndef __ASSEMBLER__` blocks,
-including includes to other headers that don't follow that provision. Where a
-specific include order is required for technical reasons, it should be clearly
-documented with comments.
-
-Files should generally include every header they need a definition from
-directly (and not include any unnecessary extra headers). Excepted from
-this are certain headers that intentionally chain-include other headers
-which logically belong to them and are just factored out into a separate
-location for implementation or organizatory reasons. This could be
-because part of the definitions is generic and part SoC-specific (e.g.
-`<gpio.h>` chain-including `<soc/gpio.h>`), architecture-specific (e.g.
-`<device/mmio.h>` chain-including `<arch/mmio.h>`), separated out into
-commonlib[/bsd] for sharing/license reasons (e.g. `<cbfs.h>`
-chain-including `<commonlib/bsd/cbfs_serialized.h>`) or just split out
-to make organizing subunits of a larger header easier. This can also
-happen when certain definitions need to be in a specific header for
-legacy POSIX reasons but we would like to logically group them together
-(e.g. `uintptr_t` is in `<stdint.h>` and `size_t` in `<stddef.h>`, but
-it's nicer to be able to just include `<types.h>` and get all the common
-type and helper function stuff we need everywhere).
-
-The headers `<kconfig.h>`, `<rules.h>` and `<commonlib/bsd/compiler.h>`
-are always automatically included in all compilation units by the build
-system and should not be included manually.
-
-Don't re-invent common macros
------------------------------
-
-The header file `src/commonlib/bsd/include/commonlib/bsd/helpers.h`
-contains a number of macros that you should use, rather than explicitly
-coding some variant of them yourself. For example, if you need to
-calculate the length of an array, take advantage of the macro
+The header file include/linux/kernel.h contains a number of macros that
+you should use, rather than explicitly coding some variant of them
+yourself. For example, if you need to calculate the length of an array,
+take advantage of the macro
 
 ```c
 #define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
 ```
 
+There are also min() and max() macros that do strict type checking if
+you need them. Feel free to peruse that header file to see what else is
+already defined that you shouldn't reproduce in your code.
+
 Editor modelines and other cruft
 --------------------------------
 

Documentation/community/forums.md

@@ -16,20 +16,3 @@ read its
 We also have a
 [real time chat](https://webchat.freenode.net?channels=%23coreboot)
 on the Freenode IRC network's #coreboot channel.
-
-## Fortnightly coreboot leadership meeting
-
-There's a leadership meeting held every 14 days (currently every other
-Wednesday at 10am Pacific Time, usually 18:00 UTC with some deviation
-possible due to daylight saving time related shifts). The meeting
-is open to everyone and provides a forum to discuss general coreboot
-topics, including community and technical matters that benefit from
-an official decision.
-
-We tried a whole lot of different tools, but so far the meetings worked
-best with [Google Meet](https://meet.google.com/syn-toap-agu),
-using [Google Docs](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit)
-for the agenda and meeting minutes. Neither the video conference nor
-the document require a Google account to participate, although editing
-access to the document is limited to adding comments - any desired
-agenda item added that way will be approved in time before the meeting.

Documentation/community/language_style.md

@@ -1,136 +0,0 @@
-# Language style
-
-Following our [Code of Conduct](code_of_conduct.md) the project aims to
-be a space where people are considerate in natural language communication:
-
-There are terms in computing that were probably considered benign when
-introduced but are uncomfortable to some. The project aims to de-emphasize
-such terms in favor of alternatives that are at least as expressive -
-but often manage to be even more descriptive.
-
-## Political Correctness
-
-A common thread in discussions was that the project merely follows some
-fad, or that this is a "political correctness" measure, designed to please
-one particular "team". While the project doesn't exist in a vacuum and
-so there are outside influences on project members, the proposal wasn't
-made with the purpose of demonstrating allegiance to any given cause -
-except one:
-
-There are people who feel uncomfortable with some terms being used,
-_especially_ when that use takes them out of their grave context
-(e.g. slave when discussing slavery) and applies them to a rather benign
-topic (e.g. coordination of multiple technical systems), taking away
-the gravity of the term.
-
-That gets especially jarring when people aren't exposed to such terms
-in abstract sociological discussions but when they stand for real issues
-they encountered.
-
-When having to choose between using a well-established term that
-affects people negatively who could otherwise contribute more happily
-and undisturbed or an alternative just-as-good term that doesn't, the
-decision should be simple.
-
-## Token gesture
-
-The other major point of contention is that such decisions are a token
-gesture that doesn't change anything. It's true: No slave is freed
-because coreboot rejects the use of the word.
-
-coreboot is ambitious enough as-is, in that the project offers
-an alternative approach to firmware, sometimes against the vested
-interests (and deep pockets) of the leaders of a multi-billion dollar
-industry. Changing the preferred vocabulary isn't another attempt at
-changing the world, it's one thing we do to try to make coreboot (and
-coreboot only) a comfortable environment for everybody.
-
-## For everybody
-
-For everybody, but with a qualifier: We have certain community etiquette,
-and we define some behavior we don't accept in our community, both
-detailed in the Code of Conduct.
-
-Other than that, we're trying to accommodate people: The CoC lays out
-that language should be interpreted as friendly by default, and to be
-graceful in light of accidents. This also applies to the use of terms
-that the project tries to avoid: The consequence of the use of such
-terms (unless obviously employed to provoke a reaction - in that case,
-please contact the arbitration team as outlined in the Code of Conduct)
-should be a friendly reminder. The project is slow to sanction and that
-won't change just because the wrong kind of words is used.
-
-## Interfacing with the world
-
-The project doesn't exist in a vacuum, and that also applies to the choice
-of words made by other initiatives in low-level technology. When JEDEC
-calls the participants of a SPI transaction "master" and "slave", there's
-little we can do about that. We _could_ decide to use different terms,
-but that wouldn't make things easier but harder, because such a deliberate
-departure means that the original terms (and their original use) gain
-lots of visibility every time (so there's no practical advantage) while
-adding confusion, and therefore even more attention, to that situation.
-
-Sometimes there are abbreviations that can be used as substitutes,
-and in that case the recommendation is to do that.
-
-As terms that we found to be best avoided are replaced in such
-initiatives, we can follow up. Members of the community with leverage
-in such organizations are encouraged to raise the concern there.
-
-## Dealing with uses
-
-There are existing uses in our documentation and code. When we decide to
-retire a term that doesn't mean that everybody is supposed to stop doing
-whatever they're doing and spend their time on purging terms. Instead,
-ongoing development should look for alternatives (and so this could come
-up in review).
-
-People can go through existing code and docs and sort out older instances,
-and while that's encouraged it's no "stop the world" event. Changes
-in flight in review may still be merged with such terms intact, but if
-there's more work required for other reasons, we'd encourage moving away
-from such terms.
-
-This document has a section on retired terms, presenting the rationale
-as well as alternative terms that could be used instead. The main goal is
-to be expressive: There's no point in just picking any alternative term,
-choose something that explains the purpose well.
-
-As mentioned, missteps will happen. Point them out, but assume no ill
-intent for as long as you can manage.
-
-## Discussing words to remove from active use
-
-There ought to be some process when terminology is brought up as a
-negative to avoid. Do not to tell people that "they're feeling wrong"
-when they have a negative reaction to certain terms, but also try to
-avoid being offended for the sake of others.
-
-When bringing up a term, on the project's mailing list or, if you don't
-feel safe doing that, by contacting the arbitration team, explain what's
-wrong with the term and offer alternatives for uses within coreboot.
-
-With a term under discussion, see if there's particular value for us to
-continue using the term (maybe in limited situations, like continuing
-to use "slave" in SPI related code).
-
-Once the arbitration team considers the topic discussed completely and
-found a consensus, it will present a decision in a leadership meeting. It
-should explain why a term should or should not be used and in the latter
-case offer alternatives. These decisions shall then be added to this
-document.
-
-## Retired terminology
-
-### slave
-
-Replacing this term for something else had the highest approval rating
-in early discussions, so it seems pretty universally considered a bad
-choice and therefore should be avoided where possible.
-
-An exception is made where it's a term used in current standards and data
-sheets: Trying to "hide" the term in such cases only puts a spotlight
-on it every time code and data sheet are compared.
-
-Alternatives: subordinate, secondary, follower

Documentation/conf.py

@@ -48,7 +48,7 @@ try:
 except ImportError:
     print("Error: Please install sphinxcontrib.ditaa for ASCII art conversion\n")
 else:
-    extensions += ['sphinxcontrib.ditaa']
+    extensions += 'sphinxcontrib.ditaa'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

Documentation/drivers/index.md

@@ -4,9 +4,6 @@ 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.
 
-* [Intel DPTF](dptf.md)
 * [IPMI KCS](ipmi_kcs.md)
 * [SMMSTORE](smmstore.md)
 * [SoundWire](soundwire.md)
-* [SMMSTOREv2](smmstorev2.md)
-* [USB4 Retimer](retimer.md)

Documentation/drivers/retimer.md

@@ -1,40 +0,0 @@
-# USB4 Retimers
-
-# Introduction
-As USB speeds continue to increase (up to 5G, 10G, and even 20G or higher in
-newer revisions of the spec), it becomes more difficult to maintain signal
-integrity for longer traces. Devices such as retimers and redrivers can be used
-to help signals maintain their integrity over long distances.
-
-A redriver is a device that boosts the high-frequency content of a signal in
-order to compensate for the attenuation typically caused by travelling through
-various circuit components (PCB, connectors, CPU, etc.). Redrivers are not
-protocol-aware, which makes them relatively simple. However, their effectiveness
-is limited, and may not work at all in some scenarios.
-
-A retimer is a device that retransmits a fresh copy of the signal it receives,
-by doing CDR and retransmitting the data (i.e., it is protocol-aware). Since
-this is a digital component, it may have firmware.
-
-
-# Driver Usage
-
-Some operating systems may have the ability to update firmware on USB4 retimers,
-and ultimately will need some way to power the device on and off so that its new
-firmware can be loaded. This is achieved by providing a GPIO signal that can be
-used for this purpose; its active state must be the one in which power is
-applied to the retimer. This driver will generate the required ACPI AML code
-which will toggle the GPIO in response to the kernel's request (through the
-`_DSM` ACPI method). Simply put something like the following in your devicetree:
-
-```
-device pci 0.0 on
-	chip drivers/intel/usb4/retimer
-		register "power_gpio" = "ACPI_GPIO_OUTPUT_ACTIVE_HIGH(GPP_A0)"
-		device generic 0 on end
-	end
-end
-```
-
-replacing the GPIO with the appropriate pin and polarity.
-

Documentation/drivers/smmstorev2.md

@@ -1,221 +0,0 @@
-# SMM based flash storage driver Version 2
-
-This documents the API exposed by the x86 system management based
-storage driver.
-
-## SMMSTOREv2
-
-SMMSTOREv2 is a [SMM] mediated driver to read from, write to and erase
-a predefined region in flash. It can be enabled by setting
-`CONFIG_SMMSTORE=y` and `CONFIG_SMMSTORE_V2=y` in menuconfig.
-
-This can be used by the OS or the payload to implement persistent
-storage to hold for instance configuration data, without needing to
-implement a (platform specific) storage driver in the payload itself.
-
-### Storage size and alignment
-
-SMMSTORE version 2 requires a minimum alignment of 64 KiB, which should
-be supported by all flash chips. Not having to perform read-modify-write
-operations is desired, as it reduces complexity and potential for bugs.
-
-This can be used by a FTW (FaultTolerantWrite) implementation that uses
-at least two regions in an A/B update scheme. The FTW implementation in
-EDK2 uses three different regions in the store:
-
-- The variable store
-- The FTW spare block
-- The FTW working block
-
-All regions must be block-aligned, and the FTW spare size must be larger
-than that of the variable store. FTW working block can be much smaller.
-With 64 KiB as block size, the minimum size of the FTW-enabled store is:
-
-- The variable store: 1 block = 64 KiB
-- The FTW spare block: 2 blocks = 2 * 64 KiB
-- The FTW working block: 1 block = 64 KiB
-
-Therefore, the minimum size for EDK2 FTW is 4 blocks, or 256 KiB.
-
-## API
-
-The API provides read and write access to an unformatted block storage.
-
-### Storage region
-
-By default SMMSTOREv2 will operate on a separate FMAP region called
-`SMMSTORE`. The default generated FMAP will include such a region. On
-systems with a locked FMAP, e.g. in an existing vboot setup with a
-locked RO region, the option exists to add a cbfsfile called `smm_store`
-in the `RW_LEGACY` (if CHROMEOS) or in the `COREBOOT` FMAP regions. It
-is recommended for new builds using a handcrafted FMD that intend to
-make use of SMMSTORE to include a sufficiently large `SMMSTORE` FMAP
-region. It is mandatory to align the `SMMSTORE` region to 64KiB for
-compatibility with the largest flash erase operation.
-
-When a default generated FMAP is used, the size of the FMAP region is
-equal to `CONFIG_SMMSTORE_SIZE`. UEFI payloads expect at least 64 KiB.
-To support a fault tolerant write mechanism, at least a multiple of
-this size is recommended.
-
-### Communication buffer
-
-To prevent malicious ring0 code to access arbitrary memory locations,
-SMMSTOREv2 uses a communication buffer in CBMEM/HOB for all transfers.
-This buffer has to be at least 64 KiB in size and must be installed
-before calling any of the SMMSTORE read or write operations. Usually,
-coreboot will install this buffer to transfer data between ring0 and
-the [SMM] handler.
-
-In order to get the communication buffer address, the payload or OS
-has to read the coreboot table with tag `0x0039`, containing:
-
-```C
-struct lb_smmstorev2 {
-	uint32_t tag;
-	uint32_t size;
-	uint32_t num_blocks;	/* Number of writeable blocks in SMM */
-	uint32_t block_size;	/* Size of a block in byte. Default: 64 KiB */
-	uint32_t mmap_addr;	/* MMIO address of the store for read only access */
-	uint32_t com_buffer;	/* Physical address of the communication buffer */
-	uint32_t com_buffer_size;	/* Size of the communication buffer in byte */
-	uint8_t apm_cmd;	/* The command byte to write to the APM I/O port */
-	uint8_t unused[3];	/* Set to zero */
-};
-```
-
-The absence of this coreboot table entry indicates that there's no
-SMMSTOREv2 support.
-
-### Blocks
-
-The SMMSTOREv2 splits the SMMSTORE FMAP partition into smaller chunks
-called *blocks*. Every block is at least the size of 64KiB to support
-arbitrary NOR flash erase ops. A payload or OS must make no further
-assumptions about the block or communication buffer size.
-
-### Generating the SMI
-
-SMMSTOREv2 is called via an SMI, which is generated via a write to the
-IO port defined in the smi_cmd entry of the FADT ACPI table. `%al`
-contains `APM_CNT_SMMSTORE=0xed` and is written to the smi_cmd IO
-port. `%ah` contains the SMMSTOREv2 command. `%ebx` contains the
-parameter buffer to the SMMSTOREv2 command.
-
-### Return values
-
-If a command succeeds, SMMSTOREv2 will return with
-`SMMSTORE_RET_SUCCESS=0` in `%eax`. On failure SMMSTORE will return
-`SMMSTORE_RET_FAILURE=1`. For unsupported SMMSTORE commands
-`SMMSTORE_REG_UNSUPPORTED=2` is returned.
-
-**NOTE 1**: The caller **must** check the return value and should make
-no assumption on the returned data if `%eax` does not contain
-`SMMSTORE_RET_SUCCESS`.
-
-**NOTE 2**: If the SMI returns without changing `%ax`, it can be assumed
-that the SMMSTOREv2 feature is not installed.
-
-### Calling arguments
-
-SMMSTOREv2 supports 3 subcommands that are passed via `%ah`, the
-additional calling arguments are passed via `%ebx`.
-
-**NOTE**: The size of the struct entries are in the native word size of
-smihandler. This means 32 bits in almost all cases.
-
-#### - SMMSTORE_CMD_INIT = 4
-
-This installs the communication buffer to use and thus enables the
-SMMSTORE handler. This command can only be executed once and is done
-by the firmware. Calling this function at runtime has no effect.
-
-The additional parameter buffer `%ebx` contains a pointer to the
-following struct:
-
-```C
-struct smmstore_params_init {
-	uint32_t com_buffer;
-	uint32_t com_buffer_size;
-} __packed;
-```
-
-INPUT:
-- `com_buffer`: Physical address of the communication buffer (CBMEM)
-- `com_buffer_size`: Size in bytes of the communication buffer
-
-#### - SMMSTORE_CMD_RAW_READ = 5
-
-SMMSTOREv2 allows reading arbitrary data. It is up to the caller to
-initialize the store with meaningful data before using it.
-
-The additional parameter buffer `%ebx` contains a pointer to the
-following struct:
-
-```C
-struct smmstore_params_raw_read {
-	uint32_t bufsize;
-	uint32_t bufoffset;
-	uint32_t block_id;
-} __packed;
-```
-
-INPUT:
-- `bufsize`: Size of data to read within the communication buffer
-- `bufoffset`: Offset within the communication buffer
-- `block_id`: Block to read from
-
-#### - SMMSTORE_CMD_RAW_WRITE = 6
-
-SMMSTOREv2 allows writing arbitrary data. It is up to the caller to
-erase a block before writing it.
-
-The additional parameter buffer `%ebx` contains a pointer to
-the following struct:
-
-```C
-struct smmstore_params_raw_write {
-        uint32_t bufsize;
-        uint32_t bufoffset;
-        uint32_t block_id;
-} __packed;
-```
-
-INPUT:
-- `bufsize`: Size of data to write within the communication buffer
-- `bufoffset`: Offset within the communication buffer
-- `block_id`: Block to write to
-
-#### - SMMSTORE_CMD_RAW_CLEAR = 7
-
-SMMSTOREv2 allows clearing blocks. A cleared block will read as `0xff`.
-By providing multiple blocks the caller can implement a fault tolerant
-write mechanism. It is up to the caller to clear blocks before writing
-to them.
-
-
-```C
-struct smmstore_params_raw_clear {
-	uint32_t block_id;
-} __packed;
-```
-
-INPUT:
-- `block_id`: Block to erase
-
-#### Security
-
-Pointers provided by the payload or OS are checked to not overlap with
-SMM. This protects the SMM handler from being compromised.
-
-As all information is exchanged using the communication buffer and
-coreboot tables, there's no risk that a malicious application capable
-of issuing SMIs could extract arbitrary data or modify the currently
-running kernel.
-
-## External links
-
-* [A Tour Beyond BIOS Implementing UEFI Authenticated Variables in SMM with EDKI](https://software.intel.com/sites/default/files/managed/cf/ea/a_tour_beyond_bios_implementing_uefi_authenticated_variables_in_smm_with_edkii.pdf)
-Note that this differs significantly from coreboot's implementation.
-
-[SMM]: ../security/smm.md

Documentation/getting_started/gerrit_guidelines.md

@@ -43,42 +43,15 @@ employer is aware and you are authorized to submit the code. For
 clarification, see the Developer's Certificate of Origin in the coreboot
 [Signed-off-by policy](https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure).
 
-* In general, patches should remain open for review for at least 24 hours
-since the last significant modification to the change. The purpose is to
-let coreboot developers around the world have a chance to review. Complex
-reworks, even if they don't change the purpose of the patch but the way
-it's implemented, should restart the wait period.
-
-* A change can go in without the wait period if its purpose is to fix
-a recently-introduced issue (build, boot or OS-level compatibility, not
-necessarily identified by coreboot.org facilities). Its commit message
-has to explain what change introduced the problem and the nature of
-the problem so that the emergency need becomes apparent. The change
-itself should be as limited in scope and impact as possible to make it
-simple to assess the impact. Such a change can be merged early with 3
-Code-Review+2. For emergency fixes that affect a single project (SoC,
-mainboard, ...) it's _strongly_ recommended to get a review by somebody
-not involved with that project to ensure that the documentation of the
-issue is clear enough.
-
-* Trivial changes that deal with minor issues like inconsistencies in
-whitespace or spelling fixes that don't impact the final binary output
-also don't need to wait. Such changes should point out in their commit
-messages how the the author verified that the binary output is identical
-(e.g. a TIMELESS build for a given configuration). When submitting
-such changes early, the submitter must be different from the author
-and must document the intent in the Gerrit discussion, e.g. "landed the
-change early because it's trivial". Note that trivial fixes shouldn't
-necessarily be expedited: Just like they're not critical enough for
-things to go wrong because of them, they're not critical enough to
-require quick handling. This exception merely serves to acknowledge that
-a round-the-world review just isn't necessary for some types of changes.
-
-* As explained in our Code of Conduct, we try to assume the best of each
-other in this community. It's okay to discuss mistakes (e.g. isolated
-instances of non-trivial and non-critical changes submitted early) but
-try to keep such inquiries blameless. If a change leads to problems with
-our code, the focus should be on fixing the issue, not on assigning blame.
+* Let non-trivial patches sit in a review state for at least 24 hours
+before submission. Remember that there are coreboot developers in timezones
+all over the world, and everyone should have a chance to contribute.
+Trivial patches would be things like whitespace changes or spelling fixes,
+in general those that don’t impact the final binary output. The
+24-hour period would start at submission, and would be restarted at any
+update which significantly changes any part of the patch. Patches can be
+'Fast-tracked' and submitted in under 24 hours with the agreement of at
+least 3 +2 votes.
 
 * Do not +2 patches that you authored or own, even for something as trivial
 as whitespace fixes. When working on your own patches, it’s easy to
@@ -320,35 +293,6 @@ 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.
-
 
 Requests for clarification and suggestions for updates to these guidelines
 should be sent to the coreboot mailing list at <coreboot@coreboot.org>.

Documentation/getting_started/gpio.md

@@ -88,6 +88,11 @@ 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 */
@@ -129,13 +134,3 @@ 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.
-
-## Pad-related known issues and workarounds
-
-### LPC_CLKRUNB blocks S0ix states when board uses eSPI
-
-When using eSPI, the pad implementing `LPC_CLKRUNB` must be set to GPIO mode.
-Other pin settings i.e. Rx path enable/disable, Tx path enable/disable, pull up
-enable/disable etc are ignored. Leaving this pin in native mode will keep the
-LPC Controller awake and prevent S0ix entry. This issues is know at least on
-Apollolake and Geminilake.

Documentation/getting_started/kconfig.md

@@ -52,7 +52,7 @@ command line.
   not have an answer yet, it stops and queries the user for the desired value.
 - olddefconfig - Generates a config, using the default value for any symbols not
   listed in the .config file.
-- savedefconfig - Creates a ‘defconfig’ file, stripping out all of the symbols
+- savedefconfig - Creates a ‘mini-config’ file, stripping out all of the symbols
   that were left as default values.  This is very useful for debugging, and is
   how config files should be saved.
 - silentoldconfig - This evaluates the .config file the same way that the
@@ -398,8 +398,6 @@ default <expr> \[if <expr>\]
 - If there is no 'default' entry for a symbol, it gets set to 'n', 0, 0x0, or
   “” depending on the type, however the 'bool' type is the only type that
   should be left without a default value.
-- If possible, the declaration should happen before all default entries to make
-  it visible in Kconfig tools like menuconfig.
 
 --------------------------------------------------------------------------------
 
@@ -607,7 +605,7 @@ int <expr> \[if <expr>\]
 
 
 ##### Example:
-    config PRE_GRAPHICS_DELAY_MS
+    config PRE_GRAPHICS_DELAY
         int "Graphics initialization delay in ms"
         default 0
         help

Documentation/ifdtool/layout.md

@@ -19,7 +19,7 @@ way to categorize anything required by the SoC but not provided by coreboot.
 | IFD Region | IFD Region name  | FMAP Name | Notes                                     |
 | index      |                  |           |                                           |
 +============+==================+===========+===========================================+
-| 0          | Flash Descriptor | SI_DESC   | Always the top 4 KiB of flash             |
+| 0          | Flash Descriptor | SI_DESC   | Always the top 4KB of flash               |
 +------------+------------------+-----------+-------------------------------------------+
 | 1          | BIOS             | SI_BIOS   | This is the region that contains coreboot |
 +------------+------------------+-----------+-------------------------------------------+
@@ -40,9 +40,9 @@ way to categorize anything required by the SoC but not provided by coreboot.
 The ifdtool can be used to manipulate a firmware image with a IFD. This tool
 will not take into account the FMAP while modifying the image which can lead to
 unexpected and hard to debug issues with the firmware image. For example if the
-ME region is defined at 6 MiB in the IFD but the FMAP only allocates 4 MiB for
-the ME, then when the ME is added by the ifdtool 6 MiB will be written which
-could overwrite 2 MiB of the BIOS.
+ME region is defined at 6 MB in the IFD but the FMAP only allocates 4 MB for the
+ME, then when the ME is added by the ifdtool 6 MB will be written which could
+overwrite 2 MB of the BIOS.
 
 In order to validate that the FMAP and the IFD are compatible the ifdtool
 provides --validate (-t) option. `ifdtool -t` will read both the IFD and the
@@ -75,4 +75,4 @@ Region mismatch between pd and SI_PDR
  FMAP area SI_PDR:
   offset: 0x007fc000
   length: 0x00004000
-```
+```

Documentation/index.md

@@ -162,11 +162,10 @@ Contents:
 
 * [Getting Started](getting_started/index.md)
 * [Tutorial](tutorial/index.md)
-* [Coding Style](contributing/coding_style.md)
+* [Coding Style](coding_style.md)
 * [Project Ideas](contributing/project_ideas.md)
 * [Documentation Ideas](contributing/documentation_ideas.md)
 * [Code of Conduct](community/code_of_conduct.md)
-* [Language style](community/language_style.md)
 * [Community forums](community/forums.md)
 * [Project services](community/services.md)
 * [coreboot at conferences](community/conferences.md)
@@ -187,6 +186,5 @@ Contents:
 * [SuperIO](superio/index.md)
 * [Vendorcode](vendorcode/index.md)
 * [Utilities](util.md)
-* [coreboot infrastructure](infrastructure/index.md)
 * [Release notes for past releases](releases/index.md)
 * [Flashing firmware tutorial](flash_tutorial/index.md)

Documentation/infrastructure/builders.md

@@ -1,392 +0,0 @@
-# Jenkins builder setup and configuration
-
-## How to set up a new jenkins builder
-
-### Contact a jenkins admin
-
-Let a jenkins admin know that you’re interested in setting up a jenkins
-build system.
-
-For a permanent build system, this should generally be a dedicated
-machine that is not generally being used for other purposes.  The
-coreboot builds are very intensive.
-
-It's also best to be aware that although we don't know of any security
-issues, the jenkins-node image is run with the privileged flag which
-gives the container root access to the build machine.  See
-[this article](https://blog.trendmicro.com/trendlabs-security-intelligence/why-running-a-privileged-container-in-docker-is-a-bad-idea/)
-about why this is discouraged.
-
-It's recommended that you give an admin root access on your machine so
-that they can reset it in case of a failure.  This is not a requirement,
-as the system can just be disabled until someone is available to fix any
-issues.
-
-Currently active Jenkins admins:
-*   Patrick Georgi:
-    *   Email: [patrick@georgi-clan.de](mailto:patrick@georgi-clan.de)
-    *   IRC: pgeorgi
-
-
-### Build Machine requirements
-
-For a builder, we need a fast system with lots of threads and plenty of
-RAM.  The builder builds and stores the git repos and output in tmpfs
-along with the ccache save area, so if there isn't enough memory, the
-builds will slow down because of smaller ccache areas and can run into
-"out of storage space" errors.
-
-#### Current Build Machines
-
-To give an idea of what a suitable build machine might be, currently the
-coreboot project has 3 active jenkins build machines.
-
-* Congenialbuilder - 128 threads, 256GiB RAM
-  *  Fastest Passing coreboot gerrit build: 4 min, 30 sec
-  *  Slowest Passing coreboot gerrit build: 9 min, 56 sec
-
-
-* Gleeful builder - 64 thread, 64GiB RAM
-  *  Fastest Passing coreboot gerrit build: 6 min, 6 sec
-  *  Slowest Passing coreboot gerrit build, 34 min
-
-
-* Ultron (9elements) - 48 threads, 128GiB RAM
-  *  Fastest Passing coreboot gerrit build: 6 min, 32 sec
-  *  Slowest Passing coreboot gerrit build: 44 min
-
-
-### Jenkins Builds
-
-There are a number of builds handled by the coreboot jenkins builders,
-for a number of different projects - coreboot, flashrom, memtest86+,
-em100, etc.  Many of these have builders for their current master branch
-as well as gerrit and coverity builds.
-
-You can see all the builds here:
-[https://qa.coreboot.org/](https://qa.coreboot.org/)
-
-Most of the time on the builders is taken up by the coreboot master and
-gerrit builds.
-
-* [coreboot gerrit build](https://qa.coreboot.org/job/coreboot-gerrit/)
-([Time trend](https://qa.coreboot.org/job/coreboot-gerrit/buildTimeTrend))
-
-
-* [coreboot master build](https://qa.coreboot.org/job/coreboot/)
- ([Time trend](https://qa.coreboot.org/job/coreboot/buildTimeTrend))
-
-
-### Stress test the machine
-
-Test the machine to make sure that building won't stress the hardware
-too much.  Install stress-ng, then run the stress test for at least an
-hour.
-
-On a system with 32 cores, it was tested with this command:
-
-```
-$ stress-ng --cpu 20 --io 6 --vm 6 --vm-bytes 1G --verify --metrics-brief -t 60m
-```
-
-You can watch the temperature with the sensors package or with ‘acpi -t’
-if your machine supports that.
-
-You can check for thermal throttling by running this command and seeing
-if the values go down on any of the cores after it's been running for a
-while.
-
-```
-$ while [ true ]; do clear; cat /proc/cpuinfo | grep 'cpu MHz' ; sleep 1; done
-```
-
-If the machine throttles or resets, you probably need to upgrade the
-cooling system.
-
-
-## jenkins-server docker installation
-
-
-### Manual Installation
-
-If you’ve met all the above requirements, and an admin has agreed to set
-up the builder in jenkins, you’re ready to go on to the next steps.
-
-
-### Set up your network so jenkins can talk to the container
-
-Expose a local port through any firewalls you might have on your router.
-This would generally be in the port forwarding section, and you'd just
-forward a port (typically 49151) from the internet directly to the
-builder’s IP address.
-
-You might also want to set up a port to forward to port 22 on your
-machine and set up openssh so you or the jenkins admins can manage
-the machine remotely (if you allow them).
-
-
-### Install and set up docker
-
-Install docker by following the
-[directions](https://docs.docker.com/engine/install/) on the docker
-site.  These instructions keep changing, so just check the latest
-information.
-
-
-#### Set up environment variables
-
-To make configuration and the later commands easier, these should go in
-your shell's .rc file.  Note that you only need to set them if you're
-using something other than the default.
-
-```
-# Set the port used on your machine to connect to jenkins.
-export COREBOOT_JENKINS_PORT=49151
-
-# Set the revision of the container from docker hub
-export DOCKER_COMMIT=65718760fa
-
-# Set the location of where the jenkins cache directory will be.
-export COREBOOT_JENKINS_CACHE_DIR="/srv/docker/coreboot-builder/cache"
-
-# Set the name of the container
-export COREBOOT_JENKINS_CONTAINER="coreboot_jenkins"
-```
-
-Make sure any variables needed are set in your environment before
-continuing to the next step.
-
-
-### Using the Makefile for docker installation
-
-From the coreboot directory, run
-
-```
-make -C util/docker help
-```
-
-This will show you the available targets and variables needed:
-
-```
-Commands for working with docker images:
-  coreboot-sdk                 - Build coreboot-sdk container
-  upload-coreboot-sdk          - Upload coreboot-sdk to hub.docker.com
-  coreboot-jenkins-node        - Build coreboot-jenkins-node container
-  upload-coreboot-jenkins-node - Upload coreboot-jenkins-node to hub.docker.com
-  doc.coreboot.org             - Build doc.coreboot.org container
-  clean-coreboot-containers    - Remove all docker coreboot containers
-  clean-coreboot-images        - Remove all docker coreboot images
-  docker-clean                 - Remove docker coreboot containers & images
-
-Commands for using docker images
-  docker-build-coreboot        - Build coreboot under coreboot-sdk
-      <BUILD_CMD=target>
-  docker-abuild                - Run abuild under coreboot-sdk
-      <ABUILD_ARGS='-a -B'>
-  docker-what-jenkins-does     - Run 'what-jenkins-does' target
-  docker-shell                 - Bash prompt in coreboot-jenkins-node
-      <USER=root or USER=coreboot>
-  docker-jenkins-server        - Run coreboot-jenkins-node image (for server)
-  docker-jenkins-attach        - Open shell in running jenkins server
-  docker-build-docs            - Build the documentation
-  docker-livehtml-docs         - Run sphinx-autobuild
-
-Variables:
-  COREBOOT_JENKINS_PORT=49151
-  COREBOOT_JENKINS_CACHE_DIR=/srv/docker/coreboot-builder/cache
-  COREBOOT_JENKINS_CONTAINER=coreboot_jenkins
-  COREBOOT_IMAGE_TAG=f2741aa632f
-  DOCKER_COMMIT=65718760fa
-```
-
-### Set up the system for the jenkins builder
-
-As a regular user - *Not root*, run:
-
-```
-sudo mkdir -p ${COREBOOT_JENKINS_CACHE_DIR}
-sudo mkdir -p ${COREBOOT_JENKINS_CCACHE_DIR}
-sudo chown $(whoami):$(whoami) ${COREBOOT_JENKINS_CCACHE_DIR}
-sudo chown $(whoami):$(whoami) ${COREBOOT_JENKINS_CACHE_DIR}
-wget http://www.dediprog.com/save/78.rar/to/EM100Pro.rar
-mv EM100Pro.rar ${COREBOOT_JENKINS_CACHE_DIR}
-```
-
-### Install the coreboot jenkins builder
-
-```
-make -C util/docker docker-jenkins-server
-```
-
-Your installation is complete on your side.
-
-### Tell the Admins that the machine is set up
-Let the admins know that the builder is set up so they can set up the
-machine profile on qa.coreboot.org.
-
-They need to know:
-*   Your external IP address or domain name.  If you don’t have a static
-IP, make sure you have a dynamic dns hostname configured.
-*   The port on your machine and firewall that’s exposed for jenkins:
-`$COREBOOT_JENKINS_PORT`
-*   The core count of the machine.
-*   How much memory is available on the machine.  This helps determine
-the amount of memory used for ccache.
-
-
-### First build
-On the first build after a machine is reset, it will frequently take
-20-25 minutes to do the entire what-jenkins-does build while the ccache
-is getting filled up and the entire coreboot repo gets downloaded.  As
-the ccache gets populated, the build time will drop.
-
-
-## Additional Information
-
-
-### How to log in to the docker instance for debugging
-```
-    $ make -C util/docker docker-jenkins-attach
-    $ su coreboot
-    $ cd ~/slave-root/workspace
-    $ bash
-```
-
-
-WARNING: This should not be used to make changes to the build system,
-but just to debug issues. Changes to the build system are highly
-discouraged as it leads to situations where patches can pass the build
-testing on one builder and fail on another builder. Any changes that are
-made in the image will be lost on the next update, so if you
-accidentally change something, you can remove the containers and images
-and update to get a fresh installation.
-
-
-### How to download containers/images for a fresh installation and remove old containers
-
-To delete the old containers & images:
-
-```
-$ docker stop $COREBOOT_JENKINS_CONTAINER
-$ docker rm $COREBOOT_JENKINS_CONTAINER
-$ docker images # lists all existing images
-$ docker rmi XXXX # Use the image ID found in the above command.
-```
-
-To get and run the new coreboot-jenkins image, change the value in the
-`DOCKER_COMMIT` variable to the new image value.
-
-```
-$ make -C util/docker docker-jenkins-server
-```
-
-#### Getting ready to push the docker images
-
-Set up an account on hub.docker.com
-
-Get an admin to add the account to the coreboot team on hub.docker.com
-
-[https://hub.docker.com/u/coreboot/dashboard/teams/?team=owners](https://hub.docker.com/u/coreboot/dashboard/teams/?team=owners)
-
-Make sure your credentials are configured on your host machine by
-running
-
-```
-$ docker login
-```
-
-This will prompt you for your docker username, password, and your email
-address, and write out to ~/.docker/config.json.  Without this file, you
-won’t be able to push the images.
-
-#### Updating the Dockerfiles:
-
-The coreboot-sdk Dockerfile will need to be updated when any additional
-dependencies are added.  Both the coreboot-sdk and the
-coreboot-jenkins-node Dockerfiles will need to be updated to the new
-version number and git commit id anytime the toolchain is updated. Both
-files are stored in the coreboot repo under coreboot/util/docker.
-
-Read the [dockerfile best practices](https://docs.docker.com/v1.8/articles/dockerfile_best-practices/)
-page before updating the files.
-
-#### Rebuilding the coreboot-sdk docker image to update the toolchain:
-
-```
-$ make -C util/docker coreboot-sdk
-```
-
-This takes a relatively long time.
-
-#### Test the coreboot-sdk docker image:
-
-There are two methods of running the docker image - interactively as a
-shell, or doing the build directly.  Running interactively as a shell is
-useful for early testing, because it allows you to update the image
-(without any changes getting saved) and re-test builds.  This saves the
-time of having to rebuild the image for every issue you find.
-
-#### Running the docker image interactively:
-
-Run:
-
-```
-$ make -C util/docker docker-jenkins-server
-$ make -C util/docker docker-jenkins-attach
-```
-
-#### Running the build directly:
-
-From the coreboot directory:
-
-```
-$ make -C util/docker docker-build-coreboot
-```
-
-You’ll also want to test building the other projects and payloads:
-ChromeEC, flashrom, memtest86+, em100, Grub2, SeaBIOS, iPXE, coreinfo,
-nvramcui, tint...
-
-#### Pushing the coreboot-sdk image to hub.docker.com for use:
-
-When you’re satisfied with the testing, push the coreboot-sdk image to
-the hub.docker.com
-
-```
-$ make -C util/docker upload-coreboot-sdk
-```
-
-#### Building and pushing the coreboot-jenkins-node docker image:
-
-This docker image is pretty simple, so there’s not really any testing
-that needs to be done.
-
-```
-$ make -C util/docker coreboot-jenkins-node
-$ make -C util/docker upload-coreboot-jenkins-node
-```
-
-### Coverity Setup
-
-To run coverity jobs, the builder needs to have the tools available, and
-to be marked as a coverity builder.
-
-
-#### Set up the Coverity tools
-
-Download the Linux-64 coverity build tool and decompress it into your
-cache directory as defined by the `$COREBOOT_JENKINS_CACHE_DIR` variable
-
-[https://scan.coverity.com/download](https://scan.coverity.com/download)
-
-Rename the directory from its original name
-(cov-analysis-linux64-7.7.0.4) to ‘coverity’, or better, create a
-symlink:
-
-```
-ln -s cov-analysis-linux64-7.7.0.4 coverity
-```
-
-
-Let the admins know that the ‘coverity’ label can be added to the
-builder.

Documentation/infrastructure/index.md

@@ -1,6 +0,0 @@
-# coreboot infrastructure
-
-This section contains documentation about coreboot infrastructure
-
-## Jenkins builders and builds
-[Setting up Jenkins build machines](builders.md)

Documentation/lib/fw_config.md

@@ -73,18 +73,18 @@ return true.
 
 ## Firmware Configuration Value
 
-The 64-bit value used as the firmware configuration bitmask is meant to be determined at runtime
+The 32bit value used as the firmware configuration bitmask is meant to be determined at runtime
 but could also be defined at compile time if needed.
 
 There are two supported sources for providing this information to coreboot.
 
 ### CBFS
 
-The value can be provided with a 64-bit raw value in CBFS that is read by coreboot.  The value
+The value can be provided with a 32bit raw value in CBFS that is read by coreboot.  The value
 can be set at build time but also adjusted in an existing image with `cbfstool`.
 
 To enable this select the `CONFIG_FW_CONFIG_CBFS` option in the build configuration and add a
-raw 64-bit value to CBFS with the name of the current prefix at `CONFIG_FW_PREFIX/fw_config`.
+raw 32bit value to CBFS with the name of the current prefix at `CONFIG_FW_PREFIX/fw_config`.
 
 When `fw_config_probe_device()` or `fw_config_probe()` is called it will look for the specified
 file in CBFS use the value it contains when matching fields and options.
@@ -121,48 +121,12 @@ 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`.
 
@@ -327,8 +291,8 @@ field and option to check.
 struct fw_config {
 	const char *field_name;
 	const char *option_name;
-	uint64_t mask;
-	uint64_t value;
+	uint32_t mask;
+	uint32_t value;
 };
 ```
 

Documentation/lib/payloads/fit.md

@@ -5,7 +5,6 @@
 
 ## Supported architectures
 
-* aarch32
 * aarch64
 * riscv
 
@@ -27,13 +26,6 @@ The section must be named in order to be found by the FIT parser:
 
 The FIT parser needs architecure support.
 
-### aarch32
-The source code can be found in `src/arch/arm/fit_payload.c`.
-
-On aarch32 the kernel (a section named 'kernel') must be in **Image**
-format and it needs a devicetree (a section named 'fdt') to boot.
-The kernel will be placed close to "*DRAMSTART*".
-
 ### aarch64
 The source code can be found in `src/arch/arm64/fit_payload.c`.
 

Documentation/mainboard/asus/a88xm-e.md

@@ -1,170 +0,0 @@
-# ASUS A88XM-E
-
-This page describes how to run coreboot on the [ASUS A88XM-E].
-
-## Technology
-
-Both "Trinity" and "Richland" FM2 desktop processing units are working,
-the CPU architecture in these CPUs/APUs are [Piledriver],
-and their GPU is [TeraScale 3] (VLIW4-based).
-
-Kaveri is non-working at the moment (FM2+),
-the CPU architecture in these CPUs/APUs are [Steamroller],
-and their GPU is [Sea Islands] (GCN2-based).
-
-A10 Richland is recommended for the best performance and working IOMMU.
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| A88XM-E          |                                                  |
-+------------------+--------------------------------------------------+
-| DDR voltage IC   | Nuvoton 3101S                                    |
-+------------------+--------------------------------------------------+
-| Network          | Realtek RTL8111G                                 |
-+------------------+--------------------------------------------------+
-| Northbridge      | Integrated into CPU with IMC and GPU (APUs only) |
-+------------------+--------------------------------------------------+
-| Southbridge      | Bolton-D4                                        |
-+------------------+--------------------------------------------------+
-| Sound IC         | Realtek ALC887                                   |
-+------------------+--------------------------------------------------+
-| Super I/O        | ITE IT8603E                                      |
-+------------------+--------------------------------------------------+
-| VRM controller   | DIGI VRM ASP1206                                 |
-+------------------+--------------------------------------------------+
-```
-
-## Flashing coreboot
-
-```eval_rst
-+---------------------+------------+
-| Type                | Value      |
-+=====================+============+
-| Socketed flash      | yes        |
-+---------------------+------------+
-| Model               | [GD25Q64]  |
-+---------------------+------------+
-| Size                | 8 MiB      |
-+---------------------+------------+
-| Package             | DIP-8      |
-+---------------------+------------+
-| Write protection    | yes        |
-+---------------------+------------+
-| Dual BIOS feature   | no         |
-+---------------------+------------+
-| Internal flashing   | yes        |
-+---------------------+------------+
-```
-
-### Internal programming
-
-The main SPI flash can be accessed using [flashrom], if the
-AmdSpiRomProtect modules have been deleted in the factory image previously.
-
-### External flashing
-
-Using a PLCC Extractor or any other appropriate tool, carefully remove the
-DIP-8 BIOS chip from its' socket while avoiding the bent pins, if possible.
-To flash it, use a [flashrom]-supported USB CH341A programmer - preferably with a
-green PCB - and double check that it's giving a 3.3V voltage on the socket pins.
-
-## Integrated graphics
-
-### Retrieve the VGA optionrom ("Retrieval via Linux kernel" method)
-
-Make sure a proprietary UEFI is flashed and boot Linux with iomem=relaxed flag.
-Some Linux drivers (e.g. radeon for AMD) make option ROMs like the video blob
-available to user space via sysfs. To use that to get the blob you need to
-enable it first. To that end you need to determine the path within /sys
-corresponding to your graphics chip. It looks like this:
-
-    # /sys/devices/pci<domain>:<bus>/<domain>:<bus>:<slot>.<function>/rom.
-
-You can get the respective information with lspci, for example:
-
-    # lspci -tv
-    # -[0000:00]-+-00.0  Advanced Micro Devices, Inc. [AMD] Family 16h Processor Root Complex
-    #            +-01.0  Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8210]
-    # ...
-
-Here the the needed bits (for the ROM of the Kabini device) are:
-
-    # PCI domain: (almost always) 0000
-    # PCI bus: (also very commonly) 00
-    # PCI slot: 01 (logical slot; different from any physical slots)
-    # PCI function: 0 (a PCI device might have multiple functions... shouldn't matter here)
-
-To enable reading of the ROM you need to write 1 to the respective file, e.g.:
-
-    # echo 1 > /sys/devices/pci0000:00/0000:00:01.0/rom
-
-The same file should then contain the video blob and it should be possible to simply copy it, e.g.:
-
-    # cp /sys/devices/pci0000:00/0000:00:01.0/rom vgabios.bin
-
-romheaders should print reasonable output for this file.
-
-This version is usable for all the GPUs.
-    1002,9901 Trinity (Radeon HD 7660D)
-    1002,9904 Trinity (Radeon HD 7560D)
-    1002,990c Richland (Radeon HD 8670D)
-    1002,990e Richland (Radeon HD 8570D)
-    1002,9991 Trinity (Radeon HD 7540D)
-    1002,9993 Trinity (Radeon HD 7480D)
-    1002,9996 Richland (Radeon HD 8470D)
-    1002,9998 Richland (Radeon HD 8370D)
-    1002,999d Richland (Radeon HD 8550D)
-    1002,130f Kaveri (Radeon R7)
-
-## Known issues
-
-- AHCI hot-plug
-- S3 resume (sometimes)
-- Windows 7 can't boot because of the incomplete ACPI implementation
-- XHCI
-
-### XHCI ports can break after using any of the blobs, restarting the
-board with factory image makes it work again as fallback.
-Tested even with/without the Bolton and Hudson blobs.
-
-## Untested
-
-- audio over HDMI
-
-## TODOs
-
-- one ATOMBIOS module for all the integrated GPUs
-- manage to work with Kaveri/Godavary (they are using a binaryPI)
-- IRQ routing is done incorrect way - common problem of fam15h boards
-
-## Working
-
-- ACPI
-- CPU frequency scaling
-- flashrom under coreboot
-- Gigabit Ethernet
-- Hardware monitoring
-- Integrated graphics
-- KVM virtualization
-- Onboard audio
-- PCI
-- PCIe
-- PS/2 keyboard mouse (during payload, bootloader)
-- SATA
-- Serial port
-- SuperIO based fan control
-- USB (disabling XHCI controller makes to work as fallback USB2.0 ports)
-- IOMMU
-
-## Extra resources
-
-- [Board manual]
-
-[ASUS A88XM-E]: https://www.asus.com/Motherboards/A88XME/
-[Board manual]: https://dlcdnets.asus.com/pub/ASUS/mb/SocketFM2/A88XM-E/E9125_A88XM-E.pdf
-[flashrom]: https://flashrom.org/Flashrom
-[GD25Q64]: http://www.elm-tech.com/ja/products/spi-flash-memory/gd25q64/gd25q64.pdf
-[Piledriver]: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29#APU_lines
-[Sea Islands]: https://en.wikipedia.org/wiki/Graphics_Core_Next#GCN_2nd_generation
-[Steamroller]: https://en.wikipedia.org/wiki/Steamroller_(microarchitecture)
-[TeraScale 3]: https://en.wikipedia.org/wiki/TeraScale_%28microarchitecture%29#TeraScale_3

Documentation/mainboard/asus/p5q.md

@@ -2,7 +2,9 @@
 
 This page describes how to run coreboot on the [ASUS P5Q] desktop board.
 
-## Working
+## TODO
+
+The following things are working in this coreboot port:
 
 + PCI slots
 + PCI-e slots
@@ -13,21 +15,20 @@ This page describes how to run coreboot on the [ASUS P5Q] desktop board.
 + All 4 DIMM slots
 + S3 suspend and resume
 + Red SATA ports
-+ Fan control through the W83667HG chip
-+ FireWire
 
-## Not working
+The following things are still missing from this coreboot port:
 
 + PS/2 mouse support
 + PATA aka IDE (because of buggy IDE controller)
-+ Fan profiles with Q-Fan
++ Fan control (will be working on 100% power)
 + TPM module (support not implemented)
 
-## Untested
+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
@@ -72,63 +73,5 @@ 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

Documentation/mainboard/clevo/n130wu/index.md

@@ -1,47 +0,0 @@
-# Clevo N130WU
-
-## Hardware
-### Technology
-```eval_rst
-+------------------+--------------------------------+
-| CPU              | Intel i7-8550U                 |
-+------------------+--------------------------------+
-| PCH              | Intel Sunrise Point LP         |
-+------------------+--------------------------------+
-| EC / Super IO    | ITE IT8587E                    |
-+------------------+--------------------------------+
-| Coprocessor      | Intel ME                       |
-+------------------+--------------------------------+
-```
-
-### Flash chip
-```eval_rst
-+---------------------+-----------------+
-| Type                | Value           |
-+=====================+=================+
-| Model               | GD25Q64B        |
-+---------------------+-----------------+
-| Socketed flash      | no              |
-+---------------------+-----------------+
-| Size                | 8 MiB           |
-+---------------------+-----------------+
-| In circuit flashing | Yes             |
-+---------------------+-----------------+
-| Package             | SOIC-8          |
-+---------------------+-----------------+
-| Write protection    | No              |
-+---------------------+-----------------+
-| Dual BIOS feature   | No              |
-+---------------------+-----------------+
-| Internal flashing   | Yes             |
-+---------------------+-----------------+
-```
-
-## Board status
-### Working
-### Not Working
-### Work in progress
-### Untested
-
-## Also known as
-* TUXEDO InfinityBook Pro 13 v3

Documentation/mainboard/emulation/qemu-i440fx.md

@@ -1,64 +0,0 @@
-# qemu i440fx mainboard
-
-## Running coreboot in qemu
-Emulators like qemu don't need a firmware to do hardware init.
-The hardware starts in the configured state already.
-
-The coreboot port allows to test non mainboard specific code.
-As you can easily attach a debugger, it's a good target for
-experimental code.
-
-## coreboot x86_64 support
-coreboot historically runs in 32-bit protected mode, even though the
-processor supports x86_64 instructions (long mode).
-
-The qemu-i440fx mainboard has been ported to x86_64 and will serve as
-reference platform to enable additional platforms.
-
-To enable the support set the Kconfig option ``CONFIG_CPU_QEMU_X86_64=y``.
-
-## Installing qemu
-
-On debian you can install qemu by running:
-```bash
-$ sudo apt-get install qemu
-```
-
-On redhat you can install qemu by running:
-```bash
-$ sudo dnf install qemu
-```
-
-## Running coreboot
-
-### To run the i386 version of coreboot (default)
-Running on qemu-system-i386 will require a 32 bit operating system.
-
-```bash
-qemu-system-i386 -bios build/coreboot.rom -serial stdio -M pc
-```
-
-### To run the experimental x86_64 version of coreboot
-Running on qemu-system-x86_64 allows to run a 32 bit or 64 bit operating system,
-as well as firmware.
-
-```bash
-qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M pc
-```
-
-## Finding bugs
-To test coreboot's x86 code it's recommended to run on a x86 host and enable KVM.
-It will not only run faster, but is closer to real hardware. If you see the
-following message:
-
-    KVM internal error. Suberror: 1
-    emulation failure
-
-something went wrong. The same bug will likely cause a FAULT on real hardware,
-too.
-
-To enable KVM run:
-
-```bash
-qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M pc -accel kvm -cpu host
-```

Documentation/mainboard/emulation/qemu-q35.md

@@ -1,64 +0,0 @@
-# qemu q35 mainboard
-
-## Running coreboot in qemu
-Emulators like qemu don't need a firmware to do hardware init.
-The hardware starts in the configured state already.
-
-The coreboot port allows to test non mainboard specific code.
-As you can easily attach a debugger, it's a good target for
-experimental code.
-
-## coreboot x86_64 support
-coreboot historically runs in 32-bit protected mode, even though the
-processor supports x86_64 instructions (long mode).
-
-The qemu-q35 mainboard has been ported to x86_64 and will serve as
-reference platform to enable additional platforms.
-
-To enable the support set the Kconfig option ``CONFIG_CPU_QEMU_X86_64=y``.
-
-## Installing qemu
-
-On debian you can install qemu by running:
-```bash
-$ sudo apt-get install qemu
-```
-
-On redhat you can install qemu by running:
-```bash
-$ sudo dnf install qemu
-```
-
-## Running coreboot
-### To run the i386 version of coreboot (default)
-Running on qemu-system-i386 will require a 32 bit operating system.
-
-```bash
-qemu-system-i386 -bios build/coreboot.rom -serial stdio -M q35
-```
-
-### To run the experimental x86_64 version of coreboot
-Running on `qemu-system-x86_64` allows to run a 32 bit or 64 bit operating system
-and firmware.
-
-```bash
-qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35
-```
-
-## Finding bugs
-To test coreboot's x86 code it's recommended to run on a x86 host and enable KVM.
-It will not only run faster, but is closer to real hardware. If you see the
-following message:
-
-    KVM internal error. Suberror: 1
-    emulation failure
-
-something went wrong. The same bug will likely cause a FAULT on real hardware,
-too.
-
-To enable KVM run:
-
-```bash
-qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35 -accel kvm -cpu host
-```
-

Documentation/mainboard/facebook/monolith.md

@@ -2,7 +2,7 @@
 
 This page describes how to run coreboot on the Facebook Monolith.
 
-Please note: the coreboot implementation for this board is in its
+Please note: the coreboot implementation for this boards is in its
 Beta state and isn't fully tested yet.
 
 ## Required blobs
@@ -41,8 +41,8 @@ These can be extracted from the original flash image as follows:
 00003000:006FFFFF me
 00001000:00002fff gbe
 ```
-3) Use `ifdtool -n <layout_file> <flash_image>` to resize the *bios* region from the default 6 MiB
-   to 9 MiB, this is required to create sufficient space for LinuxBoot.
+3) Use `ifdtool -n <layout_file> <flash_image>` to resize the *bios* region from the default 6MB
+   to 9 MB, this is required to create sufficient space for LinuxBoot.
    NOTE: Please make sure only the firmware descriptor (*fd*) region is changed. Older versions
    	 of the ifdtool corrupt the *me* region.
 4) Use `ifdtool -x <resized_flash_image>` to extract the components.
@@ -104,7 +104,7 @@ solution. Wires need to be connected to be able to flash using an external progr
 - SMBus
 - Initialization with FSP
 - SeaBIOS payload (commit a5cab58e9a3fb6e168aba919c5669bea406573b4)
-- TianoCore payload (commit 860a8d95c2ee89c9916d6e11230f246afa1cd629)
+- TianoCore payload (commit a5cab58e9a3fb6e168aba919c5669bea406573b4)
 - LinuxBoot (kernel kernel-4_19_97) (uroot commit 9c9db9dbd6b532f5f91a511a0de885c6562aadd7)
 - eMMC
 

Documentation/mainboard/gigabyte/ga-g41m-es2l.md

@@ -1,283 +0,0 @@
-# Gigabyte GA-G41M-ES2L rev 1.1
-
-This page describes how to use coreboot on the [Gigabyte GA-G41M-ES2L rev 1.1](https://www.gigabyte.com/Motherboard/GA-G41M-ES2L-rev-11) mainboard.
-
-This motherboard [also works with Libreboot](https://libreboot.org/docs/install/ga-g41m-es2l.html).
-
-## Technology
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| Type             | Value                                            |
-+==================+==================================================+
-| BIOS flash chips | 2 x SST25VF080B (8 Mbit SPI) (DUAL BIOS)         |
-+------------------+--------------------------------------------------+
-| Northbridge      | Intel G41                                        |
-+------------------+--------------------------------------------------+
-| Southbridge      | Intel ICH7                                       |
-+------------------+--------------------------------------------------+
-| CPU socket       | LGA775                                           |
-+------------------+--------------------------------------------------+
-| RAM              | 2 x DDR2 800, max. 8 GiB                         |
-+------------------+--------------------------------------------------+
-| SuperIO          | ITE IT8718F-S                                    |
-+------------------+--------------------------------------------------+
-| Audio            | Realtek ALC888B                                  |
-+------------------+--------------------------------------------------+
-| Network          | Realtek RTL8111C PCIe Gigabit Ethernet           |
-+------------------+--------------------------------------------------+
-```
-
-## Preparation
-
-```eval_rst
-For more datails how to get sources and build the toolchain, see :doc:`../../tutorial/part1`.
-```
-
-### Devuan 4 Chimaera
-
-This probably works also for any fresh Debian/Ubuntu-based distros.
-
-Install tools and libraries needed for coreboot:
-
-```shell
-sudo apt-get -V install bison build-essential curl flex git gnat libncurses5-dev m4 zlib1g-dev wget python2 python-is-python2 flashrom
-```
-
-### Get sources
-
-You need about 700 MB disk space for sources only and ~2GB disk space for sources + build results
-
-```shell
-git clone --recursive https://review.coreboot.org/coreboot.git
-```
-
-### Build toolchain
-
-Your system compilers can be different with versions, tested by coreboot developers.
-So, it is recommended to build cross-compilers with special versions, which were tested with coreboot.
-
-It is possible to skip this time-consuming part and use `ANY_TOOLCHAIN=y`, but this not recommended.
-
-You can build them for all platforms: `make crossgcc CPUS=2` but this takes ~2 hours with Intel core2duo E8400.
-
-The best way, probably, is to build cross-compilers for your platform (this takes ~20 minutes with Intel core2duo E8400):
-
-```shell
-make crossgcc-i386 CPUS=2
-```
-
-### Save MAC-address of internal LAN
-
-Run `ip -c link show`, you will find MAC-address like 6c:f0:49:xx:xx:xx
-
-```
-1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
-    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
-2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
-    link/ether 6c:f0:49:xx:xx:xx brd ff:ff:ff:ff:ff:ff
-```
-
-## Configure
-
-Create file `payloads/external/SeaBIOS/.config_seabios`:
-
-```shell
-CONFIG_COREBOOT=y
-CONFIG_ATA_DMA=y
-CONFIG_VGA_COREBOOT=y
-```
-
-Edit file `configs/config.gigabyte_ga-g41m-es2l`, replace `CONFIG_REALTEK_8168_MACADDRESS` value with your MAC-address.
-
-Run
-
-```shell
-make defconfig KBUILD_DEFCONFIG="configs/config.gigabyte_ga-g41m-es2l"
-```
-
-## Build
-
-Just execute:
-
-```shell
-make
-```
-
-It takes ~2 minutes with Intel core2duo E8400.
-
-Example of last part in the output:
-
-```
-    CBFSPRINT  coreboot.rom
-
-FMAP REGION: COREBOOT
-Name                           Offset     Type           Size   Comp
-cbfs master header             0x0        cbfs header        32 none
-fallback/romstage              0x80       stage           62316 none
-cpu_microcode_blob.bin         0xf480     microcode      180224 none
-fallback/ramstage              0x3b500    stage           98745 none
-vgaroms/seavgabios.bin         0x53700    raw             28672 none
-config                         0x5a740    raw               301 none
-revision                       0x5a8c0    raw               675 none
-build_info                     0x5abc0    raw               103 none
-fallback/dsdt.aml              0x5ac80    raw              8447 none
-rt8168-macaddress              0x5cdc0    raw                17 none
-vbt.bin                        0x5ce40    raw               802 LZMA (1899 decompressed)
-cmos.default                   0x5d1c0    cmos_default      256 none
-cmos_layout.bin                0x5d300    cmos_layout      1040 none
-fallback/postcar               0x5d740    stage           20844 none
-fallback/payload               0x62900    simple elf      70270 none
-payload_config                 0x73bc0    raw              1699 none
-payload_revision               0x742c0    raw               237 none
-(empty)                        0x74400    null           482904 none
-bootblock                      0xea280    bootblock       23360 none
-    HOSTCC     cbfstool/ifwitool.o
-    HOSTCC     cbfstool/ifwitool (link)
-
-Built gigabyte/ga-g41m-es2l (GA-G41M-ES2L)
-```
-
-## Flashing coreboot
-
-```eval_rst
-In addition to the information here, please see the
-:doc:`../../flash_tutorial/index`.
-```
-
-### Do backup
-
-The above commands read the SPI flash chip(s), write into file and then verify content again with the chip:
-
-```shell
-sudo flashrom -p internal:dualbiosindex=0 -r m_bios.rom
-sudo flashrom -p internal:dualbiosindex=0 -v m_bios.rom
-sudo flashrom -p internal:dualbiosindex=1 -r b_bios.rom
-sudo flashrom -p internal:dualbiosindex=1 -v b_bios.rom
-```
-
-If access error appeared, then add `iomem=relaxed` to Linux kernel parameters and restart your Linux system.
-
-You can also repeat backup and compare checksums manually.
-
-Backup file should be stored elsewhere, so that in case the coreboot build is faulty, some external procedure can be used without having to extract the backup from the target device first.
-
-### Write new flash image
-
-Let's write new image into SPI flash chip, verify checksum again and erase second flash chip:
-
-```shell
-sudo flashrom -p internal:dualbiosindex=0 -w build/coreboot.rom
-sudo flashrom -p internal:dualbiosindex=0 -v build/coreboot.rom
-sudo flashrom -p internal:dualbiosindex=1 -E
-```
-
-## Set text mode for GRUB
-
-Update your `/etc/default/grub` with:
-
-```shell
-GRUB_TERMINAL=console
-```
-
-And recreate GRUB configuration `/boot/grub/grub.cfg` by command
-
-```shell
-sudo update-grub
-```
-
-## Boot with new firmware
-
-Restart your system:
-
-```shell
-sudo shutdown -r now
-```
-
-If it is needed, use <kbd>Esc</kbd> key to choose boot device.
-
-Remove `iomem=relaxed` from Linux kernel parameters.
-
-Enjoy!
-
-## Status
-
-```
-+-----------------------+--------------------------+--------+-------------------------------+
-| coreboot version      | Date of sources checkout | Status | Comment                       |
-+-----------------------+--------------------------+--------+-------------------------------+
-| 4.13-1531-g2fae1c0494 | 2021-01-28               | Good   |                               |
-+-----------------------+--------------------------+--------+-------------------------------+
-| 4.13-2182-g6410a0002f | 2021-02-18               | Good   |                               |
-+-----------------------+--------------------------+--------+-------------------------------+
-```
-
-### Known issues
-
-Lm-sensors shows wrong values from it87:
-
-```
-coretemp-isa-0000
-Adapter: ISA adapter
-Core 0:       +27.0°C  (high = +80.0°C, crit = +100.0°C)
-Core 1:       +31.0°C  (high = +80.0°C, crit = +100.0°C)
-
-it8718-isa-0290
-Adapter: ISA adapter
-in0:           1.06 V  (min =  +0.00 V, max =  +4.08 V)
-in1:           1.90 V  (min =  +0.00 V, max =  +4.08 V)
-in2:           3.34 V  (min =  +0.00 V, max =  +4.08 V)
-+5V:           2.96 V  (min =  +0.00 V, max =  +4.08 V)
-in4:         224.00 mV (min =  +0.00 V, max =  +4.08 V)
-in5:           4.08 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
-in6:           4.08 V  (min =  +0.00 V, max =  +4.08 V)  ALARM
-in7:           3.09 V  (min =  +0.00 V, max =  +4.08 V)
-Vbat:          2.82 V
-fan1:        1290 RPM  (min =    0 RPM)
-fan2:           0 RPM  (min =    0 RPM)
-temp1:        -54.0°C  (low  =  +0.0°C, high = +127.0°C)  sensor = thermistor
-temp2:         -1.0°C  (low  =  +0.0°C, high = +127.0°C)  sensor = thermistor
-temp3:        +44.0°C  (low  =  +0.0°C, high = +127.0°C)  sensor = thermal diode
-cpu0_vid:    +1.100 V
-intrusion0:  ALARM
-```
-
-### Working
-
-- RAM 1,2x1GiB DDR2 PC2-6400 Kingston KTC1G-UDIMM (1.8V, 2Rx8 ?)
-- RAM 1x1GiB DDR2 PC2-5300 Brooktree AU1G08E32-667P005 / Apogee AU1G082-667P005 CL6 (1.8V, 2Rx8 ?)
-- CPU E8400
-- ACPI
-- CPU frequency scaling
-- flashrom under coreboot
-- Gigabit Ethernet
-- Hardware monitoring
-- Integrated graphics
-- SATA
-- PCI POST card
-
-### Not working
-
-- SuperIO based fan control: PWM fan speed is not changing in depend of CPU temperature
-- RAM 1,2x4GiB DDR2 PC2-6400 Samsung M378T5263AZ3-CF7 (2Rx4 PC2-6400U-666-12-E3)
-
-### Not tested
-
-- KVM virtualization
-- Onboard audio
-- PCI
-- PCIe
-- PS/2 keyboard mouse (during payload, bootloader)
-- Serial port
-- USB (disabling XHCI controller makes to work as fallback USB2.0 ports)
-- IOMMU
-
-## Interesting facts
-
-`lshw` output is different for BIOS and coreboot.
-
-```shell
-diff --side-by-side --ignore-all-space --strip-trailing-cr \
-     Documentation/mainboard/gigabyte/ga-g41m-es2l_lshw_before_coreboot.txt \
-     Documentation/mainboard/gigabyte/ga-g41m-es2l_lshw_after_coreboot.txt
-```

Documentation/mainboard/gigabyte/ga-g41m-es2l_lshw_after_coreboot.txt

@@ -1,306 +0,0 @@
-my-desktop
-    description: Desktop Computer
-    product: GA-G41M-ES2L
-    vendor: GIGABYTE
-    version: 1.0
-    serial: 123456789
-    width: 64 bits
-    capabilities: smbios-3.0.0 dmi-3.0.0 smp vsyscall32
-    configuration: boot=normal chassis=desktop
-  *-core
-       description: Motherboard
-       product: GA-G41M-ES2L
-       vendor: GIGABYTE
-       physical id: 0
-       version: 1.0
-       serial: 123456789
-     *-firmware
-          description: BIOS
-          vendor: coreboot
-          physical id: 0
-          version: 4.13-1531-g2fae1c0494
-          date: 01/29/2021
-          size: 1MiB
-          capacity: 1MiB
-          capabilities: pci pcmcia upgrade bootselect acpi
-     *-cpu
-          description: CPU
-          product: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
-          vendor: Intel Corp.
-          physical id: 4
-          bus info: cpu@0
-          version: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
-          slot: CPU0
-          size: 2943MHz
-          capacity: 3GHz
-          width: 64 bits
-          capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm cpufreq
-        *-cache
-             description: L2 cache
-             physical id: 7
-             slot: CACHE2
-             size: 6MiB
-             capacity: 6MiB
-             capabilities: internal unified
-             configuration: level=2
-     *-memory
-          description: System memory
-          physical id: 1
-          size: 2GiB
-     *-pci
-          description: Host bridge
-          product: 4 Series Chipset DRAM Controller
-          vendor: Intel Corporation
-          physical id: 100
-          bus info: pci@0000:00:00.0
-          version: 03
-          width: 32 bits
-          clock: 33MHz
-        *-pci:0
-             description: PCI bridge
-             product: 4 Series Chipset PCI Express Root Port
-             vendor: Intel Corporation
-             physical id: 1
-             bus info: pci@0000:00:01.0
-             version: 03
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pci pm msi pciexpress normal_decode bus_master cap_list
-             configuration: driver=pcieport
-             resources: irq:24
-        *-display:0
-             description: VGA compatible controller
-             product: 4 Series Chipset Integrated Graphics Controller
-             vendor: Intel Corporation
-             physical id: 2
-             bus info: pci@0000:00:02.0
-             version: 03
-             width: 64 bits
-             clock: 33MHz
-             capabilities: msi pm vga_controller bus_master cap_list rom
-             configuration: driver=i915 latency=0
-             resources: irq:16 memory:90000000-903fffff memory:80000000-8fffffff ioport:20a0(size=8) memory:c0000-dffff
-        *-display:1 UNCLAIMED
-             description: Display controller
-             product: 4 Series Chipset Integrated Graphics Controller
-             vendor: Intel Corporation
-             physical id: 2.1
-             bus info: pci@0000:00:02.1
-             version: 03
-             width: 64 bits
-             clock: 33MHz
-             capabilities: pm cap_list
-             configuration: latency=0
-             resources: memory:90400000-904fffff
-        *-multimedia
-             description: Audio device
-             product: NM10/ICH7 Family High Definition Audio Controller
-             vendor: Intel Corporation
-             physical id: 1b
-             bus info: pci@0000:00:1b.0
-             version: 01
-             width: 64 bits
-             clock: 33MHz
-             capabilities: pm msi pciexpress bus_master cap_list
-             configuration: driver=snd_hda_intel latency=0
-             resources: irq:28 memory:90700000-90703fff
-        *-pci:1
-             description: PCI bridge
-             product: NM10/ICH7 Family PCI Express Port 1
-             vendor: Intel Corporation
-             physical id: 1c
-             bus info: pci@0000:00:1c.0
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
-             configuration: driver=pcieport
-             resources: irq:25
-        *-pci:2
-             description: PCI bridge
-             product: NM10/ICH7 Family PCI Express Port 2
-             vendor: Intel Corporation
-             physical id: 1c.1
-             bus info: pci@0000:00:1c.1
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
-             configuration: driver=pcieport
-             resources: irq:26 ioport:1000(size=4096) memory:90600000-906fffff ioport:90500000(size=1048576)
-           *-network
-                description: Ethernet interface
-                product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
-                vendor: Realtek Semiconductor Co., Ltd.
-                physical id: 0
-                bus info: pci@0000:03:00.0
-                logical name: eth0
-                version: 02
-                serial: 6c:f0:49:a3:e3:d5
-                size: 1Gbit/s
-                capacity: 1Gbit/s
-                width: 64 bits
-                clock: 33MHz
-                capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
-                configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=5.10.0-2-amd64 duplex=full ip=192.168.155.136 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
-                resources: irq:17 ioport:1000(size=256) memory:90510000-90510fff memory:90500000-9050ffff memory:90600000-9060ffff
-        *-usb:0
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #1
-             vendor: Intel Corporation
-             physical id: 1d
-             bus info: pci@0000:00:1d.0
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:23 ioport:2000(size=32)
-        *-usb:1
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #2
-             vendor: Intel Corporation
-             physical id: 1d.1
-             bus info: pci@0000:00:1d.1
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:19 ioport:2020(size=32)
-        *-usb:2
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #3
-             vendor: Intel Corporation
-             physical id: 1d.2
-             bus info: pci@0000:00:1d.2
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:18 ioport:2040(size=32)
-        *-usb:3
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #4
-             vendor: Intel Corporation
-             physical id: 1d.3
-             bus info: pci@0000:00:1d.3
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:16 ioport:2060(size=32)
-        *-usb:4
-             description: USB controller
-             product: NM10/ICH7 Family USB2 EHCI Controller
-             vendor: Intel Corporation
-             physical id: 1d.7
-             bus info: pci@0000:00:1d.7
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pm debug ehci bus_master cap_list
-             configuration: driver=ehci-pci latency=0
-             resources: irq:23 memory:90704000-907043ff
-        *-pci:3
-             description: PCI bridge
-             product: 82801 PCI Bridge
-             vendor: Intel Corporation
-             physical id: 1e
-             bus info: pci@0000:00:1e.0
-             version: e1
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pci subtractive_decode bus_master cap_list
-        *-isa
-             description: ISA bridge
-             product: 82801GB/GR (ICH7 Family) LPC Interface Bridge
-             vendor: Intel Corporation
-             physical id: 1f
-             bus info: pci@0000:00:1f.0
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: isa bus_master cap_list
-             configuration: driver=lpc_ich latency=0
-             resources: irq:0
-        *-ide:0
-             description: IDE interface
-             product: 82801G (ICH7 Family) IDE Controller
-             vendor: Intel Corporation
-             physical id: 1f.1
-             bus info: pci@0000:00:1f.1
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: ide isa_compat_mode pci_native_mode bus_master
-             configuration: driver=ata_piix latency=0
-             resources: irq:18 ioport:1f0(size=8) ioport:3f6 ioport:170(size=8) ioport:376 ioport:2080(size=16)
-        *-ide:1
-             description: IDE interface
-             product: NM10/ICH7 Family SATA Controller [IDE mode]
-             vendor: Intel Corporation
-             physical id: 1f.2
-             bus info: pci@0000:00:1f.2
-             logical name: scsi2
-             version: 01
-             width: 32 bits
-             clock: 66MHz
-             capabilities: ide pm isa_compat_mode pci_native_mode bus_master cap_list emulated
-             configuration: driver=ata_piix latency=0
-             resources: irq:19 ioport:20b8(size=8) ioport:20d0(size=4) ioport:20c0(size=8) ioport:20d4(size=4) ioport:2090(size=16)
-           *-disk
-                description: ATA Disk
-                product: WDC WD5000BPVT-2
-                vendor: Western Digital
-                physical id: 0.0.0
-                bus info: scsi@2:0.0.0
-                logical name: /dev/sda
-                version: 1A03
-                serial: WD-WXD1E71MYND4
-                size: 465GiB (500GB)
-                capabilities: gpt-1.00 partitioned partitioned:gpt
-                configuration: ansiversion=5 guid=868a1c85-f309-4f3d-8282-6b5c4c373275 logicalsectorsize=512 sectorsize=4096
-        *-serial
-             description: SMBus
-             product: NM10/ICH7 Family SMBus Controller
-             vendor: Intel Corporation
-             physical id: 1f.3
-             bus info: pci@0000:00:1f.3
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             configuration: driver=i801_smbus latency=0
-             resources: irq:19 ioport:400(size=32)
-     *-pnp00:00
-          product: PnP device PNP0c02
-          physical id: 2
-          capabilities: pnp
-          configuration: driver=system
-     *-pnp00:01
-          product: PnP device PNP0103
-          physical id: 3
-          capabilities: pnp
-          configuration: driver=system
-     *-pnp00:02
-          product: PnP device PNP0c02
-          physical id: 5
-          capabilities: pnp
-          configuration: driver=system
-     *-pnp00:03
-          product: PnP device PNP0b00
-          physical id: 6
-          capabilities: pnp
-          configuration: driver=rtc_cmos
-     *-pnp00:04
-          product: PnP device PNP0303
-          physical id: 7
-          capabilities: pnp
-          configuration: driver=i8042 kbd
-     *-pnp00:05
-          product: PnP device PNP0f13
-          physical id: 8
-          capabilities: pnp
-          configuration: driver=i8042 aux

Documentation/mainboard/gigabyte/ga-g41m-es2l_lshw_before_coreboot.txt

@@ -1,304 +0,0 @@
-my-desktop
-    description: Desktop Computer
-    product: G41M-ES2L
-    vendor: Gigabyte Technology Co., Ltd.
-    width: 64 bits
-    capabilities: smbios-2.4 dmi-2.4 smp vsyscall32
-    configuration: boot=normal chassis=desktop uuid=00000000-0000-0000-0000-6CF049A3E3D5
-  *-core
-       description: Motherboard
-       product: G41M-ES2L
-       vendor: Gigabyte Technology Co., Ltd.
-       physical id: 0
-     *-firmware
-          description: BIOS
-          vendor: Award Software International, Inc.
-          physical id: 0
-          version: F9
-          date: 06/21/2010
-          size: 128KiB
-          capacity: 1MiB
-          capabilities: pci pnp apm upgrade shadowing cdboot bootselect edd int13floppy360 int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer int10video acpi usb ls120boot zipboot biosbootspecification
-     *-cpu
-          description: CPU
-          product: Intel(R) Core(TM)2 Duo CPU     E8400  @ 3.00GHz
-          vendor: Intel Corp.
-          physical id: 4
-          bus info: cpu@0
-          version: Intel(R) Core(TM)2 Duo CPU
-          slot: Socket 775
-          size: 2631MHz
-          capacity: 4GHz
-          width: 64 bits
-          clock: 333MHz
-          capabilities: fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ht tm pbe syscall nx x86-64 constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 xsave lahf_lm pti tpr_shadow vnmi flexpriority vpid dtherm cpufreq
-        *-cache:0
-             description: L1 cache
-             physical id: a
-             slot: Internal Cache
-             size: 64KiB
-             capacity: 64KiB
-             capabilities: synchronous internal write-back
-             configuration: level=1
-        *-cache:1
-             description: L2 cache
-             physical id: b
-             slot: External Cache
-             size: 6MiB
-             capabilities: synchronous internal write-back
-             configuration: level=2
-     *-memory
-          description: System Memory
-          physical id: 19
-          slot: System board or motherboard
-          size: 2GiB
-        *-bank:0
-             description: DIMM 800 MHz (1.2 ns)
-             physical id: 0
-             slot: A0
-             size: 1GiB
-             width: 64 bits
-             clock: 800MHz (1.2ns)
-        *-bank:1
-             description: DIMM [empty]
-             physical id: 1
-             slot: A1
-        *-bank:2
-             description: DIMM 800 MHz (1.2 ns)
-             physical id: 2
-             slot: A2
-             size: 1GiB
-             width: 64 bits
-             clock: 800MHz (1.2ns)
-        *-bank:3
-             description: DIMM [empty]
-             physical id: 3
-             slot: A3
-     *-pci
-          description: Host bridge
-          product: 4 Series Chipset DRAM Controller
-          vendor: Intel Corporation
-          physical id: 100
-          bus info: pci@0000:00:00.0
-          version: 03
-          width: 32 bits
-          clock: 33MHz
-        *-display
-             description: VGA compatible controller
-             product: 4 Series Chipset Integrated Graphics Controller
-             vendor: Intel Corporation
-             physical id: 2
-             bus info: pci@0000:00:02.0
-             version: 03
-             width: 64 bits
-             clock: 33MHz
-             capabilities: msi pm vga_controller bus_master cap_list rom
-             configuration: driver=i915 latency=0
-             resources: irq:16 memory:fd800000-fdbfffff memory:d0000000-dfffffff ioport:ff00(size=8) memory:c0000-dffff
-        *-multimedia
-             description: Audio device
-             product: NM10/ICH7 Family High Definition Audio Controller
-             vendor: Intel Corporation
-             physical id: 1b
-             bus info: pci@0000:00:1b.0
-             version: 01
-             width: 64 bits
-             clock: 33MHz
-             capabilities: pm msi pciexpress bus_master cap_list
-             configuration: driver=snd_hda_intel latency=0
-             resources: irq:27 memory:fdff8000-fdffbfff
-        *-pci:0
-             description: PCI bridge
-             product: NM10/ICH7 Family PCI Express Port 1
-             vendor: Intel Corporation
-             physical id: 1c
-             bus info: pci@0000:00:1c.0
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
-             configuration: driver=pcieport
-             resources: irq:24 ioport:1000(size=4096) memory:7dd00000-7defffff ioport:80000000(size=2097152)
-        *-pci:1
-             description: PCI bridge
-             product: NM10/ICH7 Family PCI Express Port 2
-             vendor: Intel Corporation
-             physical id: 1c.1
-             bus info: pci@0000:00:1c.1
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pci pciexpress msi pm normal_decode bus_master cap_list
-             configuration: driver=pcieport
-             resources: irq:25 ioport:d000(size=4096) memory:fdd00000-fddfffff ioport:fde00000(size=1048576)
-           *-network
-                description: Ethernet interface
-                product: RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
-                vendor: Realtek Semiconductor Co., Ltd.
-                physical id: 0
-                bus info: pci@0000:02:00.0
-                logical name: eth0
-                version: 02
-                serial: 6c:f0:49:a3:e3:d5
-                size: 1Gbit/s
-                capacity: 1Gbit/s
-                width: 64 bits
-                clock: 33MHz
-                capabilities: pm msi pciexpress msix vpd bus_master cap_list rom ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd 1000bt 1000bt-fd autonegotiation
-                configuration: autonegotiation=on broadcast=yes driver=r8169 driverversion=5.10.0-2-amd64 duplex=full ip=192.168.155.137 latency=0 link=yes multicast=yes port=MII speed=1Gbit/s
-                resources: irq:17 ioport:de00(size=256) memory:fdeff000-fdefffff memory:fdee0000-fdeeffff memory:fdd00000-fdd0ffff
-        *-usb:0
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #1
-             vendor: Intel Corporation
-             physical id: 1d
-             bus info: pci@0000:00:1d.0
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:23 ioport:fe00(size=32)
-        *-usb:1
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #2
-             vendor: Intel Corporation
-             physical id: 1d.1
-             bus info: pci@0000:00:1d.1
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:19 ioport:fd00(size=32)
-        *-usb:2
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #3
-             vendor: Intel Corporation
-             physical id: 1d.2
-             bus info: pci@0000:00:1d.2
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:18 ioport:fc00(size=32)
-        *-usb:3
-             description: USB controller
-             product: NM10/ICH7 Family USB UHCI Controller #4
-             vendor: Intel Corporation
-             physical id: 1d.3
-             bus info: pci@0000:00:1d.3
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: uhci bus_master
-             configuration: driver=uhci_hcd latency=0
-             resources: irq:16 ioport:fb00(size=32)
-        *-usb:4
-             description: USB controller
-             product: NM10/ICH7 Family USB2 EHCI Controller
-             vendor: Intel Corporation
-             physical id: 1d.7
-             bus info: pci@0000:00:1d.7
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pm ehci bus_master cap_list
-             configuration: driver=ehci-pci latency=0
-             resources: irq:23 memory:fdfff000-fdfff3ff
-        *-pci:2
-             description: PCI bridge
-             product: 82801 PCI Bridge
-             vendor: Intel Corporation
-             physical id: 1e
-             bus info: pci@0000:00:1e.0
-             version: e1
-             width: 32 bits
-             clock: 33MHz
-             capabilities: pci subtractive_decode cap_list
-        *-isa
-             description: ISA bridge
-             product: 82801GB/GR (ICH7 Family) LPC Interface Bridge
-             vendor: Intel Corporation
-             physical id: 1f
-             bus info: pci@0000:00:1f.0
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: isa bus_master cap_list
-             configuration: driver=lpc_ich latency=0
-             resources: irq:0
-        *-ide:0
-             description: IDE interface
-             product: 82801G (ICH7 Family) IDE Controller
-             vendor: Intel Corporation
-             physical id: 1f.1
-             bus info: pci@0000:00:1f.1
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             capabilities: ide isa_compat_mode pci_native_mode bus_master
-             configuration: driver=ata_piix latency=0
-             resources: irq:18 ioport:1f0(size=8) ioport:3f6 ioport:170(size=8) ioport:376 ioport:f800(size=16)
-        *-ide:1
-             description: IDE interface
-             product: NM10/ICH7 Family SATA Controller [IDE mode]
-             vendor: Intel Corporation
-             physical id: 1f.2
-             bus info: pci@0000:00:1f.2
-             logical name: scsi2
-             version: 01
-             width: 32 bits
-             clock: 66MHz
-             capabilities: ide pm isa_compat_mode pci_native_mode bus_master cap_list emulated
-             configuration: driver=ata_piix latency=0
-             resources: irq:19 ioport:f700(size=8) ioport:f600(size=4) ioport:f500(size=8) ioport:f400(size=4) ioport:f300(size=16)
-           *-disk
-                description: ATA Disk
-                product: WDC WD5000BPVT-2
-                vendor: Western Digital
-                physical id: 0.0.0
-                bus info: scsi@2:0.0.0
-                logical name: /dev/sda
-                version: 1A03
-                serial: WD-WXD1E71MYND4
-                size: 465GiB (500GB)
-                capabilities: gpt-1.00 partitioned partitioned:gpt
-                configuration: ansiversion=5 guid=868a1c85-f309-4f3d-8282-6b5c4c373275 logicalsectorsize=512 sectorsize=4096
-        *-serial
-             description: SMBus
-             product: NM10/ICH7 Family SMBus Controller
-             vendor: Intel Corporation
-             physical id: 1f.3
-             bus info: pci@0000:00:1f.3
-             version: 01
-             width: 32 bits
-             clock: 33MHz
-             configuration: driver=i801_smbus latency=0
-             resources: irq:19 ioport:500(size=32)
-     *-pnp00:00
-          product: PnP device PNP0c02
-          physical id: 1
-          capabilities: pnp
-          configuration: driver=system
-     *-pnp00:01
-          product: PnP device PNP0b00
-          physical id: 2
-          capabilities: pnp
-          configuration: driver=rtc_cmos
-     *-pnp00:02
-          product: PnP device PNP0c02
-          physical id: 3
-          capabilities: pnp
-          configuration: driver=system
-     *-pnp00:03
-          product: PnP device PNP0c02
-          physical id: 5
-          capabilities: pnp
-          configuration: driver=system
-     *-pnp00:04
-          product: PnP device PNP0c01
-          physical id: 6
-          capabilities: pnp
-          configuration: driver=system

Documentation/mainboard/hp/2560p.md

@@ -1,99 +0,0 @@
-# HP EliteBook 2560p
-
-This page is about the notebook [HP EliteBook 2560p].
-
-## Release status
-
-HP EliteBook 2560p was released in 2011 and is now end of life.
-It can be bought from a secondhand market like Taobao or eBay.
-
-## Required proprietary blobs
-
-The following blobs are required to operate the hardware:
-1. EC firmware
-2. Intel ME firmware
-
-EC firmware can be retrieved from the HP firmware update image, or the firmware
-backup of the laptop. EC Firmware is part of the coreboot build process.
-The guide on extracting EC firmware and using it to build coreboot is in
-document [HP Laptops with KBC1126 Embedded Controller](hp_kbc1126_laptops).
-
-Intel ME firmware is in the flash chip. It is not needed when building coreboot.
-
-## Programming
-
-The flash chip is located between the memory slots and the PCH,
-covered by the base enclosure, which needs to be removed according to
-the [Maintenance and Service Guide] to access the flash chip. An SPI
-flash programmer using 3.3V voltage such as a ch341a programmer, and
-an SOIC-8 clip can be used to read and flash the chip in-circuit.
-
-Pin 1 of the flash chip is at the side near the PCH.
-
-![Flash Chip in 2560p](2560p_flash.webp)
-
-For more details have a look at the general [flashing tutorial].
-
-## Debugging
-
-The board can be debugged with EHCI debug. The EHCI debug port is the back
-bottom USB port.
-
-Schematic of this laptop can be found on [Lab One].
-
-## Test status
-
-### Known issues
-
-- GRUB payload freezes if at_keyboard module is in the GRUB image
-  ([bug #141])
-
-### Untested
-
-- Optical Drive
-- VGA
-- Fingerprint Reader
-- Modem
-
-### Working
-
-- Integrated graphics init with libgfxinit
-- SATA
-- Audio: speaker and microphone
-- Ethernet
-- WLAN
-- WWAN
-- Bluetooth
-- ExpressCard
-- SD Card Reader
-- SmartCard Reader
-- eSATA
-- USB
-- DisplayPort
-- Keyboard, touchpad and trackpoint
-- EC ACPI support and thermal control
-- Dock: all USB ports, DisplayPort, eSATA
-- TPM
-- Internal flashing when IFD is unlocked
-- Using `me_cleaner`
-
-
-## Technology
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| CPU              | Intel Sandy/Ivy Bridge (FCPGA988)                |
-+------------------+--------------------------------------------------+
-| PCH              | Intel Cougar Point QM67                          |
-+------------------+--------------------------------------------------+
-| EC               | SMSC KBC1126                                     |
-+------------------+--------------------------------------------------+
-| Coprocessor      | Intel Management Engine                          |
-+------------------+--------------------------------------------------+
-```
-
-[HP EliteBook 2560p]: https://support.hp.com/us-en/product/hp-elitebook-2560p-notebook-pc/5071201
-[Maintenance and Service Guide]: http://h10032.www1.hp.com/ctg/Manual/c03011618
-[flashing tutorial]: ../../flash_tutorial/ext_power.md
-[Lab One]: https://www.laboneinside.com/hp-elitebook-2560p-schematic-diagram/
-[bug #141]: https://ticket.coreboot.org/issues/141

Documentation/mainboard/hp/8760w.md

@@ -36,7 +36,7 @@ checkout the [code on gerrit] to build coreboot for the laptop.
 
 ## Flashing instructions
 
-HP EliteBook 8760w has an 8 MiB SOIC-8 flash chip on the bottom of the
+HP EliteBook 8760w has an 8MB SOIC-8 flash chip on the bottom of the
 mainboard. You just need to remove the service cover, and use an SOIC-8
 clip to read and flash the chip.
 

Documentation/mainboard/hp/folio_9480m.md

@@ -1,156 +0,0 @@
-# HP EliteBook Folio 9480m
-
-This page is about the notebook [HP EliteBook Folio 9480m].
-
-## Release status
-
-HP EliteBook Folio 9480m was released in 2014 and is now end of life.
-It can be bought from a secondhand market like Taobao or eBay.
-
-## Required proprietary blobs
-
-The following blobs are required to operate the hardware:
-
-1. EC firmware
-2. Intel ME firmware
-3. mrc.bin
-
-HP EliteBook Folio 9480m uses SMSC MEC1322 as its embedded controller.
-The EC firmware is stored in the flash chip, but we don't need to touch it
-or use it in the coreboot build process.
-
-Intel ME firmware is in the flash chip. It is not needed when building coreboot.
-
-The Haswell memory reference code binary is needed when building coreboot.
-Please see [mrc.bin](../../northbridge/intel/haswell/mrc.bin).
-
-## Programming
-
-Before flashing, remove the battery and the hard drive cover according to the
-[Maintenance and Service Guide] of this laptop.
-
-![Two flash chips of HP EliteBook Folio 9480m](folio_9480m_flash.webp)
-
-HP EliteBook Folio 9480m has two flash chips, a 16MiB system flash, and a 2MiB
-private flash. To install coreboot, we need to program both flash chips.
-Read [HP Sure Start] for detailed information.
-
-To access the system flash, we need to connect the AC adapter to the machine,
-then clip on the flash chip with an SOIC-8 clip. An [STM32-based flash programmer]
-made with an STM32 development board is tested to work.
-
-To access the private flash chip, we can use a ch341a based flash programmer and
-flash the chip with the AC adapter disconnected.
-
-Before flashing coreboot, we need to do the following:
-
-1. Erase the private flash to disable the IFD protection
-2. Modify the IFD to shrink the BIOS region, so that we'll not use or override
-   the protected bootblock and PEI region, as well as the EC firmware
-
-To erase the private flash chip, attach it with the flash programmer via the SOIC-8 clip,
-then run:
-
-    flashrom -p <programmer> --erase
-
-To modify the IFD, we need a new flash layout. The flash layout of the OEM firmware is:
-
-    00000000:00000fff fd
-    00001000:00002fff gbe
-    00003000:005fffff me
-    00600000:00ffffff bios
-
-The default coreboot configuration sets the flash chip size to 12MiB, so set the end of the
-BIOS region to 0xbfffff in the new layout. The modified IFD is as follows (Platform Data
-region pd is the region protected by HP Sure Start):
-
-    00000000:00000fff fd
-    00001000:00002fff gbe
-    00003000:005fffff me
-    00600000:00bfffff bios
-    00eb5000:00ffffff pd
-
-Write the above layout in a file, and use ifdtool to modify the IFD of a flash image.
-Suppose the above layout file is ``layout.txt`` and the origin content of the system flash
-is in ``factory-sys.rom``, run:
-
-    ifdtool -n layout.txt factory-sys.rom
-
-Then a flash image with a new IFD will be in ``factory-sys.rom.new``.
-
-Flash the IFD of the system flash:
-
-    flashrom -p <programmer> --ifd -i fd -w factory-sys.rom.new
-
-Then flash the coreboot image:
-
-    # first extend the 12M coreboot.rom to 16M
-    fallocate -l 16M build/coreboot.rom
-    flashrom -p <programmer> --ifd -i bios -w build/coreboot.rom
-
-After coreboot is installed, the coreboot firmware can be updated with internal flashing:
-
-    flashrom -p internal --ifd -i bios --noverify-all -w build/coreboot.rom
-
-## Debugging
-
-The board can be debugged with EHCI debug. The EHCI debug port is the USB port on the left.
-
-## Test status
-
-### Known issues
-
-- GRUB payload freezes just like previous EliteBook laptops
-- Sometimes the PCIe WLAN module can not be found in the OS after booting to the system
-- Sometimes all the USB devices can not be found in the OS after S3 resume
-
-### Untested
-
-- Fingerprint reader
-- Smart Card reader
-
-### Working
-
-- i5-4310U CPU with 4G+4G memory
-- SATA and M.2 SATA disk
-- Ethernet
-- WLAN
-- WWAN
-- SD card reader
-- USB
-- Keyboard and touchpad
-- DisplayPort
-- VGA
-- Dock
-- Audio output from speaker and headphone jack
-- Webcam
-- TPM
-- EC ACPI
-- S3 resume
-- Arch Linux with Linux 5.8.9
-- Memory initialization with mrc.bin version 1.6.1 Build 2
-- Graphics initialization with libgfxinit
-- Payload: SeaBIOS, Tianocore
-- EC firmware
-  - KBC Revision 92.15 from OEM firmware version 01.33
-  - KBC Revision 92.17 from OEM firmware version 01.50
-- Internal flashing under coreboot
-
-## Technology
-
-```eval_rst
-+------------------+-----------------------------+
-| CPU              | Intel Haswell-ULT           |
-+------------------+-----------------------------+
-| PCH              | Intel Lynx Point Low Power  |
-+------------------+-----------------------------+
-| EC               | SMSC MEC1322                |
-+------------------+-----------------------------+
-| Coprocessor      | Intel Management Engine     |
-+------------------+-----------------------------+
-```
-
-[HP EliteBook Folio 9480m]: https://support.hp.com/us-en/product/hp-elitebook-folio-9480m-notebook-pc/7089926
-[Maintenance and Service Guide]: http://h10032.www1.hp.com/ctg/Manual/c05228980
-[STM32-based flash programmer]: https://github.com/dword1511/stm32-vserprog
-[HP Sure Start]: hp_sure_start.md

Documentation/mainboard/hp/hp_sure_start.md

@@ -1,60 +0,0 @@
-# HP Sure Start
-
-According to the [HP Sure Start Technical Whitepaper], HP Sure Start is a chipset
-and processor independent firmware intrusion detection and automatic repair system.
-It is implemented in HP notebooks since 2013, and desktops since 2015.
-
-This document talks about some mechanism of HP Sure Start on some machines, and
-the method to bypass it.
-
-## Laptops with SMSC MEC1322 embedded controller
-
-Haswell EliteBook, ZBook and ProBook 600 series use SMSC MEC1322 embedded controller.
-The EC firmware implements HP Sure Start.
-
-A Haswell EliteBook has two flash chips. According to the strings in the EC firmware,
-the 16MiB flash chip that stores the BIOS firmware is called the *system flash*, and
-the 2MiB flash chip that stores part of the system flash content is called the
-*private flash*. A Haswell ProBook 600 series laptop also uses MEC1322 and has similar
-EC firmware, but the HP Sure Start functions are not enabled.
-
-The private flash is connected to the EC, and is not accessible by the OS.
-It contains the following:
-
-- HP Sure Start policy header (starting with the string "POLI")
-- A copy of the Intel Flash Descriptor
-- A copy of the GbE firmware
-- Machine Unique Data (MUD)
-- Hashes of the IFD, GbE firmware and MUD, the hash algorithm is unknown
-- A copy of the bootblock, UEFI PEI stage, and microcode
-
-If the IFD of the system flash does not match the hash in the private flash, for example,
-modifying the IFD with ``ifdtool -u`` or ``me_cleaner -S``, the EC will recover the IFD.
-
-If the content of the private flash is lost, the EC firmware will still copy the IFD,
-bootblock and PEI to the private flash. However, the IFD is not protected after that.
-
-HP Sure Start also verifies bootblock, PEI, and microcode without using the private flash.
-EC firmware reads them from an absolute address of the system flash chip, which is
-hardcoded in the EC firmware. It looks like this verification is done with a digital
-signature. If the PEI volume is modified, EC firmware will recover it using the copy
-in the private flash. If the private flash has no valid copies of the PEI volume, and
-the PEI volume is modified, the machine will refuse to boot with the CapsLock LED blinking.
-
-## Bypassing HP Sure Start
-
-First search the mainboard for the flash chips. If there are two flash chips,
-the smaller one may be the private flash.
-
-For Intel boards, try to modify the IFD with ``ifdtool -u``, power on and shut down
-the machine, then read the flash again. If the IFD is not modified, it is likely to
-be recovered from the private flash. Find the private flash and erase it, then the IFD
-can be modified.
-
-To bypass the bootblock and PEI verification, we can modify the IFD to make the
-BIOS region not overlap with the protected region. Since the EC firmware is usually
-located at the high address of the flash chip (and in the protected region),
-we can leave it untouched, and do not need to extract the EC firmware to put it in
-the coreboot image.
-
-[HP Sure Start Technical Whitepaper]: http://h10032.www1.hp.com/ctg/Manual/c05163901

Documentation/mainboard/index.md

@@ -16,7 +16,6 @@ This section contains documentation about coreboot on specific mainboards.
 
 ## ASUS
 
-- [A88XM-E](asus/a88xm-e.md)
 - [F2A85-M](asus/f2a85-m.md)
 - [P5Q](asus/p5q.md)
 - [P8H61-M LX](asus/p8h61-m_lx.md)
@@ -27,10 +26,6 @@ This section contains documentation about coreboot on specific mainboards.
 
 - [CN81XX EVB SFF](cavium/cn8100_sff_evb.md)
 
-## Clevo
-
-- [N130WU / N131WU](clevo/n130wu/index.md)
-
 ## Dell
 
 - [OptiPlex 9010 SFF](dell/optiplex_9010.md)
@@ -42,8 +37,6 @@ The boards in this section are not real mainboards, but emulators.
 - [Spike RISC-V emulator](emulation/spike-riscv.md)
 - [Qemu RISC-V emulator](emulation/qemu-riscv.md)
 - [Qemu AArch64 emulator](emulation/qemu-aarch64.md)
-- [Qemu x86 Q35](emulation/qemu-q35.md)
-- [Qemu x86 PC](emulation/qemu-i440fx.md)
 
 ## Facebook
 
@@ -56,7 +49,6 @@ The boards in this section are not real mainboards, but emulators.
 
 ## Gigabyte
 
-- [GA-G41M-ES2L](gigabyte/ga-g41m-es2l.md)
 - [GA-H61M-S2PV](gigabyte/ga-h61m-s2pv.md)
 
 ## HP
@@ -67,10 +59,7 @@ The boards in this section are not real mainboards, but emulators.
 ### EliteBook series
 
 - [HP Laptops with KBC1126 EC](hp/hp_kbc1126_laptops.md)
-- [HP Sure Start](hp/hp_sure_start.md)
-- [EliteBook 2560p](hp/2560p.md)
 - [EliteBook 8760w](hp/8760w.md)
-- [EliteBook Folio 9480m](hp/folio_9480m.md)
 
 ## Intel
 
@@ -78,10 +67,6 @@ The boards in this section are not real mainboards, but emulators.
 - [IceLake RVP](intel/icelake_rvp.md)
 - [KBLRVP11](intel/kblrvp11.md)
 
-## Kontron
-
-- [mAL-10](kontron/mal10.md)
-
 ## Lenovo
 
 - [Mainboard codenames](lenovo/codenames.md)
@@ -91,15 +76,15 @@ The boards in this section are not real mainboards, but emulators.
 - [X2xx common](lenovo/x2xx_series.md)
 - [vboot](lenovo/vboot.md)
 
+### Arrandale series
+
+- [T410](lenovo/t410.md)
+
 ### GM45 series
 
 - [X200 / T400 / T500 / X301 common](lenovo/montevina_series.md)
 - [X301](lenovo/x301.md)
 
-### Arrandale series
-
-- [T410](lenovo/t410.md)
-
 ### Sandy Bridge series
 
 - [T420](lenovo/t420.md)
@@ -130,7 +115,6 @@ The boards in this section are not real mainboards, but emulators.
 
 ## OCP
 
-- [Delta Lake](ocp/deltalake.md)
 - [Tioga Pass](ocp/tiogapass.md)
 
 ## Open Cellular
@@ -151,10 +135,6 @@ The boards in this section are not real mainboards, but emulators.
 
 - [Hermes](prodrive/hermes.md)
 
-## Purism
-
-- [Librem Mini](purism/librem_mini.md)
-
 ## Protectli
 
 - [FW2B / FW4B](protectli/fw2b_fw4b.md)
@@ -176,14 +156,7 @@ The boards in this section are not real mainboards, but emulators.
 
 ## System76
 
-- [Gazelle 15](system76/gaze15.md)
 - [Lemur Pro](system76/lemp9.md)
-- [Oryx Pro 5](system76/oryp5.md)
-- [Oryx Pro 6](system76/oryp6.md)
-
-## Texas Instruments
-
-- [Beaglebone Black](ti/beaglebone-black.md)
 
 ## UP
 

Documentation/mainboard/intel/kblrvp11.md

@@ -60,7 +60,7 @@ $ flashrom -p internal --ifd -i bios -w coreboot.rom --noverify-all
 2. Make sure power supply is disconnected from board.
 3. Connect Dediprog SF600 to header at J7H1.
 4. Ensure that "currently working on" is in "application memory chip 1"
-5. Go to "file" and select the .rom file (16 MiB) to program chip1.
+5. Go to "file" and select the .rom file (16 MB) to program chip1.
 6. Execute the batch operation to erase and program the chip.
 
 ## Technology

Documentation/mainboard/kontron/mal10.md

@@ -1,106 +0,0 @@
-# Kontron mAL10 Computer-on-Modules platform
-
-The Kontron [mAL10] COMe is a credit card sized Computer-on-Modules
-platform based on the Intel Atom E3900 Series, Pentium and Celeron
-processors.
-
-## Technology
-
-```eval_rst
-+------------------+----------------------------------+
-| COMe Type        | mini pin-out type 10             |
-+------------------+----------------------------------+
-| SoC              | Intel Atom x5-E3940 (4 core)     |
-+------------------+----------------------------------+
-| GPU              | Intel HD Graphics 500            |
-+------------------+----------------------------------+
-| Coprocessor      | Intel TXE 3.0                    |
-+------------------+----------------------------------+
-| RAM              | 8GB DDR3L                        |
-+------------------+----------------------------------+
-| eMMC Flash       | 32GB eMMC pSLC                   |
-+------------------+----------------------------------+
-| USB3             | x2                               |
-+------------------+----------------------------------+
-| USB2             | x6                               |
-+------------------+----------------------------------+
-| SATA             | x2                               |
-+------------------+----------------------------------+
-| LAN              | Intel I210IT, I211AT             |
-+------------------+----------------------------------+
-| Super IO/EC      | Kontron CPLD/EC                  |
-+------------------+----------------------------------+
-| HWM              | NCT7802                          |
-+------------------+----------------------------------+
-```
-
-## Building coreboot
-
-The following commands will build a working image:
-
-```bash
-make distclean
-make defconfig KBUILD_DEFCONFIG=configs/config.kontron_mal10
-make
-```
-## Payloads
-- SeaBIOS
-- Tianocore
-- Linux as payload
-
-## Flashing coreboot
-
-The SPI flash can be accessed internally using [flashrom].
-The following command is used to flash BIOS region.
-
-```bash
-$ flashrom -p internal --ifd -i bios -w coreboot.rom --noverify-all
-```
-
-## Hardware Monitor
-
-The Nuvoton [NCT7802Y] is a hardware monitoring IC, capable of monitor critical
-system parameters including power supply voltages, fan speeds, and temperatures.
-The remote inputs can be connected to CPU/GPU thermal diode or any thermal diode
-sensors and thermistor.
-
-- 6 temperature sensors;
-- 5 voltage sensors;
-- 3 fan speed sensors;
-- 4 sets of temperature setting points.
-
-PECI is not supported by Apollo Lake Pentium/Celeron/Atom processors and the CPU
-temperature value is taken from a thermal resistor (NTC) that is placed very
-close to the CPU.
-
-## Known issues
-
-- Works only with Tianocore "UEFIPayload" payload edk2-stable201903-1569-g3e63a91
-  Booting with the "CorebootPayload" [crashes].
-- Tianocore outputs video through an external GPU only.
-
-## Untested
-
-- IGD/LVDS
-- SDIO
-
-## Tested and working
-
-- Kontron CPLD/EC (Serial ports, I2C port)
-- NCT7802 [HWM](#Hardware Monitor)
-- USB2/3
-- Gigabit Ethernet ports
-- eMMC
-- SATA
-- PCIe ports
-- IGD/DP
-
-## TODO
-- Onboard audio (codec IDT 92HD73C1X5, currently disabled)
-- S3 suspend/resume
-
-[mAL10]: https://www.kontron.com/products/iot/iot-industry-4.0/iot-ready-boards-and-modules/com-express/com-express-mini/come-mal10-e2-.html
-[W25Q128FV]: https://www.winbond.com/resource-files/w25q128fv%20rev.m%2005132016%20kms.pdf
-[flashrom]: https://flashrom.org/Flashrom
-[NCT7802Y]: https://www.nuvoton.com/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/?__locale=en
-[crashes]: https://pastebin.com/cpCfrPCL

Documentation/mainboard/lenovo/Ivy_Bridge_series.md

@@ -25,7 +25,7 @@ This information is valid for all supported models, except T430s, [T431s](t431s.
 
 ## Installation instructions
 * Update the EC firmware, as there's no support for EC updates in coreboot.
-* Do **NOT** accidentally swap pins or power on the board while a SPI flasher
+* Do **NOT** accidently swap pins or power on the board while a SPI flasher
   is connected. It will permanently brick your device.
 * It's recommended to only flash the BIOS region. In that case you don't
   need to extract blobs from vendor firmware.

Documentation/mainboard/lenovo/Sandy_Bridge_series.md

@@ -22,12 +22,8 @@
 ```
 
 ## Installation instructions
-
-Flashing coreboot for the first time needs to be done using an external
-programmer, because vendor firmware prevents rewriting the BIOS region.
-
 * Update the EC firmware, as there's no support for EC updates in coreboot.
-* Do **NOT** accidentally swap pins or power on the board while a SPI flasher
+* Do **NOT** accidently swap pins or power on the board while a SPI flasher
   is connected. It will destroy your device.
 * It's recommended to only flash the BIOS region. In that case you don't
   need to extract blobs from vendor firmware.

Documentation/mainboard/lenovo/montevina_series.md

@@ -9,15 +9,6 @@ the chip in your machine through flashrom:
 Note that this does not allow you to determine whether the chip is in a SOIC-8
 or a SOIC-16 package.
 
-## Installing with ME firmware
-
-To install coreboot and keep ME working, you don't need to do anything special
-with the flash descriptor. Only flash the `bios` region externally and don't
-touch any other regions:
-```console
-# flashrom -p YOUR_PROGRAMMER -w coreboot.rom --ifd -i bios
-```
-
 ## Installing without ME firmware
 
 ```eval_rst
@@ -44,7 +35,7 @@ $ ifdtool -x backup.rom
 
 Now you need to patch the flash descriptor. You can either [modify the one from
 your backup with **ifdtool**](#modifying-flash-descriptor-using-ifdtool), or
-[use one from the coreboot repository](#using-checked-in-flash-descriptor-via-bincfg).
+[generate a completely new one with **bincfg**](#creating-a-new-flash-descriptor-using-bincfg).
 
 #### Modifying flash descriptor using ifdtool
 
@@ -53,13 +44,13 @@ the `new_layout.txt` file:
 
 ```eval_rst
 +---------------------------+---------------------------+---------------------------+
-| 4 MiB chip                | 8 MiB chip                | 16 MiB chip               |
+| 4 MB chip                 | 8 MB chip                 | 16 MB chip                |
 +===========================+===========================+===========================+
 | .. code-block:: none      | .. code-block:: none      | .. code-block:: none      |
 |                           |                           |                           |
 |    00000000:00000fff fd   |    00000000:00000fff fd   |    00000000:00000fff fd   |
 |    00001000:00002fff gbe  |    00001000:00002fff gbe  |    00001000:00002fff gbe  |
-|    00003000:003fffff bios |    00003000:007fffff bios |    00003000:00ffffff bios |
+|    00003000:003fffff bios |    00003000:007fffff bios |    00003000:01ffffff bios |
 |    00fff000:00000fff pd   |    00fff000:00000fff pd   |    00fff000:00000fff pd   |
 |    00fff000:00000fff me   |    00fff000:00000fff me   |    00fff000:00000fff me   |
 +---------------------------+---------------------------+---------------------------+
@@ -88,37 +79,33 @@ $ mv flashregion_0_flashdescriptor.bin.new.new flashregion_0_flashdescriptor.bin
 
 Continue to the [Configuring coreboot](#configuring-coreboot) section.
 
-#### Using checked-in flash descriptor via bincfg
+#### Creating a new flash descriptor using bincfg
 
-There is a copy of an X200's flash descriptor checked into the coreboot
-repository. It is supposed to work for the T400/T500 as well. The descriptor
-can be converted back to its binary form using a tool called **bincfg**. Go
-to `util/bincfg` and build it:
+There is a tool to generate a modified flash descriptor called **bincfg**. Go to
+`util/bincfg` and build it:
 ```console
 $ cd util/bincfg
 $ make
 ```
 
-If your flash is not 8 MiB, you need to change values of `flcomp_density1` and
-`flreg1_limit` in the `ifd-x200.set` file according to following table:
+If your flash is not 8 MB, you need to change values of `flcomp_density1` and
+`flreg1_limit` in the ifd-x200.set file according to following table:
 
 ```eval_rst
 +-----------------+-------+-------+--------+
-|                 | 4 MiB | 8 MiB | 16 MiB |
+|                 | 4 MB  | 8 MB  | 16 MB  |
 +=================+=======+=======+========+
 | flcomp_density1 | 0x3   | 0x4   | 0x5    |
 +-----------------+-------+-------+--------+
-| flreg1_limit    | 0x3ff | 0x7ff | 0xfff  |
+| flreg1_limit    | 0x3ff | 0x7ff | 0x1fff |
 +-----------------+-------+-------+--------+
 ```
 
-Then convert the flash descriptor:
+Then create the flash descriptor:
 ```console
-$ make gen-ifd-x200
+$ ./bincfg ifd-x200.spec ifd-x200.set ifd.bin
 ```
 
-It will be saved to the `flashregion_0_fd.bin` file.
-
 #### Configuring coreboot
 
 Now configure coreboot. You need to select correct chip size and specify paths
@@ -127,11 +114,11 @@ to flash descriptor and gbe dump.
 ```
 Mainboard --->
     ROM chip size (8192 KB (8 MB)) # According to your chip
-    (0x7fd000) Size of CBFS filesystem in ROM # or 0x3fd000 for 4 MiB chip / 0xffd000 for 16 MiB chip
+    (0x7fd000) Size of CBFS filesystem in ROM # or 0x3fd000 for 4 MB chip / 0x1ffd000 for 16 MB chip
 
 Chipset --->
     [*] Add Intel descriptor.bin file
-    # Note: if you used bincfg, specify path to generated util/bincfg/flashregion_0_fd.bin
+    # Note: if you used bincfg, specify path to generated util/bincfg/ifd.bin
     (/path/to/flashregion_0_flashdescriptor.bin) Path and filename of the descriptor.bin file
 
     [*] Add gigabit ethernet configuration
@@ -140,13 +127,22 @@ Chipset --->
 
 Then build coreboot and flash whole `build/coreboot.rom` to the chip.
 
+## Installing with ME firmware
+
+To install coreboot and keep ME working, you don't need to do anything special
+with the flash descriptor. Just flash only `bios` externally and don't touch any
+other regions:
+```console
+# flashrom -p YOUR_PROGRAMMER -w coreboot.rom --ifd -i bios
+```
+
 ## Flash layout
 
 The flash layouts of the OEM firmware are as follows:
 
 ```eval_rst
 +---------------------------------+---------------------------------+
-| 4 MiB chip                      | 8 MiB chip                      |
+| 4 MB chip                       | 8 MB chip                       |
 +=================================+=================================+
 | .. code-block:: none            | .. code-block:: none            |
 |                                 |                                 |
@@ -163,6 +159,6 @@ The flash layouts of the OEM firmware are as follows:
 On each boot of vendor BIOS `ec` area in flash is checked for having firmware
 there, and if there is one, it proceedes to update firmware on H8S/2116 (when
 both external power and main battery are attached). Once update is performed,
-first 64 KiB of `ec` area is erased. Visit
+first 64 KB of `ec` area is erased. Visit
 [thinkpad-ec repository](https://github.com/hamishcoleman/thinkpad-ec) to learn
 more about how to extract EC firmware from vendor updates.

Documentation/mainboard/lenovo/t420.md

@@ -18,40 +18,6 @@ the general [flashing tutorial].
 
 Steps to access the flash IC are described here [T4xx series].
 
-## Working
- * CPU: Sandy Bridge i5-2520M, i7-2670QM
- * RAM module combinations of 2G+0, 2G+2G, 4G+0
- * mSATA
- * USB
- * Video (Intel integrated)
- * Sound (integrated speakers, integrated mic, external headphones, external mic)
- * LAN
- * Mini-PCIe slots (WLAN)
- * Bluetooth
- * Linux
- * Windows 10 (through SeaBIOS as payload, using a VGA BIOS)
- * DVD-ROM drive
- * SD card slot
- * TrackPoint
- * Touchpad
- * Webcam
- * Fn hotkeys (backlight control, thinklight)
- * Thinklight
- * Mute button (Speaker only)
- * Mini Jack audio (headphones)
- * Suspend (Linux)
-
-## Not tested
- * DSub (VGA) out
- * DisplayPort out
- * eSATA
- * ExpressCard
- * WWAN
-
-## Not working/TODOs
- * Mutemic button doesn't mute
- * Suspend (Windows 10)
-
 [T4xx series]: t4xx_series.md
 [flashing tutorial]: ../../flash_tutorial/ext_power.md
 [T420 / T520 / X220 / T420s / W520 common]: Sandy_Bridge_series.md

Documentation/mainboard/lenovo/t440p.md

@@ -8,15 +8,15 @@ Please see [mrc.bin](../../northbridge/intel/haswell/mrc.bin).
 
 ## Flashing instructions
 
-T440p has two flash chips, an 8 MiB W25Q64FV and a 4 MiB W25Q32FV. To flash
+T440p has two flash chips, an 8MB W25Q64FV and a 4MB W25Q32FV. To flash
 coreboot, you just need to remove the big door according to the T440
-[Hardware Maintenance Manual] and flash the 4 MiB chip.
+[Hardware Maintenance Manual] and flash the 4MB chip.
 
 ![T440p flash chip](t440p_flash_chip.jpg)
 
-To access the 8 MiB chip, you need to remove the base cover.
+To access the 8MB chip, you need to remove the base cover.
 
-![T440p 8 MiB flash chip](t440p_all_flash_chips.jpg)
+![T440p 8MB flash chip](t440p_all_flash_chips.jpg)
 
 The flash layout of the OEM firmware is as follows:
 
@@ -30,6 +30,7 @@ the laptop able to power on.
 
 ## Known Issues
 
+- No audio output when using a headphone
 - Cannot get the mainboard serial number from the mainboard: the OEM
   UEFI firmware gets the serial number from an "emulated EEPROM" via
   I/O port 0x1630/0x1634, but it's still unknown how to make it work

Documentation/mainboard/msi/ms7707/ms7707.md

@@ -2,7 +2,7 @@
 
 * MSI MS-7707 V1.1 (Medion OEM Akoya P4385D MSN10014555)
 * SandyBridge Intel P67 (BD82x6x)
-* Winbond 25Q32BV (4 MiB)
+* Winbond 25Q32BV (4MB)
 * Fintek F71808A SuperIO
 * Intel 82579V Gigabit
 * NEC uPD720200 USB 3.0 Host Controller

Documentation/mainboard/ocp/deltalake.md

@@ -8,26 +8,22 @@ Delta Lake server platform.
 OCP Delta Lake server platform is a component of multi-host server system
 Yosemite-V3. Both were announced by Facebook and Intel in [OCP virtual summit 2020].
 
-Delta Lake server is a single socket Cooper Lake Scalable Processor (CPX-SP) server.
+Delta Lake server is a single socket Cooper Lake Scalable Processor server.
 
 Yosemite-V3 has multiple configurations. Depending on configurations, it may
-host up to 4 Delta Lake servers (blades) in one sled.
+host up to 4 Delta Lake servers in one sled.
 
-The Yosemite-V3 system is in mass production. Facebook, 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 DVT exit equivalent status.
+Yosemite-V3 and Delta Lake are currently in DVT phase. Facebook, Intel and partners
+jointly develop FSP/coreboot/LinuxBoot stack on Delta Lake as an alternative solution.
 
 ## Required blobs
 
-Delta Lake server OSF solution requires:
+This board currently requires:
 - FSP blob: The blob (Intel Cooper Lake Scalable Processor Firmware Support Package)
-  is not yet available to the public. It will be made public soon by Intel 
-  with redistributable license.
-- Microcode: Available through github.com:otcshare/Intel-Generic-Microcode.git.
-- ME binary: Ignition binary will be made public soon by Intel with
-  redistributable license.
-- ACM binaries: only required for CBnT enablement. Available under NDA with Intel.
+  is not yet available to the public. It will be made public some time after the MP
+  (Mass Production) of CooperLake Scalable Processor when the FSP is mature.
+- Microcode: Not yet available to the public.
+- ME binary: Not yet available to the public.
 
 ## Payload
 - LinuxBoot: This is necessary only if you use LinuxBoot as coreboot payload.
@@ -50,6 +46,36 @@ To power off/on the host:
 To connect to console through SOL (Serial Over Lan):
     sol-util slotx
 
+## Working features
+The solution is developed using LinuxBoot payload with Linux kernel 5.2.9, and [u-root]
+as initramfs.
+- SMBIOS:
+    - Type 0 -- BIOS Information
+    - Type 1 -- System Information
+    - Type 2 -- Baseboard Information
+    - Type 3 -- System Enclosure or Chassis
+    - Type 4 -- Processor Information
+    - Type 8 -- Port Connector Information
+    - Type 9 -- PCI Slot Information
+    - Type 11 -- OEM String
+    - Type 13 -- BIOS Language Information
+    - Type 16 -- Physical Memory Array
+    - Type 19 -- Memory Array Mapped Address
+    - Type 127 -- End-of-Table
+
+- BMC integration:
+    - BMC readiness check
+    - IPMI commands
+    - watchdog timer
+    - POST complete pin acknowledgement
+- SEL record generation
+- Early serial output
+- port 80h direct to GPIO
+- ACPI tables: APIC/DSDT/FACP/FACS/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
+- Skipping memory training upon subsequent reboots by using MRC cache
+- BMC crash dump
+- Error injection through ITP
+
 ## Firmware configurations
 [ChromeOS VPD] is used to store most of the firmware configurations.
 RO_VPD region holds default values, while RW_VPD region holds customized
@@ -58,105 +84,29 @@ values.
 VPD variables supported are:
 - firmware_version: This variable holds overall firmware version. coreboot
   uses that value to populate smbios type 1 version field.
-- bmc_bootorder_override: When it's set to 1 IPMI OEM command can override boot
-  order. The boot order override is done in the u-root LinuxBoot payload.
-- systemboot_log_level: u-root package systemboot log levels, would be mapped to
-  quiet/verbose in systemboot as that is all we have for now. 5 to 8 would be
-  mapped to verbose, 0 to 4 and 9 would be mapped to quiet.
-- VPDs affecting coreboot are listed/documented in src/mainboard/ocp/deltalake/vpd.h.
-
-## Working features
-The solution is developed using LinuxBoot payload with Linux kernel 5.2.9,
-and [u-root] as initramfs.
-- SMBIOS:
-    - Type 0 -- BIOS Information
-    - Type 1 -- System Information
-    - Type 2 -- Baseboard Information
-    - Type 3 -- System Enclosure or Chassis
-    - Type 4 -- Processor Information
-    - Type 7 -- Cache Information
-    - Type 8 -- Port Connector Information
-    - Type 9 -- PCI Slot Information
-    - Type 11 -- OEM String
-    - Type 16 -- Physical Memory Array
-    - Type 17 -- Memory Device
-    - Type 19 -- Memory Array Mapped Address
-    - Type 32 -- System Boot Information
-    - Type 38 -- IPMI Device Information
-    - Type 41 -- Onboard Devices Extended Information
-    - Type 127 -- End-of-Table
-- BMC integration:
-    - BMC readiness check
-    - IPMI commands
-    - watchdog timer
-    - POST complete pin acknowledgement
-    - Check BMC version: ipmidump -device
-- SEL record generation
-- Converged Bootguard and TXT (CBnT)
-    - TPM
-    - Bootguard profile 0T
-    - TXT
-    - SRTM
-    - DRTM (verified through tboot)
-		- unsigned KM/BPM generation
-		- KM/BPM signing
-		- memory secret clearance upon ungraceful shutdown
-- Early serial output
-- port 80h direct to GPIO
-- ACPI tables: APIC/DMAR/DSDT/EINJ/FACP/FACS/HEST/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
-- Skipping memory training upon subsequent reboots by using MRC cache
-- BMC crash dump
-- Error injection through ITP
-- Versions
-    - Check FSP version: cbmem | grep LB_TAG_PLATFORM_BLOB_VERSION
-    - Check Microcode version: cat /proc/cpuinfo | grep microcode
-- Devices:
-    - Boot drive
-    - All 5 data drives
-    - NIC card
-- Power button
-- localboot
-- netboot from IPv6
-- basic memory hardware error injection/detection (SMI handlers not upstreamed)
-- basic PCIe hardware error injection/detection (SMI handlers not upstreamed)
-
-## Stress/performance tests passed
-- OS warm reboot (1000 cycles)
-- DC reboot (1000 cycles)
-- AC reboot (1000 cycle)
-- Mprime test (6 hours)
-- StressAppTest (6 hours)
-- Ptugen (6 hours)
-
-## Performance on par with traditional firmware
-- coremark
-- FIO
-- Iperf(IPv6)
-- Linpack
-- Intel MLC (memory latency and bandwidth)
-- SpecCPU
-- stream
-
-## Other tests passed
-- Power
-- Thermal
-- coreboot address sanitizer (both romstage and ramstage)
-- Intel selftest tool (all errors analyzed; applicable errors clean)
 
 ## Known issues
-- HECI access at OS run time:
-    - spsInfoLinux64 command fail to return ME version
-    - ptugen command fail to get memory power
-- CLTT (Closed Loop Thermal Throttling, eg. thermal protection for DIMMs)
-- ProcHot (thermal protection for processors)
+- Even though CPX-SP FSP is based on FSP 2.2 framework, it does not
+  support FSP_USES_CB_STACK. An IPS ticket is filed with Intel.
+- VT-d is not supported. An IPS ticket is filed with Intel.
+- PCIe bifuration is not supported. An IPS ticket is filed with Intel.
+- ME based power capping. This is a bug in ME. An IPS ticket is filed
+  with Intel.
+- RO_VPD region as well as other RO regions are not write protected.
+- HECI is not set up correctly, so BMC is not able to get PCH and DIMM
+  temperature sensor readings.
 
 ## Feature gaps
-- flashrom command not able to update ME region
-- ACPI BERT table
-- PCIe hotplug through VPP (Virtual Pin Ports)
-- PCIe Live Error Recovery
-- RO_VPD region as well as other RO regions are not write protected
-- Not able to selectively enable/disable core
+- Delta Lake DVT is not supported, as we only have Delta Lake EVT servers
+  at the moment.
+- SMBIOS:
+    - Type 7 -- Cache Information
+    - Type 17 -- Memory Device
+    - Type 38 -- IPMI Device Information
+    - Type 41 -- Onboard Devices Extended Information
+- ACPI:
+    - DMAR
+- PFR/CBnT
 
 ## Technology
 
@@ -166,7 +116,7 @@ and [u-root] as initramfs.
 +------------------------+---------------------------------------------+
 | BMC                    | Aspeed AST 2500                             |
 +------------------------+---------------------------------------------+
-| PCH                    | Intel Lewisburg C620 Series                 |
+| PCH                    | Intel Lewisburg C621                        |
 +------------------------+---------------------------------------------+
 ```
 

Documentation/mainboard/purism/librem_14.md

@@ -1,113 +0,0 @@
-# Purism Librem 14
-
-This page describes how to run coreboot on the [Purism Librem 14].
-
-```eval_rst
-+------------------+------------------------------------------------------+
-| CPU              | Intel Core i7-10710U                                 |
-+------------------+------------------------------------------------------+
-| PCH              | Comet Lake LP Premium (Comet Lake-U)                 |
-+------------------+------------------------------------------------------+
-| EC               | ITE IT8528E                                          |
-+------------------+------------------------------------------------------+
-| Coprocessor      | Intel Management Engine (CSME 14.x)                  |
-+------------------+------------------------------------------------------+
-```
-
-![](librem_14.webp)
-![](librem_14_flash.jpg)
-![](librem_14_ec_flash.jpg)
-
-## Required proprietary blobs
-
-To build a minimal working coreboot image some blobs are required (assuming
-only the BIOS region is being modified).
-
-```eval_rst
-+-----------------+---------------------------------+---------------------+
-| Binary file     | Apply                           | Required / Optional |
-+=================+=================================+=====================+
-| FSP-M, FSP-S    | Intel Firmware Support Package  | Required            |
-+-----------------+---------------------------------+---------------------+
-| microcode       | CPU microcode                   | Required            |
-+-----------------+---------------------------------+---------------------+
-```
-
-FSP-M and FSP-S are obtained after splitting the CometLake1 FSP binary
-(done automatically by the coreboot build system and included into the
-image) from the `3rdparty/fsp` submodule.
-
-Microcode updates are automatically included into the coreboot image by the
-build system from the `3rdparty/intel-microcode` submodule. Official Purism
-release images may include newer microcode, which is instead pulled from
-Purism's [purism-blobs] repository.
-
-A VGA Option ROM is not required to boot, as the Librem 14 uses libgfxinit.
-
-## Intel Management Engine
-
-The Librem 14 uses version 14.x of the Intel Management Engine (ME) /
-Converged Security Engine (CSE). The ME/CSE is disabled using the High
-Assurance Platform (HAP) bit, which puts the ME into a disabled state after
-platform bring-up (BUP) and disables all PCI/HECI interfaces.
-This can be verified checking the coreboot console log, using coreboot’s
-cbmem utility:
-
-    `sudo ./cbmem -1 | grep 'ME:'`
-
-provided coreboot has been patched to output the ME status even when the
-PCI device is not visible/active (as it is in Purism's release builds).
-
-## Flashing coreboot
-
-### Internal programming
-
-The main SPI flash can be accessed using [flashrom]. No official flashrom
-release supports the CometLake-U SoC yet, so it must be built from source.
-Version v1.2-107-gb1f858f or later is needed. Firmware an be easily
-flashed with internal programmer (either BIOS region or full image).
-
-### External programming
-
-The system has an internal flash chip which is a 16 MiB soldered SOIC-8
-chip, and has a diode attached to the VCC line for in-system programming.
-This chip is located on the bottom side of the board, in between the CPU
-heatsink and the left cooling fan, just above the left SO-DIMM slot.
-
-One has to remove all 9 screws from the bottom cover, then disconnect the
-battery from the mainboard (bottom left of mainboard). Use a SOIC-8 chip
-clip to program the chip (a Gigadevice GD25Q127C (3.3V) - [datasheet][GD25Q127C]).
-
-The EC firmware is stored on a separate SOIC-8 chip (a Gigadevices GD25Q80C),
-located underneath the Wi-Fi module, below the left cooling fan.
-
-## Known issues
-
- * Automatic detection of external audio input/output via the 3.5mm jack
-   does not currently work.
- * PL1/PL2 limited to 15W/20W by charger and battery discharge capability,
-   not SoC or thermal design.
-
-## Working
-
- * Internal display with libgfxinit, VGA option ROM, or FSP/GOP init
- * External displays via HDMI, USB-C Alt-Mode
- * SeaBIOS (1.14), Tianocore (CorebootPayloadPkg), and Heads payloads
- * Ethernet, m.2 2230 Wi-Fi
- * System firmware updates via flashrom
- * M.2 storage (NVMe, SATA III)
- * Built-in audio (speakers, microphone)
- * SMBus (reading SPD from DIMMs)
- * Initialization with FSP 2.0 (CometLake1)
- * S3 Suspend/Resume
- * Booting PureOS 10.x, Debian 11.x, Qubes 4.0.4, Windows 10 20H2
-
-## Not working / untested
-
- * N/A
-
-
-[Purism Librem 14]: https://puri.sm/products/librem-14/
-[purism-blobs]: https://source.puri.sm/coreboot/purism-blobs
-[GD25Q127C]: https://www.gigadevice.com/datasheet/gd25q127c/
-[flashrom]: https://flashrom.org/Flashrom

Documentation/mainboard/purism/librem_mini.md

@@ -1,129 +0,0 @@
-# Purism Librem Mini (v1, v2)
-
-This page describes how to run coreboot on the [Purism Librem Mini].
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| CPU              | Intel Core i7-8565U/8665U (v1)                   |
-|                  | Intel Core i7-10510U      (v2)                   |
-+------------------+--------------------------------------------------+
-| PCH              | Whiskey Lake / Cannon Point LP       (v1)        |
-|                  | Comet Lake LP Premium (Comet Lake-U) (v2)        |
-+------------------+--------------------------------------------------+
-| Super I/O, EC    | ITE IT8528E                                      |
-+------------------+--------------------------------------------------+
-| Coprocessor      | Intel Management Engine (CSME 12.x) (v1)         |
-|                  | Intel Management Engine (CSME 14.x) (v2)         |
-+------------------+--------------------------------------------------+
-```
-
-![](librem_mini.jpg)
-![](librem_mini_flash.jpg)
-
-## Required proprietary blobs
-
-To build a minimal working coreboot image some blobs are required (assuming
-only the BIOS region is being modified).
-
-```eval_rst
-+-----------------+---------------------------------+---------------------+
-| Binary file     | Apply                           | Required / Optional |
-+=================+=================================+=====================+
-| FSP-M, FSP-S    | Intel Firmware Support Package  | Required            |
-+-----------------+---------------------------------+---------------------+
-| microcode       | CPU microcode                   | Required            |
-+-----------------+---------------------------------+---------------------+
-| vgabios         | VGA Option ROM                  | Optional            |
-+-----------------+---------------------------------+---------------------+
-```
-
-FSP-M and FSP-S are obtained after splitting the FSP binary (done automatically
-by the coreboot build system and included into the image; Coffee Lake for v1,
-Comet Lake for v2) from the `3rdparty/fsp` submodule.
-
-Microcode updates are automatically included into the coreboot image by the build
-system from the `3rdparty/intel-microcode` submodule. Official Purism release
-images may include newer microcode, which is instead pulled from Purism's
-[purism-blobs] repository.
-
-VGA Option ROM is not required to boot, but if one needs graphics in pre-OS
-stage, it should be included (if not using FSP/GOP display init). It can
-be extracted via cbfstool from the existing board firmware or pulled from
-the [purism-blobs] repository.
-
-## Intel Management Engine
-
-The Librem Mini uses version 12.x (v1) or 14.x (v2) of the Intel Management
-Engine (ME) / Converged Security Engine (CSE). The ME/CSE is disabled using
-the High Assurance Platform (HAP) bit, which puts the ME into a disabled state
-after platform bring-up (BUP) and disables all PCI/HECI interfaces.
-This can be verified via the coreboot cbmem utility:
-
-    `sudo ./cbmem -1 | grep 'ME:'`
-
-provided coreboot has been modified to output the ME status even when
-the PCI device is not visible/active (as it is in Purism's release builds).
-
-## Flashing coreboot
-
-### Internal programming
-
-The main SPI flash can be accessed using [flashrom]. The first version
-supporting the chipset is flashrom v1.2 (v1.2-107-gb1f858f or later needed
-for the Mini v2). Firmware an be easily flashed with internal programmer
-(either BIOS region or full image).
-
-### External programming
-
-The system has an internal flash chip which is a 8 MiB soldered SOIC-8 chip,
-and has a diode attached to the VCC line for in-system programming.
-This chip is located on the bottom side of the board under the CPU heatsink,
-in line with the front USB 2.0 ports.
-
-One has to remove all screws (in order):
-
- * 2 top cover screws
- * 4 screws securing the mainboard to the chassis
- * 4 screws securing the heatsink/fan assembly to the mainboard (under the SODIMMs)
-
-The m.2 SSD will need to be removed if the Wi-Fi antenna are connected to
-an internal Wi-Fi/BT module. Use a SOIC-8 chip clip to program the chip.
-Specifically, it's a Winbond W25Q128JV (3.3V) - [datasheet][W25Q128JV].
-
-The EC firmware is stored on a separate SOIC-8 chip (a Winbond W25Q80DV),
-but is not protected by a diode and therefore cannot be read/written to without
-desoldering it from the mainboard.
-
-## Known issues
-
- * SeaBIOS can be finicky with detecting USB devices
- * Mode switching with VGA option ROM display init can be slow and sometimes hangs
- * Some SATA devices on the 2.5" interface can have issues operating at 6 Gbps,
-   despite the HSIO PHY settings being set optimally via experimentation. These devices
-   may show errors in dmesg and drop down to 3 Gbps, but should not fail to boot.
-   The same issue is present on the AMI vendor firmware.
-
-## Working
-
- * External displays via HDMI/DisplayPort with VGA option ROM or FSP/GOP init
-   (no libgfxinit support yet)
- * SeaBIOS (1.14), Tianocore (CorebootPayloadPkg), Heads (Purism downstream) payloads
- * Ethernet, m.2 2230 Wi-Fi
- * System firmware updates via flashrom
- * PCIe NVMe
- * m.2 and SATA III
- * Audio via front 3.5mm jack, HDMI, and DisplayPort
- * SMBus (reading SPD from DIMMs)
- * Initialization with FSP 2.0 (CFL for v1, CML for v2)
- * S3 Suspend/Resume
- * Booting PureOS 10.x, Debian 11.x, Qubes 4.1.0-alpha1, Linux Mint 20, Windows 10 2004
-
-## Not working / untested
-
- * ITE IT8528E Super IO functions
-
-
-[Purism Librem Mini]: https://puri.sm/products/librem-mini/
-[purism-blobs]: https://source.puri.sm/coreboot/purism-blobs
-[W25Q128JV]: https://www.winbond.com/resource-files/w25q128jv%20revf%2003272018%20plus.pdf
-[flashrom]: https://flashrom.org/Flashrom

Documentation/mainboard/supermicro/flashing_on_vendorbmc.md

@@ -30,15 +30,3 @@ You can use the *SMCIPMITool* to remotely flash the BIOS:
 
 Make sure that the ME isn't in recovery mode, otherwise you get an error
 message on updating the BIOS.
-
-## Flashing with disabled ME
-
-If ME is disabled via `me_cleaner` or the ME recovery jumper, it is still
-possible to flash remotely with the [`Supermicro Update Manager`](SUM) (`SUM`).
-
-```sh
-./sum -i <remote BMC IP> -u <user> -p <password> -c UpdateBios --reboot \
-  --force_update --file build/coreboot.rom
-```
-
-[SUM]: https://www.supermicro.com/SwDownload/SwSelect_Free.aspx?cat=SUM

Documentation/mainboard/supermicro/x11-lga1151-series/x11-lga1151-series.md

@@ -7,7 +7,6 @@ Controller etc.
 ## Supported boards
 
 - [X11SSH-TF](x11ssh-tf/x11ssh-tf.md)
-- [X11SSH-F/LN4F](x11ssh-f/x11ssh-f.md)
 - [X11SSM-F](x11ssm-f/x11ssm-f.md)
 
 ## Required proprietary blobs
@@ -18,7 +17,7 @@ Controller etc.
 ## De-blobbing
 
 - [Intel FSP2.0] can not be removed as long as there is no free replacement
-- Intel ME can be cleaned using me_cleaner (~4.5 MiB more free space)
+- Intel ME can be cleaned using me_cleaner (~4.5 MB more free space)
 - Intel Ethernet Controller Firmware can be removed when it's extended functionality is not
   needed. For more details refer to the respective datasheet (e.g 333016-008 for I210).
 - Boards with [AST2400] BMC/IPMI: Firmware can be replaced by [OpenBMC]
@@ -31,12 +30,14 @@ Look at the [flashing tutorial] and the board-specific section.
 
 These issues apply to all boards. Have a look at the board-specific issues, too.
 
+- TianoCore doesn't work with Aspeed NGI, as it's text mode only (Fix is WIP CB:35726)
 - MRC caching does not work on cold boot with Intel SPS (see [Intel FSP2.0])
 
 ## ToDo
 
 - Fix issues above
 - Fix issues in board specific sections
+- Fix TODOs mentioned in code
 - Add more boards! :-)
 
 ## Technology

Documentation/mainboard/supermicro/x11-lga1151-series/x11ssh-f/x11ssh-f.md

@@ -1,110 +0,0 @@
-# Supermicro X11SSH-F/X11SSH-LN4F
-
-This section details how to run coreboot on the [Supermicro X11SSH-F] or [Supermicro X11SSH-LN4F].
-
-## Flashing coreboot
-
-The board can be flashed externally. [STM32-based programmers] worked.
-
-The flash IC "W25Q128.V" (detected by flashrom) can be found near PCH PCIe Slot 4. It is sometime
-socketed, and covered by a sticker, hindering the observation of its precise model.
-
-It can be programmed in-system with a clip like pomona 5250.
-
-## BMC (IPMI)
-
-This board has an ASPEED [AST2400], which has BMC/[IPMI] functionality. The BMC firmware resides in a
-32 MiB SOIC-16 chip in the corner of the mainboard near the PCH PCIe Slot 4. This chip is a
-[MX25L25635F].
-
-## IGD
-
-If an IGD is integrated with CPU, it will be enabled on this board. Though there is no video output
-for it (The onboard VGA port is connected to BMC), it is said to be capable of being used for compute
-tasks, or for offloading graphics rendering via "muxless" [vga_witcheroo].
-
-## Tested and working
-
-- SeaBIOS payload to boot Kali Linux live USB
-- ECC ram (Linux' ie31200 driver works)
-- Integrated graphics device available without output
-- USB ports
-- Ethernet
-- SATA ports
-- RS232 external
-- PCIe slots
-- BMC (IPMI)
-- VGA on Aspeed
-- TPM on TPM expansion header
-
-## Known issues
-
-- See general issue section
-- S3 resume not working (vendor and coreboot)
-- SeaBIOS cannot make use of VGA on Aspeed (even if IGD is disabled)
-
-## Difference between X11SSH-F and X11SSH-LN4F
-
-The PCB is identical. The X11SSH-F has 2 NICs, the X11SSH-LN4F has 4 NICs.
-So the X11SSH-F just doesn't have 2 NICs populated.
-
-## ToDo
-
-- Fix known issues
-- Testing other payloads
-
-## Technology
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| CPU              | Intel Kaby Lake                                  |
-+------------------+--------------------------------------------------+
-| PCH              | Intel C236                                       |
-+------------------+--------------------------------------------------+
-| Coprocessor      | Intel SPS (server version of the ME)             |
-+------------------+--------------------------------------------------+
-| Super I/O        | ASPEED AST2400                                   |
-+------------------+--------------------------------------------------+
-| Ethernet         | 2x Intel I210-AT 1 GbE (for X11SSH-F)            |
-|                  | 4x Intel I210-AT 1 GbE (for X11SSH-LN4F)         |
-|                  | 1x dedicated BMC                                 |
-+------------------+--------------------------------------------------+
-| PCIe slots       | 1x 3.0 x8                                        |
-|                  | 1x 3.0 x8 (in x16)                               |
-|                  | 1x 3.0 x4 (in x8)                                |
-|                  | 1x 3.0 x2 (in M.2 slot with key M)               |
-+------------------+--------------------------------------------------+
-| USB slots        | 2x USB 2.0 (ext)                                 |
-|                  | 2x USB 3.0 (ext)                                 |
-|                  | 1x USB 3.0 (int)                                 |
-|                  | 1x dual USB 3.0 header                           |
-|                  | 2x dual USB 2.0 header                           |
-+------------------+--------------------------------------------------+
-| SATA slots       | 8x S-ATA III                                     |
-+------------------+--------------------------------------------------+
-| Other slots      | 1x RS232 (ext)                                   |
-|                  | 1x RS232 header                                  |
-|                  | 1x TPM header                                    |
-|                  | 1x Power SMB header                              |
-|                  | 5x PWM Fan connector                             |
-|                  | 2x I-SGPIO                                       |
-|                  | 2x S-ATA DOM Power connector                     |
-|                  | 1x XDP Port (connector may absent)               |
-|                  | 1x External BMC I2C Header (for IPMI card)       |
-|                  | 1x Chassis Intrusion Header                      |
-+------------------+--------------------------------------------------+
-```
-
-## Extra links
-
-- [Supermicro X11SSH-F]
-- [Board manual]
-
-[Supermicro X11SSH-F]: https://www.supermicro.com/en/products/motherboard/X11SSH-F
-[Supermicro X11SSH-LN4F]: https://www.supermicro.com/en/products/motherboard/X11SSH-LN4F
-[Board manual]: https://www.supermicro.com/manuals/motherboard/C236/MNL-1778.pdf
-[AST2400]: https://www.aspeedtech.com/products.php?fPath=20&rId=376
-[IPMI]: ../../../../drivers/ipmi_kcs.md
-[MX25L25635F]: https://media.digikey.com/pdf/Data%20Sheets/Macronix/MX25L25635F.pdf
-[STM32-based programmers]: https://github.com/dword1511/stm32-vserprog
-[vga_switcheroo]: https://01.org/linuxgraphics/gfx-docs/drm/gpu/vga-switcheroo.html

Documentation/mainboard/supermicro/x11-lga1151-series/x11ssh-tf/x11ssh-tf.md

@@ -33,6 +33,10 @@ in a 32 MiB SOIC-16 chip in the corner of the mainboard near the [AST2400]. This
 
 See general issue section.
 
+## ToDo
+
+- Fix TODOs mentioned in code
+
 ## Technology
 
 ```eval_rst

Documentation/mainboard/supermicro/x11-lga1151-series/x11ssm-f/x11ssm-f.md

@@ -4,16 +4,11 @@ This section details how to run coreboot on the [Supermicro X11SSM-F].
 
 ## Flashing coreboot
 
-The flash IC [MX25L12873F] can be found near PCH PCIe Slot 4.
+The board can be flashed externally. FTDI FT2232H and FT232H based programmers worked.
 
-The board can be flashed externally with a SOIC test clip or probes. Since
-there is no diode between VCC3.3 and the flash chip, so VCC must **not** be
-connected. Instead, the flash chip is powered from VCC3.3, which is always-on
-(even in S5). WP# and HOLD# have pull-ups and don't need to be connected.
+The flash IC [MX25L12873F] can be found near PCH PCIe Slot 4. It is socketed on retail boards.
 
-FTDI FT2232H and FT232H based programmers worked.
-
-Flashing is also possible through the BMC web interface, when a valid license was entered.
+For doing ISP (In-System-Programming) one needs to add a diode between VCC and the flash chip.
 
 ## BMC (IPMI)
 
@@ -21,10 +16,6 @@ This board has an ASPEED [AST2400], which has BMC/[IPMI] functionality. The BMC
 32 MiB SOIC-16 chip in the corner of the mainboard near the PCH PCIe Slot 4. This chip is a
 [MX25L25635F].
 
-## Disabling LAN firmware
-
-To disable the proprietary LAN firmware, the undocumented jumper J6 can be set to 2-3.
-
 ## Tested and working
 
 - GRUB2 payload with Debian testing and kernel 5.2
@@ -41,9 +32,14 @@ To disable the proprietary LAN firmware, the undocumented jumper J6 can be set t
 ## Known issues
 
 - See general issue section
+- "only partially covers this bridge" info from Linux kernel (what does that mean?)
 - LNXTHERM missing
 - S3 resume not working
 
+## ToDo
+
+- Fix TODOs mentioned in code
+
 ## Technology
 
 ```eval_rst

Documentation/mainboard/system76/gaze15.md

@@ -1,72 +0,0 @@
-# System76 Gazelle 15 (gaze15)
-
-## Specs
-
-- CPU
-  - Intel Core i7 10750H
-- EC
-  - ITE5570E running https://github.com/system76/ec
-- Graphics
-  - Intel UHD Graphics
-  - NVIDIA GeForce GTX 1650/1650 Ti/1660 Ti
-  - eDP 15.6" or 17.3" 1920x1080 @ 120 Hz LCD
-  - HDMI, Mini DisplayPort 1.4, and DisplayPort 1.4 over USB-C
-- Memory
-  - Channel 0: 8-GB/16-GB/32-GB DDR4 SO-DIMM
-  - Channel 1: 8-GB/16-GB/32-GB DDR4 SO-DIMM
-- Networking
-  - Gigabit Ethernet
-  - M.2 PCIe/CNVi Wifi/Bluetooth
-    - Intel Wireless-AC 9560, or
-    - Intel Wi-Fi 6 AX200/AX201
-- Power
-  - 120W AC adapter (GTX 1650 and 1650 Ti)
-  - 180W AC adapter (GTX 1660 Ti)
-  - 48.96Wh battery
-- Sound
-  - Realtek ALC293 codec
-  - TAS5825MRHBR smart AMP
-  - Internal speakers and microphone
-  - Combined headphone and microphone 3.5mm jack
-  - HDMI, Mini DisplayPort, USB-C DP audio
-- Storage
-  - M.2 PCIe/SATA SSD-1
-  - M.2 PCIe SSD-2
-  - 2.5" 7mm drive bay
-  - SD card reader
-  - Realtek RTL8411B card reader
-- USB
-  - 1x USB 2.0
-  - 1x USB 3.0
-  - 1x USB 3.1
-  - 1x USB 3.2 Type-C
-
-## Building coreboot
-
-```bash
-make distclean
-make defconfig KBUILD_DEFCONFIG=configs/config.system76_gaze15
-make
-```
-
-## Flashing coreboot
-
-```eval_rst
-+---------------------+---------------------+
-| Type                | Value               |
-+=====================+=====================+
-| Socketed flash      | no                  |
-+---------------------+---------------------+
-| Vendor              | GigaDevice          |
-+---------------------+---------------------+
-| Model               | GD25Q127C/GD25Q128C |
-+---------------------+---------------------+
-| Size                | 16 MiB              |
-+---------------------+---------------------+
-| Package             | SOIC-8              |
-+---------------------+---------------------+
-| Internal flashing   | yes                 |
-+---------------------+---------------------+
-| External flashing   | yes                 |
-+---------------------+---------------------+
-```

Documentation/mainboard/system76/oryp5.md

@@ -1,71 +0,0 @@
-# System76 Oryx Pro 5 (oryp5)
-
-## Specs
-
-- CPU
-  - Intel Core i7-8750H
-  - Intel Core i7-9750H
-- EC
-  - ITE8587E running https://github.com/system76/ec
-- Graphics
-  - Intel UHD Graphics 630
-  - NVIDIA GeForce RTX 2080/2070/2060
-  - eDP 16.1" or 17.3" 1920x1080 @ 144 Hz LCD
-  - HDMI, Mini DisplayPort 1.3, and DisplayPort 1.3 over USB-C
-- Memory
-  - Channel 0: 8-GB/16-GB/32-GB DDR4 SO-DIMM
-  - Channel 1: 8-GB/16-GB/32-GB DDR4 SO-DIMM
-- Networking
-  - Gigabit Ethernet
-  - Intel Dual Band Wireless-AC 9560 Wireless LAN (802.11ac) + Bluetooth
-- Power
-  - 180W (19.5V, 9.23A) AC adapter
-  - 62Wh 4-cell battery
-- Sound
-  - Realtek ALC1220 codec
-  - TAS5825MRHBR smart AMP
-  - Internal speakers and microphone
-  - Combined headphone and microphone 3.5mm jack
-  - Combined microphone and S/PDIF 3.5mm jack
-  - HDMI, Mini DisplayPort, USB-C DP audio
-- Storage
-  - M.2 PCIe/SATA SSD1
-  - M.2 PCIe/SATA SSD2
-  - 2.5" SATA HDD/SSD
-  - RTS5250 SD card reader
-- USB
-  - 2x USB 3.1 Gen2 Type-C
-  - 2x USB 3.1 Gen1 Type-A
-
-## Building coreboot
-
-```bash
-make distclean
-make defconfig KBUILD_DEFCONFIG=configs/config.system76_oryp5
-make
-```
-
-## Flashing coreboot
-
-```eval_rst
-+---------------------+---------------------+
-| Type                | Value               |
-+=====================+=====================+
-| Socketed flash      | no                  |
-+---------------------+---------------------+
-| Vendor              | GigaDevice          |
-+---------------------+---------------------+
-| Model               | GD25Q127C/GD25Q128C |
-+---------------------+---------------------+
-| Size                | 16 MiB              |
-+---------------------+---------------------+
-| Package             | SOIC-8              |
-+---------------------+---------------------+
-| Internal flashing   | yes                 |
-+---------------------+---------------------+
-| External flashing   | yes                 |
-+---------------------+---------------------+
-```
-
-External flashing via ISP requires removing the board from the chassis.
-The IC is located under the touchpad.

Documentation/mainboard/system76/oryp6.md

@@ -1,60 +0,0 @@
-# System76 Oryx Pro (oryp6)
-
-## Specs
-
-- CPU
-  - Intel i7-10875H
-- Chipset
-  - Intel HM470
-- EC
-  - ITE IT5570E running https://github.com/system76/ec
-- GPU
-  - NVIDIA GeForce RTX 2080 Super (Max-Q)
-  - or NVIDIA GeForce RTX 2070 (Max-Q)
-  - or NVIDIA GeForce RTX 2060
-  - eDP 15.6" or 17.3" 1920x1080@144Hz LCD
-  - HDMI, Mini DisplayPort 1.4, and DisplayPort over USB-C
-- Memory
-  - Up to 64GB (2x32GB) dual-channel DDR4 SO-DIMMs @ 3200 MHz
-- Networking
-  - Gigabit Ethernet
-  - M.2 PCIe/CNVi WiFi/Bluetooth
-    - Intel Wi-Fi 6 AX200/AX201
-- Power
-  - 180W (19.5V, 9.23A) AC adapter
-  - 73Wh 3-cell battery
-- Sound
-  - Internal speakers and microphone
-  - Combined headphone and microphone 3.5mm jack
-  - Combined microphone and S/PDIF (optical) 3.5mm jack
-  - HDMI, Mini DisplayPort, USB-C DisplayPort audio
-- USB
-  - 3x USB 3.2 Gen 1 Type-A
-  - 1x USB Type-C with Thunderbolt 3
-- Dimensions
-  - 15": 35.75cm x 23.8cm x 1.98cm, 1.99kg
-  - 17": 39.59cm x 26.495cm x 1.99cm, 2.3kg
-
-## Flashing coreboot
-
-```eval_rst
-+---------------------+-----------------+
-| Type                | Value           |
-+=====================+=================+
-| Socketed flash      | no              |
-+---------------------+-----------------+
-| Vendor              | Macronix        |
-+---------------------+-----------------+
-| Model               | MX25L12872F     |
-+---------------------+-----------------+
-| Size                | 16 MiB          |
-+---------------------+-----------------+
-| Package             | SOIC-8          |
-+---------------------+-----------------+
-| Internal flashing   | yes             |
-+---------------------+-----------------+
-| External flashing   | yes             |
-+---------------------+-----------------+
-```
-
-The flash chip (U53) is above the M.2 SSD connectors.

Documentation/mainboard/ti/beaglebone-black.md

@@ -1,131 +0,0 @@
-# Beaglebone Black
-This page gives some details about the [BeagleBone Black] coreboot port and
-describes how to build and run it.
-
-The port currently only supports booting coreboot from a micro SD card and has
-some other limitations listed below.
-
-## Supported Boards
-The Beaglebone port supports the following boards:
-
-- Beaglebone Black
-- Beaglebone Black Wireless
-- Beaglebone Pocket (untested, may need tweaking)
-- Beaglebone Blue (untested, may need tweaking)
-- Beaglebone Original (untested, may need tweaking)
-
-## Use Cases
-This port was primarily developed as a learning exercise and there is
-potentially little reason to use it compared to the defacto bootloader choice of
-U-Boot. However, it does have some interesting practical use cases compared to
-U-Boot:
-
-1. Choosing coreboot as a lightweight alternative to U-Boot. In this case,
-   coreboot is used to do the absolute minimum necessary to boot Linux, forgoing
-   some U-Boot features and functionality. Complex boot logic can then instead
-   be moved into Linux where it can be more flexibly and safely executed. This
-   is essentially the LinuxBoot philosophy. [U-Boot Falcon mode] has similar
-   goals to this as well.
-2. Facilitating experimenting with coreboot on real hardware. The Beaglebone
-   Black is widely available at a low pricepoint (~$65) making it a great way to
-   experiment with coreboot on real ARMv7 hardware. It also works well as a
-   development platform as it has exposed pads for JTAG and, due to the way it
-   boots, is effectively impossible to brick.
-3. The Beaglebone Black is often used as a external flasher and EHCI debug
-   gadget in the coreboot community, so many members have access to it and can
-   use it as a reference platform.
-
-## Quickstart
-1. Run `make menuconfig` and select _TI_/_Beaglebone_ in the _Mainboard_ menu.
-2. Add a payload as normal.
-3. Run `make`.
-4. Copy the resulting `build/MLO` file to the micro SD card at offset 128k - ie
-   `dd if=build/MLO of=/dev/sdcard seek=1 bs=128k`.
-
-**NOTE**: By default, the Beaglebone is configured to try to boot first from
-eMMC before booting from SD card. To ensure that the Beaglebone boots from SD,
-either erase the internal eMMC or hold the _S2_ button while powering on (note
-that this has to be while powering on - ie when plugging in the USB or DC barrel
-jack - the boot order doesn't change on reset) to prioritize SD in the boot
-order.
-
-## Serial Console
-By default, coreboot uses UART0 as the serial console. UART0 is available
-through the J1 header on both the Beaglebone Black and Beaglebone Black
-Wireless. The serial runs at 3.3V and 115200 8n1.
-
-The pin mapping is shown below for J1.
-
-    ```eval_rst
-    +----------------------------+------------+
-    | Pin number                 | Function   |
-    +============================+============+
-    | 1 (Closest to barrel jack) | GND        |
-    +----------------------------+------------+
-    | 4                          | RX         |
-    +----------------------------+------------+
-    | 5                          | TX         |
-    +----------------------------+------------+
-    ```
-
-## Boot Process
-The AM335x contains ROM code to allow booting in a number of different
-configurations. More information about the boot ROM code can be found in the
-AM335x technical reference manual (_SPRUH73Q_) in the _Initialization_ section.
-
-This coreboot port is currently configured to boot in "SD Raw Mode" where the
-boot binary, with header ("Table of Contents" in TI's nomenclature), is placed
-at the offset of 0x20000 (128KB) on the SD card. The boot ROM loads the coreboot
-bootblock stage into SRAM and executes it.
-
-The bootblock and subsequent romstage and ramstage coreboot stages expect that
-the coreboot image, containing the CBFS, is located at 0x20000 on the SD card.
-All stages directly read from the SD card in order to load the next stage in
-sequence.
-
-## Clock Initialization and PMIC
-To simplify the port, the TPS65217C Power Management IC (PMIC) on the Beaglebone
-Black is not configured by coreboot. By default, the PMIC reset values for
-VDD_MPU (1.1V) and VDD_CORE (1.8V) are within the Operating Performance Point
-(OPP) for the MPU PLL configuration set by the boot ROM of 500 MHz.
-
-When using Linux as a payload, the kernel will appropriately scale the core
-voltages for the desired MPU clock frequency as defined in the device tree.
-
-One significant difference because of this to the U-Boot port is that the DCDC1
-rail that powers the DDR3 RAM will be 1.5V by default. The Micron DDR3 supports
-both 1.35V and 1.5V and U-Boot makes use of this by setting it to 1.35V to
-conserve power. Fortunately, Linux is again able to configure this rail but it
-involves adding an entry to the device tree:
-
-    &dcdc1_reg {
-    regulator-name = "vdd_ddr3";
-    regulator-min-microvolt = <1350000>;
-    regulator-max-microvolt = <1350000>;
-    regulator-boot-on;
-    regulator-always-on;
-    };
-
-If this port was to be extended to work with boards or SoCs with different
-requirements for the MPU clock frequency or different Operating Performance
-Points, then the port may need to be extended to set the core voltages and MPU
-PLL within coreboot, prior to loading a payload. Extending coreboot so that it
-can configure the PMIC would also be necessary if there was a requirement for
-coreboot to run at a different MPU frequency than the 500 MHz set by the boot
-ROM.
-
-# Todo
-- Allow coreboot to run from the Beaglebone Black's internal eMMC. This would
-  require updating the `mmc.c` driver to support running from both SD and eMMC.
-- Support the boot ROMs *FAT mode* so that the coreboot binary can be placed on
-  a FAT partition.
-- Increase the MMC read speed, it currently takes ~15s to read ~20MB which is a
-  bit slow. To do this, it should be possible to update the MMC driver to:
-    - Increase the supported blocksize (currently is always set to 1)
-    - Support 4-bit data width (currently only supports 1-bit data width)
-- Convert the while loops in the MMC driver to timeout so that coreboot does not
-  hang on a bad SD card or when the SD card is removed during boot.
-
-
-[Beaglebone Black]: https://beagleboard.org/black [U-Boot Falcon mode]:
-https://elixir.bootlin.com/u-boot/v2020.07/source/doc/README.falcon

Documentation/mainboard/up/squared/index.md

@@ -76,15 +76,15 @@ firmware_vendor.rom
 
 ```bash
 [upsquared]$ mkdir extracted && cd extracted
-[extracted]$ ifdtool -x ../firmware_vendor.rom
+[extracted]$ ifdtool -x ../firmware_vendor.rom 
 File ../firmware_vendor.rom is 16777216 bytes
 Peculiar firmware descriptor, assuming Ibex Peak compatibility.
-  Flash Region 0 (Flash Descriptor): 00000000 - 00000fff
-  Flash Region 1 (BIOS): 00001000 - 00efefff
+  Flash Region 0 (Flash Descriptor): 00000000 - 00000fff 
+  Flash Region 1 (BIOS): 00001000 - 00efefff 
   Flash Region 2 (Intel ME): 07fff000 - 00000fff (unused)
   Flash Region 3 (GbE): 07fff000 - 00000fff (unused)
   Flash Region 4 (Platform Data): 07fff000 - 00000fff (unused)
-  Flash Region 5 (Reserved): 00eff000 - 00ffefff
+  Flash Region 5 (Reserved): 00eff000 - 00ffefff 
   Flash Region 6 (Reserved): 07fff000 - 00000fff (unused)
   Flash Region 7 (Reserved): 07fff000 - 00000fff (unused)
   Flash Region 8 (EC): 07fff000 - 00000fff (unused)

Documentation/releases/checklist.md

@@ -75,8 +75,7 @@ be more frequent than was needed, so we scaled it back to twice a year.
 - [ ] 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.
-- [ ] Also extract the release notes and place them on the web server.
+- [ ] Upload release files to web server
 - [ ] Upload crossgcc sources to web server.
 - [ ] Update download page to point to files, push to repo.
 - [ ] Write and publish blog post with release notes.
@@ -177,9 +176,8 @@ commit db508565d2483394b709654c57533e55eebace51 (HEAD, tag: 4.6, origin/master,
 ...
 ````
 
-When you used the script to generate the release, a signed tag was generated in the
-tree that was downloaded. From the coreboot-X.Y tree, just run: `git push origin X.Y`.
-In case you pushed the wrong tag already, you have to force push the new one.
+When you used the script to generate the release, a tag was generated in the tree that was downloaded.
+From the coreboot-X.Y tree, just run: `git push -f origin <TAG (X.Y)>`
 
 You will need write access for tags to the coreboot git repo to do this.
 
@@ -199,16 +197,16 @@ the coreboot server, and put them in the release directory at
 ````
 
 People can now see the release tarballs on the website at
-<https://www.coreboot.org/releases/>
+https://www.coreboot.org/releases/
 
-The downloads page is the official place to download the releases from, and it needs to be updated with links to the new release tarballs and .sig files. It can be found at <https://review.coreboot.org/cgit/homepage.git/tree/downloads.html>
+The downloads page is the official place to download the releases from, and it needs to be updated with links to the new release tarballs and .sig files. It can be found at https://review.coreboot.org/cgit/homepage.git/tree/downloads.html
 
-Here is an example commit to change it: <https://review.coreboot.org/c/homepage/+/19515>
+Here is an example commit to change it: https://review.coreboot.org/#/c/19515/
 
 ## Upload crossgcc sources
 Sometimes the source files for older revisions of
 crossgcc disappear. To deal with that we maintain a mirror at
-<https://www.coreboot.org/releases/crossgcc-sources/> where we host the
+https://www.coreboot.org/releases/crossgcc-sources/ where we host the
 sources used by the crossgcc scripts that are part of coreboot releases.
 
 Run
@@ -222,7 +220,7 @@ sources. Download them yourself and copy them into the crossgcc-sources
 directory on the server.
 
 ## After the release is complete
-Post the release notes on <https://blogs.coreboot.org>
+Post the release notes on https://blogs.coreboot.org
 
 ## Making a branch
 At times we will need to create a branch, generally for patch fixes.

Documentation/releases/coreboot-4.13-relnotes.md

@@ -1,114 +1,18 @@
-coreboot 4.13
+Upcoming release - coreboot 4.13
 ================================
 
-coreboot 4.13 was released on November 20th, 2020.
+The 4.13 release is planned for November 2020.
 
-Since 4.12 there were 4200 new commits by over 234 developers.
-Of these, about 72 contributed to coreboot for the first time.
+Update this document with changes that should be in the release notes.
 
-Thank you to all developers who again helped made coreboot better
-than ever, and a big welcome to our new contributors!
-
-New mainboards
---------------
-
-- Acer G43T-AM3
-- AMD Cereme
-- Asus A88XM-E FM2+
-- Biostar TH61-ITX
-- BostenTech GBYT4
-- Clevo L140CU/L141CU
-- Dell OptiPlex 9010
-- Example Min86 (fake board)
-- Google Ambassador
-- Google Asurada
-- Google Berknip
-- Google Boldar
-- Google Boten
-- Google Burnet
-- Google Cerise
-- Google Coachz
-- Google Dalboz
-- Google Dauntless
-- Google Delbin
-- Google Dirinboz
-- Google Dooly
-- Google Drawcia
-- Google Eldrid
-- Google Elemi
-- Google Esche
-- Google Ezkinil
-- Google Faffy
-- Google Fennel
-- Google Genesis
-- Google Hayato
-- Google Lantis
-- Google Lindar
-- Google Madoo
-- Google Magolor
-- Google Metaknight
-- Google Morphius
-- Google Noibat
-- Google Pompom
-- Google Shuboz
-- Google Stern
-- Google Terrador
-- Google Todor
-- Google Trembyle
-- Google Vilboz
-- Google Voema
-- Google Volteer2
-- Google Voxel
-- Google Willow
-- Google Woomax
-- Google Wyvern
-- HP EliteBook 2560p
-- HP EliteBook Folio 9480m
-- HP ProBook 6360b
-- Intel Alderlake-P RVP
-- Kontron COMe-bSL6
-- Lenovo ThinkPad X230s
-- Open Compute Project DeltaLake
-- Prodrive Hermes
-- Purism Librem Mini
-- Purism Librem Mini v2
-- Siemens Chili
-- Supermicro X11SSH-F
-- System76 lemp9
-
-Removed mainboards
-------------------
-
-- Google Cheza
-- Google DragonEgg
-- Google Ripto
-- Google Sushi
-- Open Compute Project SonoraPass
+* Please use Markdown.
+* See the past few release notes for the general format.
+* The chip and board additions and removals will be updated right
+  before the release, so those do not need to be added.
 
 Significant changes
 -------------------
 
-### Native refcode implementation for Bay Trail
-
-Bay Trail no longer needs a refcode binary to function properly. The refcode
-was reimplemented as coreboot code, which should be functionally equivalent.
-Thus, coreboot only needs to run the MRC.bin to successfully boot Bay Trail.
-
-### Unusual config files to build test more code
-
-There's some new highly-unusual config files, whose only purpose is to coerce
-Jenkins into build-testing several disabled-by-default coreboot config options.
-This prevents them from silently decaying over time because of build failures.
-
-### Initial support for Intel Trusted eXecution Technology
-
-coreboot now supports enabling Intel TXT. Though it's not feature-complete yet,
-the code allows successfully launching tboot, a Measured Launch Environment. It
-was tested on Haswell using an Asrock B85M Pro4 mainboard with TPM 2.0 on LPC.
-Though support for other platforms is still not ready, it is being worked on.
-The Haswell MRC.bin needs to be patched so as to enable DPR. Given that the MRC
-binary cannot be redistributed, the best long-term solution is to replace it.
-
 ### Hidden PCI devices
 
 This new functionality takes advantage of the existing 'hidden' keyword in the
@@ -135,126 +39,4 @@ attributes as per their datasheet and convert those attributes into SPD files fo
 the platforms. More details about the tools are added in
 [README.md](https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/spd_tools/intel/lp4x/README.md).
 
-### New version of SMM loader
-
-A new version of the SMM loader which accommodates platforms with over 32
-CPU threads.  The existing version of SMM loader uses a 64K code/data
-segment and only a limited number of CPU threads can fit into one segment
-(because of save state, STM, other features, etc). This loader extends beyond
-the 64K segment to accommodate additional CPUs and in theory allows as many
-CPU threads as possible limited only by SMRAM space and not by 64K. By default
-this loader version is disabled. Please see cpu/x86/Kconfig for more info.
-
-### Address Sanitizer
-
-coreboot now has an in-built Address Sanitizer, a runtime memory debugger
-designed to find out-of-bounds access and use-after-scope bugs. It is made
-available on all x86 platforms in ramstage and on QEMU i440fx, Intel Apollo
-Lake, and Haswell in romstage. Further, it can be enabled in romstage on other
-x86 platforms as well. Refer [ASan documentation](../technotes/asan.md) for
-more info.
-
-### Initial support for x86_64
-
-The x86_64 code support has been revived and enabled for QEMU. While it started
-as PoC and the only supported platform is an emulator, there's interest in
-enabling additional platforms. It would allow to access more than 4GiB of memory
-at runtime and possibly brings optimised code for faster execution times.
-It still needs changes in assembly, fixed integer to pointer conversions in C,
-wrappers for blobs, support for running Option ROMs, among other things.
-
-### Preparations to minimize enabling PCI bus mastering
-
-For security reasons, bus mastering should be enabled as late as possible. In
-coreboot, it's usually not necessary and payloads should only enable it for
-devices they use. Since not all payloads enable bus mastering properly yet,
-some Kconfig options were added as an intermediate step to give some sort of
-"backwards compatibility", which allow enabling or disabling bus mastering by
-groups.
-
-Currently available groups are:
-
-* PCI bridges
-* Any devices
-
-For now, "Any devices" is enabled by default to keep the traditional behaviour,
-which also includes all other options. This is currently necessary, for instance,
-for libpayload-based payloads as the drivers don't enable bus mastering for PCI
-bridges.
-
-Exceptional cases, that may still need early bus master enabling in the future,
-should get their own per-reason Kconfig option. Ideally before the next release.
-
-### Early runtime configurability of the console log level
-
-Traditionally, we didn't allow the log level of the `romstage` console
-to be changed at runtime (e.g. via `get_option()`). It turned out that
-the technical constraints for this (no global variables in `romstage`)
-vanished long ago, though. The new behaviour is to query `get_option()`
-now from the second stage that uses the console on. In other words, if
-the `bootblock` already enables the console, the `romstage` log level
-can be changed via `get_option()`. Keeping the log level of the first
-console static ensures that we can see console output even if there's
-a bug in the more involved code to query options.
-
-### Resource allocator v4
-
-A new revision of resource allocator v4 is now added to coreboot that supports
-mutiple ranges for allocating resources. Unlike the previous allocator (v3), it does
-not use the topmost available window for allocation. Instead, it uses the first
-window within the address space that is available and satisfies the resource request.
-This allows utilization of the entire available address space and also allows
-allocation above the 4G boundary. The old resource allocator v3 is still retained for
-some AMD platforms that do not conform to the requirements of the allocator.
-
-Deprecations
-------------
-
-### PCI bus master configuration options
-
-In order to minimize the usage of PCI bus mastering, the options we introduced in
-this release will be dropped in a future release again. For more details, please
-see [Preparations to minimize enabling PCI bus mastering](#preparations-to-minimize-enabling-pci-bus-mastering-in-coreboot).
-
-### Resource allocator v3
-
-Resource allocator v3 is retained in coreboot tree because the following platforms
-do not conform to the requirements of the resource allocation i.e. not all the fixed
-resources of the platform are provided during the `read_resources()` operation:
-
-* northbridge/amd/pi/00630F01
-* northbridge/amd/pi/00730F01
-* northbridge/amd/pi/00660F01
-* northbridge/amd/agesa/family14
-* northbridge/amd/agesa/family15tn
-* northbridge/amd/agesa/family16kb
-
-In order to have a single unified allocator in coreboot, this notice is being added
-to ensure that the platforms listed above are fixed before the next release. If there
-is interest in maintaining support for these platforms beyond the next release,
-please ensure that the platforms are fixed to conform to the expectations of resource
-allocation.
-
-Notes
------
-
-### Intel microcode updates
-
-Intel microcode updates tagged *microcode-20200616* are still included in our
-builds. Note, [Intel released new microcode updates]
-(https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/blob/main/releasenote.md)
-tagged
-
-1.  *microcode-20201110*
-2.  *microcode-20201112*
-3.  *microcode-20201118*
-
-with security updates for [INTEL-SA-00381]
-(https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00381.html)
-and [INTEL-SA-00389]
-(https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html).
-
-Due to too short time for rigorous testing and bad experience with botched
-microcode updates in the past, these new updates are not included. Users wanting
-to use those, can apply them in the operating system, or update the submodule
-pointer themselves.
+### Add significant changes here

Documentation/releases/coreboot-4.14-relnotes.md

@@ -1,161 +0,0 @@
-coreboot 4.14
-=============
-
-coreboot 4.14 was released on May 10th, 2021.
-
-Since 4.13 there have been 3660 new commits by 215 developers.
-Of these, about 50 contributed to coreboot for the first time.
-Welcome to the project!
-
-These changes have been all over the place, so that there's no
-particular area to focus on when describing this release: We had
-improvements to mainboards, to chipsets (including much welcomed
-work to open source implementations of what has been blobs before),
-to the overall architecture.
-
-Thank you to all developers who made coreboot the great open source
-firmware project that it is, and made our code better than ever.
-
-New mainboards
---------------
-
-* AMD Bilby
-* AMD Majolica
-* GIGABYTE GA-D510UD
-* Google Blipper
-* Google Brya
-* Google Cherry
-* Google Collis
-* Google Copano
-* Google Cozmo
-* Google Cret
-* Google Drobit
-* Google Galtic
-* Google Gumboz
-* Google Guybrush
-* Google Herobrine
-* Google Homestar
-* Google Katsu
-* Google Kracko
-* Google Lalala
-* Google Makomo
-* Google Mancomb
-* Google Marzipan
-* Google Pirika
-* Google Sasuke
-* Google Sasukette
-* Google Spherion
-* Google Storo
-* Google Volet
-* HP 280 G2
-* Intel Alderlake-M RVP
-* Intel Alderlake-M RVP with Chrome EC
-* Intel Elkhartlake LPDDR4x CRB
-* Intel shadowmountain
-* Kontron COMe-mAL10
-* MSI H81M-P33 (MS-7817 v1.2)
-* Pine64 ROCKPro64
-* Purism Librem 14
-* System76 darp5
-* System76 galp3-c
-* System76 gaze15
-* System76 oryp5
-* System76 oryp6
-
-Removed mainboards
-------------------
-
-* Google Boldar
-* Intel Cannonlake U LPDDR4 RVP
-* Intel Cannonlake Y LPDDR4 RVP
-
-Deprecations and incompatible changes
--------------------------------------
-
-### SAR support in VPD for Chrome OS
-
-SAR support in VPD has been deprecated for Chrome OS platforms for > 1
-year now. All new Chrome OS platforms have switched to using SAR
-tables from CBFS. For the next release, coreboot is updated to align
-with the Chrome OS factory changes and hence SAR support in VPD is
-deprecated in [CB:51483](https://review.coreboot.org/51483). Starting
-with this release, anyone building coreboot for an already released
-Chrome OS platform with SAR table in VPD will have to extract the
-"wifi_sar" key from VPD and add it as a file to CBFS using following
-steps:
- * On DUT, read SAR value using `vpd -i RO_VPD -g wifi_sar`
- * In coreboot repo, generate CBFS SAR file using:
-    `echo ${SAR_STRING} > site-local/${BOARD}-sar.hex`
- * Add to site-local/Kconfig:
-    ```
-     config WIFI_SAR_CBFS_FILEPATH
-       string
-       default "site-local/${BOARD}-sar.hex"
-    ```
-
-### CBFS stage file format change
-
-[CB:46484](https://review.coreboot.org/46484) changed the in-flash
-file format of coreboot stages to prepare for per-file signature
-verification. As described in the commit message in more details,
-when manipulating stages in a CBFS, the cbfstool build must match the
-coreboot image so that they're using the same format: coreboot.rom
-and cbfstool must be built from coreboot sources that either both
-contain this change or both do not contain this change.
-
-Since stages are usually only handled by the coreboot build system
-which builds its own cbfstool (and therefore it always matches
-coreboot.rom) this shouldn't be a concern in the vast majority of
-scenarios.
-
-Significant changes
--------------------
-
-### AMD SoC cleanup and initial Cezanne APU support
-
-There's initial support for the AMD Cezanne APUs in the tree. This code
-hasn't started as a copy of the previous generation, but was based on a
-slightly modified version of the example/min86 SoC. During the cleanup
-of the existing Picasso SoC code the common parts of the code were
-moved to the common AMD SoC code, so that they could be used by the
-Cezanne code instead of adding another slightly different copy.
-
-### X86 bootblock layout
-
-The static size C_ENV_BOOTBLOCK_SIZE was mostly dropped in favor of
-dynamically allocating the stage size; the Kconfig is still available
-to use as a fixed size and to enforce a maximum for selected chipsets.
-Linker sections are now top-aligned for a reduced flash footprint and to
-maintain the requirements of near jump from reset vector.
-
-### ACPI GNVS framework
-
-SMI handlers for APM_CNT_GNVS_UDPATE were dropped; GNVS pointer to SMM is
-now passed from within SMM_MODULE_LOADER. Allocation and initialisations
-for common ACPI GNVS table entries were largely moved to one centralized
-implementation.
-
-### Intel Xeon Scalable Processor support is now considered mature
-
-Intel Xeon Scalable Processor (Xeon-SP) family [1] is designed
-primarily to serve the needs of the server market.
-
-coreboot support for Xeon-SP is in src/soc/intel/xeon_sp directory.
-This release has support for SkyLake-SP (SKX-SP) which is the 2nd
-generation, and for CooperLake-SP (CPX-SP) which is the 3rd generation
-or the latest generation [2] on market.
-
-With this release, the codebase for multiple generations of Xeon-SP
-were unified and optimized:
-* SKX-SP SoC code is used in OCP TiogaPass mainboard [3]. Support for
-this board is in Proof Of Concept Status.
-* CPX-SP SoC code is used in OCP DeltaLake mainboard. Support for
-this board is in DVT (Design Validation Test) exit equivalent status.
-Features supported, (performance/stability) test scopes, known issues,
-features gaps are described in [4].
-
-
-[1] https://www.intel.com/content/www/us/en/products/details/processors/xeon/scalable.html
-[2] https://www.intel.com/content/www/us/en/products/docs/processors/xeon/3rd-gen-xeon-scalable-processors-brief.html
-[3] ../mainboard/ocp/tiogapass.md
-[4] ../mainboard/ocp/deltalake.md

Documentation/releases/index.md

@@ -13,7 +13,6 @@ Release notes for previous releases
 * [4.10 - July 2019](coreboot-4.10-relnotes.md)
 * [4.11 - November 2019](coreboot-4.11-relnotes.md)
 * [4.12 - May 2020](coreboot-4.12-relnotes.md)
-* [4.13 - November 2020](coreboot-4.13-relnotes.md)
 
 The checklist contains instructions to ensure that a release covers all
 important things and provides a reliable format for tarballs, branch
@@ -25,4 +24,4 @@ Upcoming release
 ----------------
 
 Please add to the release notes as changes are added:
-* [4.14 - May 2021](coreboot-4.14-relnotes.md)
+* [4.13 - November 2020](coreboot-4.13-relnotes.md)

Documentation/security/vboot/index.md

@@ -188,12 +188,12 @@ In addition to adding the coreboot files into the read-only region,
 enabling vboot causes the build script to add the read/write files into
 coreboot file systems in *FW_MAIN_A* and *FW_MAIN_B*.
 
-**RO_REGION_ONLY**
+**RO_REGION_ONLY**  
 
 The files added to this list will only be placed in the read-only region and
 not into the read/write coreboot file systems in *FW_MAIN_A* and *FW_MAIN_B*.
 
-**VBOOT_ENABLE_CBFS_FALLBACK**
+**VBOOT_ENABLE_CBFS_FALLBACK**  
 
 Normally coreboot will use the active read/write coreboot file system for all
 of it's file access when vboot is active and is not in recovery mode.

Documentation/security/vboot/list_vboot.md

@@ -8,8 +8,6 @@
 - Facebook Monolith
 
 ## Google
-- Asurada
-- Hayato
 - Auron_Paine (Acer C740 Chromebook)
 - Auron_Yuna (Acer Chromebook 15 (C910/CB5-531))
 - Buddy (Acer Chromebase 24)
@@ -22,6 +20,7 @@
 - Tricky (Dell Chromebox 3010)
 - Zako (HP Chromebox G1)
 - Butterfly (HP Pavilion Chromebook 14)
+- Cheza
 - Banon (Acer Chromebook 15 (CB3-532))
 - Celes (Samsung Chromebook 3)
 - Cyan (Acer Chromebook R11 (C738T))
@@ -36,6 +35,7 @@
 - Daisy (Samsung Chromebook (2012))
 - Deltan
 - Deltaur
+- DragonEgg
 - Drallion
 - Eve (Google Pixelbook)
 - Fizz
@@ -58,12 +58,9 @@
 - Rainier
 - Akemi
 - Dratini
-- Duffy Legacy (32MB)
 - Duffy
-- Faffy
 - Hatch
 - Jinlon
-- Kaisa Legacy (32MB)
 - Kaisa
 - Kohaku
 - Kindred
@@ -71,14 +68,10 @@
 - Mushu
 - Palkia
 - Nightfury
-- Noibat
 - Puff
 - Helios_Diskswap
 - Stryke
-- Wyvern
-- Dooly
-- Ambassador
-- Genesis
+- Sushi
 - Guado (ASUS Chromebox CN62)
 - Jecht
 - Rikku (Acer Chromebox CXI2)
@@ -98,12 +91,6 @@
 - Juniper
 - Kappa
 - Damu
-- Cerise
-- Stern
-- Willow
-- Esche
-- Burnet
-- Fennel
 - Link (Google Chromebook Pixel (2013))
 - Mistral
 - Nyan
@@ -114,13 +101,13 @@
 - Hana (Lenovo N23 Yoga Chromebook)
 - Parrot (Acer C7/C710 Chromebook)
 - Peach Pit (Samsung Chromebook 2 11\")
-- Atlas (Google Pixelbook Go)
+- Atlas
 - Poppy
 - Nami
-- Nautilus (Samsung Chromebook Plus (V2 / LTE))
-- Nocturne (Google Pixel Slate)
-- Rammus (Asus Chromebook C425, Flip C433, Flip C434)
-- Soraka (HP Chromebook x2)
+- Nautilus
+- Nocturne
+- Rammus
+- Soraka
 - Banjo (Acer Chromebook 15 (CB3-531))
 - Candy (Dell Chromebook 11 3120)
 - Clapper (Lenovo N20 Chromebook)
@@ -152,13 +139,9 @@
 - Smaug (Google Pixel C)
 - Storm (OnHub Router TGR1900)
 - Stout (Lenovo Thinkpad X131e Chromebook)
-- Bubs
-- Coachz
-- Homestar
-- Lazor
-- Marzipan
-- Pompom
 - Trogdor
+- Lazor
+- Bubs
 - Veyron_Jaq (Haier Chromebook 11)
 - Veyron_Jerry (Hisense Chromebook 11)
 - Veyron_Mighty (Haier Chromebook 11(edu))
@@ -166,22 +149,11 @@
 - Veyron_Speedy (ASUS C201 Chromebook)
 - Veyron_Mickey (Asus Chromebit CS10)
 - Veyron_Rialto
-- Dalboz
-- Vilboz
-- Ezkinil
-- Morphius
-- Trembyle
-- Berknip
-- Woomax
-- Dirinboz
-- Shuboz
 
 ## HP
 - Z220 SFF Workstation
 
 ## Intel
-- Alderlake-P RVP
-- Alderlake-P RVP with Chrome EC
 - Basking Ridge CRB
 - Cannonlake U LPDDR4 RVP
 - Cannonlake Y LPDDR4 RVP
@@ -234,7 +206,6 @@
 - ThinkPad X1
 - ThinkPad X230
 - ThinkPad X230t
-- ThinkPad X230s
 - ThinkPad X60 / X60s / X60t
 
 ## OpenCellular
@@ -255,7 +226,6 @@
 ## Supermicro
 - X11SSH-TF
 - X11SSM-F
-- X11SSH-F/X11SSH-LN4F
 
 ## UP
 - Squared

Documentation/soc/amd/family17h.md

@@ -240,12 +240,47 @@ in an Integration Guide.
 ## APCB setup
 
 APCBs are used to provide the PSP with SPD information and optionally a set of
-GPIOs to use for selecting which SPD to load. A list of APCB files should be
-specified in `APCB_SOURCES`.
+GPIOs to use for selecting which SPD to load.
+
+### Prebuilt
+The picasso `Makefile` expects APCBs to be located in
+`3rdparty/blobs/mainboard/$(MAINBOARDDIR)`. If you have a pre-built binary just
+add the following to your mainboard's Makefile.
+
+```
+# i.e., 3rdparty/blobs/mainboard/amd/mandolin/APCB_mandolin.bin
+APCB_SOURCES = mandolin
+```
 
 ### Generating APCBs
 If you have a template APCB file, the `apcb_edit` tool can be used to inject the
-SPD and GPIOs used to select the correct slot.
+SPD and GPIOs used to select the correct slot.  Entries should match this
+pattern `{NAME}_x{1,2}`. There should be a matching SPD hex file in
+`SPD_SOURCES_DIR` matching the pattern `{NAME}.spd.hex`.
+The `_x{1,2}` suffix denotes single or dual channel. Up to 16 slots can be used.
+If a slot is empty, the special empty keyword can be used. This will generate
+an APCB with an empty SPD.
+
+```
+APCB_SOURCES =  hynix-HMA851S6CJR6N-VK_x1   # 0b0000
+APCB_SOURCES += hynix-HMAA1GS6CMR6N-VK_x2   # 0b0001
+APCB_SOURCES += empty                       # 0b0010
+APCB_SOURCES += samsung-K4A8G165WC-BCWE_x1  # 0b0011
+```
+
+#### APCB Board ID GPIO configuration.
+The GPIOs determine which memory SPD will be used during boot.
+```
+# APCB_BOARD_ID_GPIO[0-3] = GPIO_NUMBER GPIO_IO_MUX GPIO_BANK_CTL
+# GPIO_NUMBER: FCH GPIO number
+# GPIO_IO_MUX: Value write to IOMUX to configure this GPIO
+# GPIO_BANK_CTL: Value write to GPIOBankCtl[23:16] to configure this GPIO
+
+APCB_BOARD_ID_GPIO0 = 121 1 0
+APCB_BOARD_ID_GPIO1 = 120 1 0
+APCB_BOARD_ID_GPIO2 = 131 3 0
+APCB_BOARD_ID_GPIO3 = 116 1 0
+```
 
 ## Footnotes
 

Documentation/soc/intel/cse_fw_update/Layout_after.svg

@@ -1,150 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by Microsoft Visio, SVG Export Layout_after.svg Page-1 -->
-<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ev="http://www.w3.org/2001/xml-events"
-		width="2.39231in" height="2.05998in" viewBox="0 0 172.246 148.318" xml:space="preserve" color-interpolation-filters="sRGB"
-		class="st12">
-	<style type="text/css">
-	<![CDATA[
-		.st1 {fill:#ffffff;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
-		.st2 {fill:#000000;font-family:Calibri;font-size:0.333344em}
-		.st3 {fill:#ffc000;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
-		.st4 {fill:#000000;font-family:Calibri;font-size:0.499992em}
-		.st5 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
-		.st6 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:1}
-		.st7 {fill:none;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
-		.st8 {stroke:#4bacc6;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
-		.st9 {font-size:1em}
-		.st10 {marker-end:url(#mrkr4-59);stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
-		.st11 {fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1;stroke-width:0.22935779816514}
-		.st12 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
-	]]>
-	</style>
-
-	<defs id="Markers">
-		<g id="lend4">
-			<path d="M 2 1 L 0 0 L 2 -1 L 2 1 " style="stroke:none"/>
-		</g>
-		<marker id="mrkr4-59" class="st11" refX="-8.72" orient="auto" markerUnits="strokeWidth" overflow="visible">
-			<use xlink:href="#lend4" transform="scale(-4.36,-4.36) "/>
-		</marker>
-	</defs>
-	<g>
-		<title>Page-1</title>
-		<g id="shape116-1" transform="translate(38.7567,-139.932)">
-			<title>Rectangle.116</title>
-			<desc>DESC</desc>
-			<rect x="0" y="143.783" width="79.3701" height="4.53543" class="st1"/>
-			<text x="35.49" y="147.25" class="st2">DESC</text>		</g>
-		<g id="shape117-4" transform="translate(38.7567,-130.935)">
-			<title>Rectangle.117</title>
-			<desc>CSE - RO</desc>
-			<rect x="0" y="139.605" width="79.3701" height="8.71293" class="st3"/>
-			<text x="29.35" y="145.76" class="st4">CSE - RO</text>		</g>
-		<g id="shape118-7" transform="translate(38.5344,-4.54823)">
-			<title>Rectangle.118</title>
-			<rect x="0" y="29.8973" width="79.5923" height="118.421" class="st1"/>
-		</g>
-		<g id="shape119-9" transform="translate(41.225,-5.80807)">
-			<title>Rectangle.119</title>
-			<desc>COREBOOT_RO</desc>
-			<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st5"/>
-			<text x="18.32" y="135.95" class="st4">COREBOOT_RO</text>		</g>
-		<g id="shape120-12" transform="translate(41.225,-34.1545)">
-			<title>Rectangle.120</title>
-			<desc>RW_MISC</desc>
-			<rect x="0" y="143.907" width="74.3581" height="4.41113" class="st5"/>
-			<text x="29.12" y="147.31" class="st2">RW_MISC</text>		</g>
-		<g id="shape121-15" transform="translate(41.225,-38.7215)">
-			<title>Rectangle.121</title>
-			<desc>FW_MAIN_B</desc>
-			<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
-			<text x="21.52" y="129.37" class="st4">FW_MAIN_B</text>		</g>
-		<g id="shape122-18" transform="translate(41.225,-67.0679)">
-			<title>Rectangle.122</title>
-			<desc>FW_MAIN_A</desc>
-			<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
-			<text x="21.41" y="129.37" class="st4">FW_MAIN_A</text>		</g>
-		<g id="shape123-21" transform="translate(3.88308,-0.375)">
-			<title>Sheet.123</title>
-			<desc>0x1FFFFFF</desc>
-			<rect x="0" y="137.688" width="41.4007" height="10.6299" class="st7"/>
-			<text x="8.09" y="144.8" class="st4">0x1FFFFFF</text>		</g>
-		<g id="shape124-24" transform="translate(21.7488,-138.564)">
-			<title>Sheet.124</title>
-			<desc>0x0</desc>
-			<rect x="0" y="138.939" width="21.2598" height="9.37934" class="st7"/>
-			<text x="6.29" y="145.43" class="st4">0x0</text>		</g>
-		<g id="shape125-27" transform="translate(41.2627,-96.0443)">
-			<title>Rectangle.125</title>
-			<desc>RW_LEGACY</desc>
-			<rect x="0" y="122.448" width="74.3581" height="25.8706" class="st5"/>
-			<text x="27.04" y="136.58" class="st2">RW_LEGACY</text>		</g>
-		<g id="shape126-30" transform="translate(119.253,-6.75295)">
-			<title>Right Brace.126</title>
-			<path d="M-0 148.32 A9.42279 2.96575 -180 0 0 5.11 146.6 L5.11 135.46 L10.21 135.46 L5.11 135.46 L5.11 124.32 A9.42279
-						 2.96575 -180 0 0 0 122.6" class="st8"/>
-		</g>
-		<g id="shape127-33" transform="translate(120.961,-10.2963)">
-			<title>Sheet.127</title>
-			<desc>HW WP</desc>
-			<rect x="0" y="137.688" width="31.1811" height="10.6299" class="st7"/>
-			<text x="6.16" y="144.8" class="st4">HW WP</text>		</g>
-		<g id="shape128-36" transform="translate(119.43,-123.061)">
-			<title>Right Brace.128</title>
-			<path d="M-0 148.32 a10.4615 0.900102 -180 0 0 5.66929 -0.520272 L5.67 144.42 L11.34 144.42 L5.67 144.42 L5.67 141.03
-						 a10.4615 0.900102 -180 0 0 -5.66929 -0.520272" class="st8"/>
-		</g>
-		<g id="shape129-39" transform="translate(126.517,-119.597)">
-			<title>Sheet.129</title>
-			<desc>SPI Controller WP via descriptor</desc>
-			<rect x="0" y="138.043" width="45.3543" height="10.2756" class="st7"/>
-			<text x="5.53" y="141.98" class="st2">SPI Controller WP via <tspan x="14.37" dy="1.2em" class="st9">descriptor</tspan></text>		</g>
-		<g id="group130-43" transform="translate(42.8947,-77.0772)">
-			<title>Sheet.130</title>
-			<g id="shape131-44">
-				<title>Rectangle.423</title>
-				<desc>CSE-RW</desc>
-				<rect x="0" y="141.232" width="70.8661" height="7.08661" class="st3"/>
-				<text x="25.77" y="146.58" class="st4">CSE-RW</text>			</g>
-		</g>
-		<g id="group132-47" transform="translate(42.8947,-48.7307)">
-			<title>Sheet.132</title>
-			<g id="shape133-48">
-				<title>Rectangle.423</title>
-				<desc>CSE-RW</desc>
-				<rect x="0" y="141.232" width="70.8661" height="7.08661" class="st3"/>
-				<text x="25.77" y="146.58" class="st4">CSE-RW</text>			</g>
-		</g>
-		<g id="shape134-51" transform="translate(38.6427,-123.114)">
-			<title>Rectangle.134</title>
-			<desc>CSE-RW</desc>
-			<rect x="0" y="140.497" width="79.3701" height="7.82103" class="st3"/>
-			<text x="30.03" y="146.21" class="st4">CSE-RW</text>		</g>
-		<g id="shape135-54" transform="translate(41.225,-52.8947)">
-			<title>Universal connector.473</title>
-			<path d="M0 148.32 L-8.38 148.32 A8.37776 8.37776 0 0 1 -16.76 139.94 L-16.76 111.25 L-16.76 81.27 A7.08661 7.08661 0
-						 0 1 -9.67 74.19 L-9.12 74.19" class="st10"/>
-		</g>
-		<g id="shape136-60" transform="translate(41.225,-81.2411)">
-			<title>Universal connector.136</title>
-			<path d="M0 148.32 L-8.38 148.32 A8.37776 8.37776 0 0 1 -16.76 139.94 L-16.76 125.43 L-16.76 109.62 A7.08661 7.08661
-						 0 0 1 -9.67 102.53 L-9.12 102.53" class="st10"/>
-		</g>
-		<g id="shape138-65" transform="translate(-124.557,86.8317) rotate(-90)">
-			<title>Sheet.138</title>
-			<desc>CSE RW copied during an update</desc>
-			<rect x="0" y="124.932" width="58.1102" height="23.3858" class="st7"/>
-			<text x="10.77" y="134.83" class="st4">CSE RW copied <tspan x="8.15" dy="1.2em" class="st9">during an update</tspan></text>		</g>
-		<g id="shape139-69" transform="translate(119.43,-133.052)">
-			<title>Right Brace.139</title>
-			<path d="M0 148.32 a10.4615 0.736641 -180 0 0 5.66929 -0.425789 L5.67 145.12 L11.34 145.12 L5.67 145.12 L5.67 142.36
-						 a10.4615 0.736641 -180 0 0 -5.66929 -0.425789" class="st8"/>
-		</g>
-		<g id="shape140-72" transform="translate(127.934,-133.061)">
-			<title>Sheet.140</title>
-			<desc>GRP0 Protected</desc>
-			<rect x="0" y="140.523" width="35.4331" height="7.79528" class="st7"/>
-			<text x="4.86" y="145.62" class="st2">GRP0 Protected</text>		</g>
-	</g>
-</svg>

Documentation/soc/intel/cse_fw_update/Layout_before.svg

@@ -1,95 +0,0 @@
-<?xml version="1.0" encoding="UTF-8" standalone="no"?>
-<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
-<!-- Generated by Microsoft Visio, SVG Export Layout_before.svg Page-1 -->
-<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ev="http://www.w3.org/2001/xml-events"
-		width="2.3058in" height="2.05998in" viewBox="0 0 166.017 148.318" xml:space="preserve" color-interpolation-filters="sRGB"
-		class="st11">
-	<style type="text/css">
-	<![CDATA[
-		.st1 {fill:#ffffff;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
-		.st2 {fill:#000000;font-family:Calibri;font-size:0.333344em}
-		.st3 {fill:#ffc000;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
-		.st4 {fill:#000000;font-family:Calibri;font-size:0.499992em}
-		.st5 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
-		.st6 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:1}
-		.st7 {fill:none;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
-		.st8 {stroke:#4bacc6;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
-		.st9 {fill:#000000;font-family:Calibri;font-size:0.416656em}
-		.st10 {font-size:1em}
-		.st11 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
-	]]>
-	</style>
-
-	<g>
-		<title>Page-1</title>
-		<g id="shape87-1" transform="translate(35.2486,-139.932)">
-			<title>Rectangle.178</title>
-			<desc>DESC</desc>
-			<rect x="0" y="143.783" width="79.3701" height="4.53543" class="st1"/>
-			<text x="35.49" y="147.25" class="st2">DESC</text>		</g>
-		<g id="shape88-4" transform="translate(35.2486,-122.945)">
-			<title>Rectangle.179</title>
-			<desc>CSME/PMC</desc>
-			<rect x="0" y="131.615" width="79.3701" height="16.7031" class="st3"/>
-			<text x="25.8" y="141.02" class="st4">CSME/PMC</text>		</g>
-		<g id="shape89-7" transform="translate(35.0263,-4.54823)">
-			<title>Rectangle.180</title>
-			<rect x="0" y="29.8973" width="79.5923" height="118.421" class="st1"/>
-		</g>
-		<g id="shape90-9" transform="translate(37.7169,-5.80807)">
-			<title>Rectangle.181</title>
-			<desc>COREBOOT_RO</desc>
-			<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st5"/>
-			<text x="18.32" y="135.95" class="st4">COREBOOT_RO</text>		</g>
-		<g id="shape91-12" transform="translate(37.7169,-34.1545)">
-			<title>Rectangle.182</title>
-			<desc>RW_MISC</desc>
-			<rect x="0" y="143.907" width="74.3581" height="4.41113" class="st5"/>
-			<text x="29.12" y="147.31" class="st2">RW_MISC</text>		</g>
-		<g id="shape92-15" transform="translate(37.7169,-38.7215)">
-			<title>Rectangle.183</title>
-			<desc>FW_MAIN_B</desc>
-			<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
-			<text x="21.52" y="129.37" class="st4">FW_MAIN_B</text>		</g>
-		<g id="shape93-18" transform="translate(37.7169,-67.0679)">
-			<title>Rectangle.184</title>
-			<desc>FW_MAIN_A</desc>
-			<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
-			<text x="21.41" y="129.37" class="st4">FW_MAIN_A</text>		</g>
-		<g id="shape94-21" transform="translate(0.375,-0.375)">
-			<title>Sheet.94</title>
-			<desc>0x1FFFFFF</desc>
-			<rect x="0" y="137.688" width="41.4007" height="10.6299" class="st7"/>
-			<text x="8.09" y="144.8" class="st4">0x1FFFFFF</text>		</g>
-		<g id="shape95-24" transform="translate(18.2407,-138.564)">
-			<title>Sheet.95</title>
-			<desc>0x0</desc>
-			<rect x="0" y="138.939" width="21.2598" height="9.37934" class="st7"/>
-			<text x="6.29" y="145.43" class="st4">0x0</text>		</g>
-		<g id="shape106-27" transform="translate(37.7546,-96.0443)">
-			<title>Rectangle.106</title>
-			<desc>RW_LEGACY</desc>
-			<rect x="0" y="122.448" width="74.3581" height="25.8706" class="st5"/>
-			<text x="27.04" y="136.58" class="st2">RW_LEGACY</text>		</g>
-		<g id="shape113-30" transform="translate(115.744,-6.75295)">
-			<title>Right Brace.398</title>
-			<path d="M-0 148.32 A9.42279 2.96575 -180 0 0 5.11 146.6 L5.11 135.46 L10.21 135.46 L5.11 135.46 L5.11 124.32 A9.42279
-						 2.96575 -180 0 0 0 122.6" class="st8"/>
-		</g>
-		<g id="shape96-33" transform="translate(117.453,-10.2963)">
-			<title>Sheet.96</title>
-			<desc>HW WP</desc>
-			<rect x="0" y="137.688" width="31.1811" height="10.6299" class="st7"/>
-			<text x="6.16" y="144.8" class="st4">HW WP</text>		</g>
-		<g id="shape115-36" transform="translate(116.508,-123.131)">
-			<title>Right Brace.115</title>
-			<path d="M0 148.32 A10.4615 2.27029 -180 0 0 5.67 147.01 L5.67 138.48 L11.34 138.48 L5.67 138.48 L5.67 129.95 A10.4615
-						 2.27029 -180 0 0 0 128.63" class="st8"/>
-		</g>
-		<g id="shape97-39" transform="translate(120.288,-122.265)">
-			<title>Sheet.97</title>
-			<desc>SPI Controller WP via descriptor</desc>
-			<rect x="0" y="124.932" width="45.3543" height="23.3858" class="st7"/>
-			<text x="4.71" y="135.13" class="st9">SPI Controller WP <tspan x="8.83" dy="1.2em" class="st10">via descriptor</tspan></text>		</g>
-	</g>
-</svg>

Documentation/soc/intel/cse_fw_update/cse_fw_update.md

@@ -1,127 +0,0 @@
-CSE FW update mechanism for devices in field
-
-## Introduction
-
-CSE Firmware and PMC Firmware are critical components of Intel SoCs.
-CSE and PMC cooperate by providing platform services during boot and other
-power transition flows.
-
-## Problem Statement
-
-Currently, on Chromium OS Systems, CSE region is not updatable. So, new CSE FW
-versions that are released by Intel to address important functional and security
-bugs post-product launch will not be available to the end-user. Hence, the proposed
-solution allows in-field CSE FW update to propagate those bug fixes
-to end user platforms.
-
-## Design Proposal
-
-### CSE FW design Proposal:
-
-Key Elements:
-
-- CSE FW layout is composed of two bootable partitions (RO Recovery Partition
-  and RW Normal Partition).
-
-- Boot partition selection: An API-based mechanism is used to decide from which partition
-  CSE will boot.
-
-- The HECI APIs below will be supported in this CSE FW:
-
-    - HMRFPO_ENABLE: This command requests the CSE enter a mode in which writes to
-    the CSE region from the CSE are disabled. It also grants temporary write access
-    to the RW partition from the host (RO is still protected by GPR0).
-
-    - GET_PARTITION_INFO: The command retrieves information for each boot partition from CSE
-    like version, start/end offsets of a partition within CSE region, and boot
-    partition status. Also, it provides below information:
-	    - The current boot partition which was used during this boot,
-	    - The boot partition that will be used on the next CSE reset
-	    - The number of boot partitions available in the CSE region
-
-    - SET_BOOT_PARTITION_INFO: This command allows the firmware to request the
-    CSE to boot from either its RO or RW partition at its next reset.
-
-    - DATA_CLEAR: This command requests the CSE to reset its data partition back
-    to manufacturing defaults
-
-FW Layout, RW/RO Partitions:
-
-The CSE RO partition is the first in the CSE boot order, hence it will be used
-out of G3. RO partition contains minimum CSE code capable to boot platform and
-execute FW update of RW partition. In addition to CSE code, the RO partition also
-contains PMC FW patch and other CSE-loadable platform FW components.
-
-RW partition contains fully operational CSE FW, PMC FW, other CSE loadable
-platform FW components.
-
-Boot partition selection:
-
-CSE FW shall support 2 APIs to get boot partition info, and set boot partition
-info to notify CSE to select the partition on the next boot.
-
-### HOST FW Design proposal:
-
-Key Elements:
-
-- Build time artifacts:
-
-    CSE RW Version update binary - The FW shall pack CSE RW update blob and
-    corresponding version binary which contains version of the CSE RW blob.
-
-- FW Update:
-
-    coreboot will implement the logic to compare the CSE's FW version with CBFS
-    CSE RW binary's version in the firmware slot (FW_MAIN_A/FW_MAIN_B) and update
-    the CSE RW region if there is a version mismatch. If there is no version
-    mismatch, firmware skips CSE FW update.
-
-- Handling of CSE FW Downgrade:
-
-  coreboot will send DATA_CLEAR HECI command when there is a CSE FW downgrade.
-  This must be done to avoid data mismatch due to CSE FW downgrade. Further,
-  CSE will restore the data back to manufacturing defaults after data reset.
-
-
-## Implementation Details
-
-
-To enable CSE FW update flow the following changes are required in coreboot:
-
-* Descriptor change may be required to accommodate CSE binary. The CSE binary is tied with
-a platform. So CSE size may vary from one platform to another.
-* FMAP changes may be required to accommodate CSE binary and CSE RW blob in the RW CBFS region.
-Please check platform specific CSE kit for CSE binary information.
-* CSE Lite SKU binary and CSE RW blob
-* Makefile change to pack CSE RW binaries in the CBFS
-* Implementation of update flow:
- - Get CSE boot partition info using GET_BOOT_PARTITION_INFO HECI command.
- - Get the cbfs_me_rw.version from the currently selected RW slot.
- - If the version from the above 2 locations don't match, then start CSE FW update.
-	 - If CSE is not booting from RO, then
-		- Set the CSE's next boot partition to RO using SET_BOOT_PARTITION_INFO
-        HECI command.
-		- Send GLOBAL_RESET HECI command to reset the system.
-	 - If RW update is a CSE FW downgrade, then coreboot has to send
-        DATA_CLEAR command to clear run time data of CSE.
-	 - Enable HMRFPO Mode (Host ME Region Flash Protection Override) by
-        sending HMRFPO_ENABLE HECI command to CSE.
-	 - Erase and Copy the CBFS CSE RW to CSE RW partition
-     - Set CSE's next boot partition to RW.
-	 - Trigger Global Reset which resets both CSE and Host.
-	Then system should boot with the updated CSE.
-
-* The resulting flash layout is shown below:
-
-![Flash Layout](./Layout_before.svg) ![FlashLayout](./Layout_after.svg)
-
-
- - Typical boot flow
-
-   - Vboot selects the RW FW (FW_MAIN_A or FW_MAIN_B) to boot.
-   - coreboot skips CSE FW update flow if boot mode is recovery.
-   - If CSE RW blob is not locatable in the CBFS, then RW Firmware skips update flow
-     and sends SET_BOOT_PARTITION_INFO command to switch CSE to boot from RW
-     and issues Global Reset if CSE is already not booting from RW partition.
-   - The RW firmware will compare the CSE RW version with CSE RW blob in the slot.
-   - If there is a mismatch, then firmware will carry out update flow as explained before.

Documentation/soc/intel/icelake/iceLake_coreboot_development.md

@@ -20,6 +20,11 @@ Like any other Intel SoC, Ice Lake coreboot development is also based on "Intel
    :doc:`../../../mainboard/intel/icelake_rvp`
    ```
 
+3. OEMs to design based on reference platform and make use of mainboard sample code. Dragonegg is Ice Lake based mainboard developed by Google
+   ```eval_rst
+   :doc:`../../../mainboard/google/dragonegg`
+   ```
+
 ### Summary:
 * SoC is Ice Lake.
 * Reference platform is icelake_rvp.

Documentation/soc/intel/index.md

@@ -8,7 +8,5 @@ This section contains documentation about coreboot on specific Intel SOCs.
 - [FSP](fsp/index.md)
 - [Ice Lake/9th Gen Core-i series](icelake/index.md)
 - [MP Initialization](mp_init/mp_init.md)
-- [Microcode Updates](microcode.md)
 - [Firmware Interface Table](fit.md)
 - [Apollolake](apollolake/index.md)
-- [CSE FW Update](cse_fw_update/cse_fw_update.md)

Documentation/soc/intel/microcode.md

@@ -1,136 +0,0 @@
-# Microcode updates
-
-When booting a modern x86 platform, one task of the firmware is to update
-[microcode] to correct hardware bugs and mitigate security issues found
-after silicon has been shipped. The [Pentium FDIV bug] could have been
-fixed with a microcode update, had the Pentium used updateable microcode.
-Starting with the Pentium Pro, CPU microcode can be updated by software.
-
-As per BIOS Writer's Guides, Intel defines a processor as the silicon and
-the accompanying microcode update, and considers any processor that does
-not have its microcode updated to be running out of specification. This
-suggests that microcode is a crucial ingredient for correct operation.
-
-On multi-processor or Hyper-Threading-enabled systems, each thread has
-its own microcode. Therefore, microcode must be updated on every thread.
-
-## When to update microcode
-
-When a CPU core comes out of reset, it uses microcode from an internal
-ROM. This “default” microcode often contains bugs, so it needs to be
-updated as soon as possible. For example, Core 2 CPUs can boot without
-microcode updates, but have stability problems. On newer platforms,
-it is nearly impossible to boot without having updated the microcode.
-On some platforms, an updated microcode is required in order to enable
-Cache-As-RAM or to be able to successfully initialize the DRAM.
-
-Plus, microcode needs to be loaded multiple times. Intel Document 504790
-explains that this is because of so-called *enhanced microcode updates*,
-which are large updates with errata workarounds for both core and uncore.
-In order to correctly apply enhanced microcode updates, the [MP-Init]
-algorithm must be decomposed into multiple initialization phases.
-
-### Firmware Interface Table
-
-Beginning with 4th generation Intel Core processors, it is possible for
-microcode to be updated before the CPU is taken out of reset. This is
-accomplished by means of [FIT], a data structure which contains pointers
-to various firmware ingredients in the BIOS flash.
-
-In rare cases, FIT microcode updates may not be successful. Therefore,
-it is important to check that the microcode is up-to-date and, if not,
-update it. This needs to be done as early as possible, like on older
-processor generations without FIT support.
-
-Whether all threads on a processor get their microcode updated through
-FIT is not clear. According to Intel Documents 493770 and 535094, FIT
-microcode updates are applied to all cores within the package. However,
-Intel Document 550049 states that FIT microcode updates are applied to
-all threads within the package.
-
-## SMM bring-up
-
-Prior to SMM relocation, microcode must have been updated at least once.
-
-## Multi-Processor bring-up
-
-The BWG briefly describes microcode updates as part of the *MP-Init*.
-
-### MP-Init
-
-As part of the [MP-Init] sequence, two microcode updates are required.
-
-* The first update must happen as soon as one AP comes out of reset.
-* The second update must happen after the MP-Init sequence has written MTRRs,
-  PRMRR, DCU mode and prefetcher configuration, SMM has been relocated, but
-  before clearing the MCE banks.
-
-## Recommendations
-
-The Linux kernel developer's recommendations are:
-* Serialize microcode updates if possible.
-* Idle as many APs as possible while updating.
-* Idle the sibling thread on a Hyper-Threading enabled CPU while updating.
-
-## Platform BWGs
-
-The requirements specified in BWGs differ between platforms:
-
-### Sandy Bridge
-
-* Before setting up Cache-As-RAM, load microcode update into the SBSP.
-* Losing (non-SBSP) NBSPs must load their microcode update before being placed
-  back in the wait-for-SIPI state.
-* Sibling threads on HT must use a semaphore.
-* Microcode update loading has been done prior to SMM relocation.
-* In MP-Init the microcode update on an AP must be done before initializing the
-  cache, MTRRs, SMRRs and PRMRRs.
-* In MP-Init a second update must happen on all threads after initializing the
-  cache, MTRRs, SMRRs and PRMRRs.
-
-Refer to Intel Document 504790 for details.
-
-### Haswell/Broadwell Client
-
-* A microcode update must exist in FIT.
-* During the race to the BSP semaphore, each NBSP must load its microcode update.
-* All HT enabled threads can load microcode in parallel. However, the
-  IA32_BIOS_UPDT_TRIG MSR is core-scoped, just like on other platforms.
-* Microcode update loading has been done prior to SMM relocation.
-* In MP-Init the microcode update on an AP must be done before initializing the
-  cache, MTRRs, SMRRs and EMRR.
-* In MP-Init a second update must happen on all threads after initializing the
-  cache, MTRRs, SMRRs and EMRR and after SMM initialization.
-
-Refer to Intel Document 493770 and 535094 for details.
-
-### Broadwell Server
-
-* A microcode update must exist in FIT.
-* Before setting up Cache-As-RAM, load microcode update into each BSP.
-* In MP-Init the microcode update on an AP must be done before initializing the
-  cache, MTRRs, SMRRs and EMRR.
-* In MP-Init a second update must happen on all threads after initializing the
-  cache, MTRRs, SMRRs and EMRR and after SMM initialization.
-
-Refer to Intel Document 546625 for details.
-
-### Skylake/Kaby Lake/Coffee Lake/Whiskey Lake/Comet Lake
-
-* A microcode update must exist in FIT.
-* Before setting up Cache-As-RAM, load microcode update into the BSP.
-* Microcode update loading has been done prior to SMM relocation.
-* In MP-Init the first update must happen as soon as one AP comes out of reset.
-* In MP-Init the second update must happen after the MP-Init sequence has
-  written MTRRs, PRMRR, DCU mode and prefetcher configuration, but before
-  clearing the MCE banks.
-* Microcode updates must happen on all threads.
-* Sibling threads on HT should use a semaphore.
-
-Refer to Intel Document 550049 for details.
-
-[microcode]: https://en.wikipedia.org/wiki/Microcode
-[Pentium FDIV bug]: https://en.wikipedia.org/wiki/Pentium_FDIV_bug
-[FIT]: fit.md
-[SDM]: https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
-[MP-Init]: mp_init/mp_init.md

Documentation/soc/qualcomm/index.md

@@ -5,4 +5,3 @@ This section contains documentation about coreboot on specific Qualcomm SOCs.
 ## Platforms
 
 - [SC7180 series](sc7180/index.md)
-- [SC7280 series](sc7280/index.md)

Documentation/soc/qualcomm/sc7280/index.md

@@ -1,17 +0,0 @@
-# Qualcomm SC7280 documentation
-
-## SOC code
-
-The SOC folder contains functions for:
-* MMU
-* CLOCK
-* GPIO
-* QUPv3 FW (provides a bridge to serial interfaces)
-* UART
-* SPI-NOR
-* AOP FW
-* USB
-
-## Notes about the hardware
-
-The timer is used from the ARMv8 architecture specific code.

Documentation/technotes/asan.md

@@ -1,302 +0,0 @@
-# Address Sanitizer
-
-Memory safety is hard to achieve. We, as humans, are bound to make mistakes in
-our code. While it may be straightforward to detect memory corruption bugs in
-few lines of code, it becomes quite challenging to find those bugs in a massive
-code. In such cases, 'Address Sanitizer' may prove to be useful and could help
-save time.
-
-[Address Sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer)
-, also known as ASan, is a runtime memory debugger designed to find
-out-of-bounds accesses and use-after-scope bugs. coreboot has an in-built
-Address Sanitizer. Therefore, it is advised to take advantage of this debugging
-tool while working on large patches. This would further help to ensure code
-quality and make runtime code more robust.
-
-## Types of errors detected
-ASan in coreboot catches the following types of memory bugs:
-
-### Stack buffer overflow
-Example stack-out-of-bounds:
-```c
-void foo()
-{
-	int stack_array[5] = {0};
-        int i, out;
-	for (i = 0; i < 10; i++)
-		out = stack_array[i];
-}
-```
-In this example, the array is of length 5 but it is being read even beyond the
-index 4.
-
-### Global buffer overflow
-Example global-out-of-bounds:
-```c
-char a[] = "I use coreboot";
-
-void foo()
-{
-        char b[] = "proprietary BIOS";
-        strcpy(a + 6, b);
-}
-```
-In this example,
-> well, you are replacing coreboot with proprietary BIOS. In any case, that's
-an "error".
-
-Let's come to the memory bug. The string 'a' is of length 14 but it is being
-written to even beyond that.
-
-### Use after scope
-Example use-after-scope:
-```c
-volatile int *p = 0;
-
-void foo() {
-  {
-    int x = 0;
-    p = &x;
-  }
-  *p = 5;
-}
-```
-In this example, the value 5 is written to an undefined address instead of the
-variable 'x'. This happens because 'x' can't be accessed outside its scope.
-
-## Using ASan
-
-In order to enable ASan on a supported platform,
-select `Address sanitizer support` from `General setup` menu while configuring
-coreboot.
-
-Then build coreboot and run the image as usual. If your code contains any of the
-above-mentioned memory bugs, ASan will report them in the console log as shown
-below:
-```text
-ASan: <bug type> in <ip>
-<access type> of <access size> bytes at addr <access address>
-```
-where,
-
-`bug type` is either `stack-out-of-bounds`, `global-out-of-bounds` or
-`use-after-scope`,
-
-`ip` is the address of the last good instruction before the bad access,
-
-`access type` is either `Read` or `Write`,
-
-`access size` is the number of bytes read or written, and
-
-`access address` is the memory location which is accessed while the error
-occurs.
-
-Next, you have to use `ip` to retrieve the instruction which causes the error.
-Since stages in coreboot are relocated, you need to normalize `ip`. For this,
-first subtract the start address of the stage from `ip`. Then, read the section
-headers from `<stage>.debug` file to determine the offset of the text segment.
-Add this offset to the difference you calculated earlier. Let's call the
-resultant address `ip'`.
-
-Next, read the contents of the symbol table and search for a function having
-an address closest to `ip'`. This is the function in which our memory bug is
-present. Let's denote the address of this function by `ip''`.
-
-Finally, read the assembly contents of the object file where this function is
-present. Look for the affected function. Here, the instruction which exists at
-the offset `ip' - ip''` corresponds to the address `ip`. Therefore, the very
-next instruction is the one which causes the error.
-
-To see ASan in action, let's take an example. Suppose, there is a
-stack-out-of-bounds error in cbfs.c that we aren’t aware of and we want ASan
-to help us detect it.
-```c
-int cbfs_boot_region_device(struct region_device *rdev)
-{
-	int array[5], i;
-	boot_device_init();
-
-	for (i = 10; i > 0; i--)
-		array[i] = i;
-
-	return vboot_locate_cbfs(rdev) &&
-	       fmap_locate_area_as_rdev("COREBOOT", rdev);
-}
-```
-First, we enable ASan from the configuration menu as shown above. Then, we
-build coreboot and run the image.
-
-ASan reports the following error in the console log:
-```text
-ASan: stack-out-of-bounds in 0x7f7432fd
-Write of 4 bytes at addr 0x7f7c2ac8
-```
-Here 0x7f7432fd is `ip` i.e. the address of the last good instruction before
-the bad access. First we have to normalize this address as stated above.
-As per the console log, this error happened in ramstage and the stage starts
-from 0x7f72c000. So, let’s look at the sections headers of ramstage from
-`ramstage.debug`.
-```text
-$ objdump -h build/cbfs/fallback/ramstage.debug
-
-build/cbfs/fallback/ramstage.debug:     file format elf32-i386
-
-Sections:
-Idx Name          Size      VMA       LMA       File off  Algn
-  0 .text         00070b20  00e00000  00e00000  00001000  2**12
-                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
-  1 .ctors        0000036c  00e70b20  00e70b20  00071b20  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, DATA
-  2 .data         0001c8f4  00e70e8c  00e70e8c  00071e8c  2**2
-                  CONTENTS, ALLOC, LOAD, RELOC, DATA
-  3 .bss          00012940  00e8d780  00e8d780  0008e780  2**7
-                  ALLOC
-  4 .heap         00004000  00ea00c0  00ea00c0  0008e780  2**0
-                  ALLOC
-```
-As you can see, the offset of the text segment is 0x00e00000. Let's subtract the
-start address of the stage from `ip` and add this offset to the difference. The
-resultant address i.e. `ip'` is 0x00e172fd.
-
-Next, we read the contents of the symbol table and search for a function having
-an address closest to 0x00e172fd.
-```text
-$ nm -n build/cbfs/fallback/ramstage.debug
-........
-........
-00e17116 t _GLOBAL__sub_I_65535_1_gfx_get_init_done
-00e17129 t tohex16
-00e171db T cbfs_load_and_decompress
-00e1729b T cbfs_boot_region_device
-00e17387 T cbfs_boot_locate
-00e1740d T cbfs_boot_map_with_leak
-00e174ef T cbfs_boot_map_optionrom
-........
-........
-```
-The symbol having an address closest to 0x00e172fd is `cbfs_boot_region_device` and
-its address i.e. `ip''` is 0x00e1729b.
-
-Now, as we know the affected function, let's read the assembly contents of
-`cbfs_boot_region_device()` which is present in `cbfs.o` to find the faulty
-instruction.
-```text
-$ objdump -d build/ramstage/lib/cbfs.o
-........
-........
-  51:   e8 fc ff ff ff          call   52 <cbfs_boot_region_device+0x52>
-  56:   83 ec 0c                sub    $0xc,%esp
-  59:   57                      push   %edi
-  5a:   83 ef 04                sub    $0x4,%edi
-  5d:   e8 fc ff ff ff          call   5e <cbfs_boot_region_device+0x5e>
-  62:   83 c4 10                add    $0x10,%esp
-  65:   89 5f 04                mov    %ebx,0x4(%edi)
-  68:   4b                      dec    %ebx
-  69:   75 eb                   jne    56 <cbfs_boot_region_device+0x56>
-........
-........
-```
-Here, we look for the instruction present at the offset 62 i.e. `ip' - ip''`.
-The instruction is `add $0x10,%esp` and it corresponds to
-`for (i = 10; i > 0; i--)` in our code. It means the very next instruction
-i.e. `mov %ebx,0x4(%edi)` is the one that causes the error. Now, as we look at
-C code of `cbfs_boot_region_device()` again, we find that this instruction
-corresponds to `array[i] = i`.
-
-Voilà! We just caught the memory bug using ASan.
-
-## Supported platforms
-Presently, the following architectures support ASan in ramstage:
-```eval_rst
-+------------------+--------------------------------+
-| Architecture     | Notes                          |
-+==================+================================+
-| x86              | Support for all x86 platforms  |
-+------------------+--------------------------------+
-```
-
-And in romstage ASan is available on the following platforms:
-```eval_rst
-+---------------------+-----------------------------+
-| Platform            | Notes                       |
-+=====================+=============================+
-| QEMU i440-fx        |                             |
-+---------------------+-----------------------------+
-| Intel Apollo Lake   |                             |
-+---------------------+-----------------------------+
-| Intel Haswell       |                             |
-+---------------------+-----------------------------+
-```
-Alternatively, you can use `grep` to view the list of platforms that support
-ASan in romstage:
-
-    $ git grep "select HAVE_ASAN_IN_ROMSTAGE"
-
-If the x86 platform you are using is not listed here, there is
-still a chance that it supports ASan in romstage.
-
-To test it, select `HAVE_ASAN_IN_ROMSTAGE` from the Kconfig file in the
-platform's dedicated directory. Then, enable ASan from the config menu as
-indicated in the previous section.
-
-If you are able to build coreboot without any errors and boot cleanly, that
-means the platform supports ASan in romstage. In that case, please upload a
-patch on Gerrit selecting this config option using 'ASan' topic. Also, update
-the platform name in the table.
-
-However, if you end up in compilation errors or the linker error saying that
-the cache got full, additional steps need to be taken to enable ASan in
-romstage on the platform. While compile errors could be resolved easily and
-therefore ASan in romstage has a good chance to be supported, a full cache is
-an indication that it is way more work or even likely impossible to enable
-ASan in romstage.
-
-## Future work
-### Heap buffer overflow
-Presently, ASan doesn't detect out-of-bounds accesses for the objects defined
-in heap.
-
-To add support for these type of memory bugs, you have to make sure that
-whenever some block of memory is allocated in the heap, the surrounding areas
-(redzones) are poisoned. Correspondingly, these redzones should be unpoisoned
-when the memory block is de-allocated.
-
-### ASan on other architectures
-The following points should help when adding support for ASan to other
-architectures like ARM or RISC-V:
-
-* Enabling ASan in ramstage on other architectures should be easy. You just
-have to make sure the shadow memory is initialized as early as possible when
-ramstage is loaded. This can be done by making a function call to `asan_init()`
-at the appropriate place.
-
-* For romstage, you have to find out if there is enough room in the cache to fit
-the shadow memory region. For this, find the boundary linker symbols for the
-region you'd want to run ASan on, excluding the hardware mapped addresses.
-Then define a new linker section named `asan_shadow` of size
-`(_end - _start) >> 3`, where `_start` and `_end` are the linker symbols you
-found earlier. This section should be appended to the region already occupied
-by the coreboot program. Now build coreboot. If you don't see any errors while
-building with the current translation function, ASan can be enabled on that
-platform.
-
-* The shadow region we currently use consumes memory equal to 1/8th of the
-program memory. So, if you end up in a linker error saying that the memory got
-full, you'll have to use a more compact shadow region. In that case, the
-translation function could be something like
-`shadow = (mem >> 7) | shadow_offset`. Since the stack buffers are protected by
-the compiler, you'll also have to create a GCC patch forcing it to use the new
-translation function for this particular architecture.
-
-* Once you are sure that the architecture supports ASan in ramstage, select
-`HAVE_ASAN_IN_RAMSTAGE` from the Kconfig file of that architecture. Similarly,
-if the platform supports ASan in romstage, select `HAVE_ASAN_IN_ROMSTAGE` from
-the platform's dedicated Kconfig file.
-
-### Post-processing script
-Unlike Linux, coreboot doesn't have `%pS` printk format to dereference pointer
-to its symbolic name. Therefore, we normalise the pointer address manually to
-determine the name of the affected function and further use it to find the
-instruction which causes the error.
-
-A custom script can be written to automate this process.

Documentation/technotes/index.md

@@ -3,4 +3,3 @@
 * [Dealing with Untrusted Input in SMM](2017-02-dealing-with-untrusted-input-in-smm.md)
 * [Rebuilding coreboot image generation](2015-11-rebuilding-coreboot-image-generation.md)
 * [Unit testing coreboot](2020-03-unit-testing-coreboot.md)
-* [Address Sanitizer](asan.md)

Documentation/tutorial/index.md

@@ -3,4 +3,3 @@
 * [Part 1: Starting from scratch](part1.md)
 * [Part 2: Submitting a patch to coreboot.org](part2.md)
 * [Part 3: Writing unit tests](part3.md)
-* [Managing local additions](managing_local_additions.md)

Documentation/tutorial/managing_local_additions.md

@@ -1,43 +0,0 @@
-Managing local additions
-========================
-
-This section describes the site-local mechanism, what it is good for and
-how it can be used.
-
-What is site-local?
--------------------
-site-local is the name of a directory that won't ever appear in the
-upstream coreboot repository but is referred to in several key places of its
-configuration and build system. The intent is provide a single location to
-store local modifications.
-
-By keeping local additions to builds in this place, it can be versioned
-independently from upstream (e.g. controlled by git in another repository)
-and any changes made there won't ever conflict with upstream changes.
-
-This optional directory is searched for in the top-level of the coreboot
-repo and is called `site-local`.
-
-Integration into the configuration system
------------------------------------------
-Kconfig includes `site-local/Kconfig` relatively early, so it can be used
-to pre-define some configuration before coreboot's regular ruleset sets
-up defaults.
-
-Integration into the build system
----------------------------------
-The build system includes, if present, `site-local/Makefile.inc`. The main
-purpose so far has been to add additional files to a CBFS image. A single
-Makefile.inc can serve multiple boards, for example:
-
-    cbfs-files-$(CONFIG_BOARD_INTEL_D945GCLF) += pci8086,2772.rom
-    pci8086,2772.rom-file := intel_d945gclf/pci8086,2772.rom
-    pci8086,2772.rom-type := optionrom
-
-    cbfs-files-$(CONFIG_BOARD_KONTRON_986LCD_M) += pci8086,27a2.rom
-    pci8086,27a2.rom-file := kontron_986lcd-m/pci8086,27a2.rom
-    pci8086,27a2.rom-type := optionrom
-
-This adds the correct Option ROM binary (which are non-redistributable and
-therefore can't become part of the coreboot.org repos) to coreboot.rom when
-built for intel/d945gclf or kontron/986lcd-m.

Documentation/tutorial/part1.md

@@ -19,21 +19,9 @@ Download, configure, and build coreboot
     $ cd coreboot
 
 ### Step 3 - Build the coreboot toolchain
-Please note that this can take a significant amount of time. Use `CPUS=` to
-specify number of `make` jobs to run in parallel.
+Please note that this can take a significant amount of time.
 
-This will list toolchain options and supported architectures:
-
-    $ make help_toolchain
-
-Here are some examples:
-
-    $ make crossgcc-i386 CPUS=$(nproc)       # build i386 toolchain
-    $ make crossgcc-aarch64 CPUS=$(nproc)    # build Aarch64 toolchain
-    $ make crossgcc-riscv CPUS=$(nproc)      # build RISC-V toolchain
-
-Note that the i386 toolchain is currently used for all x86 platforms, including
-x86_64.
+    $ make crossgcc-i386 CPUS=$(nproc)
 
 Also note that you can possibly use your system toolchain, but the results are
 not reproducible, and may have issues, so this is not recommended.  See step 5