coreboot accepted for GSoC 2022

Hello coreboot community,

We have great news: The coreboot project has been accepted for this year’s Google Summer of Code! Thanks to everyone who made this possible!

You can find our GSoC organization page here [1] (unfortunately, newlines were removed from the description, but that’s true for all of the accepted orgs).

Looking at the GSoC timeline [2], this means the next step is discussing our exciting projects. We have about a month for this, from now until April 3rd, when the application phase starts.

We’re still looking for mentors! If you are interested, please have a look at the mail that Felix Singer, GSoC 2022 admin, sent earlier [3]. You also can help with code reviews or working out a project (writing description, defining project scope and tasks, …). Every bit of help counts.

For people interested in being GSoC candidates, we have set up a page [4] with all kinds of information and documentation. Please have a look at this, it’s really worth reading it 🙂

We have also prepared a list of projects [5] and started brainstorming more project ideas [6]. No matter whether you want to participate as a GSoC contributor or mentor, if you are interested, please let us know. Also, in case you have your own project idea, feel free to reach out.

We are excited to have great discussions with you!

Your Org Admins,

Felix Singer, Martin Roth, David Hendricks

[1] https://summerofcode.withgoogle.com/programs/2022/organizations/coreboot
[2] https://developers.google.com/open-source/gsoc/timeline#march_7_-_april_3
[3] https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/PGKTAPC3UEPG722JBUBZYIQQ2UZSGRNA/
[4] https://doc.coreboot.org/contributing/gsoc.html
[5] https://doc.coreboot.org/contributing/project_ideas.html
[6] https://docs.google.com/document/d/1LU8CTITfqhJU_G_XHwvSkHAQQWed0_FLWPPoBfcplAQ

P.S. The Flashrom project, which has been included as a part of coreboot in past GSoC programs has also been accepted as a separate GSoC 2022 participating organization. Congratulations!

Announcing coreboot 4.16

coreboot 4.16 release

coreboot's first quarterly release in a number of years, version 4.16 was tagged on February 25th, 2022.

Since 4.15 there have been more than 1770 new commits by more than 170
developers.  Of these, more than 35 contributed to coreboot for the
first time.

Welcome to the project!

Thank you to all the developers who continue to make coreboot the
great open source firmware project that it is.

New mainboards:
---------------
* Acer Aspire VN7-572G
* AMD Chausie
* ASROCK H77 Pro4-M
* ASUS P8Z77-M
* Emulation QEMU power9
* Google Agah
* Google Anahera4ES
* Google Banshee
* Google Beadrix
* Google Brya4ES
* Google Crota
* Google Dojo
* Google Gimble4ES
* Google Herobrine_Rev0
* Google Kingler
* Google Kinox
* Google Krabby
* Google Moli
* Google Nereid
* Google Nivviks
* Google Primus4ES
* Google Redrix4ES
* Google Skyrim
* Google Taeko4ES
* Google Taniks
* Google Vell
* Google Volmar
* Intel Alderlake-N RVP
* Prodrive Atlas
* Star Labs Star Labs StarBook Mk V (i3-1115G4 and i7-1165G7)
* System76 gaze16 3050
* System76 gaze16 3060
* System76 gaze16 3060-b

Removed mainboards:
-------------------
* Google ->  Corsola
* Google ->  Nasher
* Google ->  Stryke

Added processors:
-----------------
* src/cpu/power9
* src/soc/amd/sabrina

Submodule Updates
-----------------
* /3rdparty/amd_blobs (6 commits)
* /3rdparty/arm-trusted-firmware (965 commits)
* /3rdparty/blobs (30 commits)
* /3rdparty/chromeec (2212 commits)
* /3rdparty/intel-microcode (1 commits)
* /3rdparty/qc_blobs (13 commits)
* /3rdparty/vboot (44 commits)

