Announcing coreboot 4.6

We are happy to announce the April 2017 release of coreboot, version 4.6.

The 4.6 release covers commit e74f5eaa to commit db508565

Since the last release in October 2016, the coreboot project had 1708 commits by 121 authors.
The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/downloads

There is a pgp signed 4.6 tag in the git repository, and a branch will be created as needed.

Changes: Past, ongoing, and future

CBMEM console development and the Linux Kernel

Our cbmem debug console was updated with some nice features. The cbmem console now persists between reboots and is able to be used on some platforms via late init. Also there is a new Linux kernel driver which removes the need for the old cbmem tool to read from the cbmem area. You can find the patch here https://patchwork.kernel.org/patch/9641997/ and it can be enabled via GOOGLE_MEMCONSOLE_COREBOOT kconfig option in your kernel – Note that this name may change going forward.

Critical bugs in TPM 1.2 support

coreboot currently has issues with the TPM 1.2 LPC driver implementation. This leads to a misbehavior in SeaBIOS where the TPM gets temporarily deactivated. We plan to publish the bugfix release 4.6.1 when we have these issues sorted out.

Native graphics and ram init improvements

The native graphics was reworked a while ago and should finally support Windows. Numerous bug fixes and EDID support is also now available. Finally, the native ram initialization for sandybridge/ivybridge platforms got patched and supports more RAM modules.

New and fresh payloads

SeaBIOS, FiLO, and iPXE were all recently updated to the latest versions. Https downloads are the default for all payloads now. We provide the libpayload project which is used for writing own payloads from scratch. The library is MOSTLY licensed under BSD and recently received new functionality in order to prepare for the upcoming replacement for the old nvramcui payload. This new payload is called cbui and is based on the nuklear graphics library including keyboard and mouse support. The cbui payload is currently expected to be merged into the main coreboot tree before the next release.  The upstream repository is here: https://github.com/siro20/coreboot/tree/cbui/payloads/cbui

UEFI support: A long road to go

coreboot can be used with the Tianocore EDK2 UEFI implementation which is open source and available at Github. Sadly it is not currently integrated into the coreboot build. This has several reasons:

  • EDK2 only supports GCC 4.8 profile. coreboot is now running on GCC 6.3.0.
  • Incompatibilities with code inside the EDK2 which has not been updated.

We started to make progress with the integration into our sources and the hope is that by the end of the summer, we finally support the EDK2 payload out-of-the-box. See the current patch state at http://review.coreboot.org/#/c/15057/

Fighting blobs and proprietary HW components

coreboot’s ultimate goal would be to replace any closed source firmware stack with free software components. Unfortunately this is not always possible due to signed binaries such as the Intel ME firmware, the AMD PSP and microcode. Recently, a way was discovered to let the Intel ME run in a functional error state and reduce it from 1.5/5MB to 80KB. It’s not perfect but it works from Nehalem up to Skylake based Intel systems. The tool is now integrated into the coreboot build system. The upstream repository is https://github.com/corna/me_cleaner

Another ongoing improvement is the new utility blobtool. It is currently used for generating the flash descriptor and GbE configuration data on older mainboard which are known to be free software. It can easily be extended for different binaries with well-defined specifications.

Did you say Ada?

coreboot now supports Ada, and a lot work was done integrating Ada into our toolchain. At the moment only the support for formal verification is missing and will be soon added. At that point, we can prove the absence of runtime errors in our Ada code. In short, everybody can start developing Ada code for our project.

The existing Ada code which can be used from now on is another native graphics initialization which will replace in the long term the current implementation. The native graphics code supports all Intel platforms up to skylake. We offer support for HDMI, VGA, DVI and DP external interfaces as well and is ready to be integrated into our mainboard implementations.

Toolchain updates

A new coreboot toolchain is out. The major toolchain change was going from GCC version 5.3.0 to 6.3.0. There were also minor version updates to GMP, MPFR, Binutils, GDB, IASL, and Clang.

Deprecation policy for boards

Starting with this release there will be a policy for deprecating unmaintained boards. See the end of this announcement for details.

Change Summary

Build system (20 commits)

  • Clean up Kconfig
  • Show more useful error messages

Codebase cleanup (94 commits)

  • Many fixes for files to pass checkpatch. Lots more to do here.
  • Remove commented out code
  • Updates to transition away from device_t
  • Work to get rid of included C files

Documentation (6 commits)

  • Start adding technotes/Design docs
  • Add Kconfig documentation

ACPI & acpigen library

  • Add GPIO macros
  • Clean up and add more functions to ACPIGEN library

EC (26 commits)

  • Add roda/it8518 embedded controller

TPM (41 commits)

  • Cleanup
  • Update ACPI ASL, Runtime generate ACPI table for TPM driver
  • Make SPI TPM driver CAR-safe
  • Update TPM init sequence

Devices (24 commits)

  • Add a new SPI device type
  • Allow devicetree accesses in postcar stage
  • PCIEXP_ASPM: Unify code with other PCI-e tuning

Lib (28 commits)

  • Add option to use Ada code in ramstage
  • bootstate: add arch specific hook at coreboot exit
  • cbfs: Add API to locate a file from specific region
  • Add library to handle SPD data in CBFS or DIMM
  • Add region file support
  • Turn CBMEM console into a ring buffer that can persist across reboots

Commonlib (11 commits)

  • Add xmalloc, xzmalloc and dma routines
  • Add input and output buffer helpers

Drivers (29 commits)

  • i2c: Pass in i2c_generic_config into i2c_generic_fill_ssdt
  • i2c/alps: Add support for ALPS Touchpad driver
  • i2c/generic: Add support for GPIO IRQ
  • i2c/generic: Enable support for adding PowerResource for device
  • i2c/hid: Add generic I2C HID driver
  • i2c/max98927: add i2c driver for Maxim 98927 codec
  • i2c/wacom_ts: Add support for WCOM touchscreen device driver
  • pc80/rtc: Check cmos checksum BEFORE reading cmos value
  • regulator: Add driver for handling GPIO-based fixed regulator
  • storage: Add SD/MMC/eMMC driver based upon depthcharge

