need Open PIC infos

need Open PIC infos

[Benjamin Herrenschmidt]

Hi !

I'm working on support for new UMA machines (beginning with iBook). I
have already figured out a lot of things and am now coding a very
preliminary support (I'm not sure yet the PMU99 will work out of the box
or not, but it looks similar to the old PMU from an interface point of view).

However, the new Apple ASICs contains an Open PIC interrupt controller
(advertised as beeing a "chrp,open-pic" controller). After looking at the
various docs I have and a quick search on Altavista, I couldn't find any
relevant documentation on the chip.
There's already some OpenPIC support in the kernel, but I'll have to
change it a little bit since, for example, Apple hardware is not a good
place to search for a 8259 master ;)
I'd like some docs in order to have better understanding of the chip.

Anyone knows if such a doc exist ? Apparently, if the register map is not
completely bogus, the current code returns an OpenPIC versio 1.2, and the
timer freq is 0x80000000 (ouch !). 

Side note: the Keylargo IC contains the open-pic and the SCC cells at the
exact same location as Hydra, things don't change so much ;) But the new
chip contains a lot new things.

The Uni-North is a rather weird beast. It appears in the device tree as 4
devices on the root level:

 /uni-n (the memory controller part)
 /pci
    /agp stuffs
    /ATI
 /pci
    /mac-io (KeyLargo is here)
    /usb
    (/slots ?)
 /pci
    /ethernet
    (/firewire on some machines)

All 3 "pci" nodes corresponding apparently to the various internal
busses: the AGP, the ethernet/firewire, and the mac-io/usb, I beleive the
external pci is on the mac-io/usb part).
The annoying thing is that all the 3 pci nodes have the same bus number.
(devices below those have various non-conflicting device number) but all
3 has different pairs of registers to access config space. This makes the
config access code a bit weird since it has to lookup the OF node of the
device in the device tree, get the parent "pci" node, etc... but It
should work this way.

-- 
           E-Mail: <mailto:bh40@calva.net>
BenH.      Web   : <http://calvaweb.calvacom.fr/bh40/>


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: need Open PIC infos

[Geert Uytterhoeven]

On Sat, 16 Oct 1999, Benjamin Herrenschmidt wrote:
> However, the new Apple ASICs contains an Open PIC interrupt controller
> (advertised as beeing a "chrp,open-pic" controller). After looking at the
> various docs I have and a quick search on Altavista, I couldn't find any
> relevant documentation on the chip.
> There's already some OpenPIC support in the kernel, but I'll have to
> change it a little bit since, for example, Apple hardware is not a good
> place to search for a 8259 master ;)
> I'd like some docs in order to have better understanding of the chip.

The i8259 slaves are not mandatory in OpenPIC.

Do you have the OpenPIC docs? They are somewhere on the AMD website. If you
can't find them, please ask me, I have a copy on my docs CD-ROM, as usual :-)

Greetings,

						Geert

--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint-Stevens-Woluwestraat 55
Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: need Open PIC infos (and more)

[Gabriel Paubert]

On Sat, 16 Oct 1999, Benjamin Herrenschmidt wrote:

> 
> Hi !
> 
> I'm working on support for new UMA machines (beginning with iBook). I
> have already figured out a lot of things and am now coding a very
> preliminary support (I'm not sure yet the PMU99 will work out of the box
> or not, but it looks similar to the old PMU from an interface point of view).

Great (and sorry for the delay in answering).

> However, the new Apple ASICs contains an Open PIC interrupt controller
> (advertised as beeing a "chrp,open-pic" controller). After looking at the
> various docs I have and a quick search on Altavista, I couldn't find any
> relevant documentation on the chip.
> There's already some OpenPIC support in the kernel, but I'll have to
> change it a little bit since, for example, Apple hardware is not a good
> place to search for a 8259 master ;)

I don't know on which board the 8259 is a master of the OpenPIC. On CHRP
boards and Motorola with Raven or Hawk chipsets, the 8259 is the slave 
connected on interrupt 0 of the OpenPIC. If you don't have a 8259 on this
input of the OpenPIC then input 0 behaves like any other input and you'll
have to program it as edge/level as per the specification. 

> I'd like some docs in order to have better understanding of the chip.

