coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

FSP 2.0 headers in coreboot
by Youness Alaoui 04 May '18

04 May '18

Hi, I've just pushed a commit for review on gerrit (https://review.coreboot.org/#/c/coreboot/+/26108/) and I'm hoping to open the discussion here on whether the public coreboot code should have the FSP headers that match the public FSP headers or if they should match the 'google fsp' headers. My understanding of the situation is that chromebooks ship with a google-modified FSP image and the fsp headers in coreboot have been added by google employees even before the FSP was officially made public by Intel. I also somewhat understood that the fsp headers in coreboot would not be updated to match the public release because it would break everyone building coreboot for their chromebooks or something like that. I'm a bit tired of always having that commit that fixes the header applied locally in all my branches, and I think that it makes much more sense for coreboot to have the fsp headers that match the public release and for the google/chromebook coreboot repository to have the "non-standard header" committed to it instead. Worst case scenario, we could add #ifdefs to determine what the structure contents should be depending on the target platform. Maybe everyone will say "of course, that makes sense" or maybe everyone will say "nope, I disagree", but hopefully we can have the discussion here (or on gerrit) and decide how to handle this use case. Note: I only pushed for skylake/kabylake, but apollolake/canonlake are probably also affected by this mismatch of headers. Thanks, Youness.

1 0

Re: [coreboot] Why do we have FSP-S
by Zaolin 04 May '18

04 May '18

You forgot Cavium Thunder X SoC support, Stefan ;) Finally coreboot supports it and there are no blobs on this platform. On 04.05.2018 20:01, Stefan Reinauer wrote: > * Timothy Pearson <tpearson(a)raptorengineering.com> [180501 04:58]: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> 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; > It's certainly good to have more options. > > As far as AArch64 goes... > Google's Pixel C is ARM64 and running coreboot. All rk3399 devices, too. > > Stefan > >

2 1

Re: [coreboot] Why do we have FSP-S
by David Hendricks 04 May '18

04 May '18

