WIP: lemp9 vboot support

Change-Id: I47fbc95a8bd242b4261f5fc52b073f0b2b6ab080

.checkpatch.conf

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

.gitignore

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

.gitmodules

@@ -9,7 +9,6 @@
 [submodule "vboot"]
 	path = 3rdparty/vboot
 	url = https://review.coreboot.org/vboot.git
-	branch = main
 [submodule "arm-trusted-firmware"]
 	path = 3rdparty/arm-trusted-firmware
 	url = https://review.coreboot.org/arm-trusted-firmware.git
@@ -35,13 +34,12 @@
 	url = https://review.coreboot.org/intel-microcode.git
 	update = none
 	ignore = dirty
-	branch = main
 [submodule "3rdparty/ffs"]
 	path = 3rdparty/ffs
 	url = https://review.coreboot.org/ffs.git
 [submodule "3rdparty/amd_blobs"]
 	path = 3rdparty/amd_blobs
-	url = https://review.coreboot.org/amd_blobs
+	url = https://review.coreboot.org/amd_blobs.git
 	update = none
 	ignore = dirty
 [submodule "3rdparty/cmocka"]
@@ -53,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/Intel/Board/board.html

@@ -0,0 +1,239 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Board</title>
+  </head>
+  <body>
+
+<h1>x86 Board Development</h1>
+<p>
+  Board development requires System-on-a-Chip (SoC) support.
+  The combined steps are listed
+  <a target="_blank" href="../development.html">here</a>.
+  The development steps for the board are listed below:
+</p>
+<ol>
+  <li><a href="#RequiredFiles">Required Files</a></li>
+  <li>Enable <a href="#SerialOutput">Serial Output</a></li>
+  <li>Load the <a href="#SpdData">Memory Timing Data</a></li>
+  <li><a href="#DisablePciDevices">Disable</a> the PCI devices</li>
+  <li><a href="#AcpiTables">ACPI Tables</a></li>
+</ol>
+
+
+<hr>
+<h2><a name="RequiredFiles">Required Files</a></h2>
+<p>
+  Create the board directory as src/mainboard/&lt;Vendor&gt;/&lt;Board&gt;.
+</p>
+
+<p>
+  The following files are required to build a new board:
+</p>
+<ol>
+  <li>Kconfig.name - Defines the Kconfig value for the board</li>
+  <li>Kconfig
+    <ol type="A">
+      <li>Selects the SoC for the board and specifies the SPI flash size
+        <ol type="I">
+          <li>BOARD_ROMSIZE_KB_&lt;Size&gt;</li>
+          <li>SOC_&lt;Vendor&gt;_&lt;Chip Family&gt;</li>
+        </ol>
+      </li>
+      <li>Declare the Kconfig values for:
+        <ol type="I">
+          <li>MAINBOARD_DIR</li>
+          <li>MAINBOARD_PART_NUMBER</li>
+          <li>MAINBOARD_VENDOR</li>
+        </ol>
+      </li>
+    </ol>
+  </li>
+  <li>devicetree.cb - Enable root bridge and serial port
+    <ol type="A">
+      <li>The first line must be "chip soc/Intel/&lt;soc family&gt;";
+        this path is used by the generated static.c to include the chip.h
+        header file
+      </li>
+    </ol>
+  </li>
+  <li>romstage.c
+    <ol type="A">
+      <li>Add routine mainboard_romstage_entry which calls romstage_common</li>
+    </ol>
+  </li>
+  <li>Configure coreboot build:
+    <ol type="A">
+      <li>Set LOCALVERSION</li>
+      <li>Select vendor for the board</li>
+      <li>Select the board</li>
+      <li>CBFS_SIZE = 0x00100000</li>
+      <li>Set the CPU_MICROCODE_CBFS_LEN</li>
+      <li>Set the CPU_MICROCODE_CBFS_LOC</li>
+      <li>Set the FSP_IMAGE_ID_STRING</li>
+      <li>Set the FSP_LOC</li>
+      <li>No payload</li>
+      <li>Choose the default value for all other options</li>
+    </ol>
+  </li>
+</ol>
+
+
+<hr>
+<h2><a name="SerialOutput">Enable Serial Output</a></h2>
+<p>
+  Use the following steps to enable serial output:
+</p>
+<ol>
+  <li>Implement the car_mainboard_pre_console_init routine in the com_init.c
+    file:
+    <ol type="A">
+      <li>Power on and enable the UART controller</li>
+      <li>Connect the UART receive and transmit data lines to the
+        appropriate SoC pins
+      </li>
+    </ol>
+  </li>
+  <li>Add Makefile.inc
+    <ol type="A">
+      <li>Add com_init.c to romstage</li>
+    </ol>
+  </li>
+</ol>
+
+
+<hr>
+<h2><a name="SpdData">Memory Timing Data</a></h2>
+<p>
+  Memory timing data is located in the flash.  This data is in the format of
+  <a target="_blank" href="https://en.wikipedia.org/wiki/Serial_presence_detect">serial presence detect</a>
+  (SPD) data.
+  Use the following steps to load the SPD data:
+</p>
+<ol>
+  <li>Edit Kconfig to add the DISPLAY_SPD_DATA" value which enables the
+    display of the SPD data being passed to MemoryInit
+  </li>
+  <li>Create an "spd" subdirectory</li>
+  <li>Create an spd/spd.c file for the SPD implementation
+    <ol type="A">
+      <li>Implement the mainboard_fill_spd_data routine
+        <ol type="i">
+          <li>Read the SPD data either from the spd.bin file or using I2C or SMBUS</li>
+          <li>Fill in the pei_data structure with SPD data for each of the DIMMs</li>
+          <li>Set the DIMM channel configuration</li>
+        </ol>
+      </li>
+    </ol>
+  </li>
+  <li>Add an .spd.hex file containing the memory timing data to the spd subdirectory</li>
+  <li>Create spd/Makefile.inc
+    <ol type="A">
+      <li>Add spd.c to romstage</li>
+      <li>Add the .spd.hex file to SPD_SOURCES</li>
+    </ol>
+  </li>
+  <li>Edit Makefile.inc to add the spd subdirectory</li>
+  <li>Edit romstage.c
+    <ol type="A">
+      <li>Call mainboard_fill_spd_data</li>
+      <li>Add mainboard_memory_init_params to copy the SPD and DRAM
+        configuration data from the pei_data structure into the UPDs
+        for MemoryInit
+      </li>
+    </ol>
+  </li>
+  <li>Edit devicetree.cb
+    <ol type="A">
+      <li>Include the UPD parameters for MemoryInit except for:
+        <ul>
+          <li>Address of SPD data</li>
+          <li>DRAM configuration set above</li>
+        </ul>
+      </li>
+    </ol>
+  </li>
+  <li>A working FSP
+    <a target="_blank" href="../fsp1_1.html#MemoryInit">MemoryInit</a>
+    routine is required to complete debugging</li>
+  <li>Debug the result until port 0x80 outputs
+    <ol type="A">
+      <li>0x34:
+        - Just after entering
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/raminit.c;hb=HEAD#l67">raminit</a>
+      </li>
+      <li>0x36:
+        - Just before displaying the
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/raminit.c;hb=HEAD#l106">UPD parameters</a>
+        for FSP MemoryInit
+      </li>
+      <li>0x92: <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l219">POST_FSP_MEMORY_INIT</a>
+        - Just before calling FSP
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/raminit.c;hb=HEAD#l125">MemoryInit</a>
+      </li>
+      <li>0x37:
+        - Just after returning from FSP
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/raminit.c;hb=HEAD#l127">MemoryInit</a>
+      </li>
+    </ol>
+  </li>
+  <li>Continue debugging with CONFIG_DISPLAY_HOBS enabled until TempRamExit is called</li>
+</ol>
+
+
+
+<hr>
+<h2><a name="DisablePciDevices">Disable PCI Devices</a></h2>
+<p>
+  Ramstage's BS_DEV_ENUMERATE state displays the PCI vendor and device IDs for all
+  of the devices in the system.  Edit the devicetree.cb file:
+</p>
+<ol>
+  <li>Edit the devicetree.cb file:
+    <ol type="A">
+      <li>Add an entry for a PCI device.function and turn it off.  The entry
+        should look similar to:
+<pre><code>device pci 14.0 off end</code></pre>
+      </li>
+      <li>Turn on the devices for:
+        <ul>
+          <li>Memory Controller</li>
+          <li>Debug serial device</li>
+        </ul>
+      </li>
+    </ol>
+  </li>
+  <li>Debug until the BS_DEV_ENUMERATE state shows the proper state for all of the devices</li>
+</ol>
+
+
+
+<hr>
+<h2><a name="AcpiTables">ACPI Tables</a></h2>
+<ol>
+  <li>Edit Kconfig
+    <ol type="A">
+      <li>Add "select HAVE_ACPI_TABLES"</li>
+    </ol>
+  </li>
+  <li>Add the acpi_tables.c module:
+    <ol type="A">
+      <li>Include soc/acpi.h</li>
+      <li>Add the acpi_create_fadt routine
+        <ol type="I">
+          <li>fill in the ACPI header</li>
+          <li>Call the acpi_fill_fadt routine</li>
+        </ol>
+      </li>
+    </ol>
+  </li>
+  <li>Add the dsdt.asl module:
+  </li>
+</ol>
+
+
+
+<hr>
+<p>Modified: 20 February 2016</p>
+  </body>
+</html>

Documentation/Intel/Board/galileo.html

@@ -0,0 +1,113 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Galileo</title>
+  </head>
+  <body>
+
+<h1>Intel&reg; Galileo Development Board</h1>
+<table>
+  <tr>
+    <td><a target="_blank" href="http://www.mouser.com/images/microsites/Intel_Galileo2_lrg.jpg"><img alt="Galileo Gen 2" src="http://www.mouser.com/images/microsites/Intel_Galileo2_lrg.jpg" width=500></a></td>
+    <td>
+      The Intel&reg; Galileo Gen 2 mainboard code was developed along with the Intel&reg;
+      <a target="_blank" href="../SoC/quark.html">Quark&trade;</a> SoC:
+      <ul>
+        <li><a target="_blank" href="../development.html">Overall</a> development</li>
+        <li><a target="_blank" href="../SoC/soc.html">SoC</a> support</li>
+        <li><a target="_blank" href="../fsp1_1.html">FSP 1.1</a> integration</li>
+        <li><a target="_blank" href="board.html">Board</a> support</li>
+      </ul>
+    </td>
+  </tr>
+</table>
+
+
+
+<hr>
+<h2>Galileo Board Documentation</h2>
+<ul>
+  <li>Common Components
+    <ul>
+      <li>A/D: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/adc108s102.pdf">ADC108S102</a></li>
+      <li>Analog Switch: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/ts5a23159.pdf">TS5A23159</a></li>
+      <li>Ethernet (10/100 MB/S): Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/dp83848-ep.pdf">DP83848</a></li>
+      <li>Load Switch: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/tps22920.pdf">TPS22920x</a></li>
+      <li>Memory (256 MiB): Micron <a target="_blank" href="https://www.micron.com/~/media/Documents/Products/Data%20Sheet/DRAM/DDR3/1Gb_1_35V_DDR3L.pdf">MT41K128M8</a></li>
+      <li>SoC: Intel&reg; Quark&trade; <a target="_blank" href="../SoC/quark.html">X-1000</a></li>
+      <li>Serial EEPROM (1 KiB): ON Semiconductor&reg; <a target="_blank" href="http://www.onsemi.com/pub_link/Collateral/CAT24C01-D.PDF">CAT24C08</a></li>
+      <li>SPI Flash (8 MiB): Winbond&trade; <a target="_blank" href="http://www.winbond-usa.com/resource-files/w25q64fv_revl1_100713.pdf">W25Q64FV</a></li>
+      <li>Step Down Converter: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/slvsag7c/slvsag7c.pdf">TPS62130</a></li>
+      <li>Step Down Converter: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ug/slvu570/slvu570.pdf">TPS652510</a></li>
+      <li>Termination Regulator: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/tps51200.pdf">TPS51200</a></li>
+    </ul>
+  </li>
+  <li>Make a bootable <a target="_blank" href="https://software.intel.com/en-us/get-started-galileo-linux-step1">micro SD card</a></li>
+</ul>
+
+<h3>Galileo Gen 2 Board Documentation</h3>
+<ul>
+  <li><a target="_blank" href="http://files.linuxgizmos.com/intel_galileo_gen2_blockdiagram.jpg">Block Diagram</a></li>
+  <li><a target="_blank" href="https://software.intel.com/en-us/iot/library/galileo-getting-started">Getting Started</a></li>
+  <li><a target="_blank" href="http://www.intel.com/content/www/us/en/embedded/products/galileo/galileo-overview.html">Overview</a></li>
+  <li><a target="_blank" href="http://files.linuxgizmos.com/intel_galileo_gen2_ports.jpg">Port Diagram</a></li>
+  <li><a target="_blank" href="http://download.intel.com/support/galileo/sb/intelgalileogen2prodbrief_330736_003.pdf">Product Brief</a></li>
+  <li><a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/guides/galileo-g2-schematic.pdf">Schematic</a></li>
+  <li><a target="_blank" href="http://download.intel.com/support/galileo/sb/galileo_boarduserguide_330237_001.pdf">User Guide</a></li>
+  <li>Components
+    <ul>
+      <li>A/D: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/adc108s102.pdf">ADC108S102</a></li>
+      <li>I2C 16-channel, 12-bit PWM: NXP Semiconductors <a target="_blank" href="http://cache.nxp.com/documents/data_sheet/PCA9685.pdf">PCA9685</a></li>
+      <li>I2C I/O Ports: NXP Semiconductors <a target="_blank" href="http://www.nxp.com/documents/data_sheet/PCAL9535A.pdf">PCAL9535A</a></li>
+      <li>Octal Buffer/Driver: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/sn74lv541at.pdf">SN74LV541AT</a></li>
+      <li>Quadruple Bus Buffer: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/sn74lv125a.pdf">SN74LV125A</a></li>
+      <li>Quadruple Bus Buffer with 3-State Outputs: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/sn74lvc126a.pdf">SN74LVC126A</a></li>
+      <li>Serial EEPROM (1 KiB): ON Semiconductor&reg; <a target="_blank" href="http://www.onsemi.com/pub_link/Collateral/CAT24C01-D.PDF">CAT24C08</a></li>
+      <li>Single 2-input multiplexer: NXP Semiconductors <a target="_blank" href="http://www.nxp.com/documents/data_sheet/74LVC1G157.pdf">74LVC1G157</a></li>
+      <li>Step Down Converter: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/slvsag7c/slvsag7c.pdf">TPS62130</a></li>
+    </ul>
+  </li>
+</ul>
+
+<h3>Galileo Gen 1 Board Documentation</h3>
+<ul>
+  <li><a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/galileo-g1-datasheet.pdf">Datasheet</a></li>
+  <li><a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/guides/galileo-g1-schematic.pdf">Schematic</a></li>
+  <li>Components
+    <ul>
+      <li>A/D: Analog Devices <a target="_blank" href="http://www.analog.com/media/en/technical-documentation/data-sheets/AD7298-1.pdf">AD7298</a></li>
+      <li>Analog Switch, 2 channel: Texas Instruments <a target="_blank" href="http://www.ti.com.cn/cn/lit/ds/symlink/ts5a23159.pdf">TS5A23159</a></li>
+      <li>EEPROM & GPIO: Cypress <a target="_blank" href="http://www.cypress.com/file/37971/download">CY8C9540A</a></li>
+      <li>Power Distribution Switch: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/tps2044b.pdf">TPS2051BDBVR</a></li>
+      <li>RS232 Converter: Texas Instruments <a target="_blank" href="http://www.ti.com/lit/ds/symlink/max3232.pdf">MAX3232</a></li>
+      <li>Voltage-Level Translator: Texas Instruments<a target="_blank" href="http://www.ti.com/lit/ds/symlink/txs0108e.pdf">TXS0108E</a></li>
+    </ul>
+  </li>
+</ul>
+
+
+
+<hr>
+<h2>Debug Tools</h2>
+<ul>
+  <li>Flash Programmer:
+    <ul>
+      <li>Dediprog <a target="_blank" href="http://www.dediprog.com/pd/spi-flash-solution/SF100">SF100</a> ISP IC Programmer</li>
+    </ul>
+  </li>
+  <li>JTAG Connector: <a target="_blank" href="https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=Olimex+ARM-JTAG-20-10">Olimex ARM-JTAG-20-10</a></li>
+  <li>JTAG Debugger:
+    <ul>
+      <li>Olimex LTD <a target="_blank" href="https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=Olimex+ARM-USB-OCD-H">ARM-USB-OCD-H</a></li>
+      <li>Tincan Tools <a target="_blank" href="https://www.tincantools.com/wiki/Flyswatter2">Flyswatter2</a></li>
+    </ul>
+  </li>
+  <li><a target="_blank" href="http://download.intel.com/support/processors/quark/sb/sourcedebugusingopenocd_quark_appnote_330015_003.pdf">Hardware Setup and Software Installation</a></li>
+  <li>USB Serial cable: FTDI <a target="_blank" href="https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=FTDI+TTL-232R-3V3">TTL-232R-3V3</a></li>
+</ul>
+
+
+<hr>
+<p>Modified: 29 February 2016</p>
+  </body>
+</html>

Documentation/Intel/SoC/quark.html

