Report on Chrome OS upstreaming

In the last months there was lots of activity in the coreboot repository due to upstreaming the work that was done in Chrome OS’ branch. We’re happy to announce that both code bases are again relatively close to each other.

In the last 7 months, about 1500 commits that landed in coreboot originated in Chrome OS’ repository (of about 2600 total). Those came from 20 domains, which represent pretty much every part of the coreboot community: well known private and commercial coreboot contributors, but also BIOS and silicon developers as well as device manufacturers.

As a result, upstream benefits from lots of new features and hardware support that was introduced during Chrome OS development, some of which warrant a shout out:

First, new hardware support: There’s MIPS support, and on the ARM side we now run on SoCs by Broadcom, Marvell, Qualcomm, and RockChip.

In terms of infrastructure, the biggest single item that came up during upstreaming is probably a safe method to declare the memory map on devices. Compared to x86, most architectures that prospered in embedded applications have a more complicated view on memory, so more care is required there.

Looking at files like src/soc/nvidia/tegra132/include/soc/memlayout.ld, it becomes clear what kind of memory is available for which purpose on that SoC.

In addition to that, there are efforts to make Chrome OS’ verified boot available as an option in upstream coreboot, and also to update the flash image format to allow for safer incremental updates.

One thing to note is that significant contributions that went into the tree recently were written with active support by Broadcom, Imagination Technologies, Intel, Marvell, Nvidia, Qualcomm, and RockChip. Welcome to coreboot!

In the future, Chrome OS will move over to a new branch point from upstream, and work on strategies to avoid diverging for two long years again. Instead, we’re looking for ways to keep the trees closer while also avoiding flooding the coreboot.org developer base with hundreds of patches. More on that as it is implemented.

GSoC 2015 H8S EC firmware

Hi community,

I’m Alexander Couzens on the list and in IRC known as lynxis. I’ve experience with embedded Linux and hardware integration of wireless devices using OpenWrt. I started modifying my vendor BIOS several years ago because my brand new Lenovo X201t didn’t allow me to use good wireless cards because it checked all pci networks devices against a white list. After my mainboard was replaced I had to do the same modification again or install coreboot. Of course I went for coreboot :) While installing coreboot I also started developing it, my GSoC is the H8S Embedded Controller firmware. The EC controls a lot of things in your laptop. An EC controls the battery charging and discharging, the keyboards, docking and undocking, multiple sensors, thermals sensors, fan, lid switch and power regulators.

Continue reading GSoC 2015 H8S EC firmware

[GSoC-2015] Introduction – End user flash tool

Hello coreboot!

My name is Łukasz Dmitrowski and I study Computer Science at West Pomerania University of Technology in Szczecin. I am relatively new to coreboot and firmware programming, but definitely want to dive in, this is why I have chosen coreboot from all available organizations. Last year I participated in GSoC and implemented MQTT-SN client for Wiselib library. It was really great and interesting experience. This year I am excited even more about my project! It is a very good starting point to get familiar with coreboot and stay with you also after GSoC.

Continue reading [GSoC-2015] Introduction – End user flash tool

[GSoC-2015] Introduction – Qemu Support for ARM64

Moin!

A new post after a long time. I’ll introduce myself again for the benefit of (few? :P) faded memories. I am Naman, a senior year undergraduate from India. I worked on developing alternate resource-efficient CBFS access patterns for ARM SoCs as a part of GSoC-2014. I am fortunate enough to engage as a GSoC student for coreboot this year too. I have had a busy semester but finally, as the summers arrive, I look forward to dive into the riveting world of coreboot hacking!

This summer I would be working to introduce a qemu target for arm64 architecture supporting coreboot. Currently, In order to work on aarch64, users require to have suitable hardware. This project intends to clear away this constraint. We have a growing aarch64 support with the tegra132 port, but no support for arm64 in emulation. Having a qemu target might be helpful for many projects which aim to arm64 work.

Continue reading [GSoC-2015] Introduction – Qemu Support for ARM64

GSoC 2015 Introduction – Nicky Sielicki

Hey coreboot community!

My name is Nicky Sielicki. I’m one of our Google Summer of Code 2015 participants. I’m a sophomore, err– I guess now I’m a junior, at the University of Wisconsin. You can read personal details about me at nicky.io, or maybe get to know me– I’m n1cky on freenode! Come say hello.

I’ve been hanging around the coreboot community for about 6 months or so after learning about coreboot from a 2008 GoogleTechTalks video about coreboot and why it’s awesome. I purchased a chromebook in hopes of playing around with coreboot and learning something. Over my winter break, I spent a lot of time reading, flashing unsuccessfully, and understanding more about coreboot.

Continue reading GSoC 2015 Introduction – Nicky Sielicki

On coreboot leadership…

Dear coreboot community!

I want to wholeheartedly thank every single one of you, who has contributed code to the coreboot project, reviewed code, improved our documentation in the wiki, or has contributed to the project by other means. You all have helped create a truly great project.

In 2014 alone, more coreboot devices have shipped than in all previous years combined! Since the start of coreboot v2 in 2003, 345 contributors have put over 12 thousand commits, an estimated effort of 457 years (COCOMO model) into the project. Since 2010, we have added support for all new Intel mobile and AMD R and G series processors. In the last year alone, we have added support for ARM/ARM64 SOCs from 7 vendors and, support for the MIPS and RISC-V architecture.