Hi Kyösti, That's a great post-mortem, thanks for writing it up! I didn't mean to imply that binary PI is a great example of how to do things, I just think Bruce's explanation is useful for answering Ivan's question of why companies don't simply open their code. As you point out binary blobs aren't a magic bullet and can end up a bitrotting mess with no salvageable value for other potential customers. Intel's done a better job with FSP so far, hopefully we can convince them that opening it up will add significant value for them by enabling more customers and more products. On that note, a shameless plug: http://www.opencompute.org/projects/open-system-firmware/ On Thu, May 3, 2018 at 1:37 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > Hi David, > > I tried to stay away from commenting, but now that you pulled this red > binaryPI card from your pocket :) > > On Wed, May 2, 2018 at 9:49 PM, David Hendricks > <david.hendricks(a)gmail.com> wrote: >> >> Bruce Griffith's e-mail about AMD's binary PI provides some great >> insights into these issues: >> https://mail.coreboot.org/pipermail/coreboot/2014-November/078892.html >> > > I did not revisit that entire thread, judging by the date it was > possibly prior to binaryPI code drops. From my perspective the only > intention with binaryPI was for SAGE to gain a monopoly consulting > position on AMD based coreboot board ports, leaving them the only ones > capable of building and debugging with the blob. I don't think any of > the advertised benefits realized and the problems with time-to-market > were not solved. I believe SAGE got the final nail on their coffin > after AMD started to lock x86 JTAG debug (aka HDT) on their new SoC's > and made SAGE EDK tool unusable. > > When referring to binaryPI below, I am ruling out ongoing development > around StoneyRidge SoC. Somewhat different team, more strict quality > goals as set by ChromeOS and much more resources and review talent put > on the task now. Or so I have been told at least. > > The aftermath of binaryPI (say, version 0.1) : > > 1. Nobody *1 can reproduce the binaryPI blob builds that were pushed > to coreboot 3rdparty repo. For most of these, I bet the source tree > revision could not be traced back either. Source repositories are > somewhere in the ruins of AMD AES and SAGE ex-personnel. > > 2. The needed binaryPI source is somewhat heavily patched version of a > package, which a commercial partner is (or was) able to get through > his AMD representative under an NDA and longish negotiations and > promises of significant purchase volumes. In other words, your AMD > reps cannot provide you with the source or the binary you need for use > with coreboot. > > 3. After the binaryPI contractor SAGE shut down and AMD AES bailed out > on coreboot (late 2015?), AMD has not granted permission to > redistribute new builds of these binaryPI blobs even if we had the > sources. And we do have the source for x86 AGESA parts, but not for > PSP. > > 4. Commits of updated blob builds mostly just referenced AMD internal > bugtracker ID numbers. For some cases, you cannot use the latest build > of these blobs as they break elsewhere. In other words, for best user > experience, you build the blob from the source you do not legally > have. > > 5. Features partially or completely known broken in pre-built blobs > (depending of SoC): ECC, HSA, IOMMU, S3 suspend, C6 boost, SPI > dual/quad, fastboot (aka MRC cache). > > 6. AMD ignored or refused requests to provide debug builds of said > blobs to create meaningful bootlogs on console, comparable to > open-source AGESA. Also built-in error backlog feature in non-debug > builds was initially broken, and once fixed, you still needed the > source to decipher the error. > > 7. Some of the PSP (aka Security Processor) firmware in 3rdparty was > modified for coreboot use. Commit message refers to which version was > submitted, but file hash does not match with one you obtained from AMD > reps. Someone with access to PSP's private key has approved the > modifications, but none of this was mentioned with the commit. > > Needless to say, with all the issues above, it's hard to attract new > industrial users on coreboot when product longevity is at risk due to > uncertanities of having no firmware evaluation. After this first > attempt of going closed-source with AGESA, there is one actively > shipping product (5 board variants) from 2015. Not counting reference > designs, there are less than five other commercially ported boards in > this group from 2015-2017. AFAICS these board boot with coreboot only > inside the companies R&D, some use custom builds of binaryPI blob > while others link original (but modified) proprietary AMD source > together with coreboot proper. I understand some would rather not ship > with proprietary UEFI, but the legalities... > > I feel disheartened to read similar issues arising with Intel FSP. > Uncertainity with matching header files with the blobs, lack of > distribution rights, vendor support channel providing somewhat > different FSP blob versions from what existing coreboot board ports > (Chromebooks, mostly) have been tested with. Furthermore, commits to > coreboot proper nowadays often refer to tickets in bugtracker that > require some corporate account. Even for those who do approve using > closed-sources blobs in their products, appears the entire x86 > coreboot ecosystem is becoming unproductive for everyone else expect > those who do have access to FSP or AGESA sources. > > > As for the request on keeping conversations civil; What to do when the > vendor/contractor *just does not get it* when review comes from the > community side? Sure, they have all the pressure of shipping their > product, but phrase "We'll fix it later" is something I really learned > to hate on these corporate reviews. For open-source parts this was > often accompanied with my offer to fix it there-and-now, but I > discovered it would just mess up their workflow and cause further > rebase havoc. > > > *1 I am using the term nobody in the meaning of "Not anybody you know > who answers your mails, an individual or company, who could and would > act upon an urgent need to patch said blob within a reasonable > timeframe and under a contract". > > Regards, > Kyösti Mälkki

1 0

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

04 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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? On 04/30/2018 09:32 PM, Zoran Stojsavljevic wrote: > 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 > <mailto:dhendricks@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 > <mailto:coreboot-bounces@coreboot.org>> on behalf of Zoran > Stojsavljevic <zoran.stojsavljevic(a)gmail.com > <mailto:zoran.stojsavljevic@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 <mailto:coreboot@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 > <mailto:nico.h@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 > <mailto:nico.h@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 <http://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_-2… > <https://urldefense.proofpoint.com/v2/url?u=https-3A__review.coreboot.org_-2…> > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mail… <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mail…> > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mail… > <https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.coreboot.org_mail…> > > - -- 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 iQEcBAEBCAAGBQJa59fuAAoJEK+E3vEXDOFbL/YIALNXqSTUR+i4JJQ4r7jtXHfQ VzYH3ejpYpT00uGfud26K73TwSR1NoJkSkHLfi834rORKeMJNrw3cauHBj4bVZF0 2Wak4hhiJPHM3/3UFTOr1DHSLzIEjHYbXmU2xclgBLlARPb+nEfVIN3PnEVD9i53 lvOiqPELfT1Enl5xmtbS67tjHQp72hqBcqsU3ubG9/ZSrxgys3MMR7tYXssKSvVd MX426x4a7Jfy/6qNX5PoNa9A0NEKtPEa5wFn7DjxJROpaMijNKOjLyiGhc+dLc5Y 96CBBxJySSOa7eZOSe943XgyVJMYzVh92sGTd3xX3ASC3aIbLUIbEKth/27kzyU= =nrZZ -----END PGP SIGNATURE-----

