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
+coreboot-builds*/
-.dependencies
 
 # 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

@@ -51,10 +51,3 @@
 	url = https://review.coreboot.org/qc_blobs.git
 	update = none
 	ignore = dirty
-[submodule "3rdparty/intel-sec-tools"]
-	path = 3rdparty/intel-sec-tools
-	url = https://review.coreboot.org/9esec-security-tooling.git
-[submodule "3rdparty/stm"]
-	path = 3rdparty/stm
-	url = https://review.coreboot.org/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.
+At the moment there's no single board that supports x86_64 or to be exact
-The `emulation/qemu-i440fx` and `emulation/qemu-q35` boards do support
+`ARCH_RAMSTAGE_X86_64` and `ARCH_ROMSTAGE_X86_64`.
-*ARCH_RAMSTAGE_X86_64* , *ARCH_POSTCAR_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
+## Steps to add basic support for x86_64
-Basic support for x86_64 has been implemented for QEMU mainboard target.
+* Add x86_64 toolchain support - *DONE*
-
+* Fix compilation errors - *DONE*
-## Reference implementation
+* Fix linker errors - *TODO*
-The reference implementation is
+* Add x86_64 rmodule support - *DONE*
-* [QEMU i440fx](../../mainboard/emulation/qemu-i440fx.md)
+* Add x86_64 exception handlers - *DONE*
-* [QEMU Q35](../../mainboard/emulation/qemu-q35.md)
+* Setup page tables for long mode - *DONE*
-
+* Add assembly code for long mode - *DONE*
-## TODO
+* Add assembly code for SMM - *DONE*
-* Identity map memory above 4GiB in ramstage
+* Add assembly code for postcar stage - *TODO*
+* Add assembly code to return to protected mode - *TODO*
+* Implement reference code for mainboard `emulation/qemu-q35` - *TODO*
 
 ## Future work
 
@@ -65,33 +64,3 @@ The reference implementation is
 * Test how well CAR works with x86_64 and paging
 * Improve mode switches
 * Test libgfxinit / VGA Option ROMs / FSP
-
-## Known bugs on real hardware
-
-According to Intel x86_64 mode hasn't been validated in CAR environments.
-Until now it could be verified on various Intel platforms and no issues have
-been found.
-
-## Known bugs on KVM enabled qemu
-
-The `x86_64` reference code runs fine in qemu soft-cpu, but has serious issues
-when using KVM mode on some machines. The workaround is to *not* place
-page-tables in ROM, as done in
-[CB:49228](https://review.coreboot.org/c/coreboot/+/49228).
-
-Here's a list of known issues:
-
-* After entering long mode, the FPU doesn't work anymore, including accessing
-  MMX registers. It works fine before entering long mode. It works fine when
-  switching back to protected mode. Other registers, like SSE registers, are
-  working fine.
-* Reading from virtual memory, when the page tables are stored in ROM, causes
-  the MMU to abort the "page table walking" mechanism when the lower address
-  bits of the virtual address to be translated have a specific pattern.
-  Instead of loading the correct physical page, the one containing the
-  page tables in ROM will be loaded and used, which breaks code and data as
-  the page table doesn't contain the expected data. This in turn leads to
-  undefined behaviour whenever the 'wrong' address is being read.
-* Disabling paging in compability mode crashes the CPU.
-* Returning from long mode to compability mode crashes the CPU.
-* Entering long mode crashes on AMD host platforms.

Documentation/cbfstool/index.md

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

Documentation/cbfstool/mmap_windows.md

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

Documentation/community/language_style.md

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

Documentation/conf.py

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

Documentation/drivers/index.md

@@ -4,9 +4,6 @@ The drivers can be found in `src/drivers`. They are intended for onboard
 and plugin devices, significantly reducing integration complexity and
 they allow to easily reuse existing code accross platforms.
 
-* [Intel DPTF](dptf.md)
 * [IPMI KCS](ipmi_kcs.md)
 * [SMMSTORE](smmstore.md)
 * [SoundWire](soundwire.md)
-* [SMMSTOREv2](smmstorev2.md)
-* [USB4 Retimer](retimer.md)

Documentation/drivers/retimer.md

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

Documentation/drivers/smmstorev2.md

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

Documentation/getting_started/gerrit_guidelines.md

@@ -43,42 +43,15 @@ employer is aware and you are authorized to submit the code. For
 clarification, see the Developer's Certificate of Origin in the coreboot
 [Signed-off-by policy](https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure).
 
-* In general, patches should remain open for review for at least 24 hours
+* Let non-trivial patches sit in a review state for at least 24 hours
-since the last significant modification to the change. The purpose is to
+before submission. Remember that there are coreboot developers in timezones
-let coreboot developers around the world have a chance to review. Complex
+all over the world, and everyone should have a chance to contribute.
-reworks, even if they don't change the purpose of the patch but the way
+Trivial patches would be things like whitespace changes or spelling fixes,
-it's implemented, should restart the wait period.
+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
-* A change can go in without the wait period if its purpose is to fix
+update which significantly changes any part of the patch. Patches can be
-a recently-introduced issue (build, boot or OS-level compatibility, not
+'Fast-tracked' and submitted in under 24 hours with the agreement of at
-necessarily identified by coreboot.org facilities). Its commit message
+least 3 +2 votes.
-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.
 
 * 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;
+	uint32_t mask;
-	uint64_t value;
+	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

@@ -16,7 +16,6 @@ This section contains documentation about coreboot on specific mainboards.
 
 ## ASUS
 
-- [A88XM-E](asus/a88xm-e.md)
 - [F2A85-M](asus/f2a85-m.md)
 - [P5Q](asus/p5q.md)
 - [P8H61-M LX](asus/p8h61-m_lx.md)
@@ -27,10 +26,6 @@ This section contains documentation about coreboot on specific mainboards.
 
 - [CN81XX EVB SFF](cavium/cn8100_sff_evb.md)
 
-## Clevo
-
-- [N130WU / N131WU](clevo/n130wu/index.md)
-
 ## Dell
 
 - [OptiPlex 9010 SFF](dell/optiplex_9010.md)
@@ -42,8 +37,6 @@ The boards in this section are not real mainboards, but emulators.
 - [Spike RISC-V emulator](emulation/spike-riscv.md)
 - [Qemu RISC-V emulator](emulation/qemu-riscv.md)
 - [Qemu AArch64 emulator](emulation/qemu-aarch64.md)
-- [Qemu x86 Q35](emulation/qemu-q35.md)
-- [Qemu x86 PC](emulation/qemu-i440fx.md)
 
 ## Facebook
 
@@ -66,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
 
@@ -77,10 +67,6 @@ The boards in this section are not real mainboards, but emulators.
 - [IceLake RVP](intel/icelake_rvp.md)
 - [KBLRVP11](intel/kblrvp11.md)
 
-## Kontron
-
-- [mAL-10](kontron/mal10.md)
-
 ## Lenovo
 
 - [Mainboard codenames](lenovo/codenames.md)
@@ -90,15 +76,15 @@ The boards in this section are not real mainboards, but emulators.
 - [X2xx common](lenovo/x2xx_series.md)
 - [vboot](lenovo/vboot.md)
 
+### Arrandale series
+
+- [T410](lenovo/t410.md)
+
 ### GM45 series
 
 - [X200 / T400 / T500 / X301 common](lenovo/montevina_series.md)
 - [X301](lenovo/x301.md)
 
-### Arrandale series
-
-- [T410](lenovo/t410.md)
-
 ### Sandy Bridge series
 
 - [T420](lenovo/t420.md)
@@ -129,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
@@ -150,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)
@@ -177,10 +158,6 @@ The boards in this section are not real mainboards, but emulators.
 
 - [Lemur Pro](system76/lemp9.md)
 
