coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

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

03 May '18

-----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? :-) On 05/03/2018 11:40 AM, ron minnich wrote: > "There is no legal issue that we are aware of with using them to develop > a libre firmware solution like coreboot; IBM just doesn't want the > detailed register manuals distributed verbatim online at this time." > > > This is worrisome. Intel docs used to be the same way in 1999, otherwise > LinuxBIOS might never have happened. Then the walls were built. I've > worked with IBM Power off and on for 30+ years. IBM can give, and IBM > has in the past taken away, and it's caused real trouble for projects > I've worked on. > > I think we need a clear statement on distribution policies for Power > docs. "There is no legal issue that we are aware of" is not enough. I > don't want to find out in two years that this information is now locked > down. > > This has been my continuing problem with Power, and it's why I've > focused more on RISC-V. There's just too much uncertainty from the Open > Power organization. With luck you can fix it, but it needs to be fixed. > > ron > > On Thu, May 3, 2018 at 5:48 AM <echelon(a)free.fr > <mailto:echelon@free.fr>> wrote: > > +1 > Same for me, I would gladly help with the port of coreboot to Talos > II (even if I am not a coreboot expert, I do have some background in > firmware development..), but there are 2 problems : > - the time : I will be able to spend my free time on coreboot > development again only after june 2018; > - the monies : I have no financial resources right now to pay > myself a Talos development platform (4000$ is expensive.. and also I > live in Europe and I'm concerned with the shipment of a so large and > fragile item from US to Europe) > I will attend the coreboot conference in september and like Jonathan > said, I'm really interested by a POWER9 session at this conference. > Best regards, > Florentin Demetrescu > > > ----- Mail d'origine ----- > De: Jonathan Neuschäfer <j.neuschaefer(a)gmx.net > <mailto:j.neuschaefer@gmx.net>> > À: Timothy Pearson <tpearson(a)raptorengineering.com > <mailto:tpearson@raptorengineering.com>> > Cc: Kyösti Mälkki <kyosti.malkki(a)gmail.com > <mailto:kyosti.malkki@gmail.com>>, Coreboot <coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org>> > Envoyé: Thu, 03 May 2018 14:06:22 +0200 (CEST) > Objet: Re: [coreboot] POWER9 / Talos II coreboot support? > > On Thu, May 03, 2018 at 06:32:29AM -0500, Timothy Pearson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On 05/03/2018 03:44 AM, Kyösti Mälkki wrote: > > > On Wed, May 2, 2018 at 9:22 PM, Timothy Pearson > > > <tpearson(a)raptorengineering.com > <mailto:tpearson@raptorengineering.com>> wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA256 > > >> > > >> We've been kicking around the idea for some time of getting a > coreboot > > >> port to the POWER9 Talos II systems going. We don't have the > resources > > >> available / free at the moment to work on this independently, > but it > > >> might be possible to get something going if there are other > community > > >> members interested in helping out. > > > > > > Count me in, I am getting sick and tired of x86 vendors ;) > > > > > > Kyösti > > > > Sounds great, glad to have you on board! Any other volunteers? > > I am interested, but I can't commit time to this at the moment. > > Is there going to be a POWER9 session at the Open Source Firmware > Conference[1] in September? I'd be happy to attend. > > > Jonathan Neuschäfer > > [1]: https://osfc.io/ > > > -- > coreboot mailing list: coreboot(a)coreboot.org > <mailto:coreboot@coreboot.org> > https://mail.coreboot.org/mailman/listinfo/coreboot > - -- 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 iQEcBAEBCAAGBQJa628YAAoJEK+E3vEXDOFbzb0H/jmz8DKuEFANe3G59QcQmqwh bPdAFD5mtiO3Na/uJOlOyvgPKOzabZR4qUJlCRoMFIgkGlyyfAaRCljVhXLQFTDx C0Rj71E2c+bdih6xSon/L6HJNBkBhYVMTlMba2yIUgqPy9M+xncYUQwcWhc4U9q9 RZFKm/NCeD6botsBeKAio2aItTwSQJe3JkZHYvgQRehCV7DRq8OgwparifVwDT4V gWt7fOYFFIfYnsyoOJ5NYQJFsxEIZJp9rA2mBYmLAVincvlsJ1NN8qApE8lUfpgu 9pbXAWNjJ7LDoJDWukJToA7hBiYdZlSTysFvOhffBYar+TkXBN0YKrcuckzcT5E= =u4Ge -----END PGP SIGNATURE-----

2 1

Re: [coreboot] Please upload board status Asus AM1I-A
by Elisenda Cuadros 03 May '18

