As mentioned yesterday, X.Org 7.4 (xserver-1.5 and newer) cannot operate on Alpha due to way it accesses PCI resources such as ROM information and video memory. Kernel Bug 10893 was filed 6 months ago, but nothing has been fixed. A work-around is to implement a fallback in libpciaccess that would access /dev/mem directly, as previous Xservers do. Unfortunately, no one appears to care enough about X support on Alpha to implement it.
Julien Cristau (jcristau), an X.Org developer, originally reported the implications of providing no fallback to the Debian bug tracking system. After failing to find it reported anywhere in FreeDesktop.org's Bugzilla, I reported it. On the #xorg-devel IRC channel, I asked jcristau if he could add anything to the bug report.
<mattst88> jcristau, if you could add anything to bug 19026, I'd really appreciate it.
<jcristau> mattst88: honestly i don't really care..
Not a good sign. Discouraged, I worked on something else for a half hour. I came back to IRC to see that developers had been discussing the fallback. No one was particularly enthusiastic. I asked Adam Jackson (ajax) of Red Hat why he opposed the fallback.
<mattst88> do we not want this fallback just on principle or because no one really cares to write it?
<ajax> mattst88: can't it be both?
<mattst88> sure, but is a temporary fallback really unacceptable?
<ajax> it's distasteful. i'm not going to write it. if someone else did, i probably wouldn't stop them.
I figured at this point I'd bother Ian Romanick, the libpciaccess maintainer, a bit more to see if I could get anything done. Before I had the chance though, David Airlie, responsible for all sorts of X development, responded.
<airlied> mattst88: also kms doesn't use the sysfs files
<airlied> or pciaccess.
The obvious implication of this statement is that once KMS (kernel modesetting) is implemented, lacking PCI resource files won't matter!
Unfortunately, it's not as quick and easy as we'd hope.
<airlied> but I need to revisit the whole mapping VRAM into unpriv userspace on those bonghits platforms.
<mattst88> right, so it should allow people to use radeons without fbdev, but isn't the radeon driver going to use sysfs/libpciaccess?
<airlied> mattst88: not with kms.
<airlied> userspace drivers in kms don't get access to all of VRAM
<airlied> or to registers.
<mattst88> so with kms, all this business about fallbacks and sysfs won't matter?
<airlied> no, however we have a whole new set of worries.
<airlied> mattst88: things like alpha sparsemem means we can't map VRAM into userspace on those platforms nicely.
<airlied> I need to read up more on the drug induced haze that is alpha mmio
<mattst88> is it doable? that is, are you at all interested in doing it? :)
<airlied> mattst88: I'm probably having to figure out how it might all work for IA64.
<mattst88> is that a similar situation to alpha?
<airlied> well its bad in that you can crap out certain machines if you allow users to access the mmio space.
<airlied> so its a DoS.
As always, there's work to be done, but this time it looks like there's someone who is actually going to do the work.
If anyone is interested in testing kernel modesetting with an R300, R400, or R500, check out David Airlie's drm-rawhide branch of his drm-2.6 kernel tree on Kernel.org.
I'll attempt to test with my Radeon X1550 and UP1500 motherboard soon and will report what I find.
Happy Birthday to this website! It's been running in one form or another for the last three years. A lot has changed since then. Originally it was just a convenient place for me to put SkyOS programming guides. Now, it's a site about Programming, Alternative Architectures, and Open Source (and still a convenient place for me to put things I don't want to lose.) It's evolved quite a bit in the last three years. I've got it, along with many other interesting things, on my TODO list for Christmas break.
Classes are finally out for the semester. Exams are over. I can finally get back to doing things I enjoy.
Since involving myself in Alpha/Linux by creating the Alpha Linux Wiki I've found out there are quite a few pressing things to be done. Firstly, we can't use recent Xservers. On the Samsung UP1xxx motherboards, the only Alpha motherboards with AGP slots (outside of EV7/Marvel servers), we can't even operate at AGP speeds. I'd love to be able to fix these myself, but I'm not knowledgeable about Linux Kernel programming. I'm therefore forced to pester kernel developers into finding a solution.
A possible work-around for the first problem is to hack libpciaccess to access /dev/mem directly, essentially doing what older Xservers do. I feel like I may, with enough help from knowledgeable developers, be able to do this myself.
On another front, ever since Compaq stopped providing Java for Alpha/Linux we've done without. This isn't so bad you may think, but the next time you chose between Azureus and Transmission for your BitTorrent client, realize we don't get a choice. Other programs taken for granted on x86[-64] are unavailable to Alpha users. OpenOffice is a great example.
Maybe Red Hat's IcedTea project can bring Java back to Alpha/Linux users. In the next month, I intend to find out.
I used to maintain a guide to using Intel's C Compiler with Portage on the Gentoo Wiki, but ever since they've lost their database, I've been reluctant to continue work on it. Why should I write content for your site and help you generate ad revenue, especially when you can't even make backups of my work?
Fortunately, there is a static archived copy available. I plan to transplant it onto my site where I can make sure that it is going to benefit the Gentoo community.
It looks like my list thus far is
Fix/Work around kernel bugs 10893 and 12127 one way or another
Determine if IcedTea can bring Java back to Alpha/Linux
Update Intel C Compiler guide and transplant to website
Snap some pictures and make some web pages for my other interesting computers
Lastly, I've picked up some interesting computers recently to compliment my AlphaServer DS20L. These deserve a place on my website as well, so I'm creating a computers section. Check back soon for information on my HP J6700 PA-RISC workstation and my Samsung UP1500 Alpha system.
When I came to college two years ago, I intended to major in Computer Science. I looked forward to learning and being around people who shared my interest in computers. As I quickly found out, (1) there weren't any people here who shared my interest or even anyone who could speak the same language, and (2) the little bit of learning I would be doing in my computer science classes wasn't interesting to me at all. By the end of my first year, after attempting to discuss my feelings (read: disappointments) about the computer science curriculum and one professor specifically with the head of the department, I realized it wasn't going to change anything. If I wanted a computer science degree, I would sit in boring classes, be treated as if I weren't competent enough to possibly know how to program, and I would have to do my assignments in Ada. After a year searching for a silver lining around the Computer Science department, I switched to Physics -- which may have been the best decision possible if I wanted to do anything interesting with computers.
Initially, I entered college as a Pre-engineering major with the intention of later going to an Engineering school for a Computer Engineering degree. I took the same Physics classes as Physics majors, the same Computer Science classes as Computer Science majors, and the same (if not harder) Math classes as Math majors.
I knew from first class sign-up day that the Computer Science faculty expected all incoming students to have no programming experience, and moreover didn't care one bit if you did have any. Normally, you find someone with common interests, in this case programming, and you will talk to them about the common interest. Here, they treated me as if I was a know-nothing outsider.
My computer generated course schedule didn't include the introductory computer science class, which is the prerequisite of all higher level computer science courses. Not taking it meant waiting a full year to take any other computer science classes. It was entitled
CSC 120 - INTRODUCTION TO THE COMPUTING SCIENCES
It sounded silly, and after reading the course description out of the catalogue, I decided it was: binary arithmetic, how a computer works, and the use of editors and linkers in programming. Yes, editors and linkers. As if they are somehow closely related.
Unfortunately, it conflicted with my schedule entirely. Adding it would require that I drop and find new times to take two other classes.
I attempted to find a way out of taking this class, so I introduced myself to the head of the Computer Science department. I told him that I knew a few programming languages already (at this point, C, PHP, and x86 assembly) and asked if there was any way I could avoid taking this class but still be able to take higher level courses. He replied that he'd give me the final exam and that if I passed, I'd get credit. "OK" I said, "that sounds great." He got a strange look on his face and paused thoughtfully for a moment. He had been trying to call a bluff that wasn't there. He quickly withdrew the offer when he realized I was serious.
I was forced to rearrange my entire schedule before I'd even set foot in class to accommodate this entirely useless class. In this two-hour class, we literally spent eight class periods on binary numbers. It was a thorough waste of my time, and the frustrating part was that wasn't even the slightest acknowledgment from the professor. To him, I was just another idiot who couldn't comprehend zeros and ones. On top of that, there were no other students who felt like I did (To everyone else, this stuff was magic). The final question on the final exam which was the hardest from the entire class was an assignment to write code to add all the even numbers from 1 to 1000. I answered in x86 assembly.
Similar episodes occurred throughout the next two years. I also began to realize that the program wasn't Computer Science but rather Software Engineering. Learning to write fault tolerant, rock solid business applications in Ada, while useful, isn't interesting to the aspiring hardware engineer.
By the end of my freshman year I decided it would be a better use of my time and my parent's money to major in Physics. After all, in the same time it would take to complete the Pre-engineering and Computer Engineering degrees, I could complete a BS in Physics and a Masters of Computer Engineering.
I've been a Physics major for a year now, while still retaining a minor in computer science. In contrast to Computer Science, the Physics professors are helpful and responsive, treat students as intelligent creatures (even if they aren't), and are understanding if there's a course scheduling conflict, which mostly are due to, you guessed it, the Computer Science department not thinking of Physics and upper level Math students.
Best of all, I recently learned that one of my Physics professors has quite an interest in DEC hardware, including Alphas. He's even nice enough to find a cabinet to house my noisy AlphaServer DS20L in the Physics lab in the Science building.
As previously reported, it was possible that Compaq's long dead suite of compilers and libraries optimized for the Alpha processor may be released to the Linux community. With hand written and highly optimized code in hand, Alpha developers could improve integral software such as gcc and glibc. Unfortunately, it does not appear that the release of this code will be possible due to licensing issues.
Linda Knippers of HP replied to my follow-up email today and told me that due to a couple things, it would be very difficult to release the Alpha tools so that they would be of any use to Linux developers. Firstly, some of the code in the compiler suite is encumbered by a MIPS license. I can only speculate that this goes back to the days of the MIPS-powered DECstation. With licensing comes lawyers, and we know how expensive they can be. It's just not worth HP's time and money to figure out how to free this code, especially for little or no gain on their part.
Secondly, the compilers are written in BLISS. Yes. BLISS. Even if the code were freely available, it would be in a language virtually no one is familiar with. As an side note, BLISS was developed at Carnegie Mellon University, the same place that developed the Mach kernel upon which Digital's/Compaq's/HP's Tru64 is based.
On top of all this, it appears to the current HP developers that all the Alpha tools for Linux were built on OpenVMS, making it ever more difficult for Linux developers to build the code assuming they could (1) find a way around the licensing issues, and (2) find a BLISS compiler.
Long story short, it doesn't appear that Compaq's Alpha tools will ever be released. Rest in peace, proprietary code.
I'm unsure if Alpha optimized libraries such as libots or libcpml contain license encumbered code. I will certainly make an attempt to find out. If they do not, there may still be a chance that HP will release their source codes.
When I bought a DS20L from eBay, I struggled to find helpful information. I sifted through Google search results, searched HP's website, read hundreds of posts on mailing lists, looked at Linux and BSD release notes, and searched everywhere I could think of. In the process, the one thing I discovered was that there was not a definitive spot for information on Alpha based computers, Alpha/Linux support, SRM versions, Alpha assembly and optimization, or Alpha software. Hopefully this new Alpha Linux Wiki will be that definitive spot.
I have been working behind the scenes with AlphaLinux.org's Peter Petrakis for the last two to three months to create a wiki to house the wealth of knowledge about the aforementioned topics in a central location. As you can see by the TODO page, there is quite a bit of content to be created. The wiki is in place, and I have written only a small fraction of what is needed. This is where we need you, the Alpha enthusiast, to add content and help make the wiki grow.
There are some things that I cannot add to the wiki even with an immense amount of research. In particular:
Pictures of Alpha hardware: Motherboards, CPUs, RAM, Cases, Full Systems, and any other Strange parts
Difficult to find SRM versions. I hope to build some sort of archive to store all available versions of SRM (maybe ARC too?)
Documentation. Do you have a document describing the internal workings of X piece of hardware?
Assembly programming examples. Examples describing the usage of various instructions, concepts, or optimization techniques.
Important Alpha related bugs. Particularly nasty bugs you can't wait to see squashed should be posted on the Bugs to watch page.
Alpha related programming projects. Alpha specific code needed for a project? Post it to the TODO page.
I sincerely hope that the Alpha community finds this resource helpful and makes good use of it.
On a related note, as many Alpha users know, this is the first time that AlphaLinux.org has been updated in years. We hope to change this by adding a forum and migrating the main site to a content management system. Peter Petrakis would like to use a Ruby based CMS, and I have no preference. If you have any suggestions, please let me know. Also, if you have suggestions of ideas for other ways to improve AlphaLinux.org I'm all ears.