Re: FireWire + Apple PB G3: some success

Re: FireWire + Apple PB G3: some success

[Benjamin Herrenschmidt]

On Fri, Mar 3, 2000, Ryuichi Oikawa <roikawa@rr.iij4u.or.jp> wrote:

>BBTW, I'm new in the MOL source and I need some information/explanation.
>Today I tried to add RageLTPro OF properties to MOL oftree.nw,
>insert it into the pci device tree and mmu map full 16MB aperture
>in thw video driver(on PB G3). I could run the drawing engine within
>MacOS manually, but ATI's extension didn't seem to recognize the chip
>at all. I even tried to load & insert into the driver properties field
>the driver extracted from ATI Driver update file, but no success.
>I don't understand MOL interface mechanism yet(and unfortunately
>my macos complier, symantec c++ doesn't work on recent system).
>
>What is the correct way to accelerate MOL video?

I don't think we can use MacOS ATI accelerator. It's tightly coupled with
the ATI driver (which handles also allocation of fb memory for QuickTime,
YUV overlay, interrupts, etc..) and will certainly break as soon as we
switch MOL console out.

We have to write our own MacOS accelerator using Apple's QD accel APIs.
Unfortunately, those APIs are under NDA and a driver using them can not
be released in source code form. I do have those APIs and I will try to
write some kind of interface layer that sends some of QD commands to MOL
so we can build chip-specific accel modules, but this layer will have to
reside in a non-GPL'd MacOS extension, and I didn't have time to do it yet.

Another possibility is to patch, from a MacOS extension, some QD
functions are directly route them to the emulator instead of using Apple
acceleration hooks.


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

Re: FireWire + Apple PB G3: some success

[Dan Bethe]

--- Benjamin Herrenschmidt <bh40@calva.net> wrote:
>
> On Fri, Mar 3, 2000, Ryuichi Oikawa <roikawa@rr.iij4u.or.jp> wrote:
>
> >BBTW, I'm new in the MOL source and I need some
> information/explanation.
> >Today I tried to add RageLTPro OF properties to MOL oftree.nw,

> Another possibility is to patch, from a MacOS extension, some QD
> functions are directly route them to the emulator instead of using
> Apple
> acceleration hooks.

	I just want to say that I have tremendous respect for anyone who's
even trying this kind of thing.  I bought my Powerbook around March of
1999, with the full intention of running Linux on it as much as humanly
possible.
	If it's significantly easier to implement 3D hardware support in MOL,
than it is to implement it natively in GLX, then I'll support that.
Hopefully it will provide a monitor or even reverse engineering
environment for us to eventually have native support.
	I'm serious, guys.  I invested in this machine for the long haul,
knowing only that at least basic bare functional hardware support
existed for it in LinuxPPC.  I intended to help you guys out as much as
I can, in any way possible.  I just started reading my "humanistic
programming in Applesoft BASIC" book, and I'm learning all about how to
format text I/O  :>  so hopefully I'll soon be able to help implement
LinuxPPC hardware support.
	I provide intrinsic support for anyone who wants to make this thing
kick as much ass as it does in MacOS, and I'm sure we can work out some
kind of extrinsic support as well, such as cash, cookies, pizza, or a
fellow tester.  You name it, and I'm there.

=====
"Don't expect your own messiah; this neverworld which you desire is
only in your mind." -- http://www.dreamtheater.net/songb4.htm#IV5

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

FireWire + Apple PB G3: some success

[Albrecht Dre_]

[I am new to the FireWire list, so please excuse me if this is not new for you.
Sorry, this is a quite long message]

I had some success with Newer Tech's FireWire2Go CardBus device on an Apple
PowerBook G3/333 (aka "Lombard") with LinuxPPC 2.2.14pre9.  This is what I did:

* added Ryuichi Oikawa patch to the kernel which enables the pci scan to "see"
CardBus devices without the PCMCIA package (there is a japanese description at
http://www.rr.iij4u.or.jp/~roikawa/others.html [which I can't read], but the
patch seems to work really fine)

