EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: VME Bus Error handling on MVME3100 and 6100 boards
From: Till Straumann <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS tech-talk <[email protected]>
Date: Wed, 23 Aug 2006 14:29:40 -0700
Andrew Johnson wrote:
Till Straumann wrote:
I was on vacation last week but I'd like to wrap this thread up with the
comment that regarding bus errors, the MVME5500 and the MVME6100
are not any different. AFAIK, none of those have the MCP interrupt
to the CPU hooked up, so even if the Tsi148 would generate a PCI target-
abort it would still not raise a machine-check interrupt.

I don't have the programmer's manual for the Discovery-II (MV64360) chip so I don't know whether the Host Bridge has the necessary capability or connections.
I don't have it either. Kate could clarify for the GT64260. Looking at the linux
drivers, I doubt it. They install regular ISRs to detect PCI errors (such as target abort).
You probably know more about the hardware than I do, and if there's no connection from the Bridge to the MCP input I accept what you say; this only increases my dislike of the MVME 3100 and 6100 boards though.
You should dislike the marvell system controllers (I really dislike that whole thing
from the interrupt, i2c to the ethernet controller)
and that company's policy of not granting access to documentation (w/o signing
an NDA).


Alas, nowadays almost all PPC boards seem to use a marvell system controller.

The earlier Motorola boards did provide the necessary support, even though their BSPs didn't use it.
I know. The RTEMS BSPs (mvme2700, svgm) do use it.
The Programmer's Reference Guide for the MVME2700 has the following information about the PCI Host Bridge in the Raven ASIC:

Error Handling

The Raven will be capable of detecting and reporting the following errors
to one or more MPC masters:
* MPC address bus time-out
* PCI master signalled master abort
* PCI master received target abort
* PCI parity error
* PCI system error


Each of these error conditions will cause an error status bit to be set in the
MPC Error Status Register. If a second error is detected while any of the
error bits is set, the OVFL bit is asserted, but none of the error bits are
changed. Each bit in the MPC Error Status Register may be cleared by
writing a 1 to it; writing a 0 to it has no effect. New error bits may be set
only when all previous error bits have been cleared.
...
Each MERST error bit may be programmed to generate a machine check
and/or a standard interrupt. The error response is programmed through the
MPC Error Enable Register on a source by source basis. When a machine
check is enabled, either the MID field in the MPC Error Attribute Register
or the DFLT bit in the MEREN Register determine the master to which the
machine check is directed. For errors in which the master who originated
the transaction can be determined, the MID field is used, provided the MID
is%00 (processor 0), %01 (processor 1), or %10 (processor 2). For errors

The wording for the equivalent section about the Hawk ASIC in the MVME5100 Programmer's Reference Guide is almost identical.


For the MVME2100 the Host Bridge is integrated onto the CPU, so the equivalent documentation is found in the MPC8240 User's Manual:

13.3.3.4 Received PCI Target-Abort Error
If a PCI transaction initiated by the MPC8240 is terminated by target-abort, the received
target-abort ïag (bit 12) of the PCI status register is set. If ErrEnR2[1] and
PICR1[MCP_EN] are both set and the MPC8240 receives a target-abort, the MPC8240
reports the error to the processor core by asserting mcp (provided PICR1[MCP_EN] is set).
Note that any data transferred in a target-abort transaction may be corrupt.


Till Straumann wrote:
OTOH, a VME bus error on read can be reported simply by using
the respective interrupt (as demonstrated earlier).

I will be implementing that in my version of the mv6100 BSP (but as demonstrated earlier though, this is of little use if the Bus Error occurs inside an ISR. I know about one device that will perform 97 bus accesses inside its ISR if it gets all-1s from its read cycles.
This driver should probably be rewritten. That many VME accesses from an ISR
introduce serious latencies (even w/o bus timeouts).

- T.
Each access would take a VME bus timeout (2048us by default) to execute, thus interrupts would be locked out for almost 0.2 seconds while this ISR runs.)

PS: does vxWorks raise a machine check on the 5500 as a result of
a bus error???

I don't have a 5500, so I don't know; from what Kate says though it can't, and in any case I very much doubt if the standard vxWorks BSP would configure it that way even if the hardware could.


- Andrew


Replies:
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Kate Feng
References:
VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Kate Feng
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson

Navigate by Date:
Prev: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·