coreboot May 2018

coreboot@coreboot.org

51 participants
137 discussions

Re: [coreboot] Thread derailment
by Nico Huber 02 May '18

02 May '18

On 02.05.2018 19:21, Zoran Stojsavljevic wrote: > Hello David, > >> We need open dialogue with vendors more than we need obnoxious >> commentary from certain individuals. > > I see... I hit hard INTEL... Again! And INTEL is NOT (at all) happy about > that, I can read between the lines. :-) No. You hit the coreboot community and the project as a whole. There is no Intel between the lines. Many not vendor affiliated people are quite angry at you at the moment. You make decent discussions futile. IIRC, I warned you about your all caps bullshit before. Please keep it civilized, or just mute yourself. Nico

2 1

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

02 May '18

Beware that patch is incomplete! Coreboot dies at src/southbridge/intel/common/acpi_pirq_gen.c line 97: if (!lpcb_path) die("ACPI_PIRQ_GEN: Missing LPCB ACPI path\n"); You have to add the lpc_acpi_name function to src/southbridge/intel/ibexpeak/lpc.c as in src/southbridge/intel/bd82x6x/lpc.c to circumvent this issue. I was preparing to upload my patch when I saw yours (which is almost identical). Additionally, I already tested my patch on a Lenovo X201i. Shall I edit your patch on gerrit or upload mine in a separate merge request, or do something else? Cheers, Matthias On 01/05/18 18:45, Kyösti Mälkki wrote: > On Mon, Apr 30, 2018 at 6:46 AM, qtux <mail(a)qtux.eu> wrote: >> 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: > > Thanks for patching _and_ testing, your patch for finalize was just merged. > >> can't derive routing for PCI INT A >> PCI INT A: no GSI > > As for IRQ regressions, I think I can see where it went wrong, find my > attempt to fix it blind-folded [1]. > > [1] https://review.coreboot.org/#/c/coreboot/+/25965 > > Kyösti >

4 6

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

02 May '18

On Wed, May 2, 2018 at 1:00 AM, Ivan Ivanov <qmastery16(a)gmail.com> wrote: > I think, by "The Right Direction" he meant having the open source code > instead of FSP-S blobs. > 'Why do we have FSP-S' - I have the same question. Why this code must > be kept closed, Intel? > Open source is always better than closed, and your major competitor - > AMD - would not be able > to use your source code - not just because of the licenses, but > because your CPUs are so different 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 IMO the lesson is that processes for open sourcing firmware are very costly and time-consuming. If we want open source firmware to be considered from the start of a product development cycle, we need to demonstrate that coreboot will add value and that the development processes will not be too costly or burdensome. It took Linux many years to become such a valuable part of the ecosystem that vendors hire kernel developers to write open source drivers. Coreboot is slowly getting to that point, and Chromebooks are setting a good example for how to do it. Ranting and making unfeasible demands does not help. Working with vendors to toward a more open future and proving our worth by shipping real products does.

1 0

POWER9 / Talos II coreboot support?
by Timothy Pearson 02 May '18

02 May '18

-----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. In a nutshell, Talos II is a completely owner controllable machine that is in the same general performance class as AMD and Intel [1]. We provide all of the data needed to create a port, including the schematics, with each system sold. We can also offer direct assistance and access to hardware for contributors to this project at no charge. The motivation for this port is to clean up the "IPL" (Initial Program Load) process. Right now a chunk of open software called hostboot runs FSP routines on the main processor. This is slow and very bloated compared to how coreboot does things. We'd like to replace hostboot with coreboot, keeping for now the initial SBE and later skiboot software intact. There are several challenges with a project of this magnitude. While the SBE brings up the basic CAR and loads hostboot into the CAR space, the processors are completely uninitialized beyond that point. Documentation is scarce, not because it is restricted per se, but mostly because the FSP routines are the main documentation. There is no simulator available for working on hostboot, either, and the initial POWER8 toolchain work still needs to be updated for POWER9 as well. Advantages to the project include showing that coreboot, or more specifically a completely open, blob-free coreboot, can actually start a modern platform, essentially proving that the concept of an open coreboot remains viable given vendor cooperation. Being able to shave a significant amount of time out of the IPL would also show that coreboot's model provides advantages over a more standard vendor flow. Is anyone interested in signing on for a long term project of this size? [1] https://raptorcs.com/TALOSII/ - -- 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 iQEcBAEBCAAGBQJa6gH9AAoJEK+E3vEXDOFbEHkIALb6cwVbBUmmxOxZMoE0cAn9 BDb0RY/g+yTATQLzWfZCxp2CkI3pEdeQ0CZA2PycTqVfCzN9qQ5AxdQrh4LfUh59 AJYxH8Q3dPkCUft5FlYEmBZWE8b8VUSE2XCj81CbBjLyi5KZli075migXXC0BX/v w5uiM+7cwYXjDqJOaVcs3qpoA7hKWvwbET8MLn/PGGy9DtuuWW+/3/HrNFS/Uv5r skvQOtv3tIlyB65BhOYLaxY+7DFAdxx4ljaeKF7zjynK+Awp0A+UrFHdZiFjf84p oLaWkomibO3a+zoVLbb6/+ETRdWpkiKRYCiZ6MfNRsDpmrK5r932MXTW/fGp7f0= =mKdF -----END PGP SIGNATURE-----