Plans to move platform support to a branch:
-------------------------------------------
After the 4.18 release in November 2022, we plan to move support for any
boards still requiring RESOURCE_ALLOCATOR_V3 to the 4.18 branch.  V4 was
introduced more than a year ago and with minor changes most platforms
were able to work just fine with it. A major difference is that V3 uses
just one continuous region below 4G to allocate all PCI memory BAR's. V4
uses all available space below 4G and if asked to, also above 4G too.
This makes it important that SoC code properly reports all fixed
resources.

Currently only AGESA platforms have issues with it. On Gerrit both
attempts to fix AMD AGESA codebases to use V4 and compatibility modes
inside the V4 allocator have been proposed, but both efforts seem
stalled. See the (not yet merged) documentation
CB:43603 [1] on it's
details. It looks like properly reporting all fixed resources is the
issue.

At this point, we are not specifying which platforms this will include
as there are a number of patches to fix these issues in flight.
Hopefully, all platforms will end up being migrated to the v4 resource
allocator so that none of the platforms need to be supported on the
branch.

Additionally, even if the support for the platform is moved to a branch,
it can be brought back to ToT if they're fixed to support the v4
allocator.

Plans for Code Deprecation
--------------------------
As of release 4.18 (November 2022) we plan to deprecate LEGACY_SMP_INIT.
This also includes the codepath for SMM_ASEG. This code is used to start
APs and do some feature programming on each AP, but also set up SMM.
This has largely been superseded by PARALLEL_MP, which should be able to
cover all use cases of LEGACY_SMP_INIT, with little code changes. The
reason for deprecation is that having 2 codepaths to do the virtually
the same increases maintenance burden on the community a lot, while also
being rather confusing.

A few things are lacking in PARALLEL_MP init:
- Support for !CONFIG_SMP on single core systems. It's likely easy to
  extend PARALLEL_MP or write some code that just does CPU detection on
  the BSP CPU.
- Support SMM in the legacy ASEG (0xa0000 - 0xb0000) region. A POC
  showed that it's not that hard to do with PARALLEL_MP CB:58700 [2]

No platforms in the tree have any hardware limitations that would block
migrating to PARALLEL_MP / a simple !CONFIG_SMP codebase.

Significant changes
-------------------
This is, of course, not a complete list of all changes in the 4.16
coreboot release, but a sampling of some of the more interesting and
significant changes.

### Option to disable Intel Management Engine
Disable the Intel (Converged Security) Management Engine ((CS)ME) via
HECI based on Intel Core processors from Skylake to Alder Lake. State is
set based on a CMOS value of `me_state`. A value of `0` will result in a
(CS)ME state of `0` (working) and value of `1` will result in a (CS)ME
state of `3` (disabled). For an example CMOS layout and more info, see
[cse.c](../../src/soc/intel/common/block/cse/cse.c).


### Add AMD apcb_v3_edit tool
apcb_v3_edit.py tool edits APCB V3 binaries. Specifically it will inject
up to 16 SPDs into an existing APCB. The APCB must have a magic number
at the top of each SPD slot.


### Allow enable/disable ME via CMOS
Add .enable method that will set the CSME state. The state is based on
the new CMOS option me_state, with values of 0 and 1. The method is very
stable when switching between different firmware platforms.

This method should not be used in combination with USE_ME_CLEANER.

State 1 will result in:
ME: Current Working State   : 4
ME: Current Operation State : 1
ME: Current Operation Mode  : 3
ME: Error Code              : 2

State 0 will result in:
ME: Current Working State   : 5
ME: Current Operation State : 1
ME: Current Operation Mode  : 0
ME: Error Code              : 0


### Move LAPIC configuration to MP init
Implementation for setup_lapic() did two things -- call enable_lapic()
and virtual_wire_mode_init().

In PARALLEL_MP case enable_lapic() was redundant as it was already
executed prior to initialize_cpu() call.  For the !PARALLEL_MP case
enable_lapic() is added to AP CPUs.


