coreboot October 2015

coreboot@coreboot.org

44 participants
137 discussions

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Aaron Durbin 28 Oct '15

28 Oct '15

On Wed, Oct 28, 2015 at 7:59 AM, Vladimir <quickcracktime(a)gmail.com> wrote: > On 10/28/2015 04:56 AM, Alex Gagniuc wrote: >> >> How will moving [AGESA] code [to a separate branch] affect supported [AMD] >> boards? >> > > The biggest problem here is: > > Various improvements and important bug fixes, that will be introduced to a > master branch and affect all the coreboot boards, will not be automatically > applied to that separate AMD branch. Those coreboot developers which have > AMD boards and want to constantly use and test latest and greatest coreboot > builds, they will have to constantly check the coreboot commit log and > backport all these improvements and fixes to their separate (and soon to be > abandoned) AMD branch. That will be adding lots of unnecessary manual work > and draining lots of workhours, which otherwise could have been spent on > writing the bug reports or improving a coreboot code which is common for all > the coreboot-supported boards. Those developers should then take a more active role in improving the code that is applicable to them. As it stands now, I don't see any work going in improving those code bases. > > As result, moving AGESA code will affect - and not only AMD boards: all the > coreboot supported boards will be indirectly negatively affected by that > change... > > Luckily Timothy Pearson has advised a perfect solution for this issue: > > On 28 October 2015 at 02:23, Timothy Pearson wrote: >> >> Perhaps in the short term we can port the remaining AGESA Fam15h boards >> to native init, and look into moving Fam14h to as much native as >> possible while still keeping the PSP happy with its blobs? >> > > If the AGESA boards will be ported to a native init, they will be able to > continue to be supported by a master branch! That approach will allow > coreboot developers with AMD boards to avoid spending time on backporting > the changes and concentrate on developing and testing the latest coreboot > builds from a master branch There's more to it than just moving to native init. That doesn't remove the maintenance burden. > > Best regards, > Vladimir Shipovalov > > On 28 October 2015 at 11:32, Patrick Georgi <pgeorgi(a)google.com> wrote: >> >> 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me(a)gmail.com>: >> > Here's a list of things I think should be moved to branches, right after >> > the 4.2 release: >> So far the idea was to drop things in master after a release, and >> create branches for releases (as I did for 4.1 yesterday, in addition >> to the tag). >> So, when dropping stuff after the 4.2 release, to go back to these >> things, you start from the 4.2 branch. >> >> > Now remember, this assumes branches are as first class >> > citizens as 'master'. Look at chromiumos coreboot: plenty of branches. >> > That shows it can work. >> There's a significant difference (and a problem that we'd inherit by >> adopting the chromium gerrit model): >> >> The difference is that Chromium firmware branches are made per-board >> for devices where not many changes are expected. >> The items you point out are most interesting for adding new boards >> (nevermind if this actually happens - but the Lenovo *60 stuff wasn't >> predicted a year before it happened either, 945 was "dead" then). >> If we go for branches for that, developing FSP1.0 coreboot will look >> quite different from master-coreboot. >> >> The problem we have with firmware branches over at Chromium is that, >> as far non-ChromeOS development is concerned, branches are where >> commits are pushed to die. They're not folded back into mainline >> Chromium nor coreboot.org. We don't really have a good solution for >> that. >> >> If we spawn tons of branches every time something becomes a bit >> inconvenient to deal with, we're quickly devolving into u-boot: >> vendors will just start maintaining their own branches, and porting >> high level features between those requires an immense amount of effort >> because there are many years of divergence between them. >> If you want a taste of that, try building something on Chromium's >> chromeos-2013.04 branch and then port it to upstream master. And that >> was just 2.5 years. >> >> tl;dr: hiding problems in branches won't serve us long-term. >> >> >> Patrick >> -- >> Google Germany GmbH, ABC-Str. 19, 20354 Hamburg >> Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: >> Hamburg >> Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle >> >> -- >> coreboot mailing list: coreboot(a)coreboot.org >> http://www.coreboot.org/mailman/listinfo/coreboot > > > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Aaron Durbin 28 Oct '15

28 Oct '15

On Wed, Oct 28, 2015 at 3:32 AM, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me(a)gmail.com>: >> Here's a list of things I think should be moved to branches, right after >> the 4.2 release: > So far the idea was to drop things in master after a release, and > create branches for releases (as I did for 4.1 yesterday, in addition > to the tag). > So, when dropping stuff after the 4.2 release, to go back to these > things, you start from the 4.2 branch. > >> Now remember, this assumes branches are as first class >> citizens as 'master'. Look at chromiumos coreboot: plenty of branches. >> That shows it can work. > There's a significant difference (and a problem that we'd inherit by > adopting the chromium gerrit model): > > The difference is that Chromium firmware branches are made per-board > for devices where not many changes are expected. > The items you point out are most interesting for adding new boards > (nevermind if this actually happens - but the Lenovo *60 stuff wasn't > predicted a year before it happened either, 945 was "dead" then). > If we go for branches for that, developing FSP1.0 coreboot will look > quite different from master-coreboot. > > The problem we have with firmware branches over at Chromium is that, > as far non-ChromeOS development is concerned, branches are where > commits are pushed to die. They're not folded back into mainline > Chromium nor coreboot.org. We don't really have a good solution for > that. > > If we spawn tons of branches every time something becomes a bit > inconvenient to deal with, we're quickly devolving into u-boot: > vendors will just start maintaining their own branches, and porting > high level features between those requires an immense amount of effort > because there are many years of divergence between them. > If you want a taste of that, try building something on Chromium's > chromeos-2013.04 branch and then port it to upstream master. And that > was just 2.5 years. > That presupposes there is work going on in those branches that is desired to be pushed back into another branch. Anyone can very much port forward something if they so choose. That's the point of the branching mechanism. What is your proposal for dealing w/ inconvenience? I haven't seen a modicum of change in that area. In fact, what we have seen is more boards being added that use the constructs that are inconvenient. From the few years that I have been involved in this project I have seen the airplanes pile up in the graveyard. So basically, it seems like status quo rules. Or the time horizon for change is so long (10 years) that the result is accumulation of more cruft? To add insult to injury there's no tenable way of making changes in these areas because the physical resources are not readily available to test against. As such there is no progress in fixing those inconveniences which in turn means an ever increasing burden for making non-periphery changes. Ignoring the #include "file.c" constructs, a large majority of the mainboards drive romstage flow entirely within those directories. i.e. main() starts in mainboard. There is no common/consistent flow for romstage on x86. That requires chipset as well as mainboard changes to rectify. How do you propose one goes about doing that? Build test it? Then have someone come 6 months later and say "hey, this doesn't work." > tl;dr: hiding problems in branches won't serve us long-term. What does serve us long-term? And what are those goals? Is it quantifiable by the number of mainboards checked into the coreboot.org repo that build regardless of the maintenance burden? > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Patrick Georgi 28 Oct '15

28 Oct '15

2015-10-28 13:59 GMT+01:00 Vladimir <quickcracktime(a)gmail.com>: > If the AGESA boards will be ported to a native init, they will be able to > continue to be supported by a master branch! That approach will allow > coreboot developers with AMD boards to avoid spending time on backporting > the changes and concentrate on developing and testing the latest coreboot > builds from a master branch I agree. Patches accepted. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Vladimir 28 Oct '15

28 Oct '15

On 10/28/2015 04:56 AM, Alex Gagniuc wrote: > > How will moving [AGESA] code [to a separate branch] affect supported [AMD] boards? > The biggest problem here is: Various improvements and important bug fixes, that will be introduced to a master branch and affect all the coreboot boards, will not be automatically applied to that separate AMD branch. Those coreboot developers which have AMD boards and want to constantly use and test latest and greatest coreboot builds, they will have to constantly check the coreboot commit log and backport all these improvements and fixes to their separate (and soon to be abandoned) AMD branch. That will be adding lots of unnecessary manual work and draining lots of workhours, which otherwise could have been spent on writing the bug reports or improving a coreboot code which is common for all the coreboot-supported boards. As result, moving AGESA code will affect - and not only AMD boards: all the coreboot supported boards will be indirectly negatively affected by that change... Luckily Timothy Pearson has advised a perfect solution for this issue: On 28 October 2015 at 02:23, Timothy Pearson wrote: > > Perhaps in the short term we can port the remaining AGESA Fam15h boards > to native init, and look into moving Fam14h to as much native as > possible while still keeping the PSP happy with its blobs? > If the AGESA boards will be ported to a native init, they will be able to continue to be supported by a master branch! That approach will allow coreboot developers with AMD boards to avoid spending time on backporting the changes and concentrate on developing and testing the latest coreboot builds from a master branch Best regards, Vladimir Shipovalov On 28 October 2015 at 11:32, Patrick Georgi <pgeorgi(a)google.com> wrote: > 2015-10-28 4:56 GMT+01:00 Alex G. <mr.nuke.me(a)gmail.com>: > > Here's a list of things I think should be moved to branches, right after > > the 4.2 release: > So far the idea was to drop things in master after a release, and > create branches for releases (as I did for 4.1 yesterday, in addition > to the tag). > So, when dropping stuff after the 4.2 release, to go back to these > things, you start from the 4.2 branch. > > > Now remember, this assumes branches are as first class > > citizens as 'master'. Look at chromiumos coreboot: plenty of branches. > > That shows it can work. > There's a significant difference (and a problem that we'd inherit by > adopting the chromium gerrit model): > > The difference is that Chromium firmware branches are made per-board > for devices where not many changes are expected. > The items you point out are most interesting for adding new boards > (nevermind if this actually happens - but the Lenovo *60 stuff wasn't > predicted a year before it happened either, 945 was "dead" then). > If we go for branches for that, developing FSP1.0 coreboot will look > quite different from master-coreboot. > > The problem we have with firmware branches over at Chromium is that, > as far non-ChromeOS development is concerned, branches are where > commits are pushed to die. They're not folded back into mainline > Chromium nor coreboot.org. We don't really have a good solution for > that. > > If we spawn tons of branches every time something becomes a bit > inconvenient to deal with, we're quickly devolving into u-boot: > vendors will just start maintaining their own branches, and porting > high level features between those requires an immense amount of effort > because there are many years of divergence between them. > If you want a taste of that, try building something on Chromium's > chromeos-2013.04 branch and then port it to upstream master. And that > was just 2.5 years. > > tl;dr: hiding problems in branches won't serve us long-term. > > > Patrick > -- > Google Germany GmbH, ABC-Str. 19, 20354 Hamburg > Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: > Hamburg > Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle > > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Alex G. 28 Oct '15

28 Oct '15

On 10/27/2015 01:36 PM, Vladimir wrote: > Although I agree with you that AMD is not innocent as well, if you would > check a "Binary situation" page at coreboot's wiki, you would see that > Intel is in three times more evil Probably "evil" is a bad term. I doubt that there's an ill intent. There are customer (read OEMs) who want such "features". Remember the Lenovo laptops that only allowed you to connect white-listed wifi cards before they would boot? [1] The real issue is that some of those "features" cannot be disabled, but that's a technical argument, and has nothing to do with evil vs good. > (still could not understand why some > incredibly talented coreboot developers are spending so much time > fighting Intel's ME issues, I can't speak for others, but that allows me to continue to work on coreboot, while also paying the bills. In fact, there is a significant number of developers who pay their bills by working on coreboot. That's progress that coreboot wouldn't otherwise see. > In any case, it would be very sad to see the AMD code gone from the > master branch. Even the code for some unpopular boards like Intel > Atom-based EOL "Mohron Peak" was allowed to stay! There are two reasons for that, one technical, and another one political. On the technical side, there are users, and people stepped up to maintain that code. That's usually sufficient to allow code back in. On the non-technical side, one or two of the developers who originally committed that code got very offended, angry, and blindsighted by the fact that it was removed. I won't go into the details. > Why AMD boards are considered worse? The sole idea of AMD code going away, Who said AMD is worse? And who said AMD is going away? The whole idea is to move it to a separate branch. This has two advantages: * it's only concerned with agesa boards, so it's not constrained by the needs of other hardware * the master branch is no longer held back by the integration issues of agesa Positive side-effects: * No longer need to build-verify AGESA for unrelated changes (AGESA boards take up more than half the server time) > which will affect many alive-and-kicking coreboot-supported AMD boards, How will moving code around affect supported boards? > is beyond my comprehension BRANCH NOT EQUALS REMOVAL Does that help? Someone in this thread (was it you Stefan?) was also suggesting we wait until 4.3 release before we "remove" AGESA code. I know this whole discussion started as "removing" stuff, but nobody wants to remove anything anymore. We've gotten smarter. We just make the effort more distributed and less centralized. I think moving to branches should be done sooner rather than later. Here's a list of things I think should be moved to branches, right after the 4.2 release: * AGESA reason: integration issues * binaryPI reason: integration issues * FSP 1.0 reason: integration issues * MRC boards reason: sandy/ivy already has native init path. Some chromebooks have already been converted. See the pattern? Now remember, this assumes branches are as first class citizens as 'master'. Look at chromiumos coreboot: plenty of branches. That shows it can work. If people apply that pattern, there are a few other things that could be branched, but I intentionally excluded: * ROMCC-only boards: why not: x86 bootblock still uses ROMCC, so there's no immediate value in removing boards that also need ROMCC for romstage. Maybe we should think of it for some future release, once we get more hardware to use CAR setup in the bootlock. * google FSP boards (informally, FSP 1.1) why not: the FSP spec that's used on those boards is subject to change (and become 1.2, 1.3, etc), and there's no indication that we'll see significant integration issues if that happens/after it goes live. Hope this clears things up, Alex [1] http://www.coreboot.org/images/6/68/Network_card_bios.jpg > > On 27 October 2015 at 23:15, Timothy Pearson > <tpearson(a)raptorengineeringinc.com > <mailto:tpearson@raptorengineeringinc.com>> wrote: > > On 10/27/2015 03:10 PM, Vladimir wrote: >> It would be really wrong to remove the whole AGESA code: there are >> AMD-based products which are still very alive and actively sold (at the >> developing markets) Moving the support for these products to a separate >> coreboot branch, could create many inconveniences for those AMD product >> owners who would like to test & use the latest and greatest coreboot >> build: they will have to backport all the commits of code that's used by >> all the boards, to that separate abandoned branch - which would cause a >> lot of hassle and would basically cut them off from the development > >> I agree that removing could be done to some 2009 VIA-based EOL boards >> that nobody cares about, but it would be a mistake to do that to all the >> AMD products, some of which are still produced to this date and used >> together with coreboot by lots of people from this mailing list > >> Also, that action will send a bad signal to AMD. AMD is actively >> supporting the coreboot project and is much more friendly to open source >> community than Intel with it's ME and creepy lock-it-all desires. >> Removing AGESA code would be an equivalent of telling "we don't need >> your code" to AMD, one of the largest coreboot supporters, and that >> could lead to a terrible consequences > > AMD is hardly innocent on that front; they require a large binary blob > to execute on the auxiliary CPU at bootup, with unknown security > consequences. Also, as far as I understand there has been no new AGESA > source release for some time, only binary blobs. > > > > >

3 2

Re: [coreboot] Linux kernel hangs
by Zaolin 28 Oct '15

28 Oct '15

Hi, yep try this patch. Then it should work again. http://review.coreboot.org/#/c/12112/ Regards Zaolin > I'm testing the Lenovo T420 port[1]. After I saw some commits on > Sandy/Ivy RAM init and native graphics init code, I asked Nicolas > Reinecke to rebase and update the code. After I flashed the new > firmware, coreboot runs fine and boot to GRUB payload. However, Linux > kernel hanged and could not boot. I think there must be something > wrong with some of the upstream commits. > > [1] http://review.coreboot.org/#/c/11765/ > > Iru Cai > -- > coreboot mailing list: coreboot(a)coreboot.org > http://www.coreboot.org/mailman/listinfo/coreboot

2 1

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Vladimir 27 Oct '15

27 Oct '15

Thank you for this enlightening message about blobgesa... Luckily AMD was 10 years slow at following Intel's ME example, 10 years since ME first version, and it was not until 2015 that built-in Platform Secure Processors completely took over the AMD's Mobility family ( Kaveri from 2014 still didnt have PSP ) . Desktop family has 2015 Godavari without the PSP. It seems that PSP-blobgesa plague is going from low end to high end direction, and - while it took over the mobility family - desktop high end is still OK, and server family is far from it (so far only low end "seattle" servers are affected) Hopefully this blobgesa will be open sourced eventually - its not that far from reality because AMD open sourced a lot of stuff during the past months... Also it will be very interesting to see how AMD Zen platforms will behave Best regards, Vladimir Shipovalov On 28 October 2015 at 00:35, Felix Held <felix-coreboot(a)felixheld.de> wrote: > > if you would check a "Binary situation" page at coreboot's wiki, you would >> see that Intel is in three times more evil >> > That page is outdated. Newer AMD systems have the platform security > processor, which is quite similiar to the ME. > > http://www.uefi.org/sites/default/files/resources/UEFI_PlugFest_AMD_Securit… > has some information on the PSP. > Chips with PSP are btw. only supported by blobgesa. > > Also the AGESA source is quite a mess (I started to do some cleanups > there, but finally dropped the project, because it wasn't worth the time > for me) and having native initialization will be much better. > > Regards > Felix >

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by ron minnich 27 Oct '15