@@ -0,0 +1,220 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Quark&trade; SoC</title>
+  </head>
+  <body>
+
+<h1>Intel&reg; Quark&trade; SoC</h1>
+<table>
+  <tr>
+    <td><a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/images/embedded/16x9/edc-quark-block-diagram-16x9.png"><img alt="Quark Block Diagram" src="http://www.intel.com/content/dam/www/public/us/en/images/embedded/16x9/edc-quark-block-diagram-16x9.png" width=500></a></td>
+    <td>
+      The Quark&trade; SoC code was developed using the
+      <a target="_blank" href="../Board/galileo.html">Galileo Gen 2</a>
+      board:
+      <ul>
+        <li><a target="_blank" href="../development.html">Overall</a> development</li>
+        <li><a target="_blank" href="soc.html">SoC</a> support</li>
+        <li><a target="_blank" href="../fsp1_1.html">FSP 1.1</a> integration</li>
+        <li><a target="_blank" href="../Board/board.html">Board</a> support</li>
+        <li><a target="_blank" href="#QuarkFsp">Quark&trade; FSP</a></li>
+        <li><a target="_blank" href="#CorebootPayloadPkg">CorebootPayloadPkg</a></li>
+      </ul>
+    </td>
+  </tr>
+</table>
+
+
+
+<hr>
+<h2>Quark&trade; Documentation</h2>
+<ul>
+  <li><a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/images/embedded/16x9/edc-quark-block-diagram-16x9.png">Block Diagram</a></li>
+  <li><a target="_blank" href="http://www.intel.com/content/www/us/en/embedded/products/quark/specifications.html">Specifications</a>:
+    <ul>
+      <li><a target="_blank" href="http://ark.intel.com/products/79084/Intel-Quark-SoC-X1000-16K-Cache-400-MHz">X1000</a>
+        - <a target="_blank" href="http://www.intel.com/content/www/us/en/search.html?keyword=X1000">Documentation</a>:
+        <ul>
+          <li><a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/quark-x1000-datasheet.pdf">Datasheet</a></li>
+          <li><a target="_blank" href="http://www.intel.com/content/dam/support/us/en/documents/processors/quark/sb/intelquarkcore_devman_001.pdf">Developer's Manual</a></li>
+          <li><a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/intel-quark-product-brief-v3.pdf">Product Brief</a></li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+  <li><a target="_blank" href="../index.html#Documentation">More documentation</a></li>
+</ul>
+
+
+
+<hr>
+<h2><a name="CorebootPayloadPkg">Quark&trade; EDK2 CorebootPayloadPkg</a></h2>
+<p>
+Build Instructions:
+</p>
+<ol>
+  <li>Set up <a href="#BuildEnvironment">build environment</a></li>
+  <li>Linux (assumes GCC48):
+<pre><code>build  -p CorebootPayloadPkg/CorebootPayloadPkgIa32.dsc  -a IA32  \
+    -t GCC48  -b DEBUG  -DDEBUG_PROPERTY_MASK=0x27  \
+    -DDEBUG_PRINT_ERROR_LEVEL=0x80000042  -DSHELL_TYPE=BUILD_SHELL  \
+    -DMAX_LOGICAL_PROCESSORS=1
+ls Build/CorebootPayloadPkgIA32/DEBUG_GCC48/FV/UEFIPAYLOAD.fd
+</code></pre>
+  </li>
+  <li>Windows (assumes Visual Studio 2015):
+<pre><code>build  -p CorebootPayloadPkg\CorebootPayloadPkgIa32.dsc  -a IA32  -t VS2015x86  -b DEBUG  -DDEBUG_PROPERTY_MASK=0x27  -DDEBUG_PRINT_ERROR_LEVEL=0x80000042  -DSHELL_TYPE=BUILD_SHELL  -DMAX_LOGICAL_PROCESSORS=1
+dir Build\CorebootPayloadPkgIA32\DEBUG_VS2015x86\FV\UEFIPAYLOAD.fd
+</code></pre>
+  </li>
+  <li>In the .config for coreboot, set the following Kconfig values:
+    <ul>
+      <li>CONFIG_PAYLOAD_ELF=y</li>
+      <li>CONFIG_PAYLOAD_FILE="path to UEFIPAYLOAD.fd"</li>
+    </ul>
+  </li>
+  <li>Build coreboot</li>
+  <li>Copy the image build/coreboot.rom into flash</li>
+</ol>
+
+
+
+<hr>
+<h2><a name="BuildEnvironment">Quark&trade; EDK2 Build Environment</a></h2>
+<p>
+  Use the following steps to setup a build environment:
+</p>
+<ol>
+  <li>Get the EDK2 sources:
+    <ol type="A">
+      <li>EDK2: git clone <a target="_blank" href="https://github.com/tianocore/edk2.git">https://github.com/tianocore/edk2.git</a></li>
+      <li>EDK2-non-osi: git clone <a target="_blank" href="https://github.com/tianocore/edk2-non-osi.git">https://github.com/tianocore/edk2-non-osi.git</a></li>
+      <li>Win32 BaseTools: git clone <a target="_blank" href="https://github.com/tianocore/edk2-BaseTools-win32.git">https://github.com/tianocore/edk2-BaseTools-win32.git</a></li>
+    </ol>
+  </li>
+  <li>Set up a build window:
+    <ul>
+      <li>Linux:
+<pre><code>export WORKSPACE=$PWD
+export PACKAGES_PATH="$PWD/edk2:$PWD/edk2-non-osi"
+cd edk2
+export WORKSPACE=$PWD
+. edksetup.sh
+</code></pre>
+      </li>
+      <li>Windows:
+<pre><code>set WORKSPACE=%CD%
+set PACKAGES_PATH=%WORKSPACE%\edk2;%WORKSPACE%\edk2-non-osi
+set EDK_TOOLS_BIN=%WORKSPACE%\edk2-BaseTools-win32
+cd edk2
+edksetup.bat
+</code></pre>
+      </li>
+    </ul>
+  </li>
+</ol>
+
+
+
+<hr>
+<h2><a name="QuarkFsp">Quark&trade; FSP</a></h2>
+<p>
+Getting the Quark FSP source:
+</p>
+<ol>
+  <li>Set up an EDK-II <a href="#BuildEnvironment">Build Environment</a></li>
+  <li>cd edk2</li>
+  <li>mkdir QuarkFspPkg</li>
+  <li>cd QuarkFspPkg</li>
+  <li>Use git to clone <a target="_blank" href="https://review.gerrithub.io/#/admin/projects/LeeLeahy/quarkfsp">QuarkFspPkg</a> into the QuarkFpsPkg directory (.)</li>
+</ol>
+
+<h3>Building QuarkFspPkg</h3>
+<p>
+There are two versions of FSP: FSP 1.1 and FSP 2.0.  There are also two
+different implementations of FSP, one using subroutines without SEC and
+PEI core and the original implementation which relies on SEC and PEI core.
+Finally there are two different build x86 types release (r32) and debug (d32).
+</p>
+<p>Note that the subroutine implementations are a <b>work in progress</b>.</p>
+<p>
+Build commands shown building debug FSP:
+</p>
+<ul>
+  <li>Linux:
+    <ul>
+      <li>QuarkFspPkg/BuildFsp1_1.sh  -d32</li>
+      <li>QuarkFspPkg/BuildFsp1_1Pei.sh  -d32</li>
+      <li>QuarkFspPkg/BuildFsp2_0.sh  -d32</li>
+      <li>QuarkFspPkg/BuildFsp2_0Pei.sh  -d32</li>
+    </ul>
+  <li>Windows:
+    <ul>
+      <li>QuarkFspPkg/BuildFsp1_1.bat  -d32</li>
+      <li>Windows: QuarkFspPkg/BuildFsp2_0.bat  -d32</li>
+    </ul>
+  </li>
+</ul>
+
+<h3>Copying FSP files into coreboot Source Tree</h3>
+<p>
+There are some helper scripts to copy the FSP output into the coreboot
+source tree.  The parameters to these scripts are:
+</p>
+<ol>
+  <li>EDK2 tree root</li>
+  <li>coreboot tree root</li>
+  <li>Build type: DEBUG or RELEASE</li>
+</ol>
+<p>
+Script files:
+</p>
+<ul>
+  <li>Linux:
+    <ul>
+      <li>QuarkFspPkg/coreboot_fsp1_1.sh</li>
+      <li>QuarkFspPkg/coreboot_fsp1_1Pei.sh</li>
+      <li>QuarkFspPkg/coreboot_fsp2_0.sh</li>
+      <li>QuarkFspPkg/coreboot_fsp2_0Pei.sh</li>
+    </ul>
+</ul>
+
+
+<hr>
+<h2>Quark&trade; EDK2 BIOS</h2>
+<p>
+Build Instructions:
+</p>
+<ol>
+  <li>Set up <a href="#BuildEnvironment">build environment</a></li>
+  <li>Build the image:
+    <ul>
+      <li>Linux:
+<pre><code>build -p QuarkPlatformPkg/Quark.dsc  -a IA32  -t GCC48  -b DEBUG  -DDEBUG_PROPERTY_MASK=0x27  -DDEBUG_PRINT_ERROR_LEVEL=0x80000042
+ls Build/Quark/DEBUG_GCC48/FV/Quark.fd
+</code></pre>
+      </li>
+      <li>Windows:
+<pre><code>build -p QuarkPlatformPkg/Quark.dsc  -a IA32  -t VS2012x86  -b DEBUG  -DDEBUG_PROPERTY_MASK=0x27  -DDEBUG_PRINT_ERROR_LEVEL=0x80000042
+dir Build\Quark\DEBUG_VS2012x86\FV\Quark.fd
+</code></pre>
+  </li>
+    </ul>
+  </li>
+</ol>
+
+<p>
+Documentation:
+</p>
+<ul>
+  <li><a target="_blank" href="https://github.com/tianocore/edk2/tree/master/QuarkPlatformPkg">EDK II firmware for Intel&reg; Quark&trade; SoC X1000 based platforms</a></li>
+  <li>Intel&reg; Quark&trade; SoC X1000 <a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/guides/quark-x1000-uefi-firmware-writers-guide.pdf">UEFI Firmware Writer's Guide</a></li>
+</ul>
+
+
+
+<hr>
+<p>Modified: 17 May 2016</p>
+  </body>
+</html>

Documentation/Intel/SoC/soc.html

