coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Re: [coreboot] Why do we have FSP-S
by Timothy Pearson 01 May '18

01 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/01/2018 02:46 PM, Zoran Stojsavljevic wrote: >> Our recommendation for some time has been a mix -- arm64 client devices >> (laptops, tablets, etc.) and ppc64el servers. With those two, you can >> replace x86 entirely if you don't have proprietary software in your >> environment. > > With all due respect, this is the discussion about Coreboot going into > The Right Direction! This is what I actually aimed for. :-) > Well, to bring this even further back on topic, it's an open secret that the POWER8/POWER9 IPL process is rather bloated. It's all open, but bloated. I'd love to see a coreboot port done in earnest to POWER9. We have all the information we need to do it, just need buy-in from serious developers. Might even be some free hardware in it for interested people.... - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJa6MeSAAoJEK+E3vEXDOFblSQIAJ9rnmQaNttblYXGPbKyDXp1 gjBSTRrWk93ZI/bn69nZSS+YS4tp3r/6GGkH9WGGX6/R+5/bk0Dd3gOILBt+MODv n+jlOccEbQn6Gnq/LkjzaYXVu5OI6kUmASJxSdylCu9qsqrbvDOUAkbCIuqWue81 Vp6UeOY0OSn0+fRtbYrfdUTJa+diHXC7YmfLliIk/8eTETU0TaQiZTmHtbiHPUWd qP6IV6MTuOFc30WU0qoKDPzX4PiKCUN8WSNs800Pb9eawtK6yo/5Jmb2aQG25jyD /T8EfLHUVvfyvMy9JP9gi1v2tq4DDacnUZwdFll+toNUjjkpVLk5QjP7mMjRIQA= =r15a -----END PGP SIGNATURE-----

1 0

Re: [coreboot] Why do we have FSP-S
by Timothy Pearson 01 May '18

01 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/01/2018 01:30 PM, Julius Werner wrote: >> All the ARM64 boards I've seen that are desktop or higher class ship >> with AMI UEFI and AMI BMC. Plus they contain their own magic blobs, >> some akin to the ME. ARM64 is not a panacea either; OpenPOWER's >> actually shipping open POWER9 systems right now with source code. Why >> not go down that route? > > Can we please stop bashing each other about whose architecture is better? I > haven't seen any POWER9 systems of laptop or lower class shipping either. > What makes one more important than the other? > > We actually have several ARM64 boards in the repository right now where you > can walk into a store and buy them for a couple hundred bucks, and install > fully open-source blob-free firmware on them straight from the coreboot > master branch. It would be great if the POWER port of coreboot can > eventually see this level of success as well. That's just more choice for > the users. > > I have also personally spent a bunch of time arguing with Arm SoC vendors > about open-sourcing their code and I think we can be pretty happy with what > we've achieved so far, even though we can always try to do even better. The > reason those ARM64 servers are heading the x86 route of running proprietary > UEFI (and, worst of all, implementing ACPI) is because no corporation with > sufficient influence is trying to guide them in the other direction. If it > wasn't for Chromebooks, the Arm laptop market might be going the same way. > That is also corporate influence. Don't mean to bash anyone. I get frustrated at times with the messages on here from people that want something they can't have (basically, cheap, powerful, and open -- pick two), and just wanted to say that there are open systems *right now*, no vendor coaxing needed. Our recommendation for some time has been a mix -- arm64 client devices (laptops, tablets, etc.) and ppc64el servers. With those two, you can replace x86 entirely if you don't have proprietary software in your environment. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJa6LWJAAoJEK+E3vEXDOFbcecIAKsBbAJXAoKukrjhQhrkuP7z ktNyJVlifl2T04DZ/TfihdnMfA9tRu+iNnnYEGbmdVpRxx2mVtUebImc5Sl/GKoJ oQmnRFF0MdXJUMvMSTtXUn9v6Ylq8jj9YIpi3hu1gQrRB7EtCNlcnZJFwnMaaTzV Xov48xgxhzZ9Wat5Mu447kOpcebUzVM1BwFDxf0kcyZxAe742I5t86S2RDAxAaMZ 4DoAHq1aB/PR9cjXQMkn2EV6hg3Xn4/rxHkNqOxI3PwU7lSYEBgZCyom8JVhixAQ TNzvthHanakV8xX57y23vibANAmeLII/v6D7z6bNZt9B54XRdsqFTDGM02/C79Y= =Cv5s -----END PGP SIGNATURE-----

