mattst88's blog

Radeon X1550 in an SGI O2?

In a thread on the SGI Enthusiast site, Nekochan.net, about Linux compatibility with SGI's MIPS based line of workstations, a user, tillin9, suggested the possibility of installing modern, off the shelf graphics cards in the SGI O2 under Linux. The O2 is equipped with a single PCI slot for expansion, so physically installing a new graphics card is no problem. Unfortunately, graphics cards require special initialization code, stored in the card's ROM, to be run at boot time. Since the Radeon's initialization routine has to be able to execute on the processor architecture in the computer in which it's installed, different code is required for x86, PowerPC, PA-RISC, SPARC, and MIPS. Since there weren't any PCI Radeon's made for MIPS powered workstations, surely ten years later, a modern Radeon would never work in an old SGI workstation...

Linux support for SGI's MIPS systems isn't on par with other architectures such as AMD64 or even Alpha currently, mainly due to the lack of man power and programming documentation. For instance, SGI has never released any programming documentation on their IP35 line of workstations which includes the Fuel and Tezro. On top of this, there's the problem of being unable to initialize the Radeon. Given this information, I incorrectly thought this meant there was no chance of installing a PCI Radeon in an old O2.

tillin9 seemed to mention that the inclusion of Radeon kernel modesetting would alleviate the problem of initializing the card. I was skeptical, so I asked around on the #dri-devel and #xorg-devel channels on Freenode about the status of the Radeon kernel modesetting code. Davie Airlie of Red Hat, one of the developers responsible for R500 support among many other things, responded quickly.

<airlied> mattst88: we haven't got radeon modeseting written yet..
<airlied> it might make .28, but it more likely will be Fedora first.
<airlied> I'm writing it as fast as I can.

So, the code's not done. It is obviously a high priority from his response. I've never seen a developer say anything similar to I'm writing it as fast as I can. Hopefully it'll be included in the kernel for the 2.6.28 release which should be about 6 months away. If not, it should be included in 2.6.29 a few months later.

Now, this code isn't being written in order to allow alternative architecture enthusiasts to use nice 3D graphics cards in SGI workstations. It certainly would be a great side-effect though. Again, I asked on the appropriate IRC channels. Alex Deucher of AMD, one of the main developers of X.org's xf86-video-ati driver responded quickly to my query.

<mattst88> will radeon kernel modesetting allow the usage of a x86 PCI radeon in a sparc, hppa, or mips box even without a special ROM?
<agd5f> mattst88: it should

What an excellent unintended benefit of Radeon kernel modesetting. I mailed the xorg mailing list just to be sure. From this, Alex Deucher responded to me again and clarified. In short:

This feature, whose main purpose is to remove an unnecessary obstacle and provide a flicker-free boot up, will also allow many users of SPARC, PA-RISC, and MIPS computers to enjoy the features provided by a modern Radeon graphics card.

To tillin9: I'm sorry for doubting you. Thanks a lot for bringing the possibility of a Radeon X1550 equipped SGI O2 workstation to my attention.

– Tags: kms linux mips radeon sgi xorg

Open Sourcing Compaq's Alpha Tools for Linux

I'm in the (long and arduous) process of becoming a Gentoo/Alpha developer. This involves, firstly, becoming an Architecture Tester. This in turn, requires that I complete a quiz, mail it to the head of the Alpha team and wait. The developer who manages the alpha arch testers, of which there are none, currently, has been missing in action for 18 days.

Once I prove myself worthy, or whatnot, I'll then complete a longer version of the arch tester quiz. Once my quiz has been reviewed, I'll be mentored for 30 days. After this 30 day period, I'll officially be a Gentoo/Alpha developer.

At this point, I'll try to get Compaq's alpha compilers and libraries back into portage in one fashion or another. libots is already in portage. The math library, libcpml, whose value I showed will be next on my agenda. Compaq's C, C++, and FORTRAN compilers, having been unmaintained for years now, have quite a few incompatibilities with modern Linux distributions. I think the best course of action for these is to get them into a portage overlay.

Compaq's alpha optimized compilers, unmaintained and bit rotting, still hold a wealth of knowledge. Compaq's cc still produces code much better than gcc in certain cases. libcpml and libots have incredibly optimized routines for all sorts of common functions. It's such a shame for them to rot as they're doing now.

With this attitude, I emailed Linda Knippers of HP, who in some capacity orcestrated the AdvFS code release under the GPL.

Hi Linda,

There are a few tools and libraries Compaq/HP has provided for Alpha Linux in the past that have been totally unmaintained in the last few years but still hold great value and knowledge to the open source community. I'm emailing to (1) see if there's any possibility that they may be open sourced in the future, or (2) be directed to contact someone more appropriate.

The tools and libraries in question are Compaq's Alpha-Optimized C, C++, and FORTRAN compilers, libots, libcpml, libcxml, and ladebug. Other Tru64 tools that we Alpha Linux users would love to use include spike and pixie.

Do you know of any plans to release any code for any (hopefully all) of these products? It seems a shame to have them bit rot when GNU Compiler Developers could learn a thing or two from ccc, and when the GNU libc Developers could incorporate libcpml routines into their math library and so forth.

Thank you for your time,

Matt Turner

She kindly responded (9 minutes later!) and told me that although she didn't know of any plans to open source these products, that it may be something HP would consider. She forwarded my mail to a former Tru64 developer to get his thoughts.

While I don't have code in hand (yet), it appears that they are at minimum receptive to this idea. Hopefully in the near future we'll be reading through Digital/Compaq's code, learning more about alpha optimization, and implementing what we learn in gcc and glibc.

I'll definitely post back any new information I find out.

– Tags: alpha gentoo linux