Subject: Re: Flash upload to ebsa285

From: Russell King <[email-masked]>
Date: Thu, 11 Feb 1999 21:59:53 +0000 (GMT)

Dave Baukus said:
> 	Other problems include:
> 		- the PCI code does not assign IO or Mem addresses to PCI devices

Correct.  This should be done by a boot loader and not the kernel.  The Linux kernel
was never intended to boot up a system.

> 		- there are some assumptions in the PCI inerrupt mapping that didn't
> 		work for me.vPCI interupt mapping seems to assume that the ebsa board 
> 		is in the system slot of my PCI backplane (slot 3 has the same 
> 		interupt mapping as the system slot).

These aren't assumptions.  The fact of PCI is that there are at the most 4 interrupts.
On each card, these are labelled INTA, INTB, INTC, and INTD.  The mapping between
the physical connections on the motherboard and the slots is motherboard dependent,
but normally you have something like:

		System   Slot 1    Slot 2     Slot 3
		  A        B          C         D
		  B        C          D         A
		  C        D          A         B
		  D        A          B         C

Cards normally drive INTA, the first row.  Hence, if you plug the EBSA285 into the
system slot and a card into slot 1, then it's interrupt will normally be on System's
B.  However, if you plug the EBSA285 into slot 3, ut appears on C.

Therefore, if you don't plug the EBSA285 into the correct slot, it will not work, and
there's nothing that the kernel can really do at the moment.

This sort of stuff is normally handled by the machine's BIOS, and the results are
stored into the configuration registers on each card.

--
Russell King ([email-masked])
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Philip Blundell <[email-masked]>
Date: Fri, 12 Feb 1999 11:53:08 +0000

Russell King wrote:

>These aren't assumptions.  The fact of PCI is that there are at the most 4 
>interrupts.  On each card, these are labelled INTA, INTB, INTC, and INTD.

This is a slight oversimplification.  There are at most 4 interrupt outputs 
per PCI device, but in theory at least it would be possible for each one of 
these to attach to a separate input on the IO-APIC or whatever.

The "rotating irqs" scheme that you illustrated is a common compromise but 
it doesn't have to be done that way.  So yes, the kernel *does* contain 
assumptions about the wiring of the backplane but you're right that it has no 
way to know what the hardware looks like.

A slightly cleaner way to deal with this is the scheme that's used on CATS 
boards where the knowledge about the hardware layout is in the firmware rather 
than the kernel.  Of course this still doesn't allow you to take an EBSA-285, 
plug it into any slot in a random backplane with unknown wiring and have it 
work.  The only way to achieve that would be to autoprobe for IRQs which is 
generally considered bad form on PCI systems.

The advantage to putting the knowledge about routing in the kernel on the 
other hand is that it allows you to take four EBSA-285s, stick them in a 
passive backplane with one as the configuration master and the others as 
slaves, and they can all work out the interrupt mapping from one card to 
another.

p.

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Fri, 12 Feb 1999 14:41:57 +0000 (GMT)

> these to attach to a separate input on the IO-APIC or whatever.

This doesn't seem to relate in any way to that which Phil has quoted.  In fact,
it seems to be agreeing totally with it, so where 'oversimplification' comes
in I have no idea.
   _____
  |_____| ------------------------------------------------- ---+---+-
  |   |        Russell King       [email-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]