headers
Frank Wille | 16 Jan 2010 17:46
Picon

Powerstack II

Hi,

after I fixed a minor problem in ofppc/ofppc/mainbus.c (crash when no /rtas
exists) I can boot a recect kernel on a Motorola Powerstack II as far as
this:

---8<---
NetBSD 5.99.23 (PWRSTK2) #12: Sat Jan 16 16:44:46 CET 2010                  

frank <at> jaana.owl.de:/home/frank/netbsd/current/src/sys/arch/ofppc/compile/obj/PWRSTK2

Model: MOT,PowerStack_II_Pro4000
total memory = 65536 KB
avail memory = 58596 KB
bootpath: /pci/ethernet <at> 4/netbsd
mainbus0 (root)
cpu0 at mainbus0: 604ev (Revision 1.0), ID 0 (primary)
cpu0: HID0 0x8000c086<EMCP,ICE,DCE,SGE,BHT,NOPDST>, powersave: 1
cpu0: 300.00 MHz
cpu0: L1 I-cache 32 KB 0B/line, D-cache 32 KB 0B/line
cpu0: L2 cache 256 KB 0B/line
ofwpci0 at mainbus0
pci0 at ofwpci0 bus 0: OFW method configuration space access
pchb0 at pci0 dev 0 function 0
pchb0: IBM 82660 PowerPC to PCI Bridge and Memory Controller (rev. 0x02)
pchb0: L1: enabled L2: enabled 
pchb0: DRAM EDO (ECC) SRAM async
pcib0 at pci0 dev 1 function 0: Symphony Labs 83C553 PCI-ISA Bridge (rev.
0x10)
pciide0 at pci0 dev 1 function 1: Symphony Labs 82C105 (rev. 0x05)
(Continue reading)

Permalink | Reply |
headers
Jochen Kunz | 17 Jan 2010 18:48
Picon

Re: Powerstack II

On Sat, 16 Jan 2010 17:46:57 +0100
Frank Wille <frank <at> phoenix.owl.de> wrote:

> 1. "pciide0: couldn't map native-PCI interrupt"
> This happens for both channels. By some debugging I found out that
> pci_intr_map() is called to map irq 14, but genofw_setup_pciintr_map()
> didn't provide a dictionary entry for this interrupt line. I think the OFW
> is to blame here, because, although pciide0 is configured native-PCI, it
> doesn't have a device node for it:
Sure. IDE is not supported on that machine. Although the hardware is
available, this hardware is hidden from the OS. This machine was
intended to use SCSI only. Hence no OFW support for IDE. You have to
add quirks to make IDE work.

> 2. "tlp0: sorry, unable to handle your board"
> That's a much bigger problem! Although the 21140A chip is recognized the
> drive is unable to read its SROM. For debugging I have printed the contents
> of the first 40 bytes in sc->sc_srom, but all bytes are 0xff!
> Is this the PCI memory access problem which Jochen Kunz mentioned?
IIRC I had no PCI memory problem. I think once I got an ex(4) to emit
packets because it uses PCI memory only. PCI DMA was the problem.

> 3. "probe(esiop0:0:0:0): command timeout, CDB: 0x12 00 00 00 24 00"
> I didn't really check yet. But I tried with and without hard disk. I'm not
> sure where to terminate the bus. Only at its end?
A SCSI bus needs to be terminated at booth ends of the cable. Without
cable or with a short cable a single terminator should work. Check if
there is a terminator on the mainboard that can be en-/disabled by a
jumper.
--

--
(Continue reading)

Permalink | Reply |
headers
Frank Wille | 17 Jan 2010 20:43
Picon

Re: Powerstack II

Jochen Kunz wrote:

>> 2. "tlp0: sorry, unable to handle your board"
>> That's a much bigger problem! Although the 21140A chip is recognized
>> the drive is unable to read its SROM. For debugging I have printed the
>> contents of the first 40 bytes in sc->sc_srom, but all bytes are 0xff!
>> Is this the PCI memory access problem which Jochen Kunz mentioned?
> IIRC I had no PCI memory problem.