@@ -0,0 +1,730 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>SoC</title>
+  </head>
+  <body>
+
+<h1>x86 System on a Chip (SoC) Development</h1>
+<p>
+  SoC development is best done in parallel with development for a specific
+  board.  The combined steps are listed
+  <a target="_blank" href="../development.html">here</a>.
+  The development steps for the SoC are listed below:
+</p>
+<ol>
+  <li><a target="_blank" href="../fsp1_1.html#RequiredFiles">FSP 1.1</a> required files</li>
+  <li>SoC <a href="#RequiredFiles">Required Files</a></li>
+  <li><a href="#Descriptor">Start Booting</a></li>
+  <li><a href="#EarlyDebug">Early Debug</a></li>
+  <li><a href="#Bootblock">Bootblock</a></li>
+  <li><a href="#TempRamInit">TempRamInit</a></li>
+  <li><a href="#Romstage">Romstage</a>
+    <ol type="A">
+      <li>Enable <a href="#SerialOutput">Serial Output"</a></li>
+      <li>Get the <a href="#PreviousSleepState">Previous Sleep State</a></li>
+      <li>Add the <a href="#MemoryInit">MemoryInit</a> Support</li>
+      <li>Disable the <a href="#DisableShadowRom">Shadow ROM</a></li>
+    </ol>
+  </li>
+  <li><a href="#Ramstage">Ramstage</a>
+    <ol type="A">
+      <li><a href="#DeviceTree">Start Device Tree Processing</a></li>
+      <li>Set up the <a href="#MemoryMap">Memory Map"</a></li>
+    </ol>
+  </li>
+  <li><a href="#AcpiTables">ACPI Tables</a></li>
+  <li><a href="#LegacyHardware">Legacy Hardware</a></li>
+</ol>
+
+
+<hr>
+<h2><a name="RequiredFiles">Required Files</a></h2>
+<p>
+  Create the directory as src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;.
+</p>
+
+<p>
+  The following files are required to build a new SoC:
+</p>
+<ul>
+  <li>Include files
+    <ul>
+      <li>include/soc/pei_data.h</li>
+      <li>include/soc/pm.h</li>
+    </ul>
+  </li>
+  <li>Kconfig - Defines the Kconfig value for the SoC and selects the tool
+    chains for the various stages:
+    <ul>
+      <li>select ARCH_BOOTBLOCK_&lt;Tool Chain&gt;</li>
+      <li>select ARCH_RAMSTAGE_&lt;Tool Chain&gt;</li>
+      <li>select ARCH_ROMSTAGE_&lt;Tool Chain&gt;</li>
+      <li>select ARCH_VERSTAGE_&lt;Tool Chain&gt;</li>
+    </ul>
+  </li>
+  <li>Makefile.inc - Specify the include paths</li>
+  <li>memmap.c - Top of usable RAM</li>
+</ul>
+
+
+<hr>
+<h2><a name="Descriptor">Start Booting</a></h2>
+<p>
+  Some SoC parts require additional firmware components in the flash.
+  This section describes how to add those pieces.
+</p>
+
+<h3>Intel Firmware Descriptor</h3>
+<p>
+  The Intel Firmware Descriptor (IFD) is located at the base of the flash part.
+  The following command overwrites the base of the flash image with the Intel
+  Firmware Descriptor:
+</p>
+<pre><code>dd if=descriptor.bin of=build/coreboot.rom conv=notrunc >/dev/null 2>&1</code></pre>
+
+
+<h3><a name="MEB">Management Engine Binary</a></h3>
+<p>
+  Some SoC parts contain and require that the Management Engine (ME) be running
+  before it is possible to bring the x86 processor out of reset.  A binary file
+  containing the management engine code must be added to the firmware using the
+  ifdtool.  The following commands add this binary blob:
+</p>
+<pre><code>util/ifdtool/ifdtool -i ME:me.bin  build/coreboot.rom
+mv build/coreboot.rom.new build/coreboot.rom
+</code></pre>
+
+
+<h3><a name="EarlyDebug">Early Debug</a></h3>
+<p>
+  Early debugging between the reset vector and the time the serial port is enabled
+  is most easily done by writing values to port 0x80.
+</p>
+
+
+<h3>Success</h3>
+<p>
+  When the reset vector is successfully invoked, port 0x80 will output the following value:
+</p>
+<ul>
+  <li>0x01: <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l45">POST_RESET_VECTOR_CORRECT</a>
+    - Bootblock successfully executed the
+    <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/16bit/reset16.inc;hb=HEAD#l4">reset vector</a>
+    and entered the 16-bit code at
+    <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/16bit/entry16.inc;hb=HEAD#l35">_start</a>
+  </li>
+</ul>
+
+
+<hr>
+<h2><a name="Bootblock">Bootblock</a></h2>
+<p>
+  Implement the bootblock using the following steps:
+</p>
+<ol>
+  <li>Create the directory as src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/bootblock</li>
+  <li>Add the timestamp.inc file which initializes the floating point registers and saves
+    the initial timestamp.
+  </li>
+  <li>Add the bootblock.c file which:
+    <ol type="A">
+      <li>Enables memory-mapped PCI config access</li>
+      <li>Updates the microcode by calling intel_update_microcode_from_cbfs</li>
+      <li>Enable ROM caching</li>
+    </ol>
+  </li>
+  <li>Edit the src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/Kconfig file
+    <ol type="A">
+      <li>Add the BOOTBLOCK_CPU_INIT value to point to the bootblock.c file</li>
+      <li>Add the CHIPSET_BOOTBLOCK_INCLUDE value to point to the timestamp.inc file</li>
+    </ol>
+  </li>
+  <li>Edit the src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/Makefile.inc file
+    <ol type="A">
+      <li>Add the bootblock subdirectory</li>
+    </ol>
+  </li>
+  <li>Edit the src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/memmap.c file
+    <ol type="A">
+      <li>Add the fsp/memmap.h include file</li>
+    </ol>
+  </li>
+  <li>Add the necessary .h files to define the necessary values and structures</li>
+  <li>When successful port 0x80 will output the following values:
+    <ol type="A">
+      <li>0x01: <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l45">POST_RESET_VECTOR_CORRECT</a>
+        - Bootblock successfully executed the
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/16bit/reset16.inc;hb=HEAD#l4">reset vector</a>
+        and entered the 16-bit code at
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/16bit/entry16.inc;hb=HEAD#l35">_start</a>
+      </li>
+      <li>0x10: <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l53">POST_ENTER_PROTECTED_MODE</a>
+        - Bootblock executing in
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/32bit/entry32.inc;hb=HEAD#l55">32-bit mode</a>
+      </li>
+      <li>0x10 - Verstage/romstage reached 32-bit mode</li>
+    </ol>
+  </li>
+</ol>
+
+<p>
+  <b>Build Note:</b> The following files are included into the default bootblock image:
+</p>
+<ul>
+  <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/bootblock_romcc.S;hb=HEAD">src/arch/x86/bootblock_romcc.S</a>
+    added by   <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/Makefile.inc;hb=HEAD#l133">src/arch/x86/Makefile.inc</a>
+    and includes the following files:
+    <ul>
+      <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/prologue.inc">src/arch/x86/prologue.inc</a></li>
+      <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/16bit/reset16.inc">src/cpu/x86/16bit/reset16.inc</a></li>
+      <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/16bit/entry16.inc">src/cpu/x86/16bit/entry16.inc</a></li>
+      <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/32bit/entry32.inc">src/cpu/x86/32bit/entry32.inc</a></li>
+      <li>The code in
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/bootblock_romcc.S">src/arch/x86/bootblock_romcc.S</a>
+        includes src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/bootblock/timestamp.inc using the
+        CONFIG_CHIPSET_BOOTBLOCK_INCLUDE value set above
+      </li>
+      <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/sse_enable.inc">src/cpu/x86/sse_enable.inc</a></li>
+      <li>The code in
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/Makefile.inc;hb=HEAD#l156">src/arch/x86/Makefile.inc</a>
+        invokes the ROMCC tool to convert the following "C" code into assembler as bootblock.inc:
+        <ul>
+          <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/include/arch/bootblock_romcc.h">src/arch/x86/include/arch/bootblock_romcc.h</a></li>
+          <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/x86/lapic/boot_cpu.c">src/cpu/x86/lapic/boot_cpu.c</a></li>
+          <li>The CONFIG_BOOTBLOCK_CPU_INIT value set above typically points to the code in
+            src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/bootblock/bootblock.c
+          </li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+  <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/id.S">src/arch/x86/id.S</a>
+    added by <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/Makefile.inc;hb=HEAD#l110">src/arch/x86/Makefile.inc</a>
+  </li>
+  <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/intel/fit/fit.S">src/cpu/intel/fit/fit.S</a>
+    added by <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/cpu/intel/fit/Makefile.inc;hb=HEAD">src/cpu/intel/fit/Makefile.inc</a>
+  </li>
+  <li><a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/walkcbfs.S">src/arch/x86/walkcbfs.S</a>
+    added by <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/Makefile.inc;hb=HEAD#l137">src/arch/x86/Makefile.inc</a>
+  </li>
+</ul>
+
+
+<hr>
+<h2><a name="TempRamInit">TempRamInit</a></h2>
+<p>
+  Enable the call to TempRamInit in two stages:
+</p>
+<ol>
+  <li>Finding the FSP binary in the read-only CBFS region</li>
+  <li>Call TempRamInit</li>
+</ol>
+
+
+<h3>Find FSP Binary</h3>
+<p>
+Use the following steps to locate the FSP binary:
+</p>
+<ol>
+  <li>Edit the src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/Kconfig file
+    <ol type="A">
+      <li>Add "select USE_GENERIC_FSP_CAR_INC" to enable the use of
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc">src/drivers/intel/fsp1_1/cache_as_ram.inc</a>
+      </li>
+      <li>Add "select SOC_INTEL_COMMON" to enable the use of the files from src/soc/intel/common
+      </li>
+    </ol>
+  </li>
+  <li>Debug the result until port 0x80 outputs
+    <ol type="A">
+      <li>0x90: <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l205">POST_FSP_TEMP_RAM_INIT</a>
+        - Just before calling
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l73">TempRamInit</a>
+      </li>
+      <li>Alternating 0xba and 0x01 - The FSP image was not found</li>
+    </ol>
+  </li>
+  <li>Add the <a target="_blank" href="../fsp1_1.html#FspBinary">FSP binary file</a> to the flash image</li>
+  <li>Set the following Kconfig values:
+    <ul>
+      <li>CONFIG_FSP_LOC to the FSP base address specified in the previous step</li>
+      <li>CONFIG_FSP_IMAGE_ID_STRING</li>
+    </ul>
+  </li>
+  <li>Debug the result until port 0x80 outputs
+    <ol type="A">
+      <li>0x90: <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l205">POST_FSP_TEMP_RAM_INIT</a>
+        - Just before calling
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l73">TempRamInit</a>
+      </li>
+      <li>Alternating 0xbb and 0x02 - TempRamInit executed, no CPU microcode update found</li>
+    </ol>
+  </li>
+</ol>
+
+
+<h3>Calling TempRamInit</h3>
+<p>
+Use the following steps to debug the call to TempRamInit:
+</p>
+<ol>
+  <li>Add the CPU microcode update file
+    <ol type="A">
+      <li>Add the microcode file with the following command
+<pre><code>util/cbfstool/cbfstool build/coreboot.rom add -t microcode -n cpu_microcode_blob.bin -b &lt;base address&gt; -f cpu_microcode_blob.bin</code></pre>
+      </li>
+      <li>Set the Kconfig values
+        <ul>
+          <li>CONFIG_CPU_MICROCODE_CBFS_LOC set to the value from the previous step</li>
+          <li>CONFIG_CPU_MICROCODE_CBFS_LEN</li>
+        </ul>
+      </li>
+    </ol>
+  </li>
+  <li>Debug the result until port 0x80 outputs
+    <ol type="A">
+      <li>0x90: <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l205">POST_FSP_TEMP_RAM_INIT</a>
+        - Just before calling
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l73">TempRamInit</a>
+      </li>
+      <li>0x2A - Just before calling
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l151">cache_as_ram_main</a>
+        which is the start of the verstage code which may be part of romstage
+      </li>
+    </ol>
+  </li>
+</ol>
+
+
+<hr>
+<h2><a name="Romstage">Romstage</a></h2>
+
+<h3><a name="SerialOutput">Serial Output</a></h3>
+<p>
+  The following steps add the serial output support for romstage:
+</p>
+<ol>
+  <li>Create the romstage subdirectory</li>
+  <li>Add romstage/romstage.c
+    <ol type="A">
+      <li>Program the necessary base addresses</li>
+      <li>Disable the TCO</li>
+    </ol>
+  </li>
+  <li>Add romstage/Makefile.inc
+    <ol type="A">
+      <li>Add romstage.c to romstage</li>
+    </ol>
+  </li>
+  <li>Add gpio configuration support if necessary</li>
+  <li>Add the necessary .h files to support the build</li>
+  <li>Update Makefile.inc
+    <ol type="A">
+      <li>Add the romstage subdirectory</li>
+      <li>Add the gpio configuration support file to romstage</li>
+    </ol>
+  </li>
+  <li>Set the necessary Kconfig values to enable serial output:
+    <ul>
+      <li>CONFIG_DRIVERS_UART_&lt;driver&gt;=y</li>
+      <li>CONFIG_CONSOLE_SERIAL=y</li>
+      <li>CONFIG_UART_FOR_CONSOLE=&lt;port&gt;</li>
+      <li>CONFIG_CONSOLE_SERIAL_115200=y</li>
+    </ul>
+  </li>
+</ol>
+
+
+<h3><a name="PreviousSleepState">Determine Previous Sleep State</a></h3>
+<p>
+  The following steps implement the code to get the previous sleep state:
+</p>
+<ol>
+  <li>Implement the fill_power_state routine which determines the previous sleep state</li>
+  <li>Debug the result until port 0x80 outputs
+    <ol type="A">
+      <li>0x32:
+        - Just after entering
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/romstage.c;hb=HEAD#l99">romstage_common</a>
+      </li>
+      <li>0x33 - Just after calling
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/romstage.c;hb=HEAD#l113">soc_pre_ram_init</a>
+      </li>
+      <li>0x34:
+        - Just after entering
+        <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/raminit.c;hb=HEAD#l67">raminit</a>
+      </li>
+    </ol>
+</ol>
+
+
+<h3><a name="MemoryInit">MemoryInit Support</a></h3>
+<p>
+  The following steps implement the code to support the FSP MemoryInit call:
+</p>
+<ol>
+  <li>Add the chip.h header file to define the UPD values which get passed
+    to MemoryInit.  Skip the values containing SPD addresses and DRAM
+    configuration data which is determined by the board.
+    <p>
+      <b>Build Note</b>: The src/mainboard/&lt;Vendor&gt;/&lt;Board&gt;/devicetree.cb
+      file specifies the default values for these parameters.  The build
+      process creates the static.c module which contains the config data
+      structure containing these values.
+    </p>
+  </li>
+  <li>Edit romstage/romstage.c
+    <ol type="A">
+      <li>Implement the romstage/romstage.c/soc_memory_init_params routine to
+        copy the values from the config structure into the UPD structure
+      </li>
+      <li>Implement the soc_display_memory_init_params routine to display
+        the updated UPD parameters by calling fsp_display_upd_value
+      </li>
+    </ol>
+  </li>
+</ol>
+
+
+<h3><a name="DisableShadowRom">Disable Shadow ROM</a></h3>
+<p>
+  A shadow of the SPI flash part is mapped from 0x000e0000 to 0x000fffff.
+  This shadow needs to be disabled to allow RAM to properly respond to
+  this address range.
+</p>
+<ol>
+  <li>Edit romstage/romstage.c and add the soc_after_ram_init routine</li>
+</ol>
+
+
+<hr>
+<h2><a name="Ramstage">Ramstage</a></h2>
+
+<h3><a name="DeviceTree">Start Device Tree Processing</a></h3>
+<p>
+  The src/mainboard/&lt;Vendor&gt;/&lt;Board&gt;/devicetree.cb file drives the
+  execution during ramstage.  This file is processed by the util/sconfig utility
+  to generate build/mainboard/&lt;Vendor&gt;/&lt;Board&gt;/static.c.  The various
+  state routines in
+  src/lib/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/lib/hardwaremain.c;hb=HEAD#l128">hardwaremain.c</a>
+  call dev_* routines which use the tables in static.c to locate operation tables
+  associated with the various chips and devices.  After location the operation
+  tables, the state routines call one or more functions depending upon the
+  state of the state machine.
+</p>
+
+<h4><a name="ChipOperations">Chip Operations</a></h4>
+<p>
+  Kick-starting the ramstage state machine requires creating the operation table
+  for the chip listed in devicetree.cb:
+</p>
+<ol>
+  <li>Edit src/soc/&lt;SoC Vendor&gt;/&lt;SoC Family&gt;/chip.c:
+    <ol type="A">
+      <li>
+        This chip's operation table has the name
+        soc_&lt;SoC Vendor&gt;_&lt;SoC Family&gt;_ops which is derived from the
+        chip path specified in the devicetree.cb file.
+      </li>
+      <li>Use the CHIP_NAME macro to specify the name for the chip</li>
+      <li>For FSP 1.1, specify a .init routine which calls intel_silicon_init</li>
+    </ol>
+  </li>
+  <li>Edit src/soc/&lt;SoC Vendor&gt;/&lt;SoC Family&gt;/Makefile.inc and add chip.c to ramstage</li>
+</ol>
+
+<h4>Domain Operations</h4>
+<p>
+  coreboot uses the domain operation table to initiate operations on all of the
+  devices in the domain.  By default coreboot enables all PCI devices which it
+  finds.  Listing a device in devicetree.cb gives the board vendor control over
+  the device state.  Non-PCI devices may also be listed under PCI device such as
+  the LPC bus or SMbus devices.
+</p>
+<ol>
+  <li>Edit src/soc/&lt;SoC Vendor&gt;/&lt;SoC Family&gt;/chip.c:
+    <ol type="A">
+      <li>
+        The domain operation table is typically placed in
+        src/soc/&lt;SoC Vendor&gt;/&lt;SoC Family&gt;/chip.c.
+        The table typically looks like the following:
+<pre><code>static struct device_operations pci_domain_ops = {
+	.read_resources	= pci_domain_read_resources,
+	.set_resources	= pci_domain_set_resources,
+	.scan_bus	= pci_domain_scan_bus,
+};
+</code></pre>
+      </li>
+      <li>
+        Create a .enable_dev entry in the chip operations table which points to a
+        routine which sets the domain table for the device with the DEVICE_PATH_DOMAIN.
+<pre><code>	if (dev->path.type == DEVICE_PATH_DOMAIN) {
+		dev->ops = &pci_domain_ops;
+	}
+</code></pre>
+      </li>
+      <li>
+        During the BS_DEV_ENUMERATE state, ramstage now display the device IDs
+        for the PCI devices on the bus.
+      </li>
+    </ol>
+  </li>
+  <li>Set CONFIG_DEBUG_BOOT_STATE=y in the .config file</li>
+  <li>
+    Debug the result until the PCI vendor and device IDs are displayed
+    during the BS_DEV_ENUMERATE state.
+  </li>
+</ol>
+
+
+<h3><a name="DeviceDrivers">PCI Device Drivers</a></h3>
+<p>
+  PCI device drivers consist of a ".c" file which contains a "pci_driver" data
+  structure at the end of the file with the attribute tag "__pci_driver".  This
+  attribute tag places an entry into a link time table listing the various
+  coreboot device drivers.
+</p>
+<p>
+  Specify the following fields in the table:
+</p>
+<ol>
+  <li>.vendor - PCI vendor ID value of the device</li>
+  <li>.device - PCI device ID value of the device or<br>
+  .devices - Address of a zero terminated array of PCI device IDs
+  </li>
+  <li>.ops - Operations table for the device.  This is the address
+    of a "static struct device_operations" data structure specifying
+    the routines to execute during the different states and sub-states
+    of ramstage's processing.
+  </li>
+  <li>Turn on the device in mainboard/&lt;Vendor&gt;/&lt;Board&gt;/devicetree.cb</li>
+  <li>
+    Debug until the device is on and properly configured in coreboot and
+    usable by the payload
+  </li>
+</ol>
+
+<h4><a name="SubsystemIds">Subsystem IDs</a></h4>
+<p>
+  PCI subsystem IDs are assigned during the BS_DEV_ENABLE state.  The device
+  driver may use the common mechanism to assign subsystem IDs by adding
+  the ".ops_pci" to the pci_driver data structure.  This field points to
+  a "struct pci_operations" that specifies a routine to set the subsystem
+  IDs for the device.  The routine might look something like this:
+</p>
+<pre><code>static void pci_set_subsystem(struct device *dev, unsigned vendor, unsigned device)
+{
+	if (!vendor || !device) {
+		vendor = pci_read_config32(dev, PCI_VENDOR_ID);
+		device = vendor >> 16;
+	}
+	printk(BIOS_SPEW,
+		"PCI: %02x:%02x:%d subsystem vendor: 0x%04x, device: 0x%04x\n",
+		0, PCI_SLOT(dev->path.pci.devfn), PCI_FUNC(dev->path.pci.devfn),
+		vendor & 0xffff, device);
+	pci_write_config32(dev, PCI_SUBSYSTEM_VENDOR_ID,
+			((device & 0xffff) << 16) | (vendor & 0xffff));
+}
+</code></pre>
+
+
+
+<h3>Set up the <a name="MemoryMap">Memory Map</a></h3>
+<p>
+  The memory map is built by the various PCI device drivers during the
+  BS_DEV_RESOURCES state of ramstage.  The northcluster driver will typically
+  specify the DRAM resources while the other drivers will typically specify
+  the IO resources.  These resources are hung off the struct device *data structure by
+  src/device/device_util.c/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/device/device_util.c;hb=HEAD#l448">new_resource</a>.
+</p>
+<p>
+  During the BS_WRITE_TABLES state, coreboot collects these resources and
+  places them into a data structure identified by LB_MEM_TABLE.
+</p>
+<p>
+  Edit the device driver file:
+</p>
+<ol>
+  <li>
+    Implement a read_resources routine which calls macros defined in
+    src/include/device/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/device/device.h;hb=HEAD#l237">device.h</a>
+    like:
+    <ul>
+      <li>ram_resource</li>
+      <li>reserved_ram_resource</li>
+      <li>bad_ram_resource</li>
+      <li>uma_resource</li>
+      <li>mmio_resource</li>
+    </ul>
+  </li>
+</ol>
+
+<p>
+  Testing: Verify that the resources are properly displayed by coreboot during the BS_WRITE_TABLES state.
+</p>
+
+
+
+<hr>
+<h2><a name="AcpiTables">ACPI Tables</a></h2>
+<p>
+  One of the payloads that needs ACPI tables is the EDK2 <a target="_blank" href="quark.html#CorebootPayloadPkg">CorebootPayloadPkg</a>.
+</p>
+
+<h3>FADT</h3>
+<p>
+  The EDK2 module
+  CorebootModulePkg/Library/CbParseLib/<a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootModulePkg/Library/CbParseLib/CbParseLib.c#l450">CbParseLib.c</a>
+  requires that the FADT contains the values in the table below.
+  These values are placed into a HOB identified by
+  <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootModulePkg/CorebootModulePkg.dec#l36">gUefiAcpiBoardInfoGuid</a>
+  by routine
+  CorebootModulePkg/CbSupportPei/CbSupportPei/<a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootModulePkg/CbSupportPei/CbSupportPei.c#l364">CbPeiEntryPoint</a>.
+</p>
+<table border="1">
+  <tr bgcolor="#c0ffc0">
+    <td>coreboot Field</td>
+    <td>EDK2 Field</td>
+    <td>gUefiAcpiBoardInfoGuid</td>
+    <td>Use</li>
+    <td>
+      <a target="_blank" href="http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf">ACPI Spec.</a>
+      Section
+    </td>
+  </tr>
+  <tr>
+    <td>gpe0_blk<br>gpe0_blk_len</td>
+    <td>Gpe0Blk<br>Gpe0BlkLen</td>
+    <td>
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootModulePkg/Library/CbParseLib/CbParseLib.c#l477">PmGpeEnBase</a>
+    </td>
+    <td><a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l129">Shutdown</a></td>
+    <td>4.8.4.1</td>
+  </tr>
+  <tr>
+    <td>pm1a_cnt_blk</td>
+    <td>Pm1aCntBlk</td>
+    <td>PmCtrlRegBase</td>
+    <td>
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l139">Shutdown</a><br>
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l40">Suspend</a>
+    </td>
+    <td>4.8.3.2.1</td>
+  </tr>
+  <tr>
+    <td>pm1a_evt_blk</td>
+    <td>Pm1aEvtBlk</td>
+    <td>PmEvtBase</td>
+    <td><a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l134">Shutdown</a></td>
+    <td>4.8.3.1.1</td>
+  </tr>
+  <tr>
+    <td>pm_tmr_blk</td>
+    <td>PmTmrBlk</td>
+    <td>PmTimerRegBase</td>
+    <td>
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/AcpiTimerLib/AcpiTimerLib.c#l55">Timer</a>
+    </td>
+    <td>4.8.3.3</td>
+  </tr>
+  <tr>
+    <td>reset_reg.</td>
+    <td>ResetReg.Address</td>
+    <td>ResetRegAddress</td>
+    <td>
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l71">Cold</a>
+      and
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l98">Warm</a>
+      resets
+    </td>
+    <td>4.3.3.6</td>
+  </tr>
+  <tr>
+    <td>reset_value</td>
+    <td>ResetValue</td>
+    <td>ResetValue</td>
+    <td>
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l71">Cold</a>
+      and
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/CorebootPayloadPkg/Library/ResetSystemLib/ResetSystemLib.c#l98">Warm</a>
+      resets
+    </td>
+    <td>4.8.3.6</td>
+  </tr>
+</table>
+<p>
+  The EDK2 data structure is defined in
+  MdeModulePkg/Include/IndustryStandard/<a target="_blank" href="https://github.com/tianocore/edk2/blob/master/MdePkg/Include/IndustryStandard/Acpi61.h#l111">Acpi61.h</a>
+  The coreboot data structure is defined in
+  src/arch/x86/include/arch/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/arch/x86/include/acpi/acpi.h;hb=HEAD#l237">acpi.h</a>
+</p>
+
+<ol>
+  <li>
+    Select <a target="_blank" href="../Board/board.html#AcpiTables">HAVE_ACPI_TABLES</a>
+    in the board's Kconfig file
+  </li>
+  <li>Create a acpi.c module:
+    <ol type="A">
+      <li>Add the acpi_fill_fadt routine and initialize the values above</li>
+    </ol>
+  </li>
+</ol>
+
+
+
+<hr>
+<h2><a name="LegacyHardware">Legacy Hardware</a></h2>
+<p>
+  One of the payloads that needs legacy hardare is the EDK2 <a target="_blank" href="quark.html#CorebootPayloadPkg">CorebootPayloadPkg</a>.
+</p>
+
+<table border="1">
+  <tr bgcolor="c0ffc0">
+    <th>Peripheral</th>
+    <th>Use</th>
+    <th>8259 Interrupt Vector</th>
+    <th>IDT Base Offset</th>
+    <th>Interrupt Handler</th>
+  </tr>
+  <tr>
+    <td>
+      <a target="_blank" href="http://www.scs.stanford.edu/10wi-cs140/pintos/specs/8254.pdf">8254</a>
+      Programmable Interval Timer
+    </td>
+    <td>
+      EDK2: PcAtChipsetPkg/8254TimerDxe/<a target="_blank" href="https://github.com/tianocore/edk2/blob/master/PcAtChipsetPkg/8254TimerDxe/Timer.c">Timer.c</a>
+    </td>
+    <td>0</td>
+    <td>0x340</td>
+    <td>
+      <a target="_blank" href="https://github.com/tianocore/edk2/blob/master/PcAtChipsetPkg/8254TimerDxe/Timer.c#l71">TimerInterruptHandler</a>
+    </td>
+  </tr>
+  <tr>
+    <td>
+      <a target="_blank" href="https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwibxYKU3ZDLAhVOzWMKHfuqB40QFggcMAA&url=http%3A%2F%2Fbochs.sourceforge.net%2Ftechspec%2Fintel-8259a-pic.pdf.gz&usg=AFQjCNF1NT0OQ6ys1Pn6Iv9sv6cKRzZbGg&sig2=HfBszp9xTVO_fajjPWCsJw">8259</a>
+      Programmable Interrupt Controller
+    </td>
+    <td>
+      EDK2: PcAtChipsetPkg/8259InterruptControllerDxe/<a target="_blank" href="https://github.com/tianocore/edk2/blob/master/PcAtChipsetPkg/8259InterruptControllerDxe/8259.c">8259.c</a>
+    </td>
+    <td>
+      Master interrupts: 0, 2 - 7<br>
+      Slave interrupts: 8 - 15<br>
+      Interrupt vector 1 is never generated, the cascaded input generates interrupts 8 - 15
+    </td>
+    <td>
+      Master: 0x340, 0x350 - 0x378<br>
+      Slave: 0x380 - 0x3b8<br>
+      Interrupt descriptors are 8 bytes each
+    </td>
+    <td>&nbsp;</td>
+  </tr>
+</table>
+
+<hr>
+<p>Modified: 4 March 2016</p>
+  </body>
+</html>

Documentation/Intel/development.html

