sravan/system76-coreboot
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/master' into galp5

Browse Source 
Change-Id: I10d9f61ff58ff2edd7d6e8430dd42be3b93cc994
This commit is contained in:
Jeremy Soller
2020-10-13 11:54:56 -06:00
parent 8be09c0c61 a2118c7b54
commit 3a3b10b81d
3240 changed files with 79963 additions and 29972 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
.gitignore vendored
View File

@@ -97,7 +97,6 @@ util/cbfstool/ifwitool
util/cbfstool/rmodtool
util/cbmem/.dependencies
util/cbmem/cbmem
util/dumpmmcr/dumpmmcr
util/ectool/ectool
util/futility/futility
util/genprof/genprof
@@ -106,16 +105,14 @@ util/ifdtool/ifdtool
util/intelmetool/intelmetool
util/inteltool/.dependencies
util/inteltool/inteltool
util/intelp2m/intelp2m
util/intelp2m/generate/gpio.h
util/intelvbttool/intelvbttool
util/k8resdump/k8resdump
util/lbtdump/lbtdump
util/mptable/mptable
util/msrtool/Makefile
util/msrtool/Makefile.deps
util/msrtool/msrtool
util/nvramtool/.dependencies
util/nvramtool/nvramtool
util/optionlist/Options.wiki
util/pmh7tool/pmh7tool
util/runfw/googlesnow
util/superiotool/superiotool
@@ -123,6 +120,8 @@ util/vgabios/testbios
util/autoport/autoport
util/kbc1126/kbc1126_ec_dump
util/kbc1126/kbc1126_ec_insert
util/spd_tools/*/gen_spd
util/spd_tools/*/gen_part_id
Documentation/*.aux
Documentation/*.idx

7
.gitmodules vendored
View File

@@ -51,3 +51,10 @@
url = https://review.coreboot.org/qc_blobs.git
update = none
ignore = dirty
[submodule "3rdparty/intel-sec-tools"]
path = 3rdparty/intel-sec-tools
url = ../9esec-security-tooling.git
[submodule "3rdparty/stm"]
path = 3rdparty/stm
url = ../STM
branch = stmpe

2
3rdparty/amd_blobs vendored

Submodule 3rdparty/amd_blobs updated: 1ac6d42bf3...e393a885c8

2
3rdparty/arm-trusted-firmware vendored

Submodule 3rdparty/arm-trusted-firmware updated: ace23683be...a4c979ade4

2
3rdparty/blobs vendored

Submodule 3rdparty/blobs updated: bbe5d99780...1aff9c32eb

2
3rdparty/fsp vendored

Submodule 3rdparty/fsp updated: 2263d48a00...eb25f19ef7

2
3rdparty/intel-microcode vendored

Submodule 3rdparty/intel-microcode updated: 33b7b2f381...0e4288f81f

1
3rdparty/intel-sec-tools vendored Submodule

Submodule 3rdparty/intel-sec-tools added at a86ff5d400

2
3rdparty/qc_blobs vendored

Submodule 3rdparty/qc_blobs updated: 126fef6b99...6b7fe498eb

1
3rdparty/stm vendored Submodule

Submodule 3rdparty/stm added at 1f3258261a

2
3rdparty/vboot vendored

Submodule 3rdparty/vboot updated: 68de90c7e2...4c523ed10f

31
Documentation/arch/x86/index.md
View File

@@ -5,16 +5,19 @@ This section contains documentation about coreboot on x86 architecture.
* [x86 PAE support](pae.md)
## State of x86_64 support
At the moment there's no single board that supports x86_64 or to be exact
`ARCH_RAMSTAGE_X86_64` and `ARCH_ROMSTAGE_X86_64`.
At the moment there's only experimental x86_64 support.
The `emulation/qemu-i440fx` and `emulation/qemu-q35` boards do support
*ARCH_RAMSTAGE_X86_64* , *ARCH_POSTCAR_X86_64* and *ARCH_ROMSTAGE_X86_64*.
In order to add support for x86_64 the following assumptions are made:
In order to add support for x86_64 the following assumptions were made:
* The CPU supports long mode
* All memory returned by malloc must be below 4GiB in physical memory
* All code that is to be run must be below 4GiB in physical memory
* The high dword of pointers is always zero
* The reference implementation is qemu
* The CPU supports 1GiB hugepages
* x86 payloads are loaded below 4GiB in physical memory and are jumped
to in *protected mode*
## Assuptions for all stages using the reference implementation
* 0-4GiB are identity mapped using 2MiB-pages as WB
@@ -37,18 +40,16 @@ The page tables contains the following structure:
At the moment *$n* is 4, which results in identity mapping the lower 4 GiB.
## Steps to add basic support for x86_64
* Add x86_64 toolchain support - *DONE*
* Fix compilation errors - *DONE*
* Fix linker errors - *TODO*
* Add x86_64 rmodule support - *DONE*
* Add x86_64 exception handlers - *DONE*
* Setup page tables for long mode - *DONE*
* Add assembly code for long mode - *DONE*
* Add assembly code for SMM - *DONE*
* Add assembly code for postcar stage - *TODO*
* Add assembly code to return to protected mode - *TODO*
* Implement reference code for mainboard `emulation/qemu-q35` - *TODO*
## Basic x86_64 support
Basic support for x86_64 has been implemented for QEMU mainboard target.
## Reference implementation
The reference implementation is
* [QEMU i440fx](../../mainboard/emulation/qemu-i440fx.md)
* [QEMU Q35](../../mainboard/emulation/qemu-q35.md)
## TODO
* Identity map memory above 4GiB in ramstage
## Future work

136
Documentation/community/language_style.md Normal file
View File

@@ -0,0 +1,136 @@
# Language style
Following our [Code of Conduct](code_of_conduct.md) the project aims to
be a space where people are considerate in natural language communication:
There are terms in computing that were probably considered benign when
introduced but are uncomfortable to some. The project aims to de-emphasize
such terms in favor of alternatives that are at least as expressive -
but often manage to be even more descriptive.
## Political Correctness
A common thread in discussions was that the project merely follows some
fad, or that this is a "political correctness" measure, designed to please
one particular "team". While the project doesn't exist in a vacuum and
so there are outside influences on project members, the proposal wasn't
made with the purpose of demonstrating allegiance to any given cause -
except one:
There are people who feel uncomfortable with some terms being used,
_especially_ when that use takes them out of their grave context
(e.g. slave when discussing slavery) and applies them to a rather benign
topic (e.g. coordination of multiple technical systems), taking away
the gravity of the term.
That gets especially jarring when people aren't exposed to such terms
in abstract sociological discussions but when they stand for real issues
they encountered.
When having to choose between using a well-established term that
affects people negatively who could otherwise contribute more happily
and undisturbed or an alternative just-as-good term that doesn't, the
decision should be simple.
## Token gesture
The other major point of contention is that such decisions are a token
gesture that doesn't change anything. It's true: No slave is freed
because coreboot rejects the use of the word.
coreboot is ambitious enough as-is, in that the project offers
an alternative approach to firmware, sometimes against the vested
interests (and deep pockets) of the leaders of a multi-billion dollar
industry. Changing the preferred vocabulary isn't another attempt at
changing the world, it's one thing we do to try to make coreboot (and
coreboot only) a comfortable environment for everybody.
## For everybody
For everybody, but with a qualifier: We have certain community etiquette,
and we define some behavior we don't accept in our community, both
detailed in the Code of Conduct.
Other than that, we're trying to accommodate people: The CoC lays out
that language should be interpreted as friendly by default, and to be
graceful in light of accidents. This also applies to the use of terms
that the project tries to avoid: The consequence of the use of such
terms (unless obviously employed to provoke a reaction - in that case,
please contact the arbitration team as outlined in the Code of Conduct)
should be a friendly reminder. The project is slow to sanction and that
won't change just because the wrong kind of words is used.
## Interfacing with the world
The project doesn't exist in a vacuum, and that also applies to the choice
of words made by other initiatives in low-level technology. When JEDEC
calls the participants of a SPI transaction "master" and "slave", there's
little we can do about that. We _could_ decide to use different terms,
but that wouldn't make things easier but harder, because such a deliberate
departure means that the original terms (and their original use) gain
lots of visibility every time (so there's no practical advantage) while
adding confusion, and therefore even more attention, to that situation.
Sometimes there are abbreviations that can be used as substitutes,
and in that case the recommendation is to do that.
As terms that we found to be best avoided are replaced in such
initiatives, we can follow up. Members of the community with leverage
in such organizations are encouraged to raise the concern there.
## Dealing with uses
There are existing uses in our documentation and code. When we decide to
retire a term that doesn't mean that everybody is supposed to stop doing
whatever they're doing and spend their time on purging terms. Instead,
ongoing development should look for alternatives (and so this could come
up in review).
People can go through existing code and docs and sort out older instances,
and while that's encouraged it's no "stop the world" event. Changes
in flight in review may still be merged with such terms intact, but if
there's more work required for other reasons, we'd encourage moving away
from such terms.
This document has a section on retired terms, presenting the rationale
as well as alternative terms that could be used instead. The main goal is
to be expressive: There's no point in just picking any alternative term,
choose something that explains the purpose well.
As mentioned, missteps will happen. Point them out, but assume no ill
intent for as long as you can manage.
## Discussing words to remove from active use
There ought to be some process when terminology is brought up as a
negative to avoid. Do not to tell people that "they're feeling wrong"
when they have a negative reaction to certain terms, but also try to
avoid being offended for the sake of others.
When bringing up a term, on the project's mailing list or, if you don't
feel safe doing that, by contacting the arbitration team, explain what's
wrong with the term and offer alternatives for uses within coreboot.
With a term under discussion, see if there's particular value for us to
continue using the term (maybe in limited situations, like continuing
to use "slave" in SPI related code).
Once the arbitration team considers the topic discussed completely and
found a consensus, it will present a decision in a leadership meeting. It
should explain why a term should or should not be used and in the latter
case offer alternatives. These decisions shall then be added to this
document.
## Retired terminology
### slave
Replacing this term for something else had the highest approval rating
in early discussions, so it seems pretty universally considered a bad
choice and therefore should be avoided where possible.
An exception is made where it's a term used in current standards and data
sheets: Trying to "hide" the term in such cases only puts a spotlight
on it every time code and data sheet are compared.
Alternatives: subordinate, secondary, follower

2
Documentation/conf.py
View File

@@ -48,7 +48,7 @@ try:
except ImportError:
print("Error: Please install sphinxcontrib.ditaa for ASCII art conversion\n")
else:
extensions += 'sphinxcontrib.ditaa'
extensions += ['sphinxcontrib.ditaa']
# The language for content autogenerated by Sphinx. Refer to documentation
# for a list of supported languages.

45
Documentation/getting_started/gerrit_guidelines.md
View File

@@ -43,15 +43,42 @@ 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](https://www.coreboot.org/Development_Guidelines#Sign-off_Procedure).
* Let non-trivial patches sit in a review state for at least 24 hours
before submission. Remember that there are coreboot developers in timezones
all over the world, and everyone should have a chance to contribute.
Trivial patches would be things like whitespace changes or spelling fixes,
in general those that don’t impact the final binary output. The
24-hour period would start at submission, and would be restarted at any
update which significantly changes any part of the patch. Patches can be
'Fast-tracked' and submitted in under 24 hours with the agreement of at
least 3 +2 votes.
* 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
let coreboot developers around the world have a chance to review. Complex
reworks, even if they don't change the purpose of the patch but the way
it's implemented, should restart the wait period.
* A change can go in without the wait period if its purpose is to fix
a recently-introduced issue (build, boot or OS-level compatibility, not
necessarily identified by coreboot.org facilities). Its commit message
has to explain what change introduced the problem and the nature of
the problem so that the emergency need becomes apparent. The change
itself should be as limited in scope and impact as possible to make it
simple to assess the impact. Such a change can be merged early with 3
Code-Review+2. For emergency fixes that affect a single project (SoC,
mainboard, ...) it's _strongly_ recommended to get a review by somebody
not involved with that project to ensure that the documentation of the
issue is clear enough.
* Trivial changes that deal with minor issues like inconsistencies in
whitespace or spelling fixes that don't impact the final binary output
also don't need to wait. Such changes should point out in their commit
messages how the the author verified that the binary output is identical
(e.g. a TIMELESS build for a given configuration). When submitting
such changes early, the submitter must be different from the author
and must document the intent in the Gerrit discussion, e.g. "landed the
change early because it's trivial". Note that trivial fixes shouldn't
necessarily be expedited: Just like they're not critical enough for
things to go wrong because of them, they're not critical enough to
require quick handling. This exception merely serves to acknowledge that
a round-the-world review just isn't necessary for some types of changes.
* As explained in our Code of Conduct, we try to assume the best of each
other in this community. It's okay to discuss mistakes (e.g. isolated
instances of non-trivial and non-critical changes submitted early) but
try to keep such inquiries blameless. If a change leads to problems with
our code, the focus should be on fixing the issue, not on assigning blame.
* Do not +2 patches that you authored or own, even for something as trivial
as whitespace fixes. When working on your own patches, it’s easy to

5
Documentation/getting_started/gpio.md
View File

@@ -88,11 +88,6 @@ configurations together into a set of macros, e.g.,
```C
/* Native function configuration */
#define PAD_CFG_NF(pad, pull, rst, func)
/*
* Set native function with RX Level/Edge configuration and disable
* input/output buffer if necessary
*/
#define PAD_CFG_NF_BUF_TRIG(pad, pull, rst, func, bufdis, trig)
/* General purpose output, no pullup/down. */
#define PAD_CFG_GPO(pad, val, rst)
/* General purpose output, with termination specified */

4
Documentation/getting_started/kconfig.md
View File

@@ -52,7 +52,7 @@ command line.
not have an answer yet, it stops and queries the user for the desired value.
- olddefconfig - Generates a config, using the default value for any symbols not
listed in the .config file.
- savedefconfig - Creates a ‘mini-config’ file, stripping out all of the symbols
- savedefconfig - Creates a ‘defconfig’ file, stripping out all of the symbols
that were left as default values. This is very useful for debugging, and is
how config files should be saved.
- silentoldconfig - This evaluates the .config file the same way that the
@@ -398,6 +398,8 @@ default <expr> \[if <expr>\]
- If there is no 'default' entry for a symbol, it gets set to 'n', 0, 0x0, or
“” depending on the type, however the 'bool' type is the only type that
should be left without a default value.
- If possible, the declaration should happen before all default entries to make
it visible in Kconfig tools like menuconfig.
--------------------------------------------------------------------------------

1
Documentation/index.md
View File

@@ -166,6 +166,7 @@ Contents:
* [Project Ideas](contributing/project_ideas.md)
* [Documentation Ideas](contributing/documentation_ideas.md)
* [Code of Conduct](community/code_of_conduct.md)
* [Language style](community/language_style.md)
* [Community forums](community/forums.md)
* [Project services](community/services.md)
* [coreboot at conferences](community/conferences.md)

