GNUBoot
/
coreboot-kgpe-d16
2
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation/Intel: Adjust heading levels 

Adjust the headings so that there is only one h1 tag per file.

Change-Id: I53f9ee47957fcde521b64c0123dac10f051c681c
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-on: https://review.coreboot.org/25684
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This commit is contained in:
Jonathan Neuschäfer 2018-04-15 20:33:50 +02:00 committed by Patrick Georgi
parent a2e17586dc
commit 7719d50352
7 changed files with 72 additions and 70 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Documentation/Intel/Board/board.html
View File

@ -22,7 +22,7 @@
<hr>
<h1><a name="RequiredFiles">Required Files</a></h1>
<h2><a name="RequiredFiles">Required Files</a></h2>
<p>
Create the board directory as src/mainboard/&lt;Vendor&gt;/&lt;Board&gt;.
</p>
@ -80,7 +80,7 @@
<hr>
<h1><a name="SerialOutput">Enable Serial Output</a></h1>
<h2><a name="SerialOutput">Enable Serial Output</a></h2>
<p>
Use the following steps to enable serial output:
</p>
@ -103,7 +103,7 @@
<hr>
<h1><a name="SpdData">Memory Timing Data</a></h1>
<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>
@ -183,7 +183,7 @@
<hr>
<h1><a name="DisablePciDevices">Disable PCI Devices</a></h1>
<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:
@ -209,7 +209,7 @@
<hr>
<h1><a name="AcpiTables">ACPI Tables</a></h1>
<h2><a name="AcpiTables">ACPI Tables</a></h2>
<ol>
<li>Edit Kconfig
<ol type="A">

8
Documentation/Intel/Board/galileo.html
View File

@ -26,7 +26,7 @@
<hr>
<h1>Galileo Board Documentation</h1>
<h2>Galileo Board Documentation</h2>
<ul>
<li>Common Components
<ul>
@ -46,7 +46,7 @@
<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>
<h2>Galileo Gen 2 Board Documentation</h2>
<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>
@ -70,7 +70,7 @@
</li>
</ul>
<h2>Galileo Gen 1 Board Documentation</h2>
<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>
@ -89,7 +89,7 @@
<hr>
<h1>Debug Tools</h1>
<h2>Debug Tools</h2>
<ul>
<li>Flash Programmer:
<ul>

14
Documentation/Intel/SoC/quark.html
View File

@ -28,7 +28,7 @@
<hr>
<h1>Quark&trade; Documentation</h1>
<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>:
@ -49,7 +49,7 @@
<hr>
<h1><a name="CorebootPayloadPkg">Quark&trade; EDK2 CorebootPayloadPkg</a></h1>
<h2><a name="CorebootPayloadPkg">Quark&trade; EDK2 CorebootPayloadPkg</a></h2>
<p>
Build Instructions:
</p>
@ -81,7 +81,7 @@ dir Build\CorebootPayloadPkgIA32\DEBUG_VS2015x86\FV\UEFIPAYLOAD.fd
<hr>
<h1><a name="BuildEnvironment">Quark&trade; EDK2 Build Environment</a></h1>
<h2><a name="BuildEnvironment">Quark&trade; EDK2 Build Environment</a></h2>
<p>
Use the following steps to setup a build environment:
</p>
@ -118,7 +118,7 @@ edksetup.bat
<hr>
<h1><a name="QuarkFsp">Quark&trade; FSP</a></h1>
<h2><a name="QuarkFsp">Quark&trade; FSP</a></h2>
<p>
Getting the Quark FSP source:
</p>
@ -130,7 +130,7 @@ Getting the Quark FSP source:
<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>
<h2>Building QuarkFspPkg</h2>
<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
@ -157,7 +157,7 @@ Build commands shown building debug FSP:
</li>
</ul>
<h2>Copying FSP files into coreboot Source Tree</h2>
<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:
@ -182,7 +182,7 @@ Script files:
<hr>
<h1>Quark&trade; EDK2 BIOS</h1>
<h2>Quark&trade; EDK2 BIOS</h2>
<p>
Build Instructions:
</p>

50
Documentation/Intel/SoC/soc.html
View File