### Add ANSI escape sequences for highlighting
Add ANSI escape sequences to highlight a log line based on its loglevel
to the output of "interactive" consoles that are meant to be displayed
on a terminal (e.g. UART). This should help make errors and warnings
stand out better among the usual spew of debug messages. For users whose
terminal or use case doesn't support these sequences for some reason (or
who simply don't like them), they can be disabled with a Kconfig.

While ANSI escape sequences can be used to add color, minicom (the
presumably most common terminal emulator for UART endpoints?) doesn't
support color output unless explicitly enabled (via -c command line
flag), and other terminal emulators may have similar restrictions, so in
an effort to make this as widely useful by default as possible I have
chosen not to use color codes and implement this highlighting via
bolding, underlining and inverting alone (which seem to go through in
all cases). If desired, support for separate color highlighting could be
added via Kconfig later.


### Add cbmem_dump_console
This function is similar to cbmem_dump_console_to_uart except it uses
the normally configured consoles. A console_paused flag was added to
prevent the cbmem console from writing to itself.


### Add coreboot-configurator
A simple GUI to change CMOS settings in coreboot's CBFS, via the
nvramtool utility.  Testing on Debian, Ubuntu and Manjaro with coreboot
4.14+, but should work with any distribution or coreboot release that
has an option table. For more info, please check the
README [3].


### Update live ISO configs to NixOS 21.11
Update configs so that they work with NixOS 21.11. Drop `iasl` package
since it was replaced with `acpica-tools`.


### Move to U-Boot v2021.10
Move to building the latest U-Boot.


### Support systems with >128 cores
Each time the spinlock is acquired a byte is decreased and then the
sign of the byte is checked. If there are more than 128 cores the sign
check will overflow. An easy fix is to increase the word size of the
spinlock acquiring and releasing.


### Add [samsung] sx9360 [proximity sensor] driver
Add driver for setting up Semtech sx9360 SAR sensor.
The driver is based on sx9310.c. The core of the driver is the same, but
the bindings are slightly different.

Registers are documented in the kernel tree. [4]
Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml


### Add driver for Genesys Logic [SD Controller] GL9750
The device is a PCIe Gen1 to SD 3.0 card reader controller to be
used in the Chromebook. The datasheet name is GL9750S and the revision
is 01.

The patch disables ASPM L0s.


### Add support for Realtek RT8125
The Realtek RT8168 and RT8125 have a similar programming interface,
therefore add the PCI device ID for the RT8125 into driver for support.


### Add Fibocom 5G WWAN ACPI support
Support PXSX._RST and PXSX.MRST._RST for warm and cold reset.
PXSX._RST is invoked on driver removal.

build dependency:
  soc/intel/common/block/pcie/rtd3

This driver will use the rtd3 methods for the same parent in the device
tree. The rtd3 chip needs to be added on the same root port in the
devicetree separately.


### Fix bug in vr_config
The `cpu_get_power_max()` function returns the TDP in milliwatts, but
the vr_config code interprets the value in watts. Divide the value by
1000 to fix this.

This also fixes an integer overflow when `cpu_get_power_max()` returns
a value greater than 65535 (UINT16_MAX).


### Make mixed topology work
When using a mixed memory topology with DDR4, it's not possible to boot
when no DIMMs are installed, even though memory-down is available. This
happens because the DIMM SPD length defaults to 256 when no DIMM SPD is
available. Relax the length check when no DIMMs are present to overcome
this problem.


### Add FSP 2.3 support
FSP 2.3 specification introduces following changes:

1. FSP_INFO_HEADER changes
   Updated SpecVersion from 0x22 to 0x23
   Updated HeaderRevision from 5 to 6
   Added ExtendedImageRevision
   FSP_INFO_HEADER length changed to 0x50

2. Added FSP_NON_VOLATILE_STORAGE_HOB2

