Voodoo3 PCI on C200 experiment pending!

I just scarfed up a somewhat used Voodoo3 PCI graphics card from Ebay and intend to try it out with Debian/HPPA and a custom built kernel.

I hope to compile a tdfx.o drm module and get the card recognized via a PALO boot command. I will use a dumb terminal for the system console during initial booting.

Any hints or tips would be appreciated :-)

Stop trying to use the card as your console :)

Stick with a serial console for startup and then launch X from that console.

It's my dream to get a Radeon 7000 PCI running on a C3K, but that will have to wait until September. I'm very interested in this test... since I'm a burgeoning DRI/DRM developer :)

If you have any problems please post to:

[email protected]

or visit

#dri-devel on irc.openprojects.net

Good luck!

c.

I think I have to disappoint you. I doesn't work for me :-(

I did exactly the same thing, I got a Voodoo 3 3000 from ebay and put it into my C240 (it's very similar to the C200 series).
I tried both 32bit and 64bit PCI slots, but XFree86's Voodoo driver seems to have some problems with 64bit PCI (at least some guru from the p-l mailing list suggested this after reading my XFree86 logs).

But unfortunately sticking the Voodoo into a 32bit PCI slot doesn't get much further: starting XFree86 will cause a HPMC shortly after a message like "Lasi: barking without apparent reason" (obviously from gsc/lasi.c). This is just before it is about to initialize the Voodoo3 (with the Intel emulator in XFree86). At least the messages printed on the console seem to be like the last messages XFree86 usually prints out just before activating the graphics card on other platforms.

Finally I even took out the (not yet supported) HP Visualize-FX2 card (64bit slot), just to get sure that there were no conflict with other PCI hardware. I'm using (or should I say: I have to use) the serial console anyway.

BTW, of course you must not compile the Voodoo FrameBuffer device, and I don't use the DRI driver either (just to be sure); just use XFree86 driver.

I recently found a message on the debian-alpha mailing list (this month) were some tried to get a Voodoo3 running on a AlphaStation. He succeeded by adding 'Option "NoINT10"' to XF86Config, but this didn't work for me. This would have been very surprising, since Alpha and HPPA are totally different architectures anyway, but who knows ...

My last attempt was with 2.4.19-pa2; still the same error.

greetings max

[...]

[...]

Does anybody can give me some hints what to do to debug this issue? I'm not a kernel hacker, and I don't have any knowledge about PA-RISC linux internals and PA-RISC assembler programming (but I hope I'll improve this situation in the future ;)

However I know C quite well (and debugging, stack manipulation, reverse engineering), and I used it not only as a hobby.

Can anybody give me some hints how I should compile the kernel (-g), how and if I should use the kernel debugger and recompile X with debugging symbols in order to get some more interesting information about how and why it Voodoo/X fails on PA-RISC linux? I'm sure will not be able to fix the problem, but I probably can feed you with some information that will help you to locate and solve the problem.
At least this is an interesting/annoying bug for two people (probably more) and we could investigate it a little bit more while you don't have to waste too much time on this issue yourself.

greetings max

Here's a start.

You want to get the HPMC state from firmware. interrupt the boot process and type "ser pim" at the firmware prompt. You want to look at gr02 (return pointer) and IOAQ (aka offset, IP). IOAQ points at the instruction that tripped the HPMC handling. It wasn't necessarily the cause. Look up the symbol in the System.map with "buildtools/a.c" (another CVS repository on cvs.parisc-linux.org).

IOAQ might point to user space if X11 server is involved. We'll have to look at PSW bits and/or Space registers to determine that.

grant

The biggest difference between Alpha and parisc is Alpha has weakly ordered memory. Reminds me of the saying: "My enemy's enemy is my friend"

BTW, ia64 on HP ZX1 doesn't like int10 either.

grant

Search the mail archives.
Once upon a time (2 years ago?), Alan Cox explained his ideas on how to make something like this work. He had an A180 in front of him at the time...

grant

I really doubt you will get a Voodoo3 to work this way. XFree have lots of problems with the Voodoo3 INT10 multihead even on x86 - the ROM seems to do some quite tricky stuff.

On the other hand a Voodoo2 should work wonderfully because its got no ROM, doesn't appear to be a video card and Glide2 has full source for bringing the board up.

XFree86 also supports using it as a 2D device, but not currently (alas 8)) DRI and Xv also.

delurking briefly since i worked on these parts (v2 and banshee-v3 which are basically the same) during my tenure at 3dfx.

I'll check my old mail archives, but the part taht you really want is just the timing tables in the rom. If you're looking at the code in cinit.c it had bitrotted quite badly after the initial bring up.

However, it used to be possible to change the device type multimedia (rather than video) and do all the initcode stuff. There was a little jumper on the cards themselves for this

yup, no 2d on voodoo2, but sort of lame just as a framebuffer device (well, if you want to use the command transport bits)

\p
---
A professional politician is a professionally dishonorable man. In order to get anywhere near high office he has to make so many compromises and submit to so many humiliations that he becomes indistinguishable from a streetwalker. --- H. L. Mencken

XFree86 supports it nicely as a 2D card nowdays. True its not exactly accelerated but it works. I use a couple for debugging displays

Voodoo2 it is then. I'm sorry but these HP graphics cards are terrible for X. 8-bit color is really the bottom of the barrel, and if I can get 16bpp on a Voodoo2 then its well worth the few bucks one costs these days, plus it adds an exotic air to the machine... "A HP workstation with a 3dfx voodoo2 ... oooh aaah." Hmm, might even be able to find some ancient Quake source with glide support and get it to work.

I used to have a V2 running in Linux several years ago, before the Banshee, before the Geforce. It really did kick butt and Quake and Quake2 were super nifty with it. I had my own version of Mesa compiled with Voodoo2 support and was the envy of my Linux buddies :-)

What do I do, just use the jumper cable to link the Visualize-EG to the voodoo2, and start up X? Obviously I will need the glide libs, but will I also need /dev/tdfx? Can the Voodoo2 tdfx module be compiled for a 2.4.19-pa3 kernel?

What about console switching? If X is running on the Voodoo2, and I hit Alt-F2, will it switch back to the Visualize-EG like it should?

Alan, if you could find a few minutes to send me your XF86Config-4 for one of these boards, or otherwise post some useful tips and hints that would be great. V2 boards are extremely cheap on Ebay and such these days, and those monsters deserve a fitting home in something like a parisc box rather than a dumpster.

Cheers!
- Doug

You'll need to rebuild glide2 and get it going on the box first, so that is actually a good starting point anyway.

You can do that, or you can run dual head

It does on x86 ... There is also sstfb which is a frame buffer/console text driver for the voodoo1/2. That might need some endianisation. I'm wondering if a USB card and a voodoo2 can turn even an A180 into a desktop ;)

I hope to get a PCI Radeon 7000 this weekend to turn a C3K into a _killer_ workstation ;)

c.