SPI interface

  • Significant cleanup and refactoring

Include (17 commits)

  • cpu/intel: Add MSR to support enabling turbo frequency
  • elog: Add all EC event codes

SuperIO (12 commits)

  • Updates for ITE SIOs
  • Add 2 new chips
  • Consolidate code to use common routines

Vboot (23 commits)

  • Add support for recovery hash space in TPM

RISC-V (25 commits)

  • Add lowRISC System On Chip support
  • Cbmem patches, move to common architectural code

ARM (16 commits)

  • Init new serial struct variables for samsung exynos5420 & allwinner a10
  • Fix verstage to use proper assembly versions of mem*()

RockChip RK3399 & platforms (46 commits)

  • Memory, I2C, USB, SD & Display fixes

X86 Intel (193 commits)

  • Broadwell/Sata: Add support for setting IOBP registers for Ports 2 and 3.
  • cpu/intel/common: Add/Use common function to set virtualization
  • drivers/intel/fsp1_1: Fix boot failure for non-verstage case
  • drivers/intel/fsp2_0: Reset on invalid stage cache.
  • drivers/intel/gma: Add textmode using libgfxinit & use scaling to simplify config
  • drivers/intel/mipi_camera: Add MIPI CSI camera SSDT generator
  • broadwell_de: Add SMM code
  • intelblocks/msr: Move intel x86 MSR definition into common location
  • intel/broadwell: Use the correct SATA port config for setting IOBP register
  • intel/wifi: Create ACPI objects for wifi SAR configuration
  • lynxpoint bd82x6x: Enable PCI-to-PCI bridge
  • mrc: Add support for separate training cache in recovery mode
  • nb/i945/early_init.c: Add FSB800 and 1067 to Egress Port Virtual Channel
  • nb/i945/raminit: Add fixes for 800MHz & 1067MHz FSB CPUs
  • nb/intel/gm45: Fix panel-power-sequence clock divisor
  • nb/intel/i945: Fix PEG port on 945gc & sdram_enhanced_addressing for channel1
  • nb/intel/pineview: Move to early cbmem
  • nb/pineview/raminit: Skip Jedec init on resume, fix hot reset path
  • nb/intel/sandybridge/gma: Always initialize DP buffer translation
  • sb/ich7: Use common/gpio.h to set up GPIOs
  • sb/intel/bd82x6x: Add TCO_Lock in finalize step
  • sb/intel/common/gpio: Support ICH9M and prior
  • sb/intel/i82801gx: Add i2c_block_read to smbus.h

sandybridge/raminit

  • Fix CAS Write Latency, disable_channel, normalize_training & odt stretch
  • Separate Sandybridge and Ivybridge
  • Reset internal state on fallback attempts
  • Find CMD rate per channel

soc/intel/common

  • Add common routines for HECI, ITSS, PCR, RTC, systemagent, UART, XHCI, & LPSS
  • Save Memory DIMM Information in SMBIOS table

Apollolake (183 commits)

  • Switch to common routines for LPSS, RTC, ITSS, UART, XHCI, & PCR
  • Enable turbo
  • Add save/restore variable MRC cache
  • Allow ApolloLake SoC to use FSP CAR Init
  • Allow USB2 eye pattern configuration in devicetree

Quark & platforms (14 commits)

  • Fix I2c & Serial port config
  • Add vboot support

ga-g41m-es2l, x4x northbridge & LGA775 (23 commits)

  • Memory fixes
  • Add S3 suspend/resume

Skylake / Kabylake (208 commits)

  • Add devicetree settings for acoustic noise mitigation
  • Perform CPU MP Init before FSP-S Init
  • Add support for GSPI controller & add GSPI controller get_config support
  • Enable Systemagent IMGU
  • Add USB Port Over Current support & Expand USB OC pins support PCH-H
  • Extract DIMM Information from FSP MEM INFO HOB
  • Add support for eSPI SMI events
  • Update ACPI & various methods

X86 amd (116 commits)

  • ACPI S3: Remove HIGH_MEMORY_SAVE where possible
  • AMD fam10 binaryPI: Remove invalid PCI ops on CPU domain
  • binaryPI platforms: Drop ACPI S3 support
  • sb/amd/sb700: Disable LPC ROM mapping when SPI Flash is used
  • southbridge/amd: Add LPC bridge acpi path for Family14 and SB800
  • arch/x86: remove CAR global migration when postcar stage is used
  • x86/acpi: Add VFCT table

AMD: vendorcode, AGESA, binaryPI (72 commits)

  • Cleanup & consolidate duplicate code
  • Fork for new cache-as-ram init code & Fix binaryPI cache-as-ram
  • Refactor S3 support functions and Delay ACPI S3 backup until ramstage loader

amd/mct:

  • Fix CsMux45 configuration, maximum read latency, & DQ mask calculation

Mainboards (198 commits)

  • asus/f2a85-m_le: Activate IOMMU support
  • lenovo/h8: Add USB Always On
  • google/oak: Enable dual DSI for rowan and the BOE 8-lane MIPI/DSI panel
  • google/parrot: Fix keyboard interrupts, DSDT
  • google/veyron: Work around RAM code strapping error
  • lenovo/t400: Rewrite dock from t60
  • intel/d510mo: enable ACPI resume from S3
  • intel/d945gclf: Fix resume from S3 suspend
  • lenovo/t400: Implement hybrid graphic in romstage
  • Enable libgfxinit on lenovo/t420 & x230, kontron/ktqm77, google/slippy
  • lenovo/x60,t60: Move EC CMOS parameters in checksummed space
  • mc_tcu3: Do not abort initialization of PTN3460 when HW-ID is missing
  • mc_tcu3: Swap LVDS even and odd lanes for a certain hardware
  • purism/librem13: Enable support for M.2 NVMe & Fix M.2 issues