03 May '18

Thumbs up for you! After enabling MRC_CACHE ram initialization is 1.1 seconds less. Regards, - Eli On 03/05/18 19:18, Kyösti Mälkki wrote: > On Thu, May 3, 2018 at 6:56 PM, Elisenda Cuadros <lists(a)e4l.es> wrote: >> Dear Paul, >> >> Sorry for the delay. >> >> I uploaded another build from current master to the board_status repository. >> >> I disabled the serial console and rebooted twice before uploading the data. >> >> I think RAM initialization time is more or less the same. >> > Set ENABLE_MRC_CACHE in menuconfig, You are correct RAM init time > improvement would only appear after 2nd boot. > >> Is there anything else I can do to debug this? > Not really, expect also pull fresh master as I think we recently broke > f16kb, see: > > https://review.coreboot.org/c/coreboot/+/26036 > > Kyösti >

1 0

Re: [coreboot] KGPE-D16 / Problem booting with two CPUs
by Elisenda Cuadros 03 May '18

03 May '18

Hi Kyösti, I will try to boot again with 6276+6238 with the current build and I will inform the result. Regards, - Eli On 03/05/18 20:07, Kyösti Mälkki wrote: > On Thu, May 3, 2018 at 8:57 PM, Elisenda Cuadros <lists(a)e4l.es> wrote: >> Finally I acquired another 6276 CPU (it was the fastest and cheapest >> option). >> >> It works perfect. >> > Maybe not related, but KGPE-D16 was affected by a regression [1] on > SMP init. That was present on master from Aug 2017 to Apr 2018. > > [1] https://review.coreboot.org/c/coreboot/+/25874 >

1 0

KGPE-D16 / Problem booting with two CPUs
by Elisenda Cuadros 03 May '18

03 May '18

Hello, After testing the board for some weeks I bought another CPU (6276). I installed this into CPU1 slot and a 6238 in CPU2. I checked that both CPUs are shining and also the memory (Micron MT18JSF25672PDZ-1G4F1DD, populated in A2/C2/E2/G2 slots). The problem is that Coreboot seems to hang at the beginning. I attach console.log. I reinstalled all the devices twice, checked the vendor manual, docs in coreboot.org, messages in mailing list, but I don't know what is causing the problem. Last test I've done is booting with vendor bios, and it boots without problem. Any ideas? Thank you for your help. Regards, - Eli

4 7

Re: [coreboot] Please upload board status Asus AM1I-A
by Elisenda Cuadros 03 May '18

03 May '18

Dear Paul, Sorry for the delay. I uploaded another build from current master to the board_status repository. I disabled the serial console and rebooted twice before uploading the data. I think RAM initialization time is more or less the same. Is there anything else I can do to debug this? Best Regards, - Eli On 16/04/18 09:07, Paul Menzel wrote: > Dear Eli, > > > Am Montag, den 12.02.2018, 11:55 +0100 schrieb Elisenda Cuadros: > >> Sure, I will be happy to do it :-) > Thank you very much for uploading the data to the board status > repository [1]. > > I noticed, that the serial console is enabled in your run, which causes > the boot time to be quite slow as all messages have to be sent over the > serial cable. > > Could you please do another upload with the serial console disabled? > You can just use latest commit from the master branch. That data would > be nice to have to keep track of possible boot time regressions. > > Also, RAM initialization took 1.7 seconds according to the time stamps. > > ``` > 2:before ram initialization 178,042 (174,580) > 3:after ram initialization 1,878,897 (1,700,855) > ``` > > If it is really that long – I didn’t see any log messages, so it’s > shouldn’t be the serial console –, could you do at least two reboots to > see if it’s due to an empty cache of the RAM data? > > > Kind regards, > > Paul > > > [1] asus/am1i-a/4.7-294-gac05cbdea4/2018-02-12T15_31_32Z > >

2 1

Re: [coreboot] POWER9 / Talos II coreboot support?
by ron minnich 03 May '18

03 May '18

