headers
Jochen Kunz | 3 Jun 2003 21:59
Picon

Interrupt interaction with OFW properties.

Hi. 

I am working on the MD code to make port-ofppc run on the Motorola
PowerStack II. PCI and ISA attachments are working, now I am on the
interrupt handling stuff. (See my post of a dmesg to port-prep
recently.) 

As Matt Thomas sugested I pulled pci_attach_hook() / fixpci() /
find_node_intr() from sys/arch/macppc/pci/pci_machdep.c and integrated
this into my sys/arch/ofppc/motorola/powerstackII_pci.c. The OFW on the
PowerStack II disables all PCI devices by default. This code sets
PCI_COMMAND_STATUS_REG and PCI_INTERRUPT_REG of each PCI device
according to the OFW properties, thus enabling the device. 

The code from macppc queries for the property "AAPL,interrupts". Is this
somthing special to macppc? The OFW on the PowerStack II has the
property "interrupts" and the OFW-PCI binding talks about "interrupts"
too. Or is there some special semantic behind the ","? 

The OFW "interrupts" property is allways 1 for all PCI devices, so the
PCI attach code gets "IRQ 1" for all PCI devices. If I don't use the
find_node_intr() function and leave PCI_INTERRUPT_REG untouched, the
devices get the correct interrupt. (I know the interrupt routing of that
machine from the Linux source linux/arch/ppc/kernel/prep_pci.c,
Utah_pci_IRQ_map[] and Utah_pci_IRQ_routes[]). So it looks to me like
the OFW initializes the PCI_INTERRUPT_REG correct, but doesn't supply a
correct "interrupts" property. Correct? Or is there somthing else I
don't know already. 
--

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bill Studenmund | 3 Jun 2003 23:40
Picon

Re: Interrupt interaction with OFW properties.

On Tue, 3 Jun 2003, Jochen Kunz wrote:

> The code from macppc queries for the property "AAPL,interrupts". Is this
> somthing special to macppc? The OFW on the PowerStack II has the
> property "interrupts" and the OFW-PCI binding talks about "interrupts"
> too. Or is there some special semantic behind the ","?

"AAPL," means it's an Apple thing. "AAPL,interrupts" is a property that
lists the interrupt pin on many Apple models.

> The OFW "interrupts" property is allways 1 for all PCI devices, so the
> PCI attach code gets "IRQ 1" for all PCI devices. If I don't use the
> find_node_intr() function and leave PCI_INTERRUPT_REG untouched, the
> devices get the correct interrupt. (I know the interrupt routing of that
> machine from the Linux source linux/arch/ppc/kernel/prep_pci.c,
> Utah_pci_IRQ_map[] and Utah_pci_IRQ_routes[]). So it looks to me like
> the OFW initializes the PCI_INTERRUPT_REG correct, but doesn't supply a
> correct "interrupts" property. Correct? Or is there somthing else I
> don't know already.

Sounds like the OFW settings aren't set up right, or they are instead
indicating if a device has an interrupt, not what line it's on.

Take care,

Bill
Permalink | Reply | 1 comment |
headers
Erik E. Fair | 3 Jun 2003 23:53
Picon

Re: Interrupt interaction with OFW properties.

AAPL is Apple Computer's NASDAQ stock market symbol.

	Erik <fair <at> netbsd.org>
Permalink | Reply | 0 comments |
headers
Jochen Kunz | 4 Jun 2003 09:04
Picon

Re: Interrupt interaction with OFW properties.

On 2003.06.03 23:40 Bill Studenmund wrote:

> "AAPL," means it's an Apple thing. "AAPL,interrupts" is a property
> that lists the interrupt pin on many Apple models.
OK. So "interrupts" is correct.

> Sounds like the OFW settings aren't set up right, or they are instead
> indicating if a device has an interrupt, not what line it's on.
Hmm. 
[diging trough the OFW-PCI binding]
Sometimes I feel stupid. I should have done this earlier. The
"interrupts" property informs about the interrupt pin the device is
using. 1 means INTA, ... 4 is INTD. This basicly means that I can throw
out find_node_intr() completely. 
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Permalink | Reply | 0 comments |
headers
Aymeric Vincent | 25 Jun 2003 21:21
Picon

ofwboot problems on ofppc


        Hi,

we are currently trying together with a friend to run NetBSD/ofppc
under psim.

Among the many weird things that we see, one of the easiest to fix
seems to be ofwboot.

However, the OF_seek() function in ofppc/stand/ofwboot/Locore.c takes
a u_quad_t as parameter, and can't printf() the right value it gets
passed (noticed because it passes bad values to the openfirmware).

Does it ring a bell to anyone?

I tried the following things:

- compile with -mno-multiple, with -O, with -O2, with -ffreestanding
  -> no change
- compile with no optimization -> ofwboot crashes (!)
- ofdev.c which calls OF_seek() in strategy() lacked the "openfirm.h"
#include, but even with it included, it changes nothing.

Loading the kernel directly works but fails miserably, whichever
executable we give it instead of init: e.g. :

root device: ofdisk0c
ofdisk0c
dump device (default ofdisk0b):
(Continue reading)

Permalink | Reply | 6 comments |
headers
Andrew Brown | 26 Jun 2003 15:25

Re: ofwboot problems on ofppc

>...
>Loading the kernel directly works but fails miserably, whichever
>executable we give it instead of init: e.g. :
>
>root device: ofdisk0c
>ofdisk0c
>dump device (default ofdisk0b): 
>
>file system (default generic): 
>
>root on ofdisk0c dumps on ofdisk0b
>root file system type: cd9660
>init path (default /sbin/init): /rescue/date
>/rescue/date
>init: trying /rescue/date
>panic: init died (signal 0, exit 0)
>Stopped in pid 1.1 (date) at    0x1c9684:       lwz     r0, r1, 0x14
>db> 
>
>I suspect "init" could be passed bad arguments just because the kernel
>doesn't get them from ofwboot, and that's why I'm trying harder to
>make ofwboot work.

it might be arguments, but if you note the exit status of "init" (aka
date), it's 0.  that typically means it completed successfully.
perhaps you were expecting to see output, but you fail to realize one
of the things that makes init special.  init expects to be init and
opens /dev/console.  date doesn't do this, so any output from it is
lost.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Aymeric Vincent | 26 Jun 2003 19:13
Picon

Re: ofwboot problems on ofppc


Andrew Brown <atatat <at> atatdot.net> writes:

> it might be arguments, but if you note the exit status of "init" (aka
> date), it's 0.  that typically means it completed successfully.
> perhaps you were expecting to see output, but you fail to realize one
> of the things that makes init special.  init expects to be init and
> opens /dev/console.  date doesn't do this, so any output from it is
> lost.

You are right. BTW, it's time for an update: hardcoding the boot
parameters in the kernel allows us to boot into single-user mode
successfully (and certainly also to multi-user mode).

The only mystery that remains is why ofwboot can't pass around
u_quad_t's successfully.

Thanks,
 Aymeric
Permalink | Reply | 2 comments |
headers
Aymeric Vincent | 26 Jun 2003 22:57
Picon

Re: ofwboot problems on ofppc


Aymeric Vincent <Aymeric.Vincent <at> labri.fr> writes:

> The only mystery that remains is why ofwboot can't pass around
> u_quad_t's successfully.

Actually the problem was in strategy(): because it was defined in K&R
form, its daddr_t argument was passed wrong.

This is now fixed in -current by a set of patches that clean up
ofwboot a bit.

 Aymeric
Permalink | Reply | 0 comments |

Gmane