[U-Boot] trouble with u-boot and bist fail on pcie adapter

[U-Boot] trouble with u-boot and bist fail on pcie adapter

[Ayman El-Khashab]

I am using a recent version of u-boot (git from the past couple of 
weeks) and have an LSI SAS adapter on a canyonlands board.
What I see happening is that u-boot reads the bist bit, then does 
numerous bar accesses, then sets the bist fail and latency words.
Once the bist is set to fail, the lsi adapter doesn't respond to 
anything else and so Linux fails to see it when it boots.  I've tried 
turning
off pcie support in u-boot, in that case the bist did not get written 
but Linux kernel crashed during the init of the adapter.  The LSI
adapter does work fine in a ubuntu PC, so the hardware is likely good.  
This adapter is an LSISAS2008 gen 2 pcie board.  On the
PC it uses both IO and MEM spaces.

I am unsure what to try next -- Linux should not assume any state about 
the adapter -- on the other hand, if u-boot does cause the
board to go into an unrecoverable state, there isn't much the kernel can 
do about that.  any help / suggestions / experiments would be
much appreciated.

Thanks
Ayman

[U-Boot] trouble with u-boot and bist fail on pcie adapter

[Wolfgang Denk]

Dear Ayman El-Khashab,

In message <4ADC055C.6080006@elkhashab.com> you wrote:
> I am using a recent version of u-boot (git from the past couple of 
> weeks) and have an LSI SAS adapter on a canyonlands board.
> What I see happening is that u-boot reads the bist bit, then does 
> numerous bar accesses, then sets the bist fail and latency words.
> Once the bist is set to fail, the lsi adapter doesn't respond to 
> anything else and so Linux fails to see it when it boots.  I've tried 
> turning
> off pcie support in u-boot, in that case the bist did not get written 
> but Linux kernel crashed during the init of the adapter.  The LSI
> adapter does work fine in a ubuntu PC, so the hardware is likely good.  
> This adapter is an LSISAS2008 gen 2 pcie board.  On the
> PC it uses both IO and MEM spaces.

Did you try setting the "pciscandelay" variable? Try setting it to 5
(or 10) [seconds]. See also

commit 6efc1fc0b63e55f94c5bc61d8dd23c918e3bc778
Author: Grzegorz Bernacki <gjb@semihalf.com>
Date:   Fri Sep 7 18:35:37 2007 +0200

    [PPC440SPe] PCIe environment settings for Katmai and Yucca
    
    - 'pciconfighost' is set by default in order to be able to scan bridges
    behind the primary host/PCIe
    
    - 'pciscandelay' env variable is recognized to allow for user-controlled
    delay before the PCIe bus enumeration; some peripheral devices require a
    significant delay before they can be scanned (e.g. LSI8408E); without the
    delay they are not detected
    
    Signed-off-by: Grzegorz Bernacki <gjb@semihalf.com>

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"The algorithm to do that is extremely nasty. You might want  to  mug
someone with it."                   - M. Devine, Computer Science 340

[U-Boot] trouble with u-boot and bist fail on pcie adapter

[ayman at elkhashab.com]

On Mon, Oct 19, 2009 at 09:35:54AM +0200, Wolfgang Denk wrote:
> 
> 
> Did you try setting the "pciscandelay" variable? Try setting it to 5
> (or 10) [seconds]. See also
> 
<snip>

Thanks Wolfgang,

Per your suggestion, we tried setting the delay (and observed a delay),
but the outcome did not change.  The BIST still got set to fail and 
caused the board to become unresponsive, and thus Linux fails the detection
later.  FWIW, we've tried both with and without switches in between with no
change in the behavior.  We observe the transactions on a lecroy pcie 
analyzer.

I suppose one question that lingers in my mind is why does u-boot do 
anything other than just configure the IO/MEM bars?  Is there some specific
reason it is touching the BIST controls?  If I could understand the reason
for this, I might be able to do some debug and at least determine whether
I need to change u-boot, Linux, or both.

Thanks so much,
Ayman

[U-Boot] trouble with u-boot and bist fail on pcie adapter

[Stefan Roese]

Hi Ayman,

On Monday 19 October 2009 18:19:47 ayman at elkhashab.com wrote:
> Per your suggestion, we tried setting the delay (and observed a delay),
> but the outcome did not change.  The BIST still got set to fail and
> caused the board to become unresponsive, and thus Linux fails the detection
> later.  FWIW, we've tried both with and without switches in between with no
> change in the behavior.  We observe the transactions on a lecroy pcie
> analyzer.

OK, thanks for reporting.
 
> I suppose one question that lingers in my mind is why does u-boot do
> anything other than just configure the IO/MEM bars?  Is there some specific
> reason it is touching the BIST controls?

Could you please check the 4xx PCIe code (cpu/ppc4xx/4xx_pcie.c), where 
exactly the BIST is "touched". A quick scan through the source didn't reveal 
such an access to me. Could be I missed it though.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de