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>
This commit is contained in:
parent
d4c55353e0
commit
6c3ece9c9e
|
@ -7,7 +7,7 @@ change.
|
||||||
|
|
||||||
\section{Scope}
|
\section{Scope}
|
||||||
This document defines how LinuxBIOS programmers can specify chips that
|
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
|
chips, but the architecture should allow for specification of other chips such
|
||||||
as southbridges. Multiple chips of same or different type are supported.
|
as southbridges. Multiple chips of same or different type are supported.
|
||||||
|
|
||||||
|
|
|
@ -5,7 +5,7 @@
|
||||||
ACPI exposes a platform-independent interface for operating systems to perform
|
ACPI exposes a platform-independent interface for operating systems to perform
|
||||||
power management and other platform-level functions. Some operating systems
|
power management and other platform-level functions. Some operating systems
|
||||||
also use ACPI to enumerate devices that are not immediately discoverable, such
|
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
|
the way that coreboot uses the concept of a "device tree" to generate ACPI
|
||||||
tables for usage by the operating system.
|
tables for usage by the operating system.
|
||||||
|
|
||||||
|
|
|
@ -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
|
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
|
the page table doesn't contain the expected data. This in turn leads to
|
||||||
undefined behaviour whenever the 'wrong' address is being read.
|
undefined behaviour whenever the 'wrong' address is being read.
|
||||||
* Disabling paging in compability mode crashes the CPU.
|
* Disabling paging in compatibility mode crashes the CPU.
|
||||||
* Returning from long mode to compability mode crashes the CPU.
|
* Returning from long mode to compatibility mode crashes the CPU.
|
||||||
* Entering long mode crashes on AMD host platforms.
|
* Entering long mode crashes on AMD host platforms.
|
||||||
|
|
|
@ -185,7 +185,7 @@ texinfo_documents = [
|
||||||
enable_auto_toc_tree = True
|
enable_auto_toc_tree = True
|
||||||
|
|
||||||
class MyCommonMarkParser(CommonMarkParser):
|
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):
|
def visit_code(self, mdnode):
|
||||||
from docutils import nodes
|
from docutils import nodes
|
||||||
n = nodes.literal(mdnode.literal, mdnode.literal)
|
n = nodes.literal(mdnode.literal, mdnode.literal)
|
||||||
|
|
|
@ -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
|
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
|
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
|
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
|
optimize most of your function away at compile time. For a good example
|
||||||
of this later case, see the kmalloc() inline function.
|
of this later case, see the kmalloc() inline function.
|
||||||
|
|
|
@ -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
|
and libraries, consisting of a backend, a frontend and client side
|
||||||
scripts. The backend should connect to an SQL database with can be
|
scripts. The backend should connect to an SQL database with can be
|
||||||
controlled using a RESTful API. The RESTful API should have basic authentication
|
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
|
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
|
Angular) to display the current board status, that is if it's working or not
|
||||||
|
|
|
@ -2,7 +2,7 @@
|
||||||
|
|
||||||
The drivers can be found in `src/drivers`. They are intended for onboard
|
The drivers can be found in `src/drivers`. They are intended for onboard
|
||||||
and plugin devices, significantly reducing integration complexity and
|
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)
|
* [Intel DPTF](dptf.md)
|
||||||
* [IPMI KCS](ipmi_kcs.md)
|
* [IPMI KCS](ipmi_kcs.md)
|
||||||
|
|
|
@ -7,7 +7,7 @@ flash IC.
|
||||||
|
|
||||||
## Contents
|
## Contents
|
||||||
|
|
||||||
* [Flashing internaly](int_flashrom.md)
|
* [Flashing internally](int_flashrom.md)
|
||||||
* [Flashing firmware standalone](ext_standalone.md)
|
* [Flashing firmware standalone](ext_standalone.md)
|
||||||
* [Flashing firmware externally supplying direct power](ext_power.md)
|
* [Flashing firmware externally supplying direct power](ext_power.md)
|
||||||
* [Flashing firmware externally without supplying direct power](no_ext_power.md)
|
* [Flashing firmware externally without supplying direct power](no_ext_power.md)
|
||||||
|
|
|
@ -19,7 +19,7 @@ time). The file gcov-io.c is unchanged.
|
||||||
+#define BITS_PER_UNIT 8
|
+#define BITS_PER_UNIT 8
|
||||||
+#define LONG_LONG_TYPE_SIZE 64
|
+#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. */
|
+ message if the assertion fails. */
|
||||||
+#ifndef ENABLE_ASSERT_CHECKING
|
+#ifndef ENABLE_ASSERT_CHECKING
|
||||||
+#define ENABLE_ASSERT_CHECKING 1
|
+#define ENABLE_ASSERT_CHECKING 1
|
||||||
|
|
|
@ -41,7 +41,7 @@ The bootblock loads the romstage or the verstage if verified boot is enabled.
|
||||||
|
|
||||||
### Cache-As-Ram
|
### Cache-As-Ram
|
||||||
The *Cache-As-Ram*, also called Non-Eviction mode, or *CAR* allows to use the
|
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.
|
languages like `C`, which need RAM for heap and stack.
|
||||||
|
|
||||||
The CAR needs to be activated using vendor specific CPU instructions.
|
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)
|
* CPU init (like set up SMM)
|
||||||
|
|
||||||
After initialization tables are written to inform the payload or operating system
|
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)
|
* ACPI tables (x86 specific)
|
||||||
* SMBIOS tables (x86 specific)
|
* SMBIOS tables (x86 specific)
|
||||||
|
|
|
@ -6,7 +6,7 @@
|
||||||
That said please always try to write documentation! One problem in the
|
That said please always try to write documentation! One problem in the
|
||||||
firmware development is the missing documentation. In this document
|
firmware development is the missing documentation. In this document
|
||||||
you will get a brief introduction how to write, submit and publish
|
you will get a brief introduction how to write, submit and publish
|
||||||
documenation to coreboot.
|
documentation to coreboot.
|
||||||
|
|
||||||
## Preparations
|
## Preparations
|
||||||
|
|
||||||
|
|
|
@ -25,7 +25,7 @@ The section must be named in order to be found by the FIT parser:
|
||||||
|
|
||||||
## Architecture specifics
|
## Architecture specifics
|
||||||
|
|
||||||
The FIT parser needs architecure support.
|
The FIT parser needs architecture support.
|
||||||
|
|
||||||
### aarch32
|
### aarch32
|
||||||
The source code can be found in `src/arch/arm/fit_payload.c`.
|
The source code can be found in `src/arch/arm/fit_payload.c`.
|
||||||
|
|
|
@ -99,7 +99,7 @@ exist and an entry structure to hold variable number of entries.
|
||||||
|
|
||||||
### 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
|
of `MAX_TIMESTAMP_CACHE` which is defined as 16 entries. Each entry is
|
||||||
defined by:
|
defined by:
|
||||||
|
|
||||||
|
|
|
@ -43,7 +43,7 @@ Three items are marked in this picture
|
||||||
+---------------------+--------------------+
|
+---------------------+--------------------+
|
||||||
| Size | 8 MiB |
|
| Size | 8 MiB |
|
||||||
+---------------------+--------------------+
|
+---------------------+--------------------+
|
||||||
| Flash programing | dediprog header |
|
| Flash programming | dediprog header |
|
||||||
+---------------------+--------------------+
|
+---------------------+--------------------+
|
||||||
| Package | SOIC-8 |
|
| Package | SOIC-8 |
|
||||||
+---------------------+--------------------+
|
+---------------------+--------------------+
|
||||||
|
|
|
@ -1,5 +1,5 @@
|
||||||
# QEMU AArch64 emulator
|
# 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
|
You can use LinuxBoot via `make menuconfig` or an arbitrary FIT image
|
||||||
as a payload for QEMU/AArch64.
|
as a payload for QEMU/AArch64.
|
||||||
|
|
||||||
|
|
|
@ -76,7 +76,7 @@ region. The update is then written into the EC once.
|
||||||
|
|
||||||
[fl]: flashlayout_Ivy_Bridge.svg
|
[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
|
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
|
space for the `bios` region. This is usually referred to as *cleaning the ME* or
|
||||||
|
|
|
@ -48,7 +48,7 @@ region. The update is then written into the EC once.
|
||||||
|
|
||||||
[fl]: flashlayout_Sandy_Bridge.svg
|
[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
|
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
|
space for the `bios` region. This is usually referred to as *cleaning the ME* or
|
||||||
|
|
|
@ -28,7 +28,7 @@ to boot and flash a working image to the A/B partition.
|
||||||
|
|
||||||
## 8 MiB ROM limitation
|
## 8 MiB ROM limitation
|
||||||
*Lenovo* devices with 8 MiB ROM only have a `RO`+`A` partition enabled in the
|
*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.
|
You can still provide your own FMAP if you need `RO`+`A`+`B` partitions.
|
||||||
|
|
||||||
## CMOS
|
## CMOS
|
||||||
|
|
|
@ -51,7 +51,7 @@ To connect to console through SOL (Serial Over Lan):
|
||||||
|
|
||||||
## Known issues / feature gaps
|
## Known issues / feature gaps
|
||||||
- C6 state is not supported. Workaround is to disable C6 support through
|
- 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.
|
- SMI handlers are not implemented.
|
||||||
- xSDT tables are not fully populated, such as processor/socket devices,
|
- xSDT tables are not fully populated, such as processor/socket devices,
|
||||||
PCIe bridge devices.
|
PCIe bridge devices.
|
||||||
|
|
|
@ -48,7 +48,7 @@
|
||||||
+---------------------+------------+
|
+---------------------+------------+
|
||||||
| Internal flashing | No |
|
| 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]).
|
The SPI header is located on the **bottom** side (see [here][overview_bottom_link]).
|
||||||
![][header_cn22]
|
![][header_cn22]
|
||||||
|
|
||||||
### Preperations
|
### Preparations
|
||||||
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.
|
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
|
```bash
|
||||||
[upsquared]$ ls
|
[upsquared]$ ls
|
||||||
firmware_vendor.rom
|
firmware_vendor.rom
|
||||||
|
|
|
@ -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)
|
- [Sandy Bridge - Register documentation](nri_registers.md)
|
||||||
|
|
||||||
## Frequency selection
|
## Frequency selection
|
||||||
|
@ -101,7 +101,7 @@ is stored to MRC cache.
|
||||||
As of writing the only supported error handling is to disable the failing
|
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,
|
channel and restart the memory training sequence. It's very likely to succeed,
|
||||||
as memory channels operate independent of each other.
|
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
|
black until you power of your device. On some platforms there's additional
|
||||||
feedback to indicate such an event.
|
feedback to indicate such an event.
|
||||||
|
|
||||||
|
|
|
@ -42,7 +42,7 @@ Only **XMP profile 1** is being used in case it advertises:
|
||||||
* 1.5V operating voltage
|
* 1.5V operating voltage
|
||||||
* The channel's installed DIMM count doesn't exceed the XMP coded limit
|
* 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.
|
used.
|
||||||
> **Note:** XMP Profiles are supported since coreboot 4.4.
|
> **Note:** XMP Profiles are supported since coreboot 4.4.
|
||||||
|
|
||||||
|
|
|
@ -1947,7 +1947,7 @@ Please handle with care!
|
||||||
+-----------+------------------------------------------------------------------+
|
+-----------+------------------------------------------------------------------+
|
||||||
| Bit | Description |
|
| 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 |
|
| | refresh |
|
||||||
+-----------+------------------------------------------------------------------+
|
+-----------+------------------------------------------------------------------+
|
||||||
| 8:11| Refresh_HP_WM, tREFI count level that turns the refresh |
|
| 8:11| Refresh_HP_WM, tREFI count level that turns the refresh |
|
||||||
|
|
|
@ -200,7 +200,7 @@ a bug in the more involved code to query options.
|
||||||
### Resource allocator v4
|
### Resource allocator v4
|
||||||
|
|
||||||
A new revision of resource allocator v4 is now added to coreboot that supports
|
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
|
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.
|
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
|
This allows utilization of the entire available address space and also allows
|
||||||
|
|
|
@ -124,7 +124,7 @@ X86
|
||||||
Areas with significant work on updates and fixes
|
Areas with significant work on updates and fixes
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
* cpu/amd/model_fxx
|
* 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
|
* nb/amd/amdfam10: Add S3, voltage & ACPI, speed fixes & MANY other
|
||||||
changes
|
changes
|
||||||
* nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other
|
* nb/amd/amdmct: Add S3, mem voltage, Fix performance & MANY other
|
||||||
|
|
|
@ -37,7 +37,7 @@ More details can be found in the [Intel TXT IBB] chapter.
|
||||||
|
|
||||||
### Measurements
|
### Measurements
|
||||||
The IBBs (Initial Boot Blocks) are measured into TPM's PCR0 by the BIOS [ACM]
|
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
|
to be measured, the [FIT] contains one ore multiple *Type 7* entries, that
|
||||||
point to the IBBs.
|
point to the IBBs.
|
||||||
|
|
||||||
|
|
|
@ -1,4 +1,4 @@
|
||||||
# x86 System Managment Mode
|
# x86 System Management Mode
|
||||||
|
|
||||||
## Introduction
|
## 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
|
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].
|
[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
|
## Secure data exchange
|
||||||
|
|
||||||
|
|
|
@ -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.
|
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
|
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
|
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.
|
measurements without hardcoding them.
|
||||||
|
|
||||||
## Known Limitations
|
## Known Limitations
|
||||||
|
|
|
@ -21,7 +21,7 @@ The SOC folder contains functions for:
|
||||||
* Secondary CPUs
|
* Secondary CPUs
|
||||||
* PCI
|
* 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.
|
ramstage.
|
||||||
|
|
||||||
## Notes about the hardware
|
## Notes about the hardware
|
||||||
|
|
|
@ -50,7 +50,7 @@ end
|
||||||
The following methods are generated for each SuperIO:
|
The following methods are generated for each SuperIO:
|
||||||
## AMTX()
|
## AMTX()
|
||||||
Acquire the global mutex and enter config mode.
|
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.
|
no other ACPI code messes with the config space while working on it.
|
||||||
|
|
||||||
## RMTX()
|
## RMTX()
|
||||||
|
@ -63,7 +63,7 @@ This method isn't guarded with the global mutex.
|
||||||
|
|
||||||
## DLDN(Arg0)
|
## DLDN(Arg0)
|
||||||
Disables the (virtual) LDN given as Arg0.
|
Disables the (virtual) LDN given as Arg0.
|
||||||
This method aquires the global mutex.
|
This method acquires the global mutex.
|
||||||
|
|
||||||
## QLDN(Arg0)
|
## QLDN(Arg0)
|
||||||
Queries the state of the (virtual) LDN given as Arg0.
|
Queries the state of the (virtual) LDN given as Arg0.
|
||||||
|
|
|
@ -4,7 +4,7 @@ This page describes the [Nuvoton] SuperIO chip that can be found on various [HP]
|
||||||
mainboards.
|
mainboards.
|
||||||
|
|
||||||
As no datasheet is available most of the functions have been reverse engineered and
|
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
|
## LDNs
|
||||||
|
|
||||||
|
|
|
@ -83,7 +83,7 @@ Requirements for unit testing frameworks:
|
||||||
|
|
||||||
Compiler for the host _must_ support the same language standards as the target
|
Compiler for the host _must_ support the same language standards as the target
|
||||||
compiler. Ideally the same toolchain should be used for building firmware
|
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
|
unit tests, whereas the coreboot toolchain will be used for building the
|
||||||
firmware executables. For some targets, the host compiler and the target
|
firmware executables. For some targets, the host compiler and the target
|
||||||
compiler could be the same, but this is not a requirement.
|
compiler could be the same, but this is not a requirement.
|
||||||
|
|
|
@ -123,7 +123,7 @@ are needed to build the coreboot toolchain. `gcc` and `gnat` have to be
|
||||||
of the same version.
|
of the same version.
|
||||||
|
|
||||||
If you started with a different distribution or package management system you
|
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
|
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
|
to the project and submit a pull request with an update for this documentation
|
||||||
for your system.
|
for your system.
|
||||||
|
|
|
@ -57,7 +57,7 @@ even if hidden `C`
|
||||||
hardware configuration (register contents, MSRs, etc). `C`
|
hardware configuration (register contents, MSRs, etc). `C`
|
||||||
* __intelvbttool__ - Parse VBT from VGA BIOS `C`
|
* __intelvbttool__ - Parse VBT from VGA BIOS `C`
|
||||||
* __ipqheader__
|
* __ipqheader__
|
||||||
* _createxbl.py_ - Concatentates XBL segments into one ELF
|
* _createxbl.py_ - Concatenates XBL segments into one ELF
|
||||||
image `Python`
|
image `Python`
|
||||||
* _ipqheader.py_ - Returns a packed MBN header image with the
|
* _ipqheader.py_ - Returns a packed MBN header image with the
|
||||||
specified base and size `Python`
|
specified base and size `Python`
|
||||||
|
|
Loading…
Reference in New Issue