WIP: lemp9 vboot support

Change-Id: I47fbc95a8bd242b4261f5fc52b073f0b2b6ab080

.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,60 +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
+	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/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
 

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

@@ -7,4 +7,3 @@ they allow to easily reuse existing code accross platforms.
 * [IPMI KCS](ipmi_kcs.md)
 * [SMMSTORE](smmstore.md)
 * [SoundWire](soundwire.md)
-* [SMMSTOREv2](smmstorev2.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

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 */

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.
 
 --------------------------------------------------------------------------------
 

Documentation/index.md

@@ -166,7 +166,6 @@ Contents:
 * [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)

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.
@@ -291,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/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
@@ -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/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/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

@@ -26,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)
@@ -41,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
 
@@ -65,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
 
@@ -124,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
@@ -145,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)

Documentation/mainboard/lenovo/montevina_series.md

@@ -89,7 +89,7 @@ $ make
 ```
 
 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:
+`flreg1_limit` in the ifd-x200.set file according to following table:
 
 ```eval_rst
 +-----------------+-------+-------+--------+

Documentation/mainboard/lenovo/t440p.md

@@ -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/ocp/deltalake.md

@@ -1,8 +1,7 @@
 # OCP Delta Lake
 
 This page describes coreboot support status for the [OCP] (Open Compute Project)
-Delta Lake server platform. This page is updated following each 4-weeks
-build/test/release cycle.
+Delta Lake server platform.
 
 ## Introduction
 
@@ -14,9 +13,8 @@ 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 in one sled.
 
-The Yosemite-V3 program has reached DVT exit. Facebook, Intel and partners
-jointly develop FSP/coreboot/LinuxBoot stack on Delta Lake as an alternative
-solution. This development is moving toward EVT 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
 
@@ -24,7 +22,7 @@ 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 some time after the MP
   (Mass Production) of CooperLake Scalable Processor when the FSP is mature.
-- Microcode: Available through github.com:otcshare/Intel-Generic-Microcode.git.
+- Microcode: Not yet available to the public.
 - ME binary: Not yet available to the public.
 
 ## Payload
@@ -57,49 +55,26 @@ as initramfs.
     - 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 32 -- System Boot Information
-    - Type 38 -- IPMI Device Information
+    - 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
-    - Check BMC version: ipmidump -device
 - SEL record generation
 - Early serial output
 - port 80h direct to GPIO
-- ACPI tables: APIC/DMAR/DSDT/FACP/FACS/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
+- 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
-- Versions
-    - Check FSP version: cbmem | grep LB_TAG_PLATFORM_BLOB_VERSION
-    - Check Microcode version: cat /proc/cpuinfo | grep microcode
-- Devices:
-    - Boot drive
-    - NIC card
-    - All 5 data drives
-- Power button
-- localboot
-- netboot from IPv6
-- TPM
-
-## Stress/performance tests passed
-- OS warm reboot (300 cycles)
-- DC reboot (300 cycles)
-- AC reboot (300 cycle)
-- Mprime test (6 hours)
-- StressAppTest (6 hours)
-- Ptugen (6 hours)
-- MLC (Intel Memory Latency Check)
-- Linkpack
-- Iperf(IPv6)
-- FIO
 
 ## Firmware configurations
 [ChromeOS VPD] is used to store most of the firmware configurations.
@@ -109,22 +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.
-- DeltaLake specific VPDs: check mb/ocp/deltalake/vpd.h.
 
 ## Known issues
-- spsInfoLinux64 command fail to return ME version.
-- fwts test failures related to mtrr.
-- kernel error message related to SleepButton ACPI event.
+- 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
+- Delta Lake DVT is not supported, as we only have Delta Lake EVT servers
+  at the moment.
 - SMBIOS:
-    - Type 16 -- Physical Memory Array
+    - Type 7 -- Cache Information
     - Type 17 -- Memory Device
-    - Type 19 -- Memory Array Mapped Address
+    - Type 38 -- IPMI Device Information
     - Type 41 -- Onboard Devices Extended Information
-- Verified measurement through CBnT
-- Boot guard of CBnT
-- RO_VPD region as well as other RO regions are not write protected.
+- ACPI:
+    - DMAR
+- PFR/CBnT
 
 ## Technology
 
@@ -134,7 +116,7 @@ VPD variables supported are:
 +------------------------+---------------------------------------------+
 | BMC                    | Aspeed AST 2500                             |
 +------------------------+---------------------------------------------+
