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@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