New on blogs.coreboot.org: Announcing coreboot 4.6

If anyone wants an idea for a board to port, something FM2+ would be 
great as they're still available yet backwards companionable with FM2 
(non plus) CPU's that lack PSP.

On 05/08/2017 04:38 PM, WordPress wrote:
> 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.

Sick!
It was annoying not being able to use modesetting on my boards.
> Https downloads are the default for all payloads now

Nice, good for slightly better security and to make it more difficult 
for people to know exactly what you are downloading.
Certificate pinning support should be the next step.
The debian clearsigner bug is one of the examples as to why https adds 
another layer of security.
>    Fighting blobs and proprietary HW components
>
> 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.

It would be great if there was a ME blob hash database, I am paranoid of 
getting a bogus one when I buy stuff off ebay.
It sketches me out to use the one from the flash chip that comes with 
the board, rather than simply a BIOS update etc (I don't know how to 
extract it successfully)
There are rumors of signing keys floating around on the internet.
> 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).

There should be an easier way for people to test stuff, I myself haven't 
bothered to do it yet as you need an openid, then a gerrit account, then 
you need to run a program on the device itself (which is difficult if 
you are using it as a router/firewall such as on my AM1ML)

If it was a more automated process where an account isn't needed that 
would encourage more people to do it.

Studies indicate that e-commerce websites that require people to create 
an account to buy something have a much lower sales conversion rate.

[Felipe Sanches]

2017-05-09 18:14 GMT-03:00 [e-mail] :
> It would be great if there was a ME blob hash database, I am paranoid of
> getting a bogus one when I buy stuff off ebay.

As a reference, MAME is a 20+ year old project that has a good track
record of documenting arcade/old-computer board ROMs by keeping track
of their hashes. It would probably be pretty good to do the same with
modern computer BIOS images.

Testing code out of Gerrit and old repo code

[Peter Stuge]

[e-mail] wrote:
> There should be an easier way for people to test stuff, I myself haven't 
> bothered to do it yet as you need an openid, then a gerrit account,

It is unfortunately completely unsustainable to operate a publically
accessible read+write service without authentication and/or other
anti-spam measures.

Any service with slight exposure will have significant traffic from
hand-crafted bots in no time.

There are no good readily available solutions for this problem. :(

//Peter

[David Hendricks]

On Tue, May 9, 2017 at 2:14 PM, [e-mail]  wrote:
> 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).
>
> There should be an easier way for people to test stuff, I myself haven't
> bothered to do it yet as you need an openid, then a gerrit account

How do you plan to submit patches to add boards or fix old ones so they
continue to build?

I remember there was talk about a non-gerrit workflow early on since some
people preferred using the mailing list to send patches, though I'm not
sure how far that got. And in that case they were fine with creating an
account so they could pushing patches and weren't asking for a whole other
authentication mechanism to be maintained by the time-constrained admins.

, then you need to run a program on the device itself (which is difficult
> if you are using it as a router/firewall such as on my AM1ML)

Can you please elaborate? If you're going to flash and reboot, why does it
matter if your system is a router/firewall? How would one report stats
without running a program on the device itself?
> If it was a more automated process

Suggestions welcome. Would an init script help?
> where an account isn't needed that would encourage more people to do it.
>
> Studies indicate that e-commerce websites that require people to create an
> account to buy something have a much lower sales conversion rate.

We thought about that briefly way back (https://mail.coreboot.org/
pipermail/coreboot/2013-November/076587.html), but nobody seems to have
thought of a better way to prevent spam and abuse. Again, suggestions
welcome.