1 0

Re: [coreboot] [RFH] Status of the Lenovo X201
by ron minnich 02 May '18

02 May '18

Yeah I think you want to hunt this stack smash error down, it's not something you want to ignore. On Wed, May 2, 2018 at 11:09 AM Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Wed, May 2, 2018 at 8:53 PM, Nico Huber <nico.h(a)gmx.de> wrote: > > On 02.05.2018 18:37, qtux wrote: > >> Thanks for your detailed explanation. So in essence shall I ignore the > >> messages or blacklist lpc_ich? > > > > Yes, either ;) > > > >> > >> Besides, while preparing the status report, I sometimes find a "Smashed > >> stack detected in romstage!" message in the console log, just before > >> ramstage is starting. Is there something to worry about there? > > > > Um, yes. I think that's not good. But I wonder why it's not happening > > consistently. > > I commented about that earlier in this thread. Seemed like actual > raminit eats a lot of stack, but loading from MRC cache or equivalent > does not. One could find that struct and move it to BSS, declared with > CAR_GLOBAL. I would rather not extend the boundary for stack-smashing > detection. > > Kyösti > > -- > 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 02 May '18

02 May '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/28/2018 02:37 PM, Mike Banon wrote: Hi Mike, > > PC Engines alix1c - AMD LX - 2017-09-17 PC Engines alix2d - AMD LX > - 2017-09-17 PC Engines apu1 - AMD Family 14h (AGESA) - 2017-09-05 > PC Engines apu2 // apu3 // apu4 // apu5 - AMD 00730F01 (PI) - > 2017-10-26 What is expected frequency of sending board status updates? We have all those board and even some awaiting port to coreboot. We are committed to keep those platforms on the master but I'm not sure if I understand rules based on which platforms are planned for removal. We maintain coreboot tree with customer specific customizations that will probably never lend in mainline, because of that we are rather interested to make coreboot work with PC Engines platforms on tagged releases and not exactly on any random commit in between. Any commit approach would require firmware validation automation which we will eventually have. So if release cycles take a lot of time then IMO delayed board status update should be allowed. Second thing that IMO is problematic in board status is assumption that system have to boot with vanilla coreboot. This is problematic when you have to use customized version of SeaBIOS or any other payload used for booting system. Because of long weekend we will send board status updates for boards under 3mdeb maintainership before 11 May. Please let me know if feel this is too late. Best Regards, - -- Piotr Król Embedded Systems Consultant https://3mdeb.com | @3mdeb_com -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE4DCbLYWmfoRjKeNLsu5x6WeqnkwFAlrkdC8ACgkQsu5x6Weq nkyuUQ/+M8tDEEw0Qfz91ceVlkmp82B7+0j1Ur0EEgalNTe8rGK0iULKyEUsNT/d 41pyblnUNzP/DVaogekJFsAi3/v9plblfUVsAhIpvaW2jS90vTxg/PQ/PXqubzZW TES2JyQKc3lCvlDACERGY+gnS/hPMYab05gKdV/wdoQtlxucJbaMLFQGisRbUVFE Wz6ormhxaz9D4M/UPQILg8Zdy669f7tBJ4FVF2ZdRvbJuia4c0H/i3tWRZ3+w5AB Dexe/OTAFHVPPtDTn+PU+BplGqRKlNFNmZhDctubRzYCFMZn8qPyV1dxD34G5N31 b+IpyanonL4aie7XbAa3f3AImOuP+ECCx/jdU8eCFFwhvn8MxmxA1syW6cFoNvst gAiedOvYjhZ7+pE6xWwVVmeFBb2tiO6oEeCQ6N3h9gj1dtMxmzjS++5bE/msNIT0 EWURF6S86DYL6SZLKNeEKYl/5aa+5JoifalpnuNe/+7QQcN2IEIPHS/2xgMBehGk 3lzGTueQS7N7y9OaMMTn+MUjzTB5L54rEji2MmHnbToaGEivqHquyAvmTYaSj5E2 tTD5L0AM6UN6ifEGlk7kyx5lnFhzqsrs5+pSBFmoMYVHym1NidJzZPNng114y086 YsgdrKhrer2oXHcF60uyTasq4eCVUKksXNh27ikIX7Sw5D5n4tk= =dj/x -----END PGP SIGNATURE-----