2 1

Re: [coreboot] [RFH] Status of the Lenovo X201
by qtux 01 May '18

01 May '18

I wrote a patch [0] for the finalize code issue. With that my X201i is working fine on current master besides an regression introduced in commit 7f5efd90e598320791200e03f761309ee04b58a3 [1]. With that regression USB and SD card is not working anymore and it raises the following errors: [ 17.986754] usb 1-1: device not accepting address 2, error -110 [ 18.110095] usb 1-1: new high-speed USB device number 3 using ehci-pci [ 18.200089] usb 2-1: device not accepting address 2, error -110 [ 18.323421] usb 2-1: new high-speed USB device number 3 using ehci-pci [ 34.200083] usb 1-1: device not accepting address 3, error -110 [ 34.200169] usb usb1-port1: attempt power cycle [ 34.413364] usb 2-1: device not accepting address 3, error -110 [ 34.413439] usb usb2-port1: attempt power cycle [ 34.636752] usb 1-1: new high-speed USB device number 4 using ehci-pci [ 34.850085] usb 2-1: new high-speed USB device number 4 using ehci-pci [ 45.293417] usb 1-1: device not accepting address 4, error -110 [ 45.416732] usb 1-1: new high-speed USB device number 5 using ehci-pci [ 45.506783] usb 2-1: device not accepting address 4, error -110 [ 45.630088] usb 2-1: new high-speed USB device number 5 using ehci-pci [ 56.173393] usb 1-1: device not accepting address 5, error -110 [ 56.173445] usb usb1-port1: unable to enumerate USB device [ 56.386753] usb 2-1: device not accepting address 5, error -110 [ 56.386845] usb usb2-port1: unable to enumerate USB device Additionally there are some IRQ errors inside the kernel messages like can't derive routing for PCI INT A PCI INT A: no GSI for different devices which seem related to the change in [1]. Cheers, Matthias [0] https://review.coreboot.org/#/c/coreboot/+/25914/ [1] https://review.coreboot.org/#/c/coreboot/+/22859/ On 29/04/18 14:14, Kyösti Mälkki wrote: > On Sun, Apr 29, 2018 at 1:35 PM, Nicola Corna <nicola(a)corna.info> wrote: >> April 28, 2018 5:59 PM, "Nico Huber" <nico.h(a)gmx.de> wrote: >> >>> Yes, that's very likely a problem. It looks like the whole finalize code >>> path of the X201 was untested all the time (even on resume). I don't >>> remember if EHCI debug works in SMM? If it does, you could enable log- >>> ging for the SMI handler as well (if you want to debug it). >>> >>> Nico >> Attached you can find the log with the SMM debug enabled, but it doesn't seem >> to me much different from the non-debug log. >> >> Nicola > DEBUG_SMI does not output to EHCI, I have considered it too unstable. > > You can try your luck with attached patch to have DEBUG_SMI=y output > on EHCI debug. EHCI console code does not take precautions against > someone else touching the same register set so it's likely to fail > once payload and/or OS loads its EHCI driver, possibly making USB > media and keyboard unusable as well. > > Kyösti

3 2

Re: [coreboot] Thread derailment
by ron minnich 01 May '18

01 May '18