27 Oct '15

I think we can make it clear to AMD that we are grateful for AGESA and their support, and the way they have helped us to get to a good place in terms of code; and, further, we can now offer a better option, with code that really fits well into coreboot. I don't see demoting AGESA as a bad thing; it's a good thing. AGESA got us to where we are, and now we take the next step: code that is well integrated. In fact I think we're all giving AMD a huge vote of confidence by making the effort to make their chips fit really well into coreboot, instead of being half-in/half-out. This is going to be a big improvement. We're not tossing AMD out; we're inviting them into the living room, with a warm fire and a nice place to sit down and relax :-) ron

1 0

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Timothy Pearson 27 Oct '15

27 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2015 03:36 PM, Vladimir wrote: > Although I agree with you that AMD is not innocent as well, if you would > check a "Binary situation" page at coreboot's wiki, you would see that > Intel is in three times more evil (still could not understand why some > incredibly talented coreboot developers are spending so much time > fighting Intel's ME issues, while AMD boards don't have that "dragon you > have to tame" on board) > > In any case, it would be very sad to see the AMD code gone from the > master branch. Even the code for some unpopular boards like Intel > Atom-based EOL "Mohron Peak" was allowed to stay! Why AMD boards are > considered worse? The sole idea of AMD code going away, which will > affect many alive-and-kicking coreboot-supported AMD boards, is beyond > my comprehension This is why I was advocating a gentle demotion to second class status. You can still use the AGESA code where needed, but native intialization would be preferred for new ports. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWL+FhAAoJEK+E3vEXDOFbjmIIAK3Tf/KBLQH92uCJsCn5ekJv S5hE1LdDBvRXM5p3xZWarqnomfvbxeNP8fg9PfOixxDLLSE/gWKE5B1H119le5Dl aXU99ge7dMefZ9uxm0zfjKLvCsS/vc7ESqC+KKcYxK0Q1KswF/g6wLeaG8LS18wQ W83gZCTdFjW8YhTnxu8kzmXDT+2vT5CSSGQoN0d6gD0WZrti7gLCL1m9Nu5stnKt Kul93N7KmVYhdUAIBzyrsTl5/JV5JzOXgHFVUvhrUa1XqRk5DC1MjHHaTYA6W1kT +f5m9HnBTGP6G4agtHBiScq/XBCl7+MdMkx3Ecb32QMgyvcSlG3UMLXiax2UHYA= =nXMZ -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
by Timothy Pearson 27 Oct '15