Payloads (53 commits)

  • Update FILO, SeaBIOS, & iPXE versions
  • Many libpayload fixes and updates

Toolchain (19 commits)

  • Update GCC, Binutils, GMP, MPFR, GDB, IASL and LLVM

Utilities: (145 commits)

  • abuild: Build saved config files and print failed builds at the end
  • autoport: Create superiotool logs and fix romstage generator
  • board-status: Update bucketize script and add README file
  • cbfstool: Add cbfs-compression-tool and enable adding precompressed files
  • cbmem: Add custom aligned memcpy() implementation
  • ectool: Fix timeout on sending EC command and support OpenBSD
  • ifdtool: Fix ICH Gbe unlock
  • intelmetool: Add support for Wildcat Point LP, fix segfault on edge cases
  • inteltool: Add support for CH6-10, ICH10, Wildcat Point-LP and fix ICH SPIBAR
  • sconfig: Add a new SPI device type
  • superiotool: Add new chips – IT8783E/F, W83627DHG, W83627EHG, F71808A

Changes in chips

Added 1 processor & northbridge:

  • amd/pi/00670F00

Added 1 soc:

  • lowrisc/lowrisc

Removed 1 northbridge:

  • intel/e7501

Added 2 sios:

  • fintek/f71808a
  • ite/it8783ef

Mainboard changes

Added 52 mainboards and variants:

  • AMD Gardenia – AMD Stoney Ridge
  • Asus F2A85_M_PRO – AMD Family 15h Trinity
  • Asus P5GC_MX – Intel Socket LGA775
  • Gigabyte GA_945GCM_S2L & GA_945GCM_S2C variant – Intel Socket LGA775
  • Google Auron variants: Yuna, Gandof, Lulu – Intel Broadwell
  • Google Beltino variants: McCloud, Monroe, Tricky, Zako – Intel Haswell
  • Google Eve – Intel Kabylake
  • Google Fizz – Intel Kabylake
  • Google Gru variants: Bob, Scarlet – RockChip RK3399
  • Google Oak variants: Hana, Rowan – MediaTek MT8173
  • Google Poppy & Soraka variant – Intel Kabylake
  • Google Rambi variants: Banjo, Candy, Clapper, Glimmer, Gnawty, Heli, Kip, Orco, Quawks, Squawks, Sumo, Swanky, & Winky – Intel Baytrail
  • Google Reef variants: Sand, Snappy, Nasher – Intel Apollolake
  • Google Slippy variants: Leon, Wolf – Intel Haswell
  • Intel KBLRVP3 & KBLRVP7 – Intel Kabylake
  • Intel LEAFHILL – Intel Apollolake
  • Intel MINNOW3 – Intel Apollolake
  • Lenovo L520: Intel Sandybridge
  • Lenovo S230U: Intel Ivybridge
  • Lenovo X1 Carbon GEN1 – Intel Sandybridge
  • lowRISC NEXYS4DDR – RiscV
  • MSI MS7721 – AMD Bulldozer
  • PC Engines APU2 – AMD Jaguar
  • RODA RV11 & RW11 variant – Intel Ivybridge
  • Sapphire Pure Platinum H61 – Intel Socket LGA1155
  • Siemens MC_APL1 – Intel Apollolake

Removed 10 mainboard variants:

  • Google Auron (Still available as a base-board for variants)
  • Google Veyron Chromeboxes: Brain, Danger, Emile, Romy
  • Google Veyron Test Projects: Gus, Nicky, Pinky, Shark, Thea

Utilities

Added 2 new utilities:

  • blobtool
  • me_cleaner

Submodules

Updated 5 submodules

  • 3rdparty/blobs (10 commits)
  • 3rdparty/arm-trusted-firmware (172 commits)
  • 3rdparty/vboot (158 commits)
  • 3rdparty/chromeec/ (810 commits)
  • util/nvidia/cbootimage (2 commits)

Tested boards

The following boards were tested recently:

  • emulation qemu-q35            4.6-1
  • asus kgpe-d16                         4.6-1
  • asus kfsn4-dre                        4.6-1
  • asus p5gc-mx                          4.6-1
  • lenovo x60                               4.5-1681 / 4.6-7
  • lenovo x230                             4.5-1674 / 4.6-27
  • asrock e350m1                        4.5-1662 / 4.6-7
  • lenovo t420                              4.5-1640
  • lenovo x200                             4.5-1598 / 4.6-33
  • sapphire pureplatinumh61  4.5-1575
  • gigabyte ga-945gcm-s2l         4.5-1568
  • lenovo t400                              4.5-1564
  • lenovo t60                                4.5-1559
  • gigabyte m57sli                      4.5-1526
  • purism librem13                    4.5-1503
  • gigabyte ga-g41m-es2l           4.5-1444
  • google slippy                           4.5-1441
  • intel d510mo                           4.5-1341

coreboot statistics from e74f5eaa43 to db508565d2

  • Total Commits: 1708
  • Average Commits per day: 8.75
  • Total authors: 121
  • New authors: 34
  • Total Reviewers: 72
  • Total Submitters: 19
  • Total lines added: 177576
  • Total lines removed: – 107460
  • Total difference: 70116

Code removal after the 4.6 release

The only platform currently scheduled for removal is the bifferos/bifferboard & soc/rdc/r8610. This platform is one of two that still uses romcc to compile romstage and doesn’t have cache-as-ram in romstage – the others were all removed long ago. Additionally, it seems to be impossible to buy, so as far as it can be determined, no testing has been done recently.

Code removal after the 4.7 release

One of the things that the coreboot project has struggled with is how to maintain the older platforms while still moving the rest of the platforms forward. Currently there are numerous platforms in the codebase which have not been well maintained.

Starting with the 4.7 release in October, the coreboot leadership is going to set standards that platforms are expected to meet to remain in the active codebase. These will generally be announced 3 – 6 months in advance to give time to get changes in. The expectation is not necessarily even that all work to meet the goal will be completed, but it is expected that a reasonable effort has started to meet the goal at the time of the release. Regardless of the work that’s been done, platforms which have not met the goal by the following release will be removed.