Continue reading On coreboot leadership…

coreboot GSOC 2015 projects

Welcome the coreboot GSOC 2015 students!


Łukasz Dmitrowski – End user flash tool

lynxislazus – H8S EC firmware

Naman – Qemu Support for ARM64 Architecture

n1cky –  Improve/automate reporting and testing


 

A special thanks to this years mentors: adurbin, furquan, martinr, carldani, stepan, pgeorgi, rminnich, ruik, stefanct, and carebear!

coreboot GSoC 2015

coreboot has been accepted as a mentoring organization for GSoC 2015! We are accepting student applications for coreboot, flashrom, and SerialICE projects.

Students:  Welcome! Please review the coreboot GSoC page and Project Ideas page. Student applications formally open on 16 March at 19:00 UTC.

Mentors:  Please signup in Melange and request to join the coreboot project. You must signup for 2015, even if you already have a Melange account. You may also find the GSoC Mentor Guide helpful.

Community:  Please recruit and welcome prospective students to the organization. You may provide ideas on the Projects Page.

The truth about Purism: Why Librem is not the same as libre

 

Purism Librem is an interesting project which promises to produce a completely libre laptop, designed to respect the user’s privacy and the user’s rights. The indivduals behind the project seem so confident as to “promise that a Purism system and all its components will be free according to the strictest of guidelines set forth by the Free Software Foundation’s Free Software Definition.” Can they deliver on this bold claim?

I first heard about Purism Librem sometime last October, when someone on #coreboot posted a link to Purism’s ideas/ideology page. It promised a fully libre system, from the ground up, with a high emphasis on libre firmware.

I only glanced over that page quickly before dismissing it as another over-ambitious and mis-informed project. There was no way that the Intel CPU and chipset they wanted could run libre, given Intel’s tight grip on the low level boot process. Coupled with their desire to include an Nvidia GPU — another high-profile offender in the libre software world — their ideas looked doomed.

The first red flag was that we, the coreboot hackers, were never contacted by Purism about what it would take to get such a design up and running on the firmware side. We could have immediately told them that there are major pieces of the initialization path for their CPU which were missing source. That is, they were only available as blobs.

The possibility of reverse engineering those blobs existed at the time. Although that takes a lot of effort, we’ve done it numerous times before. But they never asked. Had they done so, we would have also told them about another major offender. That’s the microcontroller in the chipset, which needs a signed firmware binary. By “signed” I mean a state-of-the art cryptographic verification mechanism. The chipset will refuse to run any firmware unless it was signed by a secret key held deep within Intel’s most secure dungeons. In short, this blob isn’t going away.

It was obvious to me from those first versions of Librem’s web page that the designers behind it had no idea about the binary situation. My impression was that they never contacted knowledgeable parties about it. They were reinventing the wheel and they were doomed to fail.

But that wasn’t to be. A month or so later, the subject popped up again on #coreboot. This time, they were considering crowd-funding. The information they provided via their website has changed as well. They were now claiming to be working with Intel about releasing source code for the early initialization blobs, and talking about disabling the chipset microcontroller entirely.

That sounded like a reasonable plan, with only one deadly fault: Intel doesn’t release this type of source code, and the Intel decision-makers do not talk with low-volume customers directly. Not even Google could get the source code out of Intel after shipping millions of Intel Chromebooks. The few hundred units that Purism was planning to build was definitely not going to cut it.

By that point, I made up my mind that the people behind Purism were either naive, or full of it. Deep in my heart, I wanted them to succeed, and I wanted to personally congratulate them for said success. I’m a coreboot developer; I know how this business rolls. I can make your firmware email me a daily digest of your passwords and Facebook activity, and you wouldn’t even know about it. I know what I’m talking about.

Fast-forward to the middle of January. Librem’s crowd-funding campaign had been extended from December to the end of January. A lot of new information also appeared on their web pages. Besides a quote from Richard Stallman, suggesting the FSF endorses their project, their campaign page was filled with buzz-words that seemed to have come straight out of Stallman’s most iconic speeches. The claim was that Librem is “designed to respect your privacy”.

There was also a graphic representation of the software stack. A green square meant libre, while a white square meant closed. There was so much green on the reverse pyramid of the graph, that it was too easy to miss the two or three white squares at the base. They were the platform firmware. That’s the part that emails me your passwords without any of the green dots above it being aware.

Finally, by January 22, a ZDNet article appeared which confirmed what I had predicted all along: that Librem will ship with proprietary firmware. That’s announcement came just a week shy of the crowd-funding campaign drawing to a close. With proprietary firmware, Librem is just as free as any other laptop on the market with GNU/Linux. Or in other words, it’s not any more free. It is certainly not libre.

So at the end of the day, Librem is bringing nothing new to the market. Laptops with libre operating systems have existed for decades. The only real innovators in this area have been Google and GluGlug. Google ships partially free firmware, although insufficiently libre to be able to provide the “respect your privacy” guarantee. GluGlug can make this claim, and it ships laptops with fully libre firmware. The downside of GluGlug is that it’s an aftermarket add-on. GluGlug and Google have been in business far longer than Purism. So, what has Purism brought in that’s new and exciting and libre? Nothing.