Documentation: Fix spelling errors

These issues were found and fixed by codespell, a useful tool for finding spelling errors. Signed-off-by: Martin Roth <[email protected]> Change-Id: If2a8e97911420c19e9365d5c28810b998f2c2ac8 Reviewed-on: https://review.coreboot.org/c/coreboot/+/58078 Reviewed-by: Felix Held <[email protected]> Reviewed-by: Angel Pons <[email protected]> Tested-by: build bot (Jenkins) <[email protected]>
amassivus · Oct 5, 2021 · 6c3ece9 · 6c3ece9
1 parent d4c5535
commit 6c3ece9
Show file tree

Hide file tree

Showing 34 changed files with 42 additions and 42 deletions.
diff --git a/Documentation/RFC/chip.tex b/Documentation/RFC/chip.tex
@@ -7,7 +7,7 @@
 
 \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
@@ -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
@@ -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
@@ -185,7 +185,7 @@
 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -1,12 +1,12 @@
-# x86 System Managment Mode
+# x86 System Management Mode
 
 ## Introduction
 
 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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`