treewide: Unify Google branding
Branding changes to unify and update Chrome OS to ChromeOS (removing the space). This CL also includes changing Chromium OS to ChromiumOS as well. BUG=None TEST=N/A Change-Id: I39af9f1069b62747dbfeebdd62d85fabfa655dcd Signed-off-by: Jon Murphy <jpmurphy@google.com> Reviewed-on: https://review.coreboot.org/c/coreboot/+/65479 Reviewed-by: Jack Rosenthal <jrosenth@chromium.org> Tested-by: build bot (Jenkins) <no-reply@coreboot.org> Reviewed-by: Felix Singer <felixsinger@posteo.net>
This commit is contained in:
@@ -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
|
||||
|
@@ -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.
|
||||
|
@@ -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
|
||||
|
@@ -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.
|
||||
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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
|
||||
|
@@ -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`
|
||||
|
@@ -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 |
|
||||
+------------+------------------+-----------+-------------------------------------------+
|
||||
|
Reference in New Issue
Block a user