8
Documentation/lib/payloads/fit.md
View File

@@ -5,6 +5,7 @@
## Supported architectures
* aarch32
* aarch64
* riscv
@@ -26,6 +27,13 @@ The section must be named in order to be found by the FIT parser:
The FIT parser needs architecure support.
### aarch32
The source code can be found in `src/arch/arm/fit_payload.c`.
On aarch32 the kernel (a section named 'kernel') must be in **Image**
format and it needs a devicetree (a section named 'fdt') to boot.
The kernel will be placed close to "*DRAMSTART*".
### aarch64
The source code can be found in `src/arch/arm64/fit_payload.c`.

170
Documentation/mainboard/asus/a88xm-e.md Normal file
View File

@@ -0,0 +1,170 @@
# ASUS A88XM-E
This page describes how to run coreboot on the [ASUS A88XM-E].
## Technology
Both "Trinity" and "Richland" FM2 desktop processing units are working,
the CPU architecture in these CPUs/APUs are [Piledriver],
and their GPU is [TeraScale 3] (VLIW4-based).
Kaveri is non-working at the moment (FM2+),
the CPU architecture in these CPUs/APUs are [Steamroller],
and their GPU is [Sea Islands] (GCN2-based).
A10 Richland is recommended for the best performance and working IOMMU.
```eval_rst
+------------------+--------------------------------------------------+
| A88XM-E | |
+------------------+--------------------------------------------------+
| DDR voltage IC | Nuvoton 3101S |
+------------------+--------------------------------------------------+
| Network | Realtek RTL8111G |
+------------------+--------------------------------------------------+
| Northbridge | Integrated into CPU with IMC and GPU (APUs only) |
+------------------+--------------------------------------------------+
| Southbridge | Bolton-D4 |
+------------------+--------------------------------------------------+
| Sound IC | Realtek ALC887 |
+------------------+--------------------------------------------------+
| Super I/O | ITE IT8603E |
+------------------+--------------------------------------------------+
| VRM controller | DIGI VRM ASP1206 |
+------------------+--------------------------------------------------+
```
## Flashing coreboot
```eval_rst
+---------------------+------------+
| Type | Value |
+=====================+============+
| Socketed flash | yes |
+---------------------+------------+
| Model | [GD25Q64] |
+---------------------+------------+
| Size | 8 MiB |
+---------------------+------------+
| Package | DIP-8 |
+---------------------+------------+
| Write protection | yes |
+---------------------+------------+
| Dual BIOS feature | no |
+---------------------+------------+
| Internal flashing | yes |
+---------------------+------------+
```
### Internal programming
The main SPI flash can be accessed using [flashrom], if the
AmdSpiRomProtect modules have been deleted in the factory image previously.
### External flashing
Using a PLCC Extractor or any other appropriate tool, carefully remove the
DIP-8 BIOS chip from its' socket while avoiding the bent pins, if possible.
To flash it, use a [flashrom]-supported USB CH341A programmer - preferably with a
green PCB - and double check that it's giving a 3.3V voltage on the socket pins.
## Integrated graphics
### Retrieve the VGA optionrom ("Retrieval via Linux kernel" method)
Make sure a proprietary UEFI is flashed and boot Linux with iomem=relaxed flag.
Some Linux drivers (e.g. radeon for AMD) make option ROMs like the video blob
available to user space via sysfs. To use that to get the blob you need to
enable it first. To that end you need to determine the path within /sys
corresponding to your graphics chip. It looks like this:
# /sys/devices/pci<domain>:<bus>/<domain>:<bus>:<slot>.<function>/rom.
You can get the respective information with lspci, for example:
# lspci -tv
# -[0000:00]-+-00.0 Advanced Micro Devices, Inc. [AMD] Family 16h Processor Root Complex
# +-01.0 Advanced Micro Devices, Inc. [AMD/ATI] Kabini [Radeon HD 8210]
# ...
Here the the needed bits (for the ROM of the Kabini device) are:
# PCI domain: (almost always) 0000
# PCI bus: (also very commonly) 00
# PCI slot: 01 (logical slot; different from any physical slots)
# PCI function: 0 (a PCI device might have multiple functions... shouldn't matter here)
To enable reading of the ROM you need to write 1 to the respective file, e.g.:
# echo 1 > /sys/devices/pci0000:00/0000:00:01.0/rom
The same file should then contain the video blob and it should be possible to simply copy it, e.g.:
# cp /sys/devices/pci0000:00/0000:00:01.0/rom vgabios.bin
romheaders should print reasonable output for this file.
This version is usable for all the GPUs.
1002,9901 Trinity (Radeon HD 7660D)
1002,9904 Trinity (Radeon HD 7560D)
1002,990c Richland (Radeon HD 8670D)
1002,990e Richland (Radeon HD 8570D)
1002,9991 Trinity (Radeon HD 7540D)
1002,9993 Trinity (Radeon HD 7480D)
1002,9996 Richland (Radeon HD 8470D)
1002,9998 Richland (Radeon HD 8370D)
1002,999d Richland (Radeon HD 8550D)
1002,130f Kaveri (Radeon R7)
## Known issues
- AHCI hot-plug
- S3 resume (sometimes)
- Windows 7 can't boot because of the incomplete ACPI implementation
- XHCI
### XHCI ports can break after using any of the blobs, restarting the
board with factory image makes it work again as fallback.
Tested even with/without the Bolton and Hudson blobs.
## Untested
- audio over HDMI
## TODOs
- one ATOMBIOS module for all the integrated GPUs
- manage to work with Kaveri/Godavary (they are using a binaryPI)
- IRQ routing is done incorrect way - common problem of fam15h boards
## Working
- ACPI
- CPU frequency scaling
- flashrom under coreboot
- Gigabit Ethernet
- Hardware monitoring
- Integrated graphics
- KVM virtualization
- Onboard audio
- PCI
- PCIe
- PS/2 keyboard mouse (during payload, bootloader)
- SATA
- Serial port
- SuperIO based fan control
- USB (disabling XHCI controller makes to work as fallback USB2.0 ports)
- IOMMU
## Extra resources
- [Board manual]
[ASUS A88XM-E]: https://www.asus.com/Motherboards/A88XME/
[Board manual]: https://dlcdnets.asus.com/pub/ASUS/mb/SocketFM2/A88XM-E/E9125_A88XM-E.pdf
[flashrom]: https://flashrom.org/Flashrom
[GD25Q64]: http://www.elm-tech.com/ja/products/spi-flash-memory/gd25q64/gd25q64.pdf
[Piledriver]: https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29#APU_lines
[Sea Islands]: https://en.wikipedia.org/wiki/Graphics_Core_Next#GCN_2nd_generation
[Steamroller]: https://en.wikipedia.org/wiki/Steamroller_(microarchitecture)
[TeraScale 3]: https://en.wikipedia.org/wiki/TeraScale_%28microarchitecture%29#TeraScale_3

64
Documentation/mainboard/emulation/qemu-i440fx.md Normal file
View File

@@ -0,0 +1,64 @@
# qemu i440fx mainboard
## Running coreboot in qemu
Emulators like qemu don't need a firmware to do hardware init.
The hardware starts in the configured state already.
The coreboot port allows to test non mainboard specific code.
As you can easily attach a debugger, it's a good target for
experimental code.
## coreboot x86_64 support
coreboot historically runs in 32-bit protected mode, even though the
processor supports x86_64 instructions (long mode).
The qemu-i440fx mainboard has been ported to x86_64 and will serve as
reference platform to enable additional platforms.
To enable the support set the Kconfig option ``CONFIG_CPU_QEMU_X86_64=y``.
## Installing qemu
On debian you can install qemu by running:
```bash
$ sudo apt-get install qemu
```
On redhat you can install qemu by running:
```bash
$ sudo dnf install qemu
```
## Running coreboot
### To run the i386 version of coreboot (default)
Running on qemu-system-i386 will require a 32 bit operating system.
```bash
qemu-system-i386 -bios build/coreboot.rom -serial stdio -M pc
```
### To run the experimental x86_64 version of coreboot
Running on qemu-system-x86_64 allows to run a 32 bit or 64 bit operating system,
as well as firmware.
```bash
qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M pc
```
## Finding bugs
To test coreboot's x86 code it's recommended to run on a x86 host and enable KVM.
It will not only run faster, but is closer to real hardware. If you see the
following message:
KVM internal error. Suberror: 1
emulation failure
something went wrong. The same bug will likely cause a FAULT on real hardware,
too.
To enable KVM run:
```bash
qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M pc -accel kvm -cpu host
```

64
Documentation/mainboard/emulation/qemu-q35.md Normal file
View File

@@ -0,0 +1,64 @@
# qemu q35 mainboard
## Running coreboot in qemu
Emulators like qemu don't need a firmware to do hardware init.
The hardware starts in the configured state already.
The coreboot port allows to test non mainboard specific code.
As you can easily attach a debugger, it's a good target for
experimental code.
## coreboot x86_64 support
coreboot historically runs in 32-bit protected mode, even though the
processor supports x86_64 instructions (long mode).
The qemu-q35 mainboard has been ported to x86_64 and will serve as
reference platform to enable additional platforms.
To enable the support set the Kconfig option ``CONFIG_CPU_QEMU_X86_64=y``.
## Installing qemu
On debian you can install qemu by running:
```bash
$ sudo apt-get install qemu
```
On redhat you can install qemu by running:
```bash
$ sudo dnf install qemu
```
## Running coreboot
### To run the i386 version of coreboot (default)
Running on qemu-system-i386 will require a 32 bit operating system.
```bash
qemu-system-i386 -bios build/coreboot.rom -serial stdio -M q35
```
### To run the experimental x86_64 version of coreboot
Running on `qemu-system-x86_64` allows to run a 32 bit or 64 bit operating system
and firmware.
```bash
qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35
```
## Finding bugs
To test coreboot's x86 code it's recommended to run on a x86 host and enable KVM.
It will not only run faster, but is closer to real hardware. If you see the
following message:
KVM internal error. Suberror: 1
emulation failure
something went wrong. The same bug will likely cause a FAULT on real hardware,
too.
To enable KVM run:
```bash
qemu-system-x86_64 -bios build/coreboot.rom -serial stdio -M q35 -accel kvm -cpu host
```

4
Documentation/mainboard/facebook/monolith.md
View File

@@ -2,7 +2,7 @@
This page describes how to run coreboot on the Facebook Monolith.
Please note: the coreboot implementation for this boards is in its
Please note: the coreboot implementation for this board is in its
Beta state and isn't fully tested yet.
## Required blobs
@@ -104,7 +104,7 @@ solution. Wires need to be connected to be able to flash using an external progr
- SMBus
- Initialization with FSP
- SeaBIOS payload (commit a5cab58e9a3fb6e168aba919c5669bea406573b4)
- TianoCore payload (commit a5cab58e9a3fb6e168aba919c5669bea406573b4)
- TianoCore payload (commit 860a8d95c2ee89c9916d6e11230f246afa1cd629)
- LinuxBoot (kernel kernel-4_19_97) (uroot commit 9c9db9dbd6b532f5f91a511a0de885c6562aadd7)
- eMMC

99
Documentation/mainboard/hp/2560p.md Normal file
View File