-| PCH                    | Intel Lewisburg C620 Series                 |
+| PCH                    | Intel Lewisburg C621                        |
 +------------------------+---------------------------------------------+
 ```
 

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/x11-lga1151-series/x11ssh-f/x11ssh-f.md

@@ -1,103 +0,0 @@
-# Supermicro X11SSH-F
-
-This section details how to run coreboot on the [Supermicro X11SSH-F].
-
-## 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)
-
-## 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                           |
-|                  | 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
-[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/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,102 +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.
+### Add significant changes here

Documentation/releases/coreboot-4.14-relnotes.md

@@ -1,16 +0,0 @@
-Upcoming release - coreboot 4.14
-================================
-
-The 4.14 release is planned for May 2021.
-
-Update this document with changes that should be in the release notes.
-
-* 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
--------------------
-
-### Add significant changes here

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/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,11 +139,9 @@
 - Smaug (Google Pixel C)
 - Storm (OnHub Router TGR1900)
 - Stout (Lenovo Thinkpad X131e Chromebook)
-- Bubs
-- Coachz
-- Lazor
-- Pompom
 - Trogdor
+- Lazor
+- Bubs
 - Veyron_Jaq (Haier Chromebook 11)
 - Veyron_Jerry (Hisense Chromebook 11)
 - Veyron_Mighty (Haier Chromebook 11(edu))
@@ -164,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
@@ -232,7 +206,6 @@
 - ThinkPad X1
 - ThinkPad X230
 - ThinkPad X230t
-- ThinkPad X230s
 - ThinkPad X60 / X60s / X60t
 
 ## OpenCellular
@@ -253,7 +226,6 @@
 ## Supermicro
 - X11SSH-TF
 - X11SSM-F
-- X11SSH-F
 
 ## 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/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_model.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/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/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

MAINTAINERS

@@ -208,14 +208,6 @@ F:	src/mainboard/asus/p8z77-v_lx2/
 
 
 
-CLEVO MAINBOARDS
-M:	Felix Singer <felixsinger@posteo.net>
-M:	Michael Niewöhner <foss@mniewoehner.de>
-S:	Supported
-F:	src/mainboard/clevo/
-
-
-
 FACEBOOK FBG1701 MAINBOARD
 M:	Frans Hendriks <fhendriks@eltan.com>
 M:	Wim Vervoorn <wvervoorn@eltan.com>
@@ -401,7 +393,7 @@ F:	src/mainboard/supermicro/x10slm-f/
 SUPERMICRO X11-LGA1151-SERIES
 M:	Michael Niewöhner <foss@mniewoehner.de>
 S:	Maintained
-F:	src/mainboard/supermicro/x11-lga1151-series/
+F:	src/mainboard/supermicro/x11-lga1151-series
 
 ################################################################################
 # Architectures
@@ -412,6 +404,7 @@ M:	Julius Werner <jwerner@chromium.org>
 S:	Supported
 F:	src/arch/arm/
 F:	src/arch/arm64/
+F:	src/soc/mediatek/
 F:	src/soc/nvidia/
 F:	src/soc/rockchip/
 F:	util/nvidia/
@@ -529,14 +522,6 @@ F:	src/drivers/intel/fsp2_0/
 # Systems on a Chip
 ################################################################################
 
-AMD Picasso
-M:	Marshall Dawson <marshalldawson3rd@gmail.com>
-M:	Felix Held <felix-coreboot@felixheld.de>
-M:	Jason Glenesk <jason.glenesk@gmail.com>
-S:	Maintained
-F:	src/soc/amd/picasso
-F:	src/vendorcode/amd/fsp/picasso
-
 INTEL APOLLOLAKE_SOC
 M:	Andrey Petrov <andrey.petrov@gmail.com>
 S:	Maintained
@@ -562,15 +547,10 @@ F:	src/soc/intel/xeon_sp
 F:	src/vendorcode/intel/fsp/fsp2_0/skylake_sp
 F:	src/vendorcode/intel/fsp/fsp2_0/copperlake_sp
 
-MEDIATEK SOCS
-M:	Hung-Te Lin <hungte@chromium.org>
-S:	Supported
-F:	src/soc/mediatek
-
 ORPHANED ARM SOCS
 S:	Orphaned
 F:	src/cpu/armltd/
-F:	src/soc/ti/
+F:	src/cpu/ti/
 F:	src/soc/qualcomm/
 F:	src/soc/samsung/
 F:	util/exynos/
@@ -702,13 +682,8 @@ OPTION ROM EXECUTION & X86EMU
 F:	src/device/oprom/
 
 CBFS
-M:	Julius Werner <jwerner@chromium.org>
-F:	src/include/cbfs*
-F:	src/commonlib/bsd/include/commonlib/bsd/cbfs*
-F:	src/commonlib/bsd/cbfs*
-F:	src/lib/cbfs.c
-
-CBFSTOOL
+F:	src/include/cbfs.h
+F:	src/commonlib/bsd/include/commonlib/bsd/cbfs_serialized.h
 F:	util/cbfstool/
 
 CBMEM

Makefile

@@ -440,10 +440,10 @@ doxygen_simple:
 doxyplatform doxygen_platform: $(obj)/project_filelist.txt
 	echo
 	echo "Building doxygen documentation for $(CONFIG_MAINBOARD_PART_NUMBER)"
-	export DOXYGEN_OUTPUT_DIR="$$( echo $(DOXYGEN_OUTPUT_DIR)/$(call strip_quotes, $(CONFIG_MAINBOARD_VENDOR))_$(call strip_quotes, $(CONFIG_MAINBOARD_PART_NUMBER)) | sed 's|[^A-Za-z0-9/]|_|g' )"; \
+	export DOXYGEN_OUTPUT_DIR="$(DOXYGEN_OUTPUT_DIR)/$(CONFIG_MAINBOARD_VENDOR)/$(CONFIG_MAINBOARD_PART_NUMBER)"; \
 	mkdir -p "$$DOXYGEN_OUTPUT_DIR"; \
 	export DOXYFILES="$$(cat $(obj)/project_filelist.txt | grep -v '\.ld$$' | sed 's/\.aml/\.dsl/' | tr '\n' ' ')"; \
-	export DOXYGEN_PLATFORM="$(call strip_quotes, $(CONFIG_MAINBOARD_DIR)) \($(call strip_quotes, $(CONFIG_MAINBOARD_PART_NUMBER))\) version $(KERNELVERSION)"; \
+	export DOXYGEN_PLATFORM="$(CONFIG_MAINBOARD_DIR) ($(CONFIG_MAINBOARD_PART_NUMBER)) version $(KERNELVERSION)"; \
 	$(DOXYGEN) Documentation/doxygen/Doxyfile.coreboot_platform
 
 doxyclean: doxygen-clean

Makefile.inc

@@ -13,7 +13,6 @@ CONFIG_CBFS_PREFIX:=$(call strip_quotes,$(CONFIG_CBFS_PREFIX))
 CONFIG_FMDFILE:=$(call strip_quotes,$(CONFIG_FMDFILE))
 CONFIG_DEVICETREE:=$(call strip_quotes, $(CONFIG_DEVICETREE))
 CONFIG_OVERRIDE_DEVICETREE:=$(call strip_quotes, $(CONFIG_OVERRIDE_DEVICETREE))
-CONFIG_CHIPSET_DEVICETREE:=$(call strip_quotes, $(CONFIG_CHIPSET_DEVICETREE))
 CONFIG_MEMLAYOUT_LD_FILE:=$(call strip_quotes, $(CONFIG_MEMLAYOUT_LD_FILE))
 
 #######################################################################
@@ -80,10 +79,10 @@ subdirs-y := src/lib src/commonlib/ src/console src/device src/acpi
 subdirs-y += src/ec/acpi $(wildcard src/ec/*/*) $(wildcard src/southbridge/*/*)
 subdirs-y += $(wildcard src/soc/*/*) $(wildcard src/northbridge/*/*)
 subdirs-y += src/superio
-subdirs-y += $(wildcard src/drivers/*) $(wildcard src/drivers/*/*) $(wildcard src/drivers/*/*/*)
+subdirs-y += $(wildcard src/drivers/*) $(wildcard src/drivers/*/*)
 subdirs-y += src/cpu src/vendorcode
-subdirs-y += util/cbfstool util/sconfig util/nvramtool util/pgtblgen util/amdfwtool
-subdirs-y += util/futility util/marvell util/bincfg util/supermicro util/qemu
+subdirs-y += util/cbfstool util/sconfig util/nvramtool util/pgtblgen
+subdirs-y += util/futility util/marvell util/bincfg util/supermicro
 subdirs-y += $(wildcard src/arch/*)
 subdirs-y += src/mainboard/$(MAINBOARDDIR)
 subdirs-y += src/security
@@ -265,14 +264,12 @@ REDUNDANT_OFFSET_REMARK = 2158
 # "Multiple types (Device object requires either a _HID or _ADR, but not both)"
 MULTIPLE_TYPES_WARNING = 3073
 
-IASL_WARNINGS_LIST = $(EMPTY_RESOURCE_TEMPLATE_WARNING) $(REDUNDANT_OFFSET_REMARK)
-
 ifeq ($(CONFIG_SOUTHBRIDGE_INTEL_LYNXPOINT)$(CONFIG_SOC_INTEL_BROADWELL),y)
-IASL_WARNINGS_LIST += $(MULTIPLE_TYPES_WARNING)
+IGNORED_IASL_WARNINGS = -vw $(EMPTY_RESOURCE_TEMPLATE_WARNING) -vw $(REDUNDANT_OFFSET_REMARK) -vw $(MULTIPLE_TYPES_WARNING)
+else
+IGNORED_IASL_WARNINGS = -vw $(EMPTY_RESOURCE_TEMPLATE_WARNING) -vw $(REDUNDANT_OFFSET_REMARK)
 endif
 
-IGNORED_IASL_WARNINGS = $(addprefix -vw , $(IASL_WARNINGS_LIST))
-
 define asl_template
 $(CONFIG_CBFS_PREFIX)/$(1).aml-file = $(obj)/$(1).aml
 $(CONFIG_CBFS_PREFIX)/$(1).aml-type = raw
@@ -283,7 +280,6 @@ $(obj)/$(1).aml: $(src)/mainboard/$(MAINBOARDDIR)/$(1).asl $(obj)/config.h
 	@printf "    IASL       $$(subst $(top)/,,$$(@))\n"
 	$(CC_ramstage) -x assembler-with-cpp -E -MMD -MT $$(@) $$(CPPFLAGS_ramstage) -D__ACPI__ -P -include $(src)/include/kconfig.h -I$(obj) -I$(src) -I$(src)/include -I$(src)/arch/$(ARCHDIR-$(ARCH-ramstage-y))/include -I$(src)/mainboard/$(MAINBOARDDIR) $$< -o $(obj)/$(1).asl
 	cd $$(dir $$@); $(IASL) $(IGNORED_IASL_WARNINGS) -we -p $$(notdir $$@) $(1).asl
-	echo "    IASL       "$(IASL_WARNINGS_LIST)" warning types were ignored!"
 	if ! $(IASL) -d $$@ 2>&1 | grep -Eq 'ACPI (Warning|Error)'; then	\
 		echo "    IASL       $$@ disassembled correctly.";		\
 		true;								\
@@ -415,10 +411,6 @@ CPPFLAGS_common += -include $(src)/commonlib/bsd/include/commonlib/bsd/compiler.
 CPPFLAGS_common += -I3rdparty
 CPPFLAGS_common += -D__BUILD_DIR__=\"$(obj)\"
 
-ifeq ($(BUILD_TIMELESS),1)
-CPPFLAGS_common += -D__TIMELESS__
-endif
-
 ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_YABEL)$(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y)
 CPPFLAGS_ramstage += -Isrc/device/oprom/include
 endif
@@ -426,10 +418,10 @@ endif
 CFLAGS_common += -pipe -g -nostdinc -std=gnu11
 CFLAGS_common += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
 CFLAGS_common += -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough
-CFLAGS_common += -Wshadow -Wdate-time -Wtype-limits -Wvla
+CFLAGS_common += -Wstrict-aliasing -Wshadow -Wdate-time -Wtype-limits -Wvla
 CFLAGS_common += -Wlogical-op -Wduplicated-cond -Wdangling-else
 CFLAGS_common += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer
-CFLAGS_common += -fstrict-aliasing -ffunction-sections -fdata-sections -fno-pie
+CFLAGS_common += -ffunction-sections -fdata-sections -fno-pie
 ifeq ($(CONFIG_COMPILER_GCC),y)
 # Don't add these GCC specific flags when running scan-build
 ifeq ($(CCC_ANALYZER_OUTPUT_FORMAT),)
@@ -577,6 +569,9 @@ $(IFDTOOL):
 	cp -a $(top)/util/ifdtool/ifdtool $@
 
 AMDFWTOOL:=$(objutil)/amdfwtool/amdfwtool
+$(AMDFWTOOL): $(top)/util/amdfwtool/amdfwtool.c
+	@printf "    HOSTCC     $(subst $(obj)/,,$(@))\n"
+	$(HOSTCC) $(HOSTCFLAGS) -DCONFIG_ROM_SIZE=$(CONFIG_ROM_SIZE) -o $@ $<
 
 APCB_EDIT_TOOL:=$(top)/util/apcb/apcb_edit.py
 
@@ -593,34 +588,19 @@ $(obj)/config.h: $(objutil)/kconfig/conf
 # Creation of these is architecture and mainboard independent
 DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_DEVICETREE)
 
-SCONFIG_OPTIONS := --mainboard_devtree=$(DEVICETREE_FILE)
-
 ifneq ($(CONFIG_OVERRIDE_DEVICETREE),)
-OVERRIDE_DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_OVERRIDE_DEVICETREE)
-SCONFIG_OPTIONS += --override_devtree=$(OVERRIDE_DEVICETREE_FILE)
-endif
 
-ifneq ($(CONFIG_CHIPSET_DEVICETREE),)
-CHIPSET_DEVICETREE_FILE := $(src)/$(CONFIG_CHIPSET_DEVICETREE)
-SCONFIG_OPTIONS += --chipset_devtree=$(CHIPSET_DEVICETREE_FILE)
+OVERRIDE_DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_OVERRIDE_DEVICETREE)
+
 endif
 
 DEVICETREE_STATIC_C := $(obj)/mainboard/$(MAINBOARDDIR)/static.c
-SCONFIG_OPTIONS += --output_c=$(DEVICETREE_STATIC_C)
-
 DEVICETREE_STATIC_H := $(obj)/static.h
-SCONFIG_OPTIONS += --output_h=$(DEVICETREE_STATIC_H)
 
-DEVICETREE_DEVICENAMES_H := $(obj)/static_devices.h
-SCONFIG_OPTIONS += --output_d=$(DEVICETREE_DEVICENAMES_H)
-
-DEVICETREE_FWCONFIG_H := $(obj)/static_fw_config.h
-SCONFIG_OPTIONS += --output_f=$(DEVICETREE_FWCONFIG_H)
-
-$(DEVICETREE_STATIC_C): $(DEVICETREE_FILE) $(OVERRIDE_DEVICETREE_FILE) $(CHIPSET_DEVICETREE_FILE) $(objutil)/sconfig/sconfig
+$(DEVICETREE_STATIC_C): $(DEVICETREE_FILE) $(OVERRIDE_DEVICETREE_FILE) $(objutil)/sconfig/sconfig
 	@printf "    SCONFIG    $(subst $(src)/,,$(<))\n"
 	mkdir -p $(dir $(DEVICETREE_STATIC_C))
-	$(objutil)/sconfig/sconfig $(SCONFIG_OPTIONS)
+	$(objutil)/sconfig/sconfig $(DEVICETREE_FILE) $(DEVICETREE_STATIC_C) $(DEVICETREE_STATIC_H) $(OVERRIDE_DEVICETREE_FILE)
 
 ramstage-y+=$(DEVICETREE_STATIC_C)
 romstage-y+=$(DEVICETREE_STATIC_C)
@@ -732,16 +712,6 @@ TXTIBB :=
 
 endif
 
-ifeq ($(CONFIG_INTEL_CBNT_SUPPORT),y)
-
-CBNTIBB := --cbnt
-
-else
-
-CBNTIBB :=
-
-endif # CONFIG_INTEL_CBNT_SUPPORT
-
 ifeq ($(CONFIG_COMPRESS_BOOTBLOCK),y)
 
 $(objcbfs)/bootblock.lz4: $(objcbfs)/bootblock.elf $(objutil)/cbfstool/cbfs-compression-tool
@@ -1073,7 +1043,6 @@ $(obj)/fmap.fmap: $(obj)/fmap.fmd $(FMAPTOOL)
 ifeq ($(CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK),y)
 TS_OPTIONS := -j $(CONFIG_INTEL_TOP_SWAP_BOOTBLOCK_SIZE)
 endif
-
 ifneq ($(CONFIG_UPDATE_IMAGE),y)
 $(obj)/coreboot.pre: $(objcbfs)/bootblock.bin $$(prebuilt-files) $(CBFSTOOL) $(IFITTOOL) $$(cpu_ucode_cbfs_file) $(obj)/fmap.fmap $(obj)/fmap.desc
 	$(CBFSTOOL) $@.tmp create -M $(obj)/fmap.fmap -r $(shell cat $(obj)/fmap.desc)
@@ -1083,7 +1052,6 @@ ifeq ($(CONFIG_ARCH_X86),y)
 		-n bootblock \
 		-t bootblock \
 		$(TXTIBB) \
-		$(CBNTIBB) \
 		-b -$(call file-size,$(objcbfs)/bootblock.bin) $(cbfs-autogen-attributes) \
 		$(TS_OPTIONS)
 else # ifeq ($(CONFIG_ARCH_X86),y)
@@ -1129,11 +1097,28 @@ RAMSTAGE=
 endif
 
 $(obj)/coreboot.rom: $(obj)/coreboot.pre $(RAMSTAGE) $(CBFSTOOL) $$(INTERMEDIATE)
+
 	@printf "    CBFS       $(subst $(obj)/,,$(@))\n"
 # The full ROM may be larger than the CBFS part, so create an empty
 # file (filled with \377 = 0xff) and copy the CBFS image over it.
 	dd if=/dev/zero bs=$(call _toint,$(CONFIG_ROM_SIZE)) count=1 2> /dev/null | tr '\000' '\377' > $@.tmp
 	dd if=$(obj)/coreboot.pre of=$@.tmp bs=8192 conv=notrunc 2> /dev/null
+ifneq ($(CONFIG_SEABIOS_PS2_TIMEOUT),)
+ifneq ($(CONFIG_SEABIOS_PS2_TIMEOUT),0)
+ifneq ($(CONFIG_UPDATE_IMAGE),y)
+	@printf "    SeaBIOS    Wait up to $(CONFIG_SEABIOS_PS2_TIMEOUT) ms for PS/2 keyboard controller initialization\n"
+	$(CBFSTOOL) $@.tmp add-int -i $(CONFIG_SEABIOS_PS2_TIMEOUT) -n etc/ps2-keyboard-spinup
+endif
+endif
+endif
+ifeq ($(CONFIG_SEABIOS_ADD_SERCON_PORT_FILE),y)
+	@printf "    SeaBIOS    Add sercon-port file\n"
+	$(CBFSTOOL) $@.tmp add-int -i $(CONFIG_SEABIOS_SERCON_PORT_ADDR) -n etc/sercon-port
+endif
+ifeq ($(CONFIG_SEABIOS_THREAD_OPTIONROMS),y)
+	@printf "    SeaBIOS    Thread optionroms\n"
+	$(CBFSTOOL) $@.tmp add-int -i 2 -n etc/threads
+endif
 ifeq ($(CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE),y)
 ifneq ($(CONFIG_UPDATE_IMAGE),y) # never update the bootblock
 ifeq ($(CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER),y)

configs/config.asrock_b85m_pro4.debug_smmstore_hotplug_gcov_ubsan_em100

@@ -1,49 +0,0 @@
-# Not meant for actual use, but rather to build-test individual options.
-# If keeping this combination of options buildable becomes too hard in
-# the future, then this config can be split into several smaller chunks.
-# Exercises, among other things:
-# + Code coverage
-# + UBSAN
-# + Debug options
-# + SMMSTORE
-# + Silicon Image SIL3114 driver
-# + Genesys Logic GL9763E driver
-# + EM100 support
-# + SMM module loader V2
-CONFIG_COVERAGE=y
-CONFIG_UBSAN=y
-CONFIG_VENDOR_ASROCK=y
-CONFIG_ONBOARD_VGA_IS_PRIMARY=y
-CONFIG_CBFS_SIZE=0x200000
-CONFIG_BOARD_ASROCK_B85M_PRO4=y
-CONFIG_PCIEXP_L1_SUB_STATE=y
-CONFIG_PCIEXP_CLK_PM=y
-CONFIG_CONSOLE_POST=y
-# CONFIG_INTEL_CHIPSET_LOCKDOWN is not set
-# CONFIG_FINALIZE_USB_ROUTE_XHCI is not set
-CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y
-CONFIG_PCIEXP_HOTPLUG=y
-CONFIG_SMMSTORE=y
-CONFIG_SMMSTORE_SIZE=0x30000
-CONFIG_SPI_FLASH_NO_FAST_READ=y
-CONFIG_USBDEBUG=y
-CONFIG_USBDEBUG_DONGLE_FTDI_FT232H=y
-CONFIG_DRIVERS_SIL_3114=y
-CONFIG_DRIVERS_GENESYSLOGIC_GL9763E=y
-# CONFIG_SQUELCH_EARLY_SMP is not set
-CONFIG_CONSOLE_SPI_FLASH=y
-CONFIG_POST_DEVICE_PCI_PCIE=y
-CONFIG_FATAL_ASSERTS=y
-CONFIG_DEBUG_CBFS=y
-CONFIG_DEBUG_SMBUS=y
-CONFIG_DEBUG_SMI=y
-CONFIG_DEBUG_PERIODIC_SMI=y
-CONFIG_DEBUG_MALLOC=y
-CONFIG_DEBUG_CONSOLE_INIT=y
-CONFIG_DEBUG_SPI_FLASH=y
-CONFIG_DEBUG_COVERAGE=y
-CONFIG_DEBUG_BOOT_STATE=y
-CONFIG_DEBUG_ADA_CODE=y
-CONFIG_HAVE_EM100_SUPPORT=y
-CONFIG_X86_SMM_LOADER_VERSION2=y
-CONFIG_EM100=y

configs/config.asrock_b85m_pro4.tpm2_txt_placeholder_acms

@@ -1,10 +0,0 @@
-# Known-working configuration to boot with TXT enabled. Since BIOS
-# and SINIT ACM blobs are missing, use something else as placeholder.
-# Used ACMs were extracted from a Supermicro X10SLH firmware update.
-CONFIG_VENDOR_ASROCK=y
-CONFIG_BOARD_ASROCK_B85M_PRO4=y
-CONFIG_USER_TPM2=y
-CONFIG_INTEL_TXT=y
-CONFIG_INTEL_TXT_BIOSACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin"
-CONFIG_INTEL_TXT_SINITACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin"
-CONFIG_INTEL_TXT_LOGGING=y

configs/config.emulation_qemu_x86_i440fx_debug

@@ -4,5 +4,6 @@ CONFIG_FATAL_ASSERTS=y
 CONFIG_DEBUG_CBFS=y
 CONFIG_DEBUG_PIRQ=y
 CONFIG_DEBUG_MALLOC=y
+CONFIG_TRACE=y
 CONFIG_DEBUG_BOOT_STATE=y
 CONFIG_DEBUG_ADA_CODE=y

configs/config.emulation_qemu_x86_i440fx_x86_64

@@ -1 +0,0 @@
-CONFIG_CPU_QEMU_X86_64=y

configs/config.portwell_m107.debug_smmstore_oxpcie_em100spi

@@ -1,41 +0,0 @@
-# Not meant for actual use, but rather to build-test individual options.
-# If keeping this combination of options buildable becomes too hard in
-# the future, then this config can be split into several smaller chunks.
-# Exercises, among other things:
-# + SMMSTORE
-# + OXPCIE support
-# + FSP MP init
-# + EM100Pro SPI console
-# + Debug options
-CONFIG_VENDOR_PORTWELL=y
-CONFIG_CONSOLE_POST=y
-# CONFIG_CONSOLE_SERIAL is not set
-CONFIG_ENABLE_BUILTIN_COM1=y
-CONFIG_ONBOARD_MEM_KINGSTON=y
-CONFIG_USE_INTEL_FSP_MP_INIT=y
-CONFIG_SOC_INTEL_COMMON_BLOCK_SMM_TCO_ENABLE=y
-CONFIG_SOC_INTEL_DEBUG_CONSENT=y
-CONFIG_PCIEXP_HOTPLUG=y
-CONFIG_PCIEXP_HOTPLUG_PREFETCH_MEM_BELOW_4G=y
-CONFIG_SOFTWARE_I2C=y
-CONFIG_SMMSTORE=y
-CONFIG_SPI_FLASH_NO_FAST_READ=y
-CONFIG_DRIVERS_UART_OXPCIE=y
-CONFIG_DRIVERS_GENESYSLOGIC_GL9755=y
-CONFIG_DISPLAY_HOBS=y
-CONFIG_DISPLAY_VBT=y
-CONFIG_DISPLAY_FSP_ENTRY_POINTS=y
-CONFIG_DISPLAY_UPD_DATA=y
-CONFIG_EM100PRO_SPI_CONSOLE=y
-CONFIG_DISPLAY_MTRRS=y
-CONFIG_GDB_STUB=y
-CONFIG_GDB_WAIT=y
-CONFIG_FATAL_ASSERTS=y
-CONFIG_DEBUG_CBFS=y
-CONFIG_DEBUG_SMBUS=y
-CONFIG_DEBUG_SMI=y
-CONFIG_DEBUG_PERIODIC_SMI=y
-CONFIG_DEBUG_MALLOC=y
-CONFIG_DEBUG_CONSOLE_INIT=y
-CONFIG_REALMODE_DEBUG=y
-CONFIG_DEBUG_BOOT_STATE=y

configs/config.purism_librem15_v4.txt_build_test

@@ -1,8 +0,0 @@
-# Not meant for actual use. Exercises Intel TXT code. Since BIOS
-# and SINIT ACM blobs are missing, use something else as placeholder.
-CONFIG_VENDOR_PURISM=y
-CONFIG_BOARD_PURISM_LIBREM15_V4=y
-CONFIG_INTEL_TXT=y
-CONFIG_INTEL_TXT_BIOSACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin"
-CONFIG_INTEL_TXT_SINITACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin"
-CONFIG_INTEL_TXT_LOGGING=y

configs/config.scaleway_tagada

@@ -1,15 +0,0 @@
-CONFIG_VENDOR_SCALEWAY=y
-CONFIG_BOARD_SCALEWAY_TAGADA=y
-CONFIG_CBFS_SIZE=0x400000
-CONFIG_CONSOLE_POST=y
-# CONFIG_DRIVERS_INTEL_WIFI is not set
-# CONFIG_IQAT_ENABLE is not set
-CONFIG_LEGACY_UART_MODE=y
-CONFIG_USE_DENVERTON_NS_FSP_CAR=y
-CONFIG_SPI_FLASH_NO_FAST_READ=y
-CONFIG_PAYLOAD_ELF=y
-CONFIG_PAYLOAD_FILE="UEFIPAYLOAD.fd"
-CONFIG_DISPLAY_FSP_CALLS_AND_STATUS=y
-CONFIG_DISPLAY_FSP_HEADER=y
-CONFIG_DEBUG_CBFS=y
-CONFIG_DEBUG_BOOT_STATE=y

payloads/Kconfig

@@ -30,7 +30,7 @@ config PAYLOAD_ELF
 
 config PAYLOAD_FIT
 	bool "A FIT payload"
-	depends on ARCH_ARM64 || ARCH_RISCV || ARCH_ARM
+	depends on ARCH_ARM64 || ARCH_RISCV
 	select PAYLOAD_FIT_SUPPORT
 	help
 	  Select this option if you have a payload image (a FIT file) which
@@ -97,7 +97,7 @@ config PAYLOAD_FIT_SUPPORT
 	bool "FIT support"
 	default n
 	default y if PAYLOAD_LINUX && (ARCH_ARM || ARCH_ARM64 || ARCH_RISCV)
-	depends on ARCH_ARM64 || ARCH_RISCV || ARCH_ARM
+	depends on ARCH_ARM64 || ARCH_RISCV
 	select FLATTENED_DEVICE_TREE
 	help
 	  Select this option if your payload is of type FIT.

payloads/coreinfo/.gitignore

@@ -1,2 +0,0 @@
-lpbuild/
-lp.config*

payloads/coreinfo/AUTHORS

@@ -1,14 +0,0 @@
-# This is the list of coreinfo authors for copyright purposes.
-#
-# This does not necessarily list everyone who has contributed code, since in
-# some cases, their employer may be the copyright holder.  To see the full list
-# of contributors, and their email addresses, see the revision history in source
-# control.
-# Run the below commands in the coreinfo repo for additional information.
-# To see a list of contributors: git log --pretty=format:%an | sort | uniq
-# For patches adding or removing a name: git log -i -S "NAME" --source --all
-
-Advanced Micro Devices, Inc.
-Dave Jones
-Jordan Crouse
-Uwe Hermann

payloads/coreinfo/Kconfig

@@ -1,3 +1,7 @@
+##
+##
+## Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
+##
 ## SPDX-License-Identifier: GPL-2.0-only
 
 # For a description of the syntax of this configuration file,
@@ -42,15 +46,6 @@ config PAYLOAD_INFO_VERSION
 	help
 	  The version number of this payload.
 
-config LTO
-	bool "Use link time optimization (LTO)"
-	default n
-	help
-	  Compile with link time optimization. This can often decrease the
-	  final binary size, but may increase compilation time. This option
-	  is most effective when LTO is also enabled in libpayload, which
-	  is done separately.
-
 endmenu
 
 menu "Modules"

payloads/coreinfo/Makefile

@@ -1,3 +1,8 @@
+##
+##
+## Copyright (C) 2008 Advanced Micro Devices, Inc.
+## Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
+##
 ## SPDX-License-Identifier: GPL-2.0-only
 
 src := $(CURDIR)
@@ -76,13 +81,9 @@ ifneq ($(strip $(HAVE_DOTCONFIG)),)
 include $(src)/.config
 real-all: $(TARGET)
 
-ifeq ($(CONFIG_LTO),y)
-CFLAGS += -flto
-endif
-
 $(TARGET): $(src)/.config $(coreinfo_obj)/config.h $(OBJS) libpayload
 	printf "    LPCC       $(subst $(CURDIR)/,,$(@)) (LINK)\n"
-	$(LPCC) $(CFLAGS) -o $@ $(OBJS)
+	$(LPCC) -o $@ $(OBJS)
 	$(OBJCOPY) --only-keep-debug $@ $(TARGET).debug
 	$(OBJCOPY) --strip-debug $@
 	$(OBJCOPY) --add-gnu-debuglink=$(TARGET).debug $@
@@ -127,9 +128,10 @@ include $(srck)/Makefile
 else
 
 clean:
-	rm -rf build lpbuild .xcompile
+	rm -rf build/*.elf build/*.o .xcompile
 
 distclean: clean
+	rm -rf build lpbuild
 	rm -f .config* lp.config*
 
 .PHONY: clean distclean

payloads/coreinfo/bootlog_module.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 
@@ -7,12 +19,14 @@
 #define LINES_SHOWN 19
 #define TAB_WIDTH 2
 
+
 /* Globals that are used for tracking screen state */
 static char *g_buf = NULL;
 static s32 g_line = 0;
 static s32 g_lines_count = 0;
 static s32 g_max_cursor_line = 0;
 
+
 /* Copied from libpayload/drivers/cbmem_console.c */
 struct cbmem_console {
 	u32 size;
@@ -23,6 +37,7 @@ struct cbmem_console {
 #define CURSOR_MASK ((1 << 28) - 1)
 #define OVERFLOW (1 << 31)
 
+
 static u32 char_width(char c, u32 cursor, u32 screen_width)
 {
 	if (c == '\n') {
@@ -95,7 +110,7 @@ static int bootlog_module_init(void)
 		return -1;
 	}
 
-	struct cbmem_console *console = phys_to_virt(lib_sysinfo.cbmem_cons);
+	struct cbmem_console *console = lib_sysinfo.cbmem_cons;
 	if (console == NULL) {
 		return -1;
 	}

payloads/coreinfo/cbfs_module.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2009 Uwe Hermann <uwe@hermann-uwe.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 #include "endian.h"

payloads/coreinfo/coreboot_module.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 #include <coreboot_tables.h>

payloads/coreinfo/coreinfo.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 

payloads/coreinfo/coreinfo.h

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #ifndef COREINFO_H_
 #define COREINFO_H_

payloads/coreinfo/cpuid.S

@@ -1,6 +1,18 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-/* It is derived from the x86info project, which is GPLv2-licensed. */
+/*
+ *
+ * It is derived from the x86info project, which is GPLv2-licensed.
+ *
+ * Copyright (C) 2001-2007 Dave Jones <davej@codemonkey.org.uk>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 /* calling syntax:  docpuid(idx,eax,ebx,ecx,edx) */
 

payloads/coreinfo/cpuinfo_module.c

@@ -1,6 +1,19 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
-
-/* It is derived from the x86info project, which is GPLv2-licensed. */
+/*
+ *
+ * It is derived from the x86info project, which is GPLv2-licensed.
+ *
+ * Copyright (C) 2001-2007 Dave Jones <davej@codemonkey.org.uk>
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 

payloads/coreinfo/multiboot_module.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Jordan Crouse <jordan@cosmicpenguin.net>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include <multiboot_tables.h>
 #include "coreinfo.h"

payloads/coreinfo/nvram_module.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 

payloads/coreinfo/pci_module.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Advanced Micro Devices, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include <arch/io.h>
 #include <pci.h>
@@ -151,7 +163,7 @@ static int pci_module_redraw(WINDOW *win)
 	return 0;
 }
 
-static void ci_pci_scan_bus(int bus)
+static void pci_scan_bus(int bus)
 {
 	int slot, func;
 	unsigned int val;
@@ -196,7 +208,7 @@ static void ci_pci_scan_bus(int bus)
 
 				busses = pci_read_config32(dev, REG_PRIMARY_BUS);
 
-				ci_pci_scan_bus((busses >> 8) & 0xff);
+				pci_scan_bus((busses >> 8) & 0xff);
 
 			}
 		}
@@ -240,7 +252,7 @@ static int pci_module_handle(int key)
 
 static int pci_module_init(void)
 {
-	ci_pci_scan_bus(0);
+	pci_scan_bus(0);
 	return 0;
 }
 

payloads/coreinfo/ramdump_module.c

@@ -1,4 +1,16 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 

payloads/coreinfo/timestamps_module.c

@@ -1,4 +1,14 @@
-/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
 
 #include "coreinfo.h"
 #include <commonlib/timestamp_serialized.h>
@@ -137,7 +147,7 @@ static int timestamps_module_init(void)
 	if (ret)
 		return -1;
 
-	struct timestamp_table *timestamps = phys_to_virt(lib_sysinfo.tstamp_table);
+	struct timestamp_table *timestamps = lib_sysinfo.tstamp_table;
 
 	if (timestamps == NULL)
 		return -1;

payloads/external/.gitignore

@@ -1,10 +0,0 @@
-depthcharge/depthcharge/
-FILO/filo/
-GRUB2/grub2/
-LinuxBoot/linuxboot/
-SeaBIOS/seabios/
-tianocore/tianocore/
-tint/tint/
-U-Boot/u-boot/
-Memtest86Plus/memtest86plus/
-iPXE/ipxe/

payloads/external/BOOTBOOT/Kconfig

@@ -1,6 +0,0 @@
-if PAYLOAD_BOOTBOOT
-
-config PAYLOAD_FILE
-	default "payloads/external/BOOTBOOT/bootboot/dist/bootbootcb.elf"
-
-endif

payloads/external/BOOTBOOT/Kconfig.name

@@ -1,8 +0,0 @@
-config PAYLOAD_BOOTBOOT
-	bool "BOOTBOOT"
-	depends on ARCH_X86 || ARCH_ARM64
-	help
-	  Select this option if you want to build a coreboot image
-	  with a BOOTBOOT Protocol payload.
-
-	  See https://gitlab.com/bztsrc/bootboot for more information.

payloads/external/BOOTBOOT/Makefile

@@ -1,44 +0,0 @@
-project_git_repo=https://gitlab.com/bztsrc/bootboot.git
-project_dir=bootboot
-ifeq ($(CONFIG_COREBOOT_BUILD),)
-include ../../../.config
-endif
-ifeq ($(CONFIG_ARCH_ARM64),y)
-loader_dir=$(project_dir)/aarch64-cb
-else
-loader_dir=$(project_dir)/x86_64-cb
-endif
-
-unexport KCONFIG_AUTOHEADER
-unexport KCONFIG_AUTOCONFIG
-unexport KCONFIG_DEPENDENCIES
-unexport KCONFIG_SPLITCONFIG
-unexport KCONFIG_TRISTATE
-unexport KCONFIG_NEGATIVES
-
-all: bootboot
-
-checkout:
-	echo "    GIT        BOOTBOOT $(loader_dir)"
-	test -L $(project_dir) || test -d $(project_dir) || \
-		git clone $(project_git_repo) $(project_dir)
-
-bootboot: libpayload
-	echo "    MAKE       $(loader_dir)"
-	$(MAKE) -C $(loader_dir) LIBCONFIG_PATH=../../../libpayload
-
-libpayload: checkout
-	cp $(loader_dir)/lib.config ../../libpayload/.config
-	cd ../../libpayload && $(MAKE) oldconfig && \
-		$(MAKE) && $(MAKE) DESTDIR=../external/BOOTBOOT/$(loader_dir) install
-
-clean:
-	test -d $(loader_dir) && $(MAKE) -C $(loader_dir) clean || exit 0
-
-distclean:
-	rm -rf $(project_dir)
-
-print-repo-info:
-	echo "$(project_git_repo) $(project_dir)"
-
-.PHONY: checkout bootboot libpayload clean distclean print-repo-info

payloads/external/FILO/Kconfig

@@ -5,9 +5,9 @@ choice
 	default FILO_STABLE
 
 config FILO_STABLE
-	bool "tested"
+	bool "0.6.0"
 	help
-	  Tested FILO version
+	  Stable FILO version
 
 config FILO_MASTER
 	bool "HEAD"

payloads/external/FILO/Makefile

@@ -1,6 +1,6 @@
 TAG-$(CONFIG_FILO_MASTER)=origin/master
 NAME-$(CONFIG_FILO_MASTER)=MASTER
-TAG-$(CONFIG_FILO_STABLE)=c2fa1ea6125c63e84cdf7779c37d76da8c5bc412
+TAG-$(CONFIG_FILO_STABLE)=22baa6bde9339029edfafa421b3d4a7be159edad
 NAME-$(CONFIG_FILO_STABLE)=STABLE
 
 project_git_repo=https://review.coreboot.org/filo.git

payloads/external/LinuxBoot/Kconfig

@@ -135,6 +135,7 @@ config LINUXBOOT_KERNEL_UIMAGE
 
 endchoice
 
+
 config LINUXBOOT_DTB_FILE
 	string "Compiled devicetree file"
 	depends on LINUXBOOT_ARM64 || LINUXBOOT_RISCV

payloads/external/Makefile.inc

@@ -106,31 +106,6 @@ bootorder-file := $(strip $(CONFIG_SEABIOS_BOOTORDER_FILE))
 bootorder-type := raw
 endif
 
-ifneq ($(CONFIG_SEABIOS_PS2_TIMEOUT),)
-ifneq ($(CONFIG_SEABIOS_PS2_TIMEOUT),0)
-ifneq ($(CONFIG_UPDATE_IMAGE),y)
-INTERMEDIATE+=seabios_ps2_timeout
-seabios_ps2_timeout: $(obj)/coreboot.pre $(CBFSTOOL)
-	@printf "    SeaBIOS    Wait up to $(CONFIG_SEABIOS_PS2_TIMEOUT) ms for PS/2 keyboard controller initialization\n"
-	$(CBFSTOOL) $< add-int -i $(CONFIG_SEABIOS_PS2_TIMEOUT) -n etc/ps2-keyboard-spinup
-endif
-endif
-endif
-
-ifeq ($(CONFIG_SEABIOS_ADD_SERCON_PORT_FILE),y)
-INTERMEDIATE+=seabios_sercon
-seabios_sercon: $(obj)/coreboot.pre $(CBFSTOOL)
-	@printf "    SeaBIOS    Add sercon-port file\n"
-#	$(CBFSTOOL) $@.tmp add-int -i $(CONFIG_SEABIOS_SERCON_PORT_ADDR) -n etc/sercon-port
-endif
-
-ifeq ($(CONFIG_SEABIOS_THREAD_OPTIONROMS),y)
-INTERMEDIATE+=seabios_thread_optionroms
-seabios_thread_optionroms: $(obj)/coreboot.pre $(CBFSTOOL)
-	@printf "    SeaBIOS    Thread optionroms\n"
-	$(CBFSTOOL) $@.tmp add-int -i 2 -n etc/threads
-endif
-
 # Depthcharge
 
 payloads/external/depthcharge/depthcharge/build/depthcharge.elf depthcharge: $(DOTCONFIG) $(CBFSTOOL)
@@ -328,8 +303,3 @@ payloads/external/Yabits/uefi/build/uefi.elf yabits:
 		CONFIG_YABITS_MASTER=$(CONFIG_YABITS_MASTER) \
 		CONFIG_YABITS_STABLE=$(CONFIG_YABITS_STABLE) \
 		MFLAGS= MAKEFLAGS=
-
-# BOOTBOOT
-
-payloads/external/BOOTBOOT/bootboot/dist/bootbootcb.elf:
-	$(MAKE) -C payloads/external/BOOTBOOT all

payloads/external/SeaBIOS/Kconfig

@@ -5,7 +5,7 @@ choice
 	default SEABIOS_STABLE
 
 config SEABIOS_STABLE
-	bool "1.14.0"
+	bool "1.13.0"
 	help
 	  Stable SeaBIOS version
 config SEABIOS_MASTER

payloads/external/SeaBIOS/Makefile

@@ -1,5 +1,5 @@
 TAG-$(CONFIG_SEABIOS_MASTER)=origin/master
-TAG-$(CONFIG_SEABIOS_STABLE)=155821a1990b6de78dde5f98fa5ab90e802021e0
+TAG-$(CONFIG_SEABIOS_STABLE)=f21b5a4aeb020f2a5e2c6503f906a9349dd2f069
 TAG-$(CONFIG_SEABIOS_REVISION)=$(CONFIG_SEABIOS_REVISION_ID)
 
 project_git_repo=https://review.coreboot.org/seabios.git

payloads/external/tint/Makefile

@@ -18,9 +18,9 @@ patch: download
 	cd tint; \
 	if [ -e debian ]; then \
 		rm -rf debian typedefs.h Makefile; \
-		touch Makefile; \
-		patch -l -p1 < ../libpayload_tint.patch; \
-	fi
+    		touch Makefile; \
+    		patch -l -p1 < ../libpayload_tint.patch; \
+  	fi
 
 download:
 	test -d tint || { wget $(project_url); \

payloads/libpayload/.gitignore

@@ -1 +0,0 @@
-install/

payloads/libpayload/Kconfig

@@ -79,14 +79,6 @@ config COMPILER_LLVM_CLANG
 
 endchoice
 
-config LTO
-	bool "Use link time optimization (LTO)"
-	default n
-	depends on COMPILER_GCC
-	help
-	  Compile with link time optimization. This can often decrease the
-	  final binary size, but may increase compilation time.
-
 config REMOTEGDB
 	bool "Remote GDB stub"
 	default n

payloads/libpayload/Makefile.inc

@@ -55,8 +55,7 @@ subdirs-$(CONFIG_LP_CBFS) += libcbfs
 subdirs-$(CONFIG_LP_LZMA) += liblzma
 subdirs-$(CONFIG_LP_LZ4) += liblz4
 
-INCLUDES := -Iinclude -Iinclude/$(ARCHDIR-y) -I$(obj)
-INCLUDES += -include include/kconfig.h -include include/compiler.h
+INCLUDES := -Iinclude -Iinclude/$(ARCHDIR-y) -I$(obj) -include include/kconfig.h
 
 CFLAGS +=  $(EXTRA_CFLAGS) $(INCLUDES) -Os -pipe -nostdinc -ggdb3
 CFLAGS += -nostdlib -fno-builtin -ffreestanding -fomit-frame-pointer
@@ -65,10 +64,6 @@ CFLAGS += -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes -Wvla
 CFLAGS += -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough
 CFLAGS += -Wstrict-aliasing -Wshadow -Werror
 
-ifeq ($(CONFIG_LP_LTO),y)
-CFLAGS += -flto
-endif
-
 $(obj)/libpayload-config.h: $(KCONFIG_AUTOHEADER)
 	cmp $@ $< 2>/dev/null || cp $< $@
 

payloads/libpayload/arch/arm/cpu.S

@@ -81,7 +81,7 @@
 	lsl	ip, ip, r2		@ shift by that into way position
 	mov	r0, #1
 	lsl	r2, r0, r2		@ r2 now contains the way decr
-	mov	r0, r3			@ get sets/level (no way yet)
+	mov	r0, r3 			@ get sets/level (no way yet)
 	orr	r3, r3, ip		@ merge way into way/set/level
 	bfc	r0, #0, #4		@ clear low 4 bits (level) to get numset - 1
 	sub	r2, r2, r0		@ subtract from way decr

payloads/libpayload/arch/arm64/mmu.c

@@ -625,10 +625,14 @@ static void mmu_extract_ranges(struct memrange *cb_ranges,
 static void mmu_add_fb_range(struct mmu_ranges *mmu_ranges)
 {
 	struct mmu_memrange *fb_range;
-	struct cb_framebuffer *framebuffer = &lib_sysinfo.framebuffer;
+	static struct cb_framebuffer modified_fb;
+	struct cb_framebuffer *framebuffer = lib_sysinfo.framebuffer;
 	uint32_t fb_size;
 
 	/* Check whether framebuffer is needed */
+	if (framebuffer == NULL)
+		return;
+
 	fb_size = framebuffer->bytes_per_line * framebuffer->y_resolution;
 	if (!fb_size)
 		return;
@@ -648,7 +652,16 @@ static void mmu_add_fb_range(struct mmu_ranges *mmu_ranges)
 	if (fb_range == NULL)
 		mmu_error();
 
-	framebuffer->physical_address = fb_range->base;
+	/*
+	 * Set framebuffer address. However, one needs to use a freshly
+	 * allocated framebuffer structure because the one in the coreboot
+	 * table is part of a checksum calculation. Therefore, one cannot
+	 * modify a field without recomputing the necessary checksum
+	 * calcuation.
+	 */
+	modified_fb = *framebuffer;
+	modified_fb.physical_address = fb_range->base;
+	lib_sysinfo.framebuffer = &modified_fb;
 }
 
 /*

payloads/libpayload/arch/arm64/virtual.c

@@ -30,6 +30,7 @@
 
 unsigned long virtual_offset = 0;
 
+
 int getpagesize(void)
 {
 	return 4096;