diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/acronyms.md | 4 | ||||
| -rw-r--r-- | Documentation/lib/flashmap.md | 2 | ||||
| -rw-r--r-- | Documentation/lib/fw_config.md | 10 | ||||
| -rw-r--r-- | Documentation/northbridge/intel/haswell/mrc.bin.md | 2 | ||||
| -rw-r--r-- | Documentation/security/vboot/index.md | 2 | ||||
| -rw-r--r-- | Documentation/soc/intel/cse_fw_update/cse_fw_update.md | 2 | ||||
| -rw-r--r-- | Documentation/technotes/2015-11-rebuilding-coreboot-image-generation.md | 16 | ||||
| -rw-r--r-- | Documentation/util.md | 4 | ||||
| -rw-r--r-- | Documentation/util/ifdtool/layout.md | 2 |
9 files changed, 22 insertions, 22 deletions
diff --git a/Documentation/acronyms.md b/Documentation/acronyms.md index 7987e9f51e..32a6655b1b 100644 --- a/Documentation/acronyms.md +++ b/Documentation/acronyms.md @@ -185,7 +185,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool Unit**](http://en.wikipedia.org/wiki/Central_processing_unit) * CPUID - x86: [**CPU Identification**](https://en.wikipedia.org/wiki/CPUID) opcode * Cr50 - Google: The first generation Google Security Chip (GSC) used on - Chrome OS devices. + ChromeOS devices. * CRB - Customer Reference Board * CRLF - Carriage Return, Line Feed - \\r\\n - The standard window EOL (End-of-Line) marker. @@ -914,7 +914,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool * TGL - Intel: Tigerlake * THC - Touch Host Controller * Ti50 - Google: The next generation GSC (Google Security chip) on - Chrome OS devices after Cr50 + ChromeOS devices after Cr50 * TLA - Techtronics Logic Analyzer * TLA - Three Letter Acronym * TLB - [**Translation Lookside diff --git a/Documentation/lib/flashmap.md b/Documentation/lib/flashmap.md index 68d0ab5dc7..f0816cf493 100644 --- a/Documentation/lib/flashmap.md +++ b/Documentation/lib/flashmap.md @@ -4,7 +4,7 @@ [Flashmap](https://code.google.com/p/flashmap) (FMAP) is a binary format to describe partitions in a flash chip. It was added to coreboot to support the -requirements of Chromium OS firmware but then was also used in other scenarios +requirements of ChromiumOS firmware but then was also used in other scenarios where precise placement of data in flash was necessary, or for data that is written to at runtime, as CBFS is considered too fragile for such situations. The Flashmap implementation inside coreboot is the de facto standard today. diff --git a/Documentation/lib/fw_config.md b/Documentation/lib/fw_config.md index d5f0bb2d06..c9eaeecdab 100644 --- a/Documentation/lib/fw_config.md +++ b/Documentation/lib/fw_config.md @@ -8,8 +8,8 @@ BIOS image to be used across a wide variety of devices which may have key differ otherwise similar enough to use the same coreboot build target. The initial implementation is designed to take advantage of a bitmask returned by the Embedded -Controller on Google Chrome OS devices which allows the manufacturer to use the same firmware -image across multiple devices by selecting various options at runtime. See the Chromium OS +Controller on Google ChromeOS devices which allows the manufacturer to use the same firmware +image across multiple devices by selecting various options at runtime. See the ChromiumOS [Firmware Config][1] documentation for more information. This firmware configuration interface differs from the CMOS option interface in that this @@ -91,7 +91,7 @@ file in CBFS use the value it contains when matching fields and options. ### Embedded Controller -Google Chrome OS devices support an Embedded Controller interface for reading and writing the +Google ChromeOS devices support an Embedded Controller interface for reading and writing the firmware configuration value, along with other board-specific information. It is possible for coreboot to read this value at boot on systems that support this feature. @@ -101,9 +101,9 @@ possible by enabling the CBFS source and coreboot will look in CBFS first for a before asking the embedded controller. It is also possible to adjust the value in the embedded controller *(after disabling write -protection)* with the `ectool` command in a Chrome OS environment. +protection)* with the `ectool` command in a ChromeOS environment. -For more information on the firmware configuration field on Chrome OS devices see the Chromium +For more information on the firmware configuration field on ChromeOS devices see the Chromium documentation for [Firmware Config][1] and [Board Info][2]. [1]: http://chromium.googlesource.com/chromiumos/docs/+/master/design_docs/firmware_config.md diff --git a/Documentation/northbridge/intel/haswell/mrc.bin.md b/Documentation/northbridge/intel/haswell/mrc.bin.md index edfe4b8b84..c24305eb7e 100644 --- a/Documentation/northbridge/intel/haswell/mrc.bin.md +++ b/Documentation/northbridge/intel/haswell/mrc.bin.md @@ -3,7 +3,7 @@ All Haswell boards supported by coreboot currently require a proprietary blob in order to initialise the DRAM and a few other components. The blob, named `mrc.bin`, largely consists of Intel's memory reference code -(MRC), but it has been tailored specifically for Chrome OS. It is just +(MRC), but it has been tailored specifically for ChromeOS. It is just under 200 KiB in size. Another name for `mrc.bin` is the system agent binary. diff --git a/Documentation/security/vboot/index.md b/Documentation/security/vboot/index.md index 5ee0492486..1a17c20e63 100644 --- a/Documentation/security/vboot/index.md +++ b/Documentation/security/vboot/index.md @@ -328,7 +328,7 @@ Google's Chromebooks have some special features: ### Developer Mode 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 +This may be a another (beta) version of ChromeOS, or another flavor of GNU/Linux. Use of developer mode does not void the system warranty. Upon entry into developer mode, all locally saved data on the system is lost. This prevents someone from entering developer mode to subvert the system diff --git a/Documentation/soc/intel/cse_fw_update/cse_fw_update.md b/Documentation/soc/intel/cse_fw_update/cse_fw_update.md index 98fe310113..54a5e615c8 100644 --- a/Documentation/soc/intel/cse_fw_update/cse_fw_update.md +++ b/Documentation/soc/intel/cse_fw_update/cse_fw_update.md @@ -8,7 +8,7 @@ power transition flows. ## Problem Statement -Currently, on Chromium OS Systems, CSE region is not updatable. So, new CSE FW +Currently, on ChromiumOS Systems, CSE region is not updatable. So, new CSE FW versions that are released by Intel to address important functional and security bugs post-product launch will not be available to the end-user. Hence, the proposed solution allows in-field CSE FW update to propagate those bug fixes diff --git a/Documentation/technotes/2015-11-rebuilding-coreboot-image-generation.md b/Documentation/technotes/2015-11-rebuilding-coreboot-image-generation.md index 9accbfe65d..a3f81bf4f1 100644 --- a/Documentation/technotes/2015-11-rebuilding-coreboot-image-generation.md +++ b/Documentation/technotes/2015-11-rebuilding-coreboot-image-generation.md @@ -3,7 +3,7 @@ Rebuilding coreboot image generation Current situation ----------------- -Chrome OS (CrOS) probably has the most complex image bundling process in the +ChromeOS (CrOS) probably has the most complex image bundling process in the coreboot ecosystem. To make CrOS features more accessible to the wider coreboot community, we want to move these capabilities into upstream coreboot’s build system. @@ -21,7 +21,7 @@ putting more data (eg. the bitmap data, keys) as raw data into other fmap regions. With the recent addition of more files to CBFS, both on the coreboot side -(dsdt, FSP, and so on) and with Chrome OS specifics (eg. more files describing +(dsdt, FSP, and so on) and with ChromeOS specifics (eg. more files describing boot screens) we either need to expand the scope of bundle\_firmware or move the capability to build complex images to upstream coreboot’s build system. This document proposes to do the latter and outlines how this could be @@ -41,14 +41,14 @@ images: variable to guarantee success if there’s enough room for the files. While that could be added, that becomes more make macro work indistinguishable from magic that people fail to understand, break and with good reason complain about - to work around such issues, Chrome OS firmware uses a custom tool with even + to work around such issues, ChromeOS firmware uses a custom tool with even more special cases to finally build the image it needs. If coreboot upstream is to support vboot, it should also be powerful enough not to need magic tools that only live within downstream projects. Requirements ------------ -A complete Chrome OS coreboot image consists of (depending on the device) +A complete ChromeOS coreboot image consists of (depending on the device) * platform specific data in raw fmap regions (eg IFD, ME firmware), * the bootblock (coming from the bootblock), * three copies of coreboot, consisting of the stages (verstage, romstage, @@ -68,7 +68,7 @@ using a yet to be implemented switching scheme based on fmaps) consists of * payload plus data (with each of the coreboot copies), Since a single platform is potentially built with different payload -configurations (eg. modding a Chromebook to not use the verified Chrome OS +configurations (eg. modding a Chromebook to not use the verified ChromeOS boot scheme), some concerns need to be kept separate: * Platform requirements that have nothing to do with the payload or boot schemes * IFD, ME, … need to copied to the right place @@ -111,11 +111,11 @@ Boot method manifest -------------------- The boot method manifest can subdivide the BIOS region, eg. using it directly (for coreboot’s “simple” bootblock), splitting it in two (for coreboot’s -fallback/normal) or in many parts (for Chrome OS, which requires two CBFS +fallback/normal) or in many parts (for ChromeOS, which requires two CBFS regions, one for GBB, several for VPD, …). It also specifies which of the file lists specified earlier belong in which region (eg. with verstage verifying romstage, verstage needs to be only in -Chrome OS’ RO region, while romstage belongs in RO and both RW regions). +ChromeOS’ RO region, while romstage belongs in RO and both RW regions). It can also specify a post processing step that is executed before the chipset’s. @@ -148,7 +148,7 @@ It specifies an IFD region, an ME, and the BIOS region. After the image is built, the entire image needs to be processed (although the tool likely works only on a small part of it) -It’s built in a Chrome OS-like configuration (simplified at places to avoid +It’s built in a ChromeOS-like configuration (simplified at places to avoid distracting from the important parts), so it has three CBFS regions, and several data regions for its own purpose (similar to GBB, FWID, VPD, …). After the regions are filled, one data region must be post-processed to contain diff --git a/Documentation/util.md b/Documentation/util.md index 3bdb6fafaf..9823a143ce 100644 --- a/Documentation/util.md +++ b/Documentation/util.md @@ -47,9 +47,9 @@ file `Python` * _rmodtool_ - Creates rmodules `C` * _ifwitool_ - For manipulating IFWI `C` * __cbmem__ - CBMEM parser to read e.g. timestamps and console log `C` -* __chromeos__ - These scripts can be used to access Chrome OS +* __chromeos__ - These scripts can be used to access ChromeOS resources, for example to extract System Agent reference code and other -blobs (e.g. mrc.bin, refcode, VGA option roms) from a Chrome OS +blobs (e.g. mrc.bin, refcode, VGA option roms) from a ChromeOS recovery image. `C` * __crossgcc__ - A cross toolchain builder for -elf toolchains (ie. no libc support) `Bash` diff --git a/Documentation/util/ifdtool/layout.md b/Documentation/util/ifdtool/layout.md index f89cc0308c..c898ce3828 100644 --- a/Documentation/util/ifdtool/layout.md +++ b/Documentation/util/ifdtool/layout.md @@ -29,7 +29,7 @@ way to categorize anything required by the SoC but not provided by coreboot. +------------+------------------+-----------+-------------------------------------------+ | 4 | Platform Data | SI_PDR | | +------------+------------------+-----------+-------------------------------------------+ -| 8 | EC Firmware | SI_EC | Most Chrome OS devices do not use this | +| 8 | EC Firmware | SI_EC | Most ChromeOS devices do not use this | | | | | region; EC firmware is stored in BIOS | | | | | region of flash | +------------+------------------+-----------+-------------------------------------------+ |