* used the FireWire package for 2.2.14.  As always with LinuxPPC, I had to patch
the pcilynx driver, as OpenFirmware (Apple's "BIOS") does not activate all
devices automatically:

--- snip here -----------------------------------------------------------------
--- pcilynx.c.orig      Wed Feb 23 10:47:21 2000
+++ pcilynx.c   Wed Feb 23 10:52:33 2000
@@ -1212,6 +1212,7 @@
         struct ti_lynx *lynx; /* shortcut to currently handled device */
         unsigned long page;
         unsigned int i;
+       unsigned short w;

         if (num_of_cards == MAX_PCILYNX_CARDS) {
                 PRINT_G(KERN_WARNING, "cannot handle more than %d cards.  "
@@ -1225,7 +1226,8 @@
         lynx->id = num_of_cards-1;
         lynx->dev = dev;

-        pci_set_master(dev);
+       pci_read_config_word (dev, PCI_COMMAND, &w);
+       pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER |
PCI_COMMAND_MEMORY | PCI_COMMAND_IO);

         if (!request_irq(dev->irq, lynx_irq_handler, SA_SHIRQ,
                          PCILYNX_DRIVER_NAME, lynx)) {
--- patch ends here -----------------------------------------------------------

* `modprobe pcilynx' gives the following kernel messages:

kernel: ieee1394: registered pcilynx driver, initializing now
kernel: pcilynx: looking for PCILynx cards
kernel: pcilynx0: allocated interrupt 0
kernel: pcilynx0: allocated PCL memory 65536 Bytes @ 0xc12f0000
kernel: pcilynx0: remapped memory spaces reg 0xd8887000, rom 0xd88ab001, ram
0xd8889000, aux 0xd889a000
kernel: pcilynx0: found 1394a conform PHY (using extended register set)
kernel: pcilynx0: PHY vendor id 0x00c02d
kernel: pcilynx0: PHY product id 0x303562
kernel: pcilynx0: resetting bus on request
kernel: ieee1394: detected 1 pcilynx adapter

* remaining questions:

I have a FW disk attached to the bus, but when I run testlibraw, it is not seen:

[root@tirilap133 src]# ./testlibraw
successfully got handle
current generation number: 0
1 card(s) found
  nodes on bus:  0, card name: pcilynx
using first card found: 0 nodes on bus, local ID is 0

doing transactions with custom tag handler

using standard tag handler and synchronous calls
[root@tirilap133 src]#

Is this normal, or where ist the problem?

Thanks, Albrecht.


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

Re: FireWire + Apple PB G3: some success

[Andreas Bombe]

On Wed, Feb 23, 2000 at 11:24:36AM +0100, Albrecht Dreß wrote:
> I had some success with Newer Tech's FireWire2Go CardBus device on an Apple
> PowerBook G3/333 (aka "Lombard") with LinuxPPC 2.2.14pre9.  This is what I did:
>
> * added Ryuichi Oikawa patch to the kernel which enables the pci scan to "see"
> CardBus devices without the PCMCIA package (there is a japanese description at
> http://www.rr.iij4u.or.jp/~roikawa/others.html [which I can't read], but the
> patch seems to work really fine)

Nice.  So CardBus devices do act like normal PCI devices (except for
scanning, apparantly).

>          lynx->id = num_of_cards-1;
>          lynx->dev = dev;
>
> -        pci_set_master(dev);
> +       pci_read_config_word (dev, PCI_COMMAND, &w);
> +       pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER |
> PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
>
>          if (!request_irq(dev->irq, lynx_irq_handler, SA_SHIRQ,
>                           PCILYNX_DRIVER_NAME, lynx)) {

I see.  That's the missing pci_enable_device() biting us.  But at least
in 2.2 there is no such function anyway, so it has to be done by hand.

> * `modprobe pcilynx' gives the following kernel messages:
>
[...]
> kernel: pcilynx0: resetting bus on request
> kernel: ieee1394: detected 1 pcilynx adapter

The messages for bus reset completion are missing, so it only works
partly.

> * remaining questions:
>
> I have a FW disk attached to the bus, but when I run testlibraw, it is not seen:

It's not seen because the driver is stuck in bus reset.  The most
probable reason is that DMA is not working.  I can't think of a reason
right now (since it does work on another PPC).

--
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44

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

Re: [Linux1394-devel] Re: FireWire + Apple PB G3: some success

[Maxim S. Shatskih]

> It's not seen because the driver is stuck in bus reset.  The most
> probable reason is that DMA is not working.  I can't think of a reason
> right now (since it does work on another PPC).

I've had this problem on NT4. Are you sure that the DMA enable bit in PCI
config space is set?

    Max


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

Re: FireWire + Apple PB G3: some success

[Andreas Bombe]

On Thu, Feb 24, 2000 at 05:44:53AM +0300, Maxim S. Shatskih wrote:
> > It's not seen because the driver is stuck in bus reset.  The most
> > probable reason is that DMA is not working.  I can't think of a reason
> > right now (since it does work on another PPC).
>
> I've had this problem on NT4. Are you sure that the DMA enable bit in PCI
> config space is set?

To quote Albert's patch:

 +       pci_read_config_word (dev, PCI_COMMAND, &w);
 +       pci_write_config_word (dev, PCI_COMMAND, w | PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY | PCI_COMMAND_IO);

He sets the PCI master flag (which should be the only thing disabling /
enabling DMA in general).  In the standard sources pci_set_master() is
used, which does the same.

Setting PCI_COMMAND_IO on the other hand is unneccessary since the
PCILynx only uses memory mapped I/O (if I understand PCI config
correctly).  I don't know if this flag is harmful if there are no I/O
ports.

--
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44

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

Re: FireWire + Apple PB G3: some success

[Albrecht Dre_]

[sorry for the late answer, was out for a few days...]

Andreas Bombe wrote:
> Setting PCI_COMMAND_IO on the other hand is unneccessary since the
> PCILynx only uses memory mapped I/O (if I understand PCI config
> correctly).  I don't know if this flag is harmful if there are no I/O
> ports.

I don't think that writing a read-only bit will cause any problem.

You told me earlier that the PCILynx was stuck in bus reset, because DMA seems
not to work.  Does DMA signal success/completition by interrupt?  Then this
might be a problem with the CardBus Bridge and/or interrupts.  "lspci -vv" tells
me for the PCILynx

01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link
Layer Controller (rev 04) (prog-if 00 [Generic])
        Subsystem: Texas Instruments: Unknown device 8000
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 1 min, 2 max, 32 set, cache line size 20
        Interrupt: pin A routed to IRQ 0
        Region 0: Memory at 90030000 (32-bit, non-prefetchable)
        Region 1: Memory at 90000000 (32-bit, non-prefetchable)
        Region 2: Memory at 90010000 (32-bit, non-prefetchable)
        Expansion ROM at 90020000

I think IRQ 0 is a little bit suspicious, right?  At least /proc/interrupts does
not count ANY irq's on this line.  The same information for the Cardbus bridge
is-

00:13.0 CardBus bridge: Texas Instruments: Unknown device ac1e
        Subsystem: Texas Instruments: Unknown device ac1e
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 set, cache line size 08
        Interrupt: pin A routed to IRQ 22
        Region 0: Memory at 80880000 (32-bit, non-prefetchable)
        Bus: primary=00, secondary=01, subordinate=04, sec-latency=64
Memory window 0: 90000000-90031000
        I/O window 0: 00000000-00000003
        I/O window 1: 00000000-00000003
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
        16-bit legacy interface ports at 0007

Any cardbus/pci gurus out there?

Thanks, Albrecht.


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

Re: FireWire + Apple PB G3: some success

[Andreas Bombe]

On Mon, Feb 28, 2000 at 01:59:14PM +0100, Albrecht Dreß wrote:
> [sorry for the late answer, was out for a few days...]
>
> Andreas Bombe wrote:
> > Setting PCI_COMMAND_IO on the other hand is unneccessary since the
> > PCILynx only uses memory mapped I/O (if I understand PCI config
> > correctly).  I don't know if this flag is harmful if there are no I/O
> > ports.
>
> I don't think that writing a read-only bit will cause any problem.
>
> You told me earlier that the PCILynx was stuck in bus reset, because DMA seems
> not to work.  Does DMA signal success/completition by interrupt?

Yes, I forgot that possibility.

> Then this
> might be a problem with the CardBus Bridge and/or interrupts.  "lspci -vv" tells
> me for the PCILynx
>
> 01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link
> Layer Controller (rev 04) (prog-if 00 [Generic])
>         Subsystem: Texas Instruments: Unknown device 8000
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 1 min, 2 max, 32 set, cache line size 20
>         Interrupt: pin A routed to IRQ 0
>         Region 0: Memory at 90030000 (32-bit, non-prefetchable)
>         Region 1: Memory at 90000000 (32-bit, non-prefetchable)
>         Region 2: Memory at 90010000 (32-bit, non-prefetchable)
>         Expansion ROM at 90020000
>
> I think IRQ 0 is a little bit suspicious, right?  At least /proc/interrupts does
> not count ANY irq's on this line.

I think we found the guilty party (if IRQ 0 isn't a valid IRQ on PPCs).
You could try to use setpci to configure another IRQ, probably 22
because the CardBus bridge (also using pin A) uses this too, but I
don't know PCI internals well enough to know if this is required.

The question remains why it didn't get an IRQ assigned (either BIOS
(probably not on Mac) or Linux should do this).

--
          Andreas E. Bombe <andreas.bombe@munich.netsurf.de>
http://home.pages.de/~andreas.bombe/                DSA key 0x04880A44

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

Re: FireWire + Apple PB G3: some success

[Ryuichi Oikawa]

From: Albrecht Dreß <ad@mpifr-bonn.mpg.de>
Subject: Re: FireWire + Apple PB G3: some success
Date: Mon, 28 Feb 2000 13:59:14 +0100
Message-ID: <38BA7122.44C833A9@mpifr-bonn.mpg.de>

> 01:00.0 FireWire (IEEE 1394): Texas Instruments PCILynx/PCILynx2 IEEE 1394 Link
> Layer Controller (rev 04) (prog-if 00 [Generic])
>         Subsystem: Texas Instruments: Unknown device 8000
>         Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>         Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 1 min, 2 max, 32 set, cache line size 20
>         Interrupt: pin A routed to IRQ 0
                                     ^^^^^^
>         Region 0: Memory at 90030000 (32-bit, non-prefetchable)
>         Region 1: Memory at 90000000 (32-bit, non-prefetchable)
>         Region 2: Memory at 90010000 (32-bit, non-prefetchable)
>         Expansion ROM at 90020000
>
> I think IRQ 0 is a little bit suspicious, right?  At least /proc/interrupts does
> not count ANY irq's on this line.  The same information for the Cardbus bridge
> is-
>
> 00:13.0 CardBus bridge: Texas Instruments: Unknown device ac1e
                                                            ^^^^

>         Subsystem: Texas Instruments: Unknown device ac1e
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B-
>         Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> <TAbort- <MAbort- >SERR- <PERR-
>         Latency: 32 set, cache line size 08
>         Interrupt: pin A routed to IRQ 22
>         Region 0: Memory at 80880000 (32-bit, non-prefetchable)
>         Bus: primary=00, secondary=01, subordinate=04, sec-latency=64
> Memory window 0: 90000000-90031000
>         I/O window 0: 00000000-00000003
>         I/O window 1: 00000000-00000003
>         BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
>         16-bit legacy interface ports at 0007

Have you checked if the patch you used is really working correctly?
It setups CardBus bridge's interrupt routing for only TI1130(0xac12)
and TI1131(0xac15) (see the patch to arch/ppc/kernel/pmac_pci.c).
You will have to add support for your CardBus bridge(ID 0xac1e)
referring the document from TI.

Regards,


Ryuichi Oikawa
roikawa@rr.iij4u.or.jp

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

Re: FireWire + Apple PB G3: some success

[Benjamin Herrenschmidt]

On Wed, Mar 1, 2000, Ryuichi Oikawa <roikawa@rr.iij4u.or.jp> wrote:

>Have you checked if the patch you used is really working correctly?
>It setups CardBus bridge's interrupt routing for only TI1130(0xac12)
>and TI1131(0xac15) (see the patch to arch/ppc/kernel/pmac_pci.c).
>You will have to add support for your CardBus bridge(ID 0xac1e)
>referring the document from TI.

ac1e is the TI-1211. This is the same CardBus chip used in the new Pismo
powerbook. It's datasheet can be found on TI web site with the complete
register set.

BTW. I didn't find register infos in the datasheet for the TI-1131. Do
you have those ? I'd be interested. I found only the pinout and
electrical specs.


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

Re: FireWire + Apple PB G3: some success

[Ryuichi Oikawa]

From: Benjamin Herrenschmidt <bh40@calva.net>
Subject: Re: FireWire + Apple PB G3: some success
> BTW. I didn't find register infos in the datasheet for the TI-1131. Do
> you have those ? I'd be interested. I found only the pinout and
No, I didn't find any register information except application report
on interrupts(I'll send it to you if necessary, which is just a 115K PDF)
probably because it is obsolete. But you can find it in the pcmcia-cs
package, whose auther may have a document(though I'm not quite sure).

BBTW, I'm new in the MOL source and I need some information/explanation.
Today I tried to add RageLTPro OF properties to MOL oftree.nw,
insert it into the pci device tree and mmu map full 16MB aperture
in thw video driver(on PB G3). I could run the drawing engine within
MacOS manually, but ATI's extension didn't seem to recognize the chip
at all. I even tried to load & insert into the driver properties field
the driver extracted from ATI Driver update file, but no success.
I don't understand MOL interface mechanism yet(and unfortunately
my macos complier, symantec c++ doesn't work on recent system).

What is the correct way to accelerate MOL video?

Thanks,

Ryuichi Oikawa
roikawa@rr.iij4u.or.jp

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

Re: FireWire + Apple PB G3: some success

[Albrecht Dre_]

Ryuichi Oikawa wrote:
> Have you checked if the patch you used is really working correctly?
> It setups CardBus bridge's interrupt routing for only TI1130(0xac12)
> and TI1131(0xac15) (see the patch to arch/ppc/kernel/pmac_pci.c).
> You will have to add support for your CardBus bridge(ID 0xac1e)
> referring the document from TI.

I also found that problem as I could not see the pcibios_fixup kernel message in
the logs...

As Ben already said, it it TI's PCI1211.  Although the data sheet states that
the two registers you alter with your patch (0x91 and 0x91) are "...provided for
PCI1130 campatibility", just adding the signature to activate the setup does not
work.

Unfortunately I do not have a card for which I know for sure that it will work
with LinuxPPC.  In the meantime I tested so many different combinations of
with/without your patch, with/without the PCMCIA package ver. 3.0.something/
3.1.something enables/diabled and an Adaptec SCSI CardBus Card/FireWire2Go
CardBus card (and got all sorts of nasty reactions like freezes and panics) that
I am a litte confused now.  I am afraid I have to try a more systematic
approach, and to read TI's docs first.

Anyway, thanks a lot for your help!

Yours, Albrecht.


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