I have a copy of the pdf which once was on AMD's site. I'm not sure it's
there anymore since the Athlon uses an Intel's like APIC (arghhh!, where
'A' does not mean advanced as some would believe, but Awkward IMNSHO).

Besides this, look for documentation in the Motorola Computer Group 
website about the boards with Raven and Hawk chipsets, for example the
programmer's guide for MVME2600 and MVME2400 (v2?00*pg*.pdf). The
description is more complete than in openpic.pdf, although there are still
bits which can be toggled and are not documented. 

Note that on my machines with OpenPIC I have modified the 8259
interrupt handler to better coexist with the openpic: I have defined
another class of interrupts (struct hw_interrupt_type cascaded_i8259_pic) 
to handle the case of a 8259 behind an OpenPIC in a cleaner way.

I also have a few remarks about 8259 interrupt handling introduced in
2.2.12:

a) the previous code worked perfectly AFAICT, was it changed for any
   compelling reason (more on this in point d below) ? 

b) reading the IRR (masked by the IMR to avoid calling disabled
   interrupts) will work for level triggered interrupt but not necessary
   for edge triggered ISA interrupts because the current code never sets
   the corresponding ISR bit AFAICT. If you read any 8259 documentation, 
   you will find that the edge detection logic is reset only when the ISR
   bit is set (i.e wit a poll command or an interrupt acknowledge cycle):
   this causes a problem if a device generates edge triggered interrupt
   with a low going pulse. 

   Guess what, that's exactly what the standard parallel port does since
   the IRQ line follows the ACK signal from the interface (and also what a
   number of ISA boards do from what I saw on a scope a few years ago);
   this might result in interrupt storms (I can't test it right now but
   will be able soon, just some time to find this damn connector and to
   trigger interrupts).

c) I'm not totally convinced that the are no subtle coherency problems
   with ISA DMA tranfers to main memory: when are the ISA DMA buffers
   flushed in the bridge ? The device who has finished might raise the
   interrupt request while the data is still in the PCI<->ISA bridge, then
   a PCI interrupt acknowledge or a poll command must flush the buffers
   for coherency reasons, I'm not sure only reading the IRR will have the
   same effect (this depends on bridge design details and bugs in this
   area would not be surprising).
   
d) there are actually 2 ways to read the 8259 interrupt vector: use the
   poll method as previously done (although a careful reading of the 8259
   spec shows that the high bit says whether an interrupt is present or
   not: no need to perform additional checks for spurious interrupts) or
   performing an access to the address which translates the access into 
   a PCI interrupt acknowledge cycle. MPC105/106.../GG2/Raven/Hawk
   also support this method, so why not use it ? I've used both and they
   work fine for me, of course I'm not sure that they will work perfectly
   for everybody. 

 
Note that I always rated the 8259 as the worst ever designed chip
(especially if you factor in the complexity/functionality ratio)..., until
Intel succeeded in surpassing themselves with the IO-APIC :-)

> Anyone knows if such a doc exist ? Apparently, if the register map is not
> completely bogus, the current code returns an OpenPIC versio 1.2, and the
> timer freq is 0x80000000 (ouch !).

The version number looks correct, but are you sure of the timer frequency
address ?  0x80000000 is the power up value of all the vector/priority
registers while the power up value of the timer frequency is 0, so this
looks suspiscious.

 
> Side note: the Keylargo IC contains the open-pic and the SCC cells at the
> exact same location as Hydra, things don't change so much ;) But the new
> chip contains a lot new things.
> 
> The Uni-North is a rather weird beast. It appears in the device tree as 4
> devices on the root level:
> 
>  /uni-n (the memory controller part)
>  /pci
>     /agp stuffs
>     /ATI
>  /pci
>     /mac-io (KeyLargo is here)
>     /usb
>     (/slots ?)
>  /pci
>     /ethernet
>     (/firewire on some machines)
> 
> All 3 "pci" nodes corresponding apparently to the various internal
> busses: the AGP, the ethernet/firewire, and the mac-io/usb, I beleive the
> external pci is on the mac-io/usb part).

It must be on same (sub)part as the key-largo (otherwise you would need 2
PCI buses, which means even more pins...).

