Till Straumann wrote:
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).
Discovery deos not have the necessary capability or connections to the
MCP. I was told that
on the boards which use a Discovery system controller, the MCP signal is
connected to a
pull-up and therefore not used as it is on other boards. That's the
design on the
MVME5500 and MVME6100 boards. I do not see it as a big problem for the
MVME5500 board because ......
Till Straumann wrote :
(currently, a PCI error such as target abort is routed to the one
and only EE interrupt of the powerpc).
The MCP, if available, is routed to the EE interrupt as well.
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).
It's becoming a fact of life for the RTEMS programmers like me. We just had
one signed last month.
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).
Andrew Johnson wrote :
> Ah, but in normal operation it probably only performs 4 or 5 bus
accesses at most; the problem comes if it thinks (from erroneous all-1s
>return values when reading its status registers) that it needs to do
I/O on every one of its input and output channels. This could very
easily >happen if someone hot-swapped out a VME64 IPAC carrier board the
device was mounted on (which shouldn't happen since this driver is >not
hot-swap safe, but it might still occur by mistake).
For the MVME6100, I am more concerned with the
"making use of the dud all-1's read data in the process"
that Andrew mentioned earlier. I do'nt seem to get the answer from the
http://www.aps.anl.gov/epics/tech-talk/2006/msg00892.php, which was
posted by Till.
Is it in the "vmeTsi148ClearVMEBusErrors(&erraddr);" ? How is it
programmed?
We have one application that could be optimied by the PCI bandwidth
that MVME61000 offers ( 800 MHZ).
Also, I am still not sure about the "MBLT" transfer of
the VME backplane, whih was posted at
http://www.aps.anl.gov/epics/tech-talk/2006/msg00888.php.
I assumed it was limited by the capability of the DMA controller
instead of the bus speed because I assume a simple test could be done
easily by using two MVME6100s on a VME320 crate. Perhaps
Till can verify this ??
Andrew Johnson wrote:
> Anyone interested in MicroTCA to replace the now aging VMEbus?
Why do you think VMEbus is aging ? I was researching the VXS bus for
a short while and comapred it with the MVME6100 solution for our
application. VMEbus does not seem to be aging for me.
Regards,
Kate
- Replies:
- Re: VME Bus Error handling on MVME3100 and 6100 boards Andrew Johnson
- 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
- Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
- Navigate by Date:
- Prev:
ezca and ENUM D. Peter Siddons
- Next:
Re: ezca and ENUM 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
|