Following changes are implemented in the patch to support FSP 2.3:

- Add Kconfig option
- Update FSP build binary version info based on ExtendedImageRevision
  field in header
- New NV HOB related changes will be pushed as part of another patch


### Join hash calculation for verification and measurement
This patch moves the CBFS file measurement when CONFIG_TPM_MEASURED_BOOT
is enabled from the lookup step into the code where a file is actually
loaded or mapped from flash. This has the advantage that CBFS routines
which just look up a file to inspect its metadata (e.g. cbfs_get_size())
do not cause the file to be measured twice. It also removes the existing
inefficiency that files are loaded twice when measurement is enabled
(once to measure and then again when they are used). When CBFS
verification is enabled and uses the same hash algorithm as the TPM, we
are even able to only hash the file a single time and use the result for
both purposes.


### Skip FSP Notify APIs
Alder Lake SoC deselects Kconfigs as below:
- USE_FSP_NOTIFY_PHASE_READY_TO_BOOT
- USE_FSP_NOTIFY_PHASE_END_OF_FIRMWARE
to skip FSP notify APIs (Ready to boot and End of Firmware) and make
use of native coreboot driver to perform SoC recommended operations
prior booting to payload/OS.

Additionally, created a helper function `heci_finalize()` to keep HECI
related operations separated for easy guarding again config.

TODO: coreboot native implementation to skip FSP notify phase API (post
pci enumeration) is still WIP.


### Add support for PCIe Resizable BARs
Section 7.8.6 of the PCIe spec (rev 4) indicates that some devices can
indicates support for "Resizable BARs" via a PCIe extended capability.

When support this capability is indicated by the device, the size of
each BAR is determined in a different way than the normal "moving
bits" method. Instead, a pair of capability and control registers is
allocated in config space for each BAR, which can be used to both
indicate the different sizes the device is capable of supporting for
the BAR (powers-of-2 number of bits from 20 [1 MiB] to 63 [8 EiB]), and
to also inform the device of the size that the allocator actually
reserved for the MMIO range.

This patch adds a Kconfig for a mainboard to select if it knows that it
will have a device that requires this support during PCI enumeration.
If so, there is a corresponding Kconfig to indicate the maximum number
of bits of address space to hand out to devices this way (again, limited
by what devices can support and each individual system may want to
support, but just like above, this number can range from 20 to 63) If
the device can support more bits than this Kconfig, the resource request
is truncated to the number indicated by this Kconfig.

[1] https://review.coreboot.org/c/coreboot/+/43603
[2] https://review.coreboot.org/c/coreboot/+/58700
[3] https://web.archive.org/web/20220225194308/https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/util/coreboot-configurator/README.md
[4] https://web.archive.org/web/20220225182803/https://patchwork.kernel.org/project/linux-iio/patch/20211213024057.3824985-4-gwendal@chromium.org/

coreboot 4.15 to 4.16 visualized

Current status of coreboot and Heads ports for Talos II

This post summarizes our current progress on making first coreboot port for POWER platform*, including Heads as a payload. It will also show how You can test it without having to actually flash firmware to PNOR permanently. Description of OpenPOWER boot process and coreboot’s place in it can be found in previous post under OpenPOWER tag. *) there is already a target for qemu-power8 that compiles successfully, but it executes just a single instruction: b .

KGPE-D16 open-source firmware status

Introduction Today’s computing systems and processors are becoming more and more efficient but closed as well. Closed in terms of documentation, closed in terms of free and open-source software and firmware. The x86 silicon vendors are striving for security by obscurity, falling deeper into the pit they created themselves, bound by laws that were supposed to protect them. As a result open-source firmware community has to struggle and push vendors into openness or to provide means to run open firmware on their products.

Librem 14 EC Upgrade Hardware Method

