[U-Boot] trouble with u-boot and bist fail on pcie adapter
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
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
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
Hi Ayman,
On Monday 19 October 2009 18:19:47 ayman@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@denx.de
participants (4)
-
Ayman El-Khashab -
ayman＠elkhashab.com
-
Stefan Roese -
Wolfgang Denk