> The annoying thing is that all the 3 pci nodes have the same bus number.
> (devices below those have various non-conflicting device number) but all
> 3 has different pairs of registers to access config space. This makes the
> config access code a bit weird since it has to lookup the OF node of the
> device in the device tree, get the parent "pci" node, etc... but It
> should work this way.

Oh well, as long as the RTAS handles this properly... 
And why make things simple when they can be made awkward ? 

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: need Open PIC infos (and more)

[Benjamin Herrenschmidt]

On Fri, Oct 22, 1999, Gabriel Paubert <paubert@iram.es> wrote:

>I don't know on which board the 8259 is a master of the OpenPIC. On CHRP
>boards and Motorola with Raven or Hawk chipsets, the 8259 is the slave 
>connected on interrupt 0 of the OpenPIC. If you don't have a 8259 on this
>input of the OpenPIC then input 0 behaves like any other input and you'll
>have to program it as edge/level as per the specification. 

That's what I figured out. One problem I have is that I don't know which
interrupts are level and which are edge triggered (looks like this
information is not in the device tree, or not where I looked for it).
Also, the initialisation code of the OpenPIC hangs when trying to
initialize interrupt 48. The PIC tells it has 64 interrupts (it's a 1.2
OpenPIC revision, I correctly get the MacOS-initialised NMI on interrupt
55 when pressing cmd-power). I didn't look in more details yet (that's
why I was asking for the doc ;)

>I have a copy of the pdf which once was on AMD's site. I'm not sure it's
>there anymore since the Athlon uses an Intel's like APIC (arghhh!, where
>'A' does not mean advanced as some would believe, but Awkward IMNSHO).

I didn't find anything on the AMD site, but Douglas Godfey sent it to me.

>Besides this, look for documentation in the Motorola Computer Group 
>website about the boards with Raven and Hawk chipsets, for example the
>programmer's guide for MVME2600 and MVME2400 (v2?00*pg*.pdf). The
>description is more complete than in openpic.pdf, although there are still
>bits which can be toggled and are not documented. 

I'll look into those, thanks.

>Note that on my machines with OpenPIC I have modified the 8259
>interrupt handler to better coexist with the openpic: I have defined
>another class of interrupts (struct hw_interrupt_type cascaded_i8259_pic) 
>to handle the case of a 8259 behind an OpenPIC in a cleaner way.

Are those in your MVME patches ? (Could you remind me the URL ?)

>The version number looks correct, but are you sure of the timer frequency
>address ?  0x80000000 is the power up value of all the vector/priority
>registers while the power up value of the timer frequency is 0, so this
>looks suspiscious.

That what the current code returns, but I'll do some xmon hacking this
week end to figure this out. Since the open-pic is inside Apple's ASIC,
it's possible that they actually changed the register layout, moved the
interrupt vectors down and removed the timer (this may also explain why
the init code hangs). Also, they do have a separate timer node in the
device tree (different from the openpic node and from the VIA node, but
still inside the Keylargo ASIC).

>It must be on same (sub)part as the key-largo (otherwise you would need 2
>PCI buses, which means even more pins...).

Yes, I think so too, but I'll have to check this on an iMac or a G4 (the
iBook doesn't have any other PCI chip).

>Oh well, as long as the RTAS handles this properly... 

But with BootX, we don't have RTAS ! (I didn't manage to rip off MacOS
RTAS instance). That's one of the reason I think BootX is not a good idea
for newworld machines. Once I've finished this support, I plan to do some
new booter work, basically with something based on miBoot for old-world
buggy OF machines and install CDs, and an OF booter for all of us. I
already have tons of ideas, I just lack time ;)

>And why make things simple when they can be made awkward ? 

;)

Ok, back to code now...


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: need Open PIC infos (and more)

[Gabriel Paubert]

On Fri, 22 Oct 1999, Benjamin Herrenschmidt wrote:

> On Fri, Oct 22, 1999, Gabriel Paubert <paubert@iram.es> wrote:
> 
> >I don't know on which board the 8259 is a master of the OpenPIC. On CHRP
> >boards and Motorola with Raven or Hawk chipsets, the 8259 is the slave 
> >connected on interrupt 0 of the OpenPIC. If you don't have a 8259 on this
> >input of the OpenPIC then input 0 behaves like any other input and you'll
> >have to program it as edge/level as per the specification. 
> 
> That's what I figured out. One problem I have is that I don't know which
> interrupts are level and which are edge triggered (looks like this
> information is not in the device tree, or not where I looked for it).

