Bucky Katz wrote;

> One of the things you will find _very_ frustrating about ARM, if you
> don't already, is that it's really about five different architectures,
> and they all misbehave differently.  (You are in a maze of TRMS, all
> slightly different...)
>
> Six when you finally get the joy of ARM11 devices.

The diversity of interrupt HW machinery is _major_ burden against
NetBSD (and any other OS) porting.  I have three ARM9 SoC UMs
at hand.  All the interrupt machinery designs differ each other in large
degree.  NetBSD/arm, in general, does smart things with "ipending" global
variable to implement NetBSD-peculiar (other OS camp would call it
strange) spl(9) priority level scheme.  While this approach fits with 32 way
interrupt source, it is rather painful to adapt 64bit source.  Quite frankly, I'm
doubtful whether ep93xx/ep93xx_intr.c is doing spl(9) correctly.  dual VIC
design is a mud pool.

Fortunately, it seems a standard design practice to let ARM SoC have "priority
encoder" to assign interrupt level (small number 0..15) to group interrupt
sources.  This might provide a way to simplify spl interrupt scheme for 64 way
source.  For example, Freescale Linux for MC9328 picks "IRQ number"
pending in the highest priority thru a dedicate register.  MC9328 also allows
to enable/disable individual interrupt source by writing "IRQ number" to
control register. This is a handy short cut to reduce 64 way source complexity
compared to handling multiple registers in search for target bits.

I guess some of readers are to port NetBSD/arm for new ARM SoC.  Implementing
NetBSD interrupt machinery for ARM is the hardest part of the entire efforts.  It's
true that understanding NetBSD spl(9) is not easy, but inconsistent variation of
ARM SoC interrupt HW is a real hurdle to go forward.

Toru Nishimura/ALKYL Technology