We've had to remove people from the list before, and I suppose at some point it might have to happen again. Nobody likes this option. Sometimes there is no choice. I agree that on a technical discussion list there's no place for abusive language. We're all trying to do the best we can in a non-ideal world. ron On Tue, May 1, 2018 at 9:03 AM David Hendricks <david.hendricks(a)gmail.com> wrote: > Hello all, > Recently I've noticed an uptick in threads going off-topic. While some > noise should be expected on an open source mailing list, I think it's > become very counterproductive in many recent cases. A good example is the > FSP-S thread going on where we see clear examples of people interjecting > with non-technical diatribes and disrespecting developers, corporate > contributors, and coreboot itself in violation of the existing community > standards (https://coreboot.org/Code_of_Conduct). > > Most of this is perpetrated by a very small handful of individuals who > have not contributed anything to the codebase, so I think the current > problem could be dealt with easily. It might also be worth adding something > about keeping threads on-topic and focused on technology in the Code of > Conduct. > > Another option would be to have a developer-only mailing list, but I think > it's best to try and keep things open to the community at large even if > that means ejecting the most disruptive members. > > Thoughts? > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Thread derailment
by David Hendricks 01 May '18

01 May '18

Hello all, Recently I've noticed an uptick in threads going off-topic. While some noise should be expected on an open source mailing list, I think it's become very counterproductive in many recent cases. A good example is the FSP-S thread going on where we see clear examples of people interjecting with non-technical diatribes and disrespecting developers, corporate contributors, and coreboot itself in violation of the existing community standards (https://coreboot.org/Code_of_Conduct). Most of this is perpetrated by a very small handful of individuals who have not contributed anything to the codebase, so I think the current problem could be dealt with easily. It might also be worth adding something about keeping threads on-topic and focused on technology in the Code of Conduct. Another option would be to have a developer-only mailing list, but I think it's best to try and keep things open to the community at large even if that means ejecting the most disruptive members. Thoughts?

1 0

Re: [coreboot] Why do we have FSP-S
by Taiidan＠gmx.com 01 May '18

01 May '18

Like I have said I believe the gradual encroachment of blobs and corporate control will end up leaving coreboot dead in the water and eventually even code not related to platform initiation will be blobbed, coreboot will be an open source project only in theory not in reality - the only boards that work with coreboot v8 or w/e will be unobtainable development boards requiring not just blobs but an NDA and special connections to obtain. Lets say 10 years from now, will there be a coreboot? I doubt it - you can't sustain a project like this without passion and people who believe in freedom not fake "freedom" (ie: a certain company who entertains the idea that x86 can still be free with some kind of magic) Then again in a decade you probably won't even be able to run the programs you want on a computer without approval and submission of a scanned passport and CS masters degree let alone firmware - look on the list today and you will see people who entertain the concept that computing freedom is simply not "safe" for those not blessed and tell me that isn't the future? On 04/30/2018 11:11 PM, Zoran Stojsavljevic wrote:> >> OpenPOWER's actually shipping open POWER9 systems right now >> with source code. Why not go down that route? Here here! - freedom today not tomorrow! > > The only obstacle to this one is the price. If the price goes 2x down, > it would be the perfect technical solution. :-) >If you assemble your own TALOS 2 it costs less than a proprietary intel/AMD platform with equivilant performance and features, and I consider this a miracle - it isn't meant to compete price wise with a bargain basement x86 dell "server" or what not. The idea too is that you will have it for quite longer than a normal PC, as it is very fast, high quality (assembled in usa!), and you will continue receiving security updates for much longer than with most boards. If someone is very broke they can always get one of the cheaper coreboot-libre boards which still function and are easily available.

2 1

Re: [coreboot] Why do we have FSP-S
by Zoran Stojsavljevic 01 May '18

01 May '18