@ -39,7 +39,7 @@
<hr>
<h1><a name="RequiredFiles">Required Files</a></h1>
<h2><a name="RequiredFiles">Required Files</a></h2>
<p>
Create the directory as src/soc/&lt;Vendor&gt;/&lt;Chip Family&gt;.
</p>
@ -69,13 +69,13 @@
<hr>
<h1><a name="Descriptor">Start Booting</a></h1>
<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>
<h2>Intel Firmware Descriptor</h2>
<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
@ -84,7 +84,7 @@
<pre><code>dd if=descriptor.bin of=build/coreboot.rom conv=notrunc >/dev/null 2>&1</code></pre>
<h2><a name="MEB">Management Engine Binary</a></h2>
<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
@ -96,14 +96,14 @@ mv build/coreboot.rom.new build/coreboot.rom
</code></pre>
<h2><a name="EarlyDebug">Early Debug</a></h2>
<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>
<h2>Success</h2>
<h3>Success</h3>
<p>
When the reset vector is successfully invoked, port 0x80 will output the following value:
</p>
@ -118,7 +118,7 @@ mv build/coreboot.rom.new build/coreboot.rom
<hr>
<h1><a name="Bootblock">Bootblock</a></h1>
<h2><a name="Bootblock">Bootblock</a></h2>
<p>
Implement the bootblock using the following steps:
</p>
@ -213,7 +213,7 @@ mv build/coreboot.rom.new build/coreboot.rom
<hr>
<h1><a name="TempRamInit">TempRamInit</a></h1>
<h2><a name="TempRamInit">TempRamInit</a></h2>
<p>
Enable the call to TempRamInit in two stages:
</p>
@ -223,7 +223,7 @@ mv build/coreboot.rom.new build/coreboot.rom
</ol>
<h2>Find FSP Binary</h2>
<h3>Find FSP Binary</h3>
<p>
Use the following steps to locate the FSP binary:
</p>
@ -267,7 +267,7 @@ Use the following steps to locate the FSP binary:
</ol>
<h2>Calling TempRamInit</h2>
<h3>Calling TempRamInit</h3>
<p>
Use the following steps to debug the call to TempRamInit:
</p>
@ -301,9 +301,9 @@ Use the following steps to debug the call to TempRamInit:
<hr>
<h1><a name="Romstage">Romstage</a></h1>
<h2><a name="Romstage">Romstage</a></h2>
<h2><a name="SerialOutput">Serial Output</a></h2>
<h3><a name="SerialOutput">Serial Output</a></h3>
<p>
The following steps add the serial output support for romstage:
</p>
@ -339,7 +339,7 @@ Use the following steps to debug the call to TempRamInit:
</ol>
<h2><a name="PreviousSleepState">Determine Previous Sleep State</a></h2>
<h3><a name="PreviousSleepState">Determine Previous Sleep State</a></h3>
<p>
The following steps implement the code to get the previous sleep state:
</p>
@ -362,7 +362,7 @@ Use the following steps to debug the call to TempRamInit:
</ol>
<h2><a name="MemoryInit">MemoryInit Support</a></h2>
<h3><a name="MemoryInit">MemoryInit Support</a></h3>
<p>
The following steps implement the code to support the FSP MemoryInit call:
</p>
@ -390,7 +390,7 @@ Use the following steps to debug the call to TempRamInit:
</ol>
<h2><a name="DisableShadowRom">Disable Shadow ROM</a></h2>
<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
@ -402,9 +402,9 @@ Use the following steps to debug the call to TempRamInit:
<hr>
<h1><a name="Ramstage">Ramstage</a></h1>
<h2><a name="Ramstage">Ramstage</a></h2>
<h2><a name="DeviceTree">Start Device Tree Processing</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
@ -417,7 +417,7 @@ Use the following steps to debug the call to TempRamInit:
state of the state machine.
</p>
<h3><a name="ChipOperations">Chip Operations</a></h3>
<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:
@ -437,7 +437,7 @@ Use the following steps to debug the call to TempRamInit:
<li>Edit src/soc/&lt;SoC Vendor&gt;/&lt;SoC Family&gt;/Makefile.inc and add chip.c to ramstage</li>
</ol>
<h3>Domain Operations</h3>
<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
@ -482,7 +482,7 @@ Use the following steps to debug the call to TempRamInit:
</ol>
<h2><a name="DeviceDrivers">PCI Device Drivers</a></h2>
<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
@ -509,7 +509,7 @@ Use the following steps to debug the call to TempRamInit:
</li>
</ol>
<h3><a name="SubsystemIds">Subsystem IDs</a></h3>
<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
@ -534,7 +534,7 @@ Use the following steps to debug the call to TempRamInit:
<h2>Set up the <a name="MemoryMap">Memory Map</a></h2>
<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
@ -571,12 +571,12 @@ Use the following steps to debug the call to TempRamInit:
<hr>
<h1><a name="AcpiTables">ACPI Tables</a></h1>
<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>
<h2>FADT</h2>
<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>
@ -679,7 +679,7 @@ Use the following steps to debug the call to TempRamInit:
<hr>
<h1><a name="LegacyHardware">Legacy Hardware</a></h1>
<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>

12
Documentation/Intel/fsp1_1.html
View File

@ -5,7 +5,9 @@
</head>
<body>
<h1>x86 FSP 1.1 Integration</h1>
<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
@ -26,8 +28,8 @@
</ul>
<hr>
<h1><a name="RequiredFiles">Required Files</a></h1>
<h2><a name="corebootRequiredFiles">coreboot Required Files</a></h2>
<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>
@ -47,7 +49,7 @@
<hr>
<h1><a name="FspBinary">Add the FSP Binary File to coreboot File System</a></h1>
<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>
@ -59,7 +61,7 @@
<hr>
<h1><a name="corebootFspDebugging">Enable coreboot/FSP Debugging</a></h1>
<h2><a name="corebootFspDebugging">Enable coreboot/FSP Debugging</a></h2>
<p>
Set the following Kconfig values:
</p>

20
Documentation/Intel/index.html
View File