The next expectation that will need to be met for all platforms is cbmem in romstage. This currently affects numerous platforms, including most, if not all of AMD’s platforms. Work to update many of these platforms has started, but there are others that have not made any progress towards this goal. A list of the platforms that are affected by this will be sent to the mailing list shortly.

Code removal after the 4.8 release

To further clean things up, starting with the 4.8 release, any platform that does not have a successful boot logged in the board_status repo in the previous year (that is, within the previous two releases) will be removed from the maintained coreboot codebase. Chips that do not have any associated boards will also be removed. These platforms will be announced before the release so that there is time for people to test if desired.

This is not meant to be a high bar, but as a measure to clean up the codebase and eliminate boards and chips that are actually no longer being used. The cleanup will happen just after the release, so the removed platforms will still be available in the release branch if desired. If there is still interest, developers can bring back old chips and boards by porting them to the new tree (and bringing them to current standards).

This gives everyone until April 2018 to get any boards that they care about tested before the first removal.

All the code removal information will also be sent to the mailing list along with additional details.

Results of the coreboot “Mailing List vs Forum” poll

A little while back, there were a few requests to switch from the mailing list format to a web-based forum for our official communication channel.  The coreboot leadership wanted to see what the actual preferences of the coreboot community was, so I posted a poll.  The poll was publicized in IRC and on the mailing list itself, so should have been communicated to the people who would be most directly affected by any change.

Poll results

Here are the overall results from all responses:

Hate Mailing List:1, Prefer Forum: 6, Don't care: 2, Prefer Mailing list: 21, Hate Forum: 26
All_responses

We had a total of 60 valid responses, and I think the overall results pretty clearly indicate that the coreboot project should NOT move away from the mailing list.

One suggestion was to split the communication into the mailing list for Developers, and a forum for non-developers. To see what the various groups thought, I made a few more charts:

Developer preferences:

Prefer Forum: 1, Prefer Mailing list: 16, Hate Forum: 15, Other: 3
Developer Responses

So not unexpectedly, the coreboot developers even more overwhelmingly prefer the mailing list to the general results

Non-developer preferences:

Hate Mailing list: 1, Prefer Forum: 5, Don't care: 2, Prefer Mailing list: 5, Hate Forum: 11, Other: 1
Non-developer Responses

So even within the non-developer group, there was a definite preference for the mailing list format.

Finally, I broke the Non-developer group down into the group that said they were coreboot users, as opposed to those that mainly read the mailing list.

coreboot users (non-developers):

 

Hate Mailing list: 1, Prefer Forum: 4, Prefer Mailing list: 4, Hate Forum: 5
coreboot Users (Non-Developers)

That group had the highest percentage of people who preferred the forum, but it was still well under 40%.

Suggestions

We also asked people what we should do to improve the mailing list.  Here’s a summary of the suggestions:

  • Show people how to set up their (or a different) email client to make reading the mailing list easier.
  • Have people be more polite.
  • Add a FAQ showing previously asked question and answers.
  • A netiquette should be established like on the Linux kernel mailing list.
  • Several suggestions to improve the coreboot mailing list archive at https://www.coreboot.org/pipermail/coreboot/
    • Fix the archive so that long threads aren’t spread into different sections by months.
    • Add a search function to the archive
    • Create monthly archives that can be downloaded (This exists.)
    • Update from Pipermail to a more modern archiver like Hyperkitty – https://pypi.python.org/pypi/HyperKitty

Since it doesn’t look like we’re going to switch to a forum, I’m not going to list the suggestions that people had for that.

Follow-up

Over the upcoming weeks, we’ll look at our options, and discuss our options and plans in the bi-weekly coreboot community meetings.

 

My coreboot mug filled with Lefthand Milk stout Nitro.
cheers!

coreboot is joining the Software Freedom Conservancy

The coreboot project applied to join the Software Freedom Conservancy and has been approved for membership by their board.  There is still some work to be done in hammering out the governance details, but we hope to have everything completed by April.

Joining the SFC as coreboot’s fiscal sponsor will allow us to go forward with fundraising, and that all donations to the coreboot project from the United States will be tax-deductible to the extent permitted by law.  Up to this point, coreboot hasn’t had any official way to accept donations or payments.  This has meant that the project was mainly supported financially by members of the coreboot leadership, which has put some limitations on what we were able to do.

Another of the things that joining the SFC means is that we will be formalizing and fully documenting the coreboot leadership structure.  This is one of the Conservancy’s requirements, and something that they will help the project with.

The Conservancy offers a number of other services to its members. We encourage everyone to take a look at the SFC, and to consider joining as individual supporters.

Announcing coreboot 4.5

We are happy to announce the release of coreboot 4.5

The 4.5 release covers commit 80a3df260767 to commit 0bc12abc2b26.

This release is the first since the project switched from doing quarterly releases to doing biannual releases.  The next release will be in April of 2017.

Since the last release in April, the coreboot project has had 1889 commits by 119 authors.

The release tarballs and gpg signatures are available in the usual place at https://www.coreboot.org/downloads

There is a 4.5 tag in the git repository, and a branch will be created as needed.