In "http://mail-index.netbsd.org/port-prep/2005/01/16/0006.html" you wrote
about an "obscure" problem accessing the PCI bus. Was it DMA only?

For me it looks like all PCI memory is read as 0xff.

Today I made a test with the tlp(4) driver, which works either with
registers mapped to memory- or i/o-space. It defaults to memory-space, so I
forced i/o-space and it was correctly recognized:
---8<---
tlp0: interrupting at irq 11
tlp0: Ethernet address 08:00:3e:27:xx:xx
nsphy0 at tlp0 phy 8: DP83840 10/100 media interface, rev. 1
nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
tlp0: 10base5
---8<---

In another test I was reading the CSR5 (status) register of tlp and got the
following results:

memory space: 0xffffffff
i/o space: 0xfc660044
(Continue reading)

Permalink | Reply |
headers
Jochen Kunz | 17 Jan 2010 21:01
Picon

Re: Powerstack II

On Sun, 17 Jan 2010 20:43:09 +0100
Frank Wille <frank <at> phoenix.owl.de> wrote:

> In "http://mail-index.netbsd.org/port-prep/2005/01/16/0006.html" you wrote
> about an "obscure" problem accessing the PCI bus. Was it DMA only?
IIRC yes.

> For me it looks like all PCI memory is read as 0xff.
IIRC the chipset only supports PCI IO space. PCI memory space should be
disabled when the PCI bus is attached. There are flags to en-/disable
memory and IO space when the MI PCI bus is attached.

