Subject: More IRQ questions

From: David Aparicio Campos <[email-masked]>
Date: Fri, 04 Aug 2000 14:59:57 +0200

Hello all:

I hope you don't hate me  for hammering again and again with CATS
specific questions... ;-)

--------part 1: some tricks
Russell King - ARM Linux Admin wrote:
> David Aparicio Campos writes:
> > IRQ LOCK: IRQ7 is locking the system, disabled
>
> This is the symptom of a stuck active IRQ line.  I'm just guessing,
> but its probably related to the Southbridge.  Most PC PICs (programable
> interrupt controllers) return IRQ7 when they don't know what the source
> of the interrupt is (hence why a LOT of applications don't use IRQs with
> LPTs by default).

I did a work-around for some problems relating to launch Linux with a
firmware developed on my own. The broken thing was a IRQ generated
by "southbridge" devices (i.e ISA bus and so on). I did some
experimental changes (kernel 2.2.13-rmk2) to these files:

include/asm/arch-ebsa285/irq.h
include/asm/arch-ebsa-285/time.h

in order to ignore interrupts from those devices (CATS motherboard
becoming more like a standard EBSA285). I use TIMER0 as system tick,
like EBSA285, not the ISA one.
That way, Linux starts up with no problems... yes, it's not the best
solution, but it's a begining...

---------part 2: questions about IRQ mapping
Russell King - ARM Linux Admin wrote:
>
> > Is IRQ7 related to a "PC compatible" architecture
>
> Yes.  IRQs 0 through 15 are as per your normal PC.  IRQs 16 upwards refer
> to the 21285 IRQs.  Check include/asm-arm/arch-ebsa285/irq*.h for more
> information about these.
>    _____

OK. I was somehow confused about this. CATS original firmware does some
strange (to me, but any hint is welcomed) things about asigning IRQ
numbers.
It gives IRQ 1 thru 3 for PCI add-on cards (there are only three slots),
and IRQ 128+x for onboard southbridge devices. When Linux starts, it
looks those numbers and maps them to 21285 IRQs this way:

IRQ 1    -> IRQ_PCI (INTA) number 28 (FootBridge 12)
IRQ 2    -> IRQ_IN0 (INTB) number 21 (FootBridge   5)
IRQ 3    -> IRQ_IN1 (INTC) number 22 (FootBridge   6)
IRQ 4    -> IRQ_IN3 (INTD) where is slot 4?? PCI/ISA bridge??
IRQ128+x -> IRQ 16+x (Footbridge x???)

SouthBridge common IRQ pin is routed to IRQ_IN2, so number 23
(FootBridge 7), that is the one related to that "IRQ7 lock"
message, isn't it?...

I then revised other firmware sources, but no new clues. Original
firmware from Chalice doesn't work for me, because I need to load
with BOOTP/TFTP from an unsupported NIC. Is anybody there related
with Chalice in order to give me information about source code
licensing? "support" mailbox seems to be out of order...

So, questions:

* Why Linux for CATS doen't assign IRQ from onboard devices to ISA range
  (less than 16)?? For example, USB is 139, so Linux gives IRQ 27
  (Footbridge 11). CATS information says something about giving ISA
  IRQ-11 to USB...
  That is in "arch/arm/kernel/hw-footbridge.c", function "cats_irqval".

* Same source code, question about "IRQ 4". Where is slot 4?? It seems
  like some mistake when derived from EBSA285 (which has 4 slots).

* In order to develop my own firmare, should I use "compatible" IRQ
  assignment (and resource mapping) or should I propose a new Linux 
  architecture? (First seems good at first, but I have almost no 
  information about original firmware, and reverse engineering is very
  limited because of write-only registers). A new Linux architecture
  seems reasonable if more driver support could be added by people
  (volunteers?) to this firmware, becoming then better than original
  one.
  If there is any interest, and as soon as it becomes stable, I will
  release a snapshot...could evolve to a general EBSA285/CATS one...

* There is a problem with message consistency, related to IRQ debugging:
  1) arm subsystem prints original IRQ numbers from PCI  CSR space (1..4
     and 128..144), but
  2) main Linux code shows "compatible", mapped numbers (range 0..31)
  Can we change messages in arch/arm/kernel in order to show same
  numbers than main Linux development? (maybe two numbers, with both
  "compatible" and PCI assignments).

Thank you for your patience...

  David Aparicio

BTW: I have some problems related with my link to internet, so I
couldn't download a 2.4.0-test kernel by the time of writing this,
I'm not checked if those questions have already been fixed... I
will check and post another mail if I find same problems there...

BTW: it's 3rd time I try to post you this :-(( my email server is
on fire also...

