Compare commits
1 Commits
Author | SHA1 | Date | |
---|---|---|---|
761092446e |
@ -4,7 +4,6 @@
|
||||
# Ignore aspects we don't follow here.
|
||||
--ignore C99_COMMENTS
|
||||
--ignore GLOBAL_INITIALISERS
|
||||
--ignore COMPARISON_TO_NULL
|
||||
--ignore INITIALISED_STATIC
|
||||
--ignore LINE_SPACING
|
||||
--ignore NEW_TYPEDEFS
|
||||
|
1
.gitignore
vendored
@ -33,7 +33,6 @@ tags
|
||||
.clang_complete
|
||||
.cache
|
||||
compile_commands.json
|
||||
.vscode/
|
||||
|
||||
# Cross-compile toolkits
|
||||
xgcc/
|
||||
|
4
.gitmodules
vendored
@ -61,7 +61,3 @@
|
||||
path = 3rdparty/stm
|
||||
url = ../STM
|
||||
branch = stmpe
|
||||
[submodule "util/goswid"]
|
||||
path = util/goswid
|
||||
url = ../goswid
|
||||
branch = trunk
|
||||
|
2
3rdparty/amd_blobs
vendored
2
3rdparty/arm-trusted-firmware
vendored
2
3rdparty/blobs
vendored
2
3rdparty/fsp
vendored
2
3rdparty/intel-microcode
vendored
2
3rdparty/libgfxinit
vendored
2
3rdparty/libhwbase
vendored
2
3rdparty/opensbi
vendored
2
3rdparty/qc_blobs
vendored
2
3rdparty/vboot
vendored
1
AUTHORS
@ -108,7 +108,6 @@ Jonas 'Sortie' Termansen
|
||||
Jonathan A. Kollasch
|
||||
Jonathan Neuschäfer
|
||||
Jordan Crouse
|
||||
Jörg Mische
|
||||
Joseph Smith
|
||||
Keith Hui
|
||||
Keith Packard
|
||||
|
@ -1,19 +1,17 @@
|
||||
## SPDX-License-Identifier: GPL-2.0-only
|
||||
#
|
||||
# Makefile for coreboot paper.
|
||||
# hacked together by Stefan Reinauer <stepan@openbios.org>
|
||||
#
|
||||
|
||||
PDFLATEX=pdflatex -t a4
|
||||
BUILDDIR ?= _build
|
||||
|
||||
FIGS=codeflow.pdf hypertransport.pdf
|
||||
|
||||
all: sphinx corebootPortingGuide.pdf
|
||||
all: corebootPortingGuide.pdf
|
||||
|
||||
SVG2PDF=$(shell command -v svg2pdf)
|
||||
INKSCAPE=$(shell command -v inkscape)
|
||||
CONVERT=$(shell command -v convert)
|
||||
SVG2PDF=$(shell which svg2pdf)
|
||||
INKSCAPE=$(shell which inkscape)
|
||||
CONVERT=$(shell which convert)
|
||||
|
||||
codeflow.pdf: codeflow.svg
|
||||
ifneq ($(strip $(SVG2PDF)),)
|
||||
@ -33,9 +31,6 @@ else ifneq ($(strip $(CONVERT)),)
|
||||
convert $< $@
|
||||
endif
|
||||
|
||||
$(BUILDDIR):
|
||||
mkdir -p $(BUILDDIR)
|
||||
|
||||
corebootPortingGuide.toc: $(FIGS) corebootBuildingGuide.tex
|
||||
# 2 times to make sure we have a current toc.
|
||||
$(PDFLATEX) corebootBuildingGuide.tex
|
||||
@ -44,11 +39,11 @@ corebootPortingGuide.toc: $(FIGS) corebootBuildingGuide.tex
|
||||
corebootPortingGuide.pdf: $(FIGS) corebootBuildingGuide.tex corebootPortingGuide.toc
|
||||
$(PDFLATEX) corebootBuildingGuide.tex
|
||||
|
||||
sphinx: $(BUILDDIR)
|
||||
$(MAKE) -f Makefile.sphinx html BUILDDIR="$(BUILDDIR)"
|
||||
sphinx:
|
||||
$(MAKE) -f Makefile.sphinx html
|
||||
|
||||
clean-sphinx:
|
||||
$(MAKE) -f Makefile.sphinx clean BUILDDIR="$(BUILDDIR)"
|
||||
$(MAKE) -f Makefile.sphinx clean
|
||||
|
||||
clean: clean-sphinx
|
||||
rm -f *.aux *.idx *.log *.toc *.out $(FIGS)
|
||||
@ -56,25 +51,5 @@ clean: clean-sphinx
|
||||
distclean: clean
|
||||
rm -f corebootPortingGuide.pdf
|
||||
|
||||
livesphinx: $(BUILDDIR)
|
||||
$(MAKE) -f Makefile.sphinx livehtml SPHINXOPTS="$(SPHINXOPTS)" BUILDDIR="$(BUILDDIR)"
|
||||
|
||||
test:
|
||||
@echo "Test for logging purposes - Failing tests will not fail the build"
|
||||
-$(MAKE) -f Makefile.sphinx clean && $(MAKE) -K -f Makefile.sphinx html
|
||||
-$(MAKE) -f Makefile.sphinx clean && $(MAKE) -K -f Makefile.sphinx doctest
|
||||
|
||||
help:
|
||||
@echo "all - Builds coreboot porting guide PDF (outdated)"
|
||||
@echo "sphinx - Builds html documentation in _build directory"
|
||||
@echo "clean - Cleans intermediate files"
|
||||
@echo "clean-sphinx - Removes sphinx output files"
|
||||
@echo "distclean - Removes PDF files as well"
|
||||
@echo "test - Runs documentation tests"
|
||||
@echo
|
||||
@echo " Makefile.sphinx builds - run with $(MAKE) -f Makefile-sphinx [target]"
|
||||
@echo
|
||||
@$(MAKE) -s -f Makefile.sphinx help 2>/dev/null
|
||||
|
||||
.phony: help livesphinx sphinx test
|
||||
.phony: distclean clean clean-sphinx
|
||||
livesphinx:
|
||||
$(MAKE) -f Makefile.sphinx livehtml SPHINXOPTS="$(SPHINXOPTS)"
|
||||
|
@ -1,4 +1,3 @@
|
||||
## SPDX-License-Identifier: GPL-2.0-only
|
||||
# Makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
|
290
Documentation/acpi/devicetree.md
Normal file
@ -0,0 +1,290 @@
|
||||
# Adding new devices to a device tree
|
||||
|
||||
## Introduction
|
||||
|
||||
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 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.
|
||||
|
||||
## Devicetree and overridetree (if applicable)
|
||||
|
||||
For mainboards that are organized around a "reference board" or "baseboard"
|
||||
model (see ``src/mainboard/google/octopus`` or ``hatch`` for examples), there is
|
||||
typically a devicetree.cb file that all boards share, and any differences for a
|
||||
specific board ("variant") are captured in the overridetree.cb file. Any
|
||||
settings changed in the overridetree take precedence over those in the main
|
||||
devicetree. Note, not all mainboards will have the devicetree/overridetree
|
||||
distinction, and may only have a devicetree.cb file. Or you can always just
|
||||
write the ASL (ACPI Source Language) code yourself.
|
||||
|
||||
### Naming and referencing devices
|
||||
|
||||
When declaring a device, it can optionally be given an alias that can be
|
||||
referred to elsewhere. This is particularly useful to declare a device in one
|
||||
device tree while allowing its configuration to be more easily changed in an
|
||||
overlay. For instance, the AMD Picasso SoC definition
|
||||
(`soc/amd/picasso/chipset.cb`) declares an IOMMU on a PCI bus that is disabled
|
||||
by default:
|
||||
|
||||
```
|
||||
chip soc/amd/picasso
|
||||
device domain 0 on
|
||||
...
|
||||
device pci 00.2 alias iommu off end
|
||||
...
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
A device based on this SoC can override the configuration for the IOMMU without
|
||||
duplicating addresses, as in
|
||||
`mainboard/google/zork/variants/baseboard/devicetree_trembyle.cb`:
|
||||
|
||||
```
|
||||
chip soc/amd/picasso
|
||||
device domain 0
|
||||
...
|
||||
device ref iommu on end
|
||||
...
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
In this example the override simply enables the IOMMU, but it could also
|
||||
set additional properties (or even add child devices) inside the IOMMU `device`
|
||||
block.
|
||||
|
||||
---
|
||||
|
||||
It is important to note that devices that use `device ref` syntax to override
|
||||
previous definitions of a device by alias must be placed at **exactly the same
|
||||
location in the device tree** as the original declaration. If not, this will
|
||||
actually create another device rather than overriding the properties of the
|
||||
existing one. For instance, if the above snippet from `devicetree_trembyle.cb`
|
||||
were written as follows:
|
||||
|
||||
```
|
||||
chip soc/amd/picasso
|
||||
# NOTE: not inside domain 0!
|
||||
device ref iommu on end
|
||||
end
|
||||
```
|
||||
|
||||
Then this would leave the SoC's IOMMU disabled, and instead create a new device
|
||||
with no properties as a direct child of the SoC.
|
||||
|
||||
## Device drivers
|
||||
|
||||
Let's take a look at an example entry from
|
||||
``src/mainboard/google/hatch/variants/hatch/overridetree.cb``:
|
||||
|
||||
```
|
||||
device pci 15.0 on
|
||||
chip drivers/i2c/generic
|
||||
register "hid" = ""ELAN0000""
|
||||
register "desc" = ""ELAN Touchpad""
|
||||
register "irq" = "ACPI_IRQ_WAKE_LEVEL_LOW(GPP_A21_IRQ)"
|
||||
register "wake" = "GPE0_DW0_21"
|
||||
device i2c 15 on end
|
||||
end
|
||||
end # I2C #0
|
||||
```
|
||||
|
||||
When this entry is processed during ramstage, it will create a device in the
|
||||
ACPI SSDT table (all devices in devicetrees end up in the SSDT table). The ACPI
|
||||
generation routines in coreboot actually generate the raw bytecode that
|
||||
represents the device's structure, but looking at ASL code is easier to
|
||||
understand; see below for what the disassembled bytecode looks like:
|
||||
|
||||
```
|
||||
Scope (\_SB.PCI0.I2C0)
|
||||
{
|
||||
Device (D015)
|
||||
{
|
||||
Name (_HID, "ELAN0000") // _HID: Hardware ID
|
||||
Name (_UID, Zero) // _UID: Unique ID
|
||||
Name (_DDN, "ELAN Touchpad") // _DDN: DOS Device Name
|
||||
Method (_STA, 0, NotSerialized) // _STA: Status
|
||||
{
|
||||
Return (0x0F)
|
||||
}
|
||||
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
|
||||
{
|
||||
I2cSerialBusV2 (0x0015, ControllerInitiated, 400000,
|
||||
AddressingMode7Bit, "\\_SB.PCI0.I2C0",
|
||||
0x00, ResourceConsumer, , Exclusive, )
|
||||
Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake, ,, )
|
||||
{
|
||||
0x0000002D,
|
||||
}
|
||||
})
|
||||
Name (_S0W, ACPI_DEVICE_SLEEP_D3_HOT) // _S0W: S0 Device Wake State
|
||||
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
|
||||
{
|
||||
0x15, // GPE #21
|
||||
0x03 // Sleep state S3
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
You can see it generates _HID, _UID, _DDN, _STA, _CRS, _S0W, and _PRW
|
||||
names/methods in the Device's scope.
|
||||
|
||||
## Utilizing a device driver
|
||||
|
||||
The device driver must be enabled for your build. There will be a CONFIG option
|
||||
in the Kconfig file in the directory that the driver is in (e.g.,
|
||||
``src/drivers/i2c/generic`` contains a Kconfig file; the option here is named
|
||||
CONFIG_DRIVERS_I2C_GENERIC). The config option will need to be added to your
|
||||
mainboard's Kconfig file (e.g., ``src/mainboard/google/hatch/Kconfig``) in order
|
||||
to be compiled into your build.
|
||||
|
||||
## Diving into the above example:
|
||||
|
||||
Let's take a look at how the devicetree language corresponds to the generated
|
||||
ASL.
|
||||
|
||||
First, note this:
|
||||
|
||||
```
|
||||
chip drivers/i2c/generic
|
||||
```
|
||||
|
||||
This means that the device driver we're using has a corresponding structure,
|
||||
located at ``src/drivers/i2c/generic/chip.h``, named **struct
|
||||
drivers_i2c_generic_config** and it contains many properties you can specify to
|
||||
be included in the ACPI table.
|
||||
|
||||
### hid
|
||||
|
||||
```
|
||||
register "hid" = ""ELAN0000""
|
||||
```
|
||||
|
||||
This corresponds to **const char *hid** in the struct. In the ACPI ASL, it
|
||||
translates to:
|
||||
|
||||
```
|
||||
Name (_HID, "ELAN0000") // _HID: Hardware ID
|
||||
```
|
||||
|
||||
under the device. **This property is used to match the device to its driver
|
||||
during enumeration in the OS.**
|
||||
|
||||
### desc
|
||||
|
||||
```
|
||||
register "desc" = ""ELAN Touchpad""
|
||||
```
|
||||
|
||||
corresponds to **const char *desc** and in ASL:
|
||||
|
||||
```
|
||||
Name (_DDN, "ELAN Touchpad") // _DDN: DOS Device Name
|
||||
```
|
||||
|
||||
### irq
|
||||
|
||||
It also adds the interrupt,
|
||||
|
||||
```
|
||||
Interrupt (ResourceConsumer, Level, ActiveLow, ExclusiveAndWake, ,, )
|
||||
{
|
||||
0x0000002D,
|
||||
}
|
||||
```
|
||||
|
||||
which comes from:
|
||||
|
||||
```
|
||||
register "irq" = "ACPI_IRQ_WAKE_LEVEL_LOW(GPP_A21_IRQ)"
|
||||
```
|
||||
|
||||
The GPIO pin IRQ settings control the "Level", "ActiveLow", and
|
||||
"ExclusiveAndWake" settings seen above (level means it is a level-triggered
|
||||
interrupt as opposed to edge-triggered; active low means the interrupt is
|
||||
triggered when the signal is low).
|
||||
|
||||
Note that the ACPI_IRQ_WAKE_LEVEL_LOW macro informs the platform that the GPIO
|
||||
will be routed through SCI (ACPI's System Control Interrupt) for use as a wake
|
||||
source. Also note that the IRQ names are SoC-specific, and you will need to
|
||||
find the names in your SoC's header file. The ACPI_* macros are defined in
|
||||
``src/arch/x86/include/acpi/acpi_device.h``.
|
||||
|
||||
Using a GPIO as an IRQ requires that it is configured in coreboot correctly.
|
||||
This is often done in a mainboard-specific file named ``gpio.c``.
|
||||
|
||||
### wake
|
||||
|
||||
The last register is:
|
||||
|
||||
```
|
||||
register "wake" = "GPE0_DW0_21"
|
||||
```
|
||||
|
||||
which indicates that the method of waking the system using the touchpad will be
|
||||
through a GPE, #21 associated with DW0, which is set up in devicetree.cb from
|
||||
this example. The "21" indicates GPP_X21, where GPP_X is mapped onto DW0
|
||||
elsewhere in the devicetree.
|
||||
|
||||
The last bit of the definition of that device includes:
|
||||
|
||||
```
|
||||
device i2c 15 on end
|
||||
```
|
||||
|
||||
which means it's an I2C device, with 7-bit address 0x15, and the device is "on",
|
||||
meaning it will be exposed in the ACPI table. The PCI device that the
|
||||
controller is located in determines which I2C bus the device is expected to be
|
||||
found on. In this example, this is I2C bus 0. This also determines the ACPI
|
||||
"Scope" that the device names and methods will live under, in this case
|
||||
"\_SB.PCI0.I2C0".
|
||||
|
||||
## Other auto-generated names
|
||||
|
||||
(see [ACPI specification
|
||||
6.3](https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf)
|
||||
for more details on ACPI methods)
|
||||
|
||||
### _S0W (S0 Device Wake State)
|
||||
_S0W indicates the deepest S0 sleep state this device can wake itself from,
|
||||
which in this case is ACPI_DEVICE_SLEEP_D3_HOT, representing _D3hot_.
|
||||
|
||||
### _PRW (Power Resources for Wake)
|
||||
_PRW indicates the power resources and events required for wake. There are no
|
||||
dependent power resources, but the GPE (GPE0_DW0_21) is mentioned here (0x15),
|
||||
as well as the deepest sleep state supporting waking the system (3), which is
|
||||
S3.
|
||||
|
||||
### _STA (Status)
|
||||
The _STA method is generated automatically, and its values, 0xF, indicates the
|
||||
following:
|
||||
|
||||
Bit [0] – Set if the device is present.
|
||||
Bit [1] – Set if the device is enabled and decoding its resources.
|
||||
Bit [2] – Set if the device should be shown in the UI.
|
||||
Bit [3] – Set if the device is functioning properly (cleared if device failed its diagnostics).
|
||||
|
||||
### _CRS (Current resource settings)
|
||||
The _CRS method is generated automatically, as the driver knows it is an I2C
|
||||
controller, and so specifies how to configure the controller for proper
|
||||
operation with the touchpad.
|
||||
|
||||
```
|
||||
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
|
||||
{
|
||||
I2cSerialBusV2 (0x0015, ControllerInitiated, 400000,
|
||||
AddressingMode7Bit, "\\_SB.PCI0.I2C0",
|
||||
0x00, ResourceConsumer, , Exclusive, )
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- **All fields that are left unspecified in the devicetree are initialized to
|
||||
zero.**
|
||||
- **All devices in devicetrees end up in the SSDT table, and are generated in
|
||||
coreboot's ramstage**
|
@ -11,12 +11,6 @@ upwards.
|
||||
|
||||
- [GPIO toggling in ACPI AML](gpio.md)
|
||||
|
||||
## Windows-specific ACPI documentation
|
||||
## devicetree
|
||||
|
||||
- [Windows-specific documentation](windows.md)
|
||||
|
||||
## ACPI specification - Useful links
|
||||
|
||||
- [ACPI Specification 6.5](https://uefi.org/specs/ACPI/6.5/index.html)
|
||||
- [ASL 2.0 Syntax](https://uefi.org/specs/ACPI/6.5/19_ASL_Reference.html#asl-2-0-symbolic-operators-and-expressions)
|
||||
- [Predefined ACPI Names](https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#predefined-acpi-names)
|
||||
- [Adding devices to a device tree](devicetree.md)
|
||||
|
@ -1,9 +0,0 @@
|
||||
# Testing ACPI changes under Windows
|
||||
|
||||
When testing ACPI changes in coreboot against Windows 8 or newer, beware that
|
||||
during a normal boot after a clean shutdown, Windows will use the fast startup
|
||||
mechanism which results in it not evaluating the changed ACPI code but instead
|
||||
using some cached version which won't include the changes that were supposed to
|
||||
be tested. In order for Windows to actually use the new ACPI tables, either
|
||||
disable the fast startup or just tell Windows to do a reboot which will make it
|
||||
read and use the ACPI tables in memory instead of an outdated cached version.
|
@ -1,5 +1,7 @@
|
||||
# Firmware and Computer Acronyms, Initialisms and Definitions
|
||||
|
||||
** Note that this document even more of a work in progress than most **
|
||||
** of the coreboot documentation **
|
||||
|
||||
## _0-9
|
||||
|
||||
@ -9,7 +11,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
`acpihelp _XXX`
|
||||
* 2FA - [**Two-factor Authentication**](https://en.wikipedia.org/wiki/Multi-factor_authentication)
|
||||
* 4G - In coreboot, this typically refers to the 4 gibibyte boundary of 32-bit addressable memory space.
|
||||
Better abbreviated as 4GiB
|
||||
* 5G - Telecommunication: [**Fifth-Generation Cellular Network**](https://en.wikipedia.org/wiki/5G)
|
||||
|
||||
## A
|
||||
@ -18,25 +19,24 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
initialization that happens from the PSP. Significantly, Memory
|
||||
Initialization.
|
||||
* AC - Electricity: [**Alternating Current**](https://en.wikipedia.org/wiki/Alternating_current)
|
||||
* Ack - Acknowledgment / Acknowledged
|
||||
* Ack - Acknowledgment
|
||||
* ACM – [**Authenticated Code Module**](https://doc.coreboot.org/security/intel/acm.html)
|
||||
* ACP - [**Average CPU power**](https://en.wikipedia.org/wiki/Thermal_design_power)
|
||||
* ACPI - The [**Advanced Configuration and Power
|
||||
Interface**](http://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface)
|
||||
is an industry standard for letting the OS control power management.
|
||||
* [https://uefi.org/specifications](https://uefi.org/specifications)
|
||||
* [http://www.acpi.info/](http://www.acpi.info/)
|
||||
* [http://kernelslacker.livejournal.com/88243.html](http://kernelslacker.livejournal.com/88243.html)
|
||||
* ADC - [**Analog-to-Digital Converter**](https://en.wikipedia.org/wiki/Analog-to-digital_converter)
|
||||
* ADL - Intel: [**Alder Lake**](https://en.wikichip.org/wiki/intel/microarchitectures/alder_lake)
|
||||
* AES - [**Advanced Encryption Standard**](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)
|
||||
* AESKL - Intel: AES Key Locker
|
||||
* AGESA - [**AMD Generic Encapsulated Software Architecture**](https://en.wikipedia.org/wiki/AGESA_)
|
||||
* AGP - The [**Accelerated Graphics
|
||||
Port**](https://en.wikipedia.org/wiki/Accelerated_Graphics_Port) is an
|
||||
Port**](http://en.wikipedia.org/wiki/Accelerated_Graphics_Port) is an
|
||||
older (1997-2004) point-to-point bus for video cards to communicate
|
||||
with the processor.
|
||||
* AHCI - The [**Advanced Host Controller
|
||||
Interface**](https://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface)
|
||||
Interface**](http://en.wikipedia.org/wiki/Advanced_Host_Controller_Interface)
|
||||
is a standard register set for communicating with a SATA controller.
|
||||
* [http://www.intel.com/technology/serialata/ahci.htm](http://www.intel.com/technology/serialata/ahci.htm)
|
||||
* [http://download.intel.com/technology/serialata/pdf/rev1_3.pdf](http://download.intel.com/technology/serialata/pdf/rev1_3.pdf)
|
||||
@ -45,25 +45,20 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* ALIB - AMD: ACPI-ASL Library
|
||||
* ALS - [**Ambient Light Sensor**](https://en.wikipedia.org/wiki/Ambient_light_sensor)
|
||||
* ALU - [**Arithmetic Logic Unit**](https://en.wikipedia.org/wiki/Arithmetic_logic_unit)
|
||||
* AMBA - ARM: [**Advanced Microcontroller Bus
|
||||
Architecture**](https://en.wikipedia.org/wiki/Advanced_Microcontroller_Bus_Architecture):
|
||||
An open standard to connect and manage functional blocks in an SoC
|
||||
(System on a Chip)
|
||||
* AMD64 - Another name for [**x86-64**](https://en.wikipedia.org/wiki/X86-64)
|
||||
* AMD-Vi AMD: The AMD name for their IOMMU implementation
|
||||
* AMPL - AMD: [**Advanced Platform Management Link**](https://web.archive.org/web/20220509053546/https://developer.amd.com/wordpress/media/2012/10/419181.pdf) - Also referred to as
|
||||
SBI: Sideband Interface
|
||||
* AMT - Intel: [**Active Management Technology**](https://en.wikipedia.org/wiki/Intel_Active_Management_Technology)
|
||||
* ANSI - [**American National Standards Institute**](https://en.wikipedia.org/wiki/American_National_Standards_Institute)
|
||||
* ANSI - [**American National Standards Institute**](American_National_Standards_Institute)
|
||||
* AOAC - AMD: Always On, Always Connected
|
||||
* AP - Application processor - The main processor on the board (as
|
||||
opposed to the embedded controller or other processors that may be on
|
||||
the system), any cores in the processor chip that aren't the BSP (Boot
|
||||
Strap Processor).
|
||||
the system), any cores in processor chip that isn’t the BSP - Boot
|
||||
Strap Processor.
|
||||
* APCB - AMD: AMD PSP Customization Block
|
||||
* API - [**Application Programming Interface**](https://en.wikipedia.org/wiki/API)
|
||||
* APIC - [**Advanced Programmable Interrupt
|
||||
Controller**](https://en.wikipedia.org/wiki/Advanced_Programmable_Interrupt_Controller)
|
||||
Controller**](http://en.wikipedia.org/wiki/Advanced_Programmable_Interrupt_Controller)
|
||||
this is an advanced version of a PIC that can handle interrupts from
|
||||
and for multiple CPUs. Modern systems usually have several APICs:
|
||||
Local APICs (LAPIC) are CPU-bound, IO-APICs are bridge-bound.
|
||||
@ -90,7 +85,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* ASPM - PCI: [**Active State Power
|
||||
Management**](https://en.wikipedia.org/wiki/Active_State_Power_Management)
|
||||
* ATA - [**Advanced Technology Attachment**](https://en.wikipedia.org/wiki/Parallel_ATA)
|
||||
* ATS - PCIe: Address Translation Services
|
||||
* ATAPI - [**ATA Packet Interface**](https://en.wikipedia.org/wiki/Parallel_ATA#ATAPI)
|
||||
* ATX - [**Advanced Technology eXtended**](https://en.wikipedia.org/wiki/ATX)
|
||||
* AVX - [**Advanced Vector Extensions**](https://en.wikipedia.org/wiki/Advanced_Vector_Extensions)
|
||||
@ -98,7 +92,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
|
||||
## B
|
||||
|
||||
* BAR - [**Base Address Register**](https://en.wikipedia.org/wiki/Base_Address_Register) This generally refers to one of the
|
||||
* BAR - [**Base Address Register**](http://en.wikipedia.org/wiki/Base_Address_Register) This generally refers to one of the
|
||||
base address registers in the PCI config space of a PCI device
|
||||
* Baud - [**Baud**](https://en.wikipedia.org/wiki/Baud) - Not an acronym - Symbol rate unit of symbols per second, named
|
||||
after Émile Baudot
|
||||
@ -117,7 +111,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
the entire 4GiB of the 32-bit address space. Also known as flat mode
|
||||
or [**Unreal mode**](https://en.wikipedia.org/wiki/Unreal_mode).
|
||||
* BIOS - [**Basic Input/Output
|
||||
System**](https://en.wikipedia.org/wiki/BIOS)
|
||||
System**](http://en.wikipedia.org/wiki/BIOS)
|
||||
* BIST - The [**Built-in Self Test**](https://en.wikipedia.org/wiki/Built-in_self-test) is a test run by the processor on
|
||||
itself when it is first started. Usually, any nonzero value indicates
|
||||
that the selftest failed.
|
||||
@ -129,7 +123,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
stored as a single object, this was co-opted by the open source
|
||||
communities to mean any proprietary binary file that is not available
|
||||
as source code.
|
||||
* BM - [**Bus Master**](https://en.wikipedia.org/wiki/Bus_mastering)
|
||||
* BMC - [**Baseboard Management Controller**](https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface#Baseboard_management_controller)
|
||||
* BMP - [**Bitmap**](https://en.wikipedia.org/wiki/BMP_file_format)
|
||||
* BOM - [**Bill of Materials**](https://en.wikipedia.org/wiki/Bill_of_materials)
|
||||
@ -172,8 +165,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* CID - [**Coverity ID**](https://en.wikipedia.org/wiki/Coverity)
|
||||
* CIM - [**Common Information Model**](https://www.dmtf.org/standards/cim)
|
||||
* CISC - [**Complex Instruction Set Computer**](https://en.wikipedia.org/wiki/Complex_instruction_set_computer)
|
||||
* CL - ChangeList - Another name for a patch or commit. This seems to be
|
||||
Perforce notation.
|
||||
* CL - Change List - A git patch in gerrit
|
||||
* CLK - Clock - Used when there isn't enough room for 2 additional
|
||||
characters - similar to RST, for people who hate vowels.
|
||||
* CML - Intel: [**Comet Lake**](https://en.wikichip.org/wiki/intel/microarchitectures/comet_lake)
|
||||
@ -183,37 +175,33 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
generally used to describe a section of NVRAM (Non-volatile RAM), in
|
||||
this case a section battery-backed memory in the RTC (Real Time Clock)
|
||||
that is typically used to store BIOS settings.
|
||||
*[https://en.wikipedia.org/wiki/Nonvolatile_BIOS_memory](https://en.wikipedia.org/wiki/Nonvolatile_BIOS_memory)
|
||||
*[http://en.wikipedia.org/wiki/Nonvolatile_BIOS_memory](http://en.wikipedia.org/wiki/Nonvolatile_BIOS_memory)
|
||||
* CNL - Intel: [**Cannon Lake**](https://en.wikichip.org/wiki/intel/microarchitectures/cannon_lake) (formerly Skymont)
|
||||
* CNVi - Intel: [**Connectivity Integration**](https://en.wikipedia.org/wiki/CNVi)
|
||||
* CPL - x86: Current Privilege Level - Privilege levels range from 0-3; lower numbers are more privileged.
|
||||
* CPLD - [**Complex Programmable Logic Device**](https://en.wikipedia.org/wiki/Complex_programmable_logic_device)
|
||||
* CPPC - AMD: Collaborative Processor Performance Controls
|
||||
* CPS - Characters Per Second
|
||||
* CPU - [**Central Processing
|
||||
Unit**](https://en.wikipedia.org/wiki/Central_processing_unit)
|
||||
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
|
||||
ChromeOS devices.
|
||||
* CRB - Customer Reference Board
|
||||
* CRLF - Carriage Return, Line Feed - \\r\\n - The standard window EOL
|
||||
(End-of-Line) marker.
|
||||
* crt0 - [**C Run Time 0**](https://en.wikipedia.org/wiki/Crt0)
|
||||
* crt0 - [**C Run Time 0**](http://en.wikipedia.org/wiki/Crt0)
|
||||
* crt0s - crt0 Source code
|
||||
* CRT - [**Cathode Ray Tube**](https://en.wikipedia.org/wiki/Cathode-ray_tube)
|
||||
* CSE - Intel: Converged Security Engine
|
||||
* CSI - MIPI: [**Camera Serial
|
||||
Interface**](https://en.wikipedia.org/wiki/Camera_Serial_Interface)
|
||||
* CSME - Intel: Converged Security and Management Engine
|
||||
* CTLE - Intel: Continuous Time Linear Equalization
|
||||
* CVE - [**Common Vulnerabilities and Exposures**](https://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures)
|
||||
* CXMT - ChangXin Memory Technologies
|
||||
* CZN - AMD: [**Cezanne**](https://en.wikichip.org/wiki/amd/cores/cezanne) - CPU Family 19h, Model 50h
|
||||
* CZN - AMD: Cezanne - CPU Family 19h, Model 50h
|
||||
|
||||
|
||||
## D
|
||||
|
||||
* D$ - Data Cache
|
||||
* D-States - [**ACPI Device power
|
||||
states**](https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface#Device_states)
|
||||
D0-D3 - These are device specific power states, with each higher
|
||||
@ -226,9 +214,8 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
still has power.
|
||||
* D3 Cold - ACPI Device power state: Power is completely removed from
|
||||
the device.
|
||||
* DASH - [**Desktop and mobile Architecture for System Hardware**](https://en.wikipedia.org/wiki/Desktop_and_mobile_Architecture_for_System_Hardware)
|
||||
* DASH - [**Desktop and mobile Architecture for System Hardware**](Desktop_and_mobile_Architecture_for_System_Hardware)
|
||||
* DB - DaughterBoard
|
||||
* DbC - USB: Debug Capability on the USB host controller
|
||||
* DC - Electricity: Direct Current
|
||||
* DCP - Digital Content Protection
|
||||
* DCR - **Decode Control Register** This is a way of identifying the
|
||||
@ -236,23 +223,19 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* DDC - [**Display Data Channel**](https://en.wikipedia.org/wiki/Display_Data_Channel)
|
||||
* DDI - Intel: Digital Display Interface
|
||||
* DDR - [**Double Data Rate**](https://en.wikipedia.org/wiki/Double_data_rate)
|
||||
* DEVAPC - Mediatek: Device Access Permission Control
|
||||
* DF - Data Fabric
|
||||
* DFP - USB: Downstream Facing port
|
||||
* DHCP - [**Dynamic Host Configuration Protocol**](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol)
|
||||
* DID - Device Identifier
|
||||
* DIMM - [**Dual Inline Memory Module**](https://en.wikipedia.org/wiki/DIMM)
|
||||
* DIP - [**Dual inline package**](https://en.wikipedia.org/wiki/Dual_in-line_package)
|
||||
* DMA - [**Direct Memory
|
||||
Access**](https://en.wikipedia.org/wiki/Direct_memory_access) Allows
|
||||
Access**](http://en.wikipedia.org/wiki/Direct_memory_access) Allows
|
||||
certain hardware subsystems within a computer to access system memory
|
||||
for reading and/or writing independently of the main CPU. Examples of
|
||||
systems that use DMA: Hard Disk Controller, Disk Drive Controller,
|
||||
Graphics Card, Sound Card. DMA is an essential feature of all modern
|
||||
computers, as it allows devices of different speeds to communicate
|
||||
without subjecting the CPU to a massive interrupt load.
|
||||
* DMI - Direct Media Interface is a link/bus between CPU and PCH.
|
||||
* DMI - [**Desktop Management Interface**](https://en.wikipedia.org/wiki/Desktop_Management_Interface)
|
||||
* DMI - [**Desktop Management Interface**](Desktop_Management_Interface)
|
||||
* DMIC - Digital Microphone
|
||||
* DMTF - [**Distributed Management Task Force**](https://en.wikipedia.org/wiki/Distributed_Management_Task_Force)
|
||||
* DMZ - Demilitarized Zone
|
||||
@ -260,8 +243,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* DNV - Intel: [**Denverton**](https://en.wikichip.org/wiki/intel/cores/denverton)
|
||||
* DOS - Disk Operating System
|
||||
* DP - DisplayPort
|
||||
* DPM - Mediatek: DRAM Power Manager
|
||||
* DPTC - AMD: Dynamic Power and Thermal Control
|
||||
* DPTF - Intel: Dynamic Power and Thermal Framework
|
||||
* DRAM - Memory: [**Dynamic Random Access Memory**](https://en.wikipedia.org/wiki/Dynamic_random-access_memory)
|
||||
* DRTM - Dynamic Root of Trust for Measurement
|
||||
@ -269,10 +250,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
data-in pin is generally referred to as D, and the data-out pin is Q,
|
||||
thus the IO Data signal lines are referred to as DQ lines.
|
||||
* DQS - Memory: Data Q Strobe - Data valid signal for DDR memory.
|
||||
* DRM - [**Digital Rights
|
||||
Management**](https://en.wikipedia.org/wiki/Digital_rights_management)
|
||||
* DRP - USB: Port than can be switched between either a Downstream facing (DFP) or
|
||||
an Upstream Facing (UFP).
|
||||
* DRM - [**Digital Rights Management**](https://en.wikipedia.org/wiki/Digital_rights_management)
|
||||
* DRQ - DMA Request
|
||||
* DRTU - Intel: Diagnostics and Regulatory Testing Utility
|
||||
* DSDT - The [**Differentiated System Descriptor
|
||||
@ -284,26 +262,19 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* DSL - [**Digital subscriber line**](https://en.wikipedia.org/wiki/Digital_subscriber_line)
|
||||
* DSP - [**Digital Signal Processor**](https://en.wikipedia.org/wiki/Digital_signal_processor)
|
||||
* DTB - U-Boot: Device Tree Binary
|
||||
* dTPM - Discrete TPM (Trusted Platform Module) - A separate TPM chip,
|
||||
vs Integrated TPMs or fTPMs (Firmware TPMs).
|
||||
* dTPM - Discrete Trusted Platform Module
|
||||
* DTS - U-Boot: Device Tree Source
|
||||
* DUT - Device Under Test
|
||||
* DvC - USB: Debug Capability on the USB Device (Device Capability)
|
||||
* DVFS - ARM: Dynamic Voltage and Frequency Scaling
|
||||
* DVI - [**Digital Video Interface**](https://en.wikipedia.org/wiki/Digital_Visual_Interface)
|
||||
* DVT - Production Timeline: Design Validation Test
|
||||
* DW - DesignWare: A portfolio of silicon IP blocks for sale by the
|
||||
Synopsys company. Includes blocks like USB, MIPI, PCIe, HDMI, SATA,
|
||||
I2c, memory controllers and more.
|
||||
* DW - DesignWare
|
||||
* DXE - UEFI: [**Driver Execution Environment**](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface#DXE_%E2%80%93_Driver_Execution_Environment_)
|
||||
* DXIO - AMD: Distributed CrossBar I/O
|
||||
|
||||
|
||||
## E
|
||||
|
||||
* EAPD - Intel: [**External Amplifier Power Down**](https://web.archive.org/web/20210203194800/https://www.eeweb.com/hd-audio-eapd/)
|
||||
* EBDA - Extended BIOS Data Area
|
||||
* EBG - Intel: Emmitsburg PCH
|
||||
* ECC - [**Error Correction Code**](https://en.wikipedia.org/wiki/Error_correction_code) - Typically used to refer to a type of
|
||||
memory that can detect and correct memory errors.
|
||||
* EDID - [**Extended Display Identification Data**](https://en.wikipedia.org/wiki/Extended_Display_Identification_Data)
|
||||
@ -312,12 +283,11 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
Out**](https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Extended_data_out_DRAM)
|
||||
- A DRAM standard introduced in 1994 that improved upon, but was
|
||||
backwards compatible with FPM (Fast Page Mode) memory.
|
||||
* eDP - [**Embedded DisplayPort**](https://en.wikipedia.org/wiki/DisplayPort#eDP)
|
||||
* EDP - [**Embedded DisplayPort**](DisplayPort)
|
||||
* EDS - Intel: External Design Specification
|
||||
* EEPROM - [**Electrically Erasable Programmable ROM**](https://en.wikipedia.org/wiki/EEPROM) (common mistake:
|
||||
electrical erasable programmable ROM).
|
||||
* EFI - [**Extensible Firmware Interface**](https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface)
|
||||
* EFS - AMD: Embedded Firmware Structure: The data structure that AMD processors look for first in the boot ROM to start the boot process.
|
||||
* EHCI - [**Enhanced Host Controller Interface**](https://en.wikipedia.org/wiki/Host_controller_interface_%28USB%2C_Firewire%29#EHCI) - USB 2.0
|
||||
* EHL - Intel: [**Elkhart Lake**](https://en.wikichip.org/wiki/intel/cores/elkhart_lake)
|
||||
* EIDE - Enhanced Integrated Drive Electronics
|
||||
@ -329,7 +299,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* EOL - End of Life
|
||||
* EPP - Intel: Energy-Performance Preference
|
||||
* EPROM - Erasable Programmable Read-Only Memory
|
||||
* EROFS - Linux: [**Enhanced Read-Only File System**](https://en.wikipedia.org/wiki/EROFS)
|
||||
* ESD - Electrostatic discharge
|
||||
* eSPI - Enhanced System Peripheral Interface
|
||||
* EVT - Production Timeline: Engineering Validation Test
|
||||
@ -340,7 +309,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* FADT - ACPI Table: Fixed ACPI Description Table
|
||||
* FAE - Field Application Engineer
|
||||
* FAT - File Allocation Table
|
||||
* FBVDDQ - Nvidia Power: Framebuffer Voltage
|
||||
* FCH - AMD: Firmware Control Hub
|
||||
* FCS - Production Timeline: First Customer Shipment
|
||||
* FDD - Floppy Disk Drive
|
||||
@ -358,7 +326,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* FPDT - ACPI: Firmware Performance Data Table
|
||||
* FPGA - [**Field-Programmable Gate Array**](https://en.wikipedia.org/wiki/Field-programmable_gate_array)
|
||||
* Framebuffer - The
|
||||
[**framebuffer**](https://en.wikipedia.org/wiki/Framebuffer) is a part
|
||||
[**framebuffer**](http://en.wikipedia.org/wiki/Framebuffer) is a part
|
||||
of RAM in a computer which is allocated to hold the graphics
|
||||
information for one frame or picture. This information typically
|
||||
consists of color values for every pixel on the screen. A framebuffer
|
||||
@ -370,15 +338,9 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* FPM - Memory: [**Fast Page Mode**](https://en.wikipedia.org/wiki/Dynamic_random-access_memory#Page_mode_DRAM) - A DRAM standard introduced in 1990.
|
||||
* FPU - [**Floating-Point Unit**](https://en.wikipedia.org/wiki/Floating-point_unit)
|
||||
* FSB - [**Front-Side Bus**](https://en.wikipedia.org/wiki/Front-side_bus)
|
||||
* FSM - Finite State Machine
|
||||
* FSP - Intel: Firmware Support Package
|
||||
* FSR - Intel: Firmware Status Register
|
||||
* FTP - Network Protocol: [**File Transfer Protocol**](https://en.wikipedia.org/wiki/File_Transfer_Protocol)
|
||||
* fTPM - Firmware TPM (Trusted Platform Module). This is a TPM that is
|
||||
based in firmware instead of actual hardware. It typically runs in
|
||||
some sort of TEE (Trusted Execution Environment).
|
||||
* FWCM Intel: firmware Connection Manager
|
||||
* FWID - Firmware Identifier
|
||||
* FTPM - Firmware TPM
|
||||
|
||||
|
||||
## G
|
||||
@ -394,15 +356,12 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
Real Time Clock, and maybe a few other registers running.
|
||||
* GART - AMD: [**Graphics Address Remapping Table**](https://en.wikipedia.org/wiki/Graphics_address_remapping_table)
|
||||
* GATT - Graphics Aperture Translation Table
|
||||
* GDT - [Global Descriptor Table](https://wiki.osdev.org/Global_Descriptor_Table)
|
||||
* GLK - Intel: [**Gemini Lake**](https://en.wikichip.org/wiki/intel/cores/gemini_lake)
|
||||
* GMA - Intel: [**Graphics Media
|
||||
Accelerator**](https://en.wikipedia.org/wiki/Intel_GMA)
|
||||
* GNB - Graphics NorthBridge
|
||||
* GND - Power: Ground
|
||||
* GNVS - Global Non-Volatile Storage
|
||||
* GPD - PCH GPIO in Deep Sleep well (D5 power)
|
||||
* GPE - ACPI: General Purpose Event
|
||||
* GPI - GPIOs: GPIO Input
|
||||
* GPIO - [**General Purpose Input/Output**](https://en.wikipedia.org/wiki/General-purpose_Input/Output) (Pin)
|
||||
* GPMR - Intel: General Purpose Memory Range
|
||||
@ -414,30 +373,21 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* GPU - [**Graphics Processing Unit**](https://en.wikipedia.org/wiki/Graphics_processing_unit)
|
||||
* GSoC - [**Google Summer of Code**](https://en.wikipedia.org/wiki/Google_Summer_of_Code)
|
||||
* GSC - Google Security Chip - Typically Cr50/Ti50, though could also refer to the titan chips
|
||||
* GSPI - Generic SPI - These are SPI controllers available for general
|
||||
use, not dedicated to flash, for example.
|
||||
* GTDT - ACPI: Generic Timer Description Table
|
||||
* GTT - [**Graphics Translation Table**](https://en.wikipedia.org/wiki/Graphics_address_remapping_table)
|
||||
* GUID - UEFI: [**Globally Unique IDentifier**](https://en.wikipedia.org/wiki/Universally_unique_identifier)
|
||||
|
||||
|
||||
## H
|
||||
|
||||
* HBP - Graphics: [**Horizontal Back Porch**](https://en.wikipedia.org/wiki/Horizontal_blanking_interval) In the Horizontal blanking interval, this is the blank area past the end of the scanline
|
||||
* HDA - [**High Definition Audio**](https://en.wikipedia.org/wiki/Intel_High_Definition_Audio)
|
||||
* HDCP - [**High-bandwidth Digital Content Protection**](https://en.wikipedia.org/wiki/High-bandwidth_Digital_Content_Protection)
|
||||
* HDD - Hard Disk Drive
|
||||
* HDMI - [**High-Definition Multimedia Interface**](https://en.wikipedia.org/wiki/HDMI)
|
||||
* HDR - [**High Dynamic Range**](https://en.wikipedia.org/wiki/High_dynamic_range)
|
||||
* HECI - Intel: [**Host Embedded Controller Interface**](https://en.wikipedia.org/wiki/Host_Embedded_Controller_Interface) (Replaced by MEI)
|
||||
* HFP - Graphics: [**Horizontal Front Porch**](https://en.wikipedia.org/wiki/Horizontal_blanking_interval) In the Horizontal blanking interval, this is the blank before the start of the next scanline.
|
||||
* HID - [**Human Interface
|
||||
Device**](https://en.wikipedia.org/wiki/Human_interface_device)
|
||||
* HOB - UEFI: Hand-Off Block
|
||||
* HPD - Hot-Plug Detect
|
||||
* HPET - [**High Precision Event Timer**](https://en.wikipedia.org/wiki/High_Precision_Event_Timer)
|
||||
* HSP - AMD: Hardware Security Processor
|
||||
* HSPHY - USB: USB3 High-Speed PHY
|
||||
* HSTI - Hardware Security Test Interface
|
||||
* HSW - Intel: Haswell
|
||||
* Hybrid S3 - System Power State: This is where the operating system
|
||||
@ -446,7 +396,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
resume quickly from S3 if the system stays powered, and resume from
|
||||
the disk if power is lost.
|
||||
* Hypertransport - AMD: The
|
||||
[**Hypertransport**](https://en.wikipedia.org/wiki/Hypertransport) bus
|
||||
[**Hypertransport**](http://en.wikipedia.org/wiki/Hypertransport) bus
|
||||
is an older (2001-2017) high-speed electrical interconnection protocol
|
||||
specification between CPU, Memory, and (occasionally) peripheral
|
||||
devices. This was originally called the Lightning Data Transport
|
||||
@ -457,7 +407,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
|
||||
## I
|
||||
|
||||
* I$ - Instruction Cache
|
||||
* I2C - **Inter-Integrated Circuit** is a bidirectional 2-wire bus for
|
||||
communication generally between different ICs on a circuit board.
|
||||
* [https://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus.html](https://www.esacademy.com/en/library/technical-articles-and-documents/miscellaneous/i2c-bus.html)
|
||||
@ -467,7 +416,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
- Also known as SenseWire
|
||||
* IA - Intel Architecture
|
||||
* IA-64 - Intel Itanium 64-bit architecture
|
||||
* IAFC - RISC-V: [**RISC-V Base Integer instruction set**](https://en.wikipedia.org/wiki/RISC-V), plus atomic instructions, single precision floating point instructions, and compressed instructions
|
||||
* IBB – Initial Boot Block
|
||||
* IBV - Independent BIOS Vendor
|
||||
* IC - Integrated Circuit
|
||||
@ -480,12 +428,9 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* IDSEL/AD - Initialization Device SELect/Address and Data. Each PCI
|
||||
slot has a signal called IDSEL. It is used to differentiate between
|
||||
the different slots.
|
||||
* IDT - [Interrupt Descriptor Table](https://en.wikipedia.org/wiki/Interrupt_descriptor_table)
|
||||
* IF - AMD: [**Infinity
|
||||
Fabric**](https://en.wikipedia.org/wiki/HyperTransport#Infinity_Fabric)
|
||||
is a superset of AMD's earlier Hypertransport interconnect.
|
||||
* IFD - Intel: Intel Flash Descriptor
|
||||
* IMAFC - RISC-V: [**RISC-V Base Integer instruction set**](https://en.wikipedia.org/wiki/RISC-V), plus integer multiply & divide, atomic instructions, single precision floating point instructions, and compressed instructions
|
||||
* IMC - AMD: Integrated micro-controller - An 8051 microcontroller built
|
||||
into some AMD FCHs (Fusion Controller Hubs) and Southbridge chips.
|
||||
This never worked well for anything beyond fan control and caused
|
||||
@ -497,7 +442,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* IoC - Security: Indicator of Compromise
|
||||
* IOC - Intel: I/O Cache
|
||||
* IOE - Intel: I/O Expander
|
||||
* IOHC - AMD: I/O Hub Controller
|
||||
* IOM - Intel: I/O Manager
|
||||
* IOMMU - [**I/O Memory Management Unit**](https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit)
|
||||
* IOMUX - AMD: The I/O Mux block controls how each GPIO is configured.
|
||||
@ -520,7 +464,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* IVHD - ACPI: I/O Virtualization Hardware Definition
|
||||
* IVMD - ACPI: I/O Virtualization Memory Definition
|
||||
* IVRS - I/O Virtualization Reporting Structure
|
||||
* IWYU - Include What you Use - A tool to help with include file use
|
||||
|
||||
|
||||
## J
|
||||
@ -574,7 +517,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
count**](http://www.intel.com/design/chipsets/industry/lpc.htm) bus
|
||||
was a replacement for the ISA bus, created by serializing a number of
|
||||
parallel signals to get rid of those connections.
|
||||
* LPM - USB: Link Power Management
|
||||
* LPT - Line Print Terminal, Local Print Terminal, or Line Printer. -
|
||||
The Parallel Port
|
||||
* LRU - Least Recently Used - a rule used in operating systems that
|
||||
@ -591,21 +533,13 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
|
||||
* M.2 - An interface specification for small peripheral cards.
|
||||
* MAC Address - Media Access Control Address
|
||||
* MAFS - (eSPI) Master Attached Flash Sharing: Flash components are
|
||||
attached to the controller device and may be accessed by by the
|
||||
peripheral devices through the eSPI flash access channel.
|
||||
* MBP - Intel UEFI: ME-to-BIOS Payload
|
||||
* MBR - Master Boot Record
|
||||
* MCA - [**Machine Check Architecture**](https://en.wikipedia.org/wiki/Machine_Check_Architecture)
|
||||
* MCR - Machine Check Registers
|
||||
* MCTP - [**Management Component Transport Protocol**](https://en.wikipedia.org/wiki/Management_Component_Transport_Protocol)
|
||||
* MCU - Memory Control Unit
|
||||
* MCU - [**MicroController
|
||||
Unit**](https://en.wikipedia.org/wiki/Microcontroller)
|
||||
* MCUPM - Mediatek: MCUPM is a hardware module which is used for MCUSYS Power Management. MCUPM firmware (mcupm.bin) is loaded into MCUPM SRAM at system initialization.
|
||||
* MDFIO - Intel: Multi-Die Fabric IO
|
||||
* MDN - AMD: Mendocino
|
||||
* mDP - Mini DisplayPort connector
|
||||
* ME - Intel: Management Engine
|
||||
* MEI - Intel: ME Interface (Previously known as HECI)
|
||||
* Memory training - the process of finding the best speeds, voltages,
|
||||
@ -622,7 +556,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* MKBP - Matrix Keyboard Protocol
|
||||
* MMC - [**MultiMedia
|
||||
Card**](https://en.wikipedia.org/wiki/MultiMediaCard)
|
||||
* MMIO - [**Memory Mapped I/O**](https://en.wikipedia.org/wiki/MMIO)
|
||||
* MMIO - [**Memory Mapped I/O**](http://en.wikipedia.org/wiki/MMIO)
|
||||
allows peripherals' memory or registers to be accessed directly
|
||||
through the memory bus. When the memory bus size was very small, this
|
||||
was initially done by hiding any memory at that address, effectively
|
||||
@ -644,28 +578,23 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
OS software writers to produce SMP-capable machines and OSes in a
|
||||
vendor-independent manner. Version 1.1 of the spec was released in
|
||||
1994, and the 1.4 version was released in 1995. This has been
|
||||
generally superseded by the ACPI tables.
|
||||
generally been
|
||||
https://en.wikipedia.org/wiki/MultiProcessor_Specification by the ACPI
|
||||
tables.
|
||||
* MRC - Intel: Memory Reference Code
|
||||
* MSB - Most Significant Bit
|
||||
* MSI - Message Signaled Interrupt
|
||||
* MSR - Machine-Specific Register
|
||||
* MTS or MT/s - MegaTransfers per second
|
||||
* MT/s - MegaTransfers per second
|
||||
* MTL - Intel: Meteor Lake
|
||||
* MTL - ARM: MHU Transport Layer
|
||||
* MTRR - [**Memory Type and Range Register**](https://en.wikipedia.org/wiki/MTRR)
|
||||
allows to set the cache behaviour on memory access in x86. Basically,
|
||||
it tells the CPU how to cache certain ranges of memory
|
||||
(e.g. write-through, write-combining, write-back...). Memory ranges
|
||||
are specified over physical address ranges. In Linux, they are visible
|
||||
over `/proc/mtrr` and they can be modified there. For further
|
||||
information, see the [**Linux documentation**](https://www.kernel.org/doc/html/v5.19/x86/pat.html).
|
||||
* MXM - PCIe: [**Mobile PCI Express Module**](https://en.wikipedia.org/wiki/Mobile_PCI_Express_Module)
|
||||
* MTRR - [**Memory Type and Range
|
||||
Register**](http://en.wikipedia.org/wiki/MTRR)
|
||||
|
||||
|
||||
## N
|
||||
|
||||
* Nack - Negative Acknowledgement
|
||||
* NB - North Bridge
|
||||
* NBCI - Nvidia: NoteBook Common Interface
|
||||
* NC - GPIOs: No Connect
|
||||
* NDA - Non-Disclosure Agreement.
|
||||
@ -685,7 +614,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* NVME - Non-Volatile Memory Express - An SSD interface that allows
|
||||
access to the flash memory through a PCIe bus.
|
||||
* NVPCF - Nvidia Platform and Control Framework
|
||||
* NVVDD - Nvidia Power: Core voltage
|
||||
* NX - No Execute
|
||||
|
||||
|
||||
@ -693,8 +621,8 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
|
||||
* ODH - GPIOs: Open Drain High - High is driven to the reference voltage, low is a high-impedance state
|
||||
* ODL - GPIOs: Open Drain Low - Low is driven to ground, High is a high-impedance state.
|
||||
* ODM - [**Original Design Manufacturer**](https://en.wikipedia.org/wiki/Original_design_manufacturer)
|
||||
* OEM - [**Original Equipment Manufacturer**](https://en.wikipedia.org/wiki/Original_equipment_manufacturer)
|
||||
* ODM - Original Design Manufacturer
|
||||
* OEM - Original Equipment Manufacturer
|
||||
* OHCI - [**Open Host Controller
|
||||
Interface**](https://en.wikipedia.org/wiki/Host_Controller_Interface_%28USB%29)
|
||||
- non-proprietary USB Host controller for USB 1.1 (May also refer to
|
||||
@ -715,9 +643,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* PAT - [**Page Attribute
|
||||
Table**](https://en.wikipedia.org/wiki/Page_attribute_table) This can
|
||||
be used independently or in combination with MTRR to setup memory type
|
||||
access ranges. Allows more finely-grained control than MTRR. Compared to MTRR,
|
||||
which sets memory types by physical address ranges, PAT sets them at Page
|
||||
level.
|
||||
access ranges. Allows more finely-grained control than MTRR.
|
||||
* PAT - Intel: [**Performance Acceleration
|
||||
Technology**](https://en.wikipedia.org/wiki/Performance_acceleration_technology)
|
||||
* PATA - Parallel Advanced Technology Attachment - A renaming of ATA
|
||||
@ -731,23 +657,21 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* PCD - UEFI: Platform Configuration Database
|
||||
* PCH - Intel: [**Platform Controller Hub**](https://en.wikipedia.org/wiki/Platform_Controller_Hub)
|
||||
* PCI - [**Peripheral Control
|
||||
Interconnect**](https://en.wikipedia.org/wiki/Peripheral_Component_Interconnect)
|
||||
Interconnect**](http://en.wikipedia.org/wiki/Peripheral_Component_Interconnect)
|
||||
- Replaced generally by PCIe (PCI Express)
|
||||
* PCI Configuration Space - The [**PCI Config
|
||||
space**](https://en.wikipedia.org/wiki/PCI_Configuration_Space) is an
|
||||
space**](http://en.wikipedia.org/wiki/PCI_Configuration_Space) is an
|
||||
[address space](https://en.wikipedia.org/wiki/Address_space) for all
|
||||
PCI devices. Originally, this address space was accessed through an
|
||||
index/data pair by writing the address that you wanted to read/write
|
||||
into the I/O address 0xCF8, then reading or writing I/O Address 0xCFC.
|
||||
This has been updated to an MMIO method which increases each PCI
|
||||
function's configuration space from 256 bytes to 4K.
|
||||
* PCIe - [**PCI Express**](https://en.wikipedia.org/wiki/Pci_express)
|
||||
* PCIe - [**PCI Express**](http://en.wikipedia.org/wiki/Pci_express)
|
||||
* PCMCIA: Personal Computer Memory Card International Association
|
||||
* PCO - AMD: [**Picasso**](https://en.wikichip.org/wiki/amd/cores/picasso)
|
||||
* PCO - AMD: Picasso
|
||||
* PCR: TPM: Platform Configuration Register
|
||||
* PD - GPIOs: Pull-Down - Drives the pin to ground through a resistor.
|
||||
The resistor allows the pin to be set to the reference voltage as
|
||||
needed.
|
||||
* PD - GPIOs: Pull-Down - Setting the pin high drives it to the reference voltage. Setting it low drives it to ground through a resistor.
|
||||
* PD - Power Delivery - This is a specification for communicating power
|
||||
needs and availability between two devices, typically over USB type C.
|
||||
* PEG - PCIe Graphics - A (typically) x16 PCIe slot connected to the CPU
|
||||
@ -755,9 +679,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* PEI - UEFI: Pre-EFI Initialization
|
||||
* PEIM - UEFI: PEI Module
|
||||
* PEP - Intel: Power Engine Plug-in
|
||||
* PEXVDD - Nvidia Power: PCIExpress Voltage
|
||||
* PHX - AMD: Phoenix SoC
|
||||
* PHY - [**PHYsical layer**](https://en.wikipedia.org/wiki/PHY) - The
|
||||
* PHY - [**PHYsical layer**](http://en.wikipedia.org/wiki/PHY) - The
|
||||
hardware that implements the send/receive functionality of a
|
||||
communication protocol.
|
||||
* PI - Platform Initialization
|
||||
@ -776,7 +698,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* PIT - Generally refers to the 8253/8254 [**Programmable Interval
|
||||
Timer**](https://en.wikipedia.org/wiki/Programmable_interval_timer).
|
||||
* PLCC - [**Plastic leaded chip
|
||||
carrier**](https://en.wikipedia.org/wiki/Plastic_leaded_chip_carrier)
|
||||
carrier**](http://en.wikipedia.org/wiki/Plastic_leaded_chip_carrier)
|
||||
* PLL - [**Phase-Locked
|
||||
Loop**](https://en.wikipedia.org/wiki/Phase-locked_loop)
|
||||
* PM - Platform Management
|
||||
@ -798,21 +720,15 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* POTS - [**Plain Old Telephone
|
||||
Service**](https://en.wikipedia.org/wiki/Plain_old_telephone_service)
|
||||
* PPI - UEFI: PEIM-to-PEIM Interface
|
||||
* PPR - Processor Programming Reference
|
||||
* PPR: Processor Programming Reference
|
||||
* PPT - AMD: Package Power Tracking
|
||||
* PROM - Programmable Read Only Memory
|
||||
* PROM: Programmable Read Only Memory
|
||||
* Proto - Production Timeline: The first initial production to test key
|
||||
concepts.
|
||||
* PSE - Page Size Extention
|
||||
* PSF - Intel: Primary Sideband Fabric
|
||||
* PSP - AMD: Platform Security Processor
|
||||
* PSPP - AMD: PCIE Speed Power Policy
|
||||
* PSR - Intel: Platform Service Record
|
||||
* PSR - Graphics: Panel Self-Refresh - This is a power-savings feature specified in eDP
|
||||
* PTT - Intel: Platform Trust Technology - Intel's firmware based TPM.
|
||||
* PU - GPIOs: Pull-Up - Drives the pin to reference voltage through a
|
||||
resistor. The resistor allows the signal to still be set to ground
|
||||
when needed.
|
||||
* PU - GPIOs: Pull-Up - Setting the pin low drives it to ground. Setting it high drives it to the reference voltage through a resistor.
|
||||
* PVT - Production Timeline: (Production Validation Test
|
||||
* PWM - Pulse Width Modulation
|
||||
* PXE - Pre-boot Execution Environment
|
||||
@ -835,7 +751,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
a set of 3 or 4 GPIOs to allow 8 to 16 different memory chips to be
|
||||
used.
|
||||
* RAPL - Running Average Power Limit
|
||||
* RCB - PCIe: Read Completion Boundary - Sets the address alignment on which a read request may be serviced with multiple completions
|
||||
* RCS - [**Revision control
|
||||
system**](https://en.wikipedia.org/wiki/Revision_Control_System)
|
||||
* Real mode - The original 20-bit addressing mode of the 8086 & 8088
|
||||
@ -843,7 +758,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
Segment:Offset index pair. In 2022, this is still the mode that
|
||||
x86-64 processors are in at the reset vector!
|
||||
* RDMA - [**Remote Direct Memory
|
||||
Access**](https://en.wikipedia.org/wiki/Remote_Direct_Memory_Access) is
|
||||
Access**](http://en.wikipedia.org/wiki/Remote_Direct_Memory_Access) is
|
||||
a concept whereby two or more computers communicate via DMA directly
|
||||
from main memory of one system to the main memory of another.
|
||||
* RFC - Request for Comment
|
||||
@ -856,11 +771,9 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* ROM - Read Only Memory
|
||||
* RoT - Root of Trust
|
||||
* RPL - Intel: [**Raptor Lake**](https://en.wikipedia.org/wiki/Raptor_Lake)
|
||||
* RPP - Intel: Raptor Point PCH
|
||||
* RRG - AMD (ATI): Register Reference Guide
|
||||
* RSDP - Root System Description Pointer
|
||||
* RTC - Real Time Clock
|
||||
* RTD3 - Power State: Runtime D3
|
||||
* RTFM - Read the Fucking Manual
|
||||
* RTOS - Real-Time Operating System
|
||||
* RVP - Intel: Reference Validation Platform
|
||||
@ -896,11 +809,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
contents of memory. Any critical processor state is restored.
|
||||
* S5 - ACPI System Power State: System is “completely powered off”, but
|
||||
still has power going to the board.
|
||||
* SAFS - (eSPI) Slave Attached Flash Sharing: Flash is attached to the
|
||||
peripheral device. Only valid for server platforms.
|
||||
* SAGV - Intel: System Agent Geyserville. The original internal name
|
||||
for the feature eventually released as Speedstep which controls the
|
||||
processor voltage and frequencies.
|
||||
* SAR - The [**Specific Absorption
|
||||
Rate**](https://en.wikipedia.org/wiki/Specific_absorption_rate) is the
|
||||
measurement for the amount of Radio Frequency (RF) energy absorbed by
|
||||
@ -924,13 +832,11 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
SAS (Serial Attached SCSI). The initial version is now often referred
|
||||
to as Parallel SCSI.
|
||||
* SD - [**Secure Digital**](https://en.wikipedia.org/wiki/SD_card) card
|
||||
* SDHCI - SD Host Controller Interface
|
||||
* SDRAM - Synchronous DRAM
|
||||
* SDLE: AMD: Stardust Dynamic Load Emulator
|
||||
* SEEP - Serial EEPROM (Electrically Erasable Programmable Read-Only
|
||||
Memory)
|
||||
* SEV - AMD: Secure Encrypted Virtualization
|
||||
* SF - Snoop Filter
|
||||
* Shadow RAM - RAM which content is copied from ROM residing at the same
|
||||
address for speedup purposes.
|
||||
* Shim - A small piece of code whose only purpose is to act as an
|
||||
@ -948,7 +854,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* SMBus - [**System Management
|
||||
Bus**](https://en.wikipedia.org/wiki/System_Management_Bus)
|
||||
* [http://www.smbus.org/](http://www.smbus.org/)
|
||||
* SME - AMD: Secure Memory Encryption
|
||||
* SMI - System management interrupt
|
||||
* SMM - [**System management
|
||||
mode**](https://en.wikipedia.org/wiki/System_Management_Mode)
|
||||
@ -962,15 +867,13 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* SO-DIMM: Small Outline Dual In-Line Memory Module
|
||||
* SoC - System on a Chip
|
||||
* SOIC - [**Small-Outline Integrated
|
||||
Circuit**](https://en.wikipedia.org/wiki/Small-outline_integrated_circuit)
|
||||
Circuit**](http://en.wikipedia.org/wiki/Small-outline_integrated_circuit)
|
||||
* SPD - [**Serial Presence
|
||||
Detect**](https://en.wikipedia.org/wiki/Serial_presence_detect)
|
||||
* SPI - [**Serial Peripheral
|
||||
Interface**](https://en.wikipedia.org/wiki/Serial_Peripheral_Interface)
|
||||
* SPL - AMD: Security Patch Level
|
||||
* SPM - Mediatek: System Power Manager
|
||||
* SPMI - MIPI: System Power Management Interface
|
||||
* SPR - Sapphire Rapids
|
||||
* SRAM - Static Random Access Memory
|
||||
* SSD - Solid State Drive
|
||||
* SSDT - Secondary System Descriptor Table - ACPI table
|
||||
@ -986,25 +889,19 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
Bay**](https://en.wikipedia.org/wiki/SSI_CEB)
|
||||
* SSI-TEB - Physical board format: [**SSI Thin Electronics
|
||||
Bay**](https://en.wikipedia.org/wiki/SSI_CEB)
|
||||
* SSP - [**Speech Signal Processor**](https://en.wikipedia.org/wiki/Speech_processing)
|
||||
* SSPHY - USB: USB3 Super-Speed PHY
|
||||
* STAPM - AMD: Skin Temperature Aware Power Management
|
||||
* STB - AMD: Smart Trace Buffer
|
||||
* SuperIO - The [**Super I/O**](https://en.wikipedia.org/wiki/Super_I/O)
|
||||
(SIO) device provides a system with any of a number of different
|
||||
peripherals. Most common are: A PS/2 Keyboard and mouse port, LPT
|
||||
Ports, UARTS, Watchdog Timers, Floppy drive Controllers, GPIOs, or any
|
||||
of a number of various other devices.
|
||||
* SVC - ARM: Supervisor Call
|
||||
* SVI2/3 - Serial VID (Voltage Identification) Interface 2.0 / 3.0
|
||||
* SWCM - Intel: Software Connection Manager
|
||||
|
||||
|
||||
## T
|
||||
|
||||
* TBT - Thunderbolt
|
||||
* TBT - Intel: Turbo Boost Technology
|
||||
* tBUF - I2C: The bus free time between a STOP and START condition
|
||||
* TCC - Intel: Thermal Control Circuit
|
||||
* TCP - Transmission Control Protocol
|
||||
* TCPC - Type C Port Controller
|
||||
@ -1012,8 +909,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* TDMA - Time-Division Multiple Access
|
||||
* TDP - [**Thermal Design
|
||||
Power**](https://en.wikipedia.org/wiki/Thermal_design_power)
|
||||
* TEE - [**Trusted Execution
|
||||
Environment**](https://en.wikipedia.org/wiki/Trusted_execution_environment)
|
||||
* TEE - Trusted Execution Environment
|
||||
* TFTP - Network Protocol: Trivial File Transfer Protocol
|
||||
* TGL - Intel: Tigerlake
|
||||
* THC - Touch Host Controller
|
||||
@ -1023,17 +919,14 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* TLA - Three Letter Acronym
|
||||
* TLB - [**Translation Lookside
|
||||
Buffer**](https://en.wikipedia.org/wiki/Translation_lookaside_buffer)
|
||||
* TME - Intel: Total Memory Encryption
|
||||
* TOCTOU - Time-Of-Check to Time-Of-Use
|
||||
* TOLUM - Top of Low Usable Memory
|
||||
* ToM - Top of Memory
|
||||
* TPM - Trusted Platform Module
|
||||
* TS - TimeStamp
|
||||
* TSN - Time-Sensitive Networking
|
||||
* TS - TimeStamp -
|
||||
* TSC - [**Time Stamp
|
||||
Counter**](https://en.wikipedia.org/wiki/Time_Stamp_Counter)
|
||||
* TSEG - TOM (Top of Memory) Segment
|
||||
* TSR - Temperature Sensor
|
||||
* TWAIN - Technology without an interesting name.
|
||||
* TX - Transmit
|
||||
* TXE - Intel: Trusted eXecution Engine
|
||||
@ -1046,10 +939,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* uCode - [**Microcode**](https://en.wikipedia.org/wiki/Microcode)
|
||||
* UDK - UEFI: UEFI Development Kit
|
||||
* UDP - User Datagram Protocol
|
||||
* UDMA - ATA: [**Ultra DMA**](https://en.wikipedia.org/wiki/UDMA) - The fastest transfer mode for ATA Hard Drives
|
||||
* UEFI - Unified Extensible Firmware Interface
|
||||
* UFC - User Facing Camera
|
||||
* UFP - USB: Upstream Facing Port
|
||||
* UFS - Universal Flash storage
|
||||
* UHCI - USB: [**Universal Host Controller
|
||||
Interface**](https://en.wikipedia.org/wiki/Host_controller_interface_%28USB%2C_Firewire%29%23UHCI)
|
||||
@ -1064,7 +954,6 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* UPS - Uninterruptible Power Supply
|
||||
* USART - Universal Synchronous/Asynchronous Receiver/Transmitter
|
||||
* USB - Universal Serial Bus
|
||||
* USF - Intel: Universal Scalable Firmware
|
||||
|
||||
|
||||
## V
|
||||
@ -1072,8 +961,7 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* VBIOS - Video BIOS
|
||||
* VBNV - Vboot Non-Volatile storage
|
||||
* VBT - [**Video BIOS
|
||||
Table**](https://www.kernel.org/doc/html/latest/gpu/i915.html#video-bios-table-vbt)
|
||||
* VDDQ Memory/Power: The supply voltage to the output buffers of a memory chip.
|
||||
Table**](https://01.org/linuxgraphics/gfx-docs/drm/ch04s02.html#id-1.4.3.4.16)
|
||||
* VESA - Video Electronics Standards Association
|
||||
* VGA: Video Graphics Array
|
||||
* VID: Vendor Identifier
|
||||
@ -1081,17 +969,12 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
* VLB - VESA Local Bus
|
||||
* VOIP - Voice over IP
|
||||
* Voodoo mode - a silly name for Big Real mode.
|
||||
* VMX - Intel: CPU flag for Hardware Virtualization
|
||||
* VPD - Vital Product Data
|
||||
* VPN - Virtual Private Network
|
||||
* VPU - Intel: Versatile Processor Unit
|
||||
* VR - Voltage Regulator
|
||||
* VRAM - Video Random Access Memory
|
||||
* VREF Memory/Power: Reference voltage for the input lines of a chip that determines the voltage level at which the threshold between a logical 1 and a logical 0 occurs. Usually 1/2 VDDQ.
|
||||
* VRM - Voltage Regulator Module
|
||||
* VT-d - Intel: Virtualization Technology for Directed I/O
|
||||
* VTT Memory/Power: Tracking Termination Voltage
|
||||
* vUART - Virtual UART
|
||||
|
||||
|
||||
## W
|
||||
@ -1105,11 +988,8 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
devices that open 360 degrees, or on the outside of the cover. For
|
||||
tablets, it's on the the side away from the screen.
|
||||
* WDT - [**WatchDog Timer**](https://en.wikipedia.org/wiki/Watchdog_timer)
|
||||
* WFC - World Facing Camera
|
||||
* WLAN - Wireless LAN (Local Area Network)
|
||||
* WWAN - Telecommunication: Wireless WAN (Wide Area Network)
|
||||
* WP - Cache policy: [**Write-Protected**](https://en.wikipedia.org/wiki/Cache_%28computing%29)
|
||||
* WPT - Intel: Wildcat Point - PCH for Broadwell
|
||||
* WO - Write-only
|
||||
* WOL - [**Wake-on-LAN**](https://en.wikipedia.org/wiki/Wake-on-LAN)
|
||||
* WT - Cache Policy: [**Write Through**](https://en.wikipedia.org/wiki/Cache_%28computing%29)
|
||||
@ -1130,9 +1010,8 @@ Spec](https://uefi.org/specifications) for details, or run the tool
|
||||
supporting 1.x, 2.0, and 3.x devices.
|
||||
|
||||
|
||||
## Y
|
||||
|
||||
* YCC - Color Space: [**YCbCr**](https://en.wikipedia.org/wiki/YCbCr) - A family of color spaces used in video
|
||||
## Y
|
||||
|
||||
|
||||
## Z
|
||||
|
@ -95,17 +95,6 @@ If you feel you have been falsely or unfairly accused of violating this
|
||||
Code of Conduct, you should notify the arbitration team with a concise
|
||||
description of your grievance.
|
||||
|
||||
## Legal action
|
||||
|
||||
Threatening or starting legal action against the project, sibling
|
||||
projects hosted on coreboot.org infrastructure, project or infrastructure
|
||||
maintainers leads to an immediate ban from coreboot.org and related
|
||||
systems.
|
||||
|
||||
The ban can be reconsidered, but it's the default action because the
|
||||
people who pour lots of time and money into the projects aren't interested
|
||||
in seeing their resources used against them.
|
||||
|
||||
## Scope
|
||||
|
||||
We expect all community participants (contributors, paid or otherwise;
|
||||
|
@ -14,7 +14,7 @@ read its
|
||||
## Real time chat
|
||||
|
||||
We also have a real time chat room on [IRC](ircs://irc.libera.chat/#coreboot),
|
||||
also bridged to [Matrix](https://matrix.to/#/#coreboot:matrix.org) and a
|
||||
also bridged to [Matrix](https://matrix.to/#/#coreboot:libera.chat) and a
|
||||
[Discord](https://discord.gg/JqT8NM5Zbg) presence. You can also find us on
|
||||
[OSF Slack](https://osfw.slack.com/), which has channels on many open source
|
||||
firmware related topics. Slack requires that people come from specific domains
|
||||
@ -31,7 +31,7 @@ topics, including community and technical matters that benefit from
|
||||
an official decision.
|
||||
|
||||
We tried a whole lot of different tools, but so far the meetings worked
|
||||
best with [Google Meet](https://meet.google.com/pyt-newq-rbb),
|
||||
best with [Google Meet](https://meet.google.com/syn-toap-agu),
|
||||
using [Google Docs](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ/edit)
|
||||
for the agenda and meeting minutes. Neither the video conference nor
|
||||
the document require a Google account to participate, although editing
|
||||
|
@ -55,7 +55,7 @@ else:
|
||||
#
|
||||
# This is also used if you do content translation via gettext catalogs.
|
||||
# Usually you set "language" from the command line for these cases.
|
||||
language = 'en'
|
||||
language = None
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
@ -87,9 +87,11 @@ html_theme = 'sphinx_rtd_theme'
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static']
|
||||
|
||||
html_css_files = [
|
||||
'theme_overrides.css', # override wide tables in RTD theme
|
||||
]
|
||||
html_context = {
|
||||
'css_files': [
|
||||
'_static/theme_overrides.css', # override wide tables in RTD theme
|
||||
],
|
||||
}
|
||||
|
||||
# Output file base name for HTML help builder.
|
||||
htmlhelp_basename = 'corebootdoc'
|
||||
|
@ -66,7 +66,7 @@ case 'm':
|
||||
case 'K':
|
||||
case 'k':
|
||||
mem <<= 10;
|
||||
__fallthrough;
|
||||
/* fall through */
|
||||
default:
|
||||
break;
|
||||
}
|
||||
@ -818,9 +818,9 @@ Function return values and names
|
||||
|
||||
Functions can return values of many different kinds, and one of the most
|
||||
common is a value indicating whether the function succeeded or failed.
|
||||
Such a value can be represented as an error-code integer (`CB_ERR_xxx`
|
||||
(negative number) = failure, `CB_SUCCESS` (0) = success) or a "succeeded"
|
||||
boolean (0 = failure, non-zero = success).
|
||||
Such a value can be represented as an error-code integer (-Exxx =
|
||||
failure, 0 = success) or a "succeeded" boolean (0 = failure, non-zero
|
||||
= success).
|
||||
|
||||
Mixing up these two sorts of representations is a fertile source of
|
||||
difficult-to-find bugs. If the C language included a strong distinction
|
||||
@ -832,84 +832,21 @@ If the name of a function is an action or an imperative command,
|
||||
the function should return an error-code integer. If the name
|
||||
is a predicate, the function should return a "succeeded" boolean.
|
||||
|
||||
For example, "add work" is a command, and the `add_work()` function
|
||||
returns 0 for success or `CB_ERR` for failure. In the same way, "PCI
|
||||
device present" is a predicate, and the `pci_dev_present()` function
|
||||
For example, "add work" is a command, and the add_work() function
|
||||
returns 0 for success or -EBUSY for failure. In the same way, "PCI
|
||||
device present" is a predicate, and the pci_dev_present() function
|
||||
returns 1 if it succeeds in finding a matching device or 0 if it
|
||||
doesn't.
|
||||
|
||||
All EXPORTed functions must respect this convention, and so should all
|
||||
public functions. Private (static) functions need not, but it is
|
||||
recommended that they do.
|
||||
|
||||
Functions whose return value is the actual result of a computation,
|
||||
rather than an indication of whether the computation succeeded, are not
|
||||
subject to this rule. Generally they indicate failure by returning some
|
||||
out-of-range result. Typical examples would be functions that return
|
||||
pointers; they use NULL to report failure.
|
||||
|
||||
Error handling, assertions and die()
|
||||
-----------------------------
|
||||
|
||||
As firmware, coreboot has no means to let the user interactively fix things when
|
||||
something goes wrong. We either succeed to boot or the device becomes a brick
|
||||
that must be recovered through complicated external means (e.g. a flash
|
||||
programmer). Therefore, coreboot code should strive to continue booting
|
||||
wherever possible.
|
||||
|
||||
In most cases, errors should be handled by logging a message of at least
|
||||
`BIOS_ERR` level, returning out of the function stack for the failed feature,
|
||||
and then continuing execution. For example, if a function reading the EDID of an
|
||||
eDP display panel encounters an I2C error, it should print a "cannot read EDID"
|
||||
message and return an error code. The calling display initialization function
|
||||
knows that without the EDID there is no way to initialize the display correctly,
|
||||
so it will also immediately return with an error code without running its
|
||||
remaining code that would initialize the SoC's display controller. Exeuction
|
||||
returns further up the function stack to the mainboard initialization code
|
||||
which continues booting despite the failed display initialization, since
|
||||
display functionality is non-essential to the system. (Code is encouraged but
|
||||
not required to use `enum cb_err` error codes to return these errors.)
|
||||
|
||||
coreboot also has the `die()` function that completely halts execution. `die()`
|
||||
should only be used as a last resort, since it results in the worst user
|
||||
experience (bricked system). It is generally preferrable to continue executing
|
||||
even after a problem was encountered that might be fatal (e.g. SPI clock
|
||||
couldn't be configured correctly), because a slight chance of successfully
|
||||
booting is still better than not booting at all. The only cases where `die()`
|
||||
should be used are:
|
||||
|
||||
1. There is no (simple) way to continue executing. For example, when loading the
|
||||
next stage from SPI flash fails, we don't have any more code to execute. When
|
||||
memory initialization fails, we have no space to load the ramstage into.
|
||||
|
||||
2. Continuing execution would pose a security risk. All security features in
|
||||
coreboot are optional, but when they are configured in the user must be able
|
||||
to rely on them. For example, if CBFS verification is enabled and the file
|
||||
hash when loading the romstage doesn't match what it should be, it is better
|
||||
to stop execution than to jump to potentially malicious code.
|
||||
|
||||
In addition to normal error logging with `printk()`, coreboot also offers the
|
||||
`assert()` macro. `assert()` should be used judiciously to confirm that
|
||||
conditions are true which the programmer _knows_ to be true, in order to catch
|
||||
programming errors and incorrect assumptions. It is therefore different from a
|
||||
normal `if ()`-check that is used to actually test for things which may turn
|
||||
out to be true or false based on external conditions. For example, anything
|
||||
that involves communicating with hardware, such as whether an attempt to read
|
||||
from SPI flash succeeded, should _not_ use `assert()` and should instead just
|
||||
be checked with a normal `if ()` and subsequent manual error handling. Hardware
|
||||
can always fail for various reasons and the programmer can never 100% assume in
|
||||
advance that it will work as expected. On the other hand, if a function takes a
|
||||
pointer parameter `ctx` and the contract for that function (as documented in a
|
||||
comment above its declaration) specifies that this parameter should point to a
|
||||
valid context structure, then adding an `assert(ctx)` line to that function may
|
||||
be a good idea. The programmer knows that this function should never be called
|
||||
with a NULL pointer (because that's how it is specified), and if it was actually
|
||||
called with a NULL pointer that would indicate a programming error on account of
|
||||
the caller.
|
||||
|
||||
`assert()` can be configured to either just print an error message and continue
|
||||
execution (default), or call `die()` (when `CONFIG_FATAL_ASSERTS` is set).
|
||||
Developers are encouraged to always test their code with this option enabled to
|
||||
make assertion errors (and therefore bugs) more easy to notice. Since assertions
|
||||
thus do not always stop execution, they should never be relied upon to be the
|
||||
sole guard against conditions that really _need_ to stop execution (e.g.
|
||||
security guarantees should never be enforced only by `assert()`).
|
||||
pointers; they use NULL or the ERR_PTR mechanism to report failure.
|
||||
|
||||
Headers and includes
|
||||
---------------
|
||||
@ -1065,7 +1002,7 @@ The C Programming Language, Second Edition by Brian W. Kernighan and
|
||||
Dennis M. Ritchie. Prentice Hall, Inc., 1988. ISBN 0-13-110362-8
|
||||
(paperback), 0-13-110370-9 (hardback). URL:
|
||||
<https://duckduckgo.com/?q=isbn+0-13-110362-8> or
|
||||
<https://www.google.com/search?q=isbn+0-13-110362-8>
|
||||
<https://www.google.com/search?q=isbn+0-13-110362-8.
|
||||
|
||||
|
||||
The Practice of Programming by Brian W. Kernighan and Rob Pike.
|
||||
|
@ -41,7 +41,7 @@ project you're submitting the changes to. If you’re submitting code that
|
||||
you wrote that might be owned by your employer, make sure that your
|
||||
employer is aware and you are authorized to submit the code. For
|
||||
clarification, see the Developer's Certificate of Origin in the coreboot
|
||||
[Signed-off-by policy](#sign-off-procedure).
|
||||
[Signed-off-by policy](https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure).
|
||||
|
||||
* In general, patches should remain open for review for at least 24 hours
|
||||
since the last significant modification to the change. The purpose is to
|
||||
@ -127,54 +127,6 @@ those platforms. While it would be nice to update any other platforms, you
|
||||
must at least provide a path that will allow other platforms to continue
|
||||
working.
|
||||
|
||||
Sign-off Procedure
|
||||
------------------
|
||||
The coreboot project employs a sign-off procedure similar to what is
|
||||
used by the Linux kernel. Each gerrit commit requires a sign-off line
|
||||
saying that the contributed code abides by the Developer's certificate
|
||||
of origin, below.
|
||||
```text
|
||||
Signed-off-by: Random J Developer <random@developer.example.org>
|
||||
```
|
||||
|
||||
Using '-s' with 'git commit' will automatically add a Signed-off-by line
|
||||
to your commit message. Patches without a Signed-off-by should not be
|
||||
pushed to gerrit, and will be rejected by coreboot's CI system.
|
||||
|
||||
You must use a known identity in the Signed-off-by line. Anonymous
|
||||
contributions cannot be committed! This can be anything sufficient to
|
||||
identify and contact the source of a contribution, such as your name or
|
||||
an established alias/nickname. Refer to [this LKML thread] and the
|
||||
[SCO-Linux disputes] for the rationale behind the DCO.
|
||||
|
||||
Developer's Certificate of Origin 1.1
|
||||
|
||||
> By making a contribution to this project, I certify that:
|
||||
>
|
||||
> (a) The contribution was created in whole or in part by me and I have
|
||||
> the right to submit it under the open source license indicated in the
|
||||
> file; or
|
||||
>
|
||||
> (b) The contribution is based upon previous work that, to the best of
|
||||
> my knowledge, is covered under an appropriate open source license and
|
||||
> I have the right under that license to submit that work with
|
||||
> modifications, whether created in whole or in part by me, under the
|
||||
> same open source license (unless I am permitted to submit under a
|
||||
> different license), as indicated in the file; or
|
||||
>
|
||||
> (c) The contribution was provided directly to me by some other person
|
||||
> who certified (a), (b) or (c) and I have not modified it; and
|
||||
>
|
||||
> (d) In the case of each of (a), (b), or (c), I understand and agree
|
||||
> that this project and the contribution are public and that a record of
|
||||
> the contribution (including all personal information I submit with it,
|
||||
> including my sign-off) is maintained indefinitely and may be
|
||||
> redistributed consistent with this project or the open source license
|
||||
> indicated in the file.
|
||||
|
||||
Note: The [Developer's Certificate of Origin 1.1] is licensed under the
|
||||
terms of the [Creative Commons Attribution-ShareAlike 2.5 License].
|
||||
|
||||
|
||||
Recommendations for gerrit activity
|
||||
-----------------------------------
|
||||
@ -221,10 +173,7 @@ This helps verify that the patch train won’t tie up the jenkins builders
|
||||
for no reason if there are failing patches in the train. For running
|
||||
parallel builds, you can specify the number of cores to use by setting the
|
||||
the CPUS environment variable. Example:
|
||||
|
||||
```Bash
|
||||
make what-jenkins-does CPUS=8
|
||||
```
|
||||
|
||||
* Use a topic when pushing a train of patches. This groups the commits
|
||||
together so people can easily see the connection at the top level of
|
||||
@ -232,10 +181,7 @@ gerrit. Topics can be set for individual patches in gerrit by going into
|
||||
the patch and clicking on the icon next to the topic line. Topics can also
|
||||
be set when you push the patches into gerrit. For example, to push a set of
|
||||
commits with the i915-kernel-x60 set, use the command:
|
||||
|
||||
```Bash
|
||||
git push origin HEAD:refs/for/master%topic=i915-kernel-x60
|
||||
```
|
||||
|
||||
* If one of your patches isn't ready to be merged, make sure it's obvious
|
||||
that you don't feel it's ready for merge yet. The preferred way to show
|
||||
@ -245,10 +191,7 @@ Examples of this are "WIP: title" or "[NEEDS_TEST]: title". Another way to
|
||||
mark the patch as not ready would be to give it a -1 or -2 review, but
|
||||
isn't as obvious as the commit message. These patches can also be pushed with
|
||||
the wip flag:
|
||||
|
||||
```Bash
|
||||
git push origin HEAD:refs/for/master%wip
|
||||
```
|
||||
|
||||
* When pushing patches that are not for submission, these should be marked
|
||||
as such. This can be done in the title ‘[DONOTSUBMIT]’, or can be pushed as
|
||||
@ -257,16 +200,10 @@ sorts of patches are frequently posted as ideas or RFCs for the community to
|
||||
look at. Note that private changes can still be fetched from Gerrit by anybody
|
||||
who knows their commit ID, so don't use this for sensitive changes. To push
|
||||
a private change, use the command:
|
||||
|
||||
```Bash
|
||||
git push origin HEAD:refs/for/master%private
|
||||
```
|
||||
|
||||
* Multiple push options can be combined:
|
||||
|
||||
```Bash
|
||||
git push origin HEAD:refs/for/master%private,wip,topic=experiment
|
||||
```
|
||||
|
||||
* Respond to anyone who has taken the time to review your patches, even if
|
||||
it's just to say that you disagree. While it may seem annoying to address a
|
||||
@ -340,15 +277,13 @@ git/gerrit tags by prepending the lines with 'Original-'. Marking
|
||||
the original text this way makes it much easier to tell what changes
|
||||
happened in which repository. This applies to these lines, not the actual
|
||||
commit message itself:
|
||||
|
||||
* Commit-Id:
|
||||
* Change-Id:
|
||||
* Signed-off-by:
|
||||
* Reviewed-on:
|
||||
* Tested-by:
|
||||
* Reviewed-by:
|
||||
|
||||
The script `util/gitconfig/rebase.sh` can be used to help automate this.
|
||||
Commit-Id:
|
||||
Change-Id:
|
||||
Signed-off-by:
|
||||
Reviewed-on:
|
||||
Tested-by:
|
||||
Reviewed-by:
|
||||
The script 'util/gitconfig/rebase.sh' can be used to help automate this.
|
||||
Other tags such as 'Commit-Queue' can simply be removed.
|
||||
|
||||
* Check if there's documentation that needs to be updated to remain current
|
||||
@ -434,7 +369,3 @@ Requests for clarification and suggestions for updates to these guidelines
|
||||
should be sent to the coreboot mailing list at <coreboot@coreboot.org>.
|
||||
|
||||
[ready changes]: https://review.coreboot.org/q/age:1d+project:coreboot+status:open+is:mergeable+label:All-Comments-Resolved%253Dok+label:Code-Review%253D2+-label:Code-Review%253C0+label:Verified%253D1+-label:Verified-1
|
||||
[Developer's Certificate of Origin 1.1]: https://developercertificate.org/
|
||||
[Creative Commons Attribution-ShareAlike 2.5 License]: https://creativecommons.org/licenses/by-sa/2.5/
|
||||
[this LKML thread]: https://lkml.org/lkml/2004/5/23/10
|
||||
[SCO-Linux disputes]: https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes
|
||||
|
@ -1,16 +1,5 @@
|
||||
# Google Summer of Code
|
||||
|
||||
## Organization admins
|
||||
|
||||
The *organization admins* are managing the GSoC program for the coreboot
|
||||
organization.
|
||||
|
||||
The organization admins are:
|
||||
|
||||
* Felix Singer (primary)
|
||||
* Martin Roth
|
||||
* David Hendricks
|
||||
|
||||
|
||||
## Contacts
|
||||
|
||||
@ -19,6 +8,9 @@ please have a look at our [community forums] and reach out to us. Working closel
|
||||
with the community is highly encouraged, as we've seen that our most successful
|
||||
contributors are generally very involved.
|
||||
|
||||
Felix Singer, David Hendricks and Martin Roth are the coreboot GSoC admins for
|
||||
2022. Please feel free to reach out to them directly if you have any questions.
|
||||
|
||||
|
||||
## Why work on coreboot for GSoC?
|
||||
|
||||
@ -59,8 +51,6 @@ contributors are generally very involved.
|
||||
|
||||
* [Glossary][GSoC Glossary]
|
||||
|
||||
* [Organization Admin Tips][GSoC Organization Admin Tips]
|
||||
|
||||
|
||||
## Contributor requirements & commitments
|
||||
|
||||
@ -101,7 +91,7 @@ amount of spare time. If this is not the case, then you should not apply.
|
||||
process and common issues.
|
||||
|
||||
* Get signed up for Gerrit and push at least one patch to Gerrit for review.
|
||||
Check the [small project list][Project ideas] or ask for simple tasks on
|
||||
Check the [easy project list][Project ideas] or ask for simple tasks on
|
||||
the [mailing list] or on our other [community forums] if you need ideas.
|
||||
|
||||
|
||||
@ -283,4 +273,3 @@ questions.
|
||||
[GSoC FAQ]: https://developers.google.com/open-source/gsoc/faq
|
||||
[GSoC Rules]: https://summerofcode.withgoogle.com/rules
|
||||
[GSoC Glossary]: https://developers.google.com/open-source/gsoc/resources/glossary
|
||||
[GSoC Organization Admin Tips]: https://developers.google.com/open-source/gsoc/help/oa-tips
|
||||
|
@ -20,12 +20,12 @@ doubt if you can bring yourself up to speed in a required time frame
|
||||
with the projects. We can then try together to figure out if you're a
|
||||
good match for a project, even when requirements might not all be met.
|
||||
|
||||
## Small projects
|
||||
## Easy projects
|
||||
|
||||
This is a collection of tasks which don't require deep knowledge on
|
||||
coreboot itself. If you are a beginner and want to get familiar with the
|
||||
the project and the code base, or if you just want to get your hands
|
||||
dirty with some small tasks, then these are for you.
|
||||
dirty with some easy tasks, then these are for you.
|
||||
|
||||
* Resolve static analysis issues reported by [scan-build] and
|
||||
[Coverity scan]. More details on the page for
|
||||
@ -36,7 +36,7 @@ dirty with some small tasks, then these are for you.
|
||||
[scan-build]: https://coreboot.org/scan-build/
|
||||
[Coverity scan]: https://scan.coverity.com/projects/coreboot
|
||||
[Coverity scan integration]: ../infrastructure/coverity.md
|
||||
[Linter issues]: https://qa.coreboot.org/job/coreboot-untested-files/lastSuccessfulBuild/artifact/lint.txt
|
||||
[Linter issues]: https://qa.coreboot.org/job/untested-coreboot-files/lastSuccessfulBuild/artifact/lint.txt
|
||||
|
||||
## Provide toolchain binaries
|
||||
Our crossgcc subproject provides a uniform compiler environment for
|
||||
@ -63,6 +63,7 @@ non-Linux builds or Docker for different Linux distributions.
|
||||
* hardware requirements: Nothing special
|
||||
|
||||
### Mentors
|
||||
* Patrick Georgi <patrick@georgi.software>
|
||||
|
||||
## Support Power9/Power8 in coreboot
|
||||
There are some basic PPC64 stubs in coreboot, and there's open hardware
|
||||
@ -86,8 +87,8 @@ across architectures.
|
||||
## Port payloads to ARM, AArch64 or RISC-V
|
||||
While we have a rather big set of payloads for x86 based platforms, all other
|
||||
architectures are rather limited. Improve the situation by porting a payload
|
||||
to one of the platforms, for example GRUB2, U-Boot (the UI part), edk2,
|
||||
FILO, or Linux-as-Payload.
|
||||
to one of the platforms, for example GRUB2, U-Boot (the UI part), Tianocore,
|
||||
yabits, FILO, or Linux-as-Payload.
|
||||
|
||||
Since this is a bit of a catch-all idea, an application to GSoC should pick a
|
||||
combination of payload and architecture to support.
|
||||
@ -129,6 +130,7 @@ their bug reports.
|
||||
going on from the resulting logs.
|
||||
|
||||
### Mentors
|
||||
* Patrick Georgi <patrick@georgi.software>
|
||||
|
||||
## Extend Ghidra to support analysis of firmware images
|
||||
[Ghidra](https://ghidra-sre.org) is a recently released cross-platform
|
||||
|
Before Width: | Height: | Size: 195 KiB |
@ -37,15 +37,15 @@ firmware binaries on [GitHub](https://pcengines.github.io).
|
||||
|
||||
[Star Labs](https://starlabs.systems/) offers a range of laptops designed and
|
||||
built specifically for Linux that are available with coreboot firmware. They
|
||||
use edk2 as the payload and include an NVRAM option to disable the Intel
|
||||
Management Engine.
|
||||
use Tianocore as the payload and include an NVRAM option to disable the
|
||||
Intel Management Engine.
|
||||
|
||||
### System76
|
||||
|
||||
[System76](https://system76.com/) manufactures Linux laptops, desktops, and
|
||||
servers. Some models are sold with [System76 Open
|
||||
Firmware](https://github.com/system76/firmware-open), an open source
|
||||
distribution of coreboot, edk2, and System76 firmware applications.
|
||||
distribution of coreboot, EDK2, and System76 firmware applications.
|
||||
|
||||
### Purism
|
||||
|
||||
@ -71,14 +71,12 @@ focusing on clean and simple code, long-term maintenance, transparent
|
||||
validation, privacy-respecting implementation, liberty for the owners, and
|
||||
trustworthiness for all.
|
||||
|
||||
Contributions are welcome,
|
||||
[this document](https://docs.dasharo.com/ways-you-can-help-us/).
|
||||
|
||||
### MrChromebox
|
||||
|
||||
[MrChromebox](https://mrchromebox.tech/) provides upstream coreboot firmware
|
||||
images for the vast majority of x86-based Chromebooks and Chromeboxes, using
|
||||
edk2 as the payload to provide a modern UEFI bootloader. Why replace
|
||||
Tianocore as the payload to provide a modern UEFI bootloader. Why replace
|
||||
coreboot with coreboot? Mr Chromebox's images are built using upstream
|
||||
coreboot (vs Google's older, static tree/branch), include many features and
|
||||
fixes not found in the stock firmware, and offer much broader OS compatibility
|
||||
|
@ -1,143 +0,0 @@
|
||||
# CBFS SMBIOS hooks
|
||||
|
||||
The document describes the coreboot options how to make CBFS files populate
|
||||
platform-unique SMBIOS data.
|
||||
|
||||
## SMBIOS Serial Number
|
||||
|
||||
The [DMTF SMBIOS specification] defines a field in the type 1 System
|
||||
Information and type 2 Baseboard Information called Serial Number. It
|
||||
is a null-terminated string field assumed to be unique per platform. Certain
|
||||
mainboard ports have SMBIOS hooks to generate the Serial Numbers from external
|
||||
data, e.g. Lenovo Thinkpads (see DRIVER_LENOVO_SERIALS). This driver aims to
|
||||
provide an option to populate the Serial Numbers from CBFS for boards that
|
||||
can't generate the it from any source.
|
||||
|
||||
### Usage
|
||||
|
||||
In the coreboot configuration menu (`make menuconfig`) go to `Generic Drivers`
|
||||
and select an option `Serial number in CBFS`. The Kconfig system will enable
|
||||
`DRIVERS_GENERIC_CBFS_SERIAL` and the relevant code parts will be compiled into
|
||||
coreboot image.
|
||||
|
||||
After the coreboot build for your board completes, use the cbfstool to include
|
||||
the file containing the serial number:
|
||||
|
||||
```shell
|
||||
./build/cbfstool build/coreboot.rom add -n serial_number -t raw -f /path/to/serial_file.txt
|
||||
```
|
||||
|
||||
Where `serial_file.txt` is the unterminated string representation of the SMBIOS
|
||||
type 1 or type 2 Serial Number, e.g. `5Q4Q7Y1`. If you use vboot with 1 or 2 RW
|
||||
partitions you will have to specify the RW regions where the file is going to
|
||||
be added too. By default the RW CBFS partitions are truncated, so the files
|
||||
would probably not fit, one needs to expand them first.
|
||||
|
||||
```shell
|
||||
./build/cbfstool build/coreboot.rom expand -r FW_MAIN_A
|
||||
./build/cbfstool build/coreboot.rom add -n serial_number -t raw \
|
||||
-f /path/to/serial_file.txt -r FW_MAIN_A
|
||||
./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_A
|
||||
|
||||
./build/cbfstool build/coreboot.rom expand -r FW_MAIN_B
|
||||
./build/cbfstool build/coreboot.rom add -n serial_number -t raw \
|
||||
-f /path/to/serial_file.txt -r FW_MAIN_B
|
||||
./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_B
|
||||
```
|
||||
|
||||
By default cbfstool adds files to COREBOOT region only, so when vboot is
|
||||
enabled and the platform is booting from RW partition, the file would not be
|
||||
picked up by the driver.
|
||||
|
||||
One may retrieve the Serial Number from running system (if it exists) using one
|
||||
of the following commands:
|
||||
|
||||
```shell
|
||||
# Type 1
|
||||
echo -n `sudo dmidecode -s system-serial-number` > serial_file.txt
|
||||
# OR Type 2
|
||||
echo -n `sudo dmidecode -s baseboard-serial-number` > serial_file.txt
|
||||
```
|
||||
|
||||
Ensure the file does not end with whitespaces like LF and/or CR. The above
|
||||
commands will not add any whitespaces. The driver automatically terminates the
|
||||
Serial Number with the NULL character. If the CBFS file is not present, the
|
||||
driver will fall back to the string defined in `MAINBOARD_SERIAL_NUMBER` build
|
||||
option.
|
||||
|
||||
Please note that this driver provides `smbios_mainboard_serial_number` hook
|
||||
overriding the default implementation which returns `MAINBOARD_SERIAL_NUMBER`
|
||||
build option. If you wish to populate only type 2 Serial Number field your
|
||||
board code needs to implement `smbios_system_serial_number`, otherwise the weak
|
||||
implementation of `smbios_system_serial_number` will call
|
||||
`smbios_mainboard_serial_number` from the `DRIVERS_GENERIC_CBFS_SERIAL`
|
||||
implementation overriding it. So selecting the `DRIVERS_GENERIC_CBFS_SERIAL`
|
||||
has a side-effect of populating both SMBIOS type 1 and type 2 Serial Numbers
|
||||
if the board does not implement its own `smbios_system_serial_number`.
|
||||
|
||||
There is also SMBIOS type 3 Chassis Information Serial Number, but it is not
|
||||
populated by `DRIVERS_GENERIC_CBFS_SERIAL` nor by the default weak
|
||||
implementation (returns empty string). If you wish to populate type 3 Serial
|
||||
Number, your board code should override the default
|
||||
`smbios_chassis_serial_number` weak implementation.
|
||||
|
||||
## SMBIOS System UUID
|
||||
|
||||
The [DMTF SMBIOS specification] defines a field in the type 1 System
|
||||
Information Structure called System UUID. It is a 16 bytes value compliant with
|
||||
[RFC4122] and assumed to be unique per platform. Certain mainboard ports have
|
||||
SMBIOS hooks to generate the UUID from external data, e.g. Lenovo Thinkpads
|
||||
(see DRIVER_LENOVO_SERIALS). This driver aims to provide an option to populate
|
||||
the UUID from CBFS for boards that can't generate the UUID from any source.
|
||||
|
||||
### Usage
|
||||
|
||||
In the coreboot configuration menu (`make menuconfig`) go to `Generic Drivers`
|
||||
and select an option `System UUID in CBFS`. The Kconfig system will enable
|
||||
`DRIVERS_GENERIC_CBFS_UUID` and the relevant code parts will be compiled into
|
||||
coreboot image.
|
||||
|
||||
After the coreboot build for your board completes, use the cbfstool to include
|
||||
the file containing the UUID:
|
||||
|
||||
```shell
|
||||
./build/cbfstool build/coreboot.rom add -n system_uuid -t raw -f /path/to/uuid_file.txt
|
||||
```
|
||||
|
||||
Where `uuid_file.txt` is the unterminated string representation of the SMBIOS
|
||||
type 1 UUID, e.g. `4c4c4544-0051-3410-8051-b5c04f375931`. If you use vboot with
|
||||
1 or 2 RW partitions you will have to specify the RW regions where the file is
|
||||
going to be added too. By default the RW CBFS partitions are truncated, so the
|
||||
files would probably not fit, one needs to expand them first.
|
||||
|
||||
```shell
|
||||
./build/cbfstool build/coreboot.rom expand -r FW_MAIN_A
|
||||
./build/cbfstool build/coreboot.rom add -n system_uuid -t raw \
|
||||
-f /path/to/uuid_file.txt -r FW_MAIN_A
|
||||
./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_A
|
||||
|
||||
./build/cbfstool build/coreboot.rom expand -r FW_MAIN_B
|
||||
./build/cbfstool build/coreboot.rom add -n system_uuid -t raw \
|
||||
-f /path/to/uuid_file.txt -r FW_MAIN_B
|
||||
./build/cbfstool build/coreboot.rom truncate -r FW_MAIN_B
|
||||
```
|
||||
|
||||
By default cbfstool adds files to COREBOOT region only, so when vboot is
|
||||
enabled and the platform is booting from RW partition, the file would not be
|
||||
picked up by the driver.
|
||||
|
||||
One may retrieve the UUID from running system (if it exists) using the
|
||||
following command:
|
||||
|
||||
```shell
|
||||
echo -n `sudo dmidecode -s system-uuid` > uuid_file.txt
|
||||
```
|
||||
|
||||
The above command ensures the file does not end with whitespaces like LF and/or
|
||||
CR. The above command will not add any whitespaces. But the driver will handle
|
||||
situations where up to 2 additional bytes like CR and LF will be included in
|
||||
the file. Any more than that will make the driver fail to populate UUID in
|
||||
SMBIOS.
|
||||
|
||||
[DMTF SMBIOS specification]: https://www.dmtf.org/standards/smbios
|
||||
[RFC4122]: https://www.ietf.org/rfc/rfc4122.txt
|
@ -43,7 +43,7 @@ This policy monitors the temperature of participants and controls fans to spin
|
||||
at varying speeds. These speeds are defined by the platform, and will be enabled
|
||||
depending on the various temperatures reported by participants.
|
||||
|
||||
## Note about units
|
||||
# Note about units
|
||||
|
||||
ACPI uses unusual units for specifying various physical measurements. For
|
||||
example, temperatures are specified in 10ths of a degree K, and time is measured
|
||||
@ -69,7 +69,7 @@ data was a 0). The following Methods were removed:
|
||||
2) There is no more implicit inclusion of _ACn methods for TCPU (these must be
|
||||
specified in the devicetree entries or by calling the DPTF acpigen API).
|
||||
|
||||
## ACPI Tables
|
||||
# ACPI Tables
|
||||
|
||||
DPTF relies on an assortment of ACPI tables to provide parameters to the DPTF
|
||||
application. We will discuss the more important ones here.
|
||||
@ -108,7 +108,7 @@ various informational properties.
|
||||
This table describes performance states supported by a participant (typically
|
||||
the battery charger).
|
||||
|
||||
## ACPI Methods
|
||||
# ACPI Methods
|
||||
|
||||
The Active and Passive policies also provide for short Methods to define
|
||||
different kinds of temperature thresholds.
|
||||
@ -141,7 +141,7 @@ a "graceful shutdown".
|
||||
|
||||
These are optional, and are enabled by selecting the Critical Policy.
|
||||
|
||||
## How to use the devicetree entries
|
||||
# How to use the devicetree entries
|
||||
|
||||
The `drivers/intel/dptf` chip driver is organized into several sections:
|
||||
- Policies
|
||||
@ -151,7 +151,7 @@ The `drivers/intel/dptf` chip driver is organized into several sections:
|
||||
The Policies section (`policies.active`, `policies.passive`, and
|
||||
`policies.critical`) is where the components of each policy are defined.
|
||||
|
||||
### Active Policy
|
||||
## Active Policy
|
||||
|
||||
Each Active Policy is defined in terms of 4 parts:
|
||||
1) A Source (this is implicitly defined as TFN1, the system fan)
|
||||
@ -182,7 +182,7 @@ the CPU's active cooling capability). When the CPU temperature first crosses
|
||||
rest of the table (note that it *must* be defined from highest temperature/
|
||||
percentage on down to the lowest).
|
||||
|
||||
### Passive Policy
|
||||
## Passive Policy
|
||||
|
||||
Each Passive Policy is defined in terms of 5 parts:
|
||||
1) Source - The device that can be throttled
|
||||
@ -201,7 +201,7 @@ This example sets up a policy to begin throttling the charger performance when
|
||||
temperature sensor 1 reaches 65C. The sampling period here is 60000 ms (60 s).
|
||||
The Priority is defaulted to 100 in this case.
|
||||
|
||||
### Critical Policy
|
||||
## Critical Policy
|
||||
|
||||
Each Critical Policy is defined in terms of 3 parts:
|
||||
1) Source - A device that can trigger a critical event
|
||||
@ -218,7 +218,7 @@ register "policies.critical[1]" = "DPTF_CRITICAL(CPU, 75, SHUTDOWN)"
|
||||
This example sets up a policy wherein ACPI will cause the system to shutdown
|
||||
(in a "graceful" manner) when the CPU temperature reaches 75C.
|
||||
|
||||
### Power Limits
|
||||
## Power Limits
|
||||
|
||||
Control over the SoC's Running Average Power Limits (RAPL) is one of the tools
|
||||
that DPTF uses to enact Passive policies. DPTF can control both PL1 and PL2, if
|
||||
@ -244,7 +244,7 @@ This example allow DPTF to control the SoC's PL1 level to between 3W and 15W,
|
||||
over a time interval ranging from 28 to 32 seconds, and it can move PL1 in
|
||||
increments of 200 mW.
|
||||
|
||||
### Charger Performance
|
||||
## Charger Performance
|
||||
|
||||
The battery charger can be a large contributor of unwanted heat in a system that
|
||||
has one. Controlling the rate of charging is another tool that DPTF uses to enact
|
||||
@ -266,7 +266,7 @@ register "controls.charger_perf[3]" = "{ 8, 500 }"
|
||||
In this example, when DPTF decides to throttle the charger, it has four different
|
||||
performance states to choose from.
|
||||
|
||||
### Fan Performance
|
||||
## Fan Performance
|
||||
|
||||
When using DPTF, the system fan (`TFN1`) is the device responsible for actively
|
||||
cooling the other temperature sensors on the mainboard. A fan speed table can be
|
||||
@ -298,21 +298,21 @@ increment of 10 percentage points. This is common when specifying fine-grained
|
||||
control of the fan, wherein DPTF will interpolate between the percentages in the
|
||||
table for a given temperature threshold.
|
||||
|
||||
### Options
|
||||
## Options
|
||||
|
||||
#### Fan
|
||||
### Fan
|
||||
1) Fine-grained control - a boolean (see Fan Performance section above)
|
||||
2) Step-size - Recommended minimum step size (in percentage points) to adjust
|
||||
the fan speed when using fine-grained control (ranges from 1 - 9).
|
||||
3) Low-speed notify - If true, the platform will issue a `Notify (0x80)` to the
|
||||
fan device if a low fan speed is detected.
|
||||
|
||||
#### Temperature sensors
|
||||
### Temperature sensors
|
||||
1) Hysteresis - The amount of hysteresis implemented in either circuitry or
|
||||
the firmware that reads the temperature sensor (in degrees C).
|
||||
2) Name - This name is applied to the _STR property of the sensor
|
||||
|
||||
### OEM Variables
|
||||
## OEM Variables
|
||||
Platform vendors can define an array of OEM-specific values as OEM variables
|
||||
to be used under DPTF policy. There are total six OEM variables available.
|
||||
These can be used in AP policy for more specific actions. These OEM variables
|
||||
|
@ -1,309 +0,0 @@
|
||||
# Driver Devicetree Entries
|
||||
|
||||
Let's take a look at an example entry from
|
||||
``src/mainboard/google/hatch/variants/hatch/overridetree.cb``:
|
||||
|
||||
```
|
||||
device pci 15.0 on
|
||||
chip drivers/i2c/generic
|
||||
register "hid" = ""ELAN0000""
|
||||
register "desc" = ""ELAN Touchpad""
|
||||
register "irq" = "ACPI_IRQ_LEVEL_LOW(GPP_A21_IRQ)"
|
||||
register "detect" = "1"
|
||||
register "wake" = "GPE0_DW0_21"
|
||||
device i2c 15 on end
|
||||
end
|
||||
end # I2C #0
|
||||
```
|
||||
|
||||
When this entry is processed during ramstage, it will create a device in the
|
||||
ACPI SSDT table (all devices in devicetrees end up in the SSDT table). The ACPI
|
||||
generation routines in coreboot actually generate the raw bytecode that
|
||||
represents the device's structure, but looking at ASL code is easier to
|
||||
understand; see below for what the disassembled bytecode looks like:
|
||||
|
||||
```
|
||||
Scope (\_SB.PCI0.I2C0)
|
||||
{
|
||||
Device (D015)
|
||||
{
|
||||
Name (_HID, "ELAN0000") // _HID: Hardware ID
|
||||
Name (_UID, Zero) // _UID: Unique ID
|
||||
Name (_DDN, "ELAN Touchpad") // _DDN: DOS Device Name
|
||||
Method (_STA, 0, NotSerialized) // _STA: Status
|
||||
{
|
||||
Return (0x0F)
|
||||
}
|
||||
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
|
||||
{
|
||||
I2cSerialBusV2 (0x0015, ControllerInitiated, 400000,
|
||||
AddressingMode7Bit, "\\_SB.PCI0.I2C0",
|
||||
0x00, ResourceConsumer, , Exclusive, )
|
||||
Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
|
||||
{
|
||||
0x0000002D,
|
||||
}
|
||||
})
|
||||
Name (_S0W, ACPI_DEVICE_SLEEP_D3_HOT) // _S0W: S0 Device Wake State
|
||||
Name (_PRW, Package (0x02) // _PRW: Power Resources for Wake
|
||||
{
|
||||
0x15, // GPE #21
|
||||
0x03 // Sleep state S3
|
||||
})
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
You can see it generates \_HID, \_UID, \_DDN, \_STA, \_CRS, \_S0W, and \_PRW
|
||||
names/methods in the Device's scope.
|
||||
|
||||
## Utilizing a device driver
|
||||
|
||||
The device driver must be enabled for your build. There will be a CONFIG option
|
||||
in the Kconfig file in the directory that the driver is in (e.g.,
|
||||
``src/drivers/i2c/generic`` contains a Kconfig file; the option here is named
|
||||
CONFIG_DRIVERS_I2C_GENERIC). The config option will need to be added to your
|
||||
mainboard's Kconfig file (e.g., ``src/mainboard/google/hatch/Kconfig``) in order
|
||||
to be compiled into your build.
|
||||
|
||||
## Diving into the above example:
|
||||
|
||||
Let's take a look at how the devicetree language corresponds to the generated
|
||||
ASL.
|
||||
|
||||
First, note this:
|
||||
|
||||
```
|
||||
chip drivers/i2c/generic
|
||||
```
|
||||
|
||||
This means that the device driver we're using has a corresponding structure,
|
||||
located at ``src/drivers/i2c/generic/chip.h``, named **struct
|
||||
drivers_i2c_generic_config** and it contains many properties you can specify to
|
||||
be included in the ACPI table.
|
||||
|
||||
### hid
|
||||
|
||||
```
|
||||
register "hid" = ""ELAN0000""
|
||||
```
|
||||
|
||||
This corresponds to **const char \*hid** in the struct. In the ACPI ASL, it
|
||||
translates to:
|
||||
|
||||
```
|
||||
Name (_HID, "ELAN0000") // _HID: Hardware ID
|
||||
```
|
||||
|
||||
under the device. **This property is used to match the device to its driver
|
||||
during enumeration in the OS.**
|
||||
|
||||
### desc
|
||||
|
||||
```
|
||||
register "desc" = ""ELAN Touchpad""
|
||||
```
|
||||
|
||||
corresponds to **const char \*desc** and in ASL:
|
||||
|
||||
```
|
||||
Name (_DDN, "ELAN Touchpad") // _DDN: DOS Device Name
|
||||
```
|
||||
|
||||
### irq
|
||||
|
||||
It also adds the interrupt,
|
||||
|
||||
```
|
||||
Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
|
||||
{
|
||||
0x0000002D,
|
||||
}
|
||||
```
|
||||
|
||||
which comes from:
|
||||
|
||||
```
|
||||
register "irq" = "ACPI_IRQ_LEVEL_LOW(GPP_A21_IRQ)"
|
||||
```
|
||||
|
||||
The IRQ settings control the "Trigger" and "Polarity" settings seen above (level
|
||||
means it is a level-triggered interrupt as opposed to
|
||||
edge-triggered; active low means the interrupt is triggered when the signal is
|
||||
low).
|
||||
|
||||
Also note that the IRQ names are SoC-specific, and you will need to
|
||||
find the names in your SoC's header file. The ACPI_* macros are defined in
|
||||
``src/arch/x86/include/acpi/acpi_device.h``.
|
||||
|
||||
Using a GPIO as an IRQ requires that it is configured in coreboot correctly.
|
||||
This is often done in a mainboard-specific file named ``gpio.c``.
|
||||
|
||||
AMD platforms don't have the ability to route GPIOs to the IO-APIC. Instead the
|
||||
GPIO controller needs to be used directly. You can do this by setting the
|
||||
`irq_gpio` register and using the `ACPI_GPIO_IRQ_X_X` macros.
|
||||
|
||||
i.e.,
|
||||
```
|
||||
register "irq_gpio" = "ACPI_GPIO_IRQ_EDGE_LOW(GPIO_40)"
|
||||
```
|
||||
|
||||
### detect
|
||||
|
||||
The next register is:
|
||||
|
||||
```
|
||||
register "detect" = "1"
|
||||
```
|
||||
|
||||
This flag tells the I2C driver that it should attempt to detect the presence of
|
||||
the device (using an I2C zero-byte write), and only generate a SSDT entry if the
|
||||
device is actually present. This alleviates the OS from having to determine if
|
||||
a device is present or not (ChromeOS/Linux) and prevents resource conflict/
|
||||
driver issues (Windows).
|
||||
|
||||
Currently, the detect feature works and is hooked up for all I2C touchpads,
|
||||
and should be used any time a board has multiple touchpad options.
|
||||
I2C audio devices should also work without issue.
|
||||
|
||||
Touchscreens can use this feature as well, but special care is needed to
|
||||
implement the proper power sequencing for the device to be detected. Generally,
|
||||
this means driving the enable GPIO high and holding the reset GPIO low in early
|
||||
GPIO init (bootblock/romstage), then releasing reset in ramstage. The first
|
||||
mainboards in the tree to implement this are google/skyrim and google/guybrush.
|
||||
This feature has also been used in downstream forks without issue for some time
|
||||
now on several other boards.
|
||||
|
||||
### wake
|
||||
|
||||
The last register is:
|
||||
|
||||
```
|
||||
register "wake" = "GPE0_DW0_21"
|
||||
```
|
||||
|
||||
which indicates that the method of waking the system using the touchpad will be
|
||||
through a GPE, #21 associated with DW0, which is set up in devicetree.cb from
|
||||
this example. The "21" indicates GPP_X21, where GPP_X is mapped onto DW0
|
||||
elsewhere in the devicetree.
|
||||
|
||||
### device
|
||||
|
||||
The last bit of the definition of that device includes:
|
||||
|
||||
```
|
||||
device i2c 15 on end
|
||||
```
|
||||
|
||||
which means it's an I2C device, with 7-bit address 0x15, and the device is "on",
|
||||
meaning it will be exposed in the ACPI table. The PCI device that the
|
||||
controller is located in determines which I2C bus the device is expected to be
|
||||
found on. In this example, this is I2C bus 0. This also determines the ACPI
|
||||
"Scope" that the device names and methods will live under, in this case
|
||||
"\_SB.PCI0.I2C0".
|
||||
|
||||
## Wake sources
|
||||
|
||||
The ACPI spec defines two methods to describe how a device can wake the system.
|
||||
Only one of these methods should be used, otherwise duplicate wake events will
|
||||
be generated.
|
||||
|
||||
### Using GPEs as a wake source
|
||||
|
||||
The `wake` property specified above is used to tell the ACPI subsystem that the
|
||||
device can use a GPE to wake the system. The OS can control whether to enable
|
||||
or disable the wake source by unmasking/masking off the GPE.
|
||||
|
||||
The `GPIO` -> `GPE` mapping must be configured in firmware. On AMD platforms this is
|
||||
generally done by a mainboard specific `gpio.c` file that defines the GPIO
|
||||
using `PAD_SCI`. The `GPIO` -> `GPE` mapping is returned by the
|
||||
`soc_get_gpio_event_table` method that is defined in the SoC specific `gpio.c`
|
||||
file. On Intel platforms, you fill in the `pmc_gpe0_dw0`, `pmc_gpe0_dw1`, and
|
||||
`pmc_gpe0_dw2` fields in the devicetree to map 3 GPIO communities to `tier-1`
|
||||
GPEs (the rest are available as `tier-2` GPEs).
|
||||
|
||||
Windows has a large caveat when using this method. If you use the `gpio_irq`
|
||||
property to define a `GpioInt` in the `_CRS`, and then use the `wake` property
|
||||
to define a `GPE`, Windows will
|
||||
[BSOD](https://github.com/MicrosoftDocs/windows-driver-docs/blob/staging/windows-driver-docs-pr/debugger/bug-check-0xa5--acpi-bios-error.md)
|
||||
complaining about an invalid ACPI configuration.
|
||||
> 0x1000D - A device used both GPE and GPIO interrupts, which is not supported.
|
||||
|
||||
In order to avoid this error, you should use the `irq` property instead. AMD
|
||||
platforms don't support routing GPIOs to the IO-APIC, so this workaround isn't
|
||||
feasible. The other option is to use a wake capable GPIO as described below.
|
||||
|
||||
### Using GPIO interrupts as a wake source
|
||||
|
||||
The `ACPI_IRQ_WAKE_{EDGE,LEVEL}_{LOW,HIGH}` macros can be used when setting the
|
||||
`irq` or `gpio_irq` properties. This ends up setting `ExclusiveAndWake` or
|
||||
`SharedAndWake` on the `Interrupt` or `GpioInt` ACPI resource.
|
||||
|
||||
This method has a few caveats:
|
||||
* On Intel and AMD platforms the IO-APIC can't wake the system. This means using
|
||||
the `ACPI_IRQ_WAKE_*` macros with the `irq` property won't actually wake the
|
||||
system. Instead you need to use the `gpio_irq` property, or a `GPE` as
|
||||
described above.
|
||||
* The OS needs to know how to enable the `wake` bit on the GPIO. For linux this
|
||||
means the platform specific GPIO controller driver must implement the
|
||||
`irq_set_wake` callback. For AMD systems this wasn't
|
||||
[implemented](https://github.com/torvalds/linux/commit/d62bd5ce12d79bcd6a6c3e4381daa7375dc21158)
|
||||
until linux v5.15. If the controller doesn't define this callback, it's
|
||||
possible for the firmware to manually set the `wake` bit on the GPIO. This is
|
||||
often done in a mainboard-specific file named `gpio.c`. This is not
|
||||
recommended because then it's not possible for the OS to disable the wake
|
||||
source.
|
||||
* As of
|
||||
[linux v6.0-rc5](https://github.com/torvalds/linux/releases/tag/v6.0-rc5),
|
||||
the ACPI subsystem doesn't take the interrupt `wake` bit into account when
|
||||
deciding on which power state to put the device in before suspending the
|
||||
system. This means that if you define a power resource for a device via
|
||||
`has_power_resource`, `enable_gpio`, etc, then the linux kernel will place the
|
||||
device into D3Cold. i.e., power off the device.
|
||||
|
||||
## Other auto-generated names
|
||||
|
||||
(see [ACPI specification
|
||||
6.3](https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf)
|
||||
for more details on ACPI methods)
|
||||
|
||||
### _S0W (S0 Device Wake State)
|
||||
\_S0W indicates the deepest S0 sleep state this device can wake itself from,
|
||||
which in this case is `ACPI_DEVICE_SLEEP_D3_HOT`, representing _D3hot_.
|
||||
D3Hot means the `PR3` power resources are still on and the device is still
|
||||
responsive on the bus. For i2c devices this is generally the same state as `D0`.
|
||||
|
||||
### \_PRW (Power Resources for Wake)
|
||||
\_PRW indicates the power resources and events required for wake. There are no
|
||||
dependent power resources, but the GPE (GPE0_DW0_21) is mentioned here (0x15),
|
||||
as well as the deepest sleep state supporting waking the system (3), which is
|
||||
S3.
|
||||
|
||||
### \_STA (Status)
|
||||
The \_STA method is generated automatically, and its values, 0xF, indicates the
|
||||
following:
|
||||
|
||||
Bit [0] – Set if the device is present.
|
||||
Bit [1] – Set if the device is enabled and decoding its resources.
|
||||
Bit [2] – Set if the device should be shown in the UI.
|
||||
Bit [3] – Set if the device is functioning properly (cleared if device failed its diagnostics).
|
||||
|
||||
### \_CRS (Current resource settings)
|
||||
The \_CRS method is generated automatically, as the driver knows it is an I2C
|
||||
controller, and so specifies how to configure the controller for proper
|
||||
operation with the touchpad.
|
||||
|
||||
```
|
||||
Name (_CRS, ResourceTemplate () // _CRS: Current Resource Settings
|
||||
{
|
||||
I2cSerialBusV2 (0x0015, ControllerInitiated, 400000,
|
||||
AddressingMode7Bit, "\\_SB.PCI0.I2C0",
|
||||
0x00, ResourceConsumer, , Exclusive, )
|
||||
```
|
||||
|
||||
## Notes
|
||||
|
||||
- **All device driver entries in devicetrees end up in the SSDT table, and are
|
||||
generated in coreboot's ramstage**
|
||||
(The lone exception to this rule is i2c touchpads with the 'detect' flag set;
|
||||
in this case, devices not present will not be added to the SSDT)
|
@ -4,14 +4,9 @@ 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 across platforms.
|
||||
|
||||
For details on how to connect device drivers to a mainboard, see [Driver Devicetree Entries](dt_entries.md).
|
||||
|
||||
Some of the drivers currently available include:
|
||||
|
||||
* [Intel DPTF](dptf.md)
|
||||
* [IPMI KCS](ipmi_kcs.md)
|
||||
* [SMMSTORE](smmstore.md)
|
||||
* [SMMSTOREv2](smmstorev2.md)
|
||||
* [SoundWire](soundwire.md)
|
||||
* [SMMSTOREv2](smmstorev2.md)
|
||||
* [USB4 Retimer](retimer.md)
|
||||
* [CBFS SMBIOS hooks](cbfs_smbios.md)
|
||||
|
@ -42,15 +42,6 @@ The following registers can be set:
|
||||
* `gpe_interrupt`
|
||||
* Integer
|
||||
* The bit in GPE (SCI) used to notify about a change on the KCS.
|
||||
* `wait_for_bmc`
|
||||
* Boolean
|
||||
* Wait for BMC to boot. This can be used if the BMC takes a long time to boot
|
||||
after PoR:
|
||||
- AST2400 on Supermicro X11SSH: 34 s
|
||||
* `bmc_boot_timeout`
|
||||
* Integer
|
||||
* The timeout in seconds to wait for the IPMI service to be loaded.
|
||||
Will be used if wait_for_bmc is true.
|
||||
|
||||
|
||||
[IPMI]: https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmi-second-gen-interface-spec-v2-rev1-1.pdf
|
||||
|
@ -1,6 +1,6 @@
|
||||
# USB4 Retimers
|
||||
|
||||
## Introduction
|
||||
# Introduction
|
||||
As USB speeds continue to increase (up to 5G, 10G, and even 20G or higher in
|
||||
newer revisions of the spec), it becomes more difficult to maintain signal
|
||||
integrity for longer traces. Devices such as retimers and redrivers can be used
|
||||
@ -17,7 +17,7 @@ by doing CDR and retransmitting the data (i.e., it is protocol-aware). Since
|
||||
this is a digital component, it may have firmware.
|
||||
|
||||
|
||||
## Driver Usage
|
||||
# Driver Usage
|
||||
|
||||
Some operating systems may have the ability to update firmware on USB4 retimers,
|
||||
and ultimately will need some way to power the device on and off so that its new
|
||||
|
@ -21,7 +21,7 @@ operations is desired, as it reduces complexity and potential for bugs.
|
||||
|
||||
This can be used by a FTW (FaultTolerantWrite) implementation that uses
|
||||
at least two regions in an A/B update scheme. The FTW implementation in
|
||||
edk2 uses three different regions in the store:
|
||||
EDK2 uses three different regions in the store:
|
||||
|
||||
- The variable store
|
||||
- The FTW spare block
|
||||
@ -35,7 +35,7 @@ With 64 KiB as block size, the minimum size of the FTW-enabled store is:
|
||||
- The FTW spare block: 2 blocks = 2 * 64 KiB
|
||||
- The FTW working block: 1 block = 64 KiB
|
||||
|
||||
Therefore, the minimum size for edk2 FTW is 4 blocks, or 256 KiB.
|
||||
Therefore, the minimum size for EDK2 FTW is 4 blocks, or 256 KiB.
|
||||
|
||||
## API
|
||||
|
||||
|
@ -1,136 +0,0 @@
|
||||
# External Resources
|
||||
|
||||
This is a list of resources that could be useful to coreboot developers.
|
||||
These are not endorsed or officially recommended by the coreboot project,
|
||||
but simply listed here in the hopes that someone will find something
|
||||
useful.
|
||||
|
||||
Please add any helpful or informational links and sections as you see fit.
|
||||
|
||||
## Articles
|
||||
|
||||
* External Interrupts in the x86 system.
|
||||
* [Part 1: Interrupt controller evolution](https://habr.com/en/post/446312/)
|
||||
* [Part 2: Linux kernel boot options](https://habr.com/en/post/501660/)
|
||||
* [Part 3: Interrupt routing setup in a chipset](https://habr.com/en/post/501912/)
|
||||
* System address map initialization in x86/x64 architecture.
|
||||
* [Part 1: PCI-based systems](https://resources.infosecinstitute.com/topic/system-address-map-initialization-in-x86x64-architecture-part-1-pci-based-systems/)
|
||||
* [Part 2: PCI express-based systems](https://resources.infosecinstitute.com/topic/system-address-map-initialization-x86x64-architecture-part-2-pci-express-based-systems/)
|
||||
* [PCIe elastic buffer](https://www.mindshare.com/files/resources/mindshare_pcie_elastic_buffer.pdf)
|
||||
* [Boot Guard and PSB have user-hostile defaults](https://mjg59.dreamwidth.org/58424.html)
|
||||
|
||||
|
||||
## General Information
|
||||
|
||||
* [OS Dev](https://wiki.osdev.org/Categorized_Main_Page)
|
||||
* [Interface BUS](http://www.interfacebus.com/)
|
||||
|
||||
## OpenSecurityTraining2
|
||||
|
||||
OpenSecurityTraining2 is dedicated to sharing training material for any topic
|
||||
related to computer security, including coreboot.
|
||||
|
||||
There are various ways to learn firmware, some are more efficient than others,
|
||||
depending on the people. Before going straight to practice and experimenting
|
||||
with hardware, it can be beneficial to learn the basics of computing. OST2
|
||||
focuses on conveying computer architecture and security information in the form
|
||||
of structured instructor-led classes, available to everyone for free.
|
||||
|
||||
All material is licensed [CC BY-SA 4.0](http://creativecommons.org/licenses/by-sa/4.0/),
|
||||
allowing anyone to use the material however they see fit, so long as they share
|
||||
modified works back to the community.
|
||||
|
||||
Below is a list of currently available courses that can help understand the
|
||||
inner workings of coreboot and other firmware-related topics:
|
||||
|
||||
* [coreboot design principles and boot process](https://ost2.fyi/Arch4031)
|
||||
* [x86-64 Assembly](https://ost2.fyi/Arch1001)
|
||||
* [x86-64 OS Internals](https://ost2.fyi/Arch2001)
|
||||
* [x86-64 Intel Firmware Attack & Defense](https://ost2.fyi/Arch4001)
|
||||
|
||||
There are [additional security courses](https://p.ost2.fyi/courses) at the site
|
||||
as well (such as
|
||||
[how to avoid writing exploitable code in C/C++](https://ost2.fyi/Vulns1001).)
|
||||
|
||||
## Firmware Specifications & Information
|
||||
|
||||
* [System Management BIOS - SMBIOS](https://www.dmtf.org/standards/smbios)
|
||||
* [Desktop and Mobile Architecture for System Hardware - DASH](https://www.dmtf.org/standards/dash)
|
||||
* [PNP BIOS](https://www.intel.com/content/dam/support/us/en/documents/motherboards/desktop/sb/pnpbiosspecificationv10a.pdf)
|
||||
|
||||
|
||||
### ACPI
|
||||
|
||||
* [ACPI Specs](https://uefi.org/acpi/specs)
|
||||
* [ACPI in Linux](https://www.kernel.org/doc/ols/2005/ols2005v1-pages-59-76.pdf)
|
||||
* [ACPI 5 Linux](https://blog.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/LPC2012-ACPI5.pdf)
|
||||
* [ACPI 6 Linux](https://events.static.linuxfound.org/sites/events/files/slides/ACPI_6_and_Linux_0.pdf)
|
||||
|
||||
|
||||
### Security
|
||||
|
||||
* [Intel Boot Guard](https://edk2-docs.gitbook.io/understanding-the-uefi-secure-boot-chain/secure_boot_chain_in_uefi/intel_boot_guard)
|
||||
|
||||
|
||||
## Hardware information
|
||||
|
||||
* [WikiChip](https://en.wikichip.org/wiki/WikiChip)
|
||||
* [Sandpile](https://www.sandpile.org/)
|
||||
* [CPU-World](https://www.cpu-world.com/index.html)
|
||||
* [CPU-Upgrade](https://www.cpu-upgrade.com/index.html)
|
||||
|
||||
|
||||
### Hardware Specifications & Standards
|
||||
|
||||
* [Bluetooth](https://www.bluetooth.com/specifications/specs/) - Bluetooth SIG
|
||||
* [eMMC](https://www.jedec.org/) - JEDEC - (LOGIN REQUIRED)
|
||||
* [eSPI](https://cdrdv2.intel.com/v1/dl/getContent/645987) - Intel
|
||||
* [I2c Spec](https://web.archive.org/web/20170704151406/https://www.nxp.com/docs/en/user-guide/UM10204.pdf),
|
||||
[Appnote](https://www.nxp.com/docs/en/application-note/AN10216.pdf) - NXP
|
||||
* [I2S](https://www.nxp.com/docs/en/user-manual/UM11732.pdf) - NXP
|
||||
* [I3C](https://www.mipi.org/specifications/i3c-sensor-specification) - MIPI Alliance (LOGIN REQUIRED)
|
||||
* [Memory](https://www.jedec.org/) - JEDEC - (LOGIN REQUIRED)
|
||||
* [NVMe](https://nvmexpress.org/developers/) - NVMe Specifications
|
||||
* [LPC](https://www.intel.com/content/dam/www/program/design/us/en/documents/low-pin-count-interface-specification.pdf) - Intel
|
||||
* [PCI / PCIe / M.2](https://pcisig.com/specifications) - PCI-SIG - (LOGIN REQUIRED)
|
||||
* [Power Delivery](https://www.usb.org/documents) - USB Implementers Forum
|
||||
* [SATA](https://sata-io.org/developers/purchase-specification) - SATA-IO (LOGIN REQUIRED)
|
||||
* [SMBus](http://www.smbus.org/specs/) - System Management Interface Forum
|
||||
* [Smart Battery](http://smartbattery.org/specs/) - Smart Battery System Implementers Forum
|
||||
* [USB](https://www.usb.org/documents) - USB Implementers Forum
|
||||
* [WI-FI](https://www.wi-fi.org/discover-wi-fi/specifications) - Wi-Fi Alliance
|
||||
|
||||
|
||||
### Chip Vendor Documentation
|
||||
|
||||
* AMD
|
||||
* [Developer Guides, Manuals & ISA Documents](https://developer.amd.com/resources/developer-guides-manuals/)
|
||||
* [AMD Tech Docs - Official Documentation Page](https://www.amd.com/en/support/tech-docs)
|
||||
* ARM
|
||||
* [Tools and Software - Specifications](https://developer.arm.com/tools-and-software/software-development-tools/specifications)
|
||||
* Intel
|
||||
* [Developer Zone](https://www.intel.com/content/www/us/en/developer/overview.html)
|
||||
* [Resource & Documentation Center](https://www.intel.com/content/www/us/en/resources-documentation/developer.html)
|
||||
* [Architecture Software Developer Manuals](https://www.intel.com/content/www/us/en/developer/articles/technical/intel-sdm.html)
|
||||
* [Intel specific ACPI](https://www.intel.com/content/www/us/en/standards/processor-vendor-specific-acpi-specification.html)
|
||||
|
||||
* Rockchip
|
||||
* [Open Source Wiki](https://opensource.rock-chips.com/wiki_Main_Page)
|
||||
|
||||
|
||||
## Software
|
||||
|
||||
* [Fiedka](https://github.com/fiedka/fiedka) - A graphical Firmware Editor
|
||||
* [IOTools](https://github.com/adurbin/iotools) - Command line tools to access hardware registers
|
||||
* [UEFITool](https://github.com/LongSoft/UEFITool) - Editor for UEFI PI compliant firmware images
|
||||
* [CHIPSEC](https://chipsec.github.io) - Framework for analyzing platform level security & configuration
|
||||
* [SPDEditor](https://github.com/integralfx/SPDEditor) - GUI to edit DDR3 SPD files
|
||||
* [DDR4XMPEditor](https://github.com/integralfx/DDR4XMPEditor) - Editor for DDR4 SPD and XMP
|
||||
* [overclockSPD](https://github.com/baboomerang/overclockSPD) - Fast and easy way to read and write data to RAM SPDs.
|
||||
* [VBiosFinder](https://github.com/coderobe/VBiosFinder) - This tool attempts to extract a VBIOS from a BIOS update.
|
||||
|
||||
|
||||
## Infrastructure software
|
||||
|
||||
* [Kconfig](https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html)
|
||||
* [GNU Make](https://www.gnu.org/software/make/manual/)
|
@ -62,23 +62,6 @@ supported options are:
|
||||
|
||||
`position` and `align` are mutually exclusive.
|
||||
|
||||
### Adding Makefile fragments
|
||||
|
||||
You can use the `add_intermediate` helper to add new post-processing steps for
|
||||
the final `coreboot.rom` image. For example you can add new files to CBFS by
|
||||
adding something like this to `site-local/Makefile.inc`
|
||||
|
||||
```
|
||||
$(call add_intermediate, add_mrc_data)
|
||||
$(CBFSTOOL) $< write -r RW_MRC_CACHE -f site-local/my-mrc-recording.bin
|
||||
```
|
||||
|
||||
Note that the second line must start with a tab, not spaces.
|
||||
|
||||
```eval_rst
|
||||
See also :doc:`../tutorial/managing_local_additions`.
|
||||
```
|
||||
|
||||
#### FMAP region support
|
||||
With the addition of FMAP flash partitioning support to coreboot, there was a
|
||||
need to extend the specification of files to provide more precise control
|
||||
|
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 12 KiB |
@ -1,87 +0,0 @@
|
||||
# Adding new devices to a device tree
|
||||
|
||||
## Introduction
|
||||
|
||||
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 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.
|
||||
|
||||
## Devicetree and overridetree (if applicable)
|
||||
|
||||
For mainboards that are organized around a "reference board" or "baseboard"
|
||||
model (see ``src/mainboard/google/octopus`` or ``hatch`` for examples), there is
|
||||
typically a devicetree.cb file that all boards share, and any differences for a
|
||||
specific board ("variant") are captured in the overridetree.cb file. Any
|
||||
settings changed in the overridetree take precedence over those in the main
|
||||
devicetree. Note, not all mainboards will have the devicetree/overridetree
|
||||
distinction, and may only have a devicetree.cb file. Or you can always just
|
||||
write the ASL (ACPI Source Language) code yourself.
|
||||
|
||||
### Naming and referencing devices
|
||||
|
||||
When declaring a device, it can optionally be given an alias that can be
|
||||
referred to elsewhere. This is particularly useful to declare a device in one
|
||||
device tree while allowing its configuration to be more easily changed in an
|
||||
overlay. For instance, the AMD Picasso SoC definition
|
||||
(`soc/amd/picasso/chipset.cb`) declares an IOMMU on a PCI bus that is disabled
|
||||
by default:
|
||||
|
||||
```
|
||||
chip soc/amd/picasso
|
||||
device domain 0 on
|
||||
...
|
||||
device pci 00.2 alias iommu off end
|
||||
...
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
A device based on this SoC can override the configuration for the IOMMU without
|
||||
duplicating addresses, as in
|
||||
`mainboard/google/zork/variants/baseboard/devicetree_trembyle.cb`:
|
||||
|
||||
```
|
||||
chip soc/amd/picasso
|
||||
device domain 0
|
||||
...
|
||||
device ref iommu on end
|
||||
...
|
||||
end
|
||||
end
|
||||
```
|
||||
|
||||
In this example the override simply enables the IOMMU, but it could also
|
||||
set additional properties (or even add child devices) inside the IOMMU `device`
|
||||
block.
|
||||
|
||||
---
|
||||
|
||||
It is important to note that devices that use `device ref` syntax to override
|
||||
previous definitions of a device by alias must be placed at **exactly the same
|
||||
location in the device tree** as the original declaration. If not, this will
|
||||
actually create another device rather than overriding the properties of the
|
||||
existing one. For instance, if the above snippet from `devicetree_trembyle.cb`
|
||||
were written as follows:
|
||||
|
||||
```
|
||||
chip soc/amd/picasso
|
||||
# NOTE: not inside domain 0!
|
||||
device ref iommu on end
|
||||
end
|
||||
```
|
||||
|
||||
Then this would leave the SoC's IOMMU disabled, and instead create a new device
|
||||
with no properties as a direct child of the SoC.
|
||||
|
||||
## Device drivers
|
||||
|
||||
Platform independent device drivers are hooked up via entries in a devicetree.
|
||||
See [Driver Devicetree Entries](../drivers/dt_entries.md) for more info.
|
||||
|
||||
## Notes
|
||||
|
||||
- **All fields that are left unspecified in the devicetree are initialized to
|
||||
zero.**
|
@ -6,4 +6,3 @@
|
||||
* [Kconfig](kconfig.md)
|
||||
* [Writing Documentation](writing_documentation.md)
|
||||
* [Setting up GPIOs](gpio.md)
|
||||
* [Adding devices to a device tree](devicetree.md)
|
||||
|
@ -1,8 +1,9 @@
|
||||
# Welcome to the coreboot documentation
|
||||
|
||||
This is the developer documentation for [coreboot](https://coreboot.org).
|
||||
It is built from Markdown files in the [Documentation] directory in the
|
||||
source code.
|
||||
It is built from Markdown files in the
|
||||
[Documentation](https://review.coreboot.org/cgit/coreboot.git/tree/Documentation)
|
||||
directory in the source code.
|
||||
|
||||
## Spelling of coreboot
|
||||
|
||||
@ -25,7 +26,7 @@ initialization routines across many different use cases, no matter if
|
||||
they provide standard interfaces or entirely custom boot flows.
|
||||
|
||||
Popular [payloads](payloads.md) in use with coreboot are SeaBIOS,
|
||||
which provides PCBIOS services, edk2, which provides UEFI services,
|
||||
which provides PCBIOS services, Tianocore, which provides UEFI services,
|
||||
GRUB2, the bootloader used by many Linux distributions, or depthcharge,
|
||||
a custom boot loader used on Chromebooks.
|
||||
|
||||
@ -142,7 +143,7 @@ say hello!
|
||||
## Getting the source code
|
||||
|
||||
coreboot is primarily developed in the
|
||||
[git](https://review.coreboot.org/plugins/gitiles/coreboot) version control
|
||||
[git](https://review.coreboot.org/cgit/coreboot.git) version control
|
||||
system, using [Gerrit](https://review.coreboot.org) to manage
|
||||
contributions and code review.
|
||||
|
||||
@ -192,12 +193,8 @@ Contents:
|
||||
* [SuperIO](superio/index.md)
|
||||
* [Vendorcode](vendorcode/index.md)
|
||||
* [Utilities](util.md)
|
||||
* [Software Bill of Materials](sbom/sbom.md)
|
||||
* [Project infrastructure & services](infrastructure/index.md)
|
||||
* [Boards supported in each release directory](releases/boards_supported_on_branches.md)
|
||||
* [Release notes](releases/index.md)
|
||||
* [Acronyms & Definitions](acronyms.md)
|
||||
* [External Resources](external_docs.md)
|
||||
* [Documentation License](documentation_license.md)
|
||||
|
||||
[Documentation]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/Documentation/
|
||||
|
@ -383,7 +383,7 @@ training. This example expects that the default value of this `register` is set
|
||||
|
||||
void mainboard_memory_init_params(FSPM_UPD *mupd)
|
||||
{
|
||||
if (fw_config_probe(FW_CONFIG(FEATURE, DISABLED))
|
||||
if (fw_config_probe_one(FW_CONFIG(FEATURE, DISABLED))
|
||||
mupd->ExampleFeature = false;
|
||||
}
|
||||
```
|
||||
|
@ -1,80 +0,0 @@
|
||||
# Pademelon board
|
||||
|
||||
## Specs (with Merlin Falcon SOC)
|
||||
|
||||
* Two 260-pin DDR4 SO-DIMM slots, 1.2V DDR4-1333/1600/1866/2133 SO-DIMMs
|
||||
Supports 4GB, 8GB and 16GB DDR4 unbuffered ECC (Merlin Falcon)SO-DIMMs
|
||||
* Can use Prairie Falcon, Brown Falcon, Merlin Falcon, though coreboot
|
||||
code is specific for Merlin Falcon SOC. Some specs will change if not
|
||||
using Merlin Falcon.
|
||||
* One half mini PCI-Express slot on back side of mainboard
|
||||
* One PCI Express® 3.0 x8 slot
|
||||
* Two SATA3 ports with 6Gb/s data transfer rate
|
||||
* Two USB 2.0 ports at rear panel
|
||||
* Two USB 3.0 ports at rear panel
|
||||
* Dual Gigabit Ethernet from Realtek RTL8111F Gigabit controller
|
||||
* 6-channel High-Definition audio from Realtek ALC662 codec
|
||||
* One soldered down SPI flash with dediprog header
|
||||
|
||||
## Mainboard
|
||||
|
||||
![mainboard][pademelon]
|
||||
|
||||
Three items are marked in this picture
|
||||
1. dediprog header
|
||||
2. memory dimms, address 0xA0 and 0xA4
|
||||
3. SATA cables connected to motherboard
|
||||
|
||||
## Back panel
|
||||
|
||||
![back panel][pademelon_io]
|
||||
|
||||
* The lower serial port is UART A (debug serial)
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+--------------------+
|
||||
| Type | Value |
|
||||
+=====================+====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+--------------------+
|
||||
| Model | Macronix MX256435E |
|
||||
+---------------------+--------------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+--------------------+
|
||||
| Flash programming | dediprog header |
|
||||
+---------------------+--------------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+--------------------+
|
||||
| Write protection | No |
|
||||
+---------------------+--------------------+
|
||||
```
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+---------------+------------------------------+
|
||||
| Fan control | Using fintek F81803A |
|
||||
+---------------+------------------------------+
|
||||
| CPU | Merlin Falcon (see reference)|
|
||||
+---------------+------------------------------+
|
||||
```
|
||||
|
||||
## Description of pictures within this document
|
||||
|
||||
```eval_rst
|
||||
+----------------------------+----------------------------------------+
|
||||
|pademelon.jpg | Motherboard with components identified |
|
||||
+----------------------------+----------------------------------------+
|
||||
|pademelon_io.jpg | Back panel picture |
|
||||
+----------------------------+----------------------------------------+
|
||||
```
|
||||
|
||||
## Reference
|
||||
|
||||
[Merlin Falcon BKDG][merlinfalcon]
|
||||
|
||||
[merlinfalcon]: ../../../soc/amd/family15h.md
|
||||
[pademelon]: pademelon.jpg
|
||||
[pademelon_io]: pademelon_io.jpg
|
Before Width: | Height: | Size: 79 KiB After Width: | Height: | Size: 79 KiB |
80
Documentation/mainboard/amd/padmelon/padmelon.md
Normal file
@ -0,0 +1,80 @@
|
||||
# Padmelon board
|
||||
|
||||
## Specs (with Merlin Falcon SOC)
|
||||
|
||||
* Two 260-pin DDR4 SO-DIMM slots, 1.2V DDR4-1333/1600/1866/2133 SO-DIMMs
|
||||
Supports 4GB, 8GB and 16GB DDR4 unbuffered ECC (Merlin Falcon)SO-DIMMs
|
||||
* Can use Prairie Falcon, Brown Falcon, Merlin Falcon, though coreboot
|
||||
code is specific for Merlin Falcon SOC. Some specs will change if not
|
||||
using Merlin Falcon.
|
||||
* One half mini PCI-Express slot on back side of mainboard
|
||||
* One PCI Express® 3.0 x8 slot
|
||||
* Two SATA3 ports with 6Gb/s data transfer rate
|
||||
* Two USB 2.0 ports at rear panel
|
||||
* Two USB 3.0 ports at rear panel
|
||||
* Dual Gigabit Ethernet from Realtek RTL8111F Gigabit controller
|
||||
* 6-channel High-Definition audio from Realtek ALC662 codec
|
||||
* One soldered down SPI flash with dediprog header
|
||||
|
||||
## Mainboard
|
||||
|
||||
![mainboard][padmelon]
|
||||
|
||||
Three items are marked in this picture
|
||||
1. dediprog header
|
||||
2. memory dimms, address 0xA0 and 0xA4
|
||||
3. SATA cables connected to motherboard
|
||||
|
||||
## Back panel
|
||||
|
||||
![back panel][padmelon_io]
|
||||
|
||||
* The lower serial port is UART A (debug serial)
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+--------------------+
|
||||
| Type | Value |
|
||||
+=====================+====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+--------------------+
|
||||
| Model | Macronix MX256435E |
|
||||
+---------------------+--------------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+--------------------+
|
||||
| Flash programming | dediprog header |
|
||||
+---------------------+--------------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+--------------------+
|
||||
| Write protection | No |
|
||||
+---------------------+--------------------+
|
||||
```
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+---------------+------------------------------+
|
||||
| Fan control | Using fintek F81803A |
|
||||
+---------------+------------------------------+
|
||||
| CPU | Merlin Falcon (see reference)|
|
||||
+---------------+------------------------------+
|
||||
```
|
||||
|
||||
## Description of pictures within this document
|
||||
|
||||
```eval_rst
|
||||
+----------------------------+----------------------------------------+
|
||||
|padmelon.jpg | Motherboard with components identified |
|
||||
+----------------------------+----------------------------------------+
|
||||
|padmelon_io.jpg | Back panel picture |
|
||||
+----------------------------+----------------------------------------+
|
||||
```
|
||||
|
||||
## Reference
|
||||
|
||||
[Merlin Falcon BKDG][merlinfalcon]
|
||||
|
||||
[merlinfalcon]: ../../../soc/amd/family15h.md
|
||||
[padmelon]: padmelon.jpg
|
||||
[padmelon_io]: padmelon_io.jpg
|
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 32 KiB |
@ -45,9 +45,7 @@ Tests were done with SeaBIOS 1.14.0 and slackware64-live from 2019-07-12
|
||||
- Rear eSATA connector (multiplexed with one ASM1061 port)
|
||||
- Gigabit Ethernet
|
||||
- Console output on the serial port
|
||||
- EDK II (MrChromebox's fork, at origin/uefipayload_202207) to boot
|
||||
Windows 10 (22H2) and Linux (5.19.17) via GRUB 2
|
||||
- SeaBIOS 1.16.1 to boot Windows 10 (needs VGA BIOS) and Linux via
|
||||
- SeaBIOS 1.14.0 and 1.15.0 to boot Windows 10 (needs VGA BIOS) and Linux via
|
||||
extlinux
|
||||
- Internal flashing with flashrom-1.2, see
|
||||
[Internal Programming](#internal-programming)
|
||||
|
@ -1,108 +0,0 @@
|
||||
# ASUS P2B-LS
|
||||
|
||||
This page describes how to run coreboot on the ASUS P2B-LS mainboard.
|
||||
|
||||
## Variants
|
||||
|
||||
- P2B-LS
|
||||
- P2B-L (Same circuit board with SCSI components omitted)
|
||||
- P2B-S (Same circuit board with ethernet components omitted)
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------------+
|
||||
| Type | Value |
|
||||
+=====================+===========================+
|
||||
| Model | SST 39SF020A (or similar) |
|
||||
+---------------------+---------------------------+
|
||||
| Protocol | Parallel |
|
||||
+---------------------+---------------------------+
|
||||
| Size | 256 KiB |
|
||||
+---------------------+---------------------------+
|
||||
| Package | DIP-32 |
|
||||
+---------------------+---------------------------+
|
||||
| Socketed | yes |
|
||||
+---------------------+---------------------------+
|
||||
| Write protection | no |
|
||||
+---------------------+---------------------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+---------------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------------+
|
||||
```
|
||||
|
||||
[flashrom] works out of the box since 0.9.2.
|
||||
Because of deficiency in vendor firmware, user needs to override the laptop
|
||||
warning as prompted. Once coreboot is in place there will be no further issue.
|
||||
|
||||
### CPU microcode considerations
|
||||
|
||||
By default, this board includes microcode updates for 5 families of Intel CPUs
|
||||
because of the wide variety of CPUs the board supports, directly or with an
|
||||
adapter. These take up a third of the total flash space leaving only 20kB free
|
||||
in the final cbfs image. It may be necessary to build a custom microcode update
|
||||
file by manually concatenating files in 3rdparty/intel-microcode/intel-ucode
|
||||
for only CPU models that the board will actually be run with.
|
||||
|
||||
## Working
|
||||
|
||||
- Slot 1 and Socket 370 CPUs and their L1/L2 caches
|
||||
- PS/2 keyboard with SeaBIOS (See [Known issues])
|
||||
- IDE hard drives
|
||||
- Ethernet (-LS, -L; Intel 82558)
|
||||
- SCSI (-LS, -S; Adaptec AIC7890)
|
||||
- USB
|
||||
- ISA add-on cards
|
||||
- PCI add-on cards
|
||||
- AGP graphics card
|
||||
- Floppy
|
||||
- Serial ports 1 and 2
|
||||
- Reboot
|
||||
- Soft off
|
||||
|
||||
## Known issues
|
||||
|
||||
- PS/2 keyboard may not be usable until Linux has completely booted.
|
||||
With SeaBIOS as payload, setting keyboard initialization timeout to
|
||||
500ms may fix the issue.
|
||||
|
||||
- i440BX does not support 256Mbit RAM modules. If installed, coreboot
|
||||
will attempt to initialize them at half their capacity anyway
|
||||
whereas vendor firmware will not boot at all.
|
||||
|
||||
- ECC memory can be used, but ECC support is still pending.
|
||||
|
||||
- Termination is enabled for all SCSI ports (if equipped). Support to
|
||||
disable termination is pending. Note that the SCSI-68 port is
|
||||
always terminated, even with vendor firmware.
|
||||
|
||||
## Untested
|
||||
|
||||
- Parallel port
|
||||
- EDO memory
|
||||
- Infrared
|
||||
- PC speaker
|
||||
|
||||
## Not working
|
||||
|
||||
- S3 suspend to RAM
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | Intel I440BX |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | i82371eb |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | P6 family for Slot 1 and Socket 370 |
|
||||
| | (all models from model_63x to model_6bx) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | winbond/w83977tf |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Extra resources
|
||||
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
@ -1,106 +0,0 @@
|
||||
# ASUS P3B-F
|
||||
|
||||
This page describes how to run coreboot on the ASUS P3B-F mainboard.
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------------+
|
||||
| Type | Value |
|
||||
+=====================+===========================+
|
||||
| Model | SST 39SF020A (or similar) |
|
||||
+---------------------+---------------------------+
|
||||
| Protocol | Parallel |
|
||||
+---------------------+---------------------------+
|
||||
| Size | 256 KiB |
|
||||
+---------------------+---------------------------+
|
||||
| Package | DIP-32 |
|
||||
+---------------------+---------------------------+
|
||||
| Socketed | yes |
|
||||
+---------------------+---------------------------+
|
||||
| Write protection | See below |
|
||||
+---------------------+---------------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------------+
|
||||
```
|
||||
|
||||
flashrom supports this mainboard since commit c7e9a6e15153684672bbadd1fc6baed8247ba0f6.
|
||||
If you are using older versions of flashrom, below has to be done (with ACPI disabled!)
|
||||
before flashrom can detect the flash chip:
|
||||
|
||||
```bash
|
||||
# rmmod w83781d
|
||||
# modprobe i2c-dev
|
||||
# i2cset 0 0x48 0x80 0x80
|
||||
```
|
||||
|
||||
Upon power up, flash chip is inaccessible until flashrom has been run once.
|
||||
Since flashrom does not support reversing board enabling steps,
|
||||
once it detects the flash chip, there will be no write protection until
|
||||
the next power cycle.
|
||||
|
||||
### CPU microcode considerations
|
||||
|
||||
By default, this board includes microcode updates for 5 families of Intel CPUs
|
||||
because of the wide variety of CPUs the board supports, directly or with an
|
||||
adapter. These take up a third of the total flash space leaving only 20kB free
|
||||
in the final cbfs image. It may be necessary to build a custom microcode update
|
||||
file by manually concatenating files in 3rdparty/intel-microcode/intel-ucode
|
||||
for only CPU models that the board will actually be run with.
|
||||
|
||||
## Working
|
||||
|
||||
- Slot 1 and Socket 370 CPUs and their L1/L2 caches
|
||||
- PS/2 keyboard with SeaBIOS (See [Known issues])
|
||||
- IDE hard drives
|
||||
- USB
|
||||
- PCI add-on cards
|
||||
- AGP graphics cards
|
||||
- Serial ports 1 and 2
|
||||
- Reboot
|
||||
|
||||
## Known issues
|
||||
|
||||
- PS/2 keyboard may not be usable until Linux has completely booted. With SeaBIOS
|
||||
as payload, setting keyboard initialization timeout to 2500ms may help.
|
||||
|
||||
- The coreboot+SeaBIOS combination boots so quickly some IDE hard drives are not
|
||||
yet ready by the time SeaBIOS attempts to boot from them.
|
||||
|
||||
- i440BX does not support 256Mbit RAM modules. If installed, coreboot
|
||||
will attempt to initialize them at half their capacity anyway
|
||||
whereas vendor firmware will not boot at all.
|
||||
|
||||
- ECC memory can be used, but ECC support is still pending.
|
||||
|
||||
## Untested
|
||||
|
||||
- Floppy
|
||||
- Parallel port
|
||||
- EDO memory
|
||||
- ECC memory
|
||||
- Infrared
|
||||
- PC speaker
|
||||
|
||||
## Not working
|
||||
|
||||
- ACPI (Support is currently [under gerrit review](https://review.coreboot.org/c/coreboot/+/41098))
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | Intel I440BX |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | i82371eb |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | P6 family for Slot 1 and Socket 370 |
|
||||
| | (all models from model_63x to model_6bx) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | winbond/w83977tf |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Extra resources
|
||||
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
@ -1,137 +0,0 @@
|
||||
# ASUS P8Z77-M
|
||||
|
||||
This page describes how to run coreboot on the [ASUS P8Z77-M].
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+----------------+
|
||||
| Type | Value |
|
||||
+=====================+================+
|
||||
| Model | W25Q64FVA1Q |
|
||||
+---------------------+----------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+----------------+
|
||||
| Package | DIP-8 |
|
||||
+---------------------+----------------+
|
||||
| Socketed | yes |
|
||||
+---------------------+----------------+
|
||||
| Write protection | yes |
|
||||
+---------------------+----------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+----------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+----------------+
|
||||
```
|
||||
|
||||
The flash chip is located between the blue SATA ports.
|
||||
|
||||
The main SPI flash cannot be written internally because Asus disables BIOSWE and
|
||||
enables ``BLE/SMM_BWP`` flags in ``BIOS_CNTL`` for their latest bioses.
|
||||
To install coreboot for the first time, the flash chip must be removed and
|
||||
flashed with an external programmer; flashing in-circuit doesn't work.
|
||||
The flash chip is socketed, so it's easy to remove and reflash.
|
||||
|
||||
## Working
|
||||
|
||||
- All USB2 ports (mouse, keyboard and thumb drive)
|
||||
- USB3 ports on rear (Boots SystemRescue 6.0.3 off a Kingston DataTraveler G4 8GB)
|
||||
- Gigabit Ethernet (RTL8111F)
|
||||
- SATA3, SATA2 (all ports, hot-swap not tested)
|
||||
(Blue SATA2) (Blue SATA2) (White SATA3)
|
||||
port 5 port 3 port 1
|
||||
port 6 port 4 port 2
|
||||
|
||||
- CPU Temp sensors and hardware monitor (some values don't make sense)
|
||||
- Native and MRC memory initialization
|
||||
(please see [Native raminit compatibility] and [MRC memory compatibility])
|
||||
|
||||
- Integrated graphics with both libgfxinit and the Intel Video BIOS OpROM
|
||||
(VGA/DVI-D/HDMI tested and working)
|
||||
- 16x PCIe GPU in PCIe-16x/4x slots (tested using nVidia Quadro 600 under SystemRescue 6.0.3
|
||||
(Arch based))
|
||||
- Serial port
|
||||
- PCI slot
|
||||
Rockwell HSF 56k PCI modem, Sound Blaster Live! CT4780 (cards detected, not function tested)
|
||||
Promise SATA150 TX2plus (R/W OK to connected IDE hard drive, OpRom loaded, cannot boot from
|
||||
SeaBIOS)
|
||||
- S3 suspend from Linux
|
||||
- 2-channel analog audio (WAV playback by mplayer via back panel line out port)
|
||||
- Windows 10 with libgfxinit high resolution framebuffer and VBT
|
||||
|
||||
## Known issues
|
||||
|
||||
- If you use MRC raminit, the NVRAM variable gfx_uma_size may be ignored as IGP's UMA could
|
||||
be reconfigured by the blob.
|
||||
|
||||
- If SeaBIOS is used for payload with libgfxinit, it must be brought in via coreboot's config.
|
||||
Otherwise integrated graphics would fail with a black screen.
|
||||
|
||||
- PCI POST card is not functional because the PCI bridge early init is not yet done.
|
||||
|
||||
- The black PCIEX16_2 slot, although can physically fit an x16, only has physical contacts for
|
||||
an x8, and is electrically an x4 only.
|
||||
|
||||
## Untested
|
||||
|
||||
- Wake-on-LAN
|
||||
- USB3 on header
|
||||
- TPM header
|
||||
- EHCI debugging (Debug port is on the 5-pin side of USB2_910 header)
|
||||
- HDMI and S/PDIF audio out
|
||||
|
||||
## Not working
|
||||
|
||||
- PS/2 keyboard or mouse
|
||||
- 4 and 6 channel analog audio out: Rear left and right audio is a muted
|
||||
copy of front left and right audio, and the other two channels are silent.
|
||||
|
||||
## Native (and MRC) raminit compatibility
|
||||
|
||||
- OCZ OCZ3G1600LVAM 2x2GB kit works at DDR3-1066 instead of DDR3-1600.
|
||||
|
||||
- GSkill F3-1600C9D-16GRSL 2x8GB SODIMM kit on adapter boots, but is highly unstable
|
||||
with obvious pattern of bit errors during memtest86+ runs.
|
||||
|
||||
- Samsung PC3-10600U 2x2GB kit works at full rated speed.
|
||||
|
||||
- Kingston KTH9600B-4G 2x4GB kit works at full rated speed.
|
||||
|
||||
## Extra onboard buttons
|
||||
|
||||
The board has two onboard buttons, and each has a related LED nearby.
|
||||
What controls the LEDs and what the buttons control are unknown,
|
||||
therefore they currently do nothing under coreboot.
|
||||
|
||||
- BIOS_FLBK
|
||||
OEM firmware uses this button to facilitate a simple update mechanism
|
||||
via a USB drive plugged into the bottom USB port of the USB/LAN stack.
|
||||
|
||||
- MemOK!
|
||||
OEM firmware uses this button for memory tuning related to overclocking.
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | :doc:`../../northbridge/intel/sandybridge/index` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | bd82x6x |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | model_206ax |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | Nuvoton NCT6779D |
|
||||
+------------------+--------------------------------------------------+
|
||||
| EC | None |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Extra resources
|
||||
|
||||
- [Flash chip datasheet][W25Q64FVA1Q]
|
||||
|
||||
[ASUS P8Z77-M]: https://www.asus.com/Motherboards/P8Z77M/
|
||||
[W25Q64FVA1Q]: https://www.winbond.com/resource-files/w25q64fv%20revs%2007182017.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
@ -37,7 +37,7 @@ easy to remove and reflash.
|
||||
|
||||
## Working
|
||||
|
||||
- PS/2 keyboard with SeaBIOS & edk2 (in Mint 18.3/19.1)
|
||||
- PS/2 keyboard with SeaBIOS & Tianocore (in Mint 18.3/19.1)
|
||||
|
||||
- Rear/front headphones connector audio & mic
|
||||
|
||||
@ -57,7 +57,7 @@ easy to remove and reflash.
|
||||
port 3 port 5 port 1 port 8
|
||||
port 4 port 6 port 2 port 7
|
||||
|
||||
- NVME SSD boot on PCIe-x16/x8/4x slot using edk2
|
||||
- NVME SSD boot on PCIe-x16/x8/4x slot using Tianocore
|
||||
(tested with M.2-to-PCIe adapter and a M.2 Samsung EVO 970 SSD)
|
||||
|
||||
- CPU Temp sensors (tested PSensor on linux + HWINFO64 on Win10)
|
||||
@ -89,7 +89,7 @@ easy to remove and reflash.
|
||||
- If you use the MRC.bin, the NVRAM variable gfx_uma_size may be ignored
|
||||
as IGP's UMA could be reconfigured by the blob
|
||||
|
||||
- Using edk2 + a PCIe GPU under Windows crashes with an
|
||||
- Using TianoCore + a PCIe GPU under Windows crashes with an
|
||||
ACPI_BIOS_ERROR fatal code, not sure why. Using just the IGP
|
||||
works perfectly
|
||||
|
||||
@ -105,9 +105,9 @@ easy to remove and reflash.
|
||||
|
||||
## Not working
|
||||
|
||||
- PS/2 keyboard in Win10 using edk2 (please see [Known issues])
|
||||
- PS/2 mouse using edk2
|
||||
- PCIe graphics card on Windows and edk2 (throws critical ACPI_BIOS_ERROR)
|
||||
- PS/2 keyboard in Win10 using Tianocore (please see [Known issues])
|
||||
- PS/2 mouse using Tianocore
|
||||
- PCIe graphics card on Windows and Tianocore (throws critical ACPI_BIOS_ERROR)
|
||||
|
||||
## Native raminit compatibility
|
||||
|
||||
|
@ -104,11 +104,11 @@ solution. Wires need to be connected to be able to flash using an external progr
|
||||
- SMBus
|
||||
- Initialization with FSP
|
||||
- SeaBIOS payload (commit a5cab58e9a3fb6e168aba919c5669bea406573b4)
|
||||
- edk2 payload (commit 860a8d95c2ee89c9916d6e11230f246afa1cd629)
|
||||
- TianoCore payload (commit 860a8d95c2ee89c9916d6e11230f246afa1cd629)
|
||||
- LinuxBoot (kernel kernel-4_19_97) (uroot commit 9c9db9dbd6b532f5f91a511a0de885c6562aadd7)
|
||||
- eMMC
|
||||
|
||||
All of the above has been briefly tested by booting Linux from eMMC using the edk2 payload
|
||||
All of the above has been briefly tested by booting Linux from eMMC using the TianoCore payload
|
||||
and LinuxBoot.
|
||||
|
||||
SeaBios has been checked to the extend that it runs to the boot selection and provides display
|
||||
|
@ -1,91 +0,0 @@
|
||||
# HP EliteBook 2170p
|
||||
|
||||
This page is about the notebook [HP EliteBook 2170p].
|
||||
|
||||
## Release status
|
||||
|
||||
HP EliteBook 2170p was released in 2012 and is now end of life.
|
||||
It can be bought from a secondhand market like Taobao or eBay.
|
||||
|
||||
## Required proprietary blobs
|
||||
|
||||
The following blobs are required to operate the hardware:
|
||||
1. EC firmware
|
||||
2. Intel ME firmware
|
||||
|
||||
EC firmware can be retrieved from the HP firmware update image, or the firmware
|
||||
backup of the laptop. EC Firmware is part of the coreboot build process.
|
||||
The guide on extracting EC firmware and using it to build coreboot is in
|
||||
document [HP Laptops with KBC1126 Embedded Controller](hp_kbc1126_laptops).
|
||||
|
||||
Intel ME firmware is in the flash chip. It is not needed when building coreboot.
|
||||
|
||||
## Programming
|
||||
|
||||
The flash chip is located between the memory slots, WWAN card and CPU,
|
||||
covered by the base enclosure, which needs to be removed according to
|
||||
the [Maintenance and Service Guide] to access the flash chip. Unlike
|
||||
other variants, the flash chip on 2170p is socketed, so it can be taken
|
||||
off and operated with an external programmer.
|
||||
|
||||
Pin 1 of the flash chip is at the side near the CPU.
|
||||
|
||||

|
||||
|
||||
For more details have a look at the general [flashing tutorial].
|
||||
|
||||
## Debugging
|
||||
|
||||
The board can be debugged with serial port on the dock or EHCI debug.
|
||||
The EHCI debug port is the left USB3 port.
|
||||
|
||||
## Test status
|
||||
|
||||
### Known issues
|
||||
|
||||
- GRUB payload freezes if at_keyboard module is in the GRUB image
|
||||
([bug #141])
|
||||
|
||||
### Untested
|
||||
|
||||
- Fingerprint Reader
|
||||
- Dock: Parallel port, PS/2 mouse, S-Video port
|
||||
|
||||
### Working
|
||||
|
||||
- Integrated graphics init with libgfxinit
|
||||
- SATA
|
||||
- Audio: speaker and microphone
|
||||
- Ethernet
|
||||
- WLAN
|
||||
- WWAN
|
||||
- Bluetooth
|
||||
- SD Card Reader
|
||||
- SmartCard Reader
|
||||
- USB
|
||||
- DisplayPort
|
||||
- Keyboard, touchpad and trackpoint
|
||||
- EC ACPI support and thermal control
|
||||
- Dock: all USB ports, DVI-D, Serial debug, PS/2 keyboard
|
||||
- TPM
|
||||
- Internal flashing when IFD is unlocked
|
||||
- Using `me_cleaner`
|
||||
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Sandy/Ivy Bridge (FCPGA988) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| PCH | Intel Panther Point QM77 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| EC | SMSC KBC1126 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[HP EliteBook 2170p]: https://support.hp.com/us-en/product/hp-elitebook-2170p-notebook-pc/5245427
|
||||
[Maintenance and Service Guide]: http://h10032.www1.hp.com/ctg/Manual/c03387961.pdf
|
||||
[flashing tutorial]: ../../tutorial/flashing_firmware/ext_power.md
|
Before Width: | Height: | Size: 50 KiB |
@ -14,99 +14,30 @@ The following things are still missing from this coreboot port:
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+-------------------------+
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+=========================+
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+-------------------------+
|
||||
| Model | MX25L6406E/MX25L6408E |
|
||||
+---------------------+-------------------------+
|
||||
+---------------------+------------+
|
||||
| Model | MX25L6406E |
|
||||
+---------------------+------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+-------------------------+
|
||||
+---------------------+------------+
|
||||
| In circuit flashing | yes |
|
||||
+---------------------+-------------------------+
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+-------------------------+
|
||||
| Write protection | bios region |
|
||||
+---------------------+-------------------------+
|
||||
+---------------------+------------+
|
||||
| Write protection | No |
|
||||
+---------------------+------------+
|
||||
| Dual BIOS feature | No |
|
||||
+---------------------+-------------------------+
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+-------------------------+
|
||||
```
|
||||
|
||||
### Flash layout
|
||||
The original layout of the flash should look like this:
|
||||
```
|
||||
00000000:00000fff fd
|
||||
00510000:007fffff bios
|
||||
00003000:0050ffff me
|
||||
00001000:00002fff gbe
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
### Internal programming
|
||||
|
||||
The SPI flash can be accessed using [flashrom].
|
||||
```console
|
||||
$ flashrom -p internal -c MX25L6406E/MX25L6408E -w coreboot.rom
|
||||
```
|
||||
|
||||
After shorting the FDO jumper you gain access to the full flash, but you
|
||||
still cannot write in the bios region due to SPI protected ranges.
|
||||
|
||||
**Position of FDO jumper close to the IO and second fan connector**
|
||||
![][compaq_8200_jumper]
|
||||
|
||||
[compaq_8200_jumper]: compaq_8200_sff_jumper.jpg
|
||||
|
||||
To write to the bios region you can use an [IFD Hack] originally developed
|
||||
for MacBooks, but with modified values described in this guide.
|
||||
You should read both guides before attempting the procedure.
|
||||
|
||||
Since you can still write in the flash descriptor, you can shrink
|
||||
the ME and then move the bios region into where the ME originally was.
|
||||
coreboot does not by default restrict writing to any part of the flash, so
|
||||
you will first flash a small coreboot build and after it boots, flash
|
||||
the full one.
|
||||
|
||||
The temporary flash layout with the neutered ME firmware should look like this:
|
||||
```
|
||||
00000000:00000fff fd
|
||||
00023000:001fffff bios
|
||||
00003000:00022fff me
|
||||
00001000:00002fff gbe
|
||||
00200000:007fffff pd
|
||||
```
|
||||
|
||||
It is very important to use these exact numbers or you will need to fix it
|
||||
using external flashing, but you should already be familiar with the risks
|
||||
if you got this far.
|
||||
|
||||
The temporary ROM chip size to set in menuconfig is 2 MB but the default
|
||||
CBFS size is too large for that, you can use up to about 0x1D0000.
|
||||
|
||||
When building both the temporary and the permanent installation, don't forget
|
||||
to also add the gigabit ethernet configuration when adding the flash descriptor
|
||||
and ME firmware.
|
||||
|
||||
You can pad the ROM to the required 8MB with zeros using:
|
||||
```console
|
||||
$ dd if=/dev/zero of=6M.bin bs=1024 count=6144
|
||||
$ cat coreboot.rom 6M.bin > coreboot8.rom
|
||||
```
|
||||
|
||||
If you want to continue using the neutered ME firmware use this flash layout
|
||||
for stage 2:
|
||||
```
|
||||
00000000:00000fff fd
|
||||
00023000:007fffff bios
|
||||
00003000:00022fff me
|
||||
00001000:00002fff gbe
|
||||
```
|
||||
|
||||
If you want to use the original ME firmware use the original flash layout.
|
||||
|
||||
More about flashing internally and getting the flash layout [here](../../tutorial/flashing_firmware/index.md).
|
||||
|
||||
### External programming
|
||||
|
||||
@ -143,7 +74,7 @@ as otherwise there's not enough space near the flash.
|
||||
| Coprocessor | Intel ME |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
[IFD Hack]: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/changes/70/38770/4/Documentation/flash_tutorial/int_macbook.md/
|
||||
|
||||
[Compaq 8200 Elite SFF]: https://support.hp.com/us-en/document/c03414707
|
||||
[HP]: https://www.hp.com/
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
||||
|
Before Width: | Height: | Size: 144 KiB |
@ -1,65 +0,0 @@
|
||||
# HP Compaq Elite 8300 USDT
|
||||
|
||||
This page describes how to run coreboot on the [Compaq Elite 8300 USDT] desktop
|
||||
from [HP].
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+-------------+
|
||||
| Type | Value |
|
||||
+=====================+=============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+-------------+
|
||||
| Model | W25Q128BVFG |
|
||||
+---------------------+-------------+
|
||||
| Size | 16 MiB |
|
||||
+---------------------+-------------+
|
||||
| In circuit flashing | yes |
|
||||
+---------------------+-------------+
|
||||
| Package | SOIC-16 |
|
||||
+---------------------+-------------+
|
||||
| Write protection | No |
|
||||
+---------------------+-------------+
|
||||
| Dual BIOS feature | No |
|
||||
+---------------------+-------------+
|
||||
```
|
||||
|
||||
### Internal programming
|
||||
|
||||
Internal programming is possible. Shorting the Flash Descriptor Override
|
||||
(FDO) jumper bypasses all write protections.
|
||||
|
||||
### External programming
|
||||
|
||||
Remove the lid. The flash chip can be found on the edge opposite to the CPU.
|
||||
There is a spot for a "ROM RCVRY" header next to the flash chip but it is
|
||||
unpopulated. If you don't feel like using a clip, you can easily solder
|
||||
a standard pin header there yourself and use it for programming.
|
||||
|
||||
Programming powers some parts of the board. Programming when
|
||||
Wake on LAN is active works great.
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | :doc:`../../northbridge/intel/sandybridge/index` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | bd82x6x |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | model_206ax |
|
||||
+------------------+--------------------------------------------------+
|
||||
| SuperIO | NPCD379HAKFX |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel ME |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
### SuperIO
|
||||
|
||||
This board has a Nuvoton NPCD379 SuperIO chip. Fan speed and PS/2 keyboard work
|
||||
fine using coreboot's existing code for :doc:`../../superio/nuvoton/npcd378`.
|
||||
|
||||
[Compaq Elite 8300 USDT]: https://support.hp.com/gb-en/product/hp-compaq-elite-8300-ultra-slim-pc/5232866
|
||||
[HP]: https://www.hp.com/
|
Before Width: | Height: | Size: 148 KiB |
@ -1,141 +0,0 @@
|
||||
# HP EliteBook 820 G2
|
||||
|
||||
This page is about the notebook [HP EliteBook 820 G2].
|
||||
|
||||
## Release status
|
||||
|
||||
HP EliteBook 820 G2 was released in 2015 and is now end of life.
|
||||
It can be bought from a secondhand market like Taobao or eBay.
|
||||
|
||||
## Required proprietary blobs
|
||||
|
||||
The following blobs are required to operate the hardware:
|
||||
|
||||
1. EC firmware
|
||||
2. Intel ME firmware
|
||||
3. Broadwell mrc.bin and refcode.elf
|
||||
|
||||
HP EliteBook 820 G2 uses SMSC MEC1324 as its embedded controller.
|
||||
The EC firmware is stored in the flash chip, but we don't need to touch it
|
||||
or use it in the coreboot build process.
|
||||
|
||||
Intel ME firmware is in the flash chip. It is not needed when building coreboot.
|
||||
|
||||
The Broadwell memory reference code binary and reference code blob is needed
|
||||
when building coreboot. Read the document [Blobs used in Intel Broadwell boards]
|
||||
on how to get these blobs.
|
||||
|
||||
## Programming
|
||||
|
||||
Before flashing, remove the battery and the hard drive cover according to the
|
||||
[Maintenance and Service Guide] of this laptop.
|
||||
|
||||
HP EliteBook 820 G2 has two flash chips, a 16MiB system flash, and a 2MiB
|
||||
private flash. To install coreboot, we need to program both flash chips.
|
||||
Read [HP Sure Start] for detailed information.
|
||||
|
||||

|
||||
|
||||
To access the system flash, we need to connect the AC adapter to the machine,
|
||||
then clip on the flash chip with an SOIC-8 clip. An [STM32-based flash programmer]
|
||||
made with an STM32 development board is tested to work.
|
||||
|
||||
To access the private flash chip, we can use a ch341a based flash programmer and
|
||||
flash the chip with the AC adapter disconnected.
|
||||
|
||||
To flash coreboot on a board running OME firmware, create a backup for both flash
|
||||
chips, then do the following:
|
||||
|
||||
1. Erase the private flash to disable the IFD protection
|
||||
2. Modify the IFD to shrink the BIOS region, so that we can put the firmware outside
|
||||
the protected flash region
|
||||
|
||||
To erase the private flash chip, attach it with the flash programmer via the SOIC-8 clip,
|
||||
then run:
|
||||
|
||||
flashrom -p <programmer> --erase
|
||||
|
||||
To modify the IFD, write the following flash layout to a file:
|
||||
|
||||
00000000:00000fff fd
|
||||
00001000:00002fff gbe
|
||||
00003000:005fffff me
|
||||
00600000:00bfffff bios
|
||||
00eb5000:00ffffff pd
|
||||
|
||||
Suppose the above layout file is ``layout.txt`` and the origin content of the system flash
|
||||
is in ``factory-sys.rom``, run:
|
||||
|
||||
ifdtool -n layout.txt factory-sys.rom
|
||||
|
||||
Then a flash image with a new IFD will be in ``factory-sys.rom.new``.
|
||||
|
||||
Flash the IFD of the system flash:
|
||||
|
||||
flashrom -p <programmer> --ifd -i fd -w factory-sys.rom.new
|
||||
|
||||
Then flash the coreboot image:
|
||||
|
||||
# first extend the 12M coreboot.rom to 16M
|
||||
fallocate -l 16M build/coreboot.rom
|
||||
flashrom -p <programmer> --ifd -i bios -w build/coreboot.rom
|
||||
|
||||
After coreboot is installed, the coreboot firmware can be updated with internal flashing:
|
||||
|
||||
flashrom -p internal --ifd -i bios --noverify-all -w build/coreboot.rom
|
||||
|
||||
## Debugging
|
||||
|
||||
The board can be debugged with EHCI debug. The EHCI debug port is the USB port on the left.
|
||||
|
||||
## Test status
|
||||
|
||||
### Untested
|
||||
|
||||
- NFC module
|
||||
- Fingerprint reader
|
||||
- Smart Card reader
|
||||
|
||||
### Working
|
||||
|
||||
- mainboards with i3-5010U, i5-5300U CPU, 16G+8G DDR3L memory
|
||||
- SATA and M.2 SATA disk
|
||||
- PCIe SSD
|
||||
- Webcam
|
||||
- Touch screen
|
||||
- Audio output from speaker and headphone jack
|
||||
- Intel GbE (needs a modified refcode documented in [Blobs used in Intel Broadwell boards])
|
||||
- WLAN
|
||||
- WWAN
|
||||
- SD card reader
|
||||
- Internal LCD, DisplayPort and VGA video outputs
|
||||
- Dock
|
||||
- USB
|
||||
- Keyboard and touchpad
|
||||
- EC ACPI
|
||||
- S3 resume
|
||||
- TPM
|
||||
- Arch Linux with Linux 5.11.16
|
||||
- Broadwell MRC version 2.6.0 Build 0 and refcode from Purism Librem 13 v1
|
||||
- Graphics initialization with libgfxinit
|
||||
- Payload: SeaBIOS 1.16.2
|
||||
- EC firmware: KBC Revision 96.54 from OEM firmware version 01.05
|
||||
- Internal flashing under coreboot
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+-----------------------------+
|
||||
| SoC | Intel Broadwell |
|
||||
+------------------+-----------------------------+
|
||||
| EC | SMSC MEC1324 |
|
||||
+------------------+-----------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+-----------------------------+
|
||||
```
|
||||
|
||||
[HP EliteBook 820 G2]: https://support.hp.com/us-en/product/HP-EliteBook-820-G2-Notebook-PC/7343192/
|
||||
[Blobs used in Intel Broadwell boards]: ../../soc/intel/broadwell/blobs.md
|
||||
[Maintenance and Service Guide]: http://h10032.www1.hp.com/ctg/Manual/c04775894.pdf
|
||||
[STM32-based flash programmer]: https://github.com/dword1511/stm32-vserprog
|
||||
[HP Sure Start]: hp_sure_start.md
|
Before Width: | Height: | Size: 84 KiB |
@ -130,7 +130,7 @@ The board can be debugged with EHCI debug. The EHCI debug port is the USB port o
|
||||
- Arch Linux with Linux 5.8.9
|
||||
- Memory initialization with mrc.bin version 1.6.1 Build 2
|
||||
- Graphics initialization with libgfxinit
|
||||
- Payload: SeaBIOS, edk2
|
||||
- Payload: SeaBIOS, Tianocore
|
||||
- EC firmware
|
||||
- KBC Revision 92.15 from OEM firmware version 01.33
|
||||
- KBC Revision 92.17 from OEM firmware version 01.50
|
||||
|
@ -44,17 +44,8 @@ The SPI flash can be accessed using [flashrom].
|
||||
External programming with an SPI adapter and [flashrom] does work, but it powers the
|
||||
whole southbridge complex. You need to supply enough current through the programming adapter.
|
||||
|
||||
If you want to use a SOIC pomona test clip, you have to cut the 2nd DRAM DIMM holder, as
|
||||
otherwise there's not enough space near the flash.
|
||||
|
||||
In both case, if ME has not been completely disabled, ME/AMT Flash Override jumper had better
|
||||
be temporary closed for flashing to disable the locking of regions, and prevent ME to run and
|
||||
interfere.
|
||||
|
||||
## Side note
|
||||
The mainboard of [HP Compaq Elite 8300 SFF] is very similar to the one of Z220 SFF, except
|
||||
that Compaq Elite 8300 uses Q77 instead of C216 for its PCH, and their boot firmwares are
|
||||
even interchangeable, so should do coreboot images built for them.
|
||||
If you want to use a SOIC pomona test clip, you have to cut the 2nd DRAM DIMM holder,
|
||||
as otherwise there's not enough space near the flash.
|
||||
|
||||
## Technology
|
||||
|
||||
@ -75,6 +66,5 @@ even interchangeable, so should do coreboot images built for them.
|
||||
```
|
||||
|
||||
[HP Z220 SFF Workstation]: https://support.hp.com/za-en/document/c03386950
|
||||
[HP Compaq Elite 8300 SFF]: https://support.hp.com/us-en/document/c03345460
|
||||
[HP]: https://www.hp.com/
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
||||
|
@ -11,7 +11,7 @@ This section contains documentation about coreboot on specific mainboards.
|
||||
- [G43T-AM3](acer/g43t-am3.md)
|
||||
|
||||
## AMD
|
||||
- [pademelon](amd/pademelon/pademelon.md)
|
||||
- [padmelon](amd/padmelon/padmelon.md)
|
||||
|
||||
## ASRock
|
||||
|
||||
@ -23,14 +23,11 @@ This section contains documentation about coreboot on specific mainboards.
|
||||
|
||||
- [A88XM-E](asus/a88xm-e.md)
|
||||
- [F2A85-M](asus/f2a85-m.md)
|
||||
- [P2B-LS](asus/p2b-ls.md)
|
||||
- [P3B-F](asus/p3b-f.md)
|
||||
- [P5Q](asus/p5q.md)
|
||||
- [P8C WS](asus/p8c_ws.md)
|
||||
- [P8H61-M LX](asus/p8h61-m_lx.md)
|
||||
- [P8H61-M Pro](asus/p8h61-m_pro.md)
|
||||
- [P8H77-V](asus/p8h77-v.md)
|
||||
- [P8Z77-M](asus/p8z77-m.md)
|
||||
- [P8Z77-M Pro](asus/p8z77-m_pro.md)
|
||||
- [P8Z77-V](asus/p8z77-v.md)
|
||||
- [wifigo_v1](asus/wifigo_v1.md)
|
||||
@ -75,23 +72,20 @@ The boards in this section are not real mainboards, but emulators.
|
||||
## HP
|
||||
|
||||
- [Compaq 8200 Elite SFF](hp/compaq_8200_sff.md)
|
||||
- [Compaq Elite 8300 USDT](hp/compaq_8300_usdt.md)
|
||||
- [Z220 Workstation SFF](hp/z220_sff.md)
|
||||
|
||||
### EliteBook series
|
||||
|
||||
- [HP Laptops with KBC1126 EC](hp/hp_kbc1126_laptops.md)
|
||||
- [HP Sure Start](hp/hp_sure_start.md)
|
||||
- [EliteBook 2170p](hp/2170p.md)
|
||||
- [EliteBook 2560p](hp/2560p.md)
|
||||
- [EliteBook 8760w](hp/8760w.md)
|
||||
- [EliteBook Folio 9480m](hp/folio_9480m.md)
|
||||
- [EliteBook 820 G2](hp/elitebook_820_g2.md)
|
||||
|
||||
## Intel
|
||||
|
||||
- [DG43GT](intel/dg43gt.md)
|
||||
- [DQ67SW](intel/dq67sw.md)
|
||||
- [IceLake RVP](intel/icelake_rvp.md)
|
||||
- [KBLRVP11](intel/kblrvp11.md)
|
||||
|
||||
## Kontron
|
||||
@ -125,7 +119,8 @@ The boards in this section are not real mainboards, but emulators.
|
||||
### Ivy Bridge series
|
||||
|
||||
- [T430](lenovo/t430.md)
|
||||
- [T530 / W530](lenovo/w530.md)
|
||||
- [T530](lenovo/w530.md)
|
||||
- [W530](lenovo/w530.md)
|
||||
- [T430 / T530 / X230 / W530 common](lenovo/Ivy_Bridge_series.md)
|
||||
- [T431s](lenovo/t431s.md)
|
||||
- [X230s](lenovo/x230s.md)
|
||||
@ -151,6 +146,7 @@ The boards in this section are not real mainboards, but emulators.
|
||||
## Open Cellular
|
||||
|
||||
- [Elgon](opencellular/elgon.md)
|
||||
- [Rotundu](opencellular/rotundu.md)
|
||||
|
||||
## PC Engines
|
||||
|
||||
@ -174,8 +170,6 @@ The boards in this section are not real mainboards, but emulators.
|
||||
|
||||
- [FW2B / FW4B](protectli/fw2b_fw4b.md)
|
||||
- [FW6A / FW6B / FW6C](protectli/fw6.md)
|
||||
- [VP2420](protectli/vp2420.md)
|
||||
- [VP4630 / VP4650 / VP4670](protectli/vp46xx.md)
|
||||
|
||||
## Roda
|
||||
|
||||
@ -192,7 +186,6 @@ The boards in this section are not real mainboards, but emulators.
|
||||
- [StarLite Mk III](starlabs/lite_glk.md)
|
||||
- [StarLite Mk IV](starlabs/lite_glkr.md)
|
||||
- [StarBook Mk V](starlabs/starbook_tgl.md)
|
||||
- [StarBook Mk VI](starlabs/starbook_adl.md)
|
||||
- [Flashing devices](starlabs/common/flashing.md)
|
||||
|
||||
## Supermicro
|
||||
@ -206,33 +199,19 @@ The boards in this section are not real mainboards, but emulators.
|
||||
|
||||
- [Adder Workstation 1](system76/addw1.md)
|
||||
- [Adder Workstation 2](system76/addw2.md)
|
||||
- [Adder Workstation 3](system76/addw3.md)
|
||||
- [Bonobo Workstation 14](system76/bonw14.md)
|
||||
- [Bonobo Workstation 15](system76/bonw15.md)
|
||||
- [Darter Pro 6](system76/darp6.md)
|
||||
- [Darter Pro 7](system76/darp7.md)
|
||||
- [Darter Pro 8](system76/darp8.md)
|
||||
- [Darter Pro 9](system76/darp9.md)
|
||||
- [Galago Pro 4](system76/galp4.md)
|
||||
- [Galago Pro 5](system76/galp5.md)
|
||||
- [Galago Pro 6](system76/galp6.md)
|
||||
- [Galago Pro 7](system76/galp7.md)
|
||||
- [Gazelle 15](system76/gaze15.md)
|
||||
- [Gazelle 16](system76/gaze16.md)
|
||||
- [Gazelle 17](system76/gaze17.md)
|
||||
- [Gazelle 18](system76/gaze18.md)
|
||||
- [Lemur Pro 9](system76/lemp9.md)
|
||||
- [Lemur Pro 10](system76/lemp10.md)
|
||||
- [Lemur Pro 11](system76/lemp11.md)
|
||||
- [Lemur Pro 12](system76/lemp12.md)
|
||||
- [Oryx Pro 5](system76/oryp5.md)
|
||||
- [Oryx Pro 6](system76/oryp6.md)
|
||||
- [Oryx Pro 7](system76/oryp7.md)
|
||||
- [Oryx Pro 8](system76/oryp8.md)
|
||||
- [Oryx Pro 9](system76/oryp9.md)
|
||||
- [Oryx Pro 10](system76/oryp10.md)
|
||||
- [Oryx Pro 11](system76/oryp11.md)
|
||||
- [Serval Workstation 13](system76/serw13.md)
|
||||
|
||||
## Texas Instruments
|
||||
|
||||
|
@ -1,170 +0,0 @@
|
||||
# Intel DQ67SW
|
||||
|
||||
The Intel DQ67SW is a microATX-sized desktop board for Intel Sandy Bridge CPUs.
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| Northbridge | :doc:`../../northbridge/intel/sandybridge/index` |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Southbridge | Intel Q67 (bd82x6x) |
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU socket | LGA 1155 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| RAM | 4 x DDR3-1333 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O | Nuvoton/Winbond W83677HG-i |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Audio | Realtek ALC888S |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Network | Intel 82579LM Gigabit Ethernet |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Serial | Internal header |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Status
|
||||
|
||||
### Working
|
||||
|
||||
- Sandy Bridge and Ivy Bridge CPUs (tested: i5-2500, Pentium G2120)
|
||||
- Native RAM initialization with four DIMMs
|
||||
- Integrated GPU with libgfxinit
|
||||
- PCIe graphics in the PEG slot
|
||||
- Additional PCIe slots
|
||||
- PCI slot
|
||||
- All rear (4x) and internal (8x) USB2 ports
|
||||
- Rear USB3 ports (2x)
|
||||
- All four internal SATA ports (two 6 Gb/s, two 3 Gb/s)
|
||||
- Two rear eSATA connectors (3 Gb/s)
|
||||
- SATA at 6 Gb/s
|
||||
- Gigabit Ethernet
|
||||
- SeaBIOS 1.16.1 + libgfxinit (legacy VGA) to boot slackware64 (Linux 5.15)
|
||||
- SeaBIOS 1.16.1 + extracted VGA BIOS to boot Windows 10 (21H2)
|
||||
- edk2 UefiPayload (uefipayload_202207) + libgfxinit (high-res) to boot:
|
||||
- slackware64 (Linux 5.15)
|
||||
- Windows 10 (22H2)
|
||||
- External in-circuit flashing with flashrom-1.2 and a Raspberry Pi 1
|
||||
- Poweroff
|
||||
- Resume from S3
|
||||
- Console output on the serial port
|
||||
|
||||
### Not working
|
||||
|
||||
- Automatic fan control. One can still use OS-based fan control programs,
|
||||
such as fancontrol on Linux or SpeedFan on Windows.
|
||||
- Windows 10 booted from SeaBIOS + libgfxinit (high-res). The installation
|
||||
works, but once Windows Update installs drivers, it crashes and enters a
|
||||
bootloop.
|
||||
|
||||
### Untested
|
||||
|
||||
- Firewire (LSI L-FW3227-100)
|
||||
- EHCI debug
|
||||
- S/PDIF audio
|
||||
- Audio jacks other than the green one
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q64.V |
|
||||
+---------------------+------------+
|
||||
| Size | 8 MiB |
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+------------+
|
||||
| Write protection | yes |
|
||||
+---------------------+------------+
|
||||
| Dual BIOS feature | no |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | see below |
|
||||
+---------------------+------------+
|
||||
| In circuit flashing | see below |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
The flash is divided into the following regions, as obtained with
|
||||
`ifdtool -f rom.layout backup.rom`:
|
||||
|
||||
00000000:00000fff fd
|
||||
00580000:007fffff bios
|
||||
00003000:0057ffff me
|
||||
00001000:00002fff gbe
|
||||
|
||||
Unfortunately the SPI interface to the chip is locked down by the vendor
|
||||
firmware. The BIOS Lock Enable (BLE) bit of the `BIOS_CNTL` register, part of
|
||||
the PCI configuration space of the LPC Interface Bridge, is set.
|
||||
|
||||
It is possible to program the chip is to attach an external programmer
|
||||
with an SOIC-8 clip.
|
||||
|
||||
```eval_rst
|
||||
Another way is to boot the vendor firmware in UEFI mode and exploit the
|
||||
unpatched S3 Boot Script vulnerability. See this page for a similar procedure:
|
||||
:doc:`../lenovo/ivb_internal_flashing`.
|
||||
```
|
||||
|
||||
On this specific board it is possible to prevent the BLE bit from being set
|
||||
when it resumes from S3. One entry in the S3 Boot Script must be modified,
|
||||
e.g. with a patched version of [CHIPSEC](https://github.com/chipsec/chipsec)
|
||||
that supports this specific type of S3 Boot Script, for example from strobo5:
|
||||
|
||||
$ git clone -b headerless https://github.com/strobo5/chipsec.git
|
||||
$ cd chipsec
|
||||
$ python setup.py build_ext -i
|
||||
$ sudo python chipsec_main.py -m tools.uefi.s3script_modify -a replace_op,mmio_wr,0xe00f80dc,0x00,1
|
||||
|
||||
The boot script contains an entry that writes 0x02 to memory at address
|
||||
0xe00f80dc. This address points at the PCIe configuration register at offset
|
||||
0xdc for the PCIe device 0:1f.0, which is the BIOS Control Register of the LPC
|
||||
Interface Bridge [0][1]. The value 0x02 sets the BLE bit, and the modification
|
||||
prevents this by making it write a 0 instead.
|
||||
|
||||
```eval_rst
|
||||
After suspending and resuming the board, the BIOS region can be flashed with
|
||||
a coreboot image, e.g. using flashrom. Note that the ME region is not readable,
|
||||
so the `--noverify-all` flag is necessary. Please refer to the
|
||||
:doc:`../../tutorial/flashing_firmware/index`.
|
||||
```
|
||||
|
||||
## Hardware monitoring and fan control
|
||||
|
||||
Currently there is no automatic, OS-independent fan control.
|
||||
|
||||
## Serial port header
|
||||
|
||||
Serial port 1, provided by the Super I/O, is exposed on a pin header. The
|
||||
RS-232 signals are assigned to the header so that its pin numbers map directly
|
||||
to the pin numbers of a DE-9 connector. If your serial port doesn't seem to
|
||||
work, check if your bracket expects a different assignment.
|
||||
|
||||
Here is a top view of the serial port header found on this board:
|
||||
|
||||
+---+---+
|
||||
N/C | | 9 | RI -> pin 9
|
||||
+---+---+
|
||||
Pin 8 <- CTS | 8 | 7 | RTS -> pin 7
|
||||
+---+---+
|
||||
Pin 6 <- DSR | 6 | 5 | GND -> pin 5
|
||||
+---+---+
|
||||
Pin 4 <- DTR | 4 | 3 | TxD -> pin 3
|
||||
+---+---+
|
||||
Pin 2 <- RxD | 2 | 1 | DCD -> pin 1
|
||||
+---+---+
|
||||
|
||||
## References
|
||||
|
||||
[0]: Intel 6 Series Chipset and Intel C200 Series Chipset Datasheet,
|
||||
May 2011,
|
||||
Document number 324645-006
|
||||
|
||||
[1]: Accessing PCI Express Configuration Registers Using Intel Chipsets,
|
||||
December 2008,
|
||||
Document number 321090
|
||||
|
40
Documentation/mainboard/intel/icelake_rvp.md
Normal file
@ -0,0 +1,40 @@
|
||||
# Intel Ice Lake RVP (Reference Validation Platform)
|
||||
|
||||
This page describes how to run coreboot on the Intel icelake_rvp board.
|
||||
|
||||
Ice Lake RVP is based on Intel Ice Lake platform, please refer to below link to get more details
|
||||
```eval_rst
|
||||
:doc:`../../soc/intel/icelake/iceLake_coreboot_development`
|
||||
```
|
||||
|
||||
## Building coreboot
|
||||
|
||||
* Follow build instructions mentioned in Ice Lake document
|
||||
```eval_rst
|
||||
:doc:`../../soc/intel/icelake/iceLake_coreboot_development`
|
||||
```
|
||||
|
||||
* The default options for this board should result in a fully working image:
|
||||
```bash
|
||||
# echo "CONFIG_VENDOR_INTEL=y" > .config
|
||||
# echo "CONFIG_BOARD_INTEL_ICELAKE_RVPU=y" >> .config
|
||||
# make olddefconfig && make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Vendor | Winbond |
|
||||
+---------------------+------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
@ -45,7 +45,7 @@ make
|
||||
```
|
||||
## Payloads
|
||||
- SeaBIOS
|
||||
- edk2
|
||||
- Tianocore
|
||||
- Linux as payload
|
||||
|
||||
## Flashing coreboot
|
||||
|
@ -26,12 +26,12 @@ host up to 4 Delta Lake servers (blades) in one sled.
|
||||
|
||||
The Yosemite-V3 system is in mass production. Meta, Intel and partners
|
||||
jointly develop Open System Firmware (OSF) solution on Delta Lake as an alternative
|
||||
solution. The OSF solution reached production quality for some use cases
|
||||
in July, 2021.
|
||||
solution. The OSF solution is based on FSP/coreboot/LinuxBoot stack. The
|
||||
OSF solution reached production quality for some use cases in July, 2021.
|
||||
|
||||
## How to build
|
||||
|
||||
OSF code base is publicly available at
|
||||
OSF code base is public at
|
||||
https://github.com/opencomputeproject/OpenSystemFirmware
|
||||
|
||||
Run following commands to build Delta Lake OSF image from scratch:
|
||||
@ -42,21 +42,19 @@ The Delta Lake OSF code base leverages [osf-builder] to sync down coreboot,
|
||||
Linux kernel and u-root code from their upstream repo, and sync down needed
|
||||
binary blobs. [osf-builder] also provides the top level build system.
|
||||
|
||||
Besides coreboot, the Delta Lake OSF solution includes following components:
|
||||
- FSP blob: The blobs (Intel Cooper Lake Scalable Processor Firmware Support Package)
|
||||
is downloaded from https://github.com/intel/FSP/tree/master/CedarIslandFspBinPkg.
|
||||
- Microcode: downloaded from github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.
|
||||
- ME ignition binary: downloaded from
|
||||
Delta Lake server OSF solution requires following binary blobs:
|
||||
- FSP blob: The blob (Intel Cooper Lake Scalable Processor Firmware Support Package)
|
||||
can be downloaded from https://github.com/intel/FSP/tree/master/CedarIslandFspBinPkg.
|
||||
- Microcode: Available through github.com/intel/Intel-Linux-Processor-Microcode-Data-Files.
|
||||
coreboot.org mirrors this repo and by default the correct binary is included.
|
||||
- ME binary: Ignition binary can be downloaded from
|
||||
https://github.com/tianocore/edk2-non-osi/tree/master/Silicon/Intel/PurleySiliconBinPkg/MeFirmware
|
||||
- ACM binaries: only required for CBnT enablement. Available under NDA with Intel.
|
||||
- Payload: LinuxBoot is necessary when LinuxBoot is used as the coreboot payload.
|
||||
U-root as initramfs, is used in the joint development. It is built
|
||||
U-root as initramfs, is used in the joint development. It can be built
|
||||
following [All about u-root].
|
||||
|
||||
The Delta Lake OSF solution is updated periodically to newer versions of
|
||||
upstream coreboot code base and other components.
|
||||
|
||||
## How to verify Delta Lake OSF image
|
||||
## Flashing coreboot
|
||||
|
||||
To do in-band FW image update, use [flashrom]:
|
||||
flashrom -p internal:ich_spi_mode=hwseq -c "Opaque flash chip" --ifd \
|
||||
@ -72,21 +70,6 @@ To power off/on the host:
|
||||
To connect to console through SOL (Serial Over Lan):
|
||||
sol-util slotx
|
||||
|
||||
## How to work on coreboot for Delta Lake
|
||||
After the OSF image for Delta Lake is built and verified, under
|
||||
OpenSystemFirmware/Wiwynn/deltalake directory:
|
||||
cd src/osf-builder/projects/craterlake/coreboot
|
||||
|
||||
Run "git remote -v" to confirm the origin is from coreboot upstream repo.
|
||||
|
||||
Run "git branch -v" to know the confirmed working coreboot commit ID for the
|
||||
Delta Lake OSF solution.
|
||||
|
||||
Fetch down the tip of coreboot upstream repo, run "make" to build a new OSF
|
||||
image for Delta Lake, verify that it works.
|
||||
|
||||
Now you are in a familiar coreboot environment, happy coding!
|
||||
|
||||
## Firmware configurations
|
||||
[ChromeOS VPD] is used to store most of the firmware configurations.
|
||||
RO_VPD region holds default values, while RW_VPD region holds customized
|
||||
|
76
Documentation/mainboard/opencellular/rotundu.md
Normal file
@ -0,0 +1,76 @@
|
||||
# Rutundu
|
||||
|
||||
This page describes how to run coreboot on the [Rotundu] compute board
|
||||
from [OpenCellular].
|
||||
|
||||
## TODO
|
||||
|
||||
* Configure UART
|
||||
* EC interface
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q128 |
|
||||
+---------------------+------------+
|
||||
| Size | 16 MiB |
|
||||
+---------------------+------------+
|
||||
| In circuit flashing | yes |
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+------------+
|
||||
| Write protection | No |
|
||||
+---------------------+------------+
|
||||
| Dual BIOS feature | No |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
### Internal programming
|
||||
|
||||
The SPI flash can be accessed using [flashrom].
|
||||
|
||||
### External programming
|
||||
|
||||
The GBCv1 board does have a pinheader to flash the SOIC-8 in circuit.
|
||||
Directly connecting a Pomona test-clip on the flash is also possible.
|
||||
|
||||
**Closeup view of SOIC-8 flash IC**
|
||||
|
||||
![][rotundu_flash]
|
||||
|
||||
[rotundu_flash]: rotundu_flash.jpg
|
||||
|
||||
**SPI header**
|
||||
|
||||
![][rotundu_header2]
|
||||
|
||||
[rotundu_header2]: rotundu_header2.jpg
|
||||
|
||||
**SPI header pinout**
|
||||
|
||||
Dediprog compatible pinout.
|
||||
|
||||
![][rotundu_j16]
|
||||
|
||||
[rotundu_j16]: rotundu_j16.png
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| SoC | Intel Baytrail |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel ME |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
[Rotundu]: https://github.com/Telecominfraproject/OpenCellular
|
||||
[OpenCellular]: https://code.fb.com/connectivity/introducing-opencellular-an-open-source-wireless-access-platform/
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
BIN
Documentation/mainboard/opencellular/rotundu_flash.jpg
Normal file
After Width: | Height: | Size: 92 KiB |
BIN
Documentation/mainboard/opencellular/rotundu_header2.jpg
Normal file
After Width: | Height: | Size: 55 KiB |
BIN
Documentation/mainboard/opencellular/rotundu_j16.png
Normal file
After Width: | Height: | Size: 20 KiB |
Before Width: | Height: | Size: 40 KiB |
Before Width: | Height: | Size: 47 KiB |
Before Width: | Height: | Size: 74 KiB |
@ -1,87 +0,0 @@
|
||||
# Protectli Vault VP2420
|
||||
|
||||
This page describes how to run coreboot on the [Protectli VP2420].
|
||||
|
||||

|
||||

|
||||
|
||||
## Required proprietary blobs
|
||||
|
||||
To build a minimal working coreboot image some blobs are required (assuming
|
||||
only the BIOS region is being modified).
|
||||
|
||||
```eval_rst
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
| Binary file | Apply | Required / Optional |
|
||||
+=================+=================================+=====================+
|
||||
| FSP-M, FSP-S | Intel Firmware Support Package | Required |
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
| microcode | CPU microcode | Required |
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
```
|
||||
|
||||
FSP-M and FSP-S are obtained after splitting the Elkhart Lake FSP binary (done
|
||||
automatically by the coreboot build system and included into the image) from
|
||||
the `3rdparty/fsp` submodule.
|
||||
|
||||
Microcode updates are automatically included into the coreboot image by build
|
||||
system from the `3rdparty/intel-microcode` submodule.
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash can be accessed using [flashrom]. Firmware can be easily
|
||||
flashed with internal programmer (either BIOS region or full image).
|
||||
|
||||
### External programming
|
||||
|
||||
The system has an internal flash chip which is a 16 MiB soldered SOIC-8 chip.
|
||||
This chip is located on the top side of the case (the lid side). One has to
|
||||
remove 4 top cover screws and lift up the lid. The flash chip is soldered in
|
||||
under RAM, easily accessed after taking out the memory. Specifically, it's a
|
||||
KH25L12835F (3.3V) which is a clone of Macronix
|
||||
MX25L12835F - [datasheet][MX25L12835F].
|
||||
|
||||

|
||||
|
||||
## Working
|
||||
|
||||
- USB 3.0 front ports (SeaBIOS, Tianocore UEFIPayload and Linux)
|
||||
- 4 Ethernet ports
|
||||
- HDMI, DisplayPort
|
||||
- flashrom
|
||||
- M.2 WiFi
|
||||
- M.2 4G LTE
|
||||
- M.2 SATA and NVMe
|
||||
- 2.5'' SATA SSD
|
||||
- eMMC
|
||||
- Super I/O serial port 0 via front microUSB connector
|
||||
- SMBus (reading SPD from DIMMs)
|
||||
- Initialization with Elkhart Lake FSP 2.0
|
||||
- SeaBIOS payload (version rel-1.16.0)
|
||||
- TianoCore UEFIPayload
|
||||
- Reset switch
|
||||
- Booting Debian, Ubuntu, FreeBSD
|
||||
|
||||
## Technology
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Celeron J6412 |
|
||||
+------------------+--------------------------------------------------+
|
||||
| PCH | Intel Elkhart Lake |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O, EC | ITE IT8613E |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Useful links
|
||||
|
||||
- [VP2420 Hardware Overview](https://protectli.com/kb/vp2400-series-hardware-overview/)
|
||||
- [VP2420 Product Page](https://protectli.com/product/vp2420/)
|
||||
- [Protectli TPM module](https://protectli.com/product/tpm-module/)
|
||||
- [MX25L12835F](https://www.mxic.com.tw/Lists/Datasheet/Attachments/8653/MX25L12835F,%203V,%20128Mb,%20v1.6.pdf)
|
||||
- [flashrom](https://flashrom.org/Flashrom)
|
@ -1,135 +0,0 @@
|
||||
# Protectli Vault VP46xx series
|
||||
|
||||
This page describes how to run coreboot on the [Protectli VP46xx].
|
||||
|
||||

|
||||

|
||||
|
||||
## Required proprietary blobs
|
||||
|
||||
To build a minimal working coreboot image some blobs are required (assuming
|
||||
only the BIOS region is being modified).
|
||||
|
||||
```eval_rst
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
| Binary file | Apply | Required / Optional |
|
||||
+=================+=================================+=====================+
|
||||
| FSP-M, FSP-S | Intel Firmware Support Package | Required |
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
| microcode | CPU microcode | Required |
|
||||
+-----------------+---------------------------------+---------------------+
|
||||
```
|
||||
|
||||
FSP-M and FSP-S are obtained after splitting the Comet Lake FSP binary (done
|
||||
automatically by the coreboot build system and included into the image) from
|
||||
the `3rdparty/fsp` submodule. VP4630 and VP4650 use CometLake2 FSP and VP4670
|
||||
use CometLake1 FSP (see [variants](#variants) section), so be sure to select
|
||||
the correct board in the coreboot's menuconfig, otherwise the platform will not
|
||||
succeed on memory initialization.
|
||||
|
||||
Microcode updates are automatically included into the coreboot image by build
|
||||
system from the `3rdparty/intel-microcode` submodule.
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
### Internal programming
|
||||
|
||||
The main SPI flash can be accessed using [flashrom]. The first version
|
||||
supporting the chipset is flashrom v1.2. Firmware an be easily flashed
|
||||
with internal programmer (either BIOS region or full image).
|
||||
|
||||
### External programming
|
||||
|
||||
The system has an internal flash chip which is a 16 MiB socketed SOIC-8 chip.
|
||||
This chip is located on the top side of the case (the lid side). One has to
|
||||
remove 4 top cover screws and lift up the lid. The flash chip is near the M.2
|
||||
WiFi slot connector. Remove the chip from socket and use a clip to program the
|
||||
chip. Specifically, it's a KH25L12835F (3.3V) which is a clone of Macronix
|
||||
MX25L12835F - [datasheet][MX25L12835F].
|
||||
|
||||

|
||||
|
||||
## Known issues
|
||||
|
||||
- After flashing with external programmer it is always required to reset RTC
|
||||
with a jumper or disconnect the coin cell temporarily. Only then the platform
|
||||
will boot after flashing.
|
||||
|
||||
## Working
|
||||
|
||||
- USB 3.0 front ports (SeaBIOS, Tianocore UEFIPayload and Linux)
|
||||
- 6 Ethernet ports
|
||||
- HDMI, DisplayPort and USB-C Display Port with libgfxinit and FSP GOP
|
||||
- flashrom
|
||||
- M.2 WiFi
|
||||
- M.2 4G LTE
|
||||
- M.2 SATA and NVMe
|
||||
- 2.5'' SATA SSD
|
||||
- eMMC
|
||||
- Super I/O serial port 0 via front microUSB connector (Fintek F81232 USB to
|
||||
UART adapter present on board)
|
||||
- SMBus (reading SPD from DIMMs)
|
||||
- Initialization with CometLake FSP 2.0
|
||||
- SeaBIOS payload (version rel-1.16.0)
|
||||
- TianoCore UEFIPayload
|
||||
- LPC TPM module (using Protectli custom-designed module with Infineon SLB9660)
|
||||
- Reset switch
|
||||
- Booting Debian, Ubuntu, FreeBSD
|
||||
|
||||
## Variants
|
||||
|
||||
There are 3 variants of VP46xx boards: VP4630, VP4650 and VP4670. They differ
|
||||
only in used SoC and some units may come with different Super I/O chips, either
|
||||
ITE IT8786E or IT8784E, but the configuration is the same on this platform.
|
||||
|
||||
- VP4630:
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Core i3-10110U |
|
||||
+------------------+--------------------------------------------------+
|
||||
| PCH | Intel Comet Lake U Premium |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O, EC | ITE IT8786E/IT8784E |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
- VP4650:
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Core i5-10210U |
|
||||
+------------------+--------------------------------------------------+
|
||||
| PCH | Intel Comet Lake U Premium |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O, EC | ITE IT8786E/IT8784E |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
- VP4670:
|
||||
|
||||
```eval_rst
|
||||
+------------------+--------------------------------------------------+
|
||||
| CPU | Intel Core i7-10810U |
|
||||
+------------------+--------------------------------------------------+
|
||||
| PCH | Intel Comet Lake U Premium |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Super I/O, EC | ITE IT8786E/IT8784E |
|
||||
+------------------+--------------------------------------------------+
|
||||
| Coprocessor | Intel Management Engine |
|
||||
+------------------+--------------------------------------------------+
|
||||
```
|
||||
|
||||
## Useful links
|
||||
|
||||
- [VP4600 Hardware Overview](https://protectli.com/kb/vp4600-hardware-overview/)
|
||||
- [VP4630 Product Page](https://protectli.com/product/vp4630/)
|
||||
- [Protectli TPM module](https://protectli.com/product/tpm-module/)
|
||||
|
||||
[Protectli VP46xx]: https://protectli.com/vault-6-port/
|
||||
[MX25L12835F]: https://www.mxic.com.tw/Lists/Datasheet/Attachments/8653/MX25L12835F,%203V,%20128Mb,%20v1.6.pdf
|
||||
[flashrom]: https://flashrom.org/Flashrom
|
Before Width: | Height: | Size: 37 KiB |
Before Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 35 KiB |
@ -92,7 +92,7 @@ located underneath the Wi-Fi module, below the left cooling fan.
|
||||
|
||||
* Internal display with libgfxinit, VGA option ROM, or FSP/GOP init
|
||||
* External displays via HDMI, USB-C Alt-Mode
|
||||
* SeaBIOS (1.14), edk2 (CorebootPayloadPkg), and Heads payloads
|
||||
* SeaBIOS (1.14), Tianocore (CorebootPayloadPkg), and Heads payloads
|
||||
* Ethernet, m.2 2230 Wi-Fi
|
||||
* System firmware updates via flashrom
|
||||
* M.2 storage (NVMe, SATA III)
|
||||
|
@ -107,7 +107,7 @@ desoldering it from the mainboard.
|
||||
|
||||
* External displays via HDMI/DisplayPort with VGA option ROM or FSP/GOP init
|
||||
(no libgfxinit support yet)
|
||||
* SeaBIOS (1.14), edk2 (CorebootPayloadPkg), Heads (Purism downstream) payloads
|
||||
* SeaBIOS (1.14), Tianocore (CorebootPayloadPkg), Heads (Purism downstream) payloads
|
||||
* Ethernet, m.2 2230 Wi-Fi
|
||||
* System firmware updates via flashrom
|
||||
* PCIe NVMe
|
||||
|
@ -1,30 +0,0 @@
|
||||
## Building coreboot
|
||||
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
|
||||
#### StarBook series:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* Intel Management Engine firmware (me.bin)
|
||||
* ITE Embedded Controller firmware (ec.bin)
|
||||
|
||||
#### StarLite series:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* IFWI Image (ifwi.rom)
|
||||
|
||||
The files listed below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the [StarLabsLtd/blobs](https://github.com/StarLabsLtd/blobs) repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image, where the last two words represent the
|
||||
series and processor i.e. `lite_glkr`:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_starbook_adl
|
||||
make
|
||||
```
|
@ -41,7 +41,27 @@
|
||||
|
||||
## Building coreboot
|
||||
|
||||
Please follow the [Star Labs build instructions](common/building.md) to build coreboot, using `config.starlabs_labtop_cml` as config file.
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* Intel Management Engine firmware (me.bin)
|
||||
* ITE Embedded Controller firmware (ec.bin)
|
||||
|
||||
The files listed below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_labtop_cml
|
||||
make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
@ -63,6 +83,5 @@ Please follow the [Star Labs build instructions](common/building.md) to build co
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
Please see [here](common/flashing.md) for instructions on how to flash with fwupd.
|
||||
Please see [here](../common/flashing.md) for instructions on how to flash with fwupd.
|
||||
|
@ -38,7 +38,26 @@
|
||||
|
||||
## Building coreboot
|
||||
|
||||
Please follow the [Star Labs build instructions](common/building.md) to build coreboot, using `config.starlabs_labtop_kbl` as config file.
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* Intel Management Engine firmware (me.bin)
|
||||
|
||||
The below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_labtop_kbl
|
||||
make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
@ -60,6 +79,5 @@ Please follow the [Star Labs build instructions](common/building.md) to build co
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
Please see [here](common/flashing.md) for instructions on how to flash with fwupd.
|
||||
Please see [here](../common/flashing.md) for instructions on how to flash with fwupd.
|
||||
|
@ -37,7 +37,27 @@
|
||||
|
||||
## Building coreboot
|
||||
|
||||
Please follow the [Star Labs build instructions](common/building.md) to build coreboot, using `config.starlabs_lite_glk` as config file.
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* Intel Management Engine firmware (me.bin)
|
||||
* ITE Embedded Controller firmware (ec.bin)
|
||||
|
||||
The files listed below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_lite_glk
|
||||
make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
@ -59,6 +79,5 @@ Please follow the [Star Labs build instructions](common/building.md) to build co
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
Please see [here](common/flashing.md) for instructions on how to flash with fwupd.
|
||||
Please see [here](../common/flashing.md) for instructions on how to flash with fwupd.
|
||||
|
@ -37,7 +37,26 @@
|
||||
|
||||
## Building coreboot
|
||||
|
||||
Please follow the [Star Labs build instructions](common/building.md) to build coreboot, using `config.starlabs_lite_glkr` as config file.
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* IFWI Image (ifwi.rom)
|
||||
|
||||
The files listed below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_lite_glkr
|
||||
make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
@ -59,6 +78,5 @@ Please follow the [Star Labs build instructions](common/building.md) to build co
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
Please see [here](common/flashing.md) for instructions on how to flash with fwupd.
|
||||
Please see [here](../common/flashing.md) for instructions on how to flash with fwupd.
|
||||
|
@ -1,101 +0,0 @@
|
||||
# StarBook Mk V
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU (full processor specs available at https://ark.intel.com)
|
||||
- Intel i7-1260P (Alder Lake)
|
||||
- Intel i3-1220P (Alder Lake)
|
||||
- Intel i3-1315U (Raptor Lake)
|
||||
- Intel i7-1360P (Raptor Lake)
|
||||
- EC
|
||||
- ITE IT5570E
|
||||
- Backlit keyboard, with standard PS/2 keycodes and SCI hotkeys
|
||||
- Battery
|
||||
- Charger, using AC adapter or USB-C PD
|
||||
- Suspend / resume
|
||||
- GPU
|
||||
- Intel® Iris® Xe Graphics
|
||||
- GOP driver is recommended, VBT is provided
|
||||
- eDP 14-inch 1920x1080 LCD
|
||||
- HDMI video
|
||||
- USB-C DisplayPort video
|
||||
- Memory
|
||||
- 2 x DDR4 SODIMM
|
||||
- Networking
|
||||
- AX210 2230 WiFi / Bluetooth
|
||||
- Sound
|
||||
- Realtek ALC269-VB6
|
||||
- Internal speakers
|
||||
- Internal microphone
|
||||
- Combined headphone / microphone 3.5-mm jack
|
||||
- HDMI audio
|
||||
- USB-C DisplayPort audio
|
||||
- Storage
|
||||
- M.2 PCIe SSD
|
||||
- RTS5129 MicroSD card reader
|
||||
- USB
|
||||
- 1920x1080 CCD camera
|
||||
- USB 3.1 Gen 2 (left) (Alder Lake)
|
||||
- Thunderbolt 4.0 (left) (Raptor Lake)
|
||||
- USB 3.1 Gen 2 Type-A (left)
|
||||
- USB 3.1 Gen 1 Type-A (right)
|
||||
- USB 2.0 Type-A (right)
|
||||
|
||||
## Building coreboot
|
||||
|
||||
Please follow the [Star Labs build instructions](common/building.md) to build coreboot, using `config.starlabs_starbook_adl` as config file.
|
||||
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* Intel Management Engine firmware (me.bin)
|
||||
* ITE Embedded Controller firmware (ec.bin)
|
||||
|
||||
The files listed below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image:
|
||||
|
||||
|
||||
Alder Lake:
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_starbook_adl
|
||||
make
|
||||
```
|
||||
|
||||
Raptor Lake:
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_starbook_rpl
|
||||
make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+------------+
|
||||
| Type | Value |
|
||||
+=====================+============+
|
||||
| Socketed flash | no |
|
||||
+---------------------+------------+
|
||||
| Vendor | Winbond |
|
||||
+---------------------+------------+
|
||||
| Model | W25Q256.V |
|
||||
+---------------------+------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+------------+
|
||||
| Package | SOIC-8 |
|
||||
+---------------------+------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
Please see [here](common/flashing.md) for instructions on how to flash with fwupd.
|
@ -40,7 +40,27 @@
|
||||
|
||||
## Building coreboot
|
||||
|
||||
Please follow the [Star Labs build instructions](common/building.md) to build coreboot, using `config.starlabs_starbook_tgl` as config file.
|
||||
### Preliminaries
|
||||
|
||||
Prior to building coreboot the following files are required:
|
||||
* Intel Flash Descriptor file (descriptor.bin)
|
||||
* Intel Management Engine firmware (me.bin)
|
||||
* ITE Embedded Controller firmware (ec.bin)
|
||||
|
||||
The files listed below are optional:
|
||||
- Splash screen image in Windows 3.1 BMP format (Logo.bmp)
|
||||
|
||||
These files exist in the correct location in the StarLabsLtd/blobs repo on GitHub which is used in place of the standard 3rdparty/blobs repo.
|
||||
|
||||
### Build
|
||||
|
||||
The following commands will build a working image:
|
||||
|
||||
```bash
|
||||
make distclean
|
||||
make defconfig KBUILD_DEFCONFIG=configs/config.starlabs_starbook_tgl
|
||||
make
|
||||
```
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
@ -62,6 +82,5 @@ Please follow the [Star Labs build instructions](common/building.md) to build co
|
||||
+---------------------+------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+------------+
|
||||
```
|
||||
|
||||
Please see [here](common/flashing.md) for instructions on how to flash with fwupd.
|
||||
Please see [here](../common/flashing.md) for instructions on how to flash with fwupd.
|
||||
|
@ -1,71 +0,0 @@
|
||||
# System76 Adder Workstation 3 (addw3)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i9-13900HX
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- dGPU options
|
||||
- NVIDIA GeForce RTX 4050
|
||||
- NVIDIA GeForce RTX 4060
|
||||
- NVIDIA GeForce RTX 4070
|
||||
- eDP displays
|
||||
- 15.6" 1920x1080@144Hz LCD
|
||||
- 17.3" 1920x1080@144Hz LCD
|
||||
- External outputs
|
||||
- 1x HDMI 2.1
|
||||
- 1x Mini DisplayPort 1.4
|
||||
- 1x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR5 SO-DIMMs @ 4800 MHz
|
||||
- Networking
|
||||
- Intel I219-V gigabit Ethernet
|
||||
- M.2 PCIe/CNVi WiFi/Bluetooth
|
||||
- Intel Wi-Fi 6E AX210/AX211
|
||||
- Power
|
||||
- 280W (20V, 14A) DC-in port
|
||||
- Included: Chicony A18-280P1A
|
||||
- 73Wh 4-cell Lithium-Ion battery
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone/microphone jack
|
||||
- Dedicated 3.5mm microphone jack
|
||||
- HDMI, mDP, USB-C DP audio
|
||||
- Storage
|
||||
- 2x M.2 (PCIe NVMe Gen 4) SSDs
|
||||
- MicroSD card reader
|
||||
- USB
|
||||
- 1x USB Type-C with Thunderbolt 4
|
||||
- 1x USB 3.2 Gen 2 Type-C
|
||||
- 1x USB 3.2 Gen 1 Type-A
|
||||
- 1x USB 2.0 Type-A
|
||||
- Dimensions
|
||||
- 15": 2.71cm x 35.95cm x 23.8cm, 2.05kg
|
||||
- 17": 2.82cm x 39.69cm x 26.2cm, 2.85kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | GigaDevice |
|
||||
+---------------------+---------------------+
|
||||
| Model | GD25B256E |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U65) is above the battery connector.
|
@ -1,65 +0,0 @@
|
||||
# System76 Bonobo Workstation 15 (bonw15)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i9-13900HX
|
||||
- Chipset
|
||||
- Intel HM770
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- dGPU options:
|
||||
- NVIDIA GeForce RTX 4080
|
||||
- NVIDIA GeForce RTX 4090
|
||||
- eDP 17.3" 3840x2160@144Hz LCD (BOE NE173QUM-NY1)
|
||||
- 1x HDMI 2.1
|
||||
- 1x Mini DisplayPort 1.4
|
||||
- 2x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR5 SO-DIMMs @ 5200 Mhz
|
||||
- Networking
|
||||
- Onboard Intel Killer Ethernet E3100X 2.5 GbE
|
||||
- M.2 NVMe/CNVi WiFi/Bluetooth (Intel Wi-Fi 6 AX210/211)
|
||||
- Power
|
||||
- 330W (19.5V, 16.42A) AC adapter (Chicony A20-330P1A)
|
||||
- Rectangular connector; not a barrel connector
|
||||
- 99Wh 8-cell Lithium-ion battery
|
||||
- Sound
|
||||
- Realtek ALC1220 codec
|
||||
- Realtek ALC1318 smart amp
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone & microphone jack
|
||||
- Combined 3.5mm microphone & S/PDIF jack
|
||||
- HDMI, mDP, USB-C DP audio
|
||||
- Storage
|
||||
- 3x M.2 PCIe NVMe Gen 4 SSDs
|
||||
- USB
|
||||
- 2x USB Type-C with Thunderbolt 4
|
||||
- 2x USB 3.2 Gen 2 Type-A
|
||||
- Dimensions
|
||||
- 2.49cm x 39.6cm x 27.8cm, 3.29kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | GigaDevice |
|
||||
+---------------------+---------------------+
|
||||
| Model | GD25B256E |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U58) is next to the left M.2 port.
|
@ -1,82 +0,0 @@
|
||||
# Syste76 Darter Pro 8 (darp8)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i5-1240P
|
||||
- Intel Core i7-1260P
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- Intel Iris Xe Graphics
|
||||
- eDP 15.6" 1920x1080@60Hz LCD
|
||||
- 1x HDMI
|
||||
- 1x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR4 SO-DIMMs @ 3200 MHz
|
||||
- Networking
|
||||
- Gigabit Ethernet
|
||||
- M.2 NVMe/CNVi WiFi/Bluetooth (Intel Wi-Fi 6 AX200/201)
|
||||
- Power
|
||||
- 90W (19V, 4.74A) AC barrel adapter (Chicony A16-090P1A)
|
||||
- USB-C charging, compatible with 65W+ chargers
|
||||
- 73Wh 4-cell Lithium-ion battery (L140BAT-4)
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone/microphone jack
|
||||
- HDMI, USB-C DisplayPort audio
|
||||
- Storage
|
||||
- M.2 PCIe NVMe Gen 4 SSD
|
||||
- M.2 PCIe NVMe Gen 3 or SATA 3 SSD
|
||||
- MicroSD card reader (OZ711LV2)
|
||||
- USB
|
||||
- 1x USB-C Type-C with Thunderbolt 4
|
||||
- 1x USB 3.2 (Gen 2) Type-C
|
||||
- 1x USB 3.2 (Gen 2) Type-A
|
||||
- 1x USB 2.0 Type-A
|
||||
- Dimensions
|
||||
- 35.7cm x 22.05cm x 1.99cm, 1.74kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | GigaDevice |
|
||||
+---------------------+---------------------+
|
||||
| Model | GD25B256E |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | Winbond |
|
||||
+---------------------+---------------------+
|
||||
| Model | W25Q256.V |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U19) is above the left DIMM slot.
|
@ -1,62 +0,0 @@
|
||||
# Syste76 Darter Pro 9 (darp9)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i5-1340P
|
||||
- Intel Core i7-1360P
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- Intel Iris Xe Graphics
|
||||
- eDP 15.6" 1920x1080@60Hz LCD
|
||||
- 1x HDMI
|
||||
- 1x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR5 SO-DIMMs @ 5600 MHz
|
||||
- Networking
|
||||
- Gigabit Ethernet (Realtek RTL8111H)
|
||||
- M.2 NVMe/CNVi WiFi/Bluetooth (Intel Wi-Fi 6E AX210/211)
|
||||
- Power
|
||||
- 90W (19V, 4.74A) AC barrel adapter
|
||||
- USB-C charging, compatible with 65W+ chargers
|
||||
- 73Wh 4-cell Lithium-ion battery (L140BAT-4)
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone/microphone jack
|
||||
- HDMI, USB-C DisplayPort audio
|
||||
- Storage
|
||||
- 2x M.2 PCIe NVMe Gen 4 SSDs
|
||||
- MicroSD card reader (OZ711LV2)
|
||||
- USB
|
||||
- 1x USB Type-C with Thunderbolt 4
|
||||
- 1x USB 3.2 Gen 2 Type-C
|
||||
- 1x USB 3.2 Gen 2 Type-A
|
||||
- 1x USB 2.0 Type-A
|
||||
- Dimensions
|
||||
- 35.7cm x 22.05cm x 1.99cm, 1.74kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | GigaDevice |
|
||||
+---------------------+---------------------+
|
||||
| Model | GD25B256E |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U22) is above the left DIMM slot.
|
@ -1,61 +0,0 @@
|
||||
# System76 Galago Pro 6 (galp6)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i5-1240P
|
||||
- Intel Core i7-1260P
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- Intel Iris Xe Graphics
|
||||
- eDP 14.1" 1920x1080@60Hz LCD (Panda LM140LF2L02)
|
||||
- 1x HDMI 2.1
|
||||
- 1x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR4 SO-DIMMs @ 3200 MHz
|
||||
- Networking
|
||||
- Gigabit Ethernet
|
||||
- M.2 NVMe/CNVi WiFi/Bluetooth (Intel Wi-Fi 6 AX200/201)
|
||||
- Power
|
||||
- 90W (19V, 4.74A) AC barrel adapter (Chicony A16-090P1A)
|
||||
- USB-C charging, compatible with 90W+ chargers
|
||||
- 53.35Wh 4-cell Lithium-ion battery (NV40BAT-4-53)
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone/microphone jack
|
||||
- HDMI, USB-C DisplayPort audio
|
||||
- Storage
|
||||
- M.2 PCIe NVMe Gen 4 SSD
|
||||
- MicroSD card reader (OZ711LV2)
|
||||
- USB
|
||||
- 1x USB-C Type-C with Thunderbolt 4
|
||||
- 1x USB 3.2 (Gen 2) Type-C
|
||||
- 2x USB 3.2 (Gen 1) Type-A
|
||||
- Dimensions
|
||||
- 32.49cm x 22.5cm x 1.82cm, 1.45kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | Macronix |
|
||||
+---------------------+---------------------+
|
||||
| Model | MX25L25673G |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U43) is left of the wireless card.
|
@ -1,58 +0,0 @@
|
||||
# System76 Galago Pro 7 (galp7)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i5-13500H
|
||||
- Intel Core i7-13700H
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- Intel Iris Xe Graphics
|
||||
- eDP 14.1" 1920x1080@144Hz LCD (Sharp LQ140M1JW49)
|
||||
- 1x HDMI 2.1
|
||||
- 1x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR4 SO-DIMMs @ 3200 MHz
|
||||
- Networking
|
||||
- Gigabit Ethernet
|
||||
- M.2 NVMe/CNVi WiFi/Bluetooth (Intel Wi-Fi 6 AX210/211)
|
||||
- Power
|
||||
- 90W (19V, 4.74A) AC barrel adapter (Chicony A16-090P1A)
|
||||
- USB-C charging, compatible with 90W+ chargers
|
||||
- 53Wh 4-cell Lithium-ion battery
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone/microphone jack
|
||||
- HDMI, USB-C DisplayPort audio
|
||||
- USB
|
||||
- 1x USB-C Type-C with Thunderbolt 4
|
||||
- 1x USB 3.2 (Gen 2) Type-C
|
||||
- 2x USB 3.2 (Gen 1) Type-A
|
||||
- Dimensions
|
||||
- 32.49cm x 22.5cm x 1.82cm, 1.45kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | Macronix |
|
||||
+---------------------+---------------------+
|
||||
| Model | MX25L25673G |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U43) is left of the wireless card.
|
@ -1,65 +0,0 @@
|
||||
# System76 Gazelle 17 (gaze17)
|
||||
|
||||
The gaze17 comes in 2 variants: gaze17-3050 and gaze17-3060-b.
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i5-12500H
|
||||
- Intel Core i7-12700H
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- dGPU options
|
||||
- NVIDIA GeForce RTX 3050
|
||||
- NVIDIA GeForce RTX 3050 Ti
|
||||
- NVIDIA GeForce RTX 3060
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR4 SO-DIMMs @ 3200 MT/s
|
||||
- Networking
|
||||
- Gigabit Ethernet
|
||||
- 3050: Realtek RTL8111H controller
|
||||
- 3060: Onboard Intel I219-V
|
||||
- M.2 PCIe/CNVi WiFi/Bluetooth
|
||||
- Intel Wi-Fi 6 AX201
|
||||
- Power
|
||||
- 3050: 150W (20V, 7.5A) AC barrel adapter
|
||||
- 3060: 180W (20V, 9A) AC barrel adapter
|
||||
- Lite-On PA-1181-76, using a C5 power cord
|
||||
- 54Wh 4-cell Li-ion battery (NP50BAT-4-54)
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone/microphone jack
|
||||
- Dedicated 3.5mm microphone jack
|
||||
- Storage
|
||||
- 1x M.2 PCIe NVMe Gen 4 SSD
|
||||
- 1x M.2 PCIe NVMe Gen 3 or SATA 3 SSD
|
||||
- MicroSD card reader (Realtek RTS5227S/OZ711LV2)
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | GigaDevice |
|
||||
+---------------------+---------------------+
|
||||
| Model | GD25B256E |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The position of the flash chip depends on the variant:
|
||||
|
||||
- 3050: U24, below the bottom DIMM slot.
|
||||
- 3060: U55, left of the PCIe 4.0 M.2 slot.
|
@ -1,72 +0,0 @@
|
||||
# System76 Gazelle 18 (gaze18)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel i9-13900H
|
||||
- Chipset
|
||||
- Intel HM770
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- NVIDIA GeForce RTX 3050 (70W TDP)
|
||||
- Intel Irix Xe Graphics
|
||||
- eDP displays
|
||||
- 17.3" 1920x1080@144Hz LCD
|
||||
- 15.6" 1920x1080@144Hz LCD
|
||||
- External outputs
|
||||
- 1x HDMI 2.1
|
||||
- 1x Mini DisplayPort 1.4
|
||||
- Memory
|
||||
- Up to 64GB (2x32GB) dual-channel DDR4 SO-DIMMs @ 3200 MHz
|
||||
- Networking
|
||||
- Realtek RTL8111H gigabit Ethernet
|
||||
- M.2 PCIe/CNVi WiFi/Bluetooth
|
||||
- Intel Wi-Fi 6E AX210/AX211
|
||||
- Power
|
||||
- 150W AC barrel adapter
|
||||
- Included: LiteOn PA-1151-76, using a C5 power cord
|
||||
- 54Wh 4-cell battery (NP50BAT-4-54)
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5mm headphone/microphone jack
|
||||
- Dedicated 3.5mm microphone jack
|
||||
- HDMI, mDP audio
|
||||
- Storage
|
||||
- 1x M.2 (PCIe NVMe Gen 4)
|
||||
- 1x M.2 (PCIe NVMe Gen 3)
|
||||
- MicroSD card reader
|
||||
- Realtek RTS5227S
|
||||
- USB
|
||||
- 2x USB 3.2 Gen 2 Type-C
|
||||
- Does not support USB-C charging (USB-PD) or Thunderbolt
|
||||
- 1x USB 3.2 Gen 2 Type-A
|
||||
- 1x USB 2.0 Type-A
|
||||
- Dimensions
|
||||
- 15": 35.95cm x 23.8cm x 2.27cm, 1.99kg
|
||||
- 17": 39.69cm x 26.2cm x 2.5cm, 2.41kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | GigaDevice |
|
||||
+---------------------+---------------------+
|
||||
| Model | GD25B256E |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U24) is right of the M.2 SSD connectors.
|
@ -1,62 +0,0 @@
|
||||
# System76 Lemur Pro 11 (lemp11)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i5-1235U
|
||||
- Intel Core i7-1255U
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- Intel Iris Xe Graphics
|
||||
- eDP 14.0" 1920x1080@60Hz LCD
|
||||
- 1x HDMI 2.1
|
||||
- 1x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Channel 0: 8-GB on-board DDR4 (Samsung K4AAG165WA-BCWE)
|
||||
- Channel 1: 8-GB/16-GB/32-GB DDR4 SO-DIMM @ 3200 MHz
|
||||
- Networking
|
||||
- M.2 NVMe/CNVi WiFi/Bluetooth (Intel Wi-Fi 6 AX200/201)
|
||||
- Power
|
||||
- 65W (19V, 3.42A) AC barrel adapter (AcBel ADA012)
|
||||
- USB-C charging, compatible with 65W+ chargers
|
||||
- 73Wh 4-cell Lithium-ion battery (L140BAT-4)
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5 mm headphone/microphone jack
|
||||
- HDMI, USB-C DisplayPort audio
|
||||
- Storage
|
||||
- M.2 PCIe NVMe Gen 4 SSD
|
||||
- M.2 PCIe NVMe Gen 3 or SATA 3 SSD
|
||||
- MicroSD card reader (RTS5227S)
|
||||
- USB
|
||||
- 1x USB Type-C with Thunderbolt 4
|
||||
- 1x USB 3.2 (Gen 2) Type-A
|
||||
- 1x USB 3.2 (Gen 1) Type-A
|
||||
- Dimensions
|
||||
- 1.65cm x 32.2cm x 21.68cm, 1.15kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | Macronix |
|
||||
+---------------------+---------------------+
|
||||
| Model | MX25L25673G |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U41) is left of the DIMM slot.
|
@ -1,62 +0,0 @@
|
||||
# System76 Lemur Pro 12 (lemp12)
|
||||
|
||||
## Specs
|
||||
|
||||
- CPU
|
||||
- Intel Core i5-1335U
|
||||
- Intel Core i7-1355U
|
||||
- EC
|
||||
- ITE IT5570E running [System76 EC](https://github.com/system76/ec)
|
||||
- Graphics
|
||||
- Intel Iris Xe Graphics
|
||||
- eDP 14.0" 1920x1080@60Hz LCD (Innolux N140HCE-EN2)
|
||||
- 1x HDMI 2.1
|
||||
- 1x DisplayPort 1.4 over USB-C
|
||||
- Memory
|
||||
- Channel 0: 8-GB onboard DDR5 (Samsung M425R1GB4BB0-CQKOD)
|
||||
- Channel 1: 8/16/32-GB DDR5 SO-DIMM @ 4800 MHz
|
||||
- Networking
|
||||
- M.2 NVMe/CNVi WiFi/Bluetooth (Intel Wi-Fi 6 AX210/211)
|
||||
- Power
|
||||
- 65W (19V, 3.42A) AC adapter (AcBel ADA012)
|
||||
- USB-C charging, compatible with 65W+ charger
|
||||
- 73Wh 4-cell Lithium-ion battery
|
||||
- Sound
|
||||
- Realtek ALC256 codec
|
||||
- Internal speakers and microphone
|
||||
- Combined 3.5 mm headphone/microphone jack
|
||||
- HDMI, USB-C DisplayPort audio
|
||||
- Storage
|
||||
- 1x M.2 PCIe NVMe Gen 4 SSD
|
||||
- 1x M.2 PCIe NVMe Gen 3 or SATA 3 SSD
|
||||
- MicroSD card reader (RTS5227S)
|
||||
- USB
|
||||
- 1x USB Type-C with Thudnerbolt 4
|
||||
- 1x USB 3.2 Gen 2 Type-A
|
||||
- 1x USB 3.2 Gen 1 Type-A
|
||||
- Dimensions
|
||||
- 1.65cm x 32.2cm x 21.68cm, 1.15kg
|
||||
|
||||
## Flashing coreboot
|
||||
|
||||
```eval_rst
|
||||
+---------------------+---------------------+
|
||||
| Type | Value |
|
||||
+=====================+=====================+
|
||||
| Socketed flash | no |
|
||||
+---------------------+---------------------+
|
||||
| Vendor | Macronix |
|
||||
+---------------------+---------------------+
|
||||
| Model | MX25L25673G |
|
||||
+---------------------+---------------------+
|
||||
| Size | 32 MiB |
|
||||
+---------------------+---------------------+
|
||||
| Package | WSON-8 |
|
||||
+---------------------+---------------------+
|
||||
| Internal flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
| External flashing | yes |
|
||||
+---------------------+---------------------+
|
||||
```
|
||||
|
||||
The flash chip (U41) is left of the DIMM slot.
|