- It has a Trackpoint (and even Trackpoint buttons).
- It has soldered memory (only Elpida memory is support atm).
- It has Full-HD. (missed that on x2xx).
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.
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.
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.
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.
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
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:
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/
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.
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.
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.
Starting with this release there will be a policy for deprecating unmaintained boards. See the end of this announcement for details.
Build system (20 commits)
Codebase cleanup (94 commits)
Documentation (6 commits)
ACPI & acpigen library
EC (26 commits)
TPM (41 commits)
Devices (24 commits)
Lib (28 commits)
Commonlib (11 commits)
Drivers (29 commits)
SPI interface
Include (17 commits)
SuperIO (12 commits)
Vboot (23 commits)
RISC-V (25 commits)
ARM (16 commits)
RockChip RK3399 & platforms (46 commits)
X86 Intel (193 commits)
sandybridge/raminit
soc/intel/common
Apollolake (183 commits)
Quark & platforms (14 commits)
ga-g41m-es2l, x4x northbridge & LGA775 (23 commits)
Skylake / Kabylake (208 commits)
X86 amd (116 commits)
AMD: vendorcode, AGESA, binaryPI (72 commits)
amd/mct:
Mainboards (198 commits)
Payloads (53 commits)
Toolchain (19 commits)
Utilities: (145 commits)
Added 1 processor & northbridge:
Added 1 soc:
Removed 1 northbridge:
Added 2 sios:
Added 52 mainboards and variants:
Removed 10 mainboard variants:
Added 2 new utilities:
Updated 5 submodules
The following boards were tested recently:
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.
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.
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.
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.
Here are the overall results from 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:

So not unexpectedly, the coreboot developers even more overwhelmingly prefer the mailing list to the general results
Non-developer preferences:

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):

That group had the highest percentage of people who preferred the forum, but it was still well under 40%.
We also asked people what we should do to improve the mailing list. Here’s a summary of the suggestions:
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.
Over the upcoming weeks, we’ll look at our options, and discuss our options and plans in the bi-weekly coreboot community meetings.

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.
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.
These were all development boards not available to the public.
Updated 4 submodules
The following boards were tested for this release:
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
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 –
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 –
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).--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)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.--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.
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.
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:
Next, you need to add vmlinux to coreboot:
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:
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.
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
I tried to finish one of the optional goals of my proposal:
a way to access a payload (possibly a recovery) after the hardware initialisation is complete but the OS has still not taken over.
To define it in more practical terms, I wanted to replace the running payload at the press of a predefined button.
I started by looking into the SMM (System Management Mode) and in particular the SMI (System Management Interrupts) handlers defined by each target board in the coreboot tree.
That was the easy part, it took just a bit of probing my board (Lenovo x60) and a serial cable to retrieve some of the SMI button codes (I planned on using the ThinkAdvantage button, code 0x19).
I added it to the appropriate smihandler.c file, defined the behaviour and that was about it.
The more difficult part was actually implementing a way to make it possible to boot a new payload while in SMM.
SMM can be considered a separate “module” from romstage, etc, this consequently means that it does not have access to all of the same functions.
In particular it cannot access the load_payload() and run_payload() functions defined inside prog_loaders.c, which, as the name implies, are necessary in order to use a payload.
In order to solve the problem I came up with two designs:
That about sums it up for the past few weeks.
Thank you for reading and have a nice week.
Sorry to interrupt the stream of GSoC posts! 😉 Some of you may have wondered why there were no flashrom commits at all since the 0.9.9 release in March (i.e. about 5 Months). There wasn’t much direct flashrom development going on on the vanilla branch of flashrom apart from Hatim’s GSoC efforts of course.
Instead I’ve been working on moving our repository to git. I have created some client- and server-side hooks + other infrastructure (with the help of Patrick) that will be used in the future to host the vanilla flashrom repository. This part was actually only the smaller part of time I spent on flashrom in the last months (which was not as much as I would have wished for, obviously). More on this and future development later on the flashrom mailing list…
The remaining time I’ve been working on a script that rewrites history. Not all of history, only the flashrom repository’s history. Continue reading Rewriting history (of flashrom)