> I have no idea what is going on here.
> Has somebody the 82660 PDF for me? I didn't find it on the net...
http://www.unixag-kl.fh-kl.de/~jkunz/tmp/82660_um.pdf
(I'll remove it tomorow.)

> I didn't find a jumper, but with an active terminator on both ends the error
> message disappears and the system just freezes during scanning the SCSI bus
> (probably because of the PCI memory problems).
Do you get interrupts?
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Permalink | Reply |
headers
Frank Wille | 18 Jan 2010 12:45
Picon

Re: Powerstack II

Jochen Kunz wrote:

>> For me it looks like all PCI memory is read as 0xff.
> IIRC the chipset only supports PCI IO space.

Are you sure? The 82660 seems to support it, as far as I understand the
manual. And what about devices which need PCI mem-space, like a graphics
card?

I also checked the esiop(4) driver and it requires PCI memory at the PCI
mapping register 0x14 as well, or it will fail.

Also the OFW device tree lists memspace ranges. Why should it, when it is
not supported?

> PCI memory space should be
> disabled when the PCI bus is attached. There are flags to en-/disable
> memory and IO space when the MI PCI bus is attached.

IMHO the system will never work without it. :|

>> I have no idea what is going on here.
>> Has somebody the 82660 PDF for me? I didn't find it on the net...
> [...]
> (I'll remove it tomorow.)

Thanks a lot. Got it!

>> I didn't find a jumper, but with an active terminator on both ends the
>> error message disappears and the system just freezes during scanning
(Continue reading)

Permalink | Reply |
headers
Jochen Kunz | 18 Jan 2010 16:43
Picon

Re: Powerstack II

On Mon, 18 Jan 2010 12:45:29 +0100
Frank Wille <frank <at> phoenix.owl.de> wrote:

> > IIRC the chipset only supports PCI IO space.
> Are you sure?
No. It has been some years since I hacked the Powerstack II. I only
remember that there was some limitation. Maybe there was IO space, but
only limited to a small address rage for PeeCee ISA bus style hardware
like com(4), lpt(4), pckbc(4), ...

> > Do you get interrupts?
> From the SCSI host? No.
Hmm. There was something with the on board RAM of esiop(4). I stumbled
over this on port-hp700. Maybe it is worth a try to forceable en- or
disable this. But I suspect this is the "PCI DMA does not work"
phenomenon.

> But when I'm configuring the ethernet device to I/O space to make it
> work, I receive a single IRQ 11.
In this case you got farer then I was ever.
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
Permalink | Reply |
headers
Frank Wille | 18 Jan 2010 17:53
Picon

Re: Powerstack II

Jochen Kunz wrote:

>> > IIRC the chipset only supports PCI IO space.
>> Are you sure?
> No. It has been some years since I hacked the Powerstack II. I only
> remember that there was some limitation. Maybe there was IO space, but
> only limited to a small address rage for PeeCee ISA bus style hardware
> like com(4), lpt(4), pckbc(4), ...

There is no problem with io space at all. It's the mem space which doesn't
work.

>> > Do you get interrupts?
>> From the SCSI host? No.
> Hmm. There was something with the on board RAM of esiop(4). I stumbled
> over this on port-hp700. Maybe it is worth a try to forceable en- or
> disable this.

I didn't find anything in the hp700 source. I cannot disable PCI memory for
esiop(4), as the driver will fail then. At least the dmesg shows that it is
happily using the on-board RAM:

esiop0 at pci0 dev 2 function 0: Symbios Logic 53c825a (fast wide scsi)
esiop0: using on-board RAM
esiop0: interrupting at irq 15
esiop0: alloc new tag DSA table at PHY addr 0x540000

Or do you think about disabling esiop(4) completely? Yes, I tried that. But
the system freezes at the same point. I do not reach the askroot prompt.
(Continue reading)

Permalink | Reply |
headers
Jochen Kunz | 18 Jan 2010 20:04
Picon

Re: Powerstack II

On Mon, 18 Jan 2010 17:53:41 +0100
Frank Wille <frank <at> phoenix.owl.de> 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 didn't find anything in the hp700 source. I cannot disable PCI memory for
> esiop(4), as the driver will fail then. At least the dmesg shows that it is
> happily using the on-board RAM:
I meant to disable the on board RAM in esiop(4).

> I found an old dmesg from one of your tests on the net, and the PCI io/mem
> addresses in the output show that you didn't reconfigure the PCI bus.
Yes. Please note that the whole PCI stuff in port-ofppc has changed
completely since my hacking attempts.

> Very strange, that your tlp(4) configured correctly - maybe you forced
> it to io space?
I know that I could not get tlp(4) to work. I pluged in an ex(4) for
testing.

> >> But when I'm configuring the ethernet device to I/O space to make it
> >> work, 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.
--

--
(Continue reading)

Permalink | Reply |
headers
Frank Wille | 19 Jan 2010 22:23
Picon

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.
(Continue reading)

Permalink | Reply |
headers
Jochen Kunz | 20 Jan 2010 18:21
Picon

Re: Powerstack II

On Tue, 19 Jan 2010 22:23:12 +0100
Frank Wille <frank <at> phoenix.owl.de> wrote:

> 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.
This sounds plausible.

> 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.
Wasn't there somthing to do to acknowledge PCI interrupts? Writing
somthing at some PCI address? Or am I confusing this with the Firepower
machines?

> 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*
So you are now at the same point where I was. Sorry, I can't help you
any further.
--

-- 

tschüß,
       Jochen

Homepage: http://www.unixag-kl.fh-kl.de/~jkunz/
(Continue reading)

Permalink | Reply |
headers
Frank Wille | 22 Jan 2010 16:47
Picon

Re: Powerstack II

Jochen Kunz wrote:

>> 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.
> Wasn't there somthing to do to acknowledge PCI interrupts? Writing
> somthing at some PCI address? Or am I confusing this with the Firepower
> machines?

You're right. The 82660 manual mentions an interrupt acknowledge register at
0xbffffff0. So I might have to use a prepivr-PIC instead of a i8259 PIC to
handle interrupts on this machine.

I changed the code to setup a prepivr PIC and mapiodev'd 0xbffffff0 as
prep_intr_reg. It seems to work so far that the PIC reads the correct IRQ
number from this address, but in the end nothing changed... :|

The pic_ack_irq() doesn't really acknowledge the IRQ and it is still handled
repeatedly. I tried both PIC_IVR_MOT and PIC_IVR_IBM.

--

-- 
Frank Wille
Permalink | Reply |

Gmane