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.


> > pe...@stuge.se 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?

> *> pe...@stuge.se  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

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Once they go up, who cares where  they  come  down?  That's  not  my
department."   - Werner von Braun

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Zoran Stojsavljevic]

And, to add to this case be spicy... Very spicy in this World (of final
interests)!

https://embedded.communities.intel.com/thread/13579

Thank you, Mr Roese! Thank you very much! You got it!

Here is the right addressee to solve the problem... But what the "initial
genesis" guy answered, does it make any sense? As well, as the Creator of
U-Boot (says he) prays to the Open Source Church?!

But hey, interests are changing over time (sure), and what? Really? And we
all change Churches, Religions, and U Tell me what? Why?

Greed is Good, Greed is Right... Doesn't it, Mr, Denk (I addressed you
here, directly)!?

And, yes, I am also involved. In this mess. Not running away from my woes!

https://www.youtube.com/watch?v=R8y6DJAeolo

Zoran
___

On Fri, Nov 3, 2017 at 8:20 PM, Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

> > I don't understand your note at all Zoran, but I am not alone it seems.
>
> I am not one who is asking for help here. It is U-Boot creators, not
> knowing how to solve (particular) INTEL mess. But if you all agree with
> this, I have not at all problem with this mess. You asked for it, didn't
> you, all???
>
> And... You all do the particular solutions. Today reverse engineering,
> tomorrow some partial SW from who-ever-supplies-this, after tomorrow with
> the binary blobs. Whatever works better/best for anybody... Today one API,
> tomorrow another... After tomorrow something completely different!
> Redesigned APIs, completely. ;-)
>
> It seems that I cleared it all, didn't I?
>
> Good Luck with the sporadic solutions (whatever works the best/at all in
> particular cases)!
>
> Zoran
>
> On Fri, Nov 3, 2017 at 2:48 PM, ron minnich  wrote:
>
>>
>>
>> On Fri, Nov 3, 2017 at 5:54 AM Zoran Stojsavljevic <
>> zoran.stojsavlje...@gmail.com> wrote:
>>
>>>
>>>
>>> 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?
>>>
>>>
>>>
>>
>> Stefan got a suggestion from me that running u-boot as a coreboot payload
>> might be easier, as it insulates u-boot from having to deal with FSP. I
>> also commented that I had no complaint with them running without coreboot,
>> since the more open source firmware we have the better. Either path is
>> fine, whatever works best for u-boot.
>>
>> I don't understand your note at all Zoran, but I am not alone it seems.
>>
>> ron
>>
>
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 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

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Zoran Stojsavljevic]

> I don't understand your note at all Zoran, but I am not alone it seems.

I am not one who is asking for help here. It is U-Boot creators, not
knowing how to solve (particular) INTEL mess. But if you all agree with
this, I have not at all problem with this mess. You asked for it, didn't
you, all???

And... You all do the particular solutions. Today reverse engineering,
tomorrow some partial SW from who-ever-supplies-this, after tomorrow with
the binary blobs. Whatever works better/best for anybody... Today one API,
tomorrow another... After tomorrow something completely different!
Redesigned APIs, completely. ;-)

It seems that I cleared it all, didn't I?

Good Luck with the sporadic solutions (whatever works the best/at all in
particular cases)!

Zoran

On Fri, Nov 3, 2017 at 2:48 PM, ron minnich  wrote:

>
>
> On Fri, Nov 3, 2017 at 5:54 AM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>>
>>
>> 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?
>>
>>
>>
>
> Stefan got a suggestion from me that running u-boot as a coreboot payload
> might be easier, as it insulates u-boot from having to deal with FSP. I
> also commented that I had no complaint with them running without coreboot,
> since the more open source firmware we have the better. Either path is
> fine, whatever works best for u-boot.
>
> I don't understand your note at all Zoran, but I am not alone it seems.
>
> ron
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[ron minnich]

On Fri, Nov 3, 2017 at 5:54 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:

>
>
> 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?
>
>
>

Stefan got a suggestion from me that running u-boot as a coreboot payload
might be easier, as it insulates u-boot from having to deal with FSP. I
also commented that I had no complaint with them running without coreboot,
since the more open source firmware we have the better. Either path is
fine, whatever works best for u-boot.

I don't understand your note at all Zoran, but I am not alone it seems.

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