-## Texas Instruments
-
-- [Beaglebone Black](ti/beaglebone-black.md)
-
 ## UP
 
 - [Squared](up/squared/index.md)

Documentation/mainboard/kontron/mal10.md

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

Documentation/mainboard/lenovo/montevina_series.md

@@ -9,15 +9,6 @@ the chip in your machine through flashrom:
 Note that this does not allow you to determine whether the chip is in a SOIC-8
 or a SOIC-16 package.
 
-## Installing with ME firmware
-
-To install coreboot and keep ME working, you don't need to do anything special
-with the flash descriptor. Only flash the `bios` region externally and don't
-touch any other regions:
-```console
-# flashrom -p YOUR_PROGRAMMER -w coreboot.rom --ifd -i bios
-```
-
 ## Installing without ME firmware
 
 ```eval_rst
@@ -98,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
 +-----------------+-------+-------+--------+
@@ -136,6 +127,15 @@ Chipset --->
 
 Then build coreboot and flash whole `build/coreboot.rom` to the chip.
 
+## Installing with ME firmware
+
+To install coreboot and keep ME working, you don't need to do anything special
+with the flash descriptor. Just flash only `bios` externally and don't touch any
+other regions:
+```console
+# flashrom -p YOUR_PROGRAMMER -w coreboot.rom --ifd -i bios
+```
+
 ## Flash layout
 
 The flash layouts of the OEM firmware are as follows:

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,33 +1,29 @@
 # 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
+Delta Lake server platform.
-build/test/release cycle.
 
 ## Introduction
 
 OCP Delta Lake server platform is a component of multi-host server system
 Yosemite-V3. Both were announced by Facebook and Intel in [OCP virtual summit 2020].
 
-Delta Lake server is a single socket Cooper Lake Scalable Processor (CPX-SP) server.
+Delta Lake server is a single socket Cooper Lake Scalable Processor server.
 
 Yosemite-V3 has multiple configurations. Depending on configurations, it may
 host up to 4 Delta Lake servers in one sled.
 
-The Yosemite-V3 program is in PVT phase. Facebook, Intel and partners
+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
+jointly develop FSP/coreboot/LinuxBoot stack on Delta Lake as an alternative solution.
-solution. This development reached EVT exit equivalent status.
 
 ## Required blobs
 
 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 CPX-SP.
+  (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: Ignition binary will be made public some time after the MP
+- ME binary: Not yet available to the public.
-  of CPX-SP.
-- ACM binaries: only required for CBnT enablement.
 
 ## Payload
 - LinuxBoot: This is necessary only if you use LinuxBoot as coreboot payload.
@@ -50,16 +46,6 @@ To power off/on the host:
 To connect to console through SOL (Serial Over Lan):
     sol-util slotx
 
-## Firmware configurations
-[ChromeOS VPD] is used to store most of the firmware configurations.
-RO_VPD region holds default values, while RW_VPD region holds customized
-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.
-
 ## Working features
 The solution is developed using LinuxBoot payload with Linux kernel 5.2.9, and [u-root]
 as initramfs.
@@ -69,81 +55,58 @@ 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 13 -- BIOS Language Information
     - Type 16 -- Physical Memory Array
-    - Type 17 -- Memory Device
     - Type 19 -- Memory Array Mapped Address
-    - Type 32 -- System Boot Information
-    - Type 38 -- IPMI Device Information
-    - Type 41 -- Onboard Devices Extended Information
     - Type 127 -- End-of-Table
+
 - BMC integration:
     - BMC readiness check
     - IPMI commands
     - watchdog timer
     - POST complete pin acknowledgement
-    - Check BMC version: ipmidump -device
 - SEL record generation
-- Converged Bootguard and TXT (CBnT)
-    - TPM
-    - Bootguard profile 0T
-    - TXT
-    - SRTM (verified through tboot)
-    - memory secret clearance upon ungraceful shutdown
 - 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
-- basic memory hardware error injection/detection (SMI handler not upstreamed)
-- basic PCIe hardware error injection/detection (SMI handler not upstreamed)
 
-## Stress/performance tests passed
+## Firmware configurations
-- OS warm reboot (1000 cycles)
+[ChromeOS VPD] is used to store most of the firmware configurations.
-- DC reboot (1000 cycles)
+RO_VPD region holds default values, while RW_VPD region holds customized
-- AC reboot (1000 cycle)
+values.
-- Mprime test (6 hours)
-- StressAppTest (6 hours)
-- Ptugen (6 hours)
 
-## Performance tests on par with traditional firmware
+VPD variables supported are:
-- coremark
+- firmware_version: This variable holds overall firmware version. coreboot
-- SpecCPU
+  uses that value to populate smbios type 1 version field.
-- Linkpack
-- Iperf(IPv6)
-- FIO
-
-## Other tests passed
-- Power
-- Thermal
 
 ## Known issues
-- MLC (Intel Memory Latency Check) and stream performance issue
+- Even though CPX-SP FSP is based on FSP 2.2 framework, it does not
-- HECI access at OS run time:
+  support FSP_USES_CB_STACK. An IPS ticket is filed with Intel.
-    - spsInfoLinux64 command fail to return ME version
+- VT-d is not supported. An IPS ticket is filed with Intel.
-    - ptugen command fail to get memory power
+- PCIe bifuration is not supported. An IPS ticket is filed with Intel.
+- ME based power capping. This is a bug in ME. An IPS ticket is filed
+  with Intel.
+- RO_VPD region as well as other RO regions are not write protected.
+- HECI is not set up correctly, so BMC is not able to get PCH and DIMM
+  temperature sensor readings.
 
 ## Feature gaps
-- flashrom command not able to update ME region
+- Delta Lake DVT is not supported, as we only have Delta Lake EVT servers
-- ACPI APEI tables
+  at the moment.
-- PCIe hotplug, Virtual Pin Ports
+- SMBIOS:
-- PCIe Live Error Recovery
+    - Type 7 -- Cache Information
-- RO_VPD region as well as other RO regions are not write protected
+    - Type 17 -- Memory Device
-- Not able to selectively enable/disable core
+    - Type 38 -- IPMI Device Information
+    - Type 41 -- Onboard Devices Extended Information
+- ACPI:
+    - DMAR
+- PFR/CBnT
 
 ## Technology
 
@@ -153,7 +116,7 @@ as initramfs.
 +------------------------+---------------------------------------------+
 | 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/x11-lga1151-series.md

@@ -7,7 +7,6 @@ Controller etc.
 ## Supported boards
 
 - [X11SSH-TF](x11ssh-tf/x11ssh-tf.md)
-- [X11SSH-F](x11ssh-f/x11ssh-f.md)
 - [X11SSM-F](x11ssm-f/x11ssm-f.md)
 
 ## Required proprietary blobs
@@ -31,12 +30,14 @@ Look at the [flashing tutorial] and the board-specific section.
 
 These issues apply to all boards. Have a look at the board-specific issues, too.
 
+- TianoCore doesn't work with Aspeed NGI, as it's text mode only (Fix is WIP CB:35726)
 - MRC caching does not work on cold boot with Intel SPS (see [Intel FSP2.0])
 
 ## ToDo
 
 - Fix issues above
 - Fix issues in board specific sections
+- Fix TODOs mentioned in code
 - Add more boards! :-)
 
 ## Technology

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

@@ -1,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/mainboard/supermicro/x11-lga1151-series/x11ssh-tf/x11ssh-tf.md

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

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

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

Documentation/mainboard/ti/beaglebone-black.md

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

Documentation/releases/checklist.md

@@ -75,8 +75,7 @@ be more frequent than was needed, so we scaled it back to twice a year.
 - [ ] Test the release from the actual release tarballs.
 - [ ] Push signed Tag to repo.
 - [ ] Announce that the release tag is done on IRC.
-- [ ] Upload release files to web server.
+- [ ] Upload release files to web server
-- [ ] Also extract the release notes and place them on the web server.
 - [ ] Upload crossgcc sources to web server.
 - [ ] Update download page to point to files, push to repo.
 - [ ] Write and publish blog post with release notes.
@@ -198,16 +197,16 @@ the coreboot server, and put them in the release directory at
 ````
 
 People can now see the release tarballs on the website at
-<https://www.coreboot.org/releases/>
+https://www.coreboot.org/releases/
 
-The downloads page is the official place to download the releases from, and it needs to be updated with links to the new release tarballs and .sig files. It can be found at <https://review.coreboot.org/cgit/homepage.git/tree/downloads.html>
+The downloads page is the official place to download the releases from, and it needs to be updated with links to the new release tarballs and .sig files. It can be found at https://review.coreboot.org/cgit/homepage.git/tree/downloads.html
 
-Here is an example commit to change it: <https://review.coreboot.org/c/homepage/+/19515>
+Here is an example commit to change it: https://review.coreboot.org/#/c/19515/
 
 ## Upload crossgcc sources
 Sometimes the source files for older revisions of
 crossgcc disappear. To deal with that we maintain a mirror at
-<https://www.coreboot.org/releases/crossgcc-sources/> where we host the
+https://www.coreboot.org/releases/crossgcc-sources/ where we host the
 sources used by the crossgcc scripts that are part of coreboot releases.
 
 Run
@@ -221,7 +220,7 @@ sources. Download them yourself and copy them into the crossgcc-sources
 directory on the server.
 
 ## After the release is complete
-Post the release notes on <https://blogs.coreboot.org>
+Post the release notes on https://blogs.coreboot.org
 
 ## Making a branch
 At times we will need to create a branch, generally for patch fixes.

Documentation/releases/coreboot-4.13-relnotes.md

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

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
+- Sushi
-- Dooly
-- Ambassador
-- Genesis
 - 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))
+- Nautilus
-- Nocturne (Google Pixel Slate)
+- Nocturne
-- Rammus (Asus Chromebook C425, Flip C433, Flip C434)
+- Rammus
-- Soraka (HP Chromebook x2)
+- 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
+GPIOs to use for selecting which SPD to load.
-specified in `APCB_SOURCES`.
+
+### Prebuilt
+The picasso `Makefile` expects APCBs to be located in
+`3rdparty/blobs/mainboard/$(MAINBOARDDIR)`. If you have a pre-built binary just
+add the following to your mainboard's Makefile.
+
+```
+# i.e., 3rdparty/blobs/mainboard/amd/mandolin/APCB_mandolin.bin
+APCB_SOURCES = mandolin
+```
 
 ### Generating APCBs
 If you have a template APCB file, the `apcb_edit` tool can be used to inject the
-SPD and GPIOs used to select the correct slot.
+SPD and GPIOs used to select the correct slot.  Entries should match this
+pattern `{NAME}_x{1,2}`. There should be a matching SPD hex file in
+`SPD_SOURCES_DIR` matching the pattern `{NAME}.spd.hex`.
+The `_x{1,2}` suffix denotes single or dual channel. Up to 16 slots can be used.
+If a slot is empty, the special empty keyword can be used. This will generate
+an APCB with an empty SPD.
+
+```
+APCB_SOURCES =  hynix-HMA851S6CJR6N-VK_x1   # 0b0000
+APCB_SOURCES += hynix-HMAA1GS6CMR6N-VK_x2   # 0b0001
+APCB_SOURCES += empty                       # 0b0010
+APCB_SOURCES += samsung-K4A8G165WC-BCWE_x1  # 0b0011
+```
+
+#### APCB Board ID GPIO configuration.
+The GPIOs determine which memory SPD will be used during boot.
+```
+# APCB_BOARD_ID_GPIO[0-3] = GPIO_NUMBER GPIO_IO_MUX GPIO_BANK_CTL
+# GPIO_NUMBER: FCH GPIO number
+# GPIO_IO_MUX: Value write to IOMUX to configure this GPIO
+# GPIO_BANK_CTL: Value write to GPIOBankCtl[23:16] to configure this GPIO
+
+APCB_BOARD_ID_GPIO0 = 121 1 0
+APCB_BOARD_ID_GPIO1 = 120 1 0
+APCB_BOARD_ID_GPIO2 = 131 3 0
+APCB_BOARD_ID_GPIO3 = 116 1 0
+```
 
 ## Footnotes
 

Documentation/soc/intel/cse_fw_update/Layout_after.svg

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

Documentation/soc/intel/cse_fw_update/Layout_before.svg

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

Documentation/soc/intel/cse_fw_update/cse_fw_update.md

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

Documentation/soc/intel/icelake/iceLake_coreboot_development.md

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

Documentation/soc/intel/index.md

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

Documentation/soc/intel/microcode.md

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

Documentation/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
+Please note that this can take a significant amount of time.
-specify number of `make` jobs to run in parallel.
 
-This will list toolchain options and supported architectures:
+    $ make crossgcc-i386 CPUS=$(nproc)
-
-    $ 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.
 
 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

Documentation/util.md

@@ -20,7 +20,7 @@ status repository `Bash` `Go`
 * __cavium__ - Devicetree_convert Tool to convert a DTB to a static C
 file `Python`
 * __cbfstool__
-	* [_cbfstool_](cbfstool/index.md) - For manipulating CBFS file `C`
+	* _cbfstool_ - For manipulating CBFS file `C`
 	* _fmaptool_ - Converts plaintext fmd files into fmap blobs `C`
 	* _rmodtool_ - Creates rmodules `C`
 	* _ifwitool_ - For manipulating IFWI `C`

MAINTAINERS

@@ -137,14 +137,6 @@ Maintainers List (try to look for most precise areas first)
 # Mainboards
 ################################################################################
 
-AMD family 17h and 19h reference boards
-M:	Marshall Dawson <marshalldawson3rd@gmail.com>
-M:	Felix Held <felix-coreboot@felixheld.de>
-M:	Jason Glenesk <jason.glenesk@gmail.com>
-S:	Maintained
-F:	src/mainboard/amd/majolica/
-F:	src/mainboard/amd/mandolin/
-
 APPLE MAINBOARDS
 M:	Evgeny Zinoviev <me@ch1p.io>
 S:	Maintained
@@ -216,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>
@@ -241,19 +225,19 @@ F:	src/mainboard/facebook/monolith/
 GETAC P470 MAINBOARD
 M:	Patrick Georgi <patrick@georgi.software>
 S:	Maintained
-F:	src/mainboard/getac/p470/
+F:	src/mainboard/getac/p470
 
 
 
 GIGABYTE GA-G41M-ES2L MAINBOARD
 M:	Damien Zammit <damien@zamaudio.com>
 S:	Odd Fixes
-F:	src/mainboard/gigabyte/ga-g41m-es2l/
+F:	src/mainboard/gigabyte/ga-g41m-es2l
 
 GIGABYTE GA-H61M SERIES MAINBOARDS
 M:	Angel Pons <th3fanbus@gmail.com>
 S:	Maintained
-F:	src/mainboard/gigabyte/ga-h61m-series/
+F:	src/mainboard/gigabyte/ga-h61m-series
 
 
 
@@ -281,7 +265,7 @@ F:	src/mainboard/google/stout/
 INTEL D510MO MAINBOARD
 M:	Damien Zammit <damien@zamaudio.com>
 S:	Odd Fixes
-F:	src/mainboard/intel/d510mo/
+F:	src/mainboard/intel/d510mo
 
 INTEL STRAGO MAINBOARD
 M:	Hannah Williams <hannah.williams@intel.com>
@@ -290,21 +274,6 @@ F:	/src/mainboard/intel/strago/
 
 
 
-KONTRON BSL6 MAINBOARD
-M:	Felix Singer <felixsinger@posteo.net>
-M:	Nico Huber <nico.h@gmx.de>
-S:	Supported
-F:	src/mainboard/kontron/bsl6/
-
-KONTRON MAL10 MAINBOARD
-M:	Maxim Polyakov <max.senia.poliak@gmail.com>
-M:	Nico Huber <nico.h@gmx.de>
-M:	Felix Singer <felixsinger@posteo.net>
-S:	Supported
-F:	src/mainboard/kontron/mal10/
-
-
-
 LENOVO MAINBOARDS
 M:	Alexander Couzens <lynxis@fe80.eu>
 M:	Patrick Rudolph <siro@das-labor.org>
@@ -322,7 +291,7 @@ LIBRETREND LT1000 MAINBOARD
 M:	Piotr Król <piotr.krol@3mdeb.com>
 M:	Michał Żygowski <michal.zygowski@3mdeb.com>
 S:	Maintained
-F:	src/mainboard/libretrend/lt1000/
+F:	src/mainboard/libretrend/lt1000
 
 
 OCP DELTALAKE MAINBOARD
@@ -333,7 +302,7 @@ M:	Morgan Jang <Morgan_Jang@wiwynn.com>
 M:	Ryback Hung <<Ryback.Hung@quantatw.com>
 M:	Bryant Ou <Bryant.Ou@quantatw.com>
 S:	Supported
-F:	src/mainboard/ocp/deltalake/
+F:	src/mainboard/ocp/deltalake
 
 OCP TIOGAPASS MAINBOARD
 M:	Jonathan Zhang <jonzhang@fb.com>
@@ -343,7 +312,7 @@ M:	Morgan Jang <Morgan_Jang@wiwynn.com>
 M:	Ryback Hung <<Ryback.Hung@quantatw.com>
 M:	Bryant Ou <Bryant.Ou@quantatw.com>
 S:	Maintained
-F:	src/mainboard/ocp/tiogapass/
+F:	src/mainboard/ocp/tiogapass
 
 
 
@@ -383,14 +352,14 @@ PRODRIVE HERMES MAINBOARD
 M:	Christian Walter <christian.walter@9elements.com>
 M:	Patrick Rudolph <patrick.rudolph@9elements.com>
 S:	Maintained
-F:	src/mainboard/prodrive/hermes/
+F:	src/mainboard/prodrive/hermes
 
 
 
 PURISM MAINBOARDS
 M:	Matt DeVillier <matt.devillier@puri.sm>
 S:	Supported
-F:	src/mainboard/purism/
+F:	src/mainboard/purism
 
 
 
@@ -402,12 +371,6 @@ F:	src/mainboard/samsung/stumpy/
 
 
 
-SIEMENS CHILI MAINBAORD
-M:	Felix Singer <felixsinger@posteo.net>
-M:	Nico Huber <nico.h@gmx.de>
-S:	Supported
-F:	src/mainboard/siemens/chili/
-
 SIEMENS MC_xxxx MAINBOARDS
 M:	Werner Zeh <werner.zeh@siemens.com>
 S:	Maintained
@@ -430,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
@@ -441,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/
@@ -535,13 +499,12 @@ F:	src/drivers/intel/
 F:	src/include/cpu/intel/
 
 INTEL FSP DENVERTON-NS SOC & HARCUVAR CRB
-M:	Suresh Bellampalli <suresh.bellampalli@intel.com>
 M:	Vanessa Eusebio <vanessa.f.eusebio@intel.com>
-M:	Michal Motyl <michalx.motyl@intel.com>
+M:	David Guckian <david.guckian@intel.com>
-M:	Mariusz Szafranski <mariuszx.szafranski@intel.com>
+S:	Odd Fixes
-S:	Maintained
 F:	src/mainboard/intel/harcuvar/
 F:	src/soc/intel/denverton_ns/
+F:	src/vendorcode/intel/fsp/fsp2_0/denverton_ns/
 
 INTEL FSP 1.1
 M:	Lee Leahy <leroy.p.leahy@intel.com>
@@ -559,28 +522,6 @@ F:	src/drivers/intel/fsp2_0/
 # Systems on a Chip
 ################################################################################
 
-AMD Cezanne
-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/cezanne/
-
-AMD common SoC code
-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/common/
-
-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
@@ -591,8 +532,8 @@ M:	Piotr Król <piotr.krol@3mdeb.com>
 M:	Michał Żygowski <michal.zygowski@3mdeb.com>
 M:	Frans Hendriks <fhendriks@eltan.com>
 S:	Maintained
-F:	/src/soc/intel/braswell/
+F:	/src/soc/intel/braswell
-F:	/src/vendorcode/intel/fsp/fsp1_1/braswell/
+F:	/src/vendorcode/intel/fsp/fsp1_1/braswell
 
 INTEL Xeon Sacalable Processor Family
 M:	Jonathan Zhang <jonzhang@fb.com>
@@ -603,18 +544,13 @@ M:	Ryback Hung <<Ryback.Hung@quantatw.com>
 M:	Bryant Ou <Bryant.Ou@quantatw.com>
 S:	Supported
 F:	src/soc/intel/xeon_sp
-F:	src/vendorcode/intel/fsp/fsp2_0/skylake_sp/
+F:	src/vendorcode/intel/fsp/fsp2_0/skylake_sp
-F:	src/vendorcode/intel/fsp/fsp2_0/copperlake_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/
@@ -637,13 +573,13 @@ F:	payloads/coreinfo/
 EXTERNAL PAYLOADS INTEGRATION
 M:	Stefan Reinauer <stefan.reinauer@coreboot.org>
 M:	Martin Roth <gaumless@gmail.com>
-F:	payloads/external/
+F:	payloads/external
 
 LINUXBOOT PAYLOAD INTEGRATION
 M:	Christian Walter <christian.walter@9elements.com>
 M:	Marcello Sylvester Bauer <info@marcellobauer.com>
 S:	Supported
-F:	payloads/external/LinuxBoot/
+F:	payloads/external/LinuxBoot
 
 ################################################################################
 # Utilities
@@ -717,8 +653,6 @@ F:	src/drivers/aspeed/common/
 F:	src/drivers/aspeed/ast2050/
 
 ACPI
-M:	Lance Zhao <lance.zhao@gmail.com>
-S:	Supported
 F:	src/acpi/
 F:	src/arch/x86/acpi/
 F:	util/acpi/
@@ -748,13 +682,8 @@ OPTION ROM EXECUTION & X86EMU
 F:	src/device/oprom/
 
 CBFS
-M:	Julius Werner <jwerner@chromium.org>
+F:	src/include/cbfs.h
-F:	src/include/cbfs*
+F:	src/commonlib/bsd/include/commonlib/bsd/cbfs_serialized.h
-F:	src/commonlib/bsd/include/commonlib/bsd/cbfs*
-F:	src/commonlib/bsd/cbfs*
-F:	src/lib/cbfs.c
-
-CBFSTOOL
 F:	util/cbfstool/
 
 CBMEM
@@ -775,7 +704,7 @@ TPM SUPPORT
 M:	Christian Walter <christian.walter@9elements.com>
 S:	Supported
 F:	src/drivers/*/tpm/
-F:	src/security/tpm/
+F:	src/security/tpm
 
 SUPERIOS & SUPERIOTOOL
 M:	Felix Held <felix-coreboot@felixheld.de>
@@ -793,7 +722,7 @@ ELTAN VENDORCODE
 M:	Frans Hendriks <fhendriks@eltan.com>
 M:	Wim Vervoorn <wvervoorn@eltan.com>
 S:	Maintained
-F:	src/vendorcode/eltan/
+F:	src/vendorcode/eltan
 
 MISSING: TIMERS / DELAYS
 

Makefile

@@ -8,7 +8,6 @@ src := src
 srck := $(top)/util/kconfig
 obj ?= build
 override obj := $(subst $(top)/,,$(abspath $(obj)))
-xcompile ?= $(obj)/xcompile
 objutil ?= $(obj)/util
 objk := $(objutil)/kconfig
 absobj := $(abspath $(obj))
@@ -120,7 +119,7 @@ UNIT_TEST:=1
 NOCOMPILE:=
 endif
 
-$(xcompile): util/xcompile/xcompile
+.xcompile: util/xcompile/xcompile
 	rm -f $@
 	$< $(XGCCPATH) > $@.tmp
 	\mv -f $@.tmp $@ 2> /dev/null
@@ -147,17 +146,15 @@ ifneq ($(UNIT_TEST),1)
 include $(DOTCONFIG)
 endif
 
-# The toolchain requires xcompile to determine the ARCH_SUPPORTED, so we can't
+# in addition to the dependency below, create the file if it doesn't exist
-# wait for make to generate the file.
+# to silence stupid warnings about a file that would be generated anyway.
-$(if $(wildcard $(xcompile)),, $(shell \
+$(if $(wildcard .xcompile)$(NOCOMPILE),,$(eval $(shell util/xcompile/xcompile $(XGCCPATH) > .xcompile || rm -f .xcompile)))
-	mkdir -p $(dir $(xcompile)) && \
-	util/xcompile/xcompile $(XGCCPATH) > $(xcompile) || rm -f $(xcompile)))
 
-include $(xcompile)
+-include .xcompile
 
 ifneq ($(XCOMPILE_COMPLETE),1)
-$(shell rm -f $(xcompile))
+$(shell rm -f .xcompile)
-$(error $(xcompile) deleted because it's invalid. \
+$(error .xcompile deleted because it's invalid. \
 	Restarting the build should fix that, or explain the problem)
 endif
 
@@ -443,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))
 
 #######################################################################
@@ -35,8 +34,7 @@ COREBOOT_EXPORTS += KERNELVERSION
 # Basic component discovery
 MAINBOARDDIR=$(call strip_quotes,$(CONFIG_MAINBOARD_DIR))
 VARIANT_DIR:=$(call strip_quotes,$(CONFIG_VARIANT_DIR))
-CARRIER_DIR:=$(call strip_quotes,$(CONFIG_CARRIER_DIR))
+COREBOOT_EXPORTS += MAINBOARDDIR VARIANT_DIR
-COREBOOT_EXPORTS += MAINBOARDDIR VARIANT_DIR CARRIER_DIR
 
 ## Final build results, which CBFSTOOL uses to create the final
 ## rom image file, are placed under $(objcbfs).
@@ -77,15 +75,14 @@ PHONY+= clean-abuild coreboot check-style build-dirs build_complete
 
 #######################################################################
 # root source directories of coreboot
-subdirs-y := src/lib src/commonlib/ src/console src/device src/acpi src/superio/common
+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 += $(wildcard src/superio/*) $(wildcard src/superio/*/*)
+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/cbfstool util/sconfig util/nvramtool util/pgtblgen
-subdirs-y += util/futility util/marvell util/bincfg util/supermicro util/qemu
+subdirs-y += util/futility util/marvell util/bincfg util/supermicro
-subdirs-y += util/ifdtool
 subdirs-y += $(wildcard src/arch/*)
 subdirs-y += src/mainboard/$(MAINBOARDDIR)
 subdirs-y += src/security
@@ -184,6 +181,9 @@ decompressor-generic-ccopts += -D__DECOMPRESSOR__
 bootblock-generic-ccopts += -D__BOOTBLOCK__
 romstage-generic-ccopts += -D__ROMSTAGE__
 ramstage-generic-ccopts += -D__RAMSTAGE__
+ifeq ($(CONFIG_TRACE),y)
+ramstage-c-ccopts += -finstrument-functions
+endif
 ifeq ($(CONFIG_COVERAGE),y)
 ramstage-c-ccopts += -fprofile-arcs -ftest-coverage
 endif
@@ -264,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
@@ -282,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;								\
@@ -334,9 +331,9 @@ endef
 # arg2: binary file
 cbfs-files-processor-struct= \
 	$(eval $(2): $(1) $(obj)/build.h $(KCONFIG_AUTOHEADER); \
-		printf "    CC+STRIP   $(1)\n"; \
+		printf "    CC+STRIP   $(@)\n"; \
 		$(CC_ramstage) -MMD $(CPPFLAGS_ramstage) $(CFLAGS_ramstage) $$(ramstage-c-ccopts) -include $(KCONFIG_AUTOHEADER) -MT $(2) -o $(2).tmp -c $(1) && \
-		$(OBJCOPY_ramstage) -O binary --set-section-flags .bss*=alloc,contents,load $(2).tmp $(2); \
+		$(OBJCOPY_ramstage) -O binary $(2).tmp $(2); \
 		rm -f $(2).tmp) \
 	$(eval DEPENDENCIES += $(2).d)
 
@@ -414,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
@@ -425,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),)
@@ -521,8 +514,7 @@ build_h_exports := BUILD_TIMELESS KERNELVERSION COREBOOT_EXTRA_VERSION
 # Report new `build.ht` as dependency if `build.h` differs.
 build_h_check := \
 	export $(foreach exp,$(build_h_exports),$(exp)="$($(exp))"); \
-	util/genbuild_h/genbuild_h.sh $(xcompile) \
+	util/genbuild_h/genbuild_h.sh .xcompile >$(build_h)t 2>/dev/null; \
-		>$(build_h)t 2>/dev/null; \
 	cmp -s $(build_h)t $(build_h) >/dev/null 2>&1 || echo $(build_h)t
 
 $(build_h): $$(shell $$(build_h_check))
@@ -532,12 +524,6 @@ $(build_h): $$(shell $$(build_h_check))
 build-dirs $(objcbfs) $(objgenerated):
 	mkdir -p $(objcbfs) $(objgenerated)
 
-$(obj)/build_info:
-	@echo 'COREBOOT_VERSION: $(call strip_quotes,$(KERNELVERSION))' > $@.tmp
-	@echo 'MAINBOARD_VENDOR: $(call strip_quotes,$(CONFIG_MAINBOARD_VENDOR))' >> $@.tmp
-	@echo 'MAINBOARD_PART_NUMBER: $(call strip_quotes,$(CONFIG_MAINBOARD_PART_NUMBER))' >> $@.tmp
-	mv $@.tmp $@
-
 #######################################################################
 # Build the tools
 CBFSTOOL:=$(objutil)/cbfstool/cbfstool
@@ -577,8 +563,15 @@ endif
 BINCFG:=$(objutil)/bincfg/bincfg
 
 IFDTOOL:=$(objutil)/ifdtool/ifdtool
+$(IFDTOOL):
+	@printf "    Compile IFDTOOL\n"
+	+$(MAKE) -C $(top)/util/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
 
@@ -595,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),)
+OVERRIDE_DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_OVERRIDE_DEVICETREE)
-CHIPSET_DEVICETREE_FILE := $(src)/$(CONFIG_CHIPSET_DEVICETREE)
+
-SCONFIG_OPTIONS += --chipset_devtree=$(CHIPSET_DEVICETREE_FILE)
 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
+$(DEVICETREE_STATIC_C): $(DEVICETREE_FILE) $(OVERRIDE_DEVICETREE_FILE) $(objutil)/sconfig/sconfig
-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
 	@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)
@@ -827,10 +805,6 @@ endif
 
 # cbfs-add-cmd-for-region
 # $(call cbfs-add-cmd-for-region,file in extract_nth format,region name)
-#
-# CBFSTOOL_ADD_CMD_OPTIONS can be used by arch/SoC/mainboard to supply
-# add commands with any additional arguments for cbfstool.
-# Example: --ext-win-base <base> --ext-win-size <size>
 define cbfs-add-cmd-for-region
 	$(CBFSTOOL) $@.tmp \
 	add$(if $(filter stage,$(call extract_nth,3,$(1))),-stage)$(if \
@@ -845,8 +819,8 @@ define cbfs-add-cmd-for-region
 	-r $(2) \
 	$(if $(call extract_nth,6,$(1)),-a $(call extract_nth,6,$(file)), \
 		$(if $(call extract_nth,5,$(file)),-b $(call extract_nth,5,$(file)))) \
-		$(call extract_nth,7,$(1)) \
+		$(call extract_nth,7,$(1))
-	$(CBFSTOOL_ADD_CMD_OPTIONS)
+
 
 endef
 # Empty line before endef is necessary so cbfs-add-cmd-for-region ends in a
@@ -970,25 +944,6 @@ else
 FMAP_SMMSTORE_ENTRY :=
 endif
 
-ifeq ($(CONFIG_SPD_CACHE_IN_FMAP),y)
-FMAP_SPD_CACHE_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x4000)
-FMAP_SPD_CACHE_SIZE := $(call int-multiply, $(CONFIG_DIMM_MAX) $(CONFIG_DIMM_SPD_SIZE))
-FMAP_SPD_CACHE_SIZE := $(call int-align, $(FMAP_SPD_CACHE_SIZE), 0x1000)
-FMAP_SPD_CACHE_ENTRY := $(CONFIG_SPD_CACHE_FMAP_NAME)@$(FMAP_SPD_CACHE_BASE) $(FMAP_SPD_CACHE_SIZE)
-FMAP_CURRENT_BASE := $(call int-add, $(FMAP_SPD_CACHE_BASE) $(FMAP_SPD_CACHE_SIZE))
-else
-FMAP_SPD_CACHE_ENTRY :=
-endif
-
-ifeq ($(CONFIG_VPD),y)
-FMAP_VPD_BASE := $(call int-align, $(FMAP_CURRENT_BASE), 0x4000)
-FMAP_VPD_SIZE := $(CONFIG_VPD_FMAP_SIZE)
-FMAP_VPD_ENTRY := $(CONFIG_VPD_FMAP_NAME)@$(FMAP_VPD_BASE) $(FMAP_VPD_SIZE)
-FMAP_CURRENT_BASE := $(call int-add, $(FMAP_VPD_BASE) $(FMAP_VPD_SIZE))
-else
-FMAP_VPD_ENTRY :=
-endif
-
 #
 # X86 FMAP region
 #
@@ -1065,8 +1020,6 @@ $(obj)/fmap.fmd: $(top)/Makefile.inc $(DEFAULT_FLASHMAP) $(obj)/config.h
 	    -e "s,##CONSOLE_ENTRY##,$(FMAP_CONSOLE_ENTRY)," \
 	    -e "s,##MRC_CACHE_ENTRY##,$(FMAP_MRC_CACHE_ENTRY)," \
 	    -e "s,##SMMSTORE_ENTRY##,$(FMAP_SMMSTORE_ENTRY)," \
-	    -e "s,##SPD_CACHE_ENTRY##,$(FMAP_SPD_CACHE_ENTRY)," \
-	    -e "s,##VPD_ENTRY##,$(FMAP_VPD_ENTRY)," \
 	    -e "s,##CBFS_BASE##,$(FMAP_CBFS_BASE)," \
 	    -e "s,##CBFS_SIZE##,$(FMAP_CBFS_SIZE)," \
 		$(DEFAULT_FLASHMAP) > $@.tmp
@@ -1090,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)
@@ -1101,8 +1053,7 @@ ifeq ($(CONFIG_ARCH_X86),y)
 		-t bootblock \
 		$(TXTIBB) \
 		-b -$(call file-size,$(objcbfs)/bootblock.bin) $(cbfs-autogen-attributes) \
-		$(TS_OPTIONS) \
+		$(TS_OPTIONS)
-		$(CBFSTOOL_ADD_CMD_OPTIONS)
 else # ifeq ($(CONFIG_ARCH_X86),y)
 	$(CBFSTOOL) $@.tmp write -u \
 		-r BOOTBLOCK \
@@ -1114,11 +1065,10 @@ else # ifeq ($(CONFIG_ARCH_X86),y)
 		-f $@.tmp.2 \
 		-n "header pointer" \
 		-t "cbfs header" \
-		-b -4 \
+		-b -4
-		$(CBFSTOOL_ADD_CMD_OPTIONS)
 	rm -f $@.tmp.2
 endif # ifeq ($(CONFIG_ARCH_X86),y)
-	$(CBFSTOOL) $@.tmp add-master-header $(TS_OPTIONS) $(CBFSTOOL_ADD_CMD_OPTIONS)
+	$(CBFSTOOL) $@.tmp add-master-header $(TS_OPTIONS)
 	$(prebuild-files) true
 	mv $@.tmp $@
 else # ifneq ($(CONFIG_UPDATE_IMAGE),y)
@@ -1138,30 +1088,74 @@ $(REFCODE_BLOB): $(RMODTOOL)
 	$(RMODTOOL) -i $(CONFIG_REFCODE_BLOB_FILE) -o $@
 endif
 
+FIT_ENTRY=$(call strip_quotes, $(CONFIG_INTEL_TOP_SWAP_FIT_ENTRY_FMAP_REG))
+
 ifeq ($(CONFIG_HAVE_RAMSTAGE),y)
 RAMSTAGE=$(objcbfs)/ramstage.elf
 else
 RAMSTAGE=
 endif
 
-add_intermediate = \
-	$(1): $(2) | $(INTERMEDIATE) \
-	$(eval INTERMEDIATE+=$(1)) $(eval PHONY+=$(1))
-
 $(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)
-# Print final FIT table
+ifneq ($(CONFIG_UPDATE_IMAGE),y) # never update the bootblock
+ifeq ($(CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER),y)
+	@printf "    UPDATE-FIT\n"
+	$(IFITTOOL) -f $@.tmp -a -n cpu_microcode_blob.bin -t 1 -s $(CONFIG_CPU_INTEL_NUM_FIT_ENTRIES) \
+	-r COREBOOT
+endif
+ifeq ($(CONFIG_USE_CPU_MICROCODE_CBFS_BINS),y)
+	@printf "    UPDATE-FIT\n"
+	$(IFITTOOL) -f $@.tmp -a -n cpu_microcode_blob.bin -t 1 -s $(CONFIG_CPU_INTEL_NUM_FIT_ENTRIES) \
+	-r COREBOOT
+endif
 	$(IFITTOOL) -f $@.tmp -D -r COREBOOT
-# Print final TS BOOTBLOCK FIT table
+
+# Second FIT in TOP_SWAP bootblock
 ifeq ($(CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK),y)
-	@printf "    TOP SWAP FIT table\n"
+# INTEL_TOP_SWAP_FIT_ENTRY_FMAP_REG adds a region as first ucode into the seconds bootblock
+ifneq ($(FIT_ENTRY),)
+	@printf "    UPDATE-FIT2\n"
+	$(IFITTOOL) -f $@.tmp -A -n $(FIT_ENTRY) -t 1 -s $(CONFIG_CPU_INTEL_NUM_FIT_ENTRIES) \
+	$(TS_OPTIONS) -r COREBOOT
+endif
+ifeq ($(CONFIG_CPU_MICROCODE_CBFS_EXTERNAL_HEADER),y)
+	@printf "    UPDATE-FIT2\n"
+	$(IFITTOOL) -f $@.tmp -a -n cpu_microcode_blob.bin -t 1 -s $(CONFIG_CPU_INTEL_NUM_FIT_ENTRIES) \
+	$(TS_OPTIONS) -r COREBOOT
+endif
+ifeq ($(CONFIG_USE_CPU_MICROCODE_CBFS_BINS),y)
+	@printf "    UPDATE-FIT2\n"
+	$(IFITTOOL) -f $@.tmp -a -n cpu_microcode_blob.bin -t 1 -s $(CONFIG_CPU_INTEL_NUM_FIT_ENTRIES) \
+	$(TS_OPTIONS) -r COREBOOT
+endif
 	$(IFITTOOL) -f $@.tmp -D $(TS_OPTIONS) -r COREBOOT
-endif # CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK
+
+endif
+
+endif # !CONFIG_UPDATE_IMAGE
 endif # CONFIG_CPU_INTEL_FIRMWARE_INTERFACE_TABLE
 	mv $@.tmp $@
 	@printf "    CBFSLAYOUT  $(subst $(obj)/,,$(@))\n\n"
@@ -1226,10 +1220,6 @@ cbfs-files-$(CONFIG_INCLUDE_CONFIG_FILE) += revision
 revision-file := $(obj)/build.h
 revision-type := raw
 
-cbfs-files-y += build_info
-build_info-file := $(obj)/build_info
-build_info-type := raw
-
 BOOTSPLASH_SUFFIX=$(suffix $(call strip_quotes,$(CONFIG_BOOTSPLASH_FILE)))
 cbfs-files-$(CONFIG_BOOTSPLASH_IMAGE) += bootsplash$(BOOTSPLASH_SUFFIX)
 bootsplash$(BOOTSPLASH_SUFFIX)-file := $(call strip_quotes,$(CONFIG_BOOTSPLASH_FILE))
@@ -1251,7 +1241,7 @@ cbfs-get-segments-cmd = $(CBFSTOOL) $(obj)/coreboot.pre print -v | sed -n \
 ramstage-symbol-addr-cmd = $(OBJDUMP_ramstage) -t $(objcbfs)/ramstage.elf | \
 	sed -n '/ $(1)$$/s/^\([0-9a-fA-F]*\) .*/0x\1/p'
 
-$(call add_intermediate, check-ramstage-overlaps, $(obj)/coreboot.pre)
+check-ramstage-overlaps: $(obj)/coreboot.pre
 	programs=$$($(foreach file,$(check-ramstage-overlap-files), \
 		$(call cbfs-get-segments-cmd,$(file)) ; )) ; \
 	regions=$$($(foreach region,$(check-ramstage-overlap-regions), \
@@ -1277,4 +1267,6 @@ $(call add_intermediate, check-ramstage-overlaps, $(obj)/coreboot.pre)
 	    pstart= ; pend= ; \
 	done
 
+INTERMEDIATE+=check-ramstage-overlaps
+PHONY+=check-ramstage-overlaps
 endif

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.asus_p8z77-v_lx2.debug_smmstore_hotplug_yabel_em100

@@ -1,38 +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:
-# + PCIe hotplug
-# + Fatal assertions
-# + Debug options
-# + SMMSTORE
-# + YABEL
-# + VESA framebuffer
-# + EM100 support
-CONFIG_VENDOR_ASUS=y
-CONFIG_CBFS_SIZE=0x200000
-CONFIG_BOARD_ASUS_P8Z77_V_LX2=y
-CONFIG_PCIEXP_L1_SUB_STATE=y
-CONFIG_PCIEXP_CLK_PM=y
-# CONFIG_S3_VGA_ROM_RUN is not set
-CONFIG_NATIVE_RAMINIT_IGNORE_MAX_MEM_FUSES=y
-CONFIG_NATIVE_RAMINIT_IGNORE_XMP_MAX_DIMMS=y
-CONFIG_RAMINIT_ALWAYS_ALLOW_DLL_OFF=y
-CONFIG_VGA_ROM_RUN=y
-CONFIG_PCI_OPTION_ROM_RUN_YABEL=y
-CONFIG_FRAMEBUFFER_SET_VESA_MODE=y
-CONFIG_VBE_LINEAR_FRAMEBUFFER=y
-CONFIG_PCIEXP_HOTPLUG=y
-CONFIG_SMMSTORE=y
-CONFIG_FATAL_ASSERTS=y
-CONFIG_DEBUG_CBFS=y
-CONFIG_DEBUG_RAM_SETUP=y
-CONFIG_DEBUG_SMBUS=y
-CONFIG_DEBUG_SMI=y
-CONFIG_DEBUG_MALLOC=y
-CONFIG_DEBUG_CONSOLE_INIT=y
-CONFIG_DEBUG_SPI_FLASH=y
-CONFIG_DEBUG_BOOT_STATE=y
-CONFIG_DEBUG_ADA_CODE=y
-CONFIG_HAVE_EM100_SUPPORT=y
-CONFIG_EM100=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