Re: [coreboot] BayTrail PCIe problems (hangup) in FSP (in U-Boot)

[Wolfgang Denk]

Hallo Zoran,

In message  you wrote:
> Let us involve in this discussion Mr Denk (father of U-Boot, I know Mr Denk
> personally)), and Mr Glass (option [B] here mentioned below)... For the
> (targeted by me) purposes (History involved)!

You drop me here into some thread, and even though you write
"History involved", your quoting style does not really make clear
who i writing what in response to which statements by whom :-(

Read: I don't know what you want.
> > [e-mail] writes:
> > I think you are actively hurting the overall ecosystem by working on a
>
> different
> > project (FSP in U-Boot) which overlaps with Coreboot efforts.
>
> Peter (Stuge),
>
> This is VERY correct statement... You already mentioned: It is NOT INTEL
> FSP, per say?

I don't understand either of this.  Multiple implementations of the
same feature / multiple solutions for the same problem have never
been a bad thing per se.  On contrary, in masy cases they have been
an essential requisite to enable technical progress.  Of course, it
is always possible to step on someone's toes, but I am not sure
above statement is a result of this.

So without deeper understanding I disagree with both statemen't -
with Peter's, as different projects for the same thing are not
necessarily bad, and with your's that this was true.
> It is something I am fighting for years for/in the STRONG interests of
> U-Boot/Open Source: to have consistent strategy with INTEL IOTG management
> which they ignored/have dominant/aggressive strategy to walk over the Open
> Source people, people at all (please, INTEL Legal, try to oppose me.. Be my
> guests, make my day, I know U R watching)?!

No Intel address is on Cc: - so who do you suspect to be reporting
to Intel legal?
> *> [e-mail]  writes:*
>
> *> The only thing that makes sense is for U-Boot to focus on being a
> payload that is started by coreboot (this has already been done) and for
> your issues to be solved within the coreboot frame.*

I can imagine a bunch of other scenarios which use vanilla U-Boot
without coreboot at all.  I can see no technical reason why x86 must
be different from all other architectures where U-Boot boots
directly.
> Peter (Stuge),
>
> Although I DO 100% agree with you what you did write (about U-Boot
> politics) in your very first email about DENX Systems (surprising, isn't
> it), with the *last statement* presented here do NOT agree at all!?
>
> This is a (mild per say denial) noise, my dear friend. "BS" (sorry)... To
> start Coreboot FSP and then to have U-Boot payload as third stage boot
> loader???
>
> GOOGLE would like to have this as concept, don't you agree (huge
> controlling interests involved)?
>
> NOPE! NO GO. Please. Please?! ;-)
>
> Peter...

Zoran - It is totally impossible here to tell who wrote wich part of
this.  From your context, I would guess this was Peter, but from the
working it looks more like yourself.

Please do yourself and all of us the favour and use clean,
unmistablable quoting, so it is definitely clear who wrote what.

Otherwise you are just feeding sparks of a potential flame war by
(mis-) attributing text.
> > On Fri, Nov 3, 2017 at 4:32 AM, Alexander Couzens  wrote:
> > Do you tried to use coreboot (w/o FSP) + u-boot instead? Or is this out
>
> of scope?
>
> This is complete nonsense, and you all know it... Forced by INTEL to
> protect their own interests, in very cruel/selfich way! NO GO! Please!

I don't think this is the way to further a constructive discussion.
> I did NOT want to offend anybody in this list (if anybody, after all, feels
> offended), At The End of The Day, I do NOT care... But you all should think
> what I really wrote here...

So, you use a flame thrower, and then you don't care?  Such
behaviour is usually called trolling...

Thanks, but no.

Wolfgang Denk

BayTrail PCIe problems (hangup) in FSP (in U-Boot)

[Zoran Stojsavljevic]

Hello Wolfgang,

Let me make it very productive... I know you will NOT like it (but I do NOT
care, after what you did answer to me)!

Your guy Stefan is here, asking for a help. Stefan got the straight answer:
FSP/Coreboot (intermingled), then U_Boot as payload... You got that?

What do you want else?

Tell me? It is simple and plain!

Anything else?

Thank you,
Zoran