@@ -0,0 +1,377 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Development</title>
+  </head>
+  <body>
+
+<h1>Intel&reg; x86 coreboot/FSP Development Process</h1>
+<p>
+  The x86 development process for coreboot is broken into the following components:
+</p>
+<ul>
+  <li>coreboot <a target="_blank" href="SoC/soc.html">SoC</a> development</li>
+  <li>coreboot <a target="_blank" href="Board/board.html">mainboard</a> development</li>
+  <li><a target="_blank" href="fsp1_1.html">FSP 1.1</a> integration</li>
+</ul>
+<p>
+  The development process has two main phases:
+</p>
+<ol>
+  <li>Minimal coreboot; This phase is single threaded</li>
+  <li>Adding coreboot features</li>
+</ol>
+
+<h2>Minimal coreboot</h2>
+<p>
+  The combined steps below describe how to bring up a minimal coreboot for a
+  system-on-a-chip (SoC) and a development board:
+</p>
+<table>
+  <tr bgcolor="#ffffc0">
+    <td>The initial coreboot steps are single threaded!
+      The initial minimal FSP development is also single threaded.
+      Progress can speed up by adding more developers after the minimal coreboot/FSP
+      implementation reaches the payload.
+    </td>
+  </tr>
+</table>
+<ol>
+  <li>Get the necessary tools:
+    <ul>
+      <li>Linux: Use your package manager to install m4 bison flex and the libcurses development
+        package.
+        <ul>
+          <li>Ubuntu or other Linux distribution that use apt, run:
+<pre><code>sudo apt-get install m4 bison flex libncurses5-dev
+</code></pre>
+          </li>
+        </ul>
+      </li>
+    </ul>
+  </li>
+  <li>Build the cross tools for i386:
+    <ul>
+      <li>Linux:
+<pre><code>make crossgcc-i386</code></pre>
+        To use multiple processors for the toolchain build (which takes a long time), use:
+<pre><code>make crossgcc-i386 CPUS=N</code></pre>
+        where N is the number of cores to use for the build.
+      </li>
+    </ul>
+  </li>
+  <li>Get something to build:
+    <ol type="A">
+      <li><a target="_blank" href="fsp1_1.html#RequiredFiles">FSP 1.1</a> required files</li>
+      <li><a target="_blank" href="SoC/soc.html#RequiredFiles">SoC</a> required files</li>
+      <li><a target="_blank" href="Board/board.html#RequiredFiles">Board</a> required files</li>
+    </ol>
+  </li>
+  <li>Get result to start <a target="_blank" href="SoC/soc.html#Descriptor">booting</a></li>
+  <li><a target="_blank" href="SoC/soc.html#EarlyDebug">Early Debug</a></li>
+  <li>Implement and debug the <a target="_blank" href="SoC/soc.html#Bootblock">bootblock</a> code</li>
+  <li>Implement and debug the call to <a target="_blank" href="SoC/soc.html#TempRamInit">TempRamInit</a></li>
+  <li>Enable the serial port
+    <ol type="A">
+      <li>Power on, enable and configure GPIOs for the
+        <a target="_blank" href="Board/board.html#SerialOutput">debug serial UART</a>
+      </li>
+      <li>Add the <a target="_blank" href="SoC/soc.html#SerialOutput">serial outupt</a>
+        support to romstage
+      </li>
+    </ol>
+  </li>
+  <li>Enable <a target="_blank" href="fsp1_1.html#corebootFspDebugging">coreboot/FSP</a> debugging</li>
+  <li>Determine the <a target="_blank" href="SoC/soc.html#PreviousSleepState">Previous Sleep State</a></li>
+  <li>Enable DRAM:
+    <ol type="A">
+      <li>Implement the SoC
+        <a target="_blank" href="SoC/soc.html#MemoryInit">MemoryInit</a>
+        Support
+      </li>
+      <li>Implement the board support to read the
+        <a target="_blank" href="Board/board.html#SpdData">Memory Timing Data</a>
+      </li>
+    </ol>
+  </li>
+  <li>Disable the
+    <a target="_blank" href="SoC/soc.html#DisableShadowRom">Shadow ROM</a>
+  </li>
+  <li>Enable CONFIG_DISPLAY_MTRRS to verify the MTRR configuration</li>
+  <li>
+    Implement the .init routine for the
+    <a target="_blank" href="SoC/soc.html#ChipOperations">chip operations</a>
+    structure which calls FSP SiliconInit
+  </li>
+  <li>
+    Start ramstage's
+    <a target="_blank" href="SoC/soc.html#DeviceTree">device tree processing</a>
+    to display the PCI vendor and device IDs
+  </li>
+  <li>
+    Disable the
+    <a target="_blank" href="Board/board.html#DisablePciDevices">PCI devices</a>
+  </li>
+  <li>
+    Implement the
+    <a target="_blank" href="SoC/soc.html#MemoryMap">memory map</a>
+  </li>
+  <li>coreboot should now attempt to load the payload</li>
+</ol>
+
+
+
+<h2>Add coreboot Features</h2>
+<p>
+  Most of the coreboot development gets done in this phase.  Implementation tasks in this
+  phase are easily done in parallel.
+</p>
+<ul>
+  <li>Payload and OS Features:
+    <ul>
+      <li><a target="_blank" href="SoC/soc.html#AcpiTables">ACPI Tables</a></li>
+      <li><a target="_blank" href="SoC/soc.html#LegacyHardware">Legacy hardware</a> support</li>
+    </ul>
+  </li>
+</ul>
+
+
+
+<hr>
+<table border="1">
+  <tr bgcolor="#c0ffc0">
+    <th colspan=3><h1>Features</h1></th>
+  </tr>
+  <tr bgcolor="#c0ffc0">
+    <th>SoC</th>
+    <th>Where</th>
+    <th>Testing</th>
+  </tr>
+  <tr>
+    <td>8254 Programmable Interval Timer</td>
+    <td><a target="_blank" href="SoC/soc.html#LegacyHardware">Legacy hardware</a> support</td>
+    <td><a target="_blank" href="SoC/quark.html#CorebootPayloadPkg">CorebootPayloadPkg</a> gets to shell prompt</td>
+  </tr>
+  <tr>
+    <td>8259 Programmable Interrupt Controller</td>
+    <td><a target="_blank" href="SoC/soc.html#LegacyHardware">Legacy hardware</a> support</td>
+    <td><a target="_blank" href="SoC/quark.html#CorebootPayloadPkg">CorebootPayloadPkg</a> gets to shell prompt</td>
+  </tr>
+  <tr>
+    <td>Cache-as-RAM</td>
+    <td>
+      <a target="_blank" href="SoC/soc.html#TempRamInit">Find</a>
+      FSP binary:
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l38">cache_as_ram.inc</a><br>
+      Enable: FSP 1.1 <a target="_blank" href="SoC/soc.html#TempRamInit">TempRamInit</a>
+      called from
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l73">cache_as_ram.inc</a><br>
+      Disable: FSP 1.1 TempRamExit called from
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/after_raminit.S;hb=HEAD#l41">after_raminit.S</a><br>
+    </td>
+    <td>FindFSP: POST code 0x90
+      (<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l205">POST_FSP_TEMP_RAM_INIT</a>)
+      is displayed<br>
+      Enable: POST code
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l151">0x2A</a>
+      is displayed<br>
+      Disable: CONFIG_DISPLAY_MTRRS=y, MTRRs displayed after call to TempRamExit
+    </td>
+  </tr>
+  <tr>
+    <td>Memory Map</td>
+    <td>
+      Implement a device driver for the
+      <a target="_blank" href="SoC/soc.html#MemoryMap">north cluster</a>
+    </td>
+    <td>coreboot displays the memory map correctly during the BS_WRITE_TABLES state</td>
+  </tr>
+  <tr>
+    <td>MTRRs</td>
+    <td>
+      Set values: src/drivers/intel/fsp1_1/stack.c/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/stack.c;hb=HEAD#l42">setup_stack_and_mtrrs</a><br>
+      Load values: src/drivers/intel/fsp1_1/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/after_raminit.S;hb=HEAD#l71">after_raminit.S</a>
+    </td>
+    <td>Set: Post code 0x91
+      (<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l213">POST_FSP_TEMP_RAM_EXIT</a>)
+      is displayed by
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/after_raminit.S;hb=HEAD#l41">after_raminit.S</a><br>
+      Load: Post code 0x3C is displayed by
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/after_raminit.S;hb=HEAD#l152">after_raminit.S</a><br>
+      and CONFIG_DISPLAY_MTRRS=y displays the correct memory regions</td>
+  </tr>
+  <tr>
+    <td>PCI Device Support</td>
+    <td>Implement a PCI <a target="_blank" href="SoC/soc.html#DeviceDrivers">device driver</a></td>
+    <td>The device is detected by coreboot and usable by the payload</td>
+  </tr>
+  <tr>
+    <td>Ramstage state machine</td>
+    <td>
+      Implement the chip and domain operations to start the
+      <a target="_blank" href="SoC/soc.html#DeviceTree">device tree</a>
+      processing
+    </td>
+    <td>
+      During the BS_DEV_ENUMERATE state, ramstage now display the device IDs
+      for the PCI devices on the bus.
+    </td>
+  </tr>
+  <tr>
+    <td>ROM Shadow<br>0x000E0000 - 0x000FFFFF</td>
+    <td>
+      Disable: src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;/romstage/romstage.c/<a target="_blank" href="SoC/soc.html#DisableShadowRom">soc_after_ram_init routine</a>
+    </td>
+    <td>Operates as RAM: Writes followed by a read to the 0x000E0000 - 0x000FFFFF region returns the value written</td>
+  </tr>
+
+
+  <tr bgcolor="#c0ffc0">
+    <th>Board</th>
+    <th>Where</th>
+    <th>Testing</th>
+  </tr>
+  <tr>
+    <td>Device Tree</td>
+    <td>
+      <a target="_blank" href="SoC/soc.html#DeviceTree">List</a> PCI vendor and device IDs by starting
+      the device tree processing<br>
+      <a target="_blank" href="Board/board.html#DisablePciDevices">Disable</a> PCI devices<br>
+      Enable: Implement a PCI <a target="_blank" href="SoC/soc.html#DeviceDrivers">device driver</a>
+    <td>
+      List: BS_DEV_ENUMERATE state displays PCI vendor and device IDs<br>
+      Disable: BS_DEV_ENUMERATE state shows the devices as disabled<br>
+      Enable: BS_DEV_ENUMERATE state shows the device as on and the device works for the payload
+    </td>
+  </tr>
+  <tr>
+    <td>DRAM</td>
+    <td>
+      Load SPD data: src/soc/mainboard/&lt;Vendor&gt;/&lt;Board&gt;/spd/<a target="_blank" href="Board/board.html#SpdData">spd.c</a><br>
+      UPD Setup:
+      <ul>
+        <li>src/soc&lt;Vendor&gt;//&lt;Chip Family&gt;/romstage/<a target="_blank" href="SoC/soc.html#MemoryInit">romstage.c</a></li>
+        <li>src/mainboard/&lt;Vendor&gt;/&lt;Board&gt;/<a target="_blank" href="Board/board.html#SpdData">romstage.c</a></li>
+      </ul>
+      FSP 1.1 MemoryInit called from src/drivers/intel/fsp1_1/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/raminit.c;hb=HEAD#l126">raminit.c</a>
+    </td>
+    <td>Select the following Kconfig values
+      <ul>
+        <li>DISPLAY_HOBS</li>
+        <li>DISPLAY_UPD_DATA</li>
+      </ul>
+      Testing successful if:
+      <ul>
+        <li>MemoryInit UPD values are correct</li>
+        <li>MemoryInit returns 0 (success) and</li>
+        <li>The message "ERROR - coreboot's requirements not met by FSP binary!"
+          is not displayed
+        </li>
+      </ul>
+    </td>
+  </tr>
+  <tr>
+    <td>Serial Port</td>
+    <td>
+      SoC <a target="_blank" href="SoC/soc.html#SerialOutput">Support</a><br>
+      Enable: src/soc/mainboard/&lt;Board&gt;/com_init.c/<a target="_blank" href="Board/board.html#SerialOutput">car_mainboard_pre_console_init</a>
+    </td>
+    <td>Debug serial output works</td>
+  </tr>
+
+
+  <tr bgcolor="#c0ffc0">
+    <th>Payload</th>
+    <th>Where</th>
+    <th>Testing</th>
+  </tr>
+  <tr>
+    <td>ACPI Tables</td>
+    <td>
+      SoC <a target="_blank" href="SoC/soc.html#AcpiTables">Support</a><br>
+    </td>
+    <td>Verified by payload or OS</td>
+  </tr>
+
+
+  <tr bgcolor="#c0ffc0">
+    <th>FSP</th>
+    <th>Where</th>
+    <th>Testing</th>
+  </tr>
+  <tr>
+    <td>TempRamInit</td>
+    <td>FSP <a target="_blank" href="SoC/soc.html#TempRamInit">TempRamInit</a></td>
+    <td>FSP binary found: POST code 0x90
+      (<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l205">POST_FSP_TEMP_RAM_INIT</a>)
+      is displayed<br>
+      TempRamInit successful: POST code
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/cache_as_ram.inc;hb=HEAD#l151">0x2A</a>
+      is displayed<br>
+    </td>
+  </tr>
+  <tr>
+    <td>MemoryInit</td>
+    <td><a target="_blank" href="SoC/soc.html#MemoryInit">SoC</a> support<br>
+      <a target="_blank" href="Board/board.html#SpdData">Board</a> support<br>
+    </td>
+    <td>Select the following Kconfig values
+      <ul>
+        <li>DISPLAY_HOBS</li>
+        <li>DISPLAY_UPD_DATA</li>
+      </ul>
+      Testing successful if:
+      <ul>
+        <li>MemoryInit UPD values are correct</li>
+        <li>MemoryInit returns 0 (success) and</li>
+        <li>The message "ERROR - coreboot's requirements not met by FSP binary!"
+          is not displayed
+        </li>
+      </ul>
+    </td>
+  </tr>
+  <tr>
+    <td>TempRamExit</td>
+    <td>src/drivers/intel/fsp1_1/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/after_raminit.S;hb=HEAD#l51">after_raminit.S</a></td>
+    <td>Post code 0x91
+      (<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/include/console/post_codes.h;hb=HEAD#l212">POST_FSP_TEMP_RAM_EXIT</a>)
+      is displayed before calling TempRamExit by
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/after_raminit.S;hb=HEAD#l141">after_raminit.S</a>,
+      CONFIG_DISPLAY_MTRRS=y displays the correct memory regions and
+      Post code 0x39 is displayed by
+      <a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/after_raminit.S;hb=HEAD#l141">after_raminit.S</a><br>
+    </td>
+  </tr>
+  <tr>
+    <td>SiliconInit</td>
+    <td>
+      Implement the .init routine for the
+      <a target="_blank" href="SoC/soc.html#ChipOperations">chip operations</a> structure
+    </td>
+    <td>During BS_DEV_INIT_CHIPS state, SiliconInit gets called and returns 0x00000000</td>
+  </tr>
+  <tr>
+    <td>FspNotify</td>
+    <td>
+      The code which calls FspNotify is located in
+      src/drivers/intel/fsp1_1/<a target="_blank" href="https://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/drivers/intel/fsp1_1/fsp_util.c;hb=HEAD#l182">fsp_util.c</a>.
+      The fsp_notify_boot_state_callback routine is called three times as specified
+      by the BOOT_STATE_INIT_ENTRY macros below the routine.
+    </td>
+    <td>
+      The FspNotify routines are called during:
+      <ul>
+        <li>BS_DEV_RESOURCES - on exit</li>
+        <li>BS_PAYLOAD_LOAD - on exit</li>
+        <li>BS_OS_RESUME - on entry (S3 resume)</li>
+      </ul>
+    </td>
+  </tr>
+</table>
+
+
+
+<hr>
+<p>Modified: 4 March 2016</p>
+  </body>
+</html>

Documentation/Intel/fsp1_1.html

@@ -0,0 +1,79 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>FSP 1.1</title>
+  </head>
+  <body>
+
+<h1>FSP 1.1</h1>
+
+<h2>x86 FSP 1.1 Integration</h2>
+<p>
+  Firmware Support Package (FSP) integration requires System-on-a-Chip (SoC)
+  and board support.  The combined steps are listed
+  <a target="_blank" href="development.html">here</a>.
+  The development steps for FSP are listed below:
+</p>
+<ol>
+  <li><a href="#RequiredFiles">Required Files</a></li>
+  <li>Add the <a href="#FspBinary">FSP Binary File</a> to the coreboot File System</li>
+  <li>Enable <a href="#corebootFspDebugging">coreboot/FSP Debugging</a></li>
+</ol>
+
+<p>
+  FSP Documentation:
+</p>
+<ul>
+  <li>Intel&reg; Firmware Support Package External Architecture Specification <a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf">V1.1</a></li>
+</ul>
+
+<hr>
+<h2><a name="RequiredFiles">Required Files</a></h2>
+<h3><a name="corebootRequiredFiles">coreboot Required Files</a></h3>
+<ol>
+  <li>Create the following directories if they do not already exist:
+    <ul>
+      <li>src/vendorcode/intel/fsp/fsp1_1/&lt;Chip Family&gt;</li>
+      <li>3rdparty/blobs/mainboard/&lt;Board Vendor&gt;/&lt;Board Name&gt;</li>
+    </ul>
+  </li>
+  <li>
+    The following files may need to be copied from the FSP build or release into the
+    directories above if they are not present or are out of date:
+    <ul>
+      <li>FspUpdVpd.h: src/vendorcode/intel/fsp/fsp1_1/&lt;Chip Family&gt;/FspUpdVpd.h</li>
+      <li>FSP.bin: 3rdparty/blobs/mainboard/&lt;Board Vendor&gt;/&lt;Board Name&gt;/fsp.bin</li>
+    </ul>
+  </li>
+</ol>
+
+
+<hr>
+<h2><a name="FspBinary">Add the FSP Binary File to coreboot File System</a></h2>
+<p>
+  Add the FSP binary to the coreboot flash image using the following command:
+</p>
+<pre><code>util/cbfstool/cbfstool build/coreboot.rom add -t fsp -n fsp.bin -b &lt;base address&gt; -f fsp.bin</code></pre>
+<p>
+  This command relocates the FSP binary to the 4K byte aligned location in CBFS so that the
+  FSP code for TempRamInit may be executed in place.
+</p>
+
+
+<hr>
+<h2><a name="corebootFspDebugging">Enable coreboot/FSP Debugging</a></h2>
+<p>
+  Set the following Kconfig values:
+</p>
+<ul>
+  <li>CONFIG_DISPLAY_FSP_ENTRY_POINTS - Display the FSP entry points in romstage</li>
+  <li>CONFIG_DISPLAY_HOBS - Display and verify the hand-off-blocks (HOBs) returned by MemoryInit</li>
+  <li>CONFIG_DISPLAY_VBT - Display Video BIOS Table (VBT) used for GOP</li>
+  <li>CONFIG_DISPLAY_UPD_DATA - Display the user specified product data passed to MemoryInit and SiliconInit</li>
+</ul>
+
+
+<hr>
+<p>Modified: 17 May 2016</p>
+  </body>
+</html>

Documentation/Intel/index.html

@@ -0,0 +1,128 @@
+<!DOCTYPE html>
+<html>
+  <head>
+    <title>Intel&reg; x86</title>
+  </head>
+  <body>
+
+<h1>Intel&reg; x86</h1>
+
+<h2>Intel&reg; x86 Boards</h2>
+<ul>
+  <li><a target="_blank" href="Board/galileo.html">Galileo</a></li>
+  <li><a target="_blank" href="http://wiki.minnowboard.org/Coreboot">MinnowBoard MAX</a></li>
+</ul>
+
+<h2>Intel&reg; x86 SoCs</h2>
+<ul>
+  <li><a target="_blank" href="SoC/quark.html">Quark&trade;</a></li>
+</ul>
+
+
+
+<hr>
+<h2>x86 coreboot Development</h2>
+<ul>
+  <li>Get the <a target="_blank" href="https://www.coreboot.org/Git">coreboot source</li>
+  <li><a target="_blank" href="development.html">Overall</a> development</li>
+  <li><a target="_blank" href="fsp1_1.html">FSP 1.1</a> integration
+  </li>
+  <li><a target="_blank" href="SoC/soc.html">SoC</a> support</li>
+  <li><a target="_blank" href="Board/board.html">Board</a> support</li>
+</ul>
+
+
+
+<hr>
+<h2>Payload Development</h2>
+<ul>
+  <li><a target="_blank" href="SoC/quark.html#CorebootPayloadPkg">CorebootPayloadPkg</a>
+    <ul>
+      <li><a target="_blank" href="https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Development-Process">EDK II Development Process</a></li>
+      <li>EDK II <a target="_blank" href="https://github.com/tianocore/tianocore.github.io/wiki/EDK%20II%20White%20papers">White Papers</a></li>
+      <li><a target="_blank" href="https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-Github-Quick-Start">SourceForge to Github Quick Start</a></li>
+      <li>UEFI <a target="_blank" href="http://www.uefi.org/sites/default/files/resources/UEFI%20Spec%202_5_Errata_A.PDF">2.5 Errata A</a></li>
+    </ul>
+  </li>
+</ul>
+
+
+
+<hr>
+<h2><a name="Documentation">Documentation</a></h2>
+<ul>
+  <li>Intel&reg; 64 and IA-32 Architectures <a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf">Software Developer Manual</a></li>
+  <li><a target="_blank" href="http://www.uefi.org/specifications">UEFI Specifications</a></li>
+</ul>
+
+<h3><a name="Edk2Documentation">EDK-II Documentation</a></h3>
+<ul>
+  <li>Build <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/Build_Spec_1_26.pdf">V1.26</a></li>
+  <li>Coding Standards <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/CCS_2_1_Draft.pdf">V2.1</a></li>
+  <li>DEC <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/DEC_Spec_1_25.pdf">V1.25</a></li>
+  <li>DSC <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/DSC_Spec_1_26.pdf">V1.26</a></li>
+  <li><a target="_blank" href="https://github.com/tianocore/tianocore.github.io/wiki/UEFI-Driver-Writer's-Guide">Driver Writer's Guide</a></li>
+  <li>Expression Syntax <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/ExpressionSyntax_1.1.pdf">V1.1</a></li>
+  <li>FDF <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/FDF_Spec_1_26.pdf">V1.26</a></li>
+  <li>INF <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/INF_Spec_1_25.pdf">V1.25</a></li>
+  <li>PCD <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/PCD_Infrastructure.pdf">PCD</a>V0.55</li>
+  <li>UNI <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/UNI_File_Spec_v1_2_Errata_A.pdf">V1.2 Errata A</a></li>
+  <li>VRF <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/VFR_1_9.pdf">V1.9</a></li>
+</ul>
+
+<h3><a name="FspDocumentation">FSP Documentation</a></h3>
+<ul>
+  <li>Intel&reg; Firmware Support Package External Architecture Specification <a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v2.pdf">V2.0</a></li>
+  <li>Intel&reg; Firmware Support Package External Architecture Specification <a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec-v1-1.pdf">V1.1</a></li>
+  <li>Intel&reg; Firmware Support Package External Architecture Specification <a target="_blank" href="http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/fsp-architecture-spec.pdf">V1.0</a></li>
+</ul>
+
+<h3><a name="FeatureDocumentation">Feature Documentation</a></h3>
+<table border="1">
+  <tr bgcolor="#c0ffc0"><th>Feature/Specification</th><th>Linux View/Test</th><th>EDK-II View/Test</th></tr>
+  <tr>
+    <td><a target="_blank" href="https://en.wikipedia.org/wiki/E820">e820</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/trusty/man1/dmesg.1.html">dmesg</a></td>
+    <td>&nbsp;</td>
+  </tr>
+  <tr>
+    <td><a target="_blank" href="http://www.uefi.org/specifications">ACPI</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/precise/man1/acpidump.1.html">acpidump</a></td>
+    <td>&nbsp;</td>
+  </tr>
+  <tr>
+    <td><a target="_blank" href="https://en.wikipedia.org/wiki/Extended_Display_Identification_Data">EDID</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/trusty/man1/get-edid.1.html">get-edid | parse-edid</a></td>
+    <td>&nbsp;</td>
+  </tr>
+  <tr>
+    <td><a target="_blank" href="http://www.nxp.com/documents/user_manual/UM10204.pdf">I2C</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/trusty/man1/get-edid.1.html">i2cdetect</a></td>
+    <td>&nbsp;</td>
+  </tr>
+  <tr>
+    <td><a target="_blank" href="http://www.intel.com/design/archives/processors/pro/docs/242016.htm">Multiprocessor</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/trusty/man1/lscpu.1.html">lscpu</a></td>
+    <td>&nbsp;</td>
+  </tr>
+  <tr>
+    <td><a target="_blank" href="https://pcisig.com/specifications">PCI</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/trusty/man8/lspci.8.html">lspci</a></td>
+    <td><a target="_blank" href="http://www.uefi.org/sites/default/files/resources/UEFI_Shell_Spec_2_0.pdf">pci</a></td>
+  </tr>
+  <tr>
+    <td><a target="_blank" href="https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.0.0.pdf">SMBIOS</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/trusty/man8/dmidecode.8.html">dmidecode</a></td>
+    <td><a target="_blank" href="http://www.uefi.org/sites/default/files/resources/UEFI_Shell_Spec_2_0.pdf">smbiosview</a></td>
+  </tr>
+  <tr>
+    <td><a target="_blank" href="http://www.usb.org/developers/docs/">USB</a></td>
+    <td><a target="_blank" href="http://manpages.ubuntu.com/manpages/xenial/man8/lsusb.8.html">lsusb</a></td>
+    <td>&nbsp;</td>
+  </tr>
+</table>
+
+<hr>
+<p>Modified: 18 June 2016</p>
+  </body>
+</html>

Documentation/RFC/chip.tex

@@ -7,7 +7,7 @@ change.
 
 \section{Scope}
 This document defines how LinuxBIOS programmers can specify chips that
-are used, specified, and initialized. The current scope is for superio
+are used, specified, and initalized. The current scope is for superio
 chips, but the architecture should allow for specification of other chips such
 as southbridges. Multiple chips of same or different type are supported.
 

Documentation/RFC/intel-gpio-cleanup.md

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

Documentation/acpi/devicetree.md

@@ -5,7 +5,7 @@
 ACPI exposes a platform-independent interface for operating systems to perform
 power management and other platform-level functions.  Some operating systems
 also use ACPI to enumerate devices that are not immediately discoverable, such
-as those behind I2C or SPI buses (in contrast to PCI).  This document discusses
+as those behind I2C or SPI busses (in contrast to PCI).  This document discusses
 the way that coreboot uses the concept of a "device tree" to generate ACPI
 tables for usage by the operating system.
 
@@ -20,62 +20,6 @@ devicetree.  Note, not all mainboards will have the devicetree/overridetree
 distinction, and may only have a devicetree.cb file.  Or you can always just
 write the ASL (ACPI Source Language) code yourself.
 
-### Naming and referencing devices
-
-When declaring a device, it can optionally be given an alias that can be
-referred to elsewhere. This is particularly useful to declare a device in one
-device tree while allowing its configuration to be more easily changed in an
-overlay. For instance, the AMD Picasso SoC definition
-(`soc/amd/picasso/chipset.cb`) declares an IOMMU on a PCI bus that is disabled
-by default:
-
-```
-chip soc/amd/picasso
-	device domain 0 on
-		...
-		device pci 00.2 alias iommu off end
-		...
-	end
-end
-```
-
-A device based on this SoC can override the configuration for the IOMMU without
-duplicating addresses, as in
-`mainboard/google/zork/variants/baseboard/devicetree_trembyle.cb`:
-
-```
-chip soc/amd/picasso
-	device domain 0
-		...
-		device ref iommu on end
-		...
-	end
-end
-```
-
-In this example the override simply enables the IOMMU, but it could also
-set additional properties (or even add child devices) inside the IOMMU `device`
-block.
-
----
-
-It is important to note that devices that use `device ref` syntax to override
-previous definitions of a device by alias must be placed at **exactly the same
-location in the device tree** as the original declaration. If not, this will
-actually create another device rather than overriding the properties of the
-existing one. For instance, if the above snippet from `devicetree_trembyle.cb`
-were written as follows:
-
-```
-chip soc/amd/picasso
-	# NOTE: not inside domain 0!
-	device ref iommu on end
-end
-```
-
-Then this would leave the SoC's IOMMU disabled, and instead create a new device
-with no properties as a direct child of the SoC.
-
 ## Device drivers
 
 Let's take a look at an example entry from
@@ -86,7 +30,7 @@ device pci 15.0 on
 	chip drivers/i2c/generic
 		register "hid" = ""ELAN0000""
 		register "desc" = ""ELAN Touchpad""
-		register "irq" = "ACPI_IRQ_WAKE_LEVEL_LOW(GPP_A21_IRQ)"
+		register "irq" = "ACPI_IRQ_WAKE_EDGE_LOW(GPP_A21_IRQ)"
 		register "wake" = "GPE0_DW0_21"
 		device i2c 15 on end
 	end
@@ -116,12 +60,12 @@ Scope (\_SB.PCI0.I2C0)
             I2cSerialBusV2 (0x0015, ControllerInitiated, 400000,
                 AddressingMode7Bit, "\\_SB.PCI0.I2C0",
                 0x00, ResourceConsumer, , Exclusive, )
-            Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake, ,, )
+            Interrupt (ResourceConsumer, Edge, ActiveLow, ExclusiveAndWake, ,, )
             {
                 0x0000002D,
             }
         })
-        Name (_S0W, ACPI_DEVICE_SLEEP_D3_HOT)  // _S0W: S0 Device Wake State
+        Name (_S0W, 0x04)  // _S0W: S0 Device Wake State
         Name (_PRW, Package (0x02)  // _PRW: Power Resources for Wake
         {
             0x15, // GPE #21
@@ -192,7 +136,7 @@ corresponds to **const char *desc** and in ASL:
 It also adds the interrupt,
 
 ```
-    Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake, ,, )
+    Interrupt (ResourceConsumer, Edge, ActiveLow, ExclusiveAndWake, ,, )
     {
         0x0000002D,
     }
@@ -201,15 +145,15 @@ It also adds the interrupt,
 which comes from:
 
 ```
-    register "irq" = "ACPI_IRQ_WAKE_LEVEL_LOW(GPP_A21_IRQ)"
+    register "irq" = "ACPI_IRQ_WAKE_EDGE_LOW(GPP_A21_IRQ)"
 ```
 
-The GPIO pin IRQ settings control the "Level", "ActiveLow", and
-"ExclusiveAndWake" settings seen above (level means it is a level-triggered
-interrupt as opposed to edge-triggered; active low means the interrupt is
-triggered when the signal is low).
+The GPIO pin IRQ settings control the "Edge", "ActiveLow", and
+"ExclusiveAndWake" settings seen above (edge means it is an edge-triggered
+interrupt as opposed to level-triggered; active low means the interrupt is
+triggered on a falling edge).
 
-Note that the ACPI_IRQ_WAKE_LEVEL_LOW macro informs the platform that the GPIO
+Note that the ACPI_IRQ_WAKE_EDGE_LOW macro informs the platform that the GPIO
 will be routed through SCI (ACPI's System Control Interrupt) for use as a wake
 source.  Also note that the IRQ names are SoC-specific, and you will need to
 find the names in your SoC's header file.  The ACPI_* macros are defined in
@@ -252,7 +196,7 @@ for more details on ACPI methods)
 
 ### _S0W (S0 Device Wake State)
 _S0W indicates the deepest S0 sleep state this device can wake itself from,
-which in this case is ACPI_DEVICE_SLEEP_D3_HOT, representing _D3hot_.
+which in this case is 4, representing _D3cold_.
 
 ### _PRW (Power Resources for Wake)
 _PRW indicates the power resources and events required for wake.  There are no

Documentation/acpi/gpio.md

@@ -84,6 +84,15 @@ the raw Rx gpio value.
 
 ## Implementation Details
 
+ACPI library in coreboot will provide weak definitions for all the
+above functions with error messages indicating that these functions
+are being used. This allows drivers to conditionally make use of GPIOs
+based on device-tree entries or any other config option. It is
+recommended that the SoC code in coreboot should provide
+implementations of all the above functions generating ACPI AML code
+irrespective of them being used in any driver. This allows mainboards
+to use any drivers and take advantage of this common infrastructure.
+
 Platforms are restricted to using Local5, Local6 and Local7 variables
 only in implementations of the above functions. Any AML methods called
 by the above functions do not have any such restrictions on use of
@@ -150,6 +159,7 @@ for the GPIO.
 	 */
 	acpigen_write_if_and(Local5, TX_BIT);
 	acpigen_write_store_args(ONE_OP, LOCAL0_OP);
+	acpigen_pop_len();
 	acpigen_write_else();
 	acpigen_write_store_args(ZERO_OP, LOCAL0_OP);
 	acpigen_pop_len();

Documentation/arch/x86/index.md

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

Documentation/cbfstool/index.md

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

Documentation/cbfstool/mmap_windows.md

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

Documentation/coding_style.md

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

Documentation/community/forums.md

@@ -11,29 +11,8 @@ You can subscribe on its
 read its
 [archives](https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/).
 
-## Real time chat
+## IRC
 
-We also have a real time chat room on [IRC](ircs://irc.libera.chat/#coreboot),
-also bridged to [Matrix](https://matrix.to/#/#coreboot:libera.chat) and a
-[Discord](https://discord.gg/JqT8NM5Zbg) presence. You can also find us on
-[OSF Slack](https://osfw.slack.com/), which has channels on many open source
-firmware related topics. Slack requires that people come from specific domains
-or are explicitly invited. To work around that, there's an
-[invite bot](https://slack.osfw.dev/) to let people in.
-
-## Fortnightly coreboot leadership meeting
-
-There's a leadership meeting held every 14 days (currently every other
-Wednesday at 10am Pacific Time, usually 18:00 UTC with some deviation
-possible due to daylight saving time related shifts). The meeting
-is open to everyone and provides a forum to discuss general coreboot
-topics, including community and technical matters that benefit from
-an official decision.
-
-We tried a whole lot of different tools, but so far the meetings worked
-best with [Google Meet](https://meet.google.com/syn-toap-agu),
-using [Google Docs](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit)
-for the agenda and meeting minutes. Neither the video conference nor
-the document require a Google account to participate, although editing
-access to the document is limited to adding comments - any desired
-agenda item added that way will be approved in time before the meeting.
+We also have a
+[real time chat](https://webchat.freenode.net?channels=%23coreboot)
+on the Freenode IRC network's #coreboot channel.

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.
@@ -185,7 +185,7 @@ texinfo_documents = [
 enable_auto_toc_tree = True
 
 class MyCommonMarkParser(CommonMarkParser):
-    # remove this hack once upstream RecommonMark supports inline code
+    # remove this hack once upsteam RecommonMark supports inline code
     def visit_code(self, mdnode):
         from docutils import nodes
         n = nodes.literal(mdnode.literal, mdnode.literal)

Documentation/contributing/project_ideas.md

@@ -66,6 +66,25 @@ across architectures.
 ### Mentors
 * Timothy Pearson <tpearson@raptorengineering.com>
 
+## Add Kernel Address Sanitizer functionality to coreboot
+The Kernel Address Sanitizer (KASAN) is a runtime dynamic memory error detector.
+The idea is to check every memory access (variables) for its validity
+during runtime and find bugs like stack overflow or out-of-bounds accesses.
+Implementing this stub into coreboot like "Undefined behavior sanitizer support"
+would help to ensure code quality and make the runtime code more robust.
+
+### Requirements
+* knowledge in the coreboot build system and the concept of stages
+* the KASAN feature can be improved in a way so that the memory space needed
+  during runtime is not on a fixed address provided during compile time but
+  determined during runtime. For this to achieve a small patch to the GCC will
+  be helpful. Therefore minor GCC knowledge would be beneficial.
+* Implementation can be initially done in QEMU and improved on different
+  mainboards and platforms
+
+### Mentors
+* Werner Zeh <werner.zeh@gmx.net>
+
 ## Port payloads to ARM, AArch64 or RISC-V
 While we have a rather big set of payloads for x86 based platforms, all other
 architectures are rather limited. Improve the situation by porting a payload
@@ -202,9 +221,9 @@ Build an open source replacement written in Golang using existing tools
 and libraries, consisting of a backend, a frontend and client side
 scripts. The backend should connect to an SQL database with can be
 controlled using a RESTful API. The RESTful API should have basic authentication
-for management tasks and new board status uploads.
+for managment tasks and new board status uploads.
 
-At least one older test result should be kept in the database.
+At least one older test result should be keept in the database.
 
 The frontend should use established UI libraries or frameworks (for example
 Angular) to display the current board status, that is if it's working or not

Documentation/distributions.md

@@ -8,15 +8,28 @@ and those providing after-market firmware to extend the usefulness of devices.
 
 ## Hardware shipping with coreboot
 
+### Purism
+
+[Purism](https://www.puri.sm) sells laptops with a focus on user privacy and
+security; part of that effort is to minimize the amount of proprietary and/or
+binary code. Their laptops ship with a blob-free OS and coreboot firmware
+with a neutralized Intel Management Engine (ME) and SeaBIOS as the payload.
+
 ### ChromeOS Devices
 
 All ChromeOS devices ([Chromebooks](https://chromebookdb.com/), Chromeboxes,
 Chromebit, etc) released from 2012 onward use coreboot for their main system
 firmware. Additionally, starting with the 2013 Chromebook Pixel, the firmware
-running on the Embedded Controller (EC) – a small microcontroller which provides
-functions like battery management, keyboard support, and sensor interfacing –
+running on the Embedded Controller (EC - a small microcontroller which provides
+functions like battery management, keyboard support, and sensor interfacing)
 is open source as well.
 
+### Libretrend
+
+[Libretrend](https://libretrend.com) sells the Librebox, a NUC-like PC which
+ships with coreboot firmware.
+
+
 ### PC Engines APUs
 
 [PC Engines](https://pcengines.ch) designs and sells embedded PC hardware that
@@ -24,20 +37,6 @@ ships with coreboot and support upstream maintenance for the devices through a
 third party, [3mdeb](https://3mdeb.com). They provide current and tested
 firmware binaries on [GitHub](https://pcengines.github.io).
 
-### System76
-
-[System76](https://system76.com/) manufactures Linux laptops, desktops, and
-servers. Some models are sold with [System76 Open
-Firmware](https://github.com/system76/firmware-open), an open source
-distribution of coreboot, EDK2, and System76 firmware applications.
-
-### Purism
-
-[Purism](https://www.puri.sm) sells laptops with a focus on user privacy and
-security; part of that effort is to minimize the amount of proprietary and/or
-binary code. Their laptops ship with a blob-free OS and coreboot firmware
-with a neutralized Intel Management Engine (ME) and SeaBIOS as the payload.
-
 ## After-market firmware
 
 ### Libreboot

Documentation/drivers/dptf.md

@@ -311,19 +311,3 @@ table for a given temperature threshold.
 1) Hysteresis - The amount of hysteresis implemented in either circuitry or
    the firmware that reads the temperature sensor (in degrees C).
 2) Name - This name is applied to the _STR property of the sensor
-
-## OEM Variables
-Platform vendors can define an array of OEM-specific values as OEM variables
-to be used under DPTF policy. There are total six OEM variables available.
-These can be used in AP policy for more specific actions. These OEM variables
-can be defined as below mentioned example and can be used any variable between
-[0], [1],...,[5]. Platform vendors can enable and use this for specific platform
-by defining OEM variables macro under board variant.
-
-Example:
-```C
-register "oem_data.oem_variables" = "{
-   [1] = 0x6,
-   [3] = 0x1
-}"
-```

Documentation/drivers/index.md

@@ -2,11 +2,8 @@
 
 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 across platforms.
+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/drivers/soundwire.md

@@ -375,7 +375,7 @@ chip and can be decoded for this table with the codec datasheet and board schema
  * @version: SoundWire specification version from &enum soundwire_version.
  * @link_id: Zero-based SoundWire Link Number.
  * @unique_id: Unique ID for multiple devices.
- * @manufacturer_id: Manufacturer ID from include/mipi/ids.h.
+ * @manufacturer_id: Manufacturer ID from include/device/mipi_ids.h.
  * @part_id: Vendor defined part ID.
  * @class: MIPI class encoding in &enum mipi_class.
  */

Documentation/flash_tutorial/index.md

@@ -7,7 +7,7 @@ flash IC.
 
 ## Contents
 
-* [Flashing internally](int_flashrom.md)
+* [Flashing internaly](int_flashrom.md)
 * [Flashing firmware standalone](ext_standalone.md)
 * [Flashing firmware externally supplying direct power](ext_power.md)
 * [Flashing firmware externally without supplying direct power](no_ext_power.md)

Documentation/gcov.txt

@@ -19,7 +19,7 @@ time). The file gcov-io.c is unchanged.
 +#define BITS_PER_UNIT 8
 +#define LONG_LONG_TYPE_SIZE 64
 +
-+/* There are many gcc_assertions. Set the value to 1 if we want a warning
++/* There are many gcc_assertions. Set the vaule to 1 if we want a warning
 +   message if the assertion fails.  */
 +#ifndef ENABLE_ASSERT_CHECKING
 +#define ENABLE_ASSERT_CHECKING 1

Documentation/getting_started/architecture.md

@@ -41,7 +41,7 @@ The bootblock loads the romstage or the verstage if verified boot is enabled.
 
 ### Cache-As-Ram
 The *Cache-As-Ram*, also called Non-Eviction mode, or *CAR* allows to use the
-CPU cache like regular SRAM. This is particullary useful for high level
+CPU cache like regular SRAM. This is particullary usefull for high level
 languages like `C`, which need RAM for heap and stack.
 
 The CAR needs to be activated using vendor specific CPU instructions.
@@ -85,7 +85,7 @@ The ramstage does the main device init:
 * CPU init (like set up SMM)
 
 After initialization tables are written to inform the payload or operating system
-about the current hardware existence and state. That includes:
+about the current hardware existance and state. That includes:
 
 * ACPI tables (x86 specific)
 * SMBIOS tables (x86 specific)

Documentation/getting_started/gerrit_guidelines.md

@@ -43,42 +43,15 @@ employer is aware and you are authorized to submit the code. For
 clarification, see the Developer's Certificate of Origin in the coreboot
 [Signed-off-by policy](https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure).
 
-* In general, patches should remain open for review for at least 24 hours
-since the last significant modification to the change. The purpose is to
-let coreboot developers around the world have a chance to review. Complex
-reworks, even if they don't change the purpose of the patch but the way
-it's implemented, should restart the wait period.
-
-* A change can go in without the wait period if its purpose is to fix
-a recently-introduced issue (build, boot or OS-level compatibility, not
-necessarily identified by coreboot.org facilities). Its commit message
-has to explain what change introduced the problem and the nature of
-the problem so that the emergency need becomes apparent. The change
-itself should be as limited in scope and impact as possible to make it
-simple to assess the impact. Such a change can be merged early with 3
-Code-Review+2. For emergency fixes that affect a single project (SoC,
-mainboard, ...) it's _strongly_ recommended to get a review by somebody
-not involved with that project to ensure that the documentation of the
-issue is clear enough.
-
-* Trivial changes that deal with minor issues like inconsistencies in
-whitespace or spelling fixes that don't impact the final binary output
-also don't need to wait. Such changes should point out in their commit
-messages how the the author verified that the binary output is identical
-(e.g. a TIMELESS build for a given configuration). When submitting
-such changes early, the submitter must be different from the author
-and must document the intent in the Gerrit discussion, e.g. "landed the
-change early because it's trivial". Note that trivial fixes shouldn't
-necessarily be expedited: Just like they're not critical enough for
-things to go wrong because of them, they're not critical enough to
-require quick handling. This exception merely serves to acknowledge that
-a round-the-world review just isn't necessary for some types of changes.
-
-* As explained in our Code of Conduct, we try to assume the best of each
-other in this community. It's okay to discuss mistakes (e.g. isolated
-instances of non-trivial and non-critical changes submitted early) but
-try to keep such inquiries blameless. If a change leads to problems with
-our code, the focus should be on fixing the issue, not on assigning blame.
+* Let non-trivial patches sit in a review state for at least 24 hours
+before submission. Remember that there are coreboot developers in timezones
+all over the world, and everyone should have a chance to contribute.
+Trivial patches would be things like whitespace changes or spelling fixes,
+in general those that don’t impact the final binary output. The
+24-hour period would start at submission, and would be restarted at any
+update which significantly changes any part of the patch. Patches can be
+'Fast-tracked' and submitted in under 24 hours with the agreement of at
+least 3 +2 votes.
 
 * Do not +2 patches that you authored or own, even for something as trivial
 as whitespace fixes. When working on your own patches, it’s easy to
@@ -320,47 +293,6 @@ is criticising your code, but the whole idea is to get better code into our
 codebase. Again, this also applies in the other direction: review code,
 criticize code, but don’t make it personal.
 
-Gerrit user roles
------------------
-There are a few relevant roles a user can have on Gerrit:
-
-- The anonymous user can check out source code.
-- A registered user can also comment and give "+1" and "-1" code reviews.
-- A reviewer can also give "+2" code reviews.
-- A core developer can also give "-2" (that is, blocking) code reviews
-  and submit changes.
-
-Anybody can register an account on our instance, using either an
-OpenID provider or OAuth through GitHub or Google.
-
-The reviewer group is still quite open: Any core developer can add
-registered users to that group and should do so once some activity
-(commits, code reviews, and so on) has demonstrated rough knowledge
-of how we handle things.
-
-A core developer should be sufficiently well established in the
-community so that they feel comfortable when submitting good patches,
-when asking for improvements to less good patches and reasonably
-uncomfortable when -2'ing patches. They're typically the go-to
-person for _some_ part of the coreboot tree and ideally listed as its
-maintainer in our MAINTAINERS registry. To become part of this group,
-a candidate developer who already demonstrated proficiency with the
-code base as a reviewer should be nominated, by themselves or others,
-at the regular [coreboot leadership meetings](../community/forums.md)
-where a decision is made.
-
-Core developers are expected to use their privileges for the good of the
-project, which includes any of their own coreboot development but also beyond
-that. They should make sure that [ready changes] don't linger around needlessly
-just because their authors aren't well-connected with core developers but
-submit them if they went through review and generally look reasonable. They're
-also expected to help clean-up breakage as a result of their submissions.
-
-Since the project expects some activity by core developers, long-term absence
-(as in "years") can lead to removal from the group, which can easily be
-reversed after they come back.
 
 Requests for clarification and suggestions for updates to these guidelines
 should be sent to the coreboot mailing list at <coreboot@coreboot.org>.
-
-[ready changes]: https://review.coreboot.org/q/age:1d+project:coreboot+status:open+is:mergeable+label:All-Comments-Resolved%253Dok+label:Code-Review%253D2+-label:Code-Review%253C0+label:Verified%253D1+-label:Verified-1

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 */
@@ -115,44 +120,6 @@ variant's override table.
 This configuration is often hooked into the mainboard's `enable_dev` callback,
 defined in its `struct chip_operations`.
 
-## Unconnected and unused pads
-
-In digital electronics, it is generally recommended to tie unconnected GPIOs to
-a defined signal like VCC or GND by setting their direction to output, adding an
-external pull resistor or configuring an internal pull resistor. This is done to
-prevent floating of the pin state, which can cause various issues like EMI,
-higher power usage due to continuously switching logic, etc.
-
-On Intel PCHs from Sunrise Point onwards, termination of unconnected GPIOs is
-explicitly not required, when the input buffer is disabled by setting the bit
-`GPIORXDIS` which effectively disconnects the pad from the internal logic. All
-pads defaulting to GPIO mode have this bit set. However, in the mainboard's
-GPIO configuration the macro `PAD_NC(pad, NONE)` can be used to explicitly
-configure a pad as unconnected.
-
-In case there are no schematics available for a board and the vendor set a
-pad to something like `GPIORXDIS=1`, `GPIOTXDIS=1` with an internal pull
-resistor, an unconnected or otherwise unused pad can be assumed. In this case it
-is recommended to keep the pull resistor, because the external circuit might
-rely on it.
-
-Unconnected pads defaulting to a native function (input and output) usually
-don't need to be configured as GPIO with the `GPIORXDIS` bit set. For clarity
-and documentation purpose the macro may be used as well for them.
-
-Some pads configured as native input function explicitly require external
-pull-ups when being unused, according to the PDGs:
-- eDP_HPD
-- SMBCLK/SMBDATA
-- SML0CLK/SML0DATA/SML0ALERT
-- SATAGP*
-
-When the board was designed correctly, nothing needs to be done for them
-explicitly, while using `PAD_NC(pad, NONE)` can act as documentation. If such a
-pad is missing the external pull resistor due to bad board design, the pad
-should be configured with `PAD_NC(pad, NONE)` anyway to disconnect it
-internally.
-
 ## Potential issues (gotchas!)
 
 There are a couple of configurations that you need to especially careful about,
@@ -162,21 +129,8 @@ The first is configuring a pin as an output, when it was designed to be an
 input. There is a real risk in this case of short-circuiting a component which
 could cause catastrophic failures, up to and including your mainboard!
 
-## Soft Straps
-
-Soft straps, that can be configured by the vendor in the Intel Flash Image Tool
-(FIT), can influence some pads' default mode. It is possible to select either a
-native function or GPIO mode for some pads on non-server SoCs, while on server
-SoCs most pads can be controlled. Thus, it is generally recommended to always
-configure all pads and don't just rely on the defaults mentioned in the
-datasheet(s) which might not reflect what the vendor configured.
-
-## Pad-related known issues and workarounds
-
-### LPC_CLKRUNB blocks S0ix states when board uses eSPI
-
-When using eSPI, the pad implementing `LPC_CLKRUNB` must be set to GPIO mode.
-Other pin settings i.e. Rx path enable/disable, Tx path enable/disable, pull up
-enable/disable etc are ignored. Leaving this pin in native mode will keep the
-LPC Controller awake and prevent S0ix entry. This issues is know at least on
-Apollolake and Geminilake.
+The other configuration option to watch out for deals with unconnected GPIOs.
+If no pullup or pulldown is declared with these, they may end up "floating",
+i.e., not at logical high or logical low. This can cause problems such as
+unwanted power consumption or not reading the pin correctly, if it was intended
+to be strapped.

Documentation/getting_started/kconfig.md

@@ -52,9 +52,13 @@ 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
+  oldconfig target does, but does not print out each question as it is
+  evaluated.  It still stops to query the user if an option with no answer in
+  the .config file is found.
 
 
 ### Targets not typically used in coreboot
@@ -394,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.
 
 --------------------------------------------------------------------------------
 
@@ -603,7 +605,7 @@ int <expr> \[if <expr>\]
 
 
 ##### Example:
-    config PRE_GRAPHICS_DELAY_MS
+    config PRE_GRAPHICS_DELAY
         int "Graphics initialization delay in ms"
         default 0
         help
@@ -1188,7 +1190,7 @@ https://github.com/martinlroth/language-kconfig
 ## Syntax Checking:
 
 The Kconfig utility does some basic syntax checking on the Kconfig tree.
-Running "make oldconfig" will show any errors that the Kconfig utility
+Running "make silentoldconfig" will show any errors that the Kconfig utility
 sees.
 
 ### util/kconfig_lint

Documentation/getting_started/writing_documentation.md

@@ -6,7 +6,7 @@
 That said please always try to write documentation! One problem in the
 firmware development is the missing documentation. In this document
 you will get a brief introduction how to write, submit and publish
-documentation to coreboot.
+documenation to coreboot.
 
 ## Preparations
 

Documentation/ifdtool/layout.md

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

Documentation/index.md

@@ -45,12 +45,6 @@ to the payload), but it's also a value that is deeply ingrained in the
 project. We fearlessly rip out parts of the architecture and remodel it
 when a better way of doing the same was identified.
 
-That said, since there are attempts to coerce coreboot to move in various
-directions by outside "standardization", long-established practices of
-coreboot as well as aligned projects can be documented as best practices,
-making them standards in their own right. However we reserve the right to
-retire them as the landscape shifts around us.
-
 ### One tree for everything
 
 Another difference to various other firmware projects is that we try
@@ -168,11 +162,10 @@ Contents:
 
 * [Getting Started](getting_started/index.md)
 * [Tutorial](tutorial/index.md)
-* [Coding Style](contributing/coding_style.md)
+* [Coding Style](coding_style.md)
 * [Project Ideas](contributing/project_ideas.md)
 * [Documentation Ideas](contributing/documentation_ideas.md)
 * [Code of Conduct](community/code_of_conduct.md)
-* [Language style](community/language_style.md)
 * [Community forums](community/forums.md)
 * [Project services](community/services.md)
 * [coreboot at conferences](community/conferences.md)
@@ -189,11 +182,9 @@ Contents:
 * [Mainboard](mainboard/index.md)
 * [Payloads](lib/payloads/index.md)
 * [Libraries](lib/index.md)
-* [Options](lib/option.md)
 * [Security](security/index.md)
 * [SuperIO](superio/index.md)
 * [Vendorcode](vendorcode/index.md)
 * [Utilities](util.md)
-* [coreboot infrastructure](infrastructure/index.md)
 * [Release notes for past releases](releases/index.md)
 * [Flashing firmware tutorial](flash_tutorial/index.md)

Documentation/infrastructure/builders.md

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

Documentation/infrastructure/index.md

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

Documentation/lib/flashmap.md

@@ -17,8 +17,7 @@ something else) should have its own Flashmap section, and everything else should
 normally go into CBFS.
 
 The Flashmap itself starts with a header `struct fmap` and followed by a list of
-section descriptions in `struct fmap_area`. All fields in those structures are
-in little endian format.
+section descriptions in `struct fmap_area`.
 
 ### Header
 The header `struct fmap` has following fields:

Documentation/lib/fw_config.md

@@ -73,18 +73,18 @@ return true.
 
 ## Firmware Configuration Value
 
-The 64-bit value used as the firmware configuration bitmask is meant to be determined at runtime
+The 32bit value used as the firmware configuration bitmask is meant to be determined at runtime
 but could also be defined at compile time if needed.
 
 There are two supported sources for providing this information to coreboot.
 
 ### CBFS
 
-The value can be provided with a 64-bit raw value in CBFS that is read by coreboot.  The value
+The value can be provided with a 32bit raw value in CBFS that is read by coreboot.  The value
 can be set at build time but also adjusted in an existing image with `cbfstool`.
 
 To enable this select the `CONFIG_FW_CONFIG_CBFS` option in the build configuration and add a
-raw 64-bit value to CBFS with the name of the current prefix at `CONFIG_FW_PREFIX/fw_config`.
+raw 32bit value to CBFS with the name of the current prefix at `CONFIG_FW_PREFIX/fw_config`.
 
 When `fw_config_probe_device()` or `fw_config_probe()` is called it will look for the specified
 file in CBFS use the value it contains when matching fields and options.
@@ -121,48 +121,12 @@ Each field is defined by providing the field name and the start and end bit mark
 location in the bitmask.  Field names must be at least three characters long in order to
 satisfy the sconfig parser requirements and they must be unique with non-overlapping masks.
 
-	field <name> <start-bit> <end-bit> [option...] end
+    field <name> <start-bit> <end-bit> [option...] end
 
 For single-bit fields only one number is needed:
 
 	field <name> <bit> [option...] end
 
-A field definition can also contain multiple sets of bit masks, which can be dis-contiguous.
-They are treated as if they are contiguous when defining option values.  This allows for
-extending fields even after the bits after its current masks are occupied.
-
-	field <name> <start-bit0> <end-bit0> | <start-bit1> <end-bit1> | ...
-
-For example, if more audio options need to be supported:
-
-	field AUDIO 3 3
-		option AUDIO_0  0
-		option AUDIO_1  1
-	end
-	field OTHER 4 4
-		...
-	end
-
-the following can be done:
-
-	field AUDIO 3 3 | 5 5
-		option AUDIO_FOO   0
-		option AUDIO_BLAH  1
-		option AUDIO_BAR   2
-		option AUDIO_BAZ   3
-	end
-	field OTHER 4 4
-		...
-	end
-
-In that case, the AUDIO masks are extended like so:
-
-	#define FW_CONFIG_FIELD_AUDIO_MASK						0x28
-	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_FOO_VALUE	0x0
-	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BLAH_VALUE	0x8
-	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAR_VALUE	0x20
-	#define FW_CONFIG_FIELD_AUDIO_OPTION_AUDIO_BAz_VALUE	0x28
-
 Each `field` definition starts a new block that can be composed of zero or more field options,
 and it is terminated with `end`.
 
@@ -327,8 +291,8 @@ field and option to check.
 struct fw_config {
 	const char *field_name;
 	const char *option_name;
-	uint64_t mask;
-	uint64_t value;
+	uint32_t mask;
+	uint32_t value;
 };
 ```
 

Documentation/lib/option.md

@@ -1,31 +0,0 @@
-# Option API
-
-The option API around the `set_option(const char *name, void *val)` and
-`get_option(void *dest, const char *name)` functions deprecated in favor
-of a type-safe API.
-
-Historically, options were stored in RTC battery-backed CMOS RAM inside
-the chipset on PC platforms. Nowadays, options can also be stored in the
-same flash chip as the boot firmware or through some BMC interface.
-
-The new type-safe option framework can be used by calling
-`enum cb_err set_uint_option(const char *name, unsigned int value)` and
-`unsigned int get_uint_option(const char *name, const unsigned int fallback)`.
-
-The default setting is `OPTION_BACKEND_NONE`, which disables any runtime
-configurable options. If supported by a mainboard, the `USE_OPTION_TABLE`
-and `USE_MAINBOARD_SPECIFIC_OPTION_BACKEND` choices are visible, and can
-be selected to enable runtime configurability.
-
-# Mainboard-specific option backend
-
-Mainboards with a mainboard-specific (vendor-defined) method to access
-options can select `HAVE_MAINBOARD_SPECIFIC_OPTION_BACKEND` to provide
-implementations of the option API accessors. To allow choosing between
-multiple option backends, the mainboard-specific implementation should
-only be built when `USE_MAINBOARD_SPECIFIC_OPTION_BACKEND` is selected.
-
-Where possible, using a generic, mainboard-independent mechanism should
-be preferred over reinventing the wheel in mainboard-specific code. The
-mainboard-specific approach should only be used when the option storage
-mechanism has to satisfy externally-imposed, vendor-defined constraints.

Documentation/lib/payloads/fit.md

@@ -5,7 +5,6 @@
 
 ## Supported architectures
 
-* aarch32
 * aarch64
 * riscv
 
@@ -25,14 +24,7 @@ The section must be named in order to be found by the FIT parser:
 
 ## Architecture specifics
 
-The FIT parser needs architecture 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*".
+The FIT parser needs architecure support.
 
 ### aarch64
 The source code can be found in `src/arch/arm64/fit_payload.c`.

Documentation/lib/timestamp.md

@@ -99,7 +99,7 @@ exist and an entry structure to hold variable number of entries.
 
 ### entries
 
-This field holds the details of each timestamp entry, up to a maximum
+This field holds the details of each timestamp entry, upto a maximum
 of `MAX_TIMESTAMP_CACHE` which is defined as 16 entries. Each entry is
 defined by:
 

Documentation/mainboard/amd/padmelon/padmelon.md

@@ -43,7 +43,7 @@ Three items are marked in this picture
 +---------------------+--------------------+
 | Size                | 8 MiB              |
 +---------------------+--------------------+
-| Flash programming   | dediprog header    |
+| Flash programing    | dediprog header    |
 +---------------------+--------------------+
 | Package             | SOIC-8             |
 +---------------------+--------------------+

Documentation/mainboard/asus/a88xm-e.md

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

Documentation/mainboard/asus/p5q.md

@@ -2,7 +2,9 @@
 
 This page describes how to run coreboot on the [ASUS P5Q] desktop board.
 
-## Working
+## TODO
+
+The following things are working in this coreboot port:
 
 + PCI slots
 + PCI-e slots
@@ -13,21 +15,20 @@ This page describes how to run coreboot on the [ASUS P5Q] desktop board.
 + All 4 DIMM slots
 + S3 suspend and resume
 + Red SATA ports
-+ Fan control through the W83667HG chip
-+ FireWire
 
-## Not working
+The following things are still missing from this coreboot port:
 
 + PS/2 mouse support
 + PATA aka IDE (because of buggy IDE controller)
-+ Fan profiles with Q-Fan
++ Fan control (will be working on 100% power)
 + TPM module (support not implemented)
 
-## Untested
+The following things are untested on this coreboot port:
 
 + S/PDIF
 + CD Audio In
 + Floppy disk drive
++ FireWire: PCI device shows up and driver loads, no further test
 
 
 ## Flashing coreboot
@@ -72,63 +73,5 @@ You can flash coreboot into your motherboard using [this guide].
 +------------------+---------------------------------------------------+
 ```
 
-## Controlling fans
-
-With vendor firmware, the P5Q uses the ATK0110 ACPI device to control its fans
-according to the parameters configured in the BIOS setup menu. With coreboot,
-one can instead control the Super I/O directly as described in the
-[kernel docs]:
-
-+ pwm1 controls fan1 (CHA_FAN1) and fan4 (CHA_FAN2)
-+ pwm2 controls fan2 (CPU_FAN)
-+ fan3 (PWR_FAN) cannot be controlled
-+ temp1 (board) can be used to control fan1 and fan4
-+ temp2 (CPU) can be used to control fan2
-
-### Manual fan speed
-
-These commands set the chassis fans to a constant speed:
-
-    # Use PWM output
-    echo 1 >/sys/class/hwmon/hwmon2/pwm1_mode
-    # Set to manual mode
-    echo 1 >/sys/class/hwmon/hwmon2/pwm1_enable
-    # Set relative speed: 0 (stop) to 255 (full)
-    echo 150 >/sys/class/hwmon/hwmon2/pwm1
-
-### Automatic fan speed
-
-The W83667HG can adjust fan speeds when things get too warm. These settings will
-control the chassis fans:
-
-    # Set to "Thermal Cruise" mode
-    echo 2 >/sys/class/hwmon/hwmon2/pwm1_enable
-    # Target temperature: 60°C
-    echo 60000 >/sys/class/hwmon/hwmon2/pwm1_target
-    # Minimum fan speed when spinning up
-    echo 135 >/sys/class/hwmon/hwmon2/pwm1_start_output
-    # Minimum fan speed when spinning down
-    echo 135 >/sys/class/hwmon/hwmon2/pwm1_stop_output
-    # Tolerance: 2°C
-    echo 2000 >/sys/class/hwmon/hwmon2/pwm1_tolerance
-    # Turn fans off after 600 seconds when below defined range
-    echo 600000 >/sys/class/hwmon/hwmon2/pwm1_stop_time
-
-You can also control the CPU fan with similar rules:
-
-    # Switch to "Thermal Cruise" mode
-    echo 2 >/sys/class/hwmon/hwmon2/pwm2_enable
-    # Target temperature: 55°C
-    echo 55000 >/sys/class/hwmon/hwmon2/pwm2_target
-    # Minimum fan speed when spinning down
-    echo 50 >/sys/class/hwmon/hwmon2/pwm2_stop_output
-    # Rate of fan speed change
-    echo 50 >/sys/class/hwmon/hwmon2/pwm2_step_output
-    # Maximum fan speed
-    echo 200 >/sys/class/hwmon/hwmon2/pwm2_max_output
-    # Tolerance: 2°C
-    echo 2000 >/sys/class/hwmon/hwmon2/pwm1_tolerance
-
 [ASUS P5Q]: https://www.asus.com/Motherboards/P5Q
 [this guide]: https://doc.coreboot.org/flash_tutorial/int_flashrom.html
-[kernel docs]: https://www.kernel.org/doc/Documentation/hwmon/w83627ehf.rst

Documentation/mainboard/asus/p8c_ws.md

@@ -1,94 +0,0 @@
-# ASUS P8C WS
-
-This page describes how to run coreboot on the [ASUS P8H77-V].
-
-## Flashing coreboot
-
-```eval_rst
-+---------------------+----------------+
-| Type                | Value          |
-+=====================+================+
-| Socketed flash      | yes            |
-+---------------------+----------------+
-| Model               | W25Q64FVA1Q    |
-+---------------------+----------------+
-| Size                | 8 MiB          |
-+---------------------+----------------+
-| Package             | DIP-8          |
-+---------------------+----------------+
-| Write protection    | no             |
-+---------------------+----------------+
-| Dual BIOS feature   | no             |
-+---------------------+----------------+
-| Internal flashing   | yes            |
-+---------------------+----------------+
-```
-
-The flash IC is located beside the SATA ports (circled):
-![](p8c_ws.jpg)
-
-### How to flash
-
-Unlike ordinary desktop boards, the BIOS version 3202 of ASUS P8C WS does not
-apply any write protection, so the main SPI flash can be accessed using
-[flashrom], and the whole flash is writable.
-
-The following command may be used to flash coreboot. (To do so, linux kernel
-should be started with `iomem=relaxed`)
-
-```
-# flashrom -p internal -w coreboot.rom
-```
-
-The flash chip is a socketed DIP-8 SPI flash, so it's also easy to remove and
-flash externally.
-
-## Working
-- Intel Xeon E3-1225 V2 with 4 M391B1G73BH0-YK0 UDIMMs, ECC confirmed active
-- PS/2 keyboard with SeaBIOS 1.14.0 and Debian GNU/Linux with kernel 5.10.40
-- Both Onboard NIC
-- S3 Suspend to RAM
-- USB2 on rear and front panel connectors
-- USB3
-- Integrated SATA
-- CPU Temp sensors (tested PSensor on GNU/Linux)
-- LPC TPM on TPM-header (tested tpm-tools with TPM 1.2 Infineon SLB9635TT12)
-- Native raminit
-- Integrated graphics with libgfxinit (both analog and digital output from DVI-I)
-- Nvidia Quadro 600 in all PCIe-16x slots
-- Compex WLM200NX (Qualcomm Atheros AR9220) in PCI slot
-- Onboard IEEE1394 controller under PCI bus
-- Debug output from serial port
-
-## Untested
-
-- EHCI debugging
-- S/PDIF audio
-- PS/2 mouse
-- LPT port
-
-## Technology
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| Northbridge      | :doc:`../../northbridge/intel/sandybridge/index` |
-+------------------+--------------------------------------------------+
-| Southbridge      | bd82x6x                                          |
-+------------------+--------------------------------------------------+
-| CPU              | model_206ax                                      |
-+------------------+--------------------------------------------------+
-| Super I/O        | Nuvoton NCT6776F                                 |
-+------------------+--------------------------------------------------+
-| EC               | None                                             |
-+------------------+--------------------------------------------------+
-| Coprocessor      | Intel Management Engine                          |
-+------------------+--------------------------------------------------+
-```
-
-## Extra resources
-
-- [Flash chip datasheet][W25Q64FVA1Q]
-
-[ASUS P8C WS]: https://www.asus.com/supportonly/p8c_ws/helpdesk_knowledge/
-[W25Q64FVA1Q]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
-[flashrom]: https://flashrom.org/Flashrom

Documentation/mainboard/asus/p8h77-v.md

@@ -1,81 +0,0 @@
-# ASUS P8Z77-V
-
-This page describes how to run coreboot on the [ASUS P8H77-V].
-
-## Flashing coreboot
-
-```eval_rst
-+---------------------+----------------+
-| Type                | Value          |
-+=====================+================+
-| Socketed flash      | yes            |
-+---------------------+----------------+
-| Model               | W25Q64FVA1Q    |
-+---------------------+----------------+
-| Size                | 8 MiB          |
-+---------------------+----------------+
-| Package             | DIP-8          |
-+---------------------+----------------+
-| Write protection    | yes            |
-+---------------------+----------------+
-| Dual BIOS feature   | no             |
-+---------------------+----------------+
-| Internal flashing   | no             |
-+---------------------+----------------+
-```
-
-The flash IC is located beside the SATA ports (circled):
-![](p8z77-v.jpg)
-
-### How to flash
-
-The main SPI flash cannot be written because the vendor firmware disables BIOSWE
-and enables BLE/SMM_BWP flags in BIOS_CNTL for their latest BIOSes. An external
-programmer is required. You must flash standalone, flashing in-circuit doesn't
-work. The flash chip is socketed, so it's easy to remove and reflash.
-
-## Working
-
-- PS/2 keyboard with SeaBIOS 1.14.0 and Debian GNU/Linux with kernel 5.10.28
-- Integrated Ethernet NIC
-- S3 Suspend to RAM
-- USB2 on rear and front panel connectors
-- USB3
-- Integrated SATA
-- CPU Temp sensors (tested PSensor on GNU/Linux)
-- Native raminit
-- Integrated graphics with libgfxinit (VGA/DVI-D/HDMI tested and working)
-- PCIe in PCIe-16x slots
-- Debug output from serial port
-
-## Untested
-
-- EHCI debugging
-- S/PDIF audio
-- PS/2 mouse
-
-## Technology
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| Northbridge      | :doc:`../../northbridge/intel/sandybridge/index` |
-+------------------+--------------------------------------------------+
-| Southbridge      | bd82x6x                                          |
-+------------------+--------------------------------------------------+
-| CPU              | model_206ax                                      |
-+------------------+--------------------------------------------------+
-| Super I/O        | Nuvoton NCT6779D                                 |
-+------------------+--------------------------------------------------+
-| EC               | None                                             |
-+------------------+--------------------------------------------------+
-| Coprocessor      | Intel Management Engine                          |
-+------------------+--------------------------------------------------+
-```
-
-## Extra resources
-
-- [Flash chip datasheet][W25Q64FVA1Q]
-
-[ASUS P8H77-V]: https://www.asus.com/supportonly/p8h77v/helpdesk_knowledge/
-[W25Q64FVA1Q]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
-[flashrom]: https://flashrom.org/Flashrom

Documentation/mainboard/asus/p8z77-v.md

@@ -1,112 +0,0 @@
-# ASUS P8Z77-V
-
-This page describes how to run coreboot on the [ASUS P8Z77-V].
-
-## Flashing coreboot
-
-```eval_rst
-+---------------------+----------------+
-| Type                | Value          |
-+=====================+================+
-| Socketed flash      | yes            |
-+---------------------+----------------+
-| Model               | W25Q64FVA1Q    |
-+---------------------+----------------+
-| Size                | 8 MiB          |
-+---------------------+----------------+
-| Package             | DIP-8          |
-+---------------------+----------------+
-| Write protection    | yes            |
-+---------------------+----------------+
-| Dual BIOS feature   | no             |
-+---------------------+----------------+
-| Internal flashing   | no             |
-+---------------------+----------------+
-```
-
-The flash IC is located between the black and white PCI Express x16 slots (circled):
-![](p8z77-v.jpg)
-
-### How to flash
-
-The main SPI flash cannot be written because the vendor firmware disables BIOSWE
-and enables BLE/SMM_BWP flags in BIOS_CNTL for their latest BIOSes. An external
-programmer is required. You must flash standalone, flashing in-circuit doesn't
-work. The flash chip is socketed, so it's easy to remove and reflash.
-
-## Working
-
-- PS/2 keyboard with SeaBIOS 1.14.0 and Debian GNU/Linux with kernel 5.10.28
-- Integrated Ethernet NIC
-- S3 Suspend to RAM
-- USB2 on rear and front panel connectors
-- USB3 (Z77's and ASMedia's works)
-- Integrated SATA of Z77
-- Integrated SATA of ASM1061 (works under GNU/Linux but not under SeaBIOS)
-- CPU Temp sensors (tested PSensor on GNU/Linux)
-- TPM on TPM-header (tested tpm-tools with TPM 1.2 Infineon SLB9635TT12)
-- Native raminit
-- Integrated graphics with libgfxinit (VGA/DVI-D/HDMI tested and working)
-- PCIe in PCIe-16x/8x slots (tested using an S3 Matrix GPU)
-- Debug output from serial port
-- Atheros AR9485 half-height mini PCIe WNIC adapted with Wi-Fi Go! Adapter
-- Default PCIe config (PCIEX_16_3 as 1x, PCIe Port 4 to ASM1061 SATA, see below
-  for other potential options)
-
-## Untested
-
-- EHCI debugging
-- S/PDIF audio
-- PS/2 mouse
-
-## Not working
-
-- PCIEX_1_2 (expected under default PCIe config)
-- Other PCIe configs (see below)
-
-## PCIe config
-On Asus vendor firmware, other than the default config already supported here,
-there remain another two configs: "PCIEX_16_3 as x4, with PCIEX_1_1, PCIEX_1_2
-and onboard ASM1061 disabled" and "PCIEX_16_3 as x1, but PCIe Port 4 to PCIEX_1_2,
-with onboard ASM1061 disabled".
-
-Configuring PCIEX_16_3 as x4 needs to program 0x3 to the LSB of PCHSTRP9, but
-also needs to configure GPIOs in the Super I/O chip different than the default
-config in this board's override tree.
-
-Configuring PCIe Port 4 to PCIEX_1_2 needs to configure GPIOs in the Super I/O
-chip differently than the default config.
-
-I have tried a lot, but sadly I am unable to produce the same result as the vendor
-firmware.
-
-## Asus Wi-Fi Go!
-Asus Wi-Fi Go! has several versions. P8Z77-V has the earliest version.
-See [Asus Wi-Fi Go! v1].
-
-## Technology
-
-```eval_rst
-+------------------+--------------------------------------------------+
-| Northbridge      | :doc:`../../northbridge/intel/sandybridge/index` |
-+------------------+--------------------------------------------------+
-| Southbridge      | bd82x6x                                          |
-+------------------+--------------------------------------------------+
-| CPU              | model_206ax                                      |
-+------------------+--------------------------------------------------+
-| Super I/O        | Nuvoton NCT6779D                                 |
-+------------------+--------------------------------------------------+
-| EC               | None                                             |
-+------------------+--------------------------------------------------+
-| Coprocessor      | Intel Management Engine                          |
-+------------------+--------------------------------------------------+
-```
-
-## Extra resources
-
-- [Flash chip datasheet][W25Q64FVA1Q]
-
-[ASUS P8Z77-V]: https://www.asus.com/supportonly/p8z77v/helpdesk_knowledge/
-[W25Q64FVA1Q]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
-[flashrom]: https://flashrom.org/Flashrom
-[Asus Wi-Fi Go! v1]: ./wifigo_v1.md

Documentation/mainboard/asus/wifigo_v1.md

@@ -1,40 +0,0 @@
-# Asus Wi-Fi Go! v1
-
-In this version, a standard half-length mPCIe card is mounted on the Asus Wi-Fi
-Go! daughter board, and the daughter board is connected to the motherboard
-through a proprietary 16-1 pin connector.
-![](wifigo_v1_connector.jpg)
-
-I managed to grope the most pinout of the proprietary connector.
-See [Mini PCIe pinout] for more info.
-
-```eval_rst
-+------------+----------+-----------+------------+----------+-----------+
-| WIFIGO Pin | Usage    | mPCIe pin | WIFIGO Pin | Usage    | mPCIe pin |
-+============+==========+===========+============+==========+===========+
-| 1          | 3.3v     | (many)    | 2          | REFCLK-  | 11        |
-+------------+----------+-----------+------------+----------+-----------+
-| 3          | GND      | (many)    | 4          | REFCLK+  | 13        |
-+------------+----------+-----------+------------+----------+-----------+
-| 5          | WAKE#    | 1         | 6          | PERn0    | 23        |
-+------------+----------+-----------+------------+----------+-----------+
-| 7          | (absent) |           | 8          | PERp0    | 25        |
-+------------+----------+-----------+------------+----------+-----------+
-| 9          | GND      |           | 10         | PETn0    | 31        |
-+------------+----------+-----------+------------+----------+-----------+
-| 11         | PERST#   | 20        | 12         | PETp0    | 33        |
-+------------+----------+-----------+------------+----------+-----------+
-| 13         | GND      |           | 14         | (USBD-?) | (36?)     |
-+------------+----------+-----------+------------+----------+-----------+
-| 15         | 3.3v     |           | 16         | (USBD+?) | (38?)     |
-+------------+----------+-----------+------------+----------+-----------+
-```
-
-There are two kinds of daughter boards using this connector. One among them has
-one MMCX antenna connector, the other has two antenna connectors and USB lane
-wired (this kind may be called BT Go!). I can only obtain the former, so I
-cannot confirm the exact way the USB data lane gets wired.
-![](wifigo_v1_board.jpg)
-
-## Extra resources
-[Mini PCIe pinout]: https://pinoutguide.com/Slots/mini_pcie_pinout.shtml

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

@@ -1,5 +1,5 @@
 # QEMU AArch64 emulator
-This page describes how to build and run coreboot for QEMU/AArch64.
+This page discribes how to build and run coreboot for QEMU/AArch64.
 You can use LinuxBoot via `make menuconfig` or an arbitrary FIT image
 as a payload for QEMU/AArch64.
 

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_USE_EXP_X86_64_SUPPORT=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_USE_EXP_X86_64_SUPPORT=y``.
-
-## Installing qemu
-
-On debian you can install qemu by running:
-```bash
-$ sudo apt-get install qemu
-```
-
-On redhat you can install qemu by running:
-```bash
-$ sudo dnf install qemu
-```
-
-## Running coreboot
-### To run the i386 version of coreboot (default)
-Running on qemu-system-i386 will require a 32 bit operating system.
-
-```bash
-qemu-system-i386 -bios build/coreboot.rom -serial stdio -M q35
-```
-
-### To run the experimental x86_64 version of coreboot
-Running on `qemu-system-x86_64` allows to run a 32 bit or 64 bit operating system
-and firmware.
-
-```bash
-qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35
-```
-
-## Finding bugs
-To test coreboot's x86 code it's recommended to run on a x86 host and enable KVM.
-It will not only run faster, but is closer to real hardware. If you see the
-following message:
-
-    KVM internal error. Suberror: 1
-    emulation failure
-
-something went wrong. The same bug will likely cause a FAULT on real hardware,
-too.
-
-To enable KVM run:
-
-```bash
-qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35 -accel kvm -cpu host
-```
-

Documentation/mainboard/facebook/monolith.md

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

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

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

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

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

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

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

Documentation/mainboard/hp/2560p.md

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

Documentation/mainboard/hp/8760w.md

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

Documentation/mainboard/hp/folio_9480m.md

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

Documentation/mainboard/hp/hp_sure_start.md

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

Documentation/mainboard/index.md

@@ -16,24 +16,16 @@ 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)
-- [P8C WS](asus/p8c_ws.md)
 - [P8H61-M LX](asus/p8h61-m_lx.md)
 - [P8H61-M Pro](asus/p8h61-m_pro.md)
-- [P8H77-V](asus/p8h77-v.md)
 - [P8Z77-M Pro](asus/p8z77-m_pro.md)
-- [P8Z77-V](asus/p8z77-v.md)
 
 ## Cavium
 
 - [CN81XX EVB SFF](cavium/cn8100_sff_evb.md)
 
-## Clevo
-
-- [N130WU / N131WU](clevo/n130wu/index.md)
-
 ## Dell
 
 - [OptiPlex 9010 SFF](dell/optiplex_9010.md)
@@ -45,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
 
@@ -59,7 +49,6 @@ The boards in this section are not real mainboards, but emulators.
 
 ## Gigabyte
 
-- [GA-G41M-ES2L](gigabyte/ga-g41m-es2l.md)
 - [GA-H61M-S2PV](gigabyte/ga-h61m-s2pv.md)
 
 ## HP
@@ -70,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
 
@@ -81,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)
@@ -94,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)
@@ -133,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
@@ -154,11 +135,6 @@ The boards in this section are not real mainboards, but emulators.
 
 - [Hermes](prodrive/hermes.md)
 
-## Purism
-
-- [Librem 14](purism/librem_14.md)
-- [Librem Mini](purism/librem_mini.md)
-
 ## Protectli
 
 - [FW2B / FW4B](protectli/fw2b_fw4b.md)
@@ -180,25 +156,7 @@ The boards in this section are not real mainboards, but emulators.
 
 ## System76
 
-- [Adder Workstation 1](system76/addw1.md)
-- [Adder Workstation 2](system76/addw2.md)
-- [Bonobo Workstation 14](system76/bonw14.md)
-- [Darter Pro 6](system76/darp6.md)
-- [Darter Pro 7](system76/darp7.md)
-- [Galago Pro 4](system76/galp4.md)
-- [Galago Pro 5](system76/galp5.md)
-- [Gazelle 15](system76/gaze15.md)
-- [Gazelle 16](system76/gaze16.md)
-- [Lemur Pro 9](system76/lemp9.md)
-- [Lemur Pro 10](system76/lemp10.md)
-- [Oryx Pro 5](system76/oryp5.md)
-- [Oryx Pro 6](system76/oryp6.md)
-- [Oryx Pro 7](system76/oryp7.md)
-- [Oryx Pro 8](system76/oryp8.md)
-
-## Texas Instruments
-
-- [Beaglebone Black](ti/beaglebone-black.md)
+- [Lemur Pro](system76/lemp9.md)
 
 ## UP
 

Documentation/mainboard/intel/kblrvp11.md

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

Documentation/mainboard/kontron/mal10.md

@@ -1,100 +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.
-
-## Untested
-
-- IGD/LVDS
-- SDIO
-
-## Tested and working
-
-- Kontron CPLD/EC (Serial ports, I2C port, GPIOs)
-- NCT7802 [HWM](#Hardware Monitor)
-- USB2/3
-- Gigabit Ethernet ports
-- eMMC
-- SATA
-- PCIe ports
-- IGD/DP
-
-## TODO
-- Onboard audio (codec IDT 92HD73C1X5, currently disabled)
-- S3 suspend/resume
-
-[mAL10]: https://www.kontron.com/products/iot/iot-industry-4.0/iot-ready-boards-and-modules/com-express/com-express-mini/come-mal10-e2-.html
-[W25Q128FV]: https://www.winbond.com/resource-files/w25q128fv%20rev.m%2005132016%20kms.pdf
-[flashrom]: https://flashrom.org/Flashrom
-[NCT7802Y]: https://www.nuvoton.com/products/cloud-computing/hardware-monitors/desktop-server-series/nct7802y/?__locale=en
-[crashes]: https://pastebin.com/cpCfrPCL

Documentation/mainboard/lenovo/Ivy_Bridge_series.md

@@ -25,7 +25,7 @@ This information is valid for all supported models, except T430s, [T431s](t431s.
 
 ## Installation instructions
 * Update the EC firmware, as there's no support for EC updates in coreboot.
-* Do **NOT** accidentally swap pins or power on the board while a SPI flasher
+* Do **NOT** accidently swap pins or power on the board while a SPI flasher
   is connected. It will permanently brick your device.
 * It's recommended to only flash the BIOS region. In that case you don't
   need to extract blobs from vendor firmware.
@@ -76,7 +76,7 @@ region. The update is then written into the EC once.
 
 [fl]: flashlayout_Ivy_Bridge.svg
 
-## Reducing Intel Management Engine firmware size
+## Reducing Intel Managment Engine firmware size
 
 It is possible to reduce the Intel ME firmware size to free additional
 space for the `bios` region. This is usually referred to as *cleaning the ME* or

Documentation/mainboard/lenovo/Sandy_Bridge_series.md

@@ -22,12 +22,8 @@
 ```
 
 ## Installation instructions
-
-Flashing coreboot for the first time needs to be done using an external
-programmer, because vendor firmware prevents rewriting the BIOS region.
-
 * Update the EC firmware, as there's no support for EC updates in coreboot.
-* Do **NOT** accidentally swap pins or power on the board while a SPI flasher
+* Do **NOT** accidently swap pins or power on the board while a SPI flasher
   is connected. It will destroy your device.
 * It's recommended to only flash the BIOS region. In that case you don't
   need to extract blobs from vendor firmware.
@@ -48,7 +44,7 @@ region. The update is then written into the EC once.
 
 [fl]: flashlayout_Sandy_Bridge.svg
 
-## Reducing Intel Management Engine firmware size
+## Reducing Intel Managment Engine firmware size
 
 It is possible to reduce the Intel ME firmware size to free additional
 space for the `bios` region. This is usually referred to as *cleaning the ME* or

Documentation/mainboard/lenovo/montevina_series.md

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

Documentation/mainboard/lenovo/t420.md

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

Documentation/mainboard/lenovo/t440p.md

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

Documentation/mainboard/lenovo/vboot.md

@@ -28,7 +28,7 @@ to boot and flash a working image to the A/B partition.
 
 ## 8 MiB ROM limitation
 *Lenovo* devices with 8 MiB ROM only have a `RO`+`A` partition enabled in the
-default FMAP. They are missing the `B` partition, due to size constraints.
+default FMAP. They are missing the `B` partition, due to size constaints.
 You can still provide your own FMAP if you need `RO`+`A`+`B` partitions.
 
 ## CMOS

Documentation/mainboard/msi/ms7707/ms7707.md

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

Documentation/mainboard/ocp/deltalake.md

@@ -6,42 +6,27 @@ Delta Lake server platform.
 ## Introduction
 
 OCP Delta Lake server platform is a component of multi-host server system
-Yosemite-V3. Both [Delta Lake server design spec] and [Yosemite-V3 design
-spec] were contributed to [OCP].
+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.
-Intel Cooper Lake Scalable Processor was launched in Q2 2020.
+Delta Lake server is a single socket Cooper Lake Scalable Processor server.
 
 Yosemite-V3 has multiple configurations. Depending on configurations, it may
-host up to 4 Delta Lake servers (blades) in one sled.
+host up to 4 Delta Lake servers in one sled.
 
-The Yosemite-V3 system is in mass production. Facebook, Intel and partners
-jointly develop Open System Firmware (OSF) solution on Delta Lake as an alternative
-solution. The OSF solution is based on FSP/coreboot/LinuxBoot stack. The
-OSF solution reached production quality for some use cases in July, 2021.
+Yosemite-V3 and Delta Lake are currently in DVT phase. Facebook, Intel and partners
+jointly develop FSP/coreboot/LinuxBoot stack on Delta Lake as an alternative solution.
 
-## How to build
+## Required blobs
 
-OSF code base is public at
-https://github.com/opencomputeproject/OpenSystemFirmware
-
-Run following commands to build Delta Lake OSF image from scratch:
-    git clone https://github.com/opencomputeproject/OpenSystemFirmware.git
-    cd OpenSystemFirmware/Wiwynn/deltalake && ./download_and_build.sh
-
-The Delta Lake OSF code base leverages [osf-builder] to sync down coreboot,
-Linux kernel and u-root code from their upstream repo, and sync down needed
-binary blobs. [osf-builder] also provides the top level build system.
-
-Delta Lake server OSF solution requires following binary blobs:
+This board currently requires:
 - FSP blob: The blob (Intel Cooper Lake Scalable Processor Firmware Support Package)
-  can be downloaded from https://github.com/intel/FSP/tree/master/CedarIslandFspBinPkg.
-- Microcode: Available through github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.
-  coreboot.org mirrors this repo and by default the correct binary is included.
-- ME binary: Ignition binary can be downloaded from
-	https://github.com/tianocore/edk2-non-osi/tree/master/Silicon/Intel/PurleySiliconBinPkg/MeFirmware
-- ACM binaries: only required for CBnT enablement. Available under NDA with Intel.
-- Payload: LinuxBoot is necessary when LinuxBoot is used as the coreboot payload.
+  is not yet available to the public. It will be made public some time after the MP
+  (Mass Production) of CooperLake Scalable Processor when the FSP is mature.
+- Microcode: Not yet available to the public.
+- ME binary: Not yet available to the public.
+
+## Payload
+- LinuxBoot: This is necessary only if you use LinuxBoot as coreboot payload.
   U-root as initramfs, is used in the joint development. It can be built
   following [All about u-root].
 
@@ -61,6 +46,36 @@ To power off/on the host:
 To connect to console through SOL (Serial Over Lan):
     sol-util slotx
 
+## Working features
+The solution is developed using LinuxBoot payload with Linux kernel 5.2.9, and [u-root]
+as initramfs.
+- SMBIOS:
+    - Type 0 -- BIOS Information
+    - Type 1 -- System Information
+    - Type 2 -- Baseboard Information
+    - Type 3 -- System Enclosure or Chassis
+    - Type 4 -- Processor Information
+    - Type 8 -- Port Connector Information
+    - Type 9 -- PCI Slot Information
+    - Type 11 -- OEM String
+    - Type 13 -- BIOS Language Information
+    - Type 16 -- Physical Memory Array
+    - Type 19 -- Memory Array Mapped Address
+    - Type 127 -- End-of-Table
+
+- BMC integration:
+    - BMC readiness check
+    - IPMI commands
+    - watchdog timer
+    - POST complete pin acknowledgement
+- SEL record generation
+- Early serial output
+- port 80h direct to GPIO
+- ACPI tables: APIC/DSDT/FACP/FACS/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
+- Skipping memory training upon subsequent reboots by using MRC cache
+- BMC crash dump
+- Error injection through ITP
+
 ## Firmware configurations
 [ChromeOS VPD] is used to store most of the firmware configurations.
 RO_VPD region holds default values, while RW_VPD region holds customized
@@ -69,108 +84,29 @@ values.
 VPD variables supported are:
 - firmware_version: This variable holds overall firmware version. coreboot
   uses that value to populate smbios type 1 version field.
-- bmc_bootorder_override: When it's set to 1 IPMI OEM command can override boot
-  order. The boot order override is done in the u-root LinuxBoot payload.
-- systemboot_log_level: u-root package systemboot log levels, would be mapped to
-  quiet/verbose in systemboot as that is all we have for now. 5 to 8 would be
-  mapped to verbose, 0 to 4 and 9 would be mapped to quiet.
-- VPDs affecting coreboot are listed/documented in [src/mainboard/ocp/deltalake/vpd.h].
-
-## Features
-The solution is developed using LinuxBoot payload with Linux kernel 5.2.9,
-and [u-root] as initramfs.
-- SMBIOS:
-    - Type 0 -- BIOS Information
-    - Type 1 -- System Information
-    - Type 2 -- Baseboard Information
-    - Type 3 -- System Enclosure or Chassis
-    - Type 4 -- Processor Information
-    - Type 7 -- Cache Information
-    - Type 8 -- Port Connector Information
-    - Type 9 -- PCI Slot Information
-    - Type 11 -- OEM String
-    - Type 16 -- Physical Memory Array
-    - Type 17 -- Memory Device
-    - Type 19 -- Memory Array Mapped Address
-    - Type 32 -- System Boot Information
-    - Type 38 -- IPMI Device Information
-    - Type 41 -- Onboard Devices Extended Information
-    - Type 127 -- End-of-Table
-- BMC integration:
-    - BMC readiness check
-    - IPMI commands
-    - watchdog timer
-    - POST complete pin acknowledgement
-    - Check BMC version: ipmidump -device
-- SEL record generation
-- Converged Bootguard and TXT (CBnT)
-    - TPM
-    - Bootguard profile 0T
-    - TXT
-    - SRTM
-    - DRTM (verified through tboot)
-		- unsigned KM/BPM generation
-		- KM/BPM signing
-		- memory secret clearance upon ungraceful shutdown
-- Early serial output
-- port 80h direct to GPIO
-- ACPI tables: APIC/DMAR/DSDT/EINJ/FACP/FACS/HEST/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
-- Skipping memory training upon subsequent reboots by using MRC cache
-- BMC crash dump
-- Error injection through ITP
-- Versions
-    - Check FSP version: cbmem | grep LB_TAG_PLATFORM_BLOB_VERSION
-    - Check Microcode version: cat /proc/cpuinfo | grep microcode
-- Devices:
-    - Boot drive
-    - All 5 data drives
-    - NIC card
-- Power button
-- localboot
-- netboot from IPv6
-- RAS (SMI handlers not upstreamed)
-    - EINJ/HEST
-    - error injection through ITP
-    - memory error handling
-    - PCIe error handling
-    - PCIe live error recovery (LER)
-
-## Stress/performance tests passed
-- OS warm reboot (1000 cycles)
-- DC reboot (1000 cycles)
-- AC reboot (1000 cycle)
-- Mprime test (6 hours)
-- StressAppTest (6 hours)
-- Ptugen (6 hours)
-
-## Performance on par with traditional firmware
-- coremark
-- FIO
-- Iperf(IPv6)
-- Linpack
-- Intel MLC (memory latency and bandwidth)
-- SpecCPU
-- stream
-
-## Other tests passed
-- Power
-- Thermal
-- coreboot address sanitizer (both romstage and ramstage)
-- Intel selftest tool (all errors analyzed; applicable errors clean)
 
 ## Known issues
-- HECI access at OS run time:
-    - spsInfoLinux64 command fail to return ME version
-    - ptugen command fail to get memory power
-- CLTT (Closed Loop Thermal Throttling, eg. thermal protection for DIMMs)
-- ProcHot (thermal protection for processors)
+- Even though CPX-SP FSP is based on FSP 2.2 framework, it does not
+  support FSP_USES_CB_STACK. An IPS ticket is filed with Intel.
+- VT-d is not supported. An IPS ticket is filed with Intel.
+- PCIe bifuration is not supported. An IPS ticket is filed with Intel.
+- ME based power capping. This is a bug in ME. An IPS ticket is filed
+  with Intel.
+- RO_VPD region as well as other RO regions are not write protected.
+- HECI is not set up correctly, so BMC is not able to get PCH and DIMM
+  temperature sensor readings.
 
 ## Feature gaps
-- flashrom command not able to update ME region
-- ACPI BERT table
-- PCIe hotplug through VPP (Virtual Pin Ports)
-- RO_VPD region as well as other RO regions are not write protected
-- Not able to selectively enable/disable core
+- Delta Lake DVT is not supported, as we only have Delta Lake EVT servers
+  at the moment.
+- SMBIOS:
+    - Type 7 -- Cache Information
+    - Type 17 -- Memory Device
+    - Type 38 -- IPMI Device Information
+    - Type 41 -- Onboard Devices Extended Information
+- ACPI:
+    - DMAR
+- PFR/CBnT
 
 ## Technology
 
@@ -180,17 +116,13 @@ and [u-root] as initramfs.
 +------------------------+---------------------------------------------+
 | BMC                    | Aspeed AST 2500                             |
 +------------------------+---------------------------------------------+
-| PCH                    | Intel Lewisburg C620 Series                 |
+| PCH                    | Intel Lewisburg C621                        |
 +------------------------+---------------------------------------------+
 ```
 
 [OCP]: https://www.opencompute.org
-[Delta Lake server design spec]: https://www.opencompute.org/documents/delta-lake-1s-server-design-specification-1v05-pdf
-[Yosemite-V3 design spec]: https://www.opencompute.org/documents/ocp-yosemite-v3-platform-design-specification-1v16-pdf
-[osf-builder]: https://github.com/facebookincubator/osf-builder
 [OCP virtual summit 2020]: https://www.opencompute.org/summit/virtual-summit/schedule
 [flashrom]: https://flashrom.org/Flashrom
 [All about u-root]: https://github.com/linuxboot/book/tree/master/u-root
 [u-root]: https://u-root.org/
 [ChromeOS VPD]: https://chromium.googlesource.com/chromiumos/platform/vpd/+/master/README.md
-[src/mainboard/ocp/deltalake/vpd.h]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/ocp/deltalake/vpd.h

Documentation/mainboard/ocp/tiogapass.md

@@ -51,7 +51,7 @@ To connect to console through SOL (Serial Over Lan):
 
 ## Known issues / feature gaps
 - C6 state is not supported. Workaround is to disable C6 support through
-  target OS and Linuxboot kernel parameter, such as "cpuidle.off=1".
+  target OS and Linuxboot kernel paramter, such as "cpuidle.off=1".
 - SMI handlers are not implemented.
 - xSDT tables are not fully populated, such as processor/socket devices,
   PCIe bridge devices.

Documentation/mainboard/purism/librem_14.md

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