That is some interesting info. I am curious if there is any info on 
controlling LEDs in front of the Qube2? I know they are sw controlled 
because boot loader blinks them during boot.

Regards,
Alex


Byron Servies wrote:
> Hi,
> 
> I found the following on an internal web site and received permission to 
> publish it.  Actually, I've tried to send it to this list about 4 times 
> now from 2 different accounts without success.  Let's see if it comes 
> through this time as plain text, instead of as an HTML attachement...
> 
> I'm also looking for additional information on the Qube2/RaQ2 
> internally.  There was a question recently about how the PCI interrupt 
> pins were connected, for example, and if I can find someone who still 
> has the schematics, I'll ask.
> 
> 
> === cut here ===
> 
>     2700/2800 Interrupt Overview
> 
> This note describes some of the features of the interrupt model for the
> Cobalt 2700/2800
> systems. This is based on investigation performed while tracking down
> various bugs in
> the Cobalt kernel, and is not a complete coverage. Rather this is just a
> note intended to
> assist future engineers who might stumble into the same code base and
> wonder about the
> framework.
> 
> Hardware Interrupt processing overview
> 
> The MIPS processor provides 6 hardware interrupts, and two software
> interrupts, which are
> controlled by bits in the CPU status register and cause register. The
> cause register reflects
> current interrupt state, and the status register included a mask to
> enable interrupts. There
> is also a NMI ("Non-Maskable Interrupt") that has a separate vector.
> 
> The hardware interrupts are connected to devices on the various boards,
> with the following
> breakdown by Cobalt platform:
> 
> Qube 1:
> H/W int0 : Galileo CPU Interrupt (pin 61)
> H/W int1 : Coprocessor Interrupt
> H/W int2 : Ethernet Int.
> H/W int3 : Spare
> H/W int4 : Via Intr (pin 145)
> H/W int5 : Galileo PCI Interrupt (pin 196)
> H/W NMI : Via NMI (Pin 146)
> 
> Raq1:
> H/W int0 : Galileo CPU Interrupt (pin 61)
> H/W int1 : Ethernet Int.
> H/W int2 : 2nd Ethernet Int.
> H/W int3 : serial intr
> H/W int4 : Via Intr (pin 145)
> H/W int5 : Galileo PCI Interrupt (pin 196)
> H/W NMI : Via NMI (Pin 146)
> 
> Cube2/Raq2:
> H/W int0 : Galileo CPU Interrupt (pin 61)
> H/W int1 : Ethernet Int.
> H/W int2 : 2nd Ethernet Int.
> H/W int3 : serial intr
> H/W int4 : Via Intr (pin 145)
> H/W int5 : Galileo PCI Interrupt (pin 196)
> H/W NMI : Via NMI (Pin 146)
> 
> The Galileo and Via interrupts on lines 0 and 4, are signaled to the
> processor when any of the
> variety of devices below these chips needs an interrupt. The processor
> then needs to deal with
> the underlying condition, which should be documented elsewhere. This
> document will only
> describe how the Via or Galileo interrupt routine is invoked.
> 
> The Galileo interrupt on line 5 is odd. This is supposed to be directed
> at the PCI bus, in case the
> procesor wants to generate an interrupt on some PCI device. Anyone who
> wants to suggest a
> reason for this configuration is welcome.
> 
> The remaining interrupts are pretty obvious, but it should be noted that
> the interrupts shuffle
> around some between the various systems.
> 
> IRQ Interrupts
> 
> Intel PC systems use an entirely different interrupt mechanism with
> IRQ's (Interupt Request).
> Since the Linux software and PCI interfaces are coded to this model, the
> MIPS kernel provides
> some glue to connect the PCI hardware and device programming model
> through the non-IRQ
> based processor model.
> 
> PCI devices can be configured to use a particular IRQ. An Intel
> processor then uses this IRQ to
> locate the particular interrupt routine.
> 
> Some systems support IRQ's that are assigned during system boot,
> typically by the BIOS, which
> reads the configuration from CMOS, or performs some autoconfiguration
> heuristic (plug and pray).
> Other systems hardwire particular devices to certain IRQ's.
> 
> Cobalt PCI Configuration Space Identifiers
> 
> Each device on the PCI bus is identified during configuration I/O by
> physical wiring. The Galileo
> uses one high order address lines per device, as described in Section
> 6.4 PCI Master Configuration
> of the Galileo specification.
> 
> Fortunately, the device ids are wired consistently, although it has lead
> to a number of manifest
> constants in the system, rather than a generalized probe model. The
> specific mapping for each
> board is as follows:
> 
> AD16 == device 6 connects to CPU select
> AD17 == device 7 connects to Ethernet 0
> AD18 == device 8 connects to SCSI (Raq/Raq2)
> AD19 == device 9 connects to Via
> AD20 == device 10 connects to PCI Slot 0 (Qube/Qube2)
> AD22 == device 12 connects to 2nd Ethernet (Qube2/Raq2)
> 
> Reference:
> Cube2 - 2800 I/O skematic, sheet 4
> Raq2 - Raq2 skematic, sheet 9
> Raq - Raq skematic, sheet 9
> Cube1- Cube 1 I/O skematic, sheet 7
> 
> Cobalt VIA Interrupt Wiring
> 
> The VIA chip is designed to operate in a Intel interrupt model by
> collecting external interrupt sources
> and forwarding the interrupt on to the processor. The VIA currently
> operates in a hardwired model,
> with particular secondary devices wired directly to certain VIA
> interrupt pins.
> 
> These differ among the various system boards as follows:
> 
> RaQ-1
> IRQ 3 : SMI
> IRQ 4 : SCSI Interrupt
> IRQ 14 : IDE Interrupt
> 
> RaQ-1
> IRQ 3 : SMI
> IRQ 4 : SCSI Interrupt
> IRQ 14 : IDE Interrupt
> IRQ 15 : 2nd IDE Interrupt
> 
> Cube-1
> IRQ 3 : SMI
> IRQ 4 : Serial Interrupt
> IRQ 6 : rlng Interrupt ??? (ringInt?)
> IRQ 9 : PCI Slot Interrupt
> IRQ 14 : 2nd IDE Interrupt
> 
> Cube-2
> IRQ 3 : SMI
> IRQ 9 : PCI Slot Interrupt
> IRQ 14 : IDE Interrupt
> 
> When the VIA interrupts, the kernel VIA driver reads a register to find
> the underlying interrupt source,
> and the cooresponding device interrupt is invoked.
> 
> Software PCI configuration:
> 
> The device drivers are configured through a PCI abstraction layer that
> linux forwards to the Cobalt specific
> pci routines in cobalt/pci.c. These routines initialize the PCI
> configuration space so that the various device
> drivers can use the common interface.
> 
> The PCI specification defines a number of configuration parameters, and
> the following are synthesized by
> the Cobalt kernel
> PCI_INTERRUPT_LINE
> PCI_COMMAND
> tulip |= PCI_COMMAND_IO | PCI_COMMAND_MASTER
> pci slot |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER
> scsi |= PCI_COMMAND_IO | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY
> | PCI_COMMAND_INVALIDATE
> PCI_BASE_ADDRESS_0[0] to [20] ref as 6 longs
> PCI slot
> PCI_BASE_ADDRESS_SPACE_IO means alloc from 0x10108000
> else alloc from membase 0x12000000
> 
> tulip eth1 I/O sets PCI_BASE_ADDRESS_0 to 0x10101001
> 
> SCSI sets
> PCI_BASE_ADDRESS_0, 0x10102001
> PCI_BASE_ADDRESS_1, 0x00002000
> PCI_BASE_ADDRESS_2, 0x00100000
> PCI_VENDOR_ID
> PCI_BIST
> Used for PCI slot, only
> 
> PCI_LATENCY_TIMER - for dev 0 (galileo?) set to 64
> PCI_CACHE_LINE_SIZE for dev 0 set to 7
> 
>