@@ -0,0 +1,99 @@
# HP EliteBook 2560p
This page is about the notebook [HP EliteBook 2560p].
## Release status
HP EliteBook 2560p was released in 2011 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 and the PCH,
covered by the base enclosure, which needs to be removed according to
the [Maintenance and Service Guide] to access the flash chip. An SPI
flash programmer using 3.3V voltage such as a ch341a programmer, and
an SOIC-8 clip can be used to read and flash the chip in-circuit.
Pin 1 of the flash chip is at the side near the PCH.
![Flash Chip in 2560p](2560p_flash.webp)
For more details have a look at the general [flashing tutorial].
## Debugging
The board can be debugged with EHCI debug. The EHCI debug port is the back
bottom USB port.
Schematic of this laptop can be found on [Lab One].
## Test status
### Known issues
- GRUB payload freezes if at_keyboard module is in the GRUB image
([bug #141])
### Untested
- Optical Drive
- VGA
- Fingerprint Reader
- Modem
### Working
- Integrated graphics init with libgfxinit
- SATA
- Audio: speaker and microphone
- Ethernet
- WLAN
- WWAN
- Bluetooth
- ExpressCard
- SD Card Reader
- SmartCard Reader
- eSATA
- USB
- DisplayPort
- Keyboard, touchpad and trackpoint
- EC ACPI support and thermal control
- Dock: all USB ports, DisplayPort, eSATA
- TPM
- Internal flashing when IFD is unlocked
- Using `me_cleaner`
## Technology
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Sandy/Ivy Bridge (FCPGA988) |
+------------------+--------------------------------------------------+
| PCH | Intel Cougar Point QM67 |
+------------------+--------------------------------------------------+
| EC | SMSC KBC1126 |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Management Engine |
+------------------+--------------------------------------------------+
```
[HP EliteBook 2560p]: https://support.hp.com/us-en/product/hp-elitebook-2560p-notebook-pc/5071201
[Maintenance and Service Guide]: http://h10032.www1.hp.com/ctg/Manual/c03011618
[flashing tutorial]: ../../flash_tutorial/ext_power.md
[Lab One]: https://www.laboneinside.com/hp-elitebook-2560p-schematic-diagram/
[bug #141]: https://ticket.coreboot.org/issues/141

BIN
Documentation/mainboard/hp/2560p_flash.webp Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 26 KiB

8
Documentation/mainboard/index.md
View File

@@ -37,6 +37,8 @@ The boards in this section are not real mainboards, but emulators.
- [Spike RISC-V emulator](emulation/spike-riscv.md)
- [Qemu RISC-V emulator](emulation/qemu-riscv.md)
- [Qemu AArch64 emulator](emulation/qemu-aarch64.md)
- [Qemu x86 Q35](emulation/qemu-q35.md)
- [Qemu x86 PC](emulation/qemu-i440fx.md)
## Facebook
@@ -59,6 +61,7 @@ The boards in this section are not real mainboards, but emulators.
### EliteBook series
- [HP Laptops with KBC1126 EC](hp/hp_kbc1126_laptops.md)
- [EliteBook 2560p](hp/2560p.md)
- [EliteBook 8760w](hp/8760w.md)
## Intel
@@ -115,6 +118,7 @@ The boards in this section are not real mainboards, but emulators.
## OCP
- [Delta Lake](ocp/deltalake.md)
- [Tioga Pass](ocp/tiogapass.md)
## Open Cellular
@@ -135,6 +139,10 @@ The boards in this section are not real mainboards, but emulators.
- [Hermes](prodrive/hermes.md)
## Purism
- [Librem Mini](purism/librem_mini.md)
## Protectli
- [FW2B / FW4B](protectli/fw2b_fw4b.md)

2
Documentation/mainboard/lenovo/montevina_series.md
View File

@@ -89,7 +89,7 @@ $ make
```
If your flash is not 8 MB, you need to change values of `flcomp_density1` and
`flreg1_limit` in the ifd-x200.set file according to following table:
`flreg1_limit` in the `ifd-x200.set` file according to following table:
```eval_rst
+-----------------+-------+-------+--------+

1
Documentation/mainboard/lenovo/t440p.md
View File

@@ -30,7 +30,6 @@ the laptop able to power on.
## Known Issues
- No audio output when using a headphone
- Cannot get the mainboard serial number from the mainboard: the OEM
UEFI firmware gets the serial number from an "emulated EEPROM" via
I/O port 0x1630/0x1634, but it's still unknown how to make it work

70
Documentation/mainboard/ocp/deltalake.md
View File

@@ -1,7 +1,8 @@
# OCP Delta Lake
This page describes coreboot support status for the [OCP] (Open Compute Project)
Delta Lake server platform.
Delta Lake server platform. This page is updated following each 4-weeks
build/test/release cycle.
## Introduction
@@ -13,8 +14,9 @@ Delta Lake server is a single socket Cooper Lake Scalable Processor server.
Yosemite-V3 has multiple configurations. Depending on configurations, it may
host up to 4 Delta Lake servers in one sled.
Yosemite-V3 and Delta Lake are currently in DVT phase. Facebook, Intel and partners
jointly develop FSP/coreboot/LinuxBoot stack on Delta Lake as an alternative solution.
The Yosemite-V3 program has reached DVT exit. Facebook, Intel and partners
jointly develop FSP/coreboot/LinuxBoot stack on Delta Lake as an alternative
solution. This development is moving toward EVT exit equivalent status.
## Required blobs
@@ -22,7 +24,7 @@ This board currently requires:
- FSP blob: The blob (Intel Cooper Lake Scalable Processor Firmware Support Package)
is not yet available to the public. It will be made public some time after the MP
(Mass Production) of CooperLake Scalable Processor when the FSP is mature.
- Microcode: Not yet available to the public.
- Microcode: Available through github.com:otcshare/Intel-Generic-Microcode.git.
- ME binary: Not yet available to the public.
## Payload
@@ -55,26 +57,49 @@ as initramfs.
- Type 2 -- Baseboard Information
- Type 3 -- System Enclosure or Chassis
- Type 4 -- Processor Information
- Type 7 -- Cache Information
- Type 8 -- Port Connector Information
- Type 9 -- PCI Slot Information
- Type 11 -- OEM String
- Type 13 -- BIOS Language Information
- Type 16 -- Physical Memory Array
- Type 19 -- Memory Array Mapped Address
- Type 32 -- System Boot Information
- Type 38 -- IPMI Device Information
- Type 127 -- End-of-Table
- BMC integration:
- BMC readiness check
- IPMI commands
- watchdog timer
- POST complete pin acknowledgement
- Check BMC version: ipmidump -device
- SEL record generation
- Early serial output
- port 80h direct to GPIO
- ACPI tables: APIC/DSDT/FACP/FACS/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
- ACPI tables: APIC/DMAR/DSDT/FACP/FACS/HPET/MCFG/SPMI/SRAT/SLIT/SSDT
- Skipping memory training upon subsequent reboots by using MRC cache
- BMC crash dump
- Error injection through ITP
- Versions
- Check FSP version: cbmem | grep LB_TAG_PLATFORM_BLOB_VERSION
- Check Microcode version: cat /proc/cpuinfo | grep microcode
- Devices:
- Boot drive
- NIC card
- All 5 data drives
- Power button
- localboot
- netboot from IPv6
- TPM
## Stress/performance tests passed
- OS warm reboot (300 cycles)
- DC reboot (300 cycles)
- AC reboot (300 cycle)
- Mprime test (6 hours)
- StressAppTest (6 hours)
- Ptugen (6 hours)
- MLC (Intel Memory Latency Check)
- Linkpack
- Iperf(IPv6)
- FIO
## Firmware configurations
[ChromeOS VPD] is used to store most of the firmware configurations.
@@ -84,29 +109,22 @@ values.
VPD variables supported are:
- firmware_version: This variable holds overall firmware version. coreboot
uses that value to populate smbios type 1 version field.
- DeltaLake specific VPDs: check mb/ocp/deltalake/vpd.h.
## Known issues
- Even though CPX-SP FSP is based on FSP 2.2 framework, it does not
support FSP_USES_CB_STACK. An IPS ticket is filed with Intel.
- VT-d is not supported. An IPS ticket is filed with Intel.
- PCIe bifuration is not supported. An IPS ticket is filed with Intel.
- ME based power capping. This is a bug in ME. An IPS ticket is filed
with Intel.
- RO_VPD region as well as other RO regions are not write protected.
- HECI is not set up correctly, so BMC is not able to get PCH and DIMM
temperature sensor readings.
- spsInfoLinux64 command fail to return ME version.
- fwts test failures related to mtrr.
- kernel error message related to SleepButton ACPI event.
## Feature gaps
- Delta Lake DVT is not supported, as we only have Delta Lake EVT servers
at the moment.
- SMBIOS:
- Type 7 -- Cache Information
- Type 16 -- Physical Memory Array
- Type 17 -- Memory Device
- Type 38 -- IPMI Device Information
- Type 19 -- Memory Array Mapped Address
- Type 41 -- Onboard Devices Extended Information
- ACPI:
- DMAR
- PFR/CBnT
- Verified measurement through CBnT
- Boot guard of CBnT
- RO_VPD region as well as other RO regions are not write protected.
## Technology
@@ -116,7 +134,7 @@ VPD variables supported are:
+------------------------+---------------------------------------------+
| BMC | Aspeed AST 2500 |
+------------------------+---------------------------------------------+
| PCH | Intel Lewisburg C621 |
| PCH | Intel Lewisburg C620 Series |
+------------------------+---------------------------------------------+
```

BIN
Documentation/mainboard/purism/librem_mini.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB

122
Documentation/mainboard/purism/librem_mini.md Normal file
View File

@@ -0,0 +1,122 @@
# Purism Librem Mini
This page describes how to run coreboot on the [Purism Librem Mini].
```eval_rst
+------------------+--------------------------------------------------+
| CPU | Intel Core i7-8565U |
+------------------+--------------------------------------------------+
| PCH | Whiskey Lake / Cannon Point LP |
+------------------+--------------------------------------------------+
| Super I/O, EC | ITE IT8528E |
+------------------+--------------------------------------------------+
| Coprocessor | Intel Management Engine (CSME 12.x) |
+------------------+--------------------------------------------------+
```
![](librem_mini.jpg)
![](librem_mini_flash.jpg)
## 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 |
+-----------------+---------------------------------+---------------------+
| vgabios | VGA Option ROM | Optional |
+-----------------+---------------------------------+---------------------+
```
FSP-M and FSP-S are obtained after splitting the Coffee 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 the build
system from the `3rdparty/intel-microcode` submodule. Official Purism release
images may include newer microcode, which is instead pulled from Purism's
[purism-blobs] repository.
VGA Option ROM is not required to boot, but if one needs graphics in pre-OS
stage, it should be included (if not using FSP/GOP display init). It can
be extracted via cbfstool from the existing board firmware or pulled from
the [purism-blobs] repository.
## Intel Management Engine
The Librem Mini uses version 12.x of the Intel Management Engine (ME) /
Converged Security Engine (CSE). The ME/CSE is disabled using the High
Assurance Platform (HAP) bit, which puts the ME into a disabled state
after platform bring-up (BUP) and disables all PCI/HECI interfaces.
This can be verified via the coreboot cbmem utility:
`sudo ./cbmem -1 | grep 'ME:'`
provided coreboot has been modified to output the ME status even when
the PCI device is not visible/active (as it is in Purism's release builds).
## 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 8 MiB soldered SOIC-8 chip,
and has a diode attached to the VCC line for in-system programming.
This chip is located on the bottom side of the board under the CPU heatsink,
in line with the front USB 2.0 ports.
One has to remove all screws (in order):
* 2 top cover screws
* 4 screws securing the mainboard to the chassis
* 4 screws securing the heatsink/fan assembly to the mainboard (under the SODIMMs)
The m.2 SSD will need to be removed if the Wi-Fi antenna are connected to
an internal Wi-Fi/BT module. Use a SOIC-8 chip clip to program the chip.
Specifically, it's a Winbond W25Q128JV (3.3V) - [datasheet][W25Q128JV].
The EC firmware is stored on a separate SOIC-8 chip (a Winbond W25Q80DV),
but is not protected by a diode and therefore cannot be read/written to without
desoldering it from the mainboard.
## Known issues
* SeaBIOS can be finicky with detecting USB devices
* Booting can sometimes hang when a bootsplash image is used with SeaBIOS
and VGA option ROM display init, related to display mode changing
* Issues with some SATA devices have been mitigated by limiting the SATA speed to 3Gbps
until the correct HSIO PHY settings can be determined.
## Working
* External displays via HDMI/DislpayPort with VGA option ROM or FSP/GOP init
(no libgfxinit support yet)
* SeaBIOS (1.13.x), Tianocore (CorebootPayloadpkg), Heads (Purism downstream) payloads
* Ethernet, m.2 2230 Wi-Fi
* System firmware updates via flashrom
* PCIe NVMe
* m.2 and SATA III
* Audio via front 3.5mm jack, HDMI, and DisplayPort
* SMBus (reading SPD from DIMMs)
* Initialization with CFL FSP 2.0
* S3 Suspend/Resume
* Booting PureOS 9.x, Debian 10.x, Qubes 4.0.3, Linux Mint 19.3, Windows 10 2004
## Not working / untested
* ITE IT8528E Super IO functions
[Purism Librem Mini]: https://puri.sm/products/librem-mini/
[purism-blobs]: https://source.puri.sm/coreboot/purism-blobs
[W25Q128JV]: https://www.winbond.com/resource-files/w25q128jv%20revf%2003272018%20plus.pdf
[flashrom]: https://flashrom.org/Flashrom

BIN
Documentation/mainboard/purism/librem_mini_flash.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 40 KiB

19
Documentation/releases/coreboot-4.13-relnotes.md
View File

@@ -39,4 +39,23 @@ attributes as per their datasheet and convert those attributes into SPD files fo
the platforms. More details about the tools are added in
[README.md](https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/spd_tools/intel/lp4x/README.md).
### New version of SMM loader
A new version of the SMM loader which accomodates platforms with over 32 CPU
CPU threads. The existing version of SMM loader uses a 64K code/data
segment and only a limited number of CPU threads can fit into one segment
(because of save state, STM, other features, etc). This loader extends beyond
the 64K segment to accomodate additional CPUs and in theory allows as many
CPU threads as possible limited only by SMRAM space and not by 64K. By default
this loader version is disabled. Please see cpu/x86/Kconfig for more info.
### Initial support for x86_64
The x86_64 code support has been revived and enabled for qemu. While it started
as PoC and the only supported platform is an emulator, there's interest in
enabling additional platforms. It would allow to access more than 4GiB of memory
at runtime and possibly brings optimised code for faster execution times.
It still needs changes in assembly, fixed integer to pointer conversions in C,
wrappers for blobs, support for running Option ROMs, among other things.
### Add significant changes here

1
Documentation/security/vboot/list_vboot.md
View File

@@ -142,6 +142,7 @@
- Trogdor
- Lazor
- Bubs
- Coachz
- Veyron_Jaq (Haier Chromebook 11)
- Veyron_Jerry (Hisense Chromebook 11)
- Veyron_Mighty (Haier Chromebook 11(edu))

41
Documentation/soc/amd/family17h.md
View File

@@ -240,47 +240,12 @@ in an Integration Guide.
## APCB setup
APCBs are used to provide the PSP with SPD information and optionally a set of
GPIOs to use for selecting which SPD to load.
### Prebuilt
The picasso `Makefile` expects APCBs to be located in
`3rdparty/blobs/mainboard/$(MAINBOARDDIR)`. If you have a pre-built binary just
add the following to your mainboard's Makefile.
```
# i.e., 3rdparty/blobs/mainboard/amd/mandolin/APCB_mandolin.bin
APCB_SOURCES = mandolin
```
GPIOs to use for selecting which SPD to load. A list of APCB files should be
specified in `APCB_SOURCES`.
### Generating APCBs
If you have a template APCB file, the `apcb_edit` tool can be used to inject the
SPD and GPIOs used to select the correct slot. Entries should match this
pattern `{NAME}_x{1,2}`. There should be a matching SPD hex file in
`SPD_SOURCES_DIR` matching the pattern `{NAME}.spd.hex`.
The `_x{1,2}` suffix denotes single or dual channel. Up to 16 slots can be used.
If a slot is empty, the special empty keyword can be used. This will generate
an APCB with an empty SPD.
```
APCB_SOURCES = hynix-HMA851S6CJR6N-VK_x1 # 0b0000
APCB_SOURCES += hynix-HMAA1GS6CMR6N-VK_x2 # 0b0001
APCB_SOURCES += empty # 0b0010
APCB_SOURCES += samsung-K4A8G165WC-BCWE_x1 # 0b0011
```
#### APCB Board ID GPIO configuration.
The GPIOs determine which memory SPD will be used during boot.
```
# APCB_BOARD_ID_GPIO[0-3] = GPIO_NUMBER GPIO_IO_MUX GPIO_BANK_CTL
# GPIO_NUMBER: FCH GPIO number
# GPIO_IO_MUX: Value write to IOMUX to configure this GPIO
# GPIO_BANK_CTL: Value write to GPIOBankCtl[23:16] to configure this GPIO
APCB_BOARD_ID_GPIO0 = 121 1 0
APCB_BOARD_ID_GPIO1 = 120 1 0
APCB_BOARD_ID_GPIO2 = 131 3 0
APCB_BOARD_ID_GPIO3 = 116 1 0
```
SPD and GPIOs used to select the correct slot.
## Footnotes

150
Documentation/soc/intel/cse_fw_update/Layout_after.svg Normal file
View File

@@ -0,0 +1,150 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by Microsoft Visio, SVG Export Layout_after.svg Page-1 -->
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ev="http://www.w3.org/2001/xml-events"
width="2.39231in" height="2.05998in" viewBox="0 0 172.246 148.318" xml:space="preserve" color-interpolation-filters="sRGB"
class="st12">
<style type="text/css">
<![CDATA[
.st1 {fill:#ffffff;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
.st2 {fill:#000000;font-family:Calibri;font-size:0.333344em}
.st3 {fill:#ffc000;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
.st4 {fill:#000000;font-family:Calibri;font-size:0.499992em}
.st5 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
.st6 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:1}
.st7 {fill:none;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
.st8 {stroke:#4bacc6;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
.st9 {font-size:1em}
.st10 {marker-end:url(#mrkr4-59);stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
.st11 {fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1;stroke-width:0.22935779816514}
.st12 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
]]>
</style>
<defs id="Markers">
<g id="lend4">
<path d="M 2 1 L 0 0 L 2 -1 L 2 1 " style="stroke:none"/>
</g>
<marker id="mrkr4-59" class="st11" refX="-8.72" orient="auto" markerUnits="strokeWidth" overflow="visible">
<use xlink:href="#lend4" transform="scale(-4.36,-4.36) "/>
</marker>
</defs>
<g>
<title>Page-1</title>
<g id="shape116-1" transform="translate(38.7567,-139.932)">
<title>Rectangle.116</title>
<desc>DESC</desc>
<rect x="0" y="143.783" width="79.3701" height="4.53543" class="st1"/>
<text x="35.49" y="147.25" class="st2">DESC</text> </g>
<g id="shape117-4" transform="translate(38.7567,-130.935)">
<title>Rectangle.117</title>
<desc>CSE - RO</desc>
<rect x="0" y="139.605" width="79.3701" height="8.71293" class="st3"/>
<text x="29.35" y="145.76" class="st4">CSE - RO</text> </g>
<g id="shape118-7" transform="translate(38.5344,-4.54823)">
<title>Rectangle.118</title>
<rect x="0" y="29.8973" width="79.5923" height="118.421" class="st1"/>
</g>
<g id="shape119-9" transform="translate(41.225,-5.80807)">
<title>Rectangle.119</title>
<desc>COREBOOT_RO</desc>
<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st5"/>
<text x="18.32" y="135.95" class="st4">COREBOOT_RO</text> </g>
<g id="shape120-12" transform="translate(41.225,-34.1545)">
<title>Rectangle.120</title>
<desc>RW_MISC</desc>
<rect x="0" y="143.907" width="74.3581" height="4.41113" class="st5"/>
<text x="29.12" y="147.31" class="st2">RW_MISC</text> </g>
<g id="shape121-15" transform="translate(41.225,-38.7215)">
<title>Rectangle.121</title>
<desc>FW_MAIN_B</desc>
<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
<text x="21.52" y="129.37" class="st4">FW_MAIN_B</text> </g>
<g id="shape122-18" transform="translate(41.225,-67.0679)">
<title>Rectangle.122</title>
<desc>FW_MAIN_A</desc>
<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
<text x="21.41" y="129.37" class="st4">FW_MAIN_A</text> </g>
<g id="shape123-21" transform="translate(3.88308,-0.375)">
<title>Sheet.123</title>
<desc>0x1FFFFFF</desc>
<rect x="0" y="137.688" width="41.4007" height="10.6299" class="st7"/>
<text x="8.09" y="144.8" class="st4">0x1FFFFFF</text> </g>
<g id="shape124-24" transform="translate(21.7488,-138.564)">
<title>Sheet.124</title>
<desc>0x0</desc>
<rect x="0" y="138.939" width="21.2598" height="9.37934" class="st7"/>
<text x="6.29" y="145.43" class="st4">0x0</text> </g>
<g id="shape125-27" transform="translate(41.2627,-96.0443)">
<title>Rectangle.125</title>
<desc>RW_LEGACY</desc>
<rect x="0" y="122.448" width="74.3581" height="25.8706" class="st5"/>
<text x="27.04" y="136.58" class="st2">RW_LEGACY</text> </g>
<g id="shape126-30" transform="translate(119.253,-6.75295)">
<title>Right Brace.126</title>
<path d="M-0 148.32 A9.42279 2.96575 -180 0 0 5.11 146.6 L5.11 135.46 L10.21 135.46 L5.11 135.46 L5.11 124.32 A9.42279
2.96575 -180 0 0 0 122.6" class="st8"/>
</g>
<g id="shape127-33" transform="translate(120.961,-10.2963)">
<title>Sheet.127</title>
<desc>HW WP</desc>
<rect x="0" y="137.688" width="31.1811" height="10.6299" class="st7"/>
<text x="6.16" y="144.8" class="st4">HW WP</text> </g>
<g id="shape128-36" transform="translate(119.43,-123.061)">
<title>Right Brace.128</title>
<path d="M-0 148.32 a10.4615 0.900102 -180 0 0 5.66929 -0.520272 L5.67 144.42 L11.34 144.42 L5.67 144.42 L5.67 141.03
a10.4615 0.900102 -180 0 0 -5.66929 -0.520272" class="st8"/>
</g>
<g id="shape129-39" transform="translate(126.517,-119.597)">
<title>Sheet.129</title>
<desc>SPI Controller WP via descriptor</desc>
<rect x="0" y="138.043" width="45.3543" height="10.2756" class="st7"/>
<text x="5.53" y="141.98" class="st2">SPI Controller WP via <tspan x="14.37" dy="1.2em" class="st9">descriptor</tspan></text> </g>
<g id="group130-43" transform="translate(42.8947,-77.0772)">
<title>Sheet.130</title>
<g id="shape131-44">
<title>Rectangle.423</title>
<desc>CSE-RW</desc>
<rect x="0" y="141.232" width="70.8661" height="7.08661" class="st3"/>
<text x="25.77" y="146.58" class="st4">CSE-RW</text> </g>
</g>
<g id="group132-47" transform="translate(42.8947,-48.7307)">
<title>Sheet.132</title>
<g id="shape133-48">
<title>Rectangle.423</title>
<desc>CSE-RW</desc>
<rect x="0" y="141.232" width="70.8661" height="7.08661" class="st3"/>
<text x="25.77" y="146.58" class="st4">CSE-RW</text> </g>
</g>
<g id="shape134-51" transform="translate(38.6427,-123.114)">
<title>Rectangle.134</title>
<desc>CSE-RW</desc>
<rect x="0" y="140.497" width="79.3701" height="7.82103" class="st3"/>
<text x="30.03" y="146.21" class="st4">CSE-RW</text> </g>
<g id="shape135-54" transform="translate(41.225,-52.8947)">
<title>Universal connector.473</title>
<path d="M0 148.32 L-8.38 148.32 A8.37776 8.37776 0 0 1 -16.76 139.94 L-16.76 111.25 L-16.76 81.27 A7.08661 7.08661 0
0 1 -9.67 74.19 L-9.12 74.19" class="st10"/>
</g>
<g id="shape136-60" transform="translate(41.225,-81.2411)">
<title>Universal connector.136</title>
<path d="M0 148.32 L-8.38 148.32 A8.37776 8.37776 0 0 1 -16.76 139.94 L-16.76 125.43 L-16.76 109.62 A7.08661 7.08661
0 0 1 -9.67 102.53 L-9.12 102.53" class="st10"/>
</g>
<g id="shape138-65" transform="translate(-124.557,86.8317) rotate(-90)">
<title>Sheet.138</title>
<desc>CSE RW copied during an update</desc>
<rect x="0" y="124.932" width="58.1102" height="23.3858" class="st7"/>
<text x="10.77" y="134.83" class="st4">CSE RW copied <tspan x="8.15" dy="1.2em" class="st9">during an update</tspan></text> </g>
<g id="shape139-69" transform="translate(119.43,-133.052)">
<title>Right Brace.139</title>
<path d="M0 148.32 a10.4615 0.736641 -180 0 0 5.66929 -0.425789 L5.67 145.12 L11.34 145.12 L5.67 145.12 L5.67 142.36
a10.4615 0.736641 -180 0 0 -5.66929 -0.425789" class="st8"/>
</g>
<g id="shape140-72" transform="translate(127.934,-133.061)">
<title>Sheet.140</title>
<desc>GRP0 Protected</desc>
<rect x="0" y="140.523" width="35.4331" height="7.79528" class="st7"/>
<text x="4.86" y="145.62" class="st2">GRP0 Protected</text> </g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 7.7 KiB

95
Documentation/soc/intel/cse_fw_update/Layout_before.svg Normal file
View File

@@ -0,0 +1,95 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by Microsoft Visio, SVG Export Layout_before.svg Page-1 -->
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ev="http://www.w3.org/2001/xml-events"
width="2.3058in" height="2.05998in" viewBox="0 0 166.017 148.318" xml:space="preserve" color-interpolation-filters="sRGB"
class="st11">
<style type="text/css">
<![CDATA[
.st1 {fill:#ffffff;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
.st2 {fill:#000000;font-family:Calibri;font-size:0.333344em}
.st3 {fill:#ffc000;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
.st4 {fill:#000000;font-family:Calibri;font-size:0.499992em}
.st5 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.24}
.st6 {fill:#a5a5a5;stroke:#000000;stroke-linecap:round;stroke-linejoin:round;stroke-width:1}
.st7 {fill:none;stroke:none;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
.st8 {stroke:#4bacc6;stroke-linecap:round;stroke-linejoin:round;stroke-width:0.75}
.st9 {fill:#000000;font-family:Calibri;font-size:0.416656em}
.st10 {font-size:1em}
.st11 {fill:none;fill-rule:evenodd;font-size:12px;overflow:visible;stroke-linecap:square;stroke-miterlimit:3}
]]>
</style>
<g>
<title>Page-1</title>
<g id="shape87-1" transform="translate(35.2486,-139.932)">
<title>Rectangle.178</title>
<desc>DESC</desc>
<rect x="0" y="143.783" width="79.3701" height="4.53543" class="st1"/>
<text x="35.49" y="147.25" class="st2">DESC</text> </g>
<g id="shape88-4" transform="translate(35.2486,-122.945)">
<title>Rectangle.179</title>
<desc>CSME/PMC</desc>
<rect x="0" y="131.615" width="79.3701" height="16.7031" class="st3"/>
<text x="25.8" y="141.02" class="st4">CSME/PMC</text> </g>
<g id="shape89-7" transform="translate(35.0263,-4.54823)">
<title>Rectangle.180</title>
<rect x="0" y="29.8973" width="79.5923" height="118.421" class="st1"/>
</g>
<g id="shape90-9" transform="translate(37.7169,-5.80807)">
<title>Rectangle.181</title>
<desc>COREBOOT_RO</desc>
<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st5"/>
<text x="18.32" y="135.95" class="st4">COREBOOT_RO</text> </g>
<g id="shape91-12" transform="translate(37.7169,-34.1545)">
<title>Rectangle.182</title>
<desc>RW_MISC</desc>
<rect x="0" y="143.907" width="74.3581" height="4.41113" class="st5"/>
<text x="29.12" y="147.31" class="st2">RW_MISC</text> </g>
<g id="shape92-15" transform="translate(37.7169,-38.7215)">
<title>Rectangle.183</title>
<desc>FW_MAIN_B</desc>
<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
<text x="21.52" y="129.37" class="st4">FW_MAIN_B</text> </g>
<g id="shape93-18" transform="translate(37.7169,-67.0679)">
<title>Rectangle.184</title>
<desc>FW_MAIN_A</desc>
<rect x="0" y="119.972" width="74.3581" height="28.3465" class="st6"/>
<text x="21.41" y="129.37" class="st4">FW_MAIN_A</text> </g>
<g id="shape94-21" transform="translate(0.375,-0.375)">
<title>Sheet.94</title>
<desc>0x1FFFFFF</desc>
<rect x="0" y="137.688" width="41.4007" height="10.6299" class="st7"/>
<text x="8.09" y="144.8" class="st4">0x1FFFFFF</text> </g>
<g id="shape95-24" transform="translate(18.2407,-138.564)">
<title>Sheet.95</title>
<desc>0x0</desc>
<rect x="0" y="138.939" width="21.2598" height="9.37934" class="st7"/>
<text x="6.29" y="145.43" class="st4">0x0</text> </g>
<g id="shape106-27" transform="translate(37.7546,-96.0443)">
<title>Rectangle.106</title>
<desc>RW_LEGACY</desc>
<rect x="0" y="122.448" width="74.3581" height="25.8706" class="st5"/>
<text x="27.04" y="136.58" class="st2">RW_LEGACY</text> </g>
<g id="shape113-30" transform="translate(115.744,-6.75295)">
<title>Right Brace.398</title>
<path d="M-0 148.32 A9.42279 2.96575 -180 0 0 5.11 146.6 L5.11 135.46 L10.21 135.46 L5.11 135.46 L5.11 124.32 A9.42279
2.96575 -180 0 0 0 122.6" class="st8"/>
</g>
<g id="shape96-33" transform="translate(117.453,-10.2963)">
<title>Sheet.96</title>
<desc>HW WP</desc>
<rect x="0" y="137.688" width="31.1811" height="10.6299" class="st7"/>
<text x="6.16" y="144.8" class="st4">HW WP</text> </g>
<g id="shape115-36" transform="translate(116.508,-123.131)">
<title>Right Brace.115</title>
<path d="M0 148.32 A10.4615 2.27029 -180 0 0 5.67 147.01 L5.67 138.48 L11.34 138.48 L5.67 138.48 L5.67 129.95 A10.4615
2.27029 -180 0 0 0 128.63" class="st8"/>
</g>
<g id="shape97-39" transform="translate(120.288,-122.265)">
<title>Sheet.97</title>
<desc>SPI Controller WP via descriptor</desc>
<rect x="0" y="124.932" width="45.3543" height="23.3858" class="st7"/>
<text x="4.71" y="135.13" class="st9">SPI Controller WP <tspan x="8.83" dy="1.2em" class="st10">via descriptor</tspan></text> </g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 5.0 KiB

127
Documentation/soc/intel/cse_fw_update/cse_fw_update.md Normal file
View File

@@ -0,0 +1,127 @@
CSE FW update mechanism for devices in field
## Introduction
CSE Firmware and PMC Firmware are critical components of Intel SoCs.
CSE and PMC cooperate by providing platform services during boot and other
power transition flows.
## Problem Statement
Currently, on Chromium OS Systems, CSE region is not updatable. So, new CSE FW
versions that are released by Intel to address important functional and security
bugs post-product launch will not be available to the end-user. Hence, the proposed
solution allows in-field CSE FW update to propagate those bug fixes
to end user platforms.
## Design Proposal
### CSE FW design Proposal:
Key Elements:
- CSE FW layout is composed of two bootable partitions (RO Recovery Partition
and RW Normal Partition).
- Boot partition selection: An API-based mechanism is used to decide from which partition
CSE will boot.
- The HECI APIs below will be supported in this CSE FW:
- HMRFPO_ENABLE: This command requests the CSE enter a mode in which writes to
the CSE region from the CSE are disabled. It also grants temporary write access
to the RW partition from the host (RO is still protected by GPR0).
- GET_PARTITION_INFO: The command retrieves information for each boot partition from CSE
like version, start/end offsets of a partition within CSE region, and boot
partition status. Also, it provides below information:
- The current boot partition which was used during this boot,
- The boot partition that will be used on the next CSE reset
- The number of boot partitions available in the CSE region
- SET_BOOT_PARTITION_INFO: This command allows the firmware to request the
CSE to boot from either its RO or RW partition at its next reset.
- DATA_CLEAR: This command requests the CSE to reset its data partition back
to manufacturing defaults
FW Layout, RW/RO Partitions:
The CSE RO partition is the first in the CSE boot order, hence it will be used
out of G3. RO partition contains minimum CSE code capable to boot platform and
execute FW update of RW partition. In addition to CSE code, the RO partition also
contains PMC FW patch and other CSE-loadable platform FW components.
RW partition contains fully operational CSE FW, PMC FW, other CSE loadable
platform FW components.
Boot partition selection:
CSE FW shall support 2 APIs to get boot partition info, and set boot partition
info to notify CSE to select the partition on the next boot.
### HOST FW Design proposal:
Key Elements:
- Build time artifacts:
CSE RW Version update binary - The FW shall pack CSE RW update blob and
corresponding version binary which contains version of the CSE RW blob.
- FW Update:
coreboot will implement the logic to compare the CSE's FW version with CBFS
CSE RW binary's version in the firmware slot (FW_MAIN_A/FW_MAIN_B) and update
the CSE RW region if there is a version mismatch. If there is no version
mismatch, firmware skips CSE FW update.
- Handling of CSE FW Downgrade:
coreboot will send DATA_CLEAR HECI command when there is a CSE FW downgrade.
This must be done to avoid data mismatch due to CSE FW downgrade. Further,
CSE will restore the data back to manufacturing defaults after data reset.
## Implementation Details
To enable CSE FW update flow the following changes are required in coreboot:
* Descriptor change may be required to accommodate CSE binary. The CSE binary is tied with
a platform. So CSE size may vary from one platform to another.
* FMAP changes may be required to accommodate CSE binary and CSE RW blob in the RW CBFS region.
Please check platform specific CSE kit for CSE binary information.
* CSE Lite SKU binary and CSE RW blob
* Makefile change to pack CSE RW binaries in the CBFS
* Implementation of update flow:
- Get CSE boot partition info using GET_BOOT_PARTITION_INFO HECI command.
- Get the cbfs_me_rw.version from the currently selected RW slot.
- If the version from the above 2 locations don't match, then start CSE FW update.
- If CSE is not booting from RO, then
- Set the CSE's next boot partition to RO using SET_BOOT_PARTITION_INFO
HECI command.
- Send GLOBAL_RESET HECI command to reset the system.
- If RW update is a CSE FW downgrade, then coreboot has to send
DATA_CLEAR command to clear run time data of CSE.
- Enable HMRFPO Mode (Host ME Region Flash Protection Override) by
sending HMRFPO_ENABLE HECI command to CSE.
- Erase and Copy the CBFS CSE RW to CSE RW partition
- Set CSE's next boot partition to RW.
- Trigger Global Reset which resets both CSE and Host.
Then system should boot with the updated CSE.
* The resulting flash layout is shown below:
![Flash Layout](./Layout_before.svg) ![FlashLayout](./Layout_after.svg)
- Typical boot flow
- Vboot selects the RW FW (FW_MAIN_A or FW_MAIN_B) to boot.
- coreboot skips CSE FW update flow if boot mode is recovery.
- If CSE RW blob is not locatable in the CBFS, then RW Firmware skips update flow
and sends SET_BOOT_PARTITION_INFO command to switch CSE to boot from RW
and issues Global Reset if CSE is already not booting from RW partition.
- The RW firmware will compare the CSE RW version with CSE RW blob in the slot.
- If there is a mismatch, then firmware will carry out update flow as explained before.

2
Documentation/soc/intel/index.md
View File

@@ -8,5 +8,7 @@ This section contains documentation about coreboot on specific Intel SOCs.
- [FSP](fsp/index.md)
- [Ice Lake/9th Gen Core-i series](icelake/index.md)
- [MP Initialization](mp_init/mp_init.md)
- [Microcode Updates](microcode.md)
- [Firmware Interface Table](fit.md)
- [Apollolake](apollolake/index.md)
- [CSE FW Update](cse_fw_update/cse_fw_update_model.md)

136
Documentation/soc/intel/microcode.md Normal file
View File

@@ -0,0 +1,136 @@
# Microcode updates
When booting a modern x86 platform, one task of the firmware is to update
[microcode] to correct hardware bugs and mitigate security issues found
after silicon has been shipped. The [Pentium FDIV bug] could have been
fixed with a microcode update, had the Pentium used updateable microcode.
Starting with the Pentium Pro, CPU microcode can be updated by software.
As per BIOS Writer's Guides, Intel defines a processor as the silicon and
the accompanying microcode update, and considers any processor that does
not have its microcode updated to be running out of specification. This
suggests that microcode is a crucial ingredient for correct operation.
On multi-processor or Hyper-Threading-enabled systems, each thread has
its own microcode. Therefore, microcode must be updated on every thread.
## When to update microcode
When a CPU core comes out of reset, it uses microcode from an internal
ROM. This “default” microcode often contains bugs, so it needs to be
updated as soon as possible. For example, Core 2 CPUs can boot without
microcode updates, but have stability problems. On newer platforms,
it is nearly impossible to boot without having updated the microcode.
On some platforms, an updated microcode is required in order to enable
Cache-As-RAM or to be able to successfully initialize the DRAM.
Plus, microcode needs to be loaded multiple times. Intel Document 504790
explains that this is because of so-called *enhanced microcode updates*,
which are large updates with errata workarounds for both core and uncore.
In order to correctly apply enhanced microcode updates, the [MP-Init]
algorithm must be decomposed into multiple initialization phases.
### Firmware Interface Table
Beginning with 4th generation Intel Core processors, it is possible for
microcode to be updated before the CPU is taken out of reset. This is
accomplished by means of [FIT], a data structure which contains pointers
to various firmware ingredients in the BIOS flash.
In rare cases, FIT microcode updates may not be successful. Therefore,
it is important to check that the microcode is up-to-date and, if not,
update it. This needs to be done as early as possible, like on older
processor generations without FIT support.
Whether all threads on a processor get their microcode updated through
FIT is not clear. According to Intel Documents 493770 and 535094, FIT
microcode updates are applied to all cores within the package. However,
Intel Document 550049 states that FIT microcode updates are applied to
all threads within the package.
## SMM bring-up
Prior to SMM relocation, microcode must have been updated at least once.
## Multi-Processor bring-up
The BWG briefly describes microcode updates as part of the *MP-Init*.
### MP-Init
As part of the [MP-Init] sequence, two microcode updates are required.
* The first update must happen as soon as one AP comes out of reset.
* The second update must happen after the MP-Init sequence has written MTRRs,
PRMRR, DCU mode and prefetcher configuration, SMM has been relocated, but
before clearing the MCE banks.
## Recommendations
The Linux kernel developer's recommendations are:
* Serialize microcode updates if possible.
* Idle as many APs as possible while updating.
* Idle the sibling thread on a Hyper-Threading enabled CPU while updating.
## Platform BWGs
The requirements specified in BWGs differ between platforms:
### Sandy Bridge
* Before setting up Cache-As-RAM, load microcode update into the SBSP.
* Losing (non-SBSP) NBSPs must load their microcode update before being placed
back in the wait-for-SIPI state.
* Sibling threads on HT must use a semaphore.
* Microcode update loading has been done prior to SMM relocation.
* In MP-Init the microcode update on an AP must be done before initializing the
cache, MTRRs, SMRRs and PRMRRs.
* In MP-Init a second update must happen on all threads after initializing the
cache, MTRRs, SMRRs and PRMRRs.
Refer to Intel Document 504790 for details.
### Haswell/Broadwell Client
* A microcode update must exist in FIT.
* During the race to the BSP semaphore, each NBSP must load its microcode update.
* All HT enabled threads can load microcode in parallel. However, the
IA32_BIOS_UPDT_TRIG MSR is core-scoped, just like on other platforms.
* Microcode update loading has been done prior to SMM relocation.
* In MP-Init the microcode update on an AP must be done before initializing the
cache, MTRRs, SMRRs and EMRR.
* In MP-Init a second update must happen on all threads after initializing the
cache, MTRRs, SMRRs and EMRR and after SMM initialization.
Refer to Intel Document 493770 and 535094 for details.
### Broadwell Server
* A microcode update must exist in FIT.
* Before setting up Cache-As-RAM, load microcode update into each BSP.
* In MP-Init the microcode update on an AP must be done before initializing the
cache, MTRRs, SMRRs and EMRR.
* In MP-Init a second update must happen on all threads after initializing the
cache, MTRRs, SMRRs and EMRR and after SMM initialization.
Refer to Intel Document 546625 for details.
### Skylake/Kaby Lake/Coffee Lake/Whiskey Lake/Comet Lake
* A microcode update must exist in FIT.
* Before setting up Cache-As-RAM, load microcode update into the BSP.
* Microcode update loading has been done prior to SMM relocation.
* In MP-Init the first update must happen as soon as one AP comes out of reset.
* In MP-Init the second update must happen after the MP-Init sequence has
written MTRRs, PRMRR, DCU mode and prefetcher configuration, but before
clearing the MCE banks.
* Microcode updates must happen on all threads.
* Sibling threads on HT should use a semaphore.
Refer to Intel Document 550049 for details.
[microcode]: https://en.wikipedia.org/wiki/Microcode
[Pentium FDIV bug]: https://en.wikipedia.org/wiki/Pentium_FDIV_bug
[FIT]: fit.md
[SDM]: https://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf
[MP-Init]: mp_init/mp_init.md

302
Documentation/technotes/asan.md Normal file
View File

@@ -0,0 +1,302 @@
# Address Sanitizer
Memory safety is hard to achieve. We, as humans, are bound to make mistakes in
our code. While it may be straightforward to detect memory corruption bugs in
few lines of code, it becomes quite challenging to find those bugs in a massive
code. In such cases, 'Address Sanitizer' may prove to be useful and could help
save time.
[Address Sanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer)
, also known as ASan, is a runtime memory debugger designed to find
out-of-bounds accesses and use-after-scope bugs. coreboot has an in-built
Address Sanitizer. Therefore, it is advised to take advantage of this debugging
tool while working on large patches. This would further help to ensure code
quality and make runtime code more robust.
## Types of errors detected
ASan in coreboot catches the following types of memory bugs:
### Stack buffer overflow
Example stack-out-of-bounds:
```c
void foo()
{
int stack_array[5] = {0};
int i, out;
for (i = 0; i < 10; i++)
out = stack_array[i];
}
```
In this example, the array is of length 5 but it is being read even beyond the
index 4.
### Global buffer overflow
Example global-out-of-bounds:
```c
char a[] = "I use coreboot";
void foo()
{
char b[] = "proprietary BIOS";
strcpy(a + 6, b);
}
```
In this example,
> well, you are replacing coreboot with proprietary BIOS. In any case, that's
an "error".
Let's come to the memory bug. The string 'a' is of length 14 but it is being
written to even beyond that.
### Use after scope
Example use-after-scope:
```c
volatile int *p = 0;
void foo() {
{
int x = 0;
p = &x;
}
*p = 5;
}
```
In this example, the value 5 is written to an undefined address instead of the
variable 'x'. This happens because 'x' can't be accessed outside its scope.
## Using ASan
In order to enable ASan on a supported platform,
select `Address sanitizer support` from `General setup` menu while configuring
coreboot.
Then build coreboot and run the image as usual. If your code contains any of the
above-mentioned memory bugs, ASan will report them in the console log as shown
below:
```text
ASan: <bug type> in <ip>
<access type> of <access size> bytes at addr <access address>
```
where,
`bug type` is either `stack-out-of-bounds`, `global-out-of-bounds` or
`use-after-scope`,
`ip` is the address of the last good instruction before the bad access,
`access type` is either `Read` or `Write`,
`access size` is the number of bytes read or written, and
`access address` is the memory location which is accessed while the error
occurs.
Next, you have to use `ip` to retrieve the instruction which causes the error.
Since stages in coreboot are relocated, you need to normalize `ip`. For this,
first subtract the start address of the stage from `ip`. Then, read the section
headers from `<stage>.debug` file to determine the offset of the text segment.
Add this offset to the difference you calculated earlier. Let's call the
resultant address `ip'`.
Next, read the contents of the symbol table and search for a function having
an address closest to `ip'`. This is the function in which our memory bug is
present. Let's denote the address of this function by `ip''`.
Finally, read the assembly contents of the object file where this function is
present. Look for the affected function. Here, the instruction which exists at
the offset `ip' - ip''` corresponds to the address `ip`. Therefore, the very
next instruction is the one which causes the error.
To see ASan in action, let's take an example. Suppose, there is a
stack-out-of-bounds error in cbfs.c that we aren’t aware of and we want ASan
to help us detect it.
```c
int cbfs_boot_region_device(struct region_device *rdev)
{
int array[5], i;
boot_device_init();
for (i = 10; i > 0; i--)
array[i] = i;
return vboot_locate_cbfs(rdev) &&
fmap_locate_area_as_rdev("COREBOOT", rdev);
}
```
First, we enable ASan from the configuration menu as shown above. Then, we
build coreboot and run the image.
ASan reports the following error in the console log:
```text
ASan: stack-out-of-bounds in 0x7f7432fd
Write of 4 bytes at addr 0x7f7c2ac8
```
Here 0x7f7432fd is `ip` i.e. the address of the last good instruction before
the bad access. First we have to normalize this address as stated above.
As per the console log, this error happened in ramstage and the stage starts
from 0x7f72c000. So, let’s look at the sections headers of ramstage from
`ramstage.debug`.
```text
$ objdump -h build/cbfs/fallback/ramstage.debug
build/cbfs/fallback/ramstage.debug: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00070b20 00e00000 00e00000 00001000 2**12
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .ctors 0000036c 00e70b20 00e70b20 00071b20 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
2 .data 0001c8f4 00e70e8c 00e70e8c 00071e8c 2**2
CONTENTS, ALLOC, LOAD, RELOC, DATA
3 .bss 00012940 00e8d780 00e8d780 0008e780 2**7
ALLOC
4 .heap 00004000 00ea00c0 00ea00c0 0008e780 2**0
ALLOC
```
As you can see, the offset of the text segment is 0x00e00000. Let's subtract the
start address of the stage from `ip` and add this offset to the difference. The
resultant address i.e. `ip'` is 0x00e172fd.
Next, we read the contents of the symbol table and search for a function having
an address closest to 0x00e172fd.
```text
$ nm -n build/cbfs/fallback/ramstage.debug
........
........
00e17116 t _GLOBAL__sub_I_65535_1_gfx_get_init_done
00e17129 t tohex16
00e171db T cbfs_load_and_decompress
00e1729b T cbfs_boot_region_device
00e17387 T cbfs_boot_locate
00e1740d T cbfs_boot_map_with_leak
00e174ef T cbfs_boot_map_optionrom
........
........
```
The symbol having an address closest to 0x00e172fd is `cbfs_boot_region_device` and
its address i.e. `ip''` is 0x00e1729b.
Now, as we know the affected function, let's read the assembly contents of
`cbfs_boot_region_device()` which is present in `cbfs.o` to find the faulty
instruction.
```text
$ objdump -d build/ramstage/lib/cbfs.o
........
........
51: e8 fc ff ff ff call 52 <cbfs_boot_region_device+0x52>
56: 83 ec 0c sub $0xc,%esp
59: 57 push %edi
5a: 83 ef 04 sub $0x4,%edi
5d: e8 fc ff ff ff call 5e <cbfs_boot_region_device+0x5e>
62: 83 c4 10 add $0x10,%esp
65: 89 5f 04 mov %ebx,0x4(%edi)
68: 4b dec %ebx
69: 75 eb jne 56 <cbfs_boot_region_device+0x56>
........
........
```
Here, we look for the instruction present at the offset 62 i.e. `ip' - ip''`.
The instruction is `add $0x10,%esp` and it corresponds to
`for (i = 10; i > 0; i--)` in our code. It means the very next instruction
i.e. `mov %ebx,0x4(%edi)` is the one that causes the error. Now, as we look at
C code of `cbfs_boot_region_device()` again, we find that this instruction
corresponds to `array[i] = i`.
Voilà! We just caught the memory bug using ASan.
## Supported platforms
Presently, the following architectures support ASan in ramstage:
```eval_rst
+------------------+--------------------------------+
| Architecture | Notes |
+==================+================================+
| x86 | Support for all x86 platforms |
+------------------+--------------------------------+
```
And in romstage ASan is available on the following platforms:
```eval_rst
+---------------------+-----------------------------+
| Platform | Notes |
+=====================+=============================+
| QEMU i440-fx | |
+---------------------+-----------------------------+
| Intel Apollo Lake | |
+---------------------+-----------------------------+
| Intel Haswell | |
+---------------------+-----------------------------+
```
Alternatively, you can use `grep` to view the list of platforms that support
ASan in romstage:
$ git grep "select HAVE_ASAN_IN_ROMSTAGE"
If the x86 platform you are using is not listed here, there is
still a chance that it supports ASan in romstage.
To test it, select `HAVE_ASAN_IN_ROMSTAGE` from the Kconfig file in the
platform's dedicated directory. Then, enable ASan from the config menu as
indicated in the previous section.
If you are able to build coreboot without any errors and boot cleanly, that
means the platform supports ASan in romstage. In that case, please upload a
patch on Gerrit selecting this config option using 'ASan' topic. Also, update
the platform name in the table.
However, if you end up in compilation errors or the linker error saying that
the cache got full, additional steps need to be taken to enable ASan in
romstage on the platform. While compile errors could be resolved easily and
therefore ASan in romstage has a good chance to be supported, a full cache is
an indication that it is way more work or even likely impossible to enable
ASan in romstage.
## Future work
### Heap buffer overflow
Presently, ASan doesn't detect out-of-bounds accesses for the objects defined
in heap.
To add support for these type of memory bugs, you have to make sure that
whenever some block of memory is allocated in the heap, the surrounding areas
(redzones) are poisoned. Correspondingly, these redzones should be unpoisoned
when the memory block is de-allocated.
### ASan on other architectures
The following points should help when adding support for ASan to other
architectures like ARM or RISC-V:
* Enabling ASan in ramstage on other architectures should be easy. You just
have to make sure the shadow memory is initialized as early as possible when
ramstage is loaded. This can be done by making a function call to `asan_init()`
at the appropriate place.
* For romstage, you have to find out if there is enough room in the cache to fit
the shadow memory region. For this, find the boundary linker symbols for the
region you'd want to run ASan on, excluding the hardware mapped addresses.
Then define a new linker section named `asan_shadow` of size
`(_end - _start) >> 3`, where `_start` and `_end` are the linker symbols you
found earlier. This section should be appended to the region already occupied
by the coreboot program. Now build coreboot. If you don't see any errors while
building with the current translation function, ASan can be enabled on that
platform.
* The shadow region we currently use consumes memory equal to 1/8th of the
program memory. So, if you end up in a linker error saying that the memory got
full, you'll have to use a more compact shadow region. In that case, the
translation function could be something like
`shadow = (mem >> 7) | shadow_offset`. Since the stack buffers are protected by
the compiler, you'll also have to create a GCC patch forcing it to use the new
translation function for this particular architecture.
* Once you are sure that the architecture supports ASan in ramstage, select
`HAVE_ASAN_IN_RAMSTAGE` from the Kconfig file of that architecture. Similarly,
if the platform supports ASan in romstage, select `HAVE_ASAN_IN_ROMSTAGE` from
the platform's dedicated Kconfig file.
### Post-processing script
Unlike Linux, coreboot doesn't have `%pS` printk format to dereference pointer
to its symbolic name. Therefore, we normalise the pointer address manually to
determine the name of the affected function and further use it to find the
instruction which causes the error.
A custom script can be written to automate this process.

1
Documentation/technotes/index.md
View File

@@ -3,3 +3,4 @@
* [Dealing with Untrusted Input in SMM](2017-02-dealing-with-untrusted-input-in-smm.md)
* [Rebuilding coreboot image generation](2015-11-rebuilding-coreboot-image-generation.md)
* [Unit testing coreboot](2020-03-unit-testing-coreboot.md)
* [Address Sanitizer](asan.md)

16
Documentation/tutorial/part1.md
View File

@@ -19,9 +19,21 @@ Download, configure, and build coreboot
$ cd coreboot
### Step 3 - Build the coreboot toolchain
Please note that this can take a significant amount of time.
Please note that this can take a significant amount of time. Use `CPUS=` to
specify number of `make` jobs to run in parallel.
$ make crossgcc-i386 CPUS=$(nproc)
This will list toolchain options and supported architectures:
$ make help_toolchain
Here are some examples:
$ make crossgcc-i386 CPUS=$(nproc) # build i386 toolchain
$ make crossgcc-aarch64 CPUS=$(nproc) # build Aarch64 toolchain
$ make crossgcc-riscv CPUS=$(nproc) # build RISC-V toolchain
Note that the i386 toolchain is currently used for all x86 platforms, including
x86_64.
Also note that you can possibly use your system toolchain, but the results are
not reproducible, and may have issues, so this is not recommended. See step 5

8
MAINTAINERS
View File

@@ -404,7 +404,6 @@ M: Julius Werner <jwerner@chromium.org>
S: Supported
F: src/arch/arm/
F: src/arch/arm64/
F: src/soc/mediatek/
F: src/soc/nvidia/
F: src/soc/rockchip/
F: util/nvidia/
@@ -547,10 +546,15 @@ F: src/soc/intel/xeon_sp
F: src/vendorcode/intel/fsp/fsp2_0/skylake_sp
F: src/vendorcode/intel/fsp/fsp2_0/copperlake_sp
MEDIATEK SOCS
M: Hung-Te Lin <hungte@chromium.org>
S: Supported
F: src/soc/mediatek
ORPHANED ARM SOCS
S: Orphaned
F: src/cpu/armltd/
F: src/cpu/ti/
F: src/soc/ti/
F: src/soc/qualcomm/
F: src/soc/samsung/
F: util/exynos/

41
Makefile.inc
View File

@@ -13,6 +13,7 @@ CONFIG_CBFS_PREFIX:=$(call strip_quotes,$(CONFIG_CBFS_PREFIX))
CONFIG_FMDFILE:=$(call strip_quotes,$(CONFIG_FMDFILE))
CONFIG_DEVICETREE:=$(call strip_quotes, $(CONFIG_DEVICETREE))
CONFIG_OVERRIDE_DEVICETREE:=$(call strip_quotes, $(CONFIG_OVERRIDE_DEVICETREE))
CONFIG_CHIPSET_DEVICETREE:=$(call strip_quotes, $(CONFIG_CHIPSET_DEVICETREE))
CONFIG_MEMLAYOUT_LD_FILE:=$(call strip_quotes, $(CONFIG_MEMLAYOUT_LD_FILE))
#######################################################################
@@ -81,7 +82,7 @@ subdirs-y += $(wildcard src/soc/*/*) $(wildcard src/northbridge/*/*)
subdirs-y += src/superio
subdirs-y += $(wildcard src/drivers/*) $(wildcard src/drivers/*/*)
subdirs-y += src/cpu src/vendorcode
subdirs-y += util/cbfstool util/sconfig util/nvramtool util/pgtblgen
subdirs-y += util/cbfstool util/sconfig util/nvramtool util/pgtblgen util/amdfwtool
subdirs-y += util/futility util/marvell util/bincfg util/supermicro
subdirs-y += $(wildcard src/arch/*)
subdirs-y += src/mainboard/$(MAINBOARDDIR)
@@ -264,12 +265,14 @@ REDUNDANT_OFFSET_REMARK = 2158
# "Multiple types (Device object requires either a _HID or _ADR, but not both)"
MULTIPLE_TYPES_WARNING = 3073
IASL_WARNINGS_LIST = $(EMPTY_RESOURCE_TEMPLATE_WARNING) $(REDUNDANT_OFFSET_REMARK)
ifeq ($(CONFIG_SOUTHBRIDGE_INTEL_LYNXPOINT)$(CONFIG_SOC_INTEL_BROADWELL),y)
IGNORED_IASL_WARNINGS = -vw $(EMPTY_RESOURCE_TEMPLATE_WARNING) -vw $(REDUNDANT_OFFSET_REMARK) -vw $(MULTIPLE_TYPES_WARNING)
else
IGNORED_IASL_WARNINGS = -vw $(EMPTY_RESOURCE_TEMPLATE_WARNING) -vw $(REDUNDANT_OFFSET_REMARK)
IASL_WARNINGS_LIST += $(MULTIPLE_TYPES_WARNING)
endif
IGNORED_IASL_WARNINGS = $(addprefix -vw , $(IASL_WARNINGS_LIST))
define asl_template
$(CONFIG_CBFS_PREFIX)/$(1).aml-file = $(obj)/$(1).aml
$(CONFIG_CBFS_PREFIX)/$(1).aml-type = raw
@@ -280,6 +283,7 @@ $(obj)/$(1).aml: $(src)/mainboard/$(MAINBOARDDIR)/$(1).asl $(obj)/config.h
@printf " IASL $$(subst $(top)/,,$$(@))\n"
$(CC_ramstage) -x assembler-with-cpp -E -MMD -MT $$(@) $$(CPPFLAGS_ramstage) -D__ACPI__ -P -include $(src)/include/kconfig.h -I$(obj) -I$(src) -I$(src)/include -I$(src)/arch/$(ARCHDIR-$(ARCH-ramstage-y))/include -I$(src)/mainboard/$(MAINBOARDDIR) $$< -o $(obj)/$(1).asl
cd $$(dir $$@); $(IASL) $(IGNORED_IASL_WARNINGS) -we -p $$(notdir $$@) $(1).asl
echo " IASL "$(IASL_WARNINGS_LIST)" warning types were ignored!"
if ! $(IASL) -d $$@ 2>&1 | grep -Eq 'ACPI (Warning|Error)'; then \
echo " IASL $$@ disassembled correctly."; \
true; \
@@ -411,6 +415,10 @@ CPPFLAGS_common += -include $(src)/commonlib/bsd/include/commonlib/bsd/compiler.
CPPFLAGS_common += -I3rdparty
CPPFLAGS_common += -D__BUILD_DIR__=\"$(obj)\"
ifeq ($(BUILD_TIMELESS),1)
CPPFLAGS_common += -D__TIMELESS__
endif
ifeq ($(CONFIG_PCI_OPTION_ROM_RUN_YABEL)$(CONFIG_PCI_OPTION_ROM_RUN_REALMODE),y)
CPPFLAGS_ramstage += -Isrc/device/oprom/include
endif
@@ -418,10 +426,10 @@ endif
CFLAGS_common += -pipe -g -nostdinc -std=gnu11
CFLAGS_common += -nostdlib -Wall -Wundef -Wstrict-prototypes -Wmissing-prototypes
CFLAGS_common += -Wwrite-strings -Wredundant-decls -Wno-trigraphs -Wimplicit-fallthrough
CFLAGS_common += -Wstrict-aliasing -Wshadow -Wdate-time -Wtype-limits -Wvla
CFLAGS_common += -Wshadow -Wdate-time -Wtype-limits -Wvla
CFLAGS_common += -Wlogical-op -Wduplicated-cond -Wdangling-else
CFLAGS_common += -fno-common -ffreestanding -fno-builtin -fomit-frame-pointer
CFLAGS_common += -ffunction-sections -fdata-sections -fno-pie
CFLAGS_common += -fstrict-aliasing -ffunction-sections -fdata-sections -fno-pie
ifeq ($(CONFIG_COMPILER_GCC),y)
# Don't add these GCC specific flags when running scan-build
ifeq ($(CCC_ANALYZER_OUTPUT_FORMAT),)
@@ -569,9 +577,6 @@ $(IFDTOOL):
cp -a $(top)/util/ifdtool/ifdtool $@
AMDFWTOOL:=$(objutil)/amdfwtool/amdfwtool
$(AMDFWTOOL): $(top)/util/amdfwtool/amdfwtool.c
@printf " HOSTCC $(subst $(obj)/,,$(@))\n"
$(HOSTCC) $(HOSTCFLAGS) -DCONFIG_ROM_SIZE=$(CONFIG_ROM_SIZE) -o $@ $<
APCB_EDIT_TOOL:=$(top)/util/apcb/apcb_edit.py
@@ -588,19 +593,28 @@ $(obj)/config.h: $(objutil)/kconfig/conf
# Creation of these is architecture and mainboard independent
DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_DEVICETREE)
SCONFIG_OPTIONS := --mainboard_devtree=$(DEVICETREE_FILE)
ifneq ($(CONFIG_OVERRIDE_DEVICETREE),)
OVERRIDE_DEVICETREE_FILE := $(src)/mainboard/$(MAINBOARDDIR)/$(CONFIG_OVERRIDE_DEVICETREE)
SCONFIG_OPTIONS += --override_devtree=$(OVERRIDE_DEVICETREE_FILE)
endif
ifneq ($(CONFIG_CHIPSET_DEVICETREE),)
CHIPSET_DEVICETREE_FILE := $(src)/$(CONFIG_CHIPSET_DEVICETREE)
SCONFIG_OPTIONS += --chipset_devtree=$(CHIPSET_DEVICETREE_FILE)
endif
DEVICETREE_STATIC_C := $(obj)/mainboard/$(MAINBOARDDIR)/static.c
DEVICETREE_STATIC_H := $(obj)/static.h
SCONFIG_OPTIONS += --output_c=$(DEVICETREE_STATIC_C)
$(DEVICETREE_STATIC_C): $(DEVICETREE_FILE) $(OVERRIDE_DEVICETREE_FILE) $(objutil)/sconfig/sconfig
DEVICETREE_STATIC_H := $(obj)/static.h
SCONFIG_OPTIONS += --output_h=$(DEVICETREE_STATIC_H)
$(DEVICETREE_STATIC_C): $(DEVICETREE_FILE) $(OVERRIDE_DEVICETREE_FILE) $(CHIPSET_DEVICETREE_FILE) $(objutil)/sconfig/sconfig
@printf " SCONFIG $(subst $(src)/,,$(<))\n"
mkdir -p $(dir $(DEVICETREE_STATIC_C))
$(objutil)/sconfig/sconfig $(DEVICETREE_FILE) $(DEVICETREE_STATIC_C) $(DEVICETREE_STATIC_H) $(OVERRIDE_DEVICETREE_FILE)
$(objutil)/sconfig/sconfig $(SCONFIG_OPTIONS)
ramstage-y+=$(DEVICETREE_STATIC_C)
romstage-y+=$(DEVICETREE_STATIC_C)
@@ -1097,7 +1111,6 @@ RAMSTAGE=
endif
$(obj)/coreboot.rom: $(obj)/coreboot.pre $(RAMSTAGE) $(CBFSTOOL) $$(INTERMEDIATE)
@printf " CBFS $(subst $(obj)/,,$(@))\n"
# The full ROM may be larger than the CBFS part, so create an empty
# file (filled with \377 = 0xff) and copy the CBFS image over it.

44
configs/config.asrock_b85m_pro4.debug_smmstore_hotplug_gcov_ubsan_em100 Normal file
View File

@@ -0,0 +1,44 @@
# Not meant for actual use. Exercises, among other things:
# + Code coverage
# + UBSAN
# + Debug options
# + SMMSTORE
# + Silicon Image SIL3114 driver
# + Genesys Logic GL9763E driver
# + EM100 support
CONFIG_COVERAGE=y
CONFIG_UBSAN=y
CONFIG_VENDOR_ASROCK=y
CONFIG_ONBOARD_VGA_IS_PRIMARY=y
CONFIG_CBFS_SIZE=0x200000
CONFIG_BOARD_ASROCK_B85M_PRO4=y
CONFIG_PCIEXP_L1_SUB_STATE=y
CONFIG_PCIEXP_CLK_PM=y
CONFIG_CONSOLE_POST=y
# CONFIG_INTEL_CHIPSET_LOCKDOWN is not set
# CONFIG_FINALIZE_USB_ROUTE_XHCI is not set
CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y
CONFIG_PCIEXP_HOTPLUG=y
CONFIG_SMMSTORE=y
CONFIG_SMMSTORE_SIZE=0x30000
CONFIG_SPI_FLASH_NO_FAST_READ=y
CONFIG_USBDEBUG=y
CONFIG_USBDEBUG_DONGLE_FTDI_FT232H=y
CONFIG_DRIVERS_SIL_3114=y
CONFIG_DRIVERS_GENESYSLOGIC_GL9763E=y
# CONFIG_SQUELCH_EARLY_SMP is not set
CONFIG_CONSOLE_SPI_FLASH=y
CONFIG_POST_DEVICE_PCI_PCIE=y
CONFIG_FATAL_ASSERTS=y
CONFIG_DEBUG_CBFS=y
CONFIG_DEBUG_SMBUS=y
CONFIG_DEBUG_SMI=y
CONFIG_DEBUG_PERIODIC_SMI=y
CONFIG_DEBUG_MALLOC=y
CONFIG_DEBUG_CONSOLE_INIT=y
CONFIG_DEBUG_SPI_FLASH=y
CONFIG_DEBUG_COVERAGE=y
CONFIG_DEBUG_BOOT_STATE=y
CONFIG_DEBUG_ADA_CODE=y
CONFIG_HAVE_EM100_SUPPORT=y
CONFIG_EM100=y

1
configs/config.emulation_qemu_x86_i440fx_debug
View File

@@ -4,6 +4,5 @@ CONFIG_FATAL_ASSERTS=y
CONFIG_DEBUG_CBFS=y
CONFIG_DEBUG_PIRQ=y
CONFIG_DEBUG_MALLOC=y
CONFIG_TRACE=y
CONFIG_DEBUG_BOOT_STATE=y
CONFIG_DEBUG_ADA_CODE=y

1
configs/config.emulation_qemu_x86_i440fx_x86_64 Normal file
View File

@@ -0,0 +1 @@
CONFIG_CPU_QEMU_X86_64=y

8
configs/config.purism_librem15_v4.txt_build_test Normal file
View File

@@ -0,0 +1,8 @@
# Not meant for actual use. Exercises Intel TXT code. Since BIOS
# and SINIT ACM blobs are missing, use something else as placeholder.
CONFIG_VENDOR_PURISM=y
CONFIG_BOARD_PURISM_LIBREM15_V4=y
CONFIG_INTEL_TXT=y
CONFIG_INTEL_TXT_BIOSACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin"
CONFIG_INTEL_TXT_SINITACM_FILE="3rdparty/blobs/cpu/intel/stm/stm.bin"
CONFIG_INTEL_TXT_LOGGING=y

0
configs/config.stm → configs/config.purism_librem15_v4_stm
View File

4
payloads/Kconfig
View File

@@ -30,7 +30,7 @@ config PAYLOAD_ELF
config PAYLOAD_FIT
bool "A FIT payload"
depends on ARCH_ARM64 || ARCH_RISCV
depends on ARCH_ARM64 || ARCH_RISCV || ARCH_ARM
select PAYLOAD_FIT_SUPPORT
help
Select this option if you have a payload image (a FIT file) which
@@ -97,7 +97,7 @@ config PAYLOAD_FIT_SUPPORT
bool "FIT support"
default n
default y if PAYLOAD_LINUX && (ARCH_ARM || ARCH_ARM64 || ARCH_RISCV)
depends on ARCH_ARM64 || ARCH_RISCV
depends on ARCH_ARM64 || ARCH_RISCV || ARCH_ARM
select FLATTENED_DEVICE_TREE
help
Select this option if your payload is of type FIT.

14
payloads/coreinfo/AUTHORS Normal file
View File

@@ -0,0 +1,14 @@
# This is the list of coreinfo authors for copyright purposes.
#
# This does not necessarily list everyone who has contributed code, since in
# some cases, their employer may be the copyright holder. To see the full list
# of contributors, and their email addresses, see the revision history in source
# control.
# Run the below commands in the coreinfo repo for additional information.
# To see a list of contributors: git log --pretty=format:%an | sort | uniq
# For patches adding or removing a name: git log -i -S "NAME" --source --all
Advanced Micro Devices, Inc.
Dave Jones
Jordan Crouse
Uwe Hermann

4
payloads/coreinfo/Kconfig
View File

@@ -1,7 +1,3 @@
##
##
## Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
##
## SPDX-License-Identifier: GPL-2.0-only
# For a description of the syntax of this configuration file,

8
payloads/coreinfo/Makefile
View File

@@ -1,8 +1,3 @@
##
##
## Copyright (C) 2008 Advanced Micro Devices, Inc.
## Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
##
## SPDX-License-Identifier: GPL-2.0-only
src := $(CURDIR)
@@ -128,10 +123,9 @@ include $(srck)/Makefile
else
clean:
rm -rf build/*.elf build/*.o .xcompile
rm -rf build lpbuild .xcompile
distclean: clean
rm -rf build lpbuild
rm -f .config* lp.config*
.PHONY: clean distclean

19
payloads/coreinfo/bootlog_module.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include "coreinfo.h"
@@ -19,14 +7,12 @@
#define LINES_SHOWN 19
#define TAB_WIDTH 2
/* Globals that are used for tracking screen state */
static char *g_buf = NULL;
static s32 g_line = 0;
static s32 g_lines_count = 0;
static s32 g_max_cursor_line = 0;
/* Copied from libpayload/drivers/cbmem_console.c */
struct cbmem_console {
u32 size;
@@ -37,7 +23,6 @@ struct cbmem_console {
#define CURSOR_MASK ((1 << 28) - 1)
#define OVERFLOW (1 << 31)
static u32 char_width(char c, u32 cursor, u32 screen_width)
{
if (c == '\n') {
@@ -110,7 +95,7 @@ static int bootlog_module_init(void)
return -1;
}
struct cbmem_console *console = lib_sysinfo.cbmem_cons;
struct cbmem_console *console = phys_to_virt(lib_sysinfo.cbmem_cons);
if (console == NULL) {
return -1;
}

14
payloads/coreinfo/cbfs_module.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2009 Uwe Hermann <uwe@hermann-uwe.de>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include "coreinfo.h"
#include "endian.h"

14
payloads/coreinfo/coreboot_module.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Advanced Micro Devices, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include "coreinfo.h"
#include <coreboot_tables.h>

14
payloads/coreinfo/coreinfo.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Advanced Micro Devices, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include "coreinfo.h"

14
payloads/coreinfo/coreinfo.h
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Advanced Micro Devices, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#ifndef COREINFO_H_
#define COREINFO_H_

18
payloads/coreinfo/cpuid.S
View File

@@ -1,18 +1,6 @@
/*
*
* It is derived from the x86info project, which is GPLv2-licensed.
*
* Copyright (C) 2001-2007 Dave Jones <davej@codemonkey.org.uk>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
/* It is derived from the x86info project, which is GPLv2-licensed. */
/* calling syntax: docpuid(idx,eax,ebx,ecx,edx) */

19
payloads/coreinfo/cpuinfo_module.c
View File

@@ -1,19 +1,6 @@
/*
*
* It is derived from the x86info project, which is GPLv2-licensed.
*
* Copyright (C) 2001-2007 Dave Jones <davej@codemonkey.org.uk>
* Copyright (C) 2008 Advanced Micro Devices, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
/* It is derived from the x86info project, which is GPLv2-licensed. */
#include "coreinfo.h"

14
payloads/coreinfo/multiboot_module.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Jordan Crouse <jordan@cosmicpenguin.net>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include <multiboot_tables.h>
#include "coreinfo.h"

14
payloads/coreinfo/nvram_module.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include "coreinfo.h"

14
payloads/coreinfo/pci_module.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Advanced Micro Devices, Inc.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include <arch/io.h>
#include <pci.h>

14
payloads/coreinfo/ramdump_module.c
View File

@@ -1,16 +1,4 @@
/*
*
* Copyright (C) 2008 Uwe Hermann <uwe@hermann-uwe.de>
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include "coreinfo.h"

14
payloads/coreinfo/timestamps_module.c
View File

@@ -1,14 +1,4 @@
/*
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
/* SPDX-License-Identifier: GPL-2.0-only */
#include "coreinfo.h"
#include <commonlib/timestamp_serialized.h>
@@ -147,7 +137,7 @@ static int timestamps_module_init(void)
if (ret)
return -1;
struct timestamp_table *timestamps = lib_sysinfo.tstamp_table;
struct timestamp_table *timestamps = phys_to_virt(lib_sysinfo.tstamp_table);
if (timestamps == NULL)
return -1;

6
payloads/external/BOOTBOOT/Kconfig vendored Normal file
View File

@@ -0,0 +1,6 @@
if PAYLOAD_BOOTBOOT
config PAYLOAD_FILE
default "payloads/external/BOOTBOOT/bootboot/dist/bootbootcb.elf"
endif

8
payloads/external/BOOTBOOT/Kconfig.name vendored Normal file
View File

@@ -0,0 +1,8 @@
config PAYLOAD_BOOTBOOT
bool "BOOTBOOT"
depends on ARCH_X86 || ARCH_ARM64
help
Select this option if you want to build a coreboot image
with a BOOTBOOT Protocol payload.
See https://gitlab.com/bztsrc/bootboot for more information.

44
payloads/external/BOOTBOOT/Makefile vendored Normal file
View File

@@ -0,0 +1,44 @@
project_git_repo=https://gitlab.com/bztsrc/bootboot.git
project_dir=bootboot
ifeq ($(CONFIG_COREBOOT_BUILD),)
include ../../../.config
endif
ifeq ($(CONFIG_ARCH_ARM64),y)
loader_dir=$(project_dir)/aarch64-cb
else
loader_dir=$(project_dir)/x86_64-cb
endif
unexport KCONFIG_AUTOHEADER
unexport KCONFIG_AUTOCONFIG
unexport KCONFIG_DEPENDENCIES
unexport KCONFIG_SPLITCONFIG
unexport KCONFIG_TRISTATE
unexport KCONFIG_NEGATIVES
all: bootboot
checkout:
echo " GIT BOOTBOOT $(loader_dir)"
test -L $(project_dir) || test -d $(project_dir) || \
git clone $(project_git_repo) $(project_dir)
bootboot: libpayload
echo " MAKE $(loader_dir)"
$(MAKE) -C $(loader_dir) LIBCONFIG_PATH=../../../libpayload
libpayload: checkout
cp $(loader_dir)/lib.config ../../libpayload/.config
cd ../../libpayload && $(MAKE) oldconfig && \
$(MAKE) && $(MAKE) DESTDIR=../external/BOOTBOOT/$(loader_dir) install
clean:
test -d $(loader_dir) && $(MAKE) -C $(loader_dir) clean || exit 0
distclean:
rm -rf $(project_dir)
print-repo-info:
echo "$(project_git_repo) $(project_dir)"
.PHONY: checkout bootboot libpayload clean distclean print-repo-info

1
payloads/external/LinuxBoot/Kconfig vendored
View File

@@ -135,7 +135,6 @@ config LINUXBOOT_KERNEL_UIMAGE
endchoice
config LINUXBOOT_DTB_FILE
string "Compiled devicetree file"
depends on LINUXBOOT_ARM64 || LINUXBOOT_RISCV

5
payloads/external/Makefile.inc vendored
View File

@@ -303,3 +303,8 @@ payloads/external/Yabits/uefi/build/uefi.elf yabits:
CONFIG_YABITS_MASTER=$(CONFIG_YABITS_MASTER) \
CONFIG_YABITS_STABLE=$(CONFIG_YABITS_STABLE) \
MFLAGS= MAKEFLAGS=
# BOOTBOOT
payloads/external/BOOTBOOT/bootboot/dist/bootbootcb.elf:
$(MAKE) -C payloads/external/BOOTBOOT all

2
payloads/external/SeaBIOS/Kconfig vendored
View File

@@ -5,7 +5,7 @@ choice
default SEABIOS_STABLE
config SEABIOS_STABLE
bool "1.13.0"
bool "1.14.0"
help
Stable SeaBIOS version
config SEABIOS_MASTER

2
payloads/external/SeaBIOS/Makefile vendored
View File

@@ -1,5 +1,5 @@
TAG-$(CONFIG_SEABIOS_MASTER)=origin/master
TAG-$(CONFIG_SEABIOS_STABLE)=f21b5a4aeb020f2a5e2c6503f906a9349dd2f069
TAG-$(CONFIG_SEABIOS_STABLE)=155821a1990b6de78dde5f98fa5ab90e802021e0
TAG-$(CONFIG_SEABIOS_REVISION)=$(CONFIG_SEABIOS_REVISION_ID)
project_git_repo=https://review.coreboot.org/seabios.git

6
payloads/external/tint/Makefile vendored
View File

@@ -18,9 +18,9 @@ patch: download
cd tint; \
if [ -e debian ]; then \
rm -rf debian typedefs.h Makefile; \
touch Makefile; \
patch -l -p1 < ../libpayload_tint.patch; \
fi
touch Makefile; \
patch -l -p1 < ../libpayload_tint.patch; \
fi
download:
test -d tint || { wget $(project_url); \

2
payloads/libpayload/arch/arm/cpu.S
View File

@@ -81,7 +81,7 @@
lsl ip, ip, r2 @ shift by that into way position
mov r0, #1
lsl r2, r0, r2 @ r2 now contains the way decr
mov r0, r3 @ get sets/level (no way yet)
mov r0, r3 @ get sets/level (no way yet)
orr r3, r3, ip @ merge way into way/set/level
bfc r0, #0, #4 @ clear low 4 bits (level) to get numset - 1
sub r2, r2, r0 @ subtract from way decr

17
payloads/libpayload/arch/arm64/mmu.c
View File

@@ -625,14 +625,10 @@ static void mmu_extract_ranges(struct memrange *cb_ranges,
static void mmu_add_fb_range(struct mmu_ranges *mmu_ranges)
{
struct mmu_memrange *fb_range;
static struct cb_framebuffer modified_fb;
struct cb_framebuffer *framebuffer = lib_sysinfo.framebuffer;
struct cb_framebuffer *framebuffer = &lib_sysinfo.framebuffer;
uint32_t fb_size;
/* Check whether framebuffer is needed */
if (framebuffer == NULL)
return;
fb_size = framebuffer->bytes_per_line * framebuffer->y_resolution;
if (!fb_size)
return;
@@ -652,16 +648,7 @@ static void mmu_add_fb_range(struct mmu_ranges *mmu_ranges)
if (fb_range == NULL)
mmu_error();
/*
* Set framebuffer address. However, one needs to use a freshly
* allocated framebuffer structure because the one in the coreboot
* table is part of a checksum calculation. Therefore, one cannot
* modify a field without recomputing the necessary checksum
* calcuation.
*/
modified_fb = *framebuffer;
modified_fb.physical_address = fb_range->base;
lib_sysinfo.framebuffer = &modified_fb;
framebuffer->physical_address = fb_range->base;
}
/*

1
payloads/libpayload/arch/arm64/virtual.c
View File

@@ -30,7 +30,6 @@
unsigned long virtual_offset = 0;
int getpagesize(void)
{
return 4096;

1
payloads/libpayload/arch/x86/Kconfig
View File

@@ -52,5 +52,4 @@ config DIE_ON_UNKNOWN_INTERRUPT
endchoice
endif

1
payloads/libpayload/arch/x86/apic.c
View File

@@ -127,7 +127,6 @@ void apic_start_delay(unsigned int usec)
enable_interrupts();
}
void apic_wait_delay(void)
{
/* Loop in case another interrupt has fired and resumed execution. */

2
payloads/libpayload/arch/x86/coreboot.c
View File

@@ -49,7 +49,7 @@ static void cb_parse_x86_rom_var_mtrr(void *ptr, struct sysinfo_t *info)
static void cb_parse_mrc_cache(void *ptr, struct sysinfo_t *info)
{
info->mrc_cache = get_cbmem_ptr(ptr);
info->mrc_cache = get_cbmem_addr(ptr);
}
int cb_parse_arch_specific(struct cb_record *rec, struct sysinfo_t *info)

1
payloads/libpayload/arch/x86/delay.c
View File

@@ -38,7 +38,6 @@
/* Let's assume APIC interrupts take at least 100us */
#define APIC_INTERRUPT_LATENCY_NS (100 * NSECS_PER_USEC)
void arch_ndelay(uint64_t ns)
{
uint64_t delta = ns * timer_hz() / NSECS_PER_SEC;

1
payloads/libpayload/arch/x86/virtual.c
View File

@@ -30,7 +30,6 @@
unsigned long virtual_offset = 0;
int getpagesize(void)
{
return 4096;

2
payloads/libpayload/configs/defconfig
View File

@@ -5,4 +5,4 @@ CONFIG_LP_USB_UHCI=y
CONFIG_LP_USB_OHCI=y
CONFIG_LP_USB_EHCI=y
CONFIG_LP_USB_XHCI=y
CONFIG_LP_HEAP_SIZE=262144
CONFIG_LP_HEAP_SIZE=1048576

3
payloads/libpayload/crypto/sha1.c
View File

@@ -115,7 +115,6 @@ SHA1Transform(u_int32_t state[5], const u_int8_t buffer[SHA1_BLOCK_LENGTH])
a = b = c = d = e = 0;
}
/*
* SHA1Init - Initialize new context
*/
@@ -132,7 +131,6 @@ SHA1Init(SHA1_CTX *context)
context->state[4] = 0xC3D2E1F0;
}
/*
* Run your data through this.
*/
@@ -155,7 +153,6 @@ SHA1Update(SHA1_CTX *context, const u_int8_t *data, size_t len)
(void)memcpy(&context->buffer[j], &data[i], len - i);
}
/*
* Add padding and return the message digest.
*/

3
payloads/libpayload/curses/PDCurses/demos/tui.c
View File

@@ -46,14 +46,12 @@ void rmerror(void);
# define EDITBOXCOLOR (A_BOLD | A_REVERSE)
#endif
#define th 1 /* title window height */
#define mh 1 /* main menu height */
#define sh 2 /* status window height */
#define bh (LINES - th - mh - sh) /* body window height */
#define bw COLS /* body window width */
/******************************* STATIC ************************************/
static WINDOW *wtitl, *wmain, *wbody, *wstat; /* title, menu, body, status win*/
@@ -360,7 +358,6 @@ static void cleanup(void) /* cleanup curses settings */
}
}
/******************************* EXTERNAL **********************************/
void clsbody(void)

1
payloads/libpayload/curses/PDCurses/x11/ScrollBox.c
View File

@@ -116,7 +116,6 @@ ScrollBoxClassRec scrollBoxClassRec = {
WidgetClass scrollBoxWidgetClass = (WidgetClass)&scrollBoxClassRec;
/************************************************************************
* *
* Private Routines *

1
payloads/libpayload/curses/PDCurses/x11/ScrollBox.h
View File

@@ -42,7 +42,6 @@
*/
/* Class record constants */
extern WidgetClass scrollBoxWidgetClass;

1
payloads/libpayload/curses/PDCurses/x11/ScrollBoxP.h
View File

@@ -56,7 +56,6 @@ typedef struct {
XtGeometryMask last_query_mode;
} ScrollBoxPart;
/************************************************************************
* *
* Full instance record declaration *

1
payloads/libpayload/curses/PDCurses/x11/x11.c
View File

@@ -276,7 +276,6 @@ static char *program_name;
#define RCOLOR(name, value) RPIXEL(color##name, Color##name, value)
#define RSTRINGP(name1, name2, param) { \
#name1, #name2, XtRString, \
MAX_PATH, APPDATAOFF(name1), XtRString, (XtPointer)param \

3
payloads/libpayload/curses/curses.priv.h
View File

@@ -32,7 +32,6 @@
* and: Thomas E. Dickey 1996-on *
****************************************************************************/
/*
* $Id: curses.priv.h,v 1.314 2006/12/10 00:55:14 tom Exp $
*
@@ -497,7 +496,6 @@ struct screen {
chtype * _acs_map; /* the real alternate-charset map */
bool * _screen_acs_map;
/* used in lib_vidattr.c */
bool _use_rmso; /* true if we may use 'rmso' */
bool _use_rmul; /* true if we may use 'rmul' */
@@ -980,7 +978,6 @@ extern NCURSES_EXPORT(void) name (void); \
}\
TR(TRACE_ATTRS, ("new attribute is %s", _traceattr((S))));}
#define toggle_attr_off(S,at) {\
if (PAIR_NUMBER(at) > 0) {\
(S) &= ~(at|A_COLOR);\

2
payloads/libpayload/curses/form/form.h
View File

@@ -106,7 +106,6 @@ typedef struct fieldnode {
NCURSES_FIELD_INTERNALS
} FIELD;
/*********
* FORM *
*********/
@@ -138,7 +137,6 @@ typedef struct formnode {
} FORM;
/**************
* FIELDTYPE *
**************/

16
payloads/libpayload/curses/menu/eti.h
View File

@@ -36,19 +36,19 @@
#define NCURSES_ETI_H_incl 1
#define E_OK (0)
#define E_SYSTEM_ERROR (-1)
#define E_BAD_ARGUMENT (-2)
#define E_POSTED (-3)
#define E_CONNECTED (-4)
#define E_BAD_STATE (-5)
#define E_NO_ROOM (-6)
#define E_SYSTEM_ERROR (-1)
#define E_BAD_ARGUMENT (-2)
#define E_POSTED (-3)
#define E_CONNECTED (-4)
#define E_BAD_STATE (-5)
#define E_NO_ROOM (-6)
#define E_NOT_POSTED (-7)
#define E_UNKNOWN_COMMAND (-8)
#define E_NO_MATCH (-9)
#define E_NOT_SELECTABLE (-10)
#define E_NOT_CONNECTED (-11)
#define E_NOT_CONNECTED (-11)
#define E_REQUEST_DENIED (-12)
#define E_INVALID_FIELD (-13)
#define E_INVALID_FIELD (-13)
#define E_CURRENT (-14)
#endif

3
payloads/libpayload/curses/menu/menu.h
View File

@@ -132,7 +132,6 @@ typedef struct tagMENU
} MENU;
/* Define keys */
#define REQ_LEFT_ITEM (KEY_MAX + 1)
@@ -170,7 +169,6 @@ typedef struct tagMENU
# define MAX_COMMAND (KEY_MAX + 128)
#endif
/* --------- prototypes for libmenu functions ----------------------------- */
extern NCURSES_EXPORT(ITEM **) menu_items (const MENU *);
@@ -244,7 +242,6 @@ extern NCURSES_EXPORT(int) menu_request_by_name (const char *);
extern NCURSES_EXPORT(int) set_menu_spacing (MENU *,int,int,int);
extern NCURSES_EXPORT(int) menu_spacing (const MENU *,int *,int *,int *);
extern NCURSES_EXPORT(bool) item_value (const ITEM *);
extern NCURSES_EXPORT(bool) item_visible (const ITEM *);

1
payloads/libpayload/curses/menu/mf_common.h
View File

@@ -66,7 +66,6 @@ extern int errno;
#define MODULE_ID(id) /*nothing*/
#endif
/* Maximum regular 8-bit character code */
#define MAX_REGULAR_CHARACTER (0xff)

1
payloads/libpayload/curses/tinycurses.c
View File

@@ -163,7 +163,6 @@ chtype console_acs_map[128] =
// FIXME: Ugly (and insecure!) hack!
char sprintf_tmp[1024];
int curses_flags = (F_ENABLE_CONSOLE | F_ENABLE_SERIAL);
/* Return bit mask for clearing color pair number if given ch has color */

29
payloads/libpayload/drivers/cbmem_console.c
View File

@@ -38,7 +38,7 @@ struct cbmem_console {
#define CURSOR_MASK ((1 << 28) - 1)
#define OVERFLOW (1 << 31)
static struct cbmem_console *cbmem_console_p;
static uintptr_t cbmem_console_p;
static struct console_output_driver cbmem_console_driver =
{
@@ -47,27 +47,32 @@ static struct console_output_driver cbmem_console_driver =
static void do_write(const void *buffer, size_t count)
{
memcpy(cbmem_console_p->body + (cbmem_console_p->cursor & CURSOR_MASK),
buffer, count);
cbmem_console_p->cursor += count;
struct cbmem_console *const cbmem_cons = phys_to_virt(cbmem_console_p);
memcpy(cbmem_cons->body + (cbmem_cons->cursor & CURSOR_MASK), buffer, count);
cbmem_cons->cursor += count;
}
void cbmem_console_init(void)
{
const struct cbmem_console *const cbmem_cons = phys_to_virt(lib_sysinfo.cbmem_cons);
cbmem_console_p = lib_sysinfo.cbmem_cons;
if (cbmem_console_p && cbmem_console_p->size)
if (cbmem_console_p && cbmem_cons->size)
console_add_output_driver(&cbmem_console_driver);
}
void cbmem_console_write(const void *buffer, size_t count)
{
while ((cbmem_console_p->cursor & CURSOR_MASK) + count >=
cbmem_console_p->size) {
size_t still_fits = cbmem_console_p->size -
(cbmem_console_p->cursor & CURSOR_MASK);
struct cbmem_console *const cbmem_cons = phys_to_virt(cbmem_console_p);
while ((cbmem_cons->cursor & CURSOR_MASK) + count >=
cbmem_cons->size) {
size_t still_fits = cbmem_cons->size - (cbmem_cons->cursor & CURSOR_MASK);
do_write(buffer, still_fits);
cbmem_console_p->cursor &= ~CURSOR_MASK;
cbmem_console_p->cursor |= OVERFLOW;
cbmem_cons->cursor &= ~CURSOR_MASK;
cbmem_cons->cursor |= OVERFLOW;
buffer += still_fits;
count -= still_fits;
}
@@ -77,7 +82,7 @@ void cbmem_console_write(const void *buffer, size_t count)
char *cbmem_console_snapshot(void)
{
const struct cbmem_console *console_p = cbmem_console_p;
const struct cbmem_console *const console_p = phys_to_virt(cbmem_console_p);
char *console_c;
uint32_t size, cursor, overflow;

1
payloads/libpayload/drivers/nvram.c
View File

@@ -42,7 +42,6 @@
#include <libpayload-config.h>
#include <libpayload.h>
/**
* PCs can have either 64 (very old ones), 128, or 256 bytes of CMOS RAM.
*

7
payloads/libpayload/drivers/options.c
View File

@@ -26,8 +26,11 @@
* SUCH DAMAGE.
*/
#define __STDC_FORMAT_MACROS
#include <libpayload.h>
#include <coreboot_tables.h>
#include <inttypes.h>
u8 *mem_accessor_base;
@@ -53,7 +56,7 @@ struct nvram_accessor *use_mem = &(struct nvram_accessor) {
struct cb_cmos_option_table *get_system_option_table(void)
{
return lib_sysinfo.option_table;
return phys_to_virt(lib_sysinfo.cmos_option_table);
}
int options_checksum_valid(const struct nvram_accessor *nvram)
@@ -325,7 +328,7 @@ int get_option_as_string(const struct nvram_accessor *nvram, struct cb_cmos_opti
/* only works on little endian.
26 bytes is enough for a 64bit value in decimal */
*dest = malloc(26);
sprintf(*dest, "%llu", *(u64*)raw);
sprintf(*dest, "%" PRIu64, *(u64 *)raw);
break;
case 's':
*dest = strdup(raw);

4
payloads/libpayload/drivers/serial/8250.c
View File

@@ -132,9 +132,9 @@ void serial_init(void)
void serial_console_init(void)
{
if (!lib_sysinfo.serial)
if (!lib_sysinfo.cb_serial)
return;
cb_serial = *lib_sysinfo.serial;
cb_serial = *(struct cb_serial *)phys_to_virt(lib_sysinfo.cb_serial);
serial_init();

4
payloads/libpayload/drivers/serial/ipq40xx.c
View File

@@ -553,9 +553,7 @@ static struct console_output_driver consout = {};
/* For simplicity's sake, let's rely on coreboot initializing the UART. */
void serial_console_init(void)
{
struct cb_serial *sc_ptr = lib_sysinfo.serial;
if (!sc_ptr)
if (!lib_sysinfo.cb_serial)
return;
consin.havekey = serial_havechar;

Some files were not shown because too many files have changed in this diff Show More