Librem 14s shipping today are already running the latest and greatest EC firmware. For those that already have their Librem 14, keeping your Librem EC firmware updated is simple with our ISO upgrade method. Still, for those needing to recover or test development EC builds, this video will explain how to upgrade your EC with a chip programmer. […] The post Librem 14 EC Upgrade Hardware Method appeared first on Purism.

New PureBoot Feature: Scanning Root for Tampering

With the latest PureBoot R19 pre-release we have added a number of new changes including improved GUI workflows and new security features and published a ROM image so the wider community can test it before it turns into the next stable release. To test it, existing PureBoot users can download the R19-pre1 .rom file that […] The post New PureBoot Feature: Scanning Root for Tampering appeared first on Purism.

PureBoot Security Flaw for Librem 14 Patched

PureBoot is our high-security boot firmware we offer on our Librem computers. In combination with a Librem Key, PureBoot allows you to detect tampering in the boot firmware itself, and in your OS’s kernel and other boot files. It detects tampering first by sending measurements of the boot firmware as it boots (containing among other […] The post PureBoot Security Flaw for Librem 14 Patched appeared first on Purism.

OSFC 2021 – Going Full Open-Source

OSFC 2021 - Going Full Open-Source
Oscar is so excited!
OSFC 2021 - Going Full Open-SourceOSFC 2020 was a blast - we had great talks and discussions, some virtual beers and a lot of fun - and OSFC 2021 is just around the corner! As remote conferences are new to us (and probably to everyone else as well) we gathered feedback from you - How did you liked the conference and on what bits can we improve to make the experience better next time. Of course, everyone here at the OSFC hoped that we can do a conference in person again - sadly that has to be postponed to next year. So here we are again - going full virtual! The overall feedback from you was good - however there was some feedback on the tools used for the OSFC that we like to share. Our main tool for running the conferences including the ticketing system was hopin.com - even though we liked the overall experience, we also noticed some minor problems around the platform:
  • The billing and ticketing system was quite simple. We were unable to produce invoices from bought tickets which resulted in us generating invoices manually for each attendee.
  • We got feedback from various people with different operating systems and browser setups that the stream was not working for them. We tried to resolve as many as possible - however there was not a clear set of which browser does not work on with operating system.
  • Sometimes the system was rather slow - and the chat was a bit complicated to handle
  • One big feedback point was that the system was not open - Either accessing the stream directly nor the platform itself was open-source - especially for an open-source conference that's something we put some thoughts in.

With this year's OSFC going virtual again, we put some thoughts into the technology we're planning to use throughout the event. Last time, we were in a rush - flipping everything over from physical to virtual. This year, we took our time and looked into various solution and came up with a plan.
OSFC 2021 - Going Full Open-Source
Venueless.org Logo
For the conference system itself, we are using Venueless. Venueless is a fairly new system (Initial Commit is from Apr 6, 2020) and it's fully open-source. The code can be checked out on Github. We booked one of the options mentioned on their homepage and added some extra money for features we need for our conference. Even though it's a fairly new project - we have a good feeling with the team and think that will work for us. It's fully customizable and we have a good connection to the developer.
OSFC 2021 - Going Full Open-Source
pretix.eu Logo
As the ticket system last year was one of the major pain points - we also changed this to pretix. pretix is, again, an open-source ticketing software which can be used obviously for handling tickets - for online, offline or hybrid events. The code can be found on GitHub. If it works out quite well, we're planning to use the system also for future in-person conferences and hackathons again. The system looks good - is more than capable of what we need and we are thrilled to move on with pretix.
OSFC 2021 - Going Full Open-Source
pretalx logo
Oldie but Goldie - pretalx. Last year we already used pretalx for the Call for Participation for the OSFC 2020 and we also used the schedule functionality and embedded this on the osfc.io homepage. pretalx is also open-source - Github link is here - and we already made some good experience with it. So we are going for pretalx again! Overall - we tried to go as much as possible open-source, and rely on open-source technologies for our conference. We here at OSFC think it's just natural that having a conference on open-source firmware should work with open-source technologies, also for managing and delivering our conference. We do strongly believe in the open-source spirit and support technologies and products build around it.
We hope you liked the new approach we are taking with the OSFC and we try to stick to the open-source spirit as close as possible. Let's see that we all have a great OSFC experience! We are looking forward to build a virtual space for you again - and are looking for great talks and discussion around open-source firmware!

Coreboot on the ASRock E3C246D4I

A new toy to play with OpenBMC

Coreboot on the ASRock E3C246D4II wanted to play around with OpenBMC on a physical board and this article led me to the ASRock E3C246D4I. It's a not overly expensive Intel Coffee Lake board featuring an Aspeed AST2500 BMC. So the first thing I did was to compile OpenBMC. My computer was in for a quite a chore there. It needed to download 11G of sources and compile those. Needless to say this takes a long time on a notebook computer and is best done overnight. I flashed the image via the SPI header next to the BMC flash. I used some mini crocodile clips to do this at first. Coreboot on the ASRock E3C246D4I To set up a nice way to play around with OpenBMC I attempted to hook up an EM100Pro, a flash emulator via the header. This did not seem to work. I'm not sure what was going on here. It looked like the real flash chip was not reliably put on HOLD by the EM100. When tracing the SPI commands with the EM100 0xff was the response to all the (fast)read commands. I guess a fast SPI programmer will do for now in the future. OpenBMC makes updates quite easy though: just copy the image-bmc to /run/initramfs/ and rebooting will launch an update which takes a minute or so (faster than my external programmer). So what can OpenBMC do on that board? Not much, it seemed at first. Powering the board on and off did not work and not much else either. The author of the port, Zev Zweiss, helped me a lot to get things working though. A bit of manual gpio magic and powering on and off works well. So the upstream code needs a bit of polish to get working but using the branch from the original author of this board port fared much better: sensors and power control work fine. Fan control is not implemented though, but I might look into that. Max fan speeds might be ok in a datacenter but not in my home office for sure!

Coreboot

The host flash is muxed to the BMC SPI pins so the BMC can easily (re)flash the host firmware (and is even faster at this than the host PCH due to the high SPI frequency the BMC can use). To get that working a few things needed to be done on the BMC. The flash is hooked up to the BMC SPI1 master bus which needs to be declared in the FDT. U-boot needs to set the SPI1 controller in master mode. The mux is controlled via a GPIO. 2 other GPIOs also need to be configured such that the ME on the PCH does not attempt to mess with the firmware while we're flashing (ME_RECOVERY pins). A flash controlled by a BMC is a very comfortable situation for a coreboot developper, who needs to do a dozen reflashes an hour, so hacking on coreboot with this device was a bliss (as soon as I got the uart console working). I don't have the schematics to this board so I'll have to do with what the vendor AMI firmware has set up and decode it from the hardware registers. This worked well: there is a tool to generate the PCH GPIO configuration in util/intelp2m which outputs valid C code that can directly be integrated into coreboot. I build a minimal port based on other Intel Coffeelake boards and after fixing a few issues like the console not working and memory init failing, it seemed to have initialised all the PCI devices more or less correctly and got to the payload! The default payload on X86 with coreboot is SeaBIOS. It looks like this payload does not like this board very much though: it hangs in the menu. I never got to boot anything with it. Tianocore (EDK2) proved a much better match and was able to boot from my HDD attached via USB without any issues. Booting the virtual CD-ROM from the BMC also worked like a charm. Coreboot on the ASRock E3C246D4I You can find the code on gerrit. Most things like USB, the 10G NICs, BMC IP-KVM and BMC Serial on Lan are working with that code. What's next: Get a LinuxBoot payload working and write some public documentation on how to set things up for OpenBMC and coreboot for this nice board. Maybe I can also get u-bmc working on this board? A few seconds vs a few hours in compiletime does seem like a compelling argument.