RapidIO: MC Exception when enumerating peer to peer connection

RapidIO: MC Exception when enumerating peer to peer connection

[Thomas Taranowski]

Hi all,

I'm trying to bring up a RapidIO on my p2020 on v2.6.36-rc7.  I'm
running into an issue when the host tries to enumerate the agent
devices, and fails miserably.  The rio driver does a
fsl_rio_config_read with a destid of 255, after which it hangs, until
I get a timeout exception (Handled now, thanks!).  The port connection
get's trained, and everything looks good, but I get no response.  Any
ideas on what to look at to debug this?

Also, after the timeout, the driver seems to hang after that,
presumably because the port is in an error-stop state, because when I
use my trusty jtag to issue a Port Link Maintenance Request and
request status, I get back unrecoverable ackID error for port 1, and
error-stopped port_status for port 2.

0_ffec0140 : 00000004 80000050 02000202 00000000  .......P........
0_ffec0150 : 00000000 00000000 00120002 42600001  ............B`..
0_ffec0160 : 00000004 00000005 00000000 00000000  ................


Reference information below:


U-Boot LAW configuration:
========================
Local Access Window Configuration
        LAWBAR1 : 0x000a0000, LAWAR1 : 0x80c00017 /* SRIO Port 1 */
        LAWBAR2 : 0x000a1000, LAWAR2 : 0x80d00017 /8 SRIO Port 2 */


Excerpt from linux boot:
====================
Setting up RapidIO peer-to-peer network /rapidio@ffec0000
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~ fsl_rio_setup ~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
of:fsl-of-rio ffec0000.rapidio: Of-device full name /rapidio@ffec0000
of:fsl-of-rio ffec0000.rapidio: Regs: [mem 0xffec0000-0xffedffff]
of:fsl-of-rio ffec0000.rapidio: LAW start 0x00000000a0000000,
 size 0x0000000001000000.
of:fsl-of-rio ffec0000.rapidio: pwirq: 48, bellirq: 50, txirq: 53, rxirq 54
of:fsl-of-rio ffec0000.rapidio: Overriding RIO_PORT setting to single lane 0
of:fsl-of-rio ffec0000.rapidio: RapidIO PHY type: serial
of:fsl-of-rio ffec0000.rapidio: Hardware port width: 4
of:fsl-of-rio ffec0000.rapidio: Training connection status: Single-lane 0
of:fsl-of-rio ffec0000.rapidio: RapidIO Common Transport System size: 256
EIPWQBAR: 0x00000000 IPWQBAR: 0x1f107000
IPWMR: 0x00100120 IPWSR: 0x00000000
RIO: enumerate master port 0, RIO0 mport
rio_enum_host: port `RIO0 mport`
fsl_local_config_write: index 0 offset 00000068 data 00000000
fsl_local_config_read: index 0 offset 00000068
fsl_local_config_write: index 0 offset 00000060 data 00000000
master port device id set to 0 (next=0)
fsl_local_config_read: index 0 offset 0000000c
fsl_local_config_read: index 0 offset 00000100
fsl_local_config_read: index 0 offset 00000158
RIO: Rio network device created
rio_enable_rx_tx_port(local = 1, destid = 0, hopcount = 0, port_num = 0)
fsl_local_config_read: index 0 offset 0000000c
fsl_local_config_read: index 0 offset 00000100
fsl_local_config_read: index 0 offset 0000015c
fsl_local_config_write: index 0 offset 0000015c data 42600001
Enumerating rionet.
RIO: acquiring  device lock...
fsl_rio_config_read: index 0 destid 255 hopcount 0 offset 00000068 len 4
RIO: fsl_rio_mcheck_exception - MC Exception handled. reason=0x80000000
RIO: cfg_read error -14 for ff:0:68
RIO_LTLEDCSR = 0x0


Thanks!

Re: RapidIO: MC Exception when enumerating peer to peer connection

[Micha Nelissen]

Thomas Taranowski wrote:
> use my trusty jtag to issue a Port Link Maintenance Request and
> request status, I get back unrecoverable ackID error for port 1, and
> error-stopped port_status for port 2.

Did you try rebooting all devices together?

Micha

Re: RapidIO: MC Exception when enumerating peer to peer connection

[Thomas Taranowski]

Yes, I tried pretty much all combinations of boot order, but I believe
the preferred approach is to boot the agents first, then the host
according to my freescale documentation.  My problem was that all
three devices had the same device id.  Once I programmed them with
different device id's via the alternate device id register I could
finally get doorbell messages across with the jtag.

Thanks


On Fri, Oct 29, 2010 at 2:21 AM, Micha Nelissen <micha@neli.hopto.org> wrote:
> Thomas Taranowski wrote:
>>
>> use my trusty jtag to issue a Port Link Maintenance Request and
>> request status, I get back unrecoverable ackID error for port 1, and
>> error-stopped port_status for port 2.
>
> Did you try rebooting all devices together?
>
> Micha
>

RE: RapidIO: MC Exception when enumerating peer to peer connection

[Bounine, Alexandre]

Thomas Taranowski wrote:
> Yes, I tried pretty much all combinations of boot order, but I believe
> the preferred approach is to boot the agents first, then the host
> according to my freescale documentation.  My problem was that all
> three devices had the same device id.  Once I programmed them with
> different device id's via the alternate device id register I could
> finally get doorbell messages across with the jtag.
=20
In the current fsl_rio implementation initialization enables ACCEPT_ALL
mode for the port therefore you should not have problems caused by
initial destID value. Based on your post about multiport support I think
you are close to find a source of the problem.

Are you using any switches in your setup or this is pure board-to-board
configuration?

Alex.

Re: RapidIO: MC Exception when enumerating peer to peer connection

[Micha Nelissen]

Bounine, Alexandre wrote:
> In the current fsl_rio implementation initialization enables ACCEPT_ALL
> mode for the port therefore you should not have problems caused by
> initial destID value. Based on your post about multiport support I think
> you are close to find a source of the problem.

Be aware that accept-all is not enabled from moment of power-on until 
boot of kernel. Depending on reset sequence you may or may not notice 
the difference.

Micha

RE: RapidIO: MC Exception when enumerating peer to peer connection

[Bounine, Alexandre]

Micha Nelissen <micha@neli.hopto.org> wrote:
> Bounine, Alexandre wrote:
> > In the current fsl_rio implementation initialization enables
ACCEPT_ALL
> > mode for the port therefore you should not have problems caused by
> > initial destID value. Based on your post about multiport support I
think
> > you are close to find a source of the problem.
>=20
> Be aware that accept-all is not enabled from moment of power-on until
> boot of kernel. Depending on reset sequence you may or may not notice
> the difference.

He mentioned in earlier post that he boots agents first.

Re: RapidIO: MC Exception when enumerating peer to peer connection

[Micha Nelissen]

Bounine, Alexandre wrote:
> In the current fsl_rio implementation initialization enables ACCEPT_ALL
> mode for the port therefore you should not have problems caused by
> initial destID value. Based on your post about multiport support I think

Btw, best is to use 0xFF (or 0xFFFF in 16-bit environment) as 
initial/hardware strapped destid, and not change it in any bootloader. 
This makes for much stabler kernel enumeration: the host can talk to all 
agents with 0xFF initially.

Micha

Re: RapidIO: MC Exception when enumerating peer to peer connection

[Thomas Taranowski]

Alex,

Thanks for responses all.  This is a pure board-to-board setup.  After
further investigation, it's pretty clear now that the issue is due to
my use of multiple ports ( See my other posting conveniently titled
"Support for multiple ports" :) ).  Unfortunately, the freescale linux
patchset for the p2020 do nothing to resolve this issue.


On Mon, Nov 1, 2010 at 8:58 AM, Bounine, Alexandre
<Alexandre.Bounine@idt.com> wrote:
> Thomas Taranowski wrote:
>> Yes, I tried pretty much all combinations of boot order, but I believe
>> the preferred approach is to boot the agents first, then the host
>> according to my freescale documentation. =A0My problem was that all
>> three devices had the same device id. =A0Once I programmed them with
>> different device id's via the alternate device id register I could
>> finally get doorbell messages across with the jtag.
>
> In the current fsl_rio implementation initialization enables ACCEPT_ALL
> mode for the port therefore you should not have problems caused by
> initial destID value. Based on your post about multiport support I think
> you are close to find a source of the problem.
>
> Are you using any switches in your setup or this is pure board-to-board
> configuration?
>
> Alex.
>
>