"There is no legal issue that we are aware of with using them to develop a libre firmware solution like coreboot; IBM just doesn't want the detailed register manuals distributed verbatim online at this time." This is worrisome. Intel docs used to be the same way in 1999, otherwise LinuxBIOS might never have happened. Then the walls were built. I've worked with IBM Power off and on for 30+ years. IBM can give, and IBM has in the past taken away, and it's caused real trouble for projects I've worked on. I think we need a clear statement on distribution policies for Power docs. "There is no legal issue that we are aware of" is not enough. I don't want to find out in two years that this information is now locked down. This has been my continuing problem with Power, and it's why I've focused more on RISC-V. There's just too much uncertainty from the Open Power organization. With luck you can fix it, but it needs to be fixed. ron On Thu, May 3, 2018 at 5:48 AM <echelon(a)free.fr> wrote: > +1 > Same for me, I would gladly help with the port of coreboot to Talos II > (even if I am not a coreboot expert, I do have some background in firmware > development..), but there are 2 problems : > - the time : I will be able to spend my free time on coreboot development > again only after june 2018; > - the monies : I have no financial resources right now to pay myself a > Talos development platform (4000$ is expensive.. and also I live in Europe > and I'm concerned with the shipment of a so large and fragile item from US > to Europe) > I will attend the coreboot conference in september and like Jonathan said, > I'm really interested by a POWER9 session at this conference. > Best regards, > Florentin Demetrescu > > > ----- Mail d'origine ----- > De: Jonathan Neuschäfer <j.neuschaefer(a)gmx.net> > À: Timothy Pearson <tpearson(a)raptorengineering.com> > Cc: Kyösti Mälkki <kyosti.malkki(a)gmail.com>, Coreboot < > coreboot(a)coreboot.org> > Envoyé: Thu, 03 May 2018 14:06:22 +0200 (CEST) > Objet: Re: [coreboot] POWER9 / Talos II coreboot support? > > On Thu, May 03, 2018 at 06:32:29AM -0500, Timothy Pearson wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > On 05/03/2018 03:44 AM, Kyösti Mälkki wrote: > > > On Wed, May 2, 2018 at 9:22 PM, Timothy Pearson > > > <tpearson(a)raptorengineering.com> wrote: > > >> -----BEGIN PGP SIGNED MESSAGE----- > > >> Hash: SHA256 > > >> > > >> We've been kicking around the idea for some time of getting a coreboot > > >> port to the POWER9 Talos II systems going. We don't have the > resources > > >> available / free at the moment to work on this independently, but it > > >> might be possible to get something going if there are other community > > >> members interested in helping out. > > > > > > Count me in, I am getting sick and tired of x86 vendors ;) > > > > > > Kyösti > > > > Sounds great, glad to have you on board! Any other volunteers? > > I am interested, but I can't commit time to this at the moment. > > Is there going to be a POWER9 session at the Open Source Firmware > Conference[1] in September? I'd be happy to attend. > > > Jonathan Neuschäfer > > [1]: https://osfc.io/ > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] [URGENT] Full List of AMD-based boards that are going to be removed from coreboot unless people cough up a board status update
by Piotr Król 03 May '18

03 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04/28/2018 03:46 PM, ron minnich wrote: Hi Ron, > This is a *personal* opinion, not supported by anyone else I > suppose, but: > > I don't think it's unreasonable to ask that people send in board > status 2 times a year. > > That's it. It makes it easier for potential users, and for people > maintaining the tree. > > Sound ok? Twice a year sounds ok. I still think this should be tied to release cycle, which IMO is not clear at this point. If release cycle would be similar to Linux then I would imagine status update should be sent at - -rcX stage and then after stable release. We will see how status board update will evolve. Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlrp3ugACgkQsu5x6Weq nkx91g//VLm56h+3QoZS7uF8UPXTWbCH5EO7iFOZynQQoyAYzkm7uTNdLxNYfYmR O21EJ5YcW/V3EdT/QrbgnSdlXX3MSHO+ZlwJsQWHBKTHF6+oprSQmaG4WcQ2y4GI yFg0wAj+5avz18HXE9rC6M+Hq6SYgcxBqCMsNi8p0DZxutpnb9uwyRIT6wPRDo6u Ik2tMeG7qKU0e6sXHEp920Tk7rtcWXCwQvrJRYj4td7LbI26a09VvT6MZjqjw21J MNiiKo1kgjlba2xMQtg/FUYSVNMkEfWvNcnDWiHF5cuubmOV/Xb5ePvNS5S6dcaT vvp7OYQqdVc3wXB/c1PUKP+X6jcM0ymqT3n484bX4Kk6aJy+t7IL/BBBwV8jtnuz 1mO+jKJ3c8GkpUv7JuvsvTpky9V1bDgScjvMoOhu6/WjAX5ml8urBhc7ceXSvz71 2PgPLwrEx868fV7J6HpRw4nlTYcOt2GB6cQU0aVMFEERqu+kbe7KvTwb3JWTPiBW vuy7IOOPEf0OMKDvL/QGVQ/njp9+JS+GEO1rNvQnvtg0EDYrScQJNB5VaAA7Y7Il 7K+GDM83Lj9dGnDw9/xYWzCzInFBtM3c6mB9rsqJBOKAWz5PkR2Br4wVZj5ptLgI PhPtxM6DJne8okvwQnGAza5RBrzU+F79PupJleiVCYzPxXBMlU8= =5CyK -----END PGP SIGNATURE-----

