Re: VME Bus Error handling on MVME3100 and 6100 boards

[Andrew Johnson <anj@aps.anl.gov>]

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.  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.

The earlier Motorola boards did provide the necessary support, even 
though their BSPs didn't 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.  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
--
There is considerable overlap between the intelligence
of the smartest bears and the dumbest tourists.
  -- Yosemite National Park Ranger