Port-ofppc archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Powerstack II



Jochen Kunz wrote:

>> There is no problem with io space at all. It's the mem space which
>> doesn't work.
> Maybe a problem with address mapping? (IIRC CPU address 0x80000000 gets
> maped to PCI memory address 0x00000000.)

I'm no PCI bus expert, but AFAIK the PCI base address registers for memory
space will contain the real physical addresses from the CPU's point of
view. At least this is what I see on my Pegasos and PowerMac.

And there is also a BAT mapping for 0x80000000 and 0xc0000000. What else can
I do?

With ethernet and SCSI devices disabled I managed to reach ask-root and
entered ddb. There I could inspect all the memory, and indeed everything
between 0xc0000000 and 0xc1000000 was filled with 0xff. Accessing
0xc1000000 gave me an accesss fault, though.


> I meant to disable the on board RAM in esiop(4).

Ah, ok, tried that now. And I also forced esiop(4) into io space. But the
SCSI bus probing still doesn't return.

I found out that the kernel hangs in config_finalize() waiting for
config_pending going zero, which probably doesn't happen because of endless
bus probing.


>> >> But when I'm configuring the ethernet device to I/O space to make
>> >>  it ork, I receive a single IRQ 11.
>> > In this case you got farer then I was ever.
>> Not really. ;)
> I didn't get interrupts. So you are one step ahead of me.

For ISA devices interrupts are working fine. I get serial interrupts (irq 4)
handled perfectly. But as soon as I get an irq 11 from the tlp(4) device
acknowledging the interrupt doesn't seem to work and the interrupt handler
is called again and again, freezing the system.


I'm running out of ideas. I also didn't find anything about PCI memory
problems with the Powerstack or 82660 on the net. And there is no special
Powerstack handling in the Linux source either... *sigh*

-- 
Frank Wille



Home | Main Index | Thread Index | Old Index