Experimental Physics and Industrial Control System
|
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
<2006>
2007
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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|