Nasty ATI/tulip interaction

Nasty ATI/tulip interaction

[David A. Gatwood]

Weird issue.  I finally got the PowerBase 180, and I've attempted to move
my Linux system from the G4 over to it.  I'm running a heavily patched
2.2.21-pre2 kernel.  It includes the PCI fixup patches, Promise Ultra
ATA/66 patches, and a few (possibly ppc-specific) bug fixes to get around
a problem where it was failing to get the correct drive capacity for my
Maxtor 80 gig drive for the first several warm boots.  (I think it was a
firmware bug in the Maxtor from all indications, as the drive wasn't
jumpered to truncate to 2 gigs, but it was doing it anyway.)

Anyway, everything worked fine until I actually tried to add ethernet to
the system.  When I added a 10/100 Tulip card (Netgear), all manner of
hell broke loose.

First, I tried the tulip.o driver.  Driver loaded.  Tried to ifconfig eth0
up.  My video went black.  Rebooted, video still black.  Power cycled the
monitor, all better.  Tried oldtulip.o.  Same problem.

So I thought maybe it was some weird interaction with the netgear card,
and I tried an old 10-base-T tulip card that worked under MkLinux
way-back-when.  Big mistake, as it apparently changed some card settings
in a way that I can't seem to undo.

Now, I can't even boot into single user mode without the video going black
half-way through boot.  This is with the "no video driver" checkbox in
BootX checked, since without doing that, I was getting scrambled video
half-way through boot even before this whole situation.  If I uncheck the
no video driver box, the screen goes black at the start of boot.

I've tried everything I can think of.  I've removed the ethernet card
entirely now, switched from a fixed sync 13" Apple monitor on the Apple
port to a 1024x768 multisync LCD panel on the VGA port.  I've even held
down the Cuda reset button and power key with the machine unplugged for
thirty seconds.

Does anyone know of any patches for the ATI hardware in these beasts?  If
not, then tonight, I'm going to try to flat-out neuter the entire video
subsystem to treat this card as a dumb framebuffer, since all I need is a
text console anyway.  Any suggestions on where to start?


Later,
David

---------------------------------------------------------------------
                    Check out my weekly web comic:
                     http://www.techmagazine.org


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

Re: Nasty ATI/tulip interaction

[David A. Gatwood]

On Tue, 26 Feb 2002, David A. Gatwood wrote:

> Weird issue.  I finally got the PowerBase 180, and I've attempted to move
> my Linux system from the G4 over to it.  I'm running a heavily patched
> 2.2.21-pre2 kernel.  It includes the PCI fixup patches, Promise Ultra
> ATA/66 patches, and a few (possibly ppc-specific) bug fixes
[ in IDE ].

Thanks to Ben Herrenschmidt, I've gotten it back to the point where I have
a console, but enabling the ethernet card still hoses the ATI output.

On a hunch, I downloaded, compiled, and installed pciutils, and I found
the problem....  The tulip card and the motherboard VGA got assigned the
same I/O ports address (0xf2000400).  No idea how that happened, but it's
quite consistent.

Looks like something broken.  I'd try without Michel Lanners' PCI fixup
patches, but I can't boot without them.  I'm trying to track down what's
breaking, but it isn't obvious.  I've tried to duplicate the code that
remaps planb to remap the ethernet device, but I'm getting nowhere fast.
It's attempting to do the remap, and it is successfully changing the
kernel's notion of the device address, but it looks like for some reason,
the change isn't happening in the controller itself, since I'm getting a
machine check when I actually try to access the device now.  I'm probably
doing something wrong.

I'm giving up for the night, but when I get back to this tomorrow night,
does anyone have any suggestions on how to change the PCI addy of the
ethernet card?

Later,
David

