[coreboot] FSP 2.0 headers in coreboot

Julius Werner jwerner at chromium.org
Fri May 11 01:31:26 CEST 2018


> Ok, I'll try to break this loop here. You are repeating the great bene-
> fits for a user (that I agree to) even if a blob is involved. And I keep
> asking why it should happen on our master branch (I don't see how we
> would take something away by not maintaining everything. Also, I never
> tried to exclude all blobs). It seems somehow we talk past each other.

Why should it not be on our master branch? What is your exclusion criteria?
To my knowledge the only reason why we ever remove boards from the master
branch is because they become a maintenance burden when it's hard to make
them fit into new/changing APIs and there's no developer volunteering to
keep testing for that board. And in those cases, whether that burden is
related to a blob or not, I totally agree that we can consider removing
them from master. But I don't see how that has anything to do with whether
a blob is mainboard-specific or not. If a board with those blobs is still
easy to pull along with the changes we want to make on master and there's
someone willing to regularly test it and keep it healthy, I see no reason
for exclusion.

On the other side, the general benefits of keeping stuff in master are
obvious -- users of that board can benefit from the continued development
of coreboot core features. For example, if you have a 3 year old Chromebook
like Veyron_Jerry today then the firmware Google ships you is still frozen
on a three year old branch, but since it's alive and healthy in coreboot
master you can build your own image from there and automatically get cool
new features like the persistent CBMEM console. Ideally, it would be best
if we could keep everything in master forever... we just decide to drop
stuff as a trade-off if it actively prevents us from making forward
progress on other boards, but that decision is not directly related to the
presence or absence of blobs.



More information about the coreboot mailing list