27 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2015 03:10 PM, Vladimir wrote: > It would be really wrong to remove the whole AGESA code: there are > AMD-based products which are still very alive and actively sold (at the > developing markets) Moving the support for these products to a separate > coreboot branch, could create many inconveniences for those AMD product > owners who would like to test & use the latest and greatest coreboot > build: they will have to backport all the commits of code that's used by > all the boards, to that separate abandoned branch - which would cause a > lot of hassle and would basically cut them off from the development > > I agree that removing could be done to some 2009 VIA-based EOL boards > that nobody cares about, but it would be a mistake to do that to all the > AMD products, some of which are still produced to this date and used > together with coreboot by lots of people from this mailing list > > Also, that action will send a bad signal to AMD. AMD is actively > supporting the coreboot project and is much more friendly to open source > community than Intel with it's ME and creepy lock-it-all desires. > Removing AGESA code would be an equivalent of telling "we don't need > your code" to AMD, one of the largest coreboot supporters, and that > could lead to a terrible consequences AMD is hardly innocent on that front; they require a large binary blob to execute on the auxiliary CPU at bootup, with unknown security consequences. Also, as far as I understand there has been no new AGESA source release for some time, only binary blobs. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) http://www.raptorengineeringinc.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJWL9tLAAoJEK+E3vEXDOFbGXEH/Ar/eErlZp8biCEOO3EUKXN3 CXpvDMgjsWf8k0jmlW25ythzyEuD1fLsVhD84GvvO0anwMhT66IXtHVAyXUegd7T +iJd1MmthsSJRNW8xLhu9r+YEZInLAlq56HZ7ebnwbVmeokRhUdfCKUkUshPOO0N 73v5Q7SLQbhR8NwWzDF9jYF/DJyqfkgO1boBxDDGeV5XPzy5Ho+fwPFrH+E47nes 4u1uNxu8MYQvDoQzxIc/HE9scAhl79kuk3GUuiuoe6RlreKPlrFQVK0Rb+yIe/n+ 63mz53ZLdHCoglQLiGpMYlrQDSgzwvHH7i+lfavacgctJd7+Q0n5MFh9TppN4Uc= =G6dr -----END PGP SIGNATURE-----

2 1

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot October 2015