3 2

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

03 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/03/2018 03:44 AM, Kyösti Mälkki wrote: > On Wed, May 2, 2018 at 9:22 PM, Timothy Pearson > <tpearson(a)raptorengineering.com> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> We've been kicking around the idea for some time of getting a coreboot >> port to the POWER9 Talos II systems going. We don't have the resources >> available / free at the moment to work on this independently, but it >> might be possible to get something going if there are other community >> members interested in helping out. > > Count me in, I am getting sick and tired of x86 vendors ;) > > Kyösti Sounds great, glad to have you on board! Any other volunteers? I've created a Wiki page where we can start tracking at least what needs to be done, and most importantly start documenting the various chunks of hardware that coreboot needs to set up [1]. It's preloaded with what I am sure is a very optimistic list of tasks; contributions are welcome as we iron out exactly what is involved here. I'd like to see what kind of manpower we can attract on-list here, then schedule some meetings around the best approach to the initial bringup. We can also figure out how to handle getting hardware access to the various folks involved. I don't know how much of the initial work is more practical in e.g. qemu versus on bare metal, given the complexity of some of the existing firmware stage handoffs. At minimum we should start documenting the entry and exit interfaces between SBE<-->coreboot<-->skiboot, along with expected processor state at entry/exit, to see what we're getting involved in. On the plus side we have direct access to LPC via the nest, and a BMC that receives LPC accesses including serial and port 80 traffic. This should make debugging fairly easy, once enough of a bootblock has been written to take over from the SBE and initialize enough of the nest to get LPC online. POWER9 doesn't have the concept of I/O space, so the LPC access is all handled via MMIO reads and writes to a specific set of addresses in the nest itself. There's a sizeable chunk of register documentation available on the OpenPOWER portal, although I think the detailed register manuals need an IBM account (freely available) and possibly a (free) OpenPOWER signup. There is no legal issue that we are aware of with using them to develop a libre firmware solution like coreboot; IBM just doesn't want the detailed register manuals distributed verbatim online at this time. Let's make this happen! [1] https://wiki.raptorcs.com/wiki/Coreboot/ToDo - -- 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 iQEcBAEBCAAGBQJa6vNMAAoJEK+E3vEXDOFbSCsH/Rl202jzyeOhoSi5z3N6RXVT Bwdtn6z9QTQhb7m8f4blmhlXNifdiooOrgLuCo9Vw5af+X1W06U+CJkAZlk8QRRh RpFUpZlZHv9s+Er+005XNjiqSFIxbEnlKddrGa3AwxNXBQaKNuJeIUCARyK98n3r JmuyaaMVnLksjc91wExIeeKyQDQo2VyrvnSMPDMIgbRPQrYEWWzs6rQNK2nQXl7n LL5xdVP2NT+pSX/zwtowmZkq26EDg8P9FfEAMHfhtGx3FyWK2R1cQ4cUhNqKKn5Y f33Ud5Kq+ZqzNFCKUz/HupiyaM1q4hoaqDrYjoPYA9XWKu3jamQ4YXi0g0gFabk= =kzda -----END PGP SIGNATURE-----

3 2

Re: [coreboot] Why do we have FSP-S
by Kyösti Mälkki 03 May '18

03 May '18

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

Contribution trolling (was Re: Thread derailment)
by Nico Huber 03 May '18

03 May '18

Hello Zoran, did you just try to derail the thread-derailment thread? Or did you try to make any point at all? > [coreboot] How to handle vbt.bin > https://www.mail-archive.com/coreboot@coreboot.org/msg51401.html > > You, GOOGLE designers, are here talking essays (War and Peace) about > what to do, how to improve vbt.dat area. Is this some sort of conspiracy theory? Because I couldn't find a single mail in that thread from a Google employee. Attacking me on a topic where I did most of the work and you just copied mine and others work to Wikipedia [1] seems pretty weird. If you want to highlight your own contribution to the community why not pick one of the various threads where you actually helped people to get their boards running? Because you did. And that was great. But I'm not sure any more if it outweighs the damage you do. Nico [1] https://en.wikipedia.org/wiki/Coreboot/VBT Now that you reminded me, a final warning about this page: Fix all copyright infringements and out-of-context copy-pasta or I'll look forward to take it down.

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