Re: [coreboot] 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  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.
>
>
> > > pe...@stuge.se 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?
>
> > *> pe...@stuge.se  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
>
> --
> DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> "Once they go up, who cares where  they  come  down?  That's  not  my
> department."   - Werner von Braun
>
-- 
coreboot mailing list: coreboot@coreboot.org

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

[Zoran Stojsavljevic]

Crazy context, what I am reading in this thread... Well! Annoying...
Perception (mine) it is (do you all agree)?!

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)!

Shall we? ;-)

> On Fri, Nov 3, 2017 at 4:32 AM, Alexander Couzens  wrote:
> Hi Stefan,
> we have two versions in the tree
> [A] fsp baytrail
> [B] non-fsp baytrail but with mrc.bin as meminit *(DONE by Chromium -
HOW???*)

Lynxis (really?!?!)  https://www.youtube.com/watch?v=jbfLYSJFdWM [Ferocious
Disposition??? ;-)]

Version [B] is the one, most probably, as initial architecture, U-Boot
[Stefan Roese/Denx Systems] is using?! Coreboot is out of question/scope,
since I see that the initial email [by Mr Roese] is NOT (anyhow) understood
(well) by Coreboot designers (Peter Stuge, you do get this one, don't
you... I "somehow" appreciate/your effort)!

Since the following presented below is (I assume) true, if I am not
mistaken. Mr Denk can oppose me (please, do not hesitate, Mr Denk - killed
me few times in The Past, but...You all never know???), I am in waiting
state for this one?!

> pe...@stuge.se 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?

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)?!


*> pe...@stuge.se  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.*

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...

And, since (in contrary to you) I am VERY familiar with/what DENX Systems
does (I am, believe me)... U-Boot should/MUST to be freed of GOOGLE/INTEL
behemoths... OK?

So, I am leaving (huge interest) credits to Chromium... Which are (anyhow
by politically correct) slaves to GOOGLE interests... ;-)

*ARE THEY, MR. RON MINNICH???*

OFF TOPIC: Got the point (I am as we speak in Belgrade, and going to play
Street Ball (Ada Ciganlija) with the street people... Hey?)???

> 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 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...

Please, think it through???

Thank you,
Zoran Stojsavljevic
___

On Fri, Nov 3, 2017 at 4:32 AM, Alexander Couzens  wrote:

> Hi Stefan,
>
> we have two versions in the tree
> a) fsp baytrail
> b) non-fsp baytrail but with mrc.bin as meminit
>
> Do you tried to use coreboot (w/o FSP) + u-boot instead? Or is this out
> of scope?
>
> Best,
> lynxis
> --
> Alexander Couzens
>
> mail: lyn...@fe80.eu
> jabber: lyn...@fe80.eu
> mobile: +4915123277221
> gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Stefan Roese]

Hi Alexander,

On 03.11.2017 04:32, Alexander Couzens wrote:

we have two versions in the tree
a) fsp baytrail
b) non-fsp baytrail but with mrc.bin as meminit

Do you tried to use coreboot (w/o FSP) + u-boot instead? Or is this out
of scope?


We have not tried this yet, thanks for the tip. Right now, I'm still
trying to find a solution for this FSP issue. If this is not possible,
then your suggestion might be an option, yes.

Thanks,
Stefan


--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Alexander Couzens]

Hi Stefan,

we have two versions in the tree
a) fsp baytrail
b) non-fsp baytrail but with mrc.bin as meminit

Do you tried to use coreboot (w/o FSP) + u-boot instead? Or is this out
of scope?

Best,
lynxis
-- 
Alexander Couzens

mail: lyn...@fe80.eu
jabber: lyn...@fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F  F1E2 C29E 9DA6 A0DF 8604


pgpCncxewz37x.pgp
Description: OpenPGP digital signature
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[ron minnich]

On Thu, Nov 2, 2017 at 8:44 AM Stefan Roese  wrote:

>
>
> In this special case, I might have triggered a bug / issue in the Intel
> FSP and solving this might also help the coreboot project / community.
>
>
>
Sounds good to me. I have no complaint with what you're doing; the more
people working to open up firmware, the better. Good luck!

ron
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Stefan Roese]

Hi Ron,

On 02.11.2017 16:20, ron minnich wrote:
Simon Glass has done excellent work with making u-boot run as a coreboot 
payload for at least 5 years now. You might want to talk to him. It 
might help avoid a lot of unnecessary work. Just a thought.


I'm in contact with Simon, thanks for the notice. He also did a lot of
work on getting U-Boot running as a standalone bootloader on some x86
platforms (e.g. MinnowMax). I understand that it is debatable, if this
is "needed" or not. Even though diversity might help all parties - at
least from my point of view.