4 3

Re: [coreboot] PC Engines apu2 boot regression
by Aaron Durbin 04 May '18

04 May '18

On Fri, May 4, 2018 at 11:16 AM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: >> On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adurbin(a)google.com> wrote: >>>> >>>> Any idea what can be result of such weird behavior? >>> > > My current guess is AP CPUs do not see initialised memory for > _car_region_start .. _end. That region is set up using fixed MTRRs in > low memory and probably not synced between cores so early in romstage. > Ugh. Why do we allow the APs to run through all these stages? Is this for parallel node memory training? Can we ring fence where the APs actually run better? > > diff --git a/src/console/init.c b/src/console/init.c > index 8f71b09..4731e7e 100644 > --- a/src/console/init.c > +++ b/src/console/init.c > @@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL; > > static inline int get_log_level(void) > { > - if (car_get_var(console_inited) == 0) > + if (boot_cpu() && car_get_var(console_inited) == 0) > return -1; > if (CONSOLE_LEVEL_CONST) > return get_console_loglevel(); > > Kyösti

1 0

Re: [coreboot] PC Engines apu2 boot regression
by Kyösti Mälkki 04 May '18

04 May '18

On Fri, May 4, 2018 at 7:19 PM, Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adurbin(a)google.com> wrote: >>> >>> Any idea what can be result of such weird behavior? >> My current guess is AP CPUs do not see initialised memory for _car_region_start .. _end. That region is set up using fixed MTRRs in low memory and probably not synced between cores so early in romstage. diff --git a/src/console/init.c b/src/console/init.c index 8f71b09..4731e7e 100644 --- a/src/console/init.c +++ b/src/console/init.c @@ -35,7 +35,7 @@ static int console_loglevel = CONFIG_DEFAULT_CONSOLE_LOGLEVEL; static inline int get_log_level(void) { - if (car_get_var(console_inited) == 0) + if (boot_cpu() && car_get_var(console_inited) == 0) return -1; if (CONSOLE_LEVEL_CONST) return get_console_loglevel(); Kyösti

1 0

PC Engines apu2 boot regression
by Piotr Król 04 May '18

04 May '18

Hi Aaron, I tried to boot PC Engines apu2 on recent master branch and discovered that it not boot. Bisection points to: 60320182d011 console: only allow console messages after initialization It is hard to believe that this change cause AGESA reset loop, but I checked 3 times. After applying above commit I end up with loop: coreboot-4.7-441-g60320182d0 Fri Mar 2 15:22:24 UTC 2018 romstage starting... BSP Family_Model: 00730f01 cpu_init_detectedx = 00000000 agesawrapper_amdinitreset() entry CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) CBFS: Locating 'AGESA' CBFS: Found @ offset 5ffdc0 size 7b0e0 CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) CBFS: Locating 'AGESA' CBFS: Found @ offset 5ffdc0 size 7b0e0 Fch OEM config in INIT RESET Done Any idea what can be result of such weird behavior? Best Regards, -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com

3 3

Re: [coreboot] PC Engines apu2 boot regression
by Kyösti Mälkki 04 May '18

04 May '18