Areas with significant updates:

  • Toolchain (29 commits)
    • Updated mpfr version from 3.1.3 to 3.1.4
    • Updated gcc version from 5.2.0 to 5.3.0
    • Updated binutils version from 2.25 to 2.26.1 & Fix aarch64 build problem
    • Updated gdb version from 7.9.1 to 7.11
    • Updated iasl version from 20160318 to 20160831
    • Updated python version from 3.4.3 to 3.5.1
    • Updated expat version from 2.1.0 to 2.1.1
    • Updated llvm / clang version from 3.7.1 to 3.8.0
    • Updated make version from 4.1 to 4.2.1
  • Build system (32 commits)
    • Updates for cbfstool / fmap changes
    • Order per-region files to optimize placement success
    • Add support for the ADA language and toolchain.
  • Utilities (103 commits)
    • Lint – Update checkpatch.pl, add tools  to find non-ascii & unprintable chars and to verify a single newline at the end of files
    • cbfstool – Update for Linux payloads, Honor FSP modules addresses, fix elf parsing
    • Sconfig – Add 10 bit addressing mode for i2c devices, add generic device type, support strings, pass in devicetree filename
  • General code cleanup (197 commits)
    • Cleaning up code formatting and whitespace
    • Fix spelling & capitalization
    • Removing commented out code
    • Transition away from device_t
  • TPM (55 commits)
    • Add support for Trusted Platform Module 2.0
    • SPI & refactored I2C TPM driver
  • Drivers (54 commits)
    • Add ACPI support in several drivers
    • coreboot_tables –  Extend serial port description
    • Elog – refactor, add debug info
    • I2C – add generic driver,
    • SPI – Add new chip support, major refactoring, don’t assume SPI flash boot device
  • Lib (33 commits)
    • Add real-time-clock functions
    • Add RW boot device construct
    • reg_script updates: add to bootblock, add xor support, add display support
    • Timestamp fixes & updates
  • Vendorcode
    • AMD (14 commits) – Cleanup, add libagesa.a builds, remove unused code.
    • Google (22 commits) – VBoot2 updates and cleanup
    • Intel (86 commits) – Add Intel FSP 2.0, update Broadwell DE support
  • Payloads (37 commits)
    • Subpayload support got extend and is enabled by default.
    • nvramcui: refactor, update build
    • SeaBIOS: Update stable version to 1.9.3, add bootorder file
    • iPXE: Update stable version to the last commit of July 2016
    • Fix broken linux boot sequence

Mainboard changes

Added 13 mainboards, plus a few mainboard variants not included here:

  • ADI RCC-DFF networking board (adi/rcc-dff) – intel/rangeley SoC
  • AMD Evaluation Board DB-FT3B-LC (amd/db-ft3b-lc) – amd/00730F01 (Family 16h Models 30h-3Fh (Mullins)) CPU
  • AMD f2950 / TONK 1201/2 Board (amd/f2950) – amd/geode_lx CPU
  • Apple iMAC 5.2 (apple/imac52) – intel/i945 CPU
  • Unibap Development Kit ODE E21XX – amd/00730F01 (Family 16h Models 30h-3Fh (Mullins)) CPU
  • elmex/pcm205400 – amd/Family_14 CPU
  • elmex/pcm205401 – amd/Family_14 CPU
  • Lenovo N21 chromebook (google/enguarde) – intel/baytrail SoC
  • google/gale – Qualcomm IPQ40XX SoC
  • AOpen Chromebox (google/ninja) – intel/baytrail SoC
  • google/reef – intel/apollolake SoC
  • Acer Chromebox CXI2 (google/rikku) – intel/Broadwell SoC
  • google/rotor – marvell/MVMAP2315 SoC

Removed 5 mainboards:

These were all development boards not available to the public.

  • google/bolt – intel/haswell – removed in commit 139314b
  • google/rush – nvidia/tegra132 – removed in commit e67cd9e
  • google/rush_ryu – nvidia/tegra132 – removed in commit 0c63415
  • google/slippy – intel/haswell – removed in commit bc24b85
  • intel/amenia – intel/apollolake – removed in commit c2586db

Existing boards with significant updates

  • asus/kgpe-d16 – amd/socket_G34 – Add TPM support, enable secondary serial port
  • emulation/spike-riscv: RISC-V -clean up, use generic bootblock,  look for CBFS in RAM, reimplement SBI
  • google/gru – rockchip/RK3399 SoC (76 commits) – Board bringup
  • google/oak – mediatek/mt8173 SoC- Add Elm variant, update memory, configure display, initialize touchscreen gpio
  • intel/galilleo- intel/quark SoC (14 commits) – Board bringup, add galileo gen1 support, switch to FSP2.0
  • intel/minnowmax – intel/fsp_baytrail SoC – Enable all PCIe ports, Program GPIO for power LED
  • lenovo/x60 – intel/socket_mPGA478 – init GPIOs before dock check, add hda verb table
  • siemens/mc_bdx1 – intel/fsp_broadwell_de SoC – Add external RTC, Set up MAC addresses, Update IRQs
  • siemens/mc_tcu3 – intel/fsp_baytrail SoC – cleanup & LCD panel updates

Changes in chips

Moved 3 northbridge/southbridge pairs to soc:

  • dmp/vortex86ex
  • intel/sch
  • rdc/r8610

Added 2 socs:

  • marvell/mvmap2315 (12 commits)
  • qualcomm/ipq40xx (22 commits)

Removed 1 soc:

  • nvidia/tegra132 – removed in commit 9ba0699

Added 2 sios:

  • nuvoton/nct6776
  • nuvoton/nct6791d

Existing chip areas with many changes

  • ARM (34 commits)
    • Add armv7-r configuration
    • rockchip/rk3399 (73 commits) – Bringup, memory updates
  • RISC-V (40 commits)
    • Improve and refactor trap handling
  • X86 (225 commits)
    • ACPI (40 commits) Add support for writing various entries and descriptor types, Add common definitions, Use ‘GOOG’ id for coreboot table
    • amd/mct_ddr3 northbridge: Support non-ECC DIMMs, Update SMBIOS, various fixes
    • arch/x86: many postcar stage updates, add common ACPI definitions, Support “weak” BIST and timestamp save routines
    • intel/apollolake SoC (211 commits) – Chip bringup, Update bootblock
    • intel/common: ACPI updates, Add smihandler, LPSS I2C driver, and  IGD OpRegion support
    • intel/fsp_broadwell_de: IRQ fixes, SPI message fixes, Add DMAR table to ACPI
    • intel/gm45 northbridge: Fix text mode init, enable vesa framebuffer, use VGA if connected
    • intel/i945 northbridge: add native VGA init, Update divisor calculations
    • intel/quark SoC (62 commits) – Chip bringup, add Fsp2.0 support, updates for serial console
    • intel/skylake CPU (61 commits) – Finished Skylake bringup, start updating for Kabylake FSP
    • intel/x4x northbridge (13 commits) – Memory & Graphics updates