unsubscribe: body of `unsubscribe linux-arm-kernel' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 4 Aug 2000 17:30:59 +0100 (BST)

> specific questions... ;-)

Its fine - its kernel stuff on the kernel list.

> (FootBridge 7), that is the one related to that "IRQ7 lock"

No. "IRQ7 lock" means Linux IRQ7, which translates to ISA IRQ7.
Therefore, what I believe is happening is that for whatever reason,
the Southbridge is signalling that it has a pending IRQ via, as you
say IRQ23.

When IRQ23 is detected, we issue a PCI IACK (interrupt acknowledge)
cycle and the southbridge places into the PCI bus the IRQ number of
the interrupt.

At this point, the southbridge says "Hey, I don't have an interrupt
pending, so I'm going to send you the value 7".  This translates
through to IRQ7.

> * Why Linux for CATS doen't assign IRQ from onboard devices to ISA
>   range (less than 16)??

>From your description, the PCI interrupts are not connected to the
southbridge, which handles IRQs 0 through 15.

>   like some mistake when derived from EBSA285 (which has 4 slots).

Its a harmless mistake.  Phil?

>   release a snapshot...could evolve to a general EBSA285/CATS one...

I don't believe this is necessary.

>   "compatible" and PCI assignments).

Please explain some more.  What/where/how are you getting these IRQ
numbers?
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |            http://www.arm.linux.org.uk/            /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |

---

From: David Aparicio Campos <[email-masked]>
Date: Mon, 07 Aug 2000 08:03:35 +0200

> southbridge, which handles IRQs 0 through 15.

Right. PCI IRQ INTA..D are directly connected to FootBridge pins, but also
routed to Southbridge "as they would be in a PC, and can be assigned ISA
interrupts" (according to some sheets from Chalice).
What confuses me is asignation of on-board southbridge devices, like USB,
which is given a 139 IRQ, then Linux assigns IRQ (139-128)+16 -> 27
that would be a IRQ_DMA2. This makes no sense to me. In this same sheets
Chalice says it assigns USB an ISA IRQ, number 11. This would lead to
a IRQ (139-128) -> 11, seems righter.
All this is related to BIOS assigned IRQ > 128, which Linux translates to
FootBridge range, above 16:
("arch/arm/kernel/hw-footbridge.c" function "cats_irqval").
Has anybody played with USB driver for CATS??

> I don't believe this is necessary.

OK, I will try to be "compatible" with former Chalice BIOS (sig).

> Please explain some more.  What/where/how are you getting these IRQ

I have revised all "printk" calls in arch/arm, and I found only one example.
Usually,
Linux prints standard PC numbering. When some driver (in CATS architecture)
finds a PCI device, prints an IRQ assignment above IRQ 16 (which is right).
In "arch/arm/kernel/hw-footbridge.c", same "cats_irqval": irq printed is that
assigned by BIOS, not a Linux number (which can not be done because
there is no possible assignment according to the table). My complaining is
about
labelling only:

Message like this
  "PCI: device AA:BB has unknown irq line X"
could be some like
  "PCI: device AA:BB has unknown BIOS INT number X"

Maybe too much words for an improbable error, it's my fault! (I have seen
this message because I assigned wrong numbers in my BIOS, but besides
Chalice radically change its firmware, this message is never going to be
seen).
As I'm new to arm development, I only wanted to express my first impression
about being confused by "prink" information with my IRQ problems... but as I
write, it seems less important to me, about to delete all this paragraph...

The idea was because x86 mixes PCI and ISA interrupts in range 0..15 (the
"classic" concept about IRQ that we see in messages). So ARM does in a
different way, it has:

1) IRQ "compatible numbers"
2) INT native & PCI numbers, (compatible with #1)
3) BIOS numeration, (incompatible with #2 and #3)

My proposal was to maintain labels like "IRQ n" for case 1, but change 2 and
3:
2) Arquitecture Interrupt Number x : "AIRQ x"
3) Bios Interrupt Number x: "BIRQ x"

Maybe #2 being a crazy idea and #3 a practical one... and I don't know about
other architectures, if it makes sense or not...

David

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Mon, 7 Aug 2000 22:01:28 +0100 (BST)

> other architectures, if it makes sense or not...

It does seem sensible, especially as it's only the CATS which has this
weird and wonderful mapping scheme.  Feel free to submit a patch, but
note that you're working on a non-development kernel.

I don't know if Phil has any comments on this problem (its his code after
all).
   _____

---

From: David Aparicio Campos <[email-masked]>
Date: Tue, 08 Aug 2000 07:47:51 +0200

> note that you're working on a non-development kernel.

I will download 2.2.15 and 2.4.0-preX, and try to send patches for both. Still
guessing If I should move on 2.4.0... I will give it a try.
Please note that label (3) is for CATS (I think there are no messages about BIOS
in other architectures) , but (2) is a general ARM question. From your mail, I will
only patch CATS part.

> I don't know if Phil has any comments on this problem (its his code after

Please, Phil,  tell me also about removing slot 4...

>      like some mistake when derived from EBSA285 (which has 4 slots).

Also, please tell me about on-board IRQs (above 128). I still think that USB
assignment is wrong (at least I don't understand it)... but so I don't have USB
devices (neither drivers knowledge) I cannot test this.

>      That is in "arch/arm/kernel/hw-footbridge.c", function "cats_irqval".

Regards

   David Aparicio

---

From: David Aparicio <[email-masked]>
Date: Wed, 09 Aug 2000 15:40:55 +0200

Hello all again:

> in other architectures) , but (2) is a general ARM question. From your mail, I will

I downloaded 2.2.16 (rmk2) and 2-4.0test5 (rmk2). See below.

> Please, Phil,  tell me also about removing slot 4...

I suppose it doesn't matter to change or leave it, what I would really want
to know is if "slot 4" is any on-board function or if its an add-on card (as
I guess).

> devices (neither drivers knowledge) I cannot test this.

Sorry for the last one, I saw that 2.4.0 (somewhere in 2.3.xx I suppose) fixed it.

I'm far from sending any patch, I had to install a new toolchain (I had incompatible
binutils). Also 2.2.16 needed to be touched by hand (some illegal assembler
intructions,
there was a previous mail in this list about that).
What happened is that my FW is broken with this new toolchain, I am checking all
the thing again :-(.
I used a "frozen" image of my FW with 2.4.0-test5. It hangs also (IRQ still beating
somewhere), but it gives some more information. It's related to a semaphore inside
irq lock handling... What is IRQ_32 (arrrggg) ??

Regards!

boot no options
Linux version 2.4.0-test5-rmk2 (root@lobos) (gcc version 2.95.2 20000516 (release)
[Rebel.com]) #5 Tue Aug 8 18:32:04 CEST 2000
Processor: Intel StrongARM-110 revision 3
Architecture: Chalice-CATS
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/hda1 ro mem=32M parport=0x378,7 ide0=autotune
ide_setup: ide0=autotune
Calibrating delay loop... <2>Bad mode in interrupt handler detected: mode IRQ_32
Vectors:
00000000: ef9f0000 ea0000cd e59ff3d0 ea0000bb  ea00009a ea0000ea ea000078 ea0000e7
00000020: f9000000 50000000 00100000 000000d1  00000000 00000000 00000000 00000000
Stubs:
00000200: e59fd1dc e24ee004 e58de000 e10fe000  e58de004 e3a0d093 e161f00d e20ee00f
00000220: e79fe10e e1b0f00e c00329a0 c0032688  c0032688 c00327a0 c0032688 c0032688
00000240: c0032688 c0032688 c0032688 c0032688  c0032688 c0032688 c0032688 c0032688
00000260: c0032688 c0032688 00000000 00000000  00000000 00000000 00000000 00000000
00000280: e59fd164 e24ee008 e58de000 e10fe000  e58de004 e3a0d093 e161f00d e20ee00f
000002a0: e79fe10e e1b0f00e c0032960 c0032674  c0032674 c0032740 c0032674 c0032674
000002c0: c0032674 c0032674 c0032674 c0032674  c0032674 c0032674 c0032674 c0032674
000002e0: c0032674 c0032674 00000000 00000000  00000000 00000000 00000000 00000000
00000300: e59fd0e4 e24ee004 e58de000 e10fe000  e58de004 e3a0d093 e161f00d e21ee00f
00000320: 059fe004 159fe004 e1b0f00e c0032b40  c0032660 00000000 00000000 00000000
00000340: e59fd0a0 e58de000 e10fe000 e58de004  e3a0d093 e161f00d e20ee00f e79fe10e
00000360: e1b0f00e c0032ae0 c003269c c003269c  c00328e0 c003269c c003269c c003269c
00000380: c003269c c003269c c003269c c003269c  c003269c c003269c c003269c c003269c
000003a0: c003269c 00000000 00000000 00000000  00000000 00000000 00000000 00000000
000003c0: e25ef004 eafffffe 00000000 00000000  00000000 00000000 00000000 00000000
000003e0: c0032c40 c0124a64 c0124a70 c0124a7c  00000000 00000000 00000000 00000000
00000400: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00000420: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00000440: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00000460: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
00000480: 00000000 00000000 00000000 00000000  00000000 00000000 00000000 00000000
000004a0: 00000000 00000000 00000000 00000000  00000000 00000000
Internal error: Oops: 0
CPU: 0
pc : [<c000840c>]    lr : [<c00fdda4>]
sp : c00418c0  ip : c00083e8  fp : c0123fc0
r10: c0123fe4  r9 : 00015040  r8 : 4401a103
r7 : c0124a88  r6 : c013e150  r5 : c013e0e8  r4 : c013f538
r3 : c01248c4  r2 : 0000001a  r1 : 80000053  r0 : c003e900
Flags: nZCv  IRQs off  FIQs off  Mode IRQ_32  Segment kernel
Control: 517D  Table: 0000517D  DAC: 0000001D
Process swapper (pid: 0, stackpage=c0123000)
Stack: invalid kernel stack pointer c0123fc0
Backtrace: invalid frame pointer c0123fc0
Code: pc not in code space
Kernel panic: Attempted to kill the idle task!
In idle task - not syncing
....