The magic formula to all this, INTEL improvement, is everything contained in only one word: ARM64! This is a very politically correct Civil Approach, don't you agree?! ;-) Best Regards. Zoran Stojsavljevic _______ On Tue, May 1, 2018 at 1:46 AM, David Hendricks <dhendricks(a)fb.com> wrote: > > You are just, with this desperate chit-chat, fueling INTEL's big EGO. > Please, continue to do so! INTEL, at the end of the day, will thank > you for that! :-)) > > Please keep things civil. Whatever you think of Intel and FSP, this is a > good opportunity to improve support for coreboot and others reading this > thread would like to see progress. > > > ------------------------------ > *From:* coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zoran > Stojsavljevic <zoran.stojsavljevic(a)gmail.com> > *Sent:* Monday, April 30, 2018 9:58:33 AM > *To:* Nico Huber > *Cc:* Nathaniel L Desimone; Furquan Shaikh; Vincent Palatin; > coreboot(a)coreboot.org; Aaron Durbin; Stefan Reinauer; Martin Roth; ron > minnich; Shelley Chen; Julius Werner; Vadim Bendebury; Nick Vaccaro; Chris > Ching; Duncan Laurie; Subrata Banik > *Subject:* Re: [coreboot] Why do we have FSP-S > > Nico, Aaron, > > You are just, with this desperate chit-chat, fueling INTEL's big EGO. > Please, continue to do so! INTEL, at the end of the day, will thank > you for that! :-)) > > Zoran > _______ > > On Mon, Apr 30, 2018 at 4:48 PM, Nico Huber <nico.h(a)gmx.de> wrote: > > Hello Aaron, > > > > thanks for your reply. > > > > On 30.04.2018 05:22, Aaron Durbin wrote: > >> On Sat, Apr 28, 2018 at 7:16 AM, Nico Huber <nico.h(a)gmx.de> wrote: > >>> Hello coreboot folks, hello Intel and Google coreboot developers, > >>> > >>> back on Tuesday, some of us discovered a commit on gerrit [1] that > >>> implements (another) foreign interface inside coreboot. Discussing > >> > >> It's more of a bridge into coreboot's infrastructure, imo. > > > > It is. Anyway, maybe discuss that in another thread or on gerrit. > > > >> > >>> it didn't go well and I kind of bursted. I feel sorry about that now > >>> (especially because I got too personal). > >>> > >>> One of the causes for this clash definitely was that things apparently > >>> were discussed before but not with coreboot (i.e. this coreboot mailing > >>> list). So I'll try to take the general discussion here, but I've to > >>> start some years back, where you lost me. > >>> > >>> Some questions (that I believe have to be answered) right away. I'll > >>> argue about why later, so these won't get lost (in an already too long > >>> email): > >>> > >>> > >>> TLDR; > >>> For Google: > >>> You kind of introduced blobs in coreboot (with Sandy Bridge) which was > >>> a simple jump-in-jump-out thing and kind of accepted. The argument was > >>> that the things it does aren't documented by Intel anymore, AFAIR. But > >>> with Broadwell suddenly another blob emerged (in ramstage) some > >>> `refcode.elf` AIUI. It turned out, later, that this blob (also) does > >>> things that were open source for Haswell (and would work verbatim on > >>> Broadwell). It seems to play a role comparable to FSP-S. > >>> o What's the story behind this blob? > >>> o Why was it introduced? > >>> o Was there more than IP concerns? Time to market pressure maybe? > >> > >> Saying it's comparable to FSP-S is apt. The story is, like most > >> things, that it has specific things that are not architectural that > >> Intel thinks they need to be secret. Typical settings are related to > >> power management. When needing to be competitive in the laptop space > >> power is a big concern. Time to market may have been a thing too, but > >> I don't recall all the specifics. I'll get to it later in the > >> response, but there are temporal components to decisions and/or how > >> things change over time that are not within Google's control when > >> working on a particular platform. > >> > >>> > >>> For Intel: > >>> It's hard for me to understand what parts of your silicon init you can > >>> open-source and what parts you can't. I know your BIOS Writer's Guides > >>> (BWG) / BIOS Spec, and many things therein are often published by you > >>> or Google. Please tell us. > >>> o Are the things that you can *not* open-source documented at all? > >>> o if so, in these BWG documents? > >>> o Or is everything in these documents generally publishable (with > >>> some NDA clearance, ofc)? > >>> o For a configuration of FSP-S that just runs the bare minimum to > >>> boot (e.g. skips questionable add-ons like TXT, SGX), is there > >>> anything not publishable? > >>> o Can anything be done to get more documentation published? e.g. > >>> for things that are done in open source (or were done in the past) > >>> but are not publicly documented. > >> > >> Based on my working history a lot of BWGs and/or specs are usually > >> wrong. They don't always contain the right information, but generally > >> contain quite a few things that are wrong where you second guess > >> everything in the docs. This should sound familiar: the 'reference > >> code' is the documentation. Most docs are not in sync with reality or > >> necessarily with how the silicon was actually designed. It's my belief > >> when there wasn't as much change from version to version, the > >> copy-pasting in docs just kinda worked. But as things have been > >> getting more complicated and incorporating more 'features' the > >> documentation has not been keeping up. > > > > Still these documents exist. And I deem them most valuable. I know there > > are flaws that can drive you crazy. But! they give a very good overview > > about what has to happen for silicon init. If published (for my sake w/o > > the secret ingredient bits) [2], they would be a great reference for > > discussions about the design of clean silicon-init code. We could har- > > ness the power of the community much better. > > > > It doesn't matter if somebody with access to the reference code has to > > fix some bugs later, once you have a decent maintainable code base. > > Neither would a blob that hides the secret ingredients if it only con- > > tains those (and no infrastructure / control flow; I think you, Aaron, > > and me share the same opinion on that). > > > >> > >>> > >>> > >>> So why ask? The original introduction of blobs in coreboot in general > >>> happened with the argument that the things it does (e.g. memory init) > >>> are not documented anymore by Intel. This is a valid argument because > >>> the lack of documentation makes it harder to write clean code. I also > >>> believe it's true (that no documentation exists) because I've seen a > >>> previous BWG that already referred a lot to the reference code. > >>> > >>> But, AFAIR, the introduction of blobs in coreboot's *ramstage* was > never > >>> discussed. The blobs I've seen so far all did things that were already > >>> open source for earlier platforms. Plus they are twisting coreboot into > >>> something that isn't coreboot anymore. Architectural changes happen in > >>> chipset specific code instead of moving coreboot as a whole (after an > >>> open discussion). Also, most of the positive aspects about coreboot are > >>> lost. > >> > >> Purely business commentary: In order to develop a competitive laptop > >> on recent hardware one needs to include the features that consumers > >> expect. Intel also ties those features inside of FSP, but FSP has a > >> responsibility problem. It has traditionally attempted to do things it > >> should not. FSP should be a library of sorts, but it has things in > >> there it shouldn't. I mentioned some of this on the CL itself about > >> our usage of SkipMpInit. It trying to take over resources that it > >> shouldn't (among other things). > >> > >> What architectural changes are you referring to? And what is your > > > > You've got me there. I meant architectural things, not changes. Like > > that patch on gerrit. It doesn't seem to be Intel specific, I also > > can't find any soc_ reference in it. Yet, it's pushed to soc/intel/ > > and to me that looks like somebody wants to sneak it it (without big > > discussion / being thought through for all of coreboot). > > > >> definition of coreboot (I know see you wrote it below :)? early > >> firmware that will initialize everything in open source for Intel > >> platforms? I wish that were the case, but it's not something that is > >> allowed by Intel currently. I'd love to see more granularity in FSP, > >> but as noted in the CL commentary Intel hasn't been accepting of my > >> suggestions for making things more granular such that one could do the > >> only things that are deemed 'super secret' by Intel. The muddling of > >> responsibility and lack of granularity are the current result. > >> > >>> > >>> Of course, it's hard to argument about whether something is coreboot > >>> or not without a clear definition of coreboot. But let me get this > >>> one straight: It's definitely not coreboot just because it happens on > >>> coreboot.org. > >>> > >>> I'll try to sum up what is coreboot to me, and compare that to a > current > >>> coreboot with FSP. coreboot > >>> > >>> 1. is free software > >>> 2. is open source > >>> 3. is auditable > >>> 4. is lean (less code means less bugs) > >>> 5. gives control to the user > >>> > >>> but with FSP: > >>> > >>> 1. You can not fully adapt it, you can't even just download it (often > >>> have to steal the FSP binary): > >>> 0% > >>> 2. Comparing the sizes of open-source parts and FSP, maybe 30%. But > >>> if you don't count open-source code that is only needed to handle > >>> blob issues, rather > >>> 20% > >> > >> Is this 20-30% coreboot/open source of the total? Were you counting > >> the edk2 stuff in there? A lot of the bloat in FSP comes from open > >> source edk2. > > > > You can't count EDK2 into it. Once it's built into FSP, it's not open- > > source any more (unless somebody proves what parts match a reproducible > > compilation of the open-source code). And for an open-source experience > > you'd still need means to adapt these EDK2 parts in the binary. It was > > just a wild guess based on my experience with Kaby Lake FSP (~500KiB), > > and guessed 200KiB coreboot. > > > >> > >>> 3. If you are backed by a huge company or government, you can audit > >>> coreboot+FSP (I guess), if not than not, 50%? But given that the > >>> size of the whole package is about 10 times the size of a clean > >>> implementation, you have to audit 10 times more code (of much > >>> poorer quality), thus at most > >>> 5% > >>> 4. 0% (see above) > >>> 5. That seems to be my only point that Intel cares about. Still, > >>> coreboot compatible binaries are often not available. You need > >>> very weird workarounds if the one setting you miss is not there: > >>> 50% > >>> > >>> Numbers are just educated guesses, but might match reality. If you > >>> average these, you'll see that coreboot+FSP is only 15% of (my) > >>> coreboot. I would estimate that you can get up to 20% with the > >>> design of FPS2.0. > >> > >> I agree with the overall assessment above. As currently > >> deployed/supported FSP is not really geared to people who don't have a > >> more intimate relationship with Intel. It's been brought up numerous > >> times, but it's Intel's decision to make a better product. > > > > Right, quality of their products is up to them. But isn't it our re- > > sponsibility to decide whether they can do that (15%) in the name of > > coreboot? > > > > Nico > > > > [2] Assuming that the BWGs don't contain the secret ingredients, even > > an NDA offer to all coreboot developer's (both hired ones and indi- > > viduals) could help. If Intel allows to derive open-source code from > > it (e.g. after a private review on gerrit) people would have less > > doubts about signing an NDA, IMHO. Just a random thought; anything I > > can come up with atm seems to be better than the status quo. > > > >>> > >>> So it's time for an FSP3.0 that was designed with the community, > >>> I'd say. > >>> > >>> Best regards, > >>> Nico > >>> > >>> [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__review. > coreboot.org_-23_c_coreboot_-2B_25634_&d=DwICAg&c= > 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme > YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80& > s=_TJ-Ft6l7FJJmJ1VJ-GJJfSzItat6lK0i15bv5BNSl0&e= > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail. > coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c= > 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme > YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s= > OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e= > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail. > coreboot.org_mailman_listinfo_coreboot&d=DwICAg&c= > 5VD0RTtNlTh3ycd41b3MUw&r=CFWWReJabtqA8oU7yaBHbIE9YvsZme > YWXWpJOiuGyNM&m=3wwXcqkQtroFB_kT3W-a0IFzj6sYZDqT1C8O9vYVP80&s= > OnpcOaHyTeaZP13RrmLnm8XTsPwDbszJ7xWXe_PpavY&e= >

1 0

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 May 2018