[coreboot] A new, modern coreboot long-term support laptop (was: Expectations, project direction and interest of contributors)

[mrnuke]

On Monday, March 24, 2014 05:00:26 PM ron minnich wrote:
> I keep wanting to drop out of this discussion but there are some things I
> just can't let go by,
> 
Let's focus on constructicism then (if that is even a word).

> On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel <
> 
> paulepanter at users.sourceforge.net> wrote:
> > First I find "wildest expectations" a little exaggerated seeing the
> > blobs (especially ME) shipped in all current Intel devices [1]. It is
> > even worse that these blobs are not allowed to be distributed making
> > building and flashing an image more difficult.
> 
> [...]
> 
> We don't like it. But if the choice is to ship on nothing, or ship with
> blobs, we'll ship with blobs. The X60 ports ship with blobs too, if you look
> at the big picture, because we still don't have EC source on those boxes.
> The OLPC shipped with blobs. This is not a simple problem.
> 
[slightly OT, feel free to skip] My stance on blobs is a little weird. I try 
to make sure I have full control of my system. If the blob cannot do any harm 
to my freedom, or in other words, respects it, then that blob is acceptable.
 * For example, a hardwired boot blob which has been RE'd so that we know what 
it does and how it does it, would be acceptable (see Allwinner). Even the FSF, 
according to RMS's own essays considers this to essentially be hardware.
 * A non-ISA (a) firmware blob which controls a piece of hardware which
  i) can only do one thing
  ii) without compromising the security of the system
  iii) and is non-essential for the functioning of the system
is acceptable. Examples would be USB 3.0 firmware blobs. Examples of blobs 
which would NOT be are ME (violates all three points), MRC (violates point 
iii, and potentially ii).
 * An ISA blob which is NOT essential for the bring-up of the system, and can 
reasonably be replaced by a free alternative. This basically includes VGA 
BIOSes.

(a) I define an ISA blob to be a blob which contains instructions for the main 
CPU's architecture, and executes such instructions on the main CPU. Microcode 
would be a non-ISA blob, as it is not a set of x86 (or ARMv7) instructions, 
despite it residing in the main CPU.

> > Additionally I heard claims, that the GPLv2 license is violated as it is
> > currently impossible to rebuild the exact same image that is shipped
> > with the devices as it is not even clear what commit was used to build
> > the image and to my knowledge the requests on the list and in the IRC
> > channel were not answered.
> 
> Dude, the commit is IN THE IMAGE. At least on the images I work with. As in:
> ro bios version | Google_Link.2695.1.133
> 
[Again, feel free to skip ahead] I made some of the claims Paul is talking 
about. I have the git hash of the firmware which came with my chromebook, but 
a branch containing that hash is not available publicly. This is one of the 
reasons I proposed to allow merging branches from shipping firmware rather 
than forcing a rebase of all patches.

> 
> For Google and the laptop vendors, I guess the goal is simply to save
> 
[Again, feel free to skip ahead]. Then why do vendors put a $130 CPU in a 
laptop that sells just shy of $200?

> > the money per device that traditionally went to the BIOS/UEFI vendors.
> 
> You should not impute motive where you have no knowledge [...]
> 
A very tempting point, but I'll stay out of it.

> > In my opinion, we should get the first AMD laptop supported as soon as
> > possible
> 
> yes, well, I've been asking for help on this for some time, years in fact,
> but I can't do it all myself. It's part of my huge disappointment that our
> volunteers chose to put their time into (quite obsolete, no longer
> manufactured) X and T thinkpads instead of something modern and open. You
> can fault Google for their decision to go with Intel; but the volunteers
> have not done a lot better, in fact worse in my view. Frankly, it's a
> disappointment.
>
This is where I've been meaning to get to. I'm all for doing what the new 
title of this (hijacked) thread says: a new, modern long-term coreboot 
supported laptop which is "Respects Your Freedom" certifiable. A laptop that 
will become what the X60 is today.

I don't have the financials to do this by myself. I don't have the time to do 
this by myself, and most certainly not the experience to provide an A to Z 
turnkey solution. I'm glad you asked. Carl-Daniel asked as well. He did a few 
months ago, and is still in the process of choosing a good candidate. There 
aren't many that are both durable _and_ RYF-certifiable after our port is 
made.

I am willing to invest whatever limited time, limited knowledge, and limited 
experience I have into making this project happen.
 
> One option here is to focus less on the things you currently put your time
> on, and focus more on getting that AMD laptop working, eh? Because it's
> easy to talk about what we should do. It's better to start DOING IT. And
> getting that AMD laptop going is a lot more important than fixing spelling
> errors in AGESA.
> 
Chose the hardware. Set up a github temporary fork. Send me the hardware. I 
got Pomona, I got SPI, I got USB debug, and I got the burning desire to make 
this happen.

Once we get the hardware in the hands of interested parties we can start 
actually DOING IT. There is no shortage of capable and interested individuals. 
We're just scattered across the internets with no clear direction, no leader, 
and no hardware.

Yeah, I hijacked the thread. I don't care. A modern LTS laptop is far more 
important than a theoretical rant-cussion about expectations. Sue me.

Still interested? I'll tell you my vision in more detail.

Alex