Timo,
These routines will probably be moved out of EPICS base in the near
future into a device and or OS specific distribution. If you send your
patches I will attempt install them into the master copy.
Jeff
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]On Behalf Of
> Timo Korhonen
> Sent: Thursday, October 19, 2000 5:16 AM
> To: [email protected]
> Subject: Interrupts, vectors and mv230x ioc
>
>
> The issue of interrupt vector handling in our PowerPC ioc (mv2306) has been a
> little bit of an open issue for us until recently. I had to study an existing
> driver
> (written and running on a 68K cpu) that hung completely and behaved somewhat
> randomly when we tried it on our mv2306 ioc's. The problem turned out to be
> the following:
>
> The driver uses functions from devLib.c to connect and disconnect routines to
> interrupt vectors: during initialization it connects to a dummy routine to check
>
> if the board works as expected and then, if successful, it disconnects from this
>
> vector and connects to the "real" irq handler.
> In vxWorks intArchLib, only a small subset of functions are implemented for
> the PPC architecture; notably, functions like intVecGet and intVecSet are not
> implemented (although they are in the symbol table and calling intVecGet for
> instance always returns zero!)
>
> This behaviour confused the driver, because it could not disconnect from the
> first interrupt. devDisconnectInterrupt (in devLib.c) uses intVecGet to get
> the connected handler - and gets always NULL, even if the vector was connected.
>
> On mv2306, the VME interrupts come through the interface chip (Tundra Universe)
> to a single handler which then dispatches the installed handlers based on the
> vector table information.
> The vectors are stored in linked lists by the interrupt controller driver. I
> wrote a small set of functions with which it is possible to get the
> equivalent (I guess....) behaviour to a 68K cpu.
> I also have modifications to make the devLib and veclist work.
>
> However, I have a few open questions:
>
> 1. The mv2306 structure permits having multiple handlers attached to the same
> vector. However, this causes problems for devDisconnectInterrupt (if the
> same routine is attached several times with different parameters, there is
> no way to tell which one to disconnect.)
> Allowing only one routine per vector (like in 68K) should be ok?
>
> 2. The code in veclist.c makes a check (cISRTest) where it tries to match the
> handler attached to a pointer to a C routine. For those architectures where this
>
> is imported, the call to intConnect constructs a handler from the passed
> function; in our ioc, a VOIDFUNCPTR and an int are just put into a linked
> list of handlers. In my patch I do the following: I look for a symbol at the
> address
> and if a symbol is found, I assume that is a C funtion. I believe this is a
> reasonable assumption?
> The generic VME irq handler (in universe.c) calls the user handler like this:
>
> currHandler->vec (currHandler->arg);
>
> which to me looks pretty much like assuming a C routine.
>
> 3. The list of unexpected interrupt handlers is not very relevant in the case of
>
> mv2306, because the Universe interrupt handler checks the vector table and
> complains if the interrupt handler entry is NULL.
> It is not necessary to have a handler attached to unused vectors. This is just
> cosmetics, but in the patches I remove the default vxWorks handler stub
> definitions from the table, to avoid confusing error messages during startup.
>
> 4. I am not sure if this applies to other than mv2300 series ioc. Because of
> this, I used #ifdef MV2300 in the patches.
>
> 5. Could the experts help me to sort out the patches so that this could go into
> the next release (if they are still relevant)?
>
> I do not attach any code here but I will send it to whoever wants to help (Marty
> Kraimer?).
>
> Timo Korhonen/SLS
>
>
>
> --
> Timo Korhonen PSI (Paul Scherrer Institut), SLS
> CH-5232 Villigen PSI
> tel + 41- 56 3103262 fax + 41 - 56 310 3151
> e-mail: [email protected]
>
>
>
- References:
- Interrupts, vectors and mv230x ioc Timo Korhonen
- Navigate by Date:
- Prev:
Interrupts, vectors and mv230x ioc Timo Korhonen
- Next:
Re: Interrupts, vectors and mv230x ioc 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:
Interrupts, vectors and mv230x ioc Timo Korhonen
- Next:
Re: Interrupts, vectors and mv230x ioc 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
|