3 4

Re: [coreboot] Thread derailment
by Zoran Stojsavljevic 02 May '18

02 May '18

Hello David, > We need open dialogue with vendors more than we need obnoxious > commentary from certain individuals. I see... I hit hard INTEL... Again! And INTEL is NOT (at all) happy about that, I can read between the lines. :-) It is NOT matter of open dialogue with vendors. It is matter of direct INTERESTS between GOOGLE and INTEL, *where The TRUTH is completely sacrificed*. Sorry to be straight honest with you. The Truth here is the biggest victim. But... It depends what your interests are, and how these interests convert, convert into what?! ;-) Anyway, all said IMHO! Zoran _______ On Wed, May 2, 2018 at 5:29 PM, David Hendricks <david.hendricks(a)gmail.com> wrote: > On Wed, May 2, 2018 at 1:07 AM, Ivan Ivanov <qmastery16(a)gmail.com> wrote: > > > > Regarding the FSP-S thread - sorry, but I did not see any derailment. > > The whole thread - 'Why do we have FSP-S' - is about "why we should > > have more blobs when we already have enough?" And its understandable > > that some people got upset while seeing how coreboot is slowly turning > > from being almost completely open source to the big collection of blobs > > launching each other. Hopefully this reply would not get me removed... > > The problem is the animosity some members brought to the other thread, > complete with conspiracy theories about "corporate control", insults > directed Intel, and negative comments about coreboot. > > Just because someone doesn't like a particular vendor or blobs doesn't > mean they should interject with rude comments and prevent others from > having a civil discussion. The FSP-S thread illustrates exactly why > companies don't "consult the community" before doing things. If the > mailing list can't be used to discuss things with major hardware > vendors then these discussions will simply happen elsewhere without > any community input. > > We need open dialogue with vendors more than we need obnoxious > commentary from certain individuals. > > > > > Best regards, > > Ivan Ivanov > > > > 2018-05-01 19:07 GMT+03:00 ron minnich <rminnich(a)gmail.com>: > > > 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 > > > > > > > > > -- > > > coreboot mailing list: coreboot(a)coreboot.org > > > https://mail.coreboot.org/mailman/listinfo/coreboot > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Thread derailment
by David Hendricks 02 May '18

02 May '18

On Wed, May 2, 2018 at 1:07 AM, Ivan Ivanov <qmastery16(a)gmail.com> wrote: > > Regarding the FSP-S thread - sorry, but I did not see any derailment. > The whole thread - 'Why do we have FSP-S' - is about "why we should > have more blobs when we already have enough?" And its understandable > that some people got upset while seeing how coreboot is slowly turning > from being almost completely open source to the big collection of blobs > launching each other. Hopefully this reply would not get me removed... The problem is the animosity some members brought to the other thread, complete with conspiracy theories about "corporate control", insults directed Intel, and negative comments about coreboot. Just because someone doesn't like a particular vendor or blobs doesn't mean they should interject with rude comments and prevent others from having a civil discussion. The FSP-S thread illustrates exactly why companies don't "consult the community" before doing things. If the mailing list can't be used to discuss things with major hardware vendors then these discussions will simply happen elsewhere without any community input. We need open dialogue with vendors more than we need obnoxious commentary from certain individuals. > > Best regards, > Ivan Ivanov > > 2018-05-01 19:07 GMT+03:00 ron minnich <rminnich(a)gmail.com>: > > 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 > > > > > > -- > > coreboot mailing list: coreboot(a)coreboot.org > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] Thread derailment
by Ivan Ivanov 02 May '18

02 May '18

Regarding the FSP-S thread - sorry, but I did not see any derailment. The whole thread - 'Why do we have FSP-S' - is about "why we should have more blobs when we already have enough?" And its understandable that some people got upset while seeing how coreboot is slowly turning from being almost completely open source to the big collection of blobs launching each other. Hopefully this reply would not get me removed... Best regards, Ivan Ivanov 2018-05-01 19:07 GMT+03:00 ron minnich <rminnich(a)gmail.com>: > 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 > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

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

02 May '18

Hello Zoran, Zoran Stojsavljevic: >> 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. :-) > Please clarify what "The Right Direction" is. You have confused me, as I thought the thread was about 'Why do we have FSP-S'.

2 1

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