Re: VME Bus Error handling on MVME3100 and 6100 boards

[Till Straumann <strauman@slac.stanford.edu>]

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