Re: [coreboot] Thread derailment

> IIRC, I warned you about your all caps bullshit before. Please keep it > civilized, or just mute yourself. Hello Hico, Here is example of your "work". Wanted to say, your talks, lot of talks. [coreboot] How to handle vbt.bin https://www.mail-archive.com/coreboot@coreboot.org/msg51401.html

Re: [coreboot] [RFH] Status of the Lenovo X201

Hi Nico, On 02.05.2018 00:42, Nico Huber wrote: > Well, you better know what you are doing ;) that's indeed really true. :-) Regards, Reiner -- -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] Why do we have FSP-S

On Wed, May 2, 2018 at 1:00 AM, Ivan Ivanov 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

[coreboot] POWER9 / Talos II coreboot support?

-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

Re: [coreboot] [RFH] Status of the Lenovo X201

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 wrote: > On Wed, May 2, 2018 at 8:53 PM, Nico Huber wrote: > > On 02.05.2018 18:37, qtux wrote: > >> Thanks

Re: [coreboot] [RFH] Status of the Lenovo X201

On Wed, May 2, 2018 at 8:53 PM, Nico Huber 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

Re: [coreboot] [RFH] Status of the Lenovo X201

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

Re: [coreboot] Thread derailment

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.

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

On 02.05.2018 17:53, Piotr Król wrote: > On 04/28/2018 03:46 PM, ron minnich wrote: >> 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

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

On 02.05.2018 18:06, Piotr Król wrote: > On 04/28/2018 03:48 PM, Nico Huber wrote: >> On 28.04.2018 15:16, Piotr Król wrote: >>> 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

Re: [coreboot] Thread derailment

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

Re: [coreboot] [RFH] Status of the Lenovo X201

Thanks for your detailed explanation. So in essence shall I ignore the messages or blacklist lpc_ich? 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

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/28/2018 03:48 PM, Nico Huber wrote: > Hi Piotr, Hi Nico, > > On 28.04.2018 15:16, Piotr Król wrote: >> Second thing that IMO is problematic in board status is >> assumption that system have to boot with vanilla coreboot. This >> is

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

-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

Re: [coreboot] Thread derailment

On Wed, May 2, 2018 at 1:07 AM, Ivan Ivanov 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

Re: [coreboot] Thread derailment

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

Re: [coreboot] Why do we have FSP-S

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

Re: [coreboot] Why do we have FSP-S

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,