In this special case, I might have triggered a bug / issue in the Intel
FSP and solving this might also help the coreboot project / community.

Thanks,
Stefan

On Thu, Nov 2, 2017 at 7:31 AM Peter Stuge > wrote:


Hi Stefan,

Stefan Roese wrote:
 > I'm facing a PCIe init related problem most likely caused in the
 > Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you
 > don't mind me posting this question on this coreboot list, since
 > here many more people are present with Intel FSP knowledge.

I think you are actively hurting the overall ecosystem by working on
a different project (FSP in U-Boot) which overlaps with coreboot
efforts.

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.

Anything else is an obviously selfish effort by Denx and I don't see
why the coreboot community would support that. Please know that I
have no bias against Denx, since I had no experience with Denx I
thus far always erred on the side of giving benefit of the doubt.

At the very least, you should have framed your question in a coreboot
setting, if you want to engage with the coreboot community.

That is of course still very much possible.


//Peter

--
coreboot mailing list: coreboot@coreboot.org

https://mail.coreboot.org/mailman/listinfo/coreboot





--
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[ron minnich]

Simon Glass has done excellent work with making u-boot run as a coreboot
payload for at least 5 years now. You might want to talk to him. It might
help avoid a lot of unnecessary work. Just a thought.

On Thu, Nov 2, 2017 at 7:31 AM Peter Stuge  wrote:

> Hi Stefan,
>
> Stefan Roese wrote:
> > I'm facing a PCIe init related problem most likely caused in the
> > Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you
> > don't mind me posting this question on this coreboot list, since
> > here many more people are present with Intel FSP knowledge.
>
> I think you are actively hurting the overall ecosystem by working on
> a different project (FSP in U-Boot) which overlaps with coreboot
> efforts.
>
> 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.
>
> Anything else is an obviously selfish effort by Denx and I don't see
> why the coreboot community would support that. Please know that I
> have no bias against Denx, since I had no experience with Denx I
> thus far always erred on the side of giving benefit of the doubt.
>
> At the very least, you should have framed your question in a coreboot
> setting, if you want to engage with the coreboot community.
>
> That is of course still very much possible.
>
>
> //Peter
>
> --
> coreboot mailing list: coreboot@coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Peter Stuge]

Hi Stefan,

Stefan Roese wrote:
> I'm facing a PCIe init related problem most likely caused in the
> Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you
> don't mind me posting this question on this coreboot list, since
> here many more people are present with Intel FSP knowledge.

I think you are actively hurting the overall ecosystem by working on
a different project (FSP in U-Boot) which overlaps with coreboot
efforts.

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.

Anything else is an obviously selfish effort by Denx and I don't see
why the coreboot community would support that. Please know that I
have no bias against Denx, since I had no experience with Denx I
thus far always erred on the side of giving benefit of the doubt.

At the very least, you should have framed your question in a coreboot
setting, if you want to engage with the coreboot community.

That is of course still very much possible.


//Peter

-- 
coreboot mailing list: coreboot@coreboot.org
https://mail.coreboot.org/mailman/listinfo/coreboot

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

[Stefan Roese]

Hi,

I'm facing a PCIe init related problem most likely caused in the
Intel FSP in our BayTrail U-Boot port (not coreboot!). I hope you
don't mind me posting this question on this coreboot list, since
here many more people are present with Intel FSP knowledge.

So here we go:

We are currently struggling with an FSP PCIe related issue on our
BayTrail target. Here we use an PLX / Avago PCIe switch, connected
to the PCIe root port of the CPU with a PCIe x4 link.

The BIOS always boots fine. Only U-Boot doesn't boot at all. No
output on the console. This is on some boards, somehow depending
on the PLX switch that is connected.

Measuring has shown, that the PCIe clock is only stable for ~20ms
before data is transferred in the U-Boot case. In the BIOS case,
the time between clock stable and data is ~120ms. The PCIe spec
mentions, that  the clock should be asserted for more than 100ms.
So U-Boot is violating the spec here, which might be the root cause.

I've now instrumented the U-Boot with many early debug and delay
code and found, that it hangs inside of the FSP code. I then
installed the DEBUG FSP blob and have found, that its stuck (as
expected) in the FSP PCIe init:


CommonUsbInit() - End
ConfigureUsb() End
PchInitRootPorts() Start

Here the log from a different board, with stable and working
4 times x1 PCIe links (different board with 4 times x1 PCIe
links -> pci-good):

