<div dir="ltr"><div class="gmail_quote"><div dir="ltr">Am So., 25. Nov. 2018 um 17:14 Uhr schrieb <a href="mailto:Taiidan@gmx.com">Taiidan@gmx.com</a> <<a href="mailto:Taiidan@gmx.com">Taiidan@gmx.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can agree yes some stuff that clearly no longer works should be<br>
removed from master but people were talking about for instance removing<br>
the native fam15h boards KGPE-D16 and KCMA-D8 (last and best owner<br>
controlled libre firmware x86 boards and arguably the best examples of<br>
coreboot ports and hw init code)<br></blockquote><div>To be honest, in my opinion the Intel i945/gm45 hw init beats anything that's out there for AMD.</div><div>I may be biased though :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I feel as though at the current rate of people being too eager to remove<br>
still functional boards for arbitrary reasons there won't be any easily<br>
obtainable non development boards on master - </blockquote><div>It's not so arbitrary: The problem is that every deviation we carry along in the tree means an explosion in the feature and test matrix: Every boolean option means that we have twice as many configurations that could go wrong.</div><div><br></div><div>There are two conflicting statements by non-developing users and we need some decision on how to deal with them:</div><div><br></div><div>1. Users want new features that land on master to work on their boards.</div><div>2. Users don't want to invest time in keeping their boards working on master.</div><div><br></div><div>2. is somewhat handled by telling users to go for the latest release and/or commit that is known to work, but that means that they won't benefit from newer features.</div><div><br></div><div>Even without the efforts to streamline coreboot development which mean that old APIs are shut down, there's no guarantee that boards will remain working on master without maintenance: This project deliberately does away with the traditional BIOS development model of "copy, paste, modify and forget", for greater cohesion and feature parity.</div><div><br></div><div>That approach comes at a cost, and one part of that is that without a maintainer for a board (since we also do away with the "forget" part of traditional BIOS development), the master branch is unreliable for that board by default.</div><div>Once there is a maintainer, the changes advocated for the next release or the one after that aren't _that_ much effort. And it's not like with the romcc-romstage removal, where we removed classes of devices (those without CAR), the changes proposed now are all completely on the software design side.</div><div><br></div><div>It may even work to set aside some time dedicated to testing patches somebody does without hardware access to bring up chipsets up to newest standards. Naturally that has more friction than having developer and user reside in the same place or even be the same person.</div><div>However for most boards we don't have any signal if anybody is still using them or has a desire to use a newer revision than whatever they already have on their boards.</div><div><br></div><div>Apparently this thread brought up some such interested parties, which I already see as a benefit, but I'd rather have a mechanism that doesn't require the threat of board removal. Suggestions welcome :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">another side issue is that<br>
coreboot repos don't contain the libs required to compile the older<br>
versions which are becoming increasingly unavailable with some only<br></blockquote><div>You're referring to the dependencies for crossgcc?</div><div>That's a good point, I'll see that I'll set up a mirror for those.</div><div>Everything else comes from git repos we control, so that should be safe. If I'm missing anything else in this assessment, I'd like to learn about it so I can fix it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">since it will only be able to initiate new x86 systems that happen to<br>
require binary blobs.<br></blockquote><div>Why no ARM or RISC-V? :-(</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have never met a comp-sci/comp-engineering graduate or anyone in a<br>
computer field who has heard of coreboot and that needs to change<br>
</blockquote><div>Uni Heidelberg used to use coreboot for FPGA work on AMD gear, they even contributed.</div></div><div>There are a few master theses that were written around coreboot.</div><div><br></div><div>Also, everybody on this mailing list is arguably "in a computer field" and I'd suggest that they have heard of coreboot.</div><div><br></div><div><br></div><div>Patrick</div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Google Germany GmbH, ABC-Str. 19, 20354 Hamburg<br>Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg<br>Geschäftsführer: Paul Manicle, Halimah DeLaine Prado</div></div>