diff options
| author | Martin Roth <martin@coreboot.org> | 2021-10-01 14:10:19 -0600 |
|---|---|---|
| committer | Martin Roth <martinroth@google.com> | 2021-10-05 18:06:24 +0000 |
| commit | 6c3ece9c9ef73db5c0e02cc5a41c98f46b86c3e9 (patch) | |
| tree | 23a804c556938f20002a2727ac62495a9bb982fe | |
| parent | d4c55353e044e157994eaf15b78103a9473e5440 (diff) | |
Documentation: Fix spelling errors
These issues were found and fixed by codespell, a useful tool for
finding spelling errors.
Signed-off-by: Martin Roth <martin@coreboot.org>
Change-Id: If2a8e97911420c19e9365d5c28810b998f2c2ac8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/58078
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
34 files changed, 42 insertions, 42 deletions
diff --git a/Documentation/RFC/chip.tex b/Documentation/RFC/chip.tex index 01f40c1e80..c67109231f 100644 --- a/Documentation/RFC/chip.tex +++ b/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 initalized. The current scope is for superio +are used, specified, and initialized. 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. diff --git a/Documentation/acpi/devicetree.md b/Documentation/acpi/devicetree.md index 5cbaf152d2..41f5901999 100644 --- a/Documentation/acpi/devicetree.md +++ b/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 busses (in contrast to PCI). This document discusses +as those behind I2C or SPI buses (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. diff --git a/Documentation/arch/x86/index.md b/Documentation/arch/x86/index.md index 0e14115db8..a30c5e25f8 100644 --- a/Documentation/arch/x86/index.md +++ b/Documentation/arch/x86/index.md @@ -92,6 +92,6 @@ Here's a list of known issues: page tables in ROM will be loaded and used, which breaks code and data as the page table doesn't contain the expected data. This in turn leads to undefined behaviour whenever the 'wrong' address is being read. -* Disabling paging in compability mode crashes the CPU. -* Returning from long mode to compability mode crashes the CPU. +* 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. diff --git a/Documentation/conf.py b/Documentation/conf.py index 3180fd9720..70b189a7f3 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -185,7 +185,7 @@ texinfo_documents = [ enable_auto_toc_tree = True class MyCommonMarkParser(CommonMarkParser): - # remove this hack once upsteam RecommonMark supports inline code + # remove this hack once upstream RecommonMark supports inline code def visit_code(self, mdnode): from docutils import nodes n = nodes.literal(mdnode.literal, mdnode.literal) diff --git a/Documentation/contributing/coding_style.md b/Documentation/contributing/coding_style.md index a8c7356bfe..4980659cc0 100644 --- a/Documentation/contributing/coding_style.md +++ b/Documentation/contributing/coding_style.md @@ -801,7 +801,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 compiletime constant, and as a +cases where a parameter is known to be a compile time 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. diff --git a/Documentation/contributing/project_ideas.md b/Documentation/contributing/project_ideas.md index 2f6f73825c..75c78caee1 100644 --- a/Documentation/contributing/project_ideas.md +++ b/Documentation/contributing/project_ideas.md @@ -202,9 +202,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 managment tasks and new board status uploads. +for management tasks and new board status uploads. -At least one older test result should be keept in the database. +At least one older test result should be kept 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 diff --git a/Documentation/drivers/index.md b/Documentation/drivers/index.md index 40d747da9d..1b8539d9e5 100644 --- a/Documentation/drivers/index.md +++ b/Documentation/drivers/index.md @@ -2,7 +2,7 @@ The drivers can be found in `src/drivers`. They are intended for onboard and plugin devices, significantly reducing integration complexity and -they allow to easily reuse existing code accross platforms. +they allow to easily reuse existing code across platforms. * [Intel DPTF](dptf.md) * [IPMI KCS](ipmi_kcs.md) diff --git a/Documentation/flash_tutorial/index.md b/Documentation/flash_tutorial/index.md index 43382979d2..da3d7f098f 100644 --- a/Documentation/flash_tutorial/index.md +++ b/Documentation/flash_tutorial/index.md @@ -7,7 +7,7 @@ flash IC. ## Contents -* [Flashing internaly](int_flashrom.md) +* [Flashing internally](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) diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt index 896ec939d6..750e883f91 100644 --- a/Documentation/gcov.txt +++ b/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 vaule to 1 if we want a warning ++/* There are many gcc_assertions. Set the value to 1 if we want a warning + message if the assertion fails. */ +#ifndef ENABLE_ASSERT_CHECKING +#define ENABLE_ASSERT_CHECKING 1 diff --git a/Documentation/getting_started/architecture.md b/Documentation/getting_started/architecture.md index 8d63ac2c75..09fb96031f 100644 --- a/Documentation/getting_started/architecture.md +++ b/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 usefull for high level +CPU cache like regular SRAM. This is particullary useful 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 existance and state. That includes: +about the current hardware existence and state. That includes: * ACPI tables (x86 specific) * SMBIOS tables (x86 specific) diff --git a/Documentation/getting_started/writing_documentation.md b/Documentation/getting_started/writing_documentation.md index 384fc6d1fc..480ad78724 100644 --- a/Documentation/getting_started/writing_documentation.md +++ b/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 -documenation to coreboot. +documentation to coreboot. ## Preparations diff --git a/Documentation/lib/payloads/fit.md b/Documentation/lib/payloads/fit.md index ef5e892c36..ac3c18341a 100644 --- a/Documentation/lib/payloads/fit.md +++ b/Documentation/lib/payloads/fit.md @@ -25,7 +25,7 @@ The section must be named in order to be found by the FIT parser: ## Architecture specifics -The FIT parser needs architecure support. +The FIT parser needs architecture support. ### aarch32 The source code can be found in `src/arch/arm/fit_payload.c`. diff --git a/Documentation/lib/timestamp.md b/Documentation/lib/timestamp.md index d5dc8facf3..a769f99098 100644 --- a/Documentation/lib/timestamp.md +++ b/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, upto a maximum +This field holds the details of each timestamp entry, up to a maximum of `MAX_TIMESTAMP_CACHE` which is defined as 16 entries. Each entry is defined by: diff --git a/Documentation/mainboard/amd/padmelon/padmelon.md b/Documentation/mainboard/amd/padmelon/padmelon.md index 20b1b13052..975426d8c6 100644 --- a/Documentation/mainboard/amd/padmelon/padmelon.md +++ b/Documentation/mainboard/amd/padmelon/padmelon.md @@ -43,7 +43,7 @@ Three items are marked in this picture +---------------------+--------------------+ | Size | 8 MiB | +---------------------+--------------------+ -| Flash programing | dediprog header | +| Flash programming | dediprog header | +---------------------+--------------------+ | Package | SOIC-8 | +---------------------+--------------------+ diff --git a/Documentation/mainboard/emulation/qemu-aarch64.md b/Documentation/mainboard/emulation/qemu-aarch64.md index 4df36a9944..6db8cefef0 100644 --- a/Documentation/mainboard/emulation/qemu-aarch64.md +++ b/Documentation/mainboard/emulation/qemu-aarch64.md @@ -1,5 +1,5 @@ # QEMU AArch64 emulator -This page discribes how to build and run coreboot for QEMU/AArch64. +This page describes 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. diff --git a/Documentation/mainboard/lenovo/Ivy_Bridge_series.md b/Documentation/mainboard/lenovo/Ivy_Bridge_series.md index 0f3e4c3179..ca02b3c69a 100644 --- a/Documentation/mainboard/lenovo/Ivy_Bridge_series.md +++ b/Documentation/mainboard/lenovo/Ivy_Bridge_series.md @@ -76,7 +76,7 @@ region. The update is then written into the EC once. [fl]: flashlayout_Ivy_Bridge.svg -## Reducing Intel Managment Engine firmware size +## Reducing Intel Management 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 diff --git a/Documentation/mainboard/lenovo/Sandy_Bridge_series.md b/Documentation/mainboard/lenovo/Sandy_Bridge_series.md index 84bae4014d..e1d9c77501 100644 --- a/Documentation/mainboard/lenovo/Sandy_Bridge_series.md +++ b/Documentation/mainboard/lenovo/Sandy_Bridge_series.md @@ -48,7 +48,7 @@ region. The update is then written into the EC once. [fl]: flashlayout_Sandy_Bridge.svg -## Reducing Intel Managment Engine firmware size +## Reducing Intel Management 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 diff --git a/Documentation/mainboard/lenovo/vboot.md b/Documentation/mainboard/lenovo/vboot.md index 3f1536018f..0a451ab7c4 100644 --- a/Documentation/mainboard/lenovo/vboot.md +++ b/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 constaints. +default FMAP. They are missing the `B` partition, due to size constraints. You can still provide your own FMAP if you need `RO`+`A`+`B` partitions. ## CMOS diff --git a/Documentation/mainboard/ocp/tiogapass.md b/Documentation/mainboard/ocp/tiogapass.md index 6d6afb1920..8c49923791 100644 --- a/Documentation/mainboard/ocp/tiogapass.md +++ b/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 paramter, such as "cpuidle.off=1". + target OS and Linuxboot kernel parameter, such as "cpuidle.off=1". - SMI handlers are not implemented. - xSDT tables are not fully populated, such as processor/socket devices, PCIe bridge devices. diff --git a/Documentation/mainboard/up/squared/index.md b/Documentation/mainboard/up/squared/index.md index d07f1118a8..2895e1f6a0 100644 --- a/Documentation/mainboard/up/squared/index.md +++ b/Documentation/mainboard/up/squared/index.md @@ -48,7 +48,7 @@ +---------------------+------------+ | Internal flashing | No | +---------------------+------------+ -| In curcuit flashing | Yes | +| In circuit flashing | Yes | +---------------------+------------+ ``` @@ -67,8 +67,8 @@ The GPIO header is located on the **bottom** side (see [here][overview_bottom_li The SPI header is located on the **bottom** side (see [here][overview_bottom_link]). ![][header_cn22] -### Preperations -In order to build coreboot, it's neccessary to extract some files from the vendor firmware. Make sure that you have a fully working dump. +### Preparations +In order to build coreboot, it's necessary to extract some files from the vendor firmware. Make sure that you have a fully working dump. ```bash [upsquared]$ ls firmware_vendor.rom diff --git a/Documentation/northbridge/intel/sandybridge/nri.md b/Documentation/northbridge/intel/sandybridge/nri.md index bf0b89f6a0..1cd5fb4014 100644 --- a/Documentation/northbridge/intel/sandybridge/nri.md +++ b/Documentation/northbridge/intel/sandybridge/nri.md @@ -40,7 +40,7 @@ The memory initialization code has to take care of lots of duties: +---------+-------------------------------------------------------------------+------------+--------------+ ``` -## (Unoffical) register documentation +## (Unofficial) register documentation - [Sandy Bridge - Register documentation](nri_registers.md) ## Frequency selection @@ -101,7 +101,7 @@ is stored to MRC cache. As of writing the only supported error handling is to disable the failing channel and restart the memory training sequence. It's very likely to succeed, as memory channels operate independent of each other. -In case no DIMM could be initilized coreboot will halt. The screen will stay +In case no DIMM could be initialized coreboot will halt. The screen will stay black until you power of your device. On some platforms there's additional feedback to indicate such an event. diff --git a/Documentation/northbridge/intel/sandybridge/nri_freq.md b/Documentation/northbridge/intel/sandybridge/nri_freq.md index 208c1cb13c..8d66b5c234 100644 --- a/Documentation/northbridge/intel/sandybridge/nri_freq.md +++ b/Documentation/northbridge/intel/sandybridge/nri_freq.md @@ -42,7 +42,7 @@ Only **XMP profile 1** is being used in case it advertises: * 1.5V operating voltage * The channel's installed DIMM count doesn't exceed the XMP coded limit -In case the XMP profile doesn't fullfill those limits, the regular SPD will be +In case the XMP profile doesn't fulfill those limits, the regular SPD will be used. > **Note:** XMP Profiles are supported since coreboot 4.4. diff --git a/Documentation/northbridge/intel/sandybridge/nri_registers.md b/Documentation/northbridge/intel/sandybridge/nri_registers.md index aae1205ec6..32bd3d1e28 100644 --- a/Documentation/northbridge/intel/sandybridge/nri_registers.md +++ b/Documentation/northbridge/intel/sandybridge/nri_registers.md @@ -1947,7 +1947,7 @@ Please handle with care! +-----------+------------------------------------------------------------------+ | Bit | Description | +===========+==================================================================+ -| 0:7| OREF_RI, Rank idle period that defines an oppertunity for | +| 0:7| OREF_RI, Rank idle period that defines an opportunity for | | | refresh | +-----------+------------------------------------------------------------------+ | 8:11| Refresh_HP_WM, tREFI count level that turns the refresh | diff --git a/Documentation/releases/coreboot-4.13-relnotes.md b/Documentation/releases/coreboot-4.13-relnotes.md index 971d438ee0..600bf67433 100644 --- a/Documentation/releases/coreboot-4.13-relnotes.md +++ b/Documentation/releases/coreboot-4.13-relnotes.md @@ -200,7 +200,7 @@ a bug in the more involved code to query options. ### Resource allocator v4 A new revision of resource allocator v4 is now added to coreboot that supports -mutiple ranges for allocating resources. Unlike the previous allocator (v3), it does +multiple ranges for allocating resources. Unlike the previous allocator (v3), it does not use the topmost available window for allocation. Instead, it uses the first window within the address space that is available and satisfies the resource request. This allows utilization of the entire available address space and also allows diff --git a/Documentation/releases/coreboot-4.3-relnotes.md b/Documentation/releases/coreboot-4.3-relnotes.md index c33c48a2bd..c0dda6e7b5 100644 --- a/Documentation/releases/coreboot-4.3-relnotes.md +++ b/Documentation/releases/coreboot-4.3-relnotes.md @@ -124,7 +124,7 @@ X86 Areas with significant work on updates and fixes ------------------------------------------------ * cpu/amd/model_fxx -* intel/fsp1_x: Fix timestanps & postcodes, add native CAR & microcode +* intel/fsp1_x: Fix timestamps & postcodes, add native CAR & microcode * nb/amd/amdfam10: Add S3, voltage & ACPI, speed fixes & MANY other changes * nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other diff --git a/Documentation/security/intel/txt.md b/Documentation/security/intel/txt.md index f80a731e81..7a746ec6de 100644 --- a/Documentation/security/intel/txt.md +++ b/Documentation/security/intel/txt.md @@ -37,7 +37,7 @@ More details can be found in the [Intel TXT IBB] chapter. ### Measurements The IBBs (Initial Boot Blocks) are measured into TPM's PCR0 by the BIOS [ACM] -before the CPU reset vector is executed. To indentify the regions that need +before the CPU reset vector is executed. To identify the regions that need to be measured, the [FIT] contains one ore multiple *Type 7* entries, that point to the IBBs. diff --git a/Documentation/security/smm.md b/Documentation/security/smm.md index 4e95427b86..397b7af552 100644 --- a/Documentation/security/smm.md +++ b/Documentation/security/smm.md @@ -1,4 +1,4 @@ -# x86 System Managment Mode +# x86 System Management Mode ## Introduction @@ -6,7 +6,7 @@ The code running in System Management Mode (SMM) provides runtime services to applications running in [ring0]. It has a higher privilege level than [ring0] and resides in the SMRAM region which cannot be accessed from [ring0]. -SMM can be entered by issuing System Managment Interrupts (SMIs). +SMM can be entered by issuing System Management Interrupts (SMIs). ## Secure data exchange diff --git a/Documentation/security/vboot/measured_boot.md b/Documentation/security/vboot/measured_boot.md index df4cc68008..adfae46d60 100644 --- a/Documentation/security/vboot/measured_boot.md +++ b/Documentation/security/vboot/measured_boot.md @@ -9,7 +9,7 @@ The "Initial Boot Block" or "Core Root of Trust for Measurement" is the first code block loaded at reset vector and measured by a DRTM solution. In case SRTM mode is active, the IBB measures itself before measuring the next code block. In coreboot, cbfs files which are part of the IBB are identified -by a metatdata tag. This makes it possible to have platform specific IBB +by a metadata tag. This makes it possible to have platform specific IBB measurements without hardcoding them. ## Known Limitations diff --git a/Documentation/soc/cavium/cn81xx/index.md b/Documentation/soc/cavium/cn81xx/index.md index 3063b946d0..684948cfd6 100644 --- a/Documentation/soc/cavium/cn81xx/index.md +++ b/Documentation/soc/cavium/cn81xx/index.md @@ -21,7 +21,7 @@ The SOC folder contains functions for: * Secondary CPUs * PCI -All other hardware is initilized by the BDK code, which is invoked from +All other hardware is initialized by the BDK code, which is invoked from ramstage. ## Notes about the hardware diff --git a/Documentation/superio/common/ssdt.md b/Documentation/superio/common/ssdt.md index 2f4049ef12..5f9e2f6298 100644 --- a/Documentation/superio/common/ssdt.md +++ b/Documentation/superio/common/ssdt.md @@ -50,7 +50,7 @@ end The following methods are generated for each SuperIO: ## AMTX() Acquire the global mutex and enter config mode. -It's called this at the begining of an atomic operation to make sure +It's called this at the beginning of an atomic operation to make sure no other ACPI code messes with the config space while working on it. ## RMTX() @@ -63,7 +63,7 @@ This method isn't guarded with the global mutex. ## DLDN(Arg0) Disables the (virtual) LDN given as Arg0. -This method aquires the global mutex. +This method acquires the global mutex. ## QLDN(Arg0) Queries the state of the (virtual) LDN given as Arg0. diff --git a/Documentation/superio/nuvoton/npcd378.md b/Documentation/superio/nuvoton/npcd378.md index f7fe1a56c6..11a0a88154 100644 --- a/Documentation/superio/nuvoton/npcd378.md +++ b/Documentation/superio/nuvoton/npcd378.md @@ -4,7 +4,7 @@ This page describes the [Nuvoton] SuperIO chip that can be found on various [HP] mainboards. As no datasheet is available most of the functions have been reverse engineered and -might be inacurate or wrong. +might be inaccurate or wrong. ## LDNs diff --git a/Documentation/technotes/2020-03-unit-testing-coreboot.md b/Documentation/technotes/2020-03-unit-testing-coreboot.md index 02c2e30ee0..a4d283f693 100644 --- a/Documentation/technotes/2020-03-unit-testing-coreboot.md +++ b/Documentation/technotes/2020-03-unit-testing-coreboot.md @@ -83,7 +83,7 @@ Requirements for unit testing frameworks: Compiler for the host _must_ support the same language standards as the target compiler. Ideally the same toolchain should be used for building firmware - executables and test binaries, however the host complier will be used to build + executables and test binaries, however the host compiler will be used to build unit tests, whereas the coreboot toolchain will be used for building the firmware executables. For some targets, the host compiler and the target compiler could be the same, but this is not a requirement. diff --git a/Documentation/tutorial/part1.md b/Documentation/tutorial/part1.md index e02812b68f..870248847f 100644 --- a/Documentation/tutorial/part1.md +++ b/Documentation/tutorial/part1.md @@ -123,7 +123,7 @@ are needed to build the coreboot toolchain. `gcc` and `gnat` have to be of the same version. If you started with a different distribution or package management system you -might need to install other packages. Most likely they are named sightly +might need to install other packages. Most likely they are named slightly different. If that is the case for you, we'd like to encourage you to contribute to the project and submit a pull request with an update for this documentation for your system. diff --git a/Documentation/util.md b/Documentation/util.md index 083401f034..8c6bcb7fca 100644 --- a/Documentation/util.md +++ b/Documentation/util.md @@ -57,7 +57,7 @@ even if hidden `C` hardware configuration (register contents, MSRs, etc). `C` * __intelvbttool__ - Parse VBT from VGA BIOS `C` * __ipqheader__ - * _createxbl.py_ - Concatentates XBL segments into one ELF + * _createxbl.py_ - Concatenates XBL segments into one ELF image `Python` * _ipqheader.py_ - Returns a packed MBN header image with the specified base and size `Python` |