...
CommonUsbInit() - End
ConfigureUsb() End
PchInitRootPorts() Start
Root Port 1 device enabled. RpEnableMask: 0xF
Root Port 2 device enabled. RpEnableMask: 0xF
Root Port 3 device enabled. RpEnableMask: 0xF
Root Port 4 device enabled. RpEnableMask: 0xF
PchInitRootPorts() End
ConfigureSata() Start
...

I've attached the logs, so that you can review them yourself
as well.

Do you have any ideas, whats going on in the PCI init stuff in the
FSP? Or if and how we can influence this PCIe related configuration
to solve this hangup inside of the FSP? Has such a problem or a
similar one been noticed on some BayTrail platforms with coreboot
before?

BTW:
I've just found a workaround (more ugly hack) to solve this issue.
If I disable the link in the PCIe root port (PCI BDF 0,0x1c,0)
in the LCTL register before jumping into the FSP, the FSP
"survives" the init phase and jumps back into U-Boot. I can
then re-force the link before the U-Boot PCI scan is done
and then everything is fine. The PCIe PLX switch is detected
correctly and all downstream ports seem to be working as
expected.

Thanks,
Stefan 


= PEIM FSP  (VLYVIEW0 0x0304) =
Register PPI Notify: DCD0BE23-9586-40F4-B643-06522CED4EDE
Install PPI: 8C8CE578-8A3D-4F1C-9935-896185C32DD3
Install PPI: 5473C07A-3DCB-4DCA-BD6F-1E9689E7349A
The 0th FV start address is 0x000FFFE0400, size is 0x00017C00, handle is 0x0
Register PPI Notify: 49EDB1C1-BF21-4761-BB12-EB0031AABB39
Register PPI Notify: EA7CA24B-DED5-4DAD-A389-BF827E8F9B38
Install PPI: B9E0ABFE-5979-4914-977F-6DEE78C278A6
Install PPI: DBE23AA9-A345-4B97-85B6-B226F1617389

Install PPI: 06E81C58-4AD7-44BC-8390-F10265F72480
Install PPI: 01F34D25-4DE2-23AD-3FF3-36353FF323F1

Install PPI: 49EDB1C1-BF21-4761-BB12-EB0031AABB39
Notify: PPI Guid: 49EDB1C1-BF21-4761-BB12-EB0031AABB39, Peim notify entry 
point: FFFE0FD4
The 1th FV start address is 0x000FFFB, size is 0x0002F400, handle is 
0xFFFB

Install PPI: A55D6970-1306-440C-8C72-8F51FAFB2926

PcdMrcInitTsegSize = 1
PcdMrcInitMmioSize = 800
PcdMrcInitSPDAddr1 = A0
PcdMrcInitSPDAddr2 = A2
Setting BootMode to 0
Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
About to call MrcInit();
BayleyBay Platform Type
RID = 0x11.
Reg_EFF_DualCH_EN = 0x100301C0.
CurrentMrcData.BootMode = 4
Configuring Memory Start...
Configuring Memory End
UpperTotalMemory =  0x1
dBMBOUND =  0x8000
dBMBOUNDHI   =  0x18000
dGFXBase =  0x7BE0
dTSegBase=  0x7BD0
Save MRC params.
Current MRC Data DDR Freq2
Current MRC Data Core Freq   2
Current MRC Data Tcl 8
Current MRC Data WL  7
Current MRC Data DDRType 1
Current MRC Data MMIO Size   800
Current MRC Data TSeg Size   1
Channel 0
Enabled 1

 Socket 0
DimmPresent 1
DimmDataWidth 1
DimmBusWidth 3
DimmSize 2
DimmSides 0
Channel 1
Enabled 1

 Socket 0
DimmPresent 1
DimmDataWidth 1
DimmBusWidth 3
DimmSize 2
DimmSides 0
Current MRC Timing Data MRC_DATA_TRP 8
Current MRC Timing Data MRC_DATA_TRCD 8
Current MRC Timing Data MRC_DATA_TRAS18
Current MRC Timing Data MRC_DATA_TWR   8
Current MRC Timing Data MRC_DATA_TWTR   4
Current MRC Timing Data MRC_DATA_TRRD6
Current MRC Timing Data MRC_DATA_TRTP   4
Current MRC Timing Data MRC_DATA_TFAW   16
PeiInstallPeiMemory MemoryBegin 0x7B60, MemoryLength 0x20
Old Stack