On Fri, May 4, 2018 at 6:37 PM, Aaron Durbin <adurbin(a)google.com> wrote: > On Fri, May 4, 2018 at 9:23 AM, Piotr Król <piotr.krol(a)3mdeb.com> wrote: >> Hi Aaron, >> I tried to boot PC Engines apu2 on recent master branch and discovered >> that it not boot. Bisection points to: >> >> 60320182d011 console: only allow console messages after initialization >> >> It is hard to believe that this change cause AGESA reset loop, but I >> checked 3 times. After applying above commit I end up with loop: >> >> coreboot-4.7-441-g60320182d0 Fri Mar 2 15:22:24 UTC 2018 romstage >> starting... >> BSP Family_Model: 00730f01 >> cpu_init_detectedx = 00000000 >> agesawrapper_amdinitreset() entry >> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) >> CBFS: Locating 'AGESA' >> CBFS: Found @ offset 5ffdc0 size 7b0e0 >> CBFS: 'Master Header Locator' located CBFS at [200:7fffc0) >> CBFS: Locating 'AGESA' >> CBFS: Found @ offset 5ffdc0 size 7b0e0 >> Fch OEM config in INIT RESET Done >> >> Any idea what can be result of such weird behavior? > > I think it's because we still have boards that utilize CAR_GLOBAL, but > don't handle migration of CAR globals. Those two things combined > really makes for situations that just don't work and ramstage loading > is just lucky to work on those platforms. I was originally thinking > this patch would work, but I don't think that's the case because when > I build apu2 CONFIG_EARLY_CBMEM_INIT is already set. If you revert > that patch what does your log look like? We could be recursively > entering into car_get_var_ptr() through the printk() path, but that > would require things not marked as CAR_GLOBAL being passed to that > function. There is one way to fix all of these scenarios: remove CAR > migration by transitioning everyone to postcar stub between romstage > and ramstage. That's a lot of work, though. We can try and debug > further because I'm not clear why things aren't working. > Well I am looking at this as well now. I have not booted vanilla master on apu2 for sometime, being preparing POSTCAR_STAGE for these binaryPI boards instead.. Kyösti

1 0

coreboot release 4.8 - Targeting May 15.
by Martin Roth 04 May '18

04 May '18

The coreboot 4.8 release is planned for May 15. That's the day that we'll choose the commit to base the release on and create the release tag in git. The tarballs will be available on the website shortly afterwards. For anyone who feels like contributing to the release notes, you can work on them here: https://pads.ccc.de/yGXyCFe7g7 I've added the list of commits up to today in the document, below the release notes section. It would be helpful if people could test their boards and upload the results board-status repository. This lets everyone know that the code for that board, processor, and chipset is still working in the current coreboot tree. As always, thanks to everyone involved in coreboot. Your work is greatly appreciated. Martin

1 0

Re: [coreboot] POWER9 / Talos II coreboot support?
by Timothy Pearson 04 May '18

04 May '18

On 05/03/2018 06:02 PM, ron minnich wrote: > > > On Thu, May 3, 2018 at 1:20 PM Timothy Pearson > <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > I think I was being a bit pessimistic / too careful here. We're close > to getting the docs publicly released, but that doesn't help anyone > wanting access right now, which is why I mentioned the other route. > IBM's committed to getting the documentation released, they're just > making sure that what they release is actually correct for the products > it covers. > > It might make sense to get our "working group" together over the next > few weeks, by which time the documentation should be available in public > form. > > Are you interested in joining? :-) > > > of course, but not until those docs are freed up. > > Context: I've been trying for 2 years now to get OPAL released under > dual gpl2 licensing with the current apache2 license, apache2 and gpl2 > are not compatible, so we'd be in a bit of a mess should we use OPAL > code in coreboot, and it would be easiest if we were able to use some of > that code. > > The first response from IBM was "why do you think you need coreboot?" I > worked through that, and there was agreement in the end it ought to > happen, said agreement reached about 2 years ago. Stuff Would Happen, I > was told. After that, silence. > > This is pretty much par for the course with Power. In 1990 I spent two > years getting an agreement that would allow me to .... get more agreements. > > So close doesn't count. Once I see the kind of docs I need to see, not > requiring a clickwrap, and covering all aspects of every chip on your > board, I'm in: I'll order a board. Until then, I can't really do much. > > Thanks for your efforts on Power! > > ron > > Fully understood. I have a fairly detailed view into what happened after the events you mention, but less so before. Sometime we should meet up and figure out the entire timeline of just what went wrong and how it's being fixed (slowly). FWIW the docs are going to happen; when they are up I'll send another Email here. :-) -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com

1 0

← Newer
1
...
8
9
10
11
12
13
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 May 2018