Submodules

Updated 4 submodules

  • 3rdparty/blobs (6 commits)
  • 3rdparty/arm-trusted-firmware (425 commits)
  • 3rdparty/vboot (61 commits)
  • 3rdparty/chromeec/ (676 commits)

Tested boards

The following boards were tested for this release:

  • asrock/e350m1              4.4-1890
  • asus/kfsn4-dre               4.4-1698 / 4.5-17
  • asus/kgpe-d16                4.4-1802 / 4.5-17
  • emulation/qemu-q35   4.4-1698 / 4.5-8
  • gigabyte/ga-b75m-d3v 4.4-1757
  • google/peppy                 4.4-1882
  • lenovo/g505s                 4.4-1739
  • lenovo/x201                   4.4-1886
  • lenovo/x220                   4.4-1746 / 4.5-17

coreboot statistics

Total Commits: 1889
Average Commits per day: 10.92
Total authors: 119
New authors: 47
Total Reviewers: 67
Total Submitters: 19
Total lines added: 164950
Total lines removed: -182737
Total difference: -17787

[GSoC] Multiple status registers, block protection and OTP support, wrap-up (1/2)

Hello! 🙂

GSoC 2016 coding period has come to an end and mentor’s evaluating students this week. It has been an enriching 13 weeks of reading datasheets, designing structures, coding, learning and hanging out over IRC! 😛 I’d like to take this opportunity to present my work and details on how to use it. 🙂

Firstly, to offer context to the work, here is a list of public mails and blog posts. These should give an idea as to how the discussions and work evolved. A lot of the discussions have happened over IRC, but #flashrom does not keep any logs.

The patch sets that I sent to the mailing list can be found at –

  1. Multiple status register and access protection infrastructure
  2. OTP/Security registers infrastructure
  3. Dummy chips

You can also find these over at flashrom’s patchwork. The mailing list is where the review happens (although a better alternative, IMHO, is Gerrit which coreboot uses). The patches aren’t currently merged and are under review. In any case, you are most welcome to join review (which will likely be very helpful for me). 🙂 If you’d like to look at something more on the bleeding edge, then I invite you to my GitHub.

Now, moving on how to use the work. The most exhaustive documentation on how to use it is the code itself :P, but in the following list I attempt to list scenarios –

  • For SPI chips that have multiple status registers, flashrom’s verbose output will print the status register bits and there values. Most bits are named, i.e., the datasheet refers to the bit by an abbreviation, for instance, WEL for Write Enable Latch, WIP for Work In Progress, BP for Block Protect, LB for Lock Bit and so on. The verbose output will print these names, both in abbreviated and long forms, for most chips (and these abbreviations tend to be generic across many manufacturers). However, the process for adding new chips that leverage this, and adding new bits, is a fairly easy task (I would invite you to have a look at the code 😉 for more details). The verbose output also prints the write protection mode for status register(s) in effect (software protected, hardware protected, power cycle lock down and so on).
  • In case you want to disable or enable (a particular type) write protection for status register, you can use the --wp-disable or --wp-enable[=MODE] respectively (where MODE is either of software, hardware, power cycle or permanent – you are encouraged to have a look at the man page 🙂 for more details)
  • In case you want to protect a particular range of an SPI chip from writes or erases, you will need to alter the BP, TB or SEC bits. Currently, there is a CLI that will enable you to accomplish all that. 😛 First, you’ll want to look at the list of ranges your SPI chip supports – run flashrom with --wp-list. Take note of the start address and the length of the memory range you want to protect. Then again run flashrom with --wp-set-range start=0xfff000,len=4 (0xfff000 and 4 are for representational purpose only). By now the memory range is protected, but you can additionally enable status register write protection by following what the foregoing point described.
  • For SPI chips that support OTP, you can read, write and erase OTP regions (of course for supported chips :P). For OTP operations, you have at your disposal --print-otp-status, --read-otp [,reg=], --write-otp file=[,reg=], --erase-otp [reg=] and --lock-otp [reg=]. You can read the OTP memory to a file, or you can write to the OTP region from a file, very much like reading and writing from/to SPI chip. For more details, I would again like to point you to the man page. 🙂

Since this is a work-in-progress, the CLI may change (and is very likely). Currently around 10% of SPI chips use this new infrastructure. Models of a few manufacturers (and especially exotic ones like Atmel) are yet to be fully incorporated. You are most welcome to add support for new chips or update the existing ones to support new infrastructure. 🙂

I would like to sincerely thank my mentors Stefan and David for their support and help. I am indebted to them for this opportunity and I hope that we continue to share this relationship in the future while I continue to explore and contribute to flashrom. It has been a pleasure getting to know each of them. I’d also like to thank Urja for pitching in from time to time 🙂 It was fun hanging out over IRC and helping folks asking questions there. And I am looking forward to it for years to come. 😛

In the next and final part of this post, I will highlight how we intend to improve upon this work in the future, where it will be headed and what more we have in store, so please stay tuned. 😉 Phew, this was a long one, and rightly so as it attempts to summarise a great deal of experiences. If you have any feedback, questions or comments on the blogs or code, please feel to ping me on #flashrom where I am known as hatim. You can also email me at hatim@hatimak.me.

Thanks, and looking forward to hearing from you. 🙂 See you in the next and final part.

[GSoC] Better RISC-V support, wrap-up

In less than an hour, Google Summer of Code 2016 will be over (at least for us students). In this blog post, I will describe how you can use coreboot on RISC-V.

You can find the complete list of commits that I made during GSoC with this gerrit query.

The details

Compiling spike, the RISC-V instruction-set-level simulator

Spike, also known as riscv-isa-sim, is the reference implementation of RISC-V, and the only RISC-V platform that is currently known to work with coreboot (QEMU is nominally also supported, but the corresponding coreboot code has not been updated in a while).