BTW, this doesn't work:

        unsigned char bus, devfn, confreg;
        unsigned short cmd;
        unsigned int i, reg;

        struct device_node *eth_device;

        eth_device = find_devices("pci1385,f004");
        if (eth_device == 0) {
                printk(KERN_WARNING "PCI: Error fixing eth: no OF
device.\n");
                return;
        }
        if (eth_device->next != NULL)
                printk(KERN_WARNING "PCI: Only fixing first eth
device.\n");
        if (eth_device->n_addrs != 1) {
                printk(KERN_WARNING "PCI: Error fixing eth: expected 1 "
                        "address, got %d.\n", eth_device->n_addrs);
                return;
        }
        DBG("PCI: Relocating address %lx ->%lx\n", dev->base_address[0],
                dev->base_address[0]+0x1000);
        dev->base_address[0] = dev->base_address[0] | 0x1000;
        /* Either 0 or PCI_BASE_ADDRESS_0 on next line */
        confreg=PCI_BASE_ADDRESS_0;
        pci_write_config_dword(dev, confreg,
                dev->base_address[0]);
        *newaddr=dev->base_address[0];
        confreg=0;

        /* Enable i/o space, once the new base is set */
        pcibios_read_config_dword (bus, devfn, confreg, &i);
        pcibios_read_config_word (bus, devfn, PCI_COMMAND, &cmd);
        cmd |= PCI_COMMAND_IO;
        pcibios_write_config_word (bus, devfn, PCI_COMMAND, cmd);

Nor this

        confreg = eth_device->addrs[0].space & 0xff;
        reg = (confreg - PCI_BASE_ADDRESS_0) >> 2;

        bus=dev->bus;
        devfn=dev->devfn;

        /* Set the new base address */
        pcibios_write_config_dword (bus, devfn, confreg, newaddr);

	dev->base_address[0] = newaddr;

        /* Enable i/o space, once the new base is set */
        pcibios_read_config_dword (bus, devfn, confreg, &i);
        pcibios_read_config_word (bus, devfn, PCI_COMMAND, &cmd);
        cmd |= PCI_COMMAND_IO;
        pcibios_write_config_word (bus, devfn, PCI_COMMAND, cmd);


---------------------------------------------------------------------
                    Check out my weekly web comic:
                     http://www.techmagazine.org


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

Re: Nasty ATI/tulip interaction

[Michel Lanners]

Hi David,

Sorry for replying late; was on holiday...

On  27 Feb, this message from David A. Gatwood echoed through cyberspace:
>
> On Tue, 26 Feb 2002, David A. Gatwood wrote:
>
>> Weird issue.  I finally got the PowerBase 180, and I've attempted to move
>> my Linux system from the G4 over to it.  I'm running a heavily patched
>> 2.2.21-pre2 kernel.  It includes the PCI fixup patches, Promise Ultra
>> ATA/66 patches, and a few (possibly ppc-specific) bug fixes
> [ in IDE ].

Any specific reason to stay with a 2.2 kernel? I can run 2.4.18 mainline
straight-Linus (sorry, straight-Marcello) on my 7600, with a Promise as
well.

2.4 kenels are a lot faster on PPC as well...

> Thanks to Ben Herrenschmidt, I've gotten it back to the point where I have
> a console, but enabling the ethernet card still hoses the ATI output.
>
> On a hunch, I downloaded, compiled, and installed pciutils, and I found
> the problem....  The tulip card and the motherboard VGA got assigned the
> same I/O ports address (0xf2000400).  No idea how that happened, but it's
> quite consistent.

Definitely a reason to move to 2.4 with the dynamic resource allocation.
That one will catch conflicts (modulo bugs like a chip not decoding as
precise as it says...).

> Looks like something broken.  I'd try without Michel Lanners' PCI fixup
> patches, but I can't boot without them.

Use 2.4 ;-) Should boot, and you can get rid of my patches :-))

> I'm trying to track down what's
> breaking, but it isn't obvious.  I've tried to duplicate the code that
> remaps planb to remap the ethernet device, but I'm getting nowhere fast.
> It's attempting to do the remap, and it is successfully changing the
> kernel's notion of the device address, but it looks like for some reason,
> the change isn't happening in the controller itself, since I'm getting a
> machine check when I actually try to access the device now.  I'm probably
> doing something wrong.

You sure you did everything required? You need to write the new address
back into the device's control registers, and you need to enable IO/Mem
space response before the device would repond. A non-responding device
can give you a machine check.

> I'm giving up for the night, but when I get back to this tomorrow night,
> does anyone have any suggestions on how to change the PCI addy of the
> ethernet card?

I'm repeting myself, but try 2.4 ?

> BTW, this doesn't work:
[snip]

Hmmm.. should have worked, though. Didn't see any obvious errors. Try a
2.4 kernel (did I say that before?), if that fails also, I'd say you
have a hardware bug somewhere that needs to be worked around....

Cheers

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


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

Re: Nasty ATI/tulip interaction

[David A. Gatwood]

On Wed, 13 Mar 2002, Michel Lanners wrote:

> Any specific reason to stay with a 2.2 kernel? I can run 2.4.18 mainline
> straight-Linus (sorry, straight-Marcello) on my 7600, with a Promise as
> well.

Ran into nasty problems booting with BootX on a G4, as I was trying to
have exactly the same environment on my G4 as I was going to have on the
PowerBase.  Then, I finaly got the PowerBase.  So basically, it was legacy
from having needed to get the system up and running before the final
machine actually arrived.  Caused some hiccups.


> Hmmm.. should have worked, though. Didn't see any obvious errors. Try a
> 2.4 kernel (did I say that before?), if that fails also, I'd say you
> have a hardware bug somewhere that needs to be worked around....

Probably.  I ran into several.  Anyway, got the thing working.  :-)


David

---------------------------------------------------------------------
David A. Gatwood                                dgatwood@gatwood.net
Developer Docs Writer                             dgatwood@apple.com
Apple Computer                                  dgatwood@mklinux.org

                    Check out my weekly web comic:
                     http://www.techmagazine.org


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

Re: Nasty ATI/tulip interaction

[Ethan Benson]

On Thu, Mar 14, 2002 at 02:40:08PM -0800, David A. Gatwood wrote:
>
> On Wed, 13 Mar 2002, Michel Lanners wrote:
>
> > Any specific reason to stay with a 2.2 kernel? I can run 2.4.18 mainline
> > straight-Linus (sorry, straight-Marcello) on my 7600, with a Promise as
> > well.
>
> Ran into nasty problems booting with BootX on a G4, as I was trying to
> have exactly the same environment on my G4 as I was going to have on the
> PowerBase.  Then, I finaly got the PowerBase.  So basically, it was legacy
> from having needed to get the system up and running before the final
> machine actually arrived.  Caused some hiccups.

you must not use BootX on newworld hardware (such as G4s).  you must
use yaboot.

--
Ethan Benson
http://www.alaska.net/~erbenson/

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