@ -5,15 +5,15 @@
</head>
<body>
<h1>Intel&reg; x86 Boards</h1>
<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>
<h1>Intel&reg; x86 SoCs</h1>
<h2>Intel&reg; x86 SoCs</h2>
<ul>
<li><a target="_blank" href="SoC/quark.html">Quark&trade;</a></li>
</ul>
@ -21,7 +21,7 @@
<hr>
<h1>x86 coreboot Development</h1>
<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>
@ -35,7 +35,7 @@
<hr>
<h1>Payload Development</h1>
<h2>Payload Development</h2>
<ul>
<li><a target="_blank" href="SoC/quark.html#CorebootPayloadPkg">CorebootPayloadPkg</a>
<ul>
@ -50,13 +50,13 @@
<hr>
<h1><a name="Documentation">Documentation</a></h1>
<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>
<h2><a name="Edk2Documentation">EDK-II Documentation</a></h2>
<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>
@ -71,14 +71,14 @@
<li>VRF <a target="_blank" href="https://github.com/tianocore-docs/Docs/raw/master/Specifications/VFR_1_9.pdf">V1.9</a></li>
</ul>
<h2><a name="FspDocumentation">FSP Documentation</a></h2>
<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>
<h2><a name="FeatureDocumentation">Feature Documentation</a></h2>
<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>

26
Documentation/Intel/vboot.html
View File

@ -24,7 +24,7 @@ Google's vboot verifies the firmware and places measurements
within the TPM.
<hr>
<h1>Root of Trust</h1>
<h2>Root of Trust</h2>
<p>
When using vboot, the root-of-trust is basically the read-only portion of the
SPI flash. The following items factor into the trust equation:
@ -57,7 +57,7 @@ flash maintains the manufactured state during the system's lifetime.
</p>
<hr>
<h1>Firmware Layout</h1>
<h2>Firmware Layout</h2>
<p>
Several sections are added to the firmware layout to support vboot:
</p>
@ -71,7 +71,7 @@ Several sections are added to the firmware layout to support vboot:
The following sections describe the various portions of the flash layout.
</p>
<h2>Read-Only Section</h2>
<h3>Read-Only Section</h3>
<p>
The read-only section contains a coreboot file system (CBFS) that contains all
of the boot firmware necessary to perform recovery for the system. This
@ -87,14 +87,14 @@ size and must cover the entire read-only section which consists of:
<li>coreboot file system containing read-only recovery firmware</li>
</ul>
<h2>Google Binary Blob (GBB) Area</h2>
<h3>Google Binary Blob (GBB) Area</h3>
<p>
The GBB area is part of the read-only section. This area contains a 4096 or
8192 bit public root RSA key that is used to verify the VBLOCK area to obtain
the firmware signing key.
</p>
<h2>Recovery Firmware</h2>
<h3>Recovery Firmware</h3>
<p>
The recovery firmware is contained within a coreboot file system and consists
of:
@ -129,7 +129,7 @@ SPI flash device to boot the system.
</p>
<h2>Read/Write Section</h2>
<h3>Read/Write Section</h3>
<p>
The read/write sections contain an area which contains the firmware signing
@ -158,7 +158,7 @@ These files also produce the tables which get passed to the operating system.
</p>
<hr>
<h1>Firmware Updates</h1>
<h2>Firmware Updates</h2>
<p>
The read/write sections exist in one of three states:
</p>
@ -208,7 +208,7 @@ gets corrupted.
</p>
<hr>
<h1>Build Flags</h1>
<h2>Build Flags</h2>
<p>
The following Kconfig values need to be selected to enable vboot:
</p>
@ -255,7 +255,7 @@ systems in FW_MAIN_A and FW_MAIN_B.
</p>
<hr>
<h1>Signing the coreboot Image</h1>
<h2>Signing the coreboot Image</h2>
<p>
The following command script is an example of how to sign the coreboot image file.
This script is used on the Intel Galileo board and creates the GBB area and
@ -341,7 +341,7 @@ gbb_utility \
</code></pre>
<hr>
<h1>Boot Flow</h1>
<h2>Boot Flow</h2>
<p>
The reset vector exist in the read-only area and points to the bootblock entry
point. The only copy of the bootblock exists in the read-only area of the SPI
@ -367,7 +367,7 @@ not valid vboot falls back to the read-only area to boot into system recovery.
</p>
<hr>
<h1>Chromebook Special Features</h1>
<h2>Chromebook Special Features</h2>
<p>
Google's Chromebooks have some special features:
</p>
@ -376,7 +376,7 @@ Google's Chromebooks have some special features:
<li>Write-protect screw</li>
</ul>
<h2>Developer Mode</h2>
<h3>Developer Mode</h3>
<p>
Developer mode allows the user to use coreboot to boot another operating system.
This may be a another (beta) version of Chrome OS, or another flavor of
@ -386,7 +386,7 @@ This prevents someone from entering developer mode to subvert the system
security to access files on the local system or cloud.
</p>
<h2>Write Protect Screw</h2>
<h3>Write Protect Screw</h3>
<p>
Chromebooks have a write-protect screw which provides the ground to the
write-protect pin of the SPI flash. Google specifically did this to allow