It should be somewhere, how do  your interrupt cells look like ? (one or 2
entries) Otherwise maybe the firmware sets them corectly and you don't
have to change them.

> Also, the initialisation code of the OpenPIC hangs when trying to
> initialize interrupt 48. The PIC tells it has 64 interrupts (it's a 1.2
> OpenPIC revision, I correctly get the MacOS-initialised NMI on interrupt
> 55 when pressing cmd-power). I didn't look in more details yet (that's
> why I was asking for the doc ;)

I thought that this was specified in the interrupt property of each device
and of the parent bus node but I can't find the reference right now. I'm
no more using OF (unfortunately) and the one I had on my machines was
truly awful (there was no pci interrupt routing information AFAIR, no
RTAS, the entry for the interrupt controller was mpic@1f when it should
have been mpic@0, etc...)

> >Note that on my machines with OpenPIC I have modified the 8259
> >interrupt handler to better coexist with the openpic: I have defined
> >another class of interrupts (struct hw_interrupt_type cascaded_i8259_pic) 
> >to handle the case of a 8259 behind an OpenPIC in a cleaner way.
> 
> Are those in your MVME patches ? (Could you remind me the URL ?)

Yes, they are there (along with other things): 

	ftp://vlab1.iram.es/linux-2.2/*patch*

> That what the current code returns, but I'll do some xmon hacking this
> week end to figure this out. Since the open-pic is inside Apple's ASIC,
> it's possible that they actually changed the register layout, moved the
> interrupt vectors down and removed the timer (this may also explain why
> the init code hangs). Also, they do have a separate timer node in the
> device tree (different from the openpic node and from the VIA node, but
> still inside the Keylargo ASIC).

Then they can't claim it's chrp,openpic of anything similar...

> But with BootX, we don't have RTAS ! (I didn't manage to rip off MacOS
> RTAS instance). That's one of the reason I think BootX is not a good idea
> for newworld machines. Once I've finished this support, I plan to do some
> new booter work, basically with something based on miBoot for old-world
> buggy OF machines and install CDs, and an OF booter for all of us. I
> already have tons of ideas, I just lack time ;)

I lack time too. And I've never used a Mac. Still planning to buy a PB...

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: need Open PIC infos

[Troy Benjegerdes]

Benjamin Herrenschmidt wrote:
> 
> Hi !
> 
> I'm working on support for new UMA machines (beginning with iBook). I
> have already figured out a lot of things and am now coding a very
> preliminary support (I'm not sure yet the PMU99 will work out of the box
> or not, but it looks similar to the old PMU from an interface point of view).
> 
> However, the new Apple ASICs contains an Open PIC interrupt controller
> (advertised as beeing a "chrp,open-pic" controller). After looking at the
> various docs I have and a quick search on Altavista, I couldn't find any
> relevant documentation on the chip.
> There's already some OpenPIC support in the kernel, but I'll have to
> change it a little bit since, for example, Apple hardware is not a good
> place to search for a 8259 master ;)
> I'd like some docs in order to have better understanding of the chip.
> 
> Anyone knows if such a doc exist ? Apparently, if the register map is not
> completely bogus, the current code returns an OpenPIC versio 1.2, and the
> timer freq is 0x80000000 (ouch !).

You might try the programmers manual for the Motorola MTX series
motherboard, which has an OpenPIC (and an 8259, unfortunately). I believe
arch/ppc/kernel/openpic.c is a mostly complete implementation. Last I
checked (about kernel 2.2.5 or so) the only major thing missing was some
interprocessor interrupt support.

If you haven't already, you might check out the PReP and CHRP specific
kernel code, since both CHRP and some PReP machines use it.

Hope this helps. 

Troy-- Anxiously awaiting a Sawtooth G4 to start hacking on

-- 
--------------------------------------------------------------------------
| Troy Benjegerdes    |  troy@blacklablinux.com    |    hozer@drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/