On Fri, Nov 3, 2017 at 11:27 AM, Wolfgang Denk  wrote:
> Hallo Zoran,
>
> In message <CAGAf8LzBUfqdWN74Kh3SGdSOPiLa4GUKT+Gr-kEN_A9NQShnZQ@mail.
> gmail.com> you wrote:
> > Let us involve in this discussion Mr Denk (father of U-Boot, I know Mr
>
> Denk
> > personally)), and Mr Glass (option [B] here mentioned below)... For the
> > (targeted by me) purposes (History involved)!
>
> You drop me here into some thread, and even though you write
> "History involved", your quoting style does not really make clear
> who i writing what in response to which statements by whom :-(
>
> Read: I don't know what you want.
> > > [e-mail] writes:
> > > I think you are actively hurting the overall ecosystem by working on a
> >
> > different
> > > project (FSP in U-Boot) which overlaps with Coreboot efforts.
> >
> > Peter (Stuge),
> >
> > This is VERY correct statement... You already mentioned: It is NOT INTEL
> > FSP, per say?
>
> I don't understand either of this.  Multiple implementations of the
> same feature / multiple solutions for the same problem have never
> been a bad thing per se.  On contrary, in masy cases they have been
> an essential requisite to enable technical progress.  Of course, it
> is always possible to step on someone's toes, but I am not sure
> above statement is a result of this.
>
> So without deeper understanding I disagree with both statemen't -
> with Peter's, as different projects for the same thing are not
> necessarily bad, and with your's that this was true.
> > It is something I am fighting for years for/in the STRONG interests of
> > U-Boot/Open Source: to have consistent strategy with INTEL IOTG
>
> management
> > which they ignored/have dominant/aggressive strategy to walk over the
>
> Open
> > Source people, people at all (please, INTEL Legal, try to oppose me.. Be
>
> my
> > guests, make my day, I know U R watching)?!
>
> No Intel address is on Cc: - so who do you suspect to be reporting
> to Intel legal?
> > *> [e-mail]  writes:*
> >
> > *> The only thing that makes sense is for U-Boot to focus on being a
> > payload that is started by coreboot (this has already been done) and for
> > your issues to be solved within the coreboot frame.*
>
> I can imagine a bunch of other scenarios which use vanilla U-Boot
> without coreboot at all.  I can see no technical reason why x86 must
> be different from all other architectures where U-Boot boots
> directly.
> > Peter (Stuge),
> >
> > Although I DO 100% agree with you what you did write (about U-Boot
> > politics) in your very first email about DENX Systems (surprising, isn't
> > it), with the *last statement* presented here do NOT agree at all!?
> >
> > This is a (mild per say denial) noise, my dear friend. "BS" (sorry)... To
> > start Coreboot FSP and then to have U-Boot payload as third stage boot
> > loader???
> >
> > GOOGLE would like to have this as concept, don't you agree (huge
> > controlling interests involved)?
> >
> > NOPE! NO GO. Please. Please?! ;-)
> >
> > Peter...
>
> Zoran - It is totally impossible here to tell who wrote wich part of
> this.  From your context, I would guess this was Peter, but from the
> working it looks more like yourself.
>
> Please do yourself and all of us the favour and use clean,
> unmistablable quoting, so it is definitely clear who wrote what.
>
> Otherwise you are just feeding sparks of a potential flame war by
> (mis-) attributing text.
> > > On Fri, Nov 3, 2017 at 4:32 AM, Alexander Couzens
>
> wrote:
> > > Do you tried to use coreboot (w/o FSP) + u-boot instead? Or is this out
> >
> > of scope?
> >
> > This is complete nonsense, and you all know it... Forced by INTEL to
> > protect their own interests, in very cruel/selfich way! NO GO! Please!
>
> I don't think this is the way to further a constructive discussion.
> > I did NOT want to offend anybody in this list (if anybody, after all,
>
> feels
> > offended), At The End of The Day, I do NOT care... But you all should
>
> think
> > what I really wrote here...
>
> So, you use a flame thrower, and then you don't care?  Such
> behaviour is usually called trolling...
>
> Thanks, but no.
>
> Wolfgang Denk

BayTrail PCIe problems (hangup) in FSP (in U-Boot)

[Peter Stuge]

Hey there,

Wolfgang Denk wrote:
> Multiple implementations of the same feature / multiple solutions
> for the same problem have never been a bad thing per se.

Not per se, but they have indeed been a bad thing with coreboot in
the past.

The coreboot project has always sought cooperation with hardware vendors.

Intel was however not interested, to the point where multiple different
efforts to implement coreboot were all independently refused support on
the (obviously false) grounds that "nobody else wants what you are
asking for."

One could argue that Intel is now more interested, since they make the
FSP available and work with coreboot upstream, but I for one think that
is far too simplistic.

I understand where you are coming from, because it would be logical
also for x86 vendors to enable as many customers as possible to
program their silicon, but the trend with x86 is actually strictly
the opposite.

For good insight I highly recommend that you read ISBN 9781430265719
"Platform Embedded Security Technology Revealed" by Intel.

You can hopefully see that it's more important to work together on
x86 than on platforms where vendors have a different attitude.
> So without deeper understanding I disagree with both statemen't -
> with Peter's, as different projects for the same thing are not
> necessarily bad

You're absolutely right about the "not neccessarily" part - but coreboot
experience is clear - we achieve more quicker when working together.
> I can imagine a bunch of other scenarios which use vanilla U-Boot
> without coreboot at all.

Please share? I guess you know that coreboot explicitly wants to do
the bare minimum. U-Boot as payload makes perfect sense to me,
because in the end a standalone U-Boot on x86 needs to do most
everything that coreboot already does.
> I can see no technical reason why x86 must be different from all
> other architectures where U-Boot boots directly.

Right - but good reasons aren't always technical. ;)

Thanks

//Peter