First, you need to build and install libfesvr:

Then, you can compile and install spike:

  • Clone the spike git repository.
  • Apply the patch in this pull request to make console output possible.
  • Open riscv/processor.cc in a text editor and find processor_t::get_csr. Add a line that reads case CSR_MTIME: return 0;.
  • run ./configure --prefix="$HOME" --with-fesvr="$HOME" && make && make install

Compiling coreboot for RISC-V

  • Clone the coreboot git repository, if you haven’t already
  • Apply Iru Cai’s patch that updates the toolchain to GCC 6.1. You will currently have to fix a merge conflict when you apply this patch, but it’s an easy one.
  • Run make crossgcc-riscv
  • Run make menuconfig to configure coreboot. Select Emulation and SPIKE usb riscv in the Mainboard menu.
  • Run make
  • Run util/riscvtools/make-spike-elf.sh build/coreboot.rom build/coreboot.elf
  • Start coreboot by running spike build/coreboot.elf. You should see a few pages of output, ending in Payload not loaded.

Compiling and running Linux

  • Clone the riscv-linux git repository and check out the priv-1.9 branch
  • Apply this patch that allows linux to be started in machine-mode.
  • Download a copy linux 4.6.x from kernel.org, and unpack it. I’ll assume version 4.6.2 is used.
  • cd into linux-4.6.2/arch and symlink the arch/riscv directory from riscv-linux
  • Back in linux-4.6.2, run make O=build ARCH=riscv defconfig; cd into the newly created build directory.
  • Run make ARCH=riscv menuconfig. In the “General Setup” menu of the linux menuconfig, enter path/to/coreboot/util/crossgcc/xgcc/bin/riscv64-elf- as the cross-compiler tool prefix.
  • Run make ARCH=riscv vmlinux to compile linux.
  • Open vmlinux in a hex editor, such as hexer. Change the 8-byte number at 0x18 to 00 00 00 90 00 00 00 00; Add 00 00 00 90 00 00 00 00 to the numbers at 0x58 and 0x90, to load linux at physical addresses within RAM. It’s unfortunate that I have to recommend this step, but I did not come up with a better fix yet.

Next, you need to add vmlinux to coreboot:

  • Return to the coreboot directory.
  • Apply the remaining coreboot patches that are tagged riscv.
  • In the Payload menu, select An ELF executable payload. Instead of payload.elf, select the vmlinux file.
  • Run make and util/riscvtools/make-spike-elf.sh build/coreboot.rom build/coreboot.elf again.
  • Run spike build/coreboot.elf. You should now see a Linux boot, at least partially.

Future work

Even though my GSoC is over, coreboot’s support for RISC-V can still be improved, and I intend to fix at least some of the following things:

  • As you can see above, running coreboot and linux on RISC-V currently isn’t straight-forward, but involves a few manual steps.
  • There are other RISC-V platforms that I’d like to see coreboot on, such as lowRISC.
  • Linux does not completely boot, i.e. into userspace. There are still some bugs to be ironed out.
  • Automatic testing could be used to detect regressions.
  • I only tested coreboot on RISC-V with Linux; support for other operating systems or payloads is welcome.

Acknowledgements

I’d like to thank Ron Minnich and Furquan Shaikh for being good mentors, and everyone in the coreboot community for being helpful and friendly.

[GSOC] Panic Room, Recap

Hello everyone, in the following post I’m going to recap all that I’ve managed to accomplish during the GSoC of this year.

As a disclaimer: I plan to maintain these patches until they are fit to be mainlined or rejected altogether in case of design flaws.

libpayload: replace cbfs_media api with region_device api

This patchset should be complete, I tested it quite thoroughly by using the API to update the bayou payload (separate patch). I'm still waiting on a review on this one so I suspect there will be some cause for nitpicks.
bayou: Adapt to the coreboot-v4 era

Changed the design of the payload to make it integrate better with the current infrastructure of coreboot. The majority of the changes have been documented in the appropriate wiki entry. The patchset is complete and working.
console/serialice: Add SerialICE

The patchset was started and the initial work was done by Patrick Rudolph.
I picked it up from there, fixed the problems that it had and tried to get it in shape. It currently works as expected, waiting on more review/feedback.
serialice: update QEMU to version 2.5
serialice: adapt serialice to work with QEMU stable-2.5

In its current state this patchset produces a working build, all the functionality seems to be intact and SerialICE produces the same output as with the old implementation. There could be some unforeseen problems with the changes in the QEMU infrastructure and it could use a cleanup.
[WIP] src: replace device_t type with pnp/pci_defn_t

This is one of the latest commits that I've worked on, it's still a work in progress but I plan to remove all the the improper uses of device_t and replace it with the appropriate type. It's probably gonna take a while and I suspect the patch is going to be massive. If anyone has any suggestion on how to handle this transition feel free to tell me.
tint: Fix tint and add Kconfig option

The payload works as intended. Only nit is that maintaining a separate patch to apply to the tint code is tricky/messy.
lib/selfboot: Replace rdev_mmap_full()

The code worked, even though it's been a while since I rebased the change to check for conflicts. Should be an easy fix anyway.
payloads: add support lz4 compression

selfboot: add sequential lz4 payload decompression

The functionality works as expected.
coreinfo: Add support to read timestamps

cbmem: share additional time stamps IDs

Code works as intended, the only thing missing are the commas that should split the timestamps in groups of 3 digits. I couldn't port that part since it relied on a recursive function that no longer worked.
elfwriter: Fix multi-phdrs ELFs parsing

cbfstool: Require "-m ARCH" to extract payloads and stages

cbfstool: Extract payload in ELF

One of the oldest patchset that I wrote, took a while to get it right but it seems to be working wonderfully.
region: Add writeat and eraseat support

Below are a bunch of minor patches that I’ve written to fix the bugs that I’ve encountered while working on the patches above or browsing the source tree:

i945.h: fix #include path

emulation/qemu-i440fx: add cmos.default file

nvramcui: refactor code

pc80/mc146818rtc.h: Replace leftover macro token

lenovo/x60: add GPIOs initialisation before dock check

serialice: update lint filters

payloads: add Kconfig option for bayou

libpayload: split "Drivers" config section in Kconfig

bayou: delete pbuilder utility

filo: Specify libpayload path

cbfstool: Allow to easily build the individual tools

If you have any question regarding these patches you can find me on IRC (avengerf12).

I wanna conclude this post by expressing my gratitude towards the coreboot’s GSoC admins and mentors for the wonderful opportunity that they have given me and to the coreboot community for all the help and suggestions.

Sincerely,

Antonello

[GSoC] Better RISC-V Support, week #10

This past week, I worked on the virtual memory initialization code of coreboot on RISC-V. The first part of this was to update encoding.h a file that defines constants such as bit masks which are necessary for interacting with RISC-V’s Control and Status Registers. As a result, I also had to change a few files that relied on outdated constants. Then I wrote some code to walk the page table structures, and fixed one or two bugs in the page table setup code. Unfortunately my patches aren’t as finished as I would like them to be.

When I tested my changes with a Linux payload (which I had to edit the ELF headers of, because Linux uses virtual addresses, while cbfstool and the SELF loader use physical addresses), I stumbled upon another strange error: I get a store access fault in the instruction of the trap handler that saves the first register, even if I initialize the stack pointer to a value that’s within the RAM. When the trap handler runs again to handle this store access fault, it runs without any problems. This fault is especially confusing, because machine mode should always be able to access RAM through its physical addresses.

What’s next?

During the next week, I’ll be traveling and won’t be able to work on coreboot. When I return, I will rework my patches so they can be merged, and hopefully understand the aforementioned access fault problem. Properly set-up page tables should bring me a step closer to running Linux on coreboot/RISC-V (without bbl in the middle).

If time permits, I will start porting coreboot to the Nexys 4 DDR devboard.

[GSOC] Panic Room, week #7

What have you procrastinated on this past week?

As usual, I’m glad you asked.

During the past week I worked every day(/night) on the porting of the region_device API (commit) as I probably mentioned last week. The port is now complete and it should be bug-free (?).
It’s been tested pretty thoroughly since I immediately used it to adapt Bayou from the old LAR/coreboot-v3 paradigm to the new CBFS/coreboot-v4 one.
A bunch of bugs cropped up with the new API during the transition (debugging the API wasn’t fun at all) but they have been solved and unless for some corner-cases that I missed it should just work.

The second part of the week, as you might have guessed read, has been devoted to fixing Bayou (commit). This has been quite fun, almost everything was broken or relied on some old function that has since been dropped from libpayload.
It now works quite well and supports all of the original features.
The only problem now are with the other payloads since they aren’t all able to exit cleanly and give back control to bayou (i.e. coreinfo reboots before returning, tint halts, etc).
If you want to know more details take a look at the commit message.

Apart from this two items I wrote a couple of patches concerned with libpayload and a patch that adds support for sequential lz4 decompression during the boot process (Thank you, Julius Werner, for pointing that out).
I also just finished updating the wiki entry for Bayou, so if someone wants to test it out… 🙂

What’s next?

With less than a month left of my GSOC time I plan to dedicate solely to maintain the patches that I currently have and work on the coreboot/serialice integration (so as to finally do something pertinent to the original proposal).

Have a nice weekend!

 

P.S.

I had to drop the idea of working on the FILO (flashupdate) project since it relies on a series of patches that have not been finished yet (libflashrom). It will be a project for another time perhaps.

P.S.S.

I think I lost count of a few weeks here and there…

[GSoC] Better RISC-V support, week #6/7/8/9

Since I haven’t posted an update of my coreboot-on-RISC-V work in a while, this will be a slightly longer post.

Week 6

In week 6, I started documenting how to build and boot coreboot on RISC-V, in the coreboot wiki.
It is now a bit outdated, because we’re moving away from using bbl to boot Linux.

Week 7

I wrote some patches: I removed code that used the old Host-Target Interface (HTIF), because it’s deprecated. I submitted an improved version of my workaround for the bug that causes Spike to only execute 5000 instructions in some cases. I informed the coreboot resource management subsystem about the position of the RAM in physical address space, so that the program loader wouldn’t refuse to load segments into RAM. I submitted two patches to fix compiler errors with the new toolchain.

Meanwhile, there were some good news in the RISC-V world:

Week 8

I submitted a few more patches and started to explore the Nexys4 board. The precompiled bitstream and kernel from the lowRISC version 0.3 tutorial worked without any problems, and after a few days and some help from the lowRISC mailing list, I was able to recompile the lowRISC bitstream.

This week

I discussed the choice of boot medium with the lowRISC developers, and they agreed that a memory-mapped flash would be useful. Once it is implemented, I
can start porting coreboot to lowRISC on the Nexys 4 DDR board. Luckily the Nexys4 already has large enough flash to use for this purpose.

My mentors and I agreed that the switch from machine mode to supervisor mode should be left completely to the payload.

What’s next?

I will continue to work on running coreboot on the Spike emulator. Currently I’m facing the following problems and tasks:

  • Linux, when compiled to an ELF file (vmlinux) specifies that it wants to be loaded at the physical address 0x0 and at the virtual address 0xffffffff80000000. Since coreboot’s ELF loading code only looks at the physical address, it refuses to load Linux, since RAM starts at 0x80000000 on RISC-V.
  • Low level platform information (most importantly the memory layout) is passed to the firmware (coreboot in this case) as a configuration string, which is dynamically generated by the emulator, in the case of Spike. I still need to implemented a parser for this format, so coreboot can know how much memory is available.
  • The RISC-V Privileged Architecture Specification 1.9 specifies that there shall be a page at the top of the virtual address space where the operating system can call a few functions exposed by the firmware (this is the Supervisor Binary Interface).