View previous topic :: View next topic |
Author |
Message |
GenTimJS Guru
Joined: 03 May 2003 Posts: 406 Location: NH, USA
|
Posted: Sat Jul 26, 2003 6:27 pm Post subject: Gentoo On SGI RXXXX ?? Been done? Should I bother? |
|
|
I may be coming into some older SGI systems. Indigo2 / Indy series R4000 or 5000 series.
Any others working on Gentoo for SGI?
Anyone tried and failed?
Thoughts? Comments? Should I bother, or save the time and just slit my belly now?
Whats involved fundamentally?
-Tim Smith _________________ -Tim Smith |
|
Back to top |
|
|
Kumba Developer
Joined: 16 Jul 2002 Posts: 393 Location: Sigma 957
|
Posted: Tue Jul 29, 2003 8:15 pm Post subject: Gentoo/MIPS |
|
|
We've been working on Gentoo/MIPS stuff for Gentoo for several months now.... Guess it hasn't been published too much.
Join #gentoo-mips on irc.freenode.net, and look at the channel topic there. It has the bulk of the information for getting started as well as some people in the chatroom (if awake) will have useful advice on what does/does not work.
Primarily, SGI Indigo2 + R4x00 and Indy R4x00/R5000 works well. Any other SGI system is either non-functional on Linux in general, or provided linux works, hasn't been tested with Gentoo yet.
Gentoo on other MIPS devices, like Cobalt RaQand Qube systems is wholly untested. I did manage to kludge Gentoo on a debian install on my RaQ2, but a particulary nasty Tulip/Kernel bug makes running a newer kernel very unfeasible, putting this work on hold.
I'm slowly working on new stages for Gentoo/MIPS, as well as cleaning up the documentation, but summer classes have hampered my efforts some.
--Kumba _________________ "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic |
|
Back to top |
|
|
dweigert Guru
Joined: 04 Oct 2002 Posts: 369 Location: Somerset, NJ USA
|
Posted: Tue Jul 29, 2003 11:45 pm Post subject: |
|
|
Patiently waiting for the Indigo2 R10K to be supported.....
Dan _________________ "Always remember to mount a scratch monkey..." |
|
Back to top |
|
|
Galahad Tux's lil' helper
Joined: 12 Feb 2003 Posts: 126
|
Posted: Wed Jul 30, 2003 7:35 pm Post subject: Impact |
|
|
And for support for Impact Graphics |
|
Back to top |
|
|
Kumba Developer
Joined: 16 Jul 2002 Posts: 393 Location: Sigma 957
|
Posted: Thu Jul 31, 2003 1:57 am Post subject: |
|
|
dweigert wrote: | Patiently waiting for the Indigo2 R10K to be supported.....
Dan |
Galahad wrote: | And for support for Impact Graphics |
In both cases, you'll be waiting a very long time. R10K Indigo2's are known as IP28 systems, and like their IP32 bretheren (SGI o2 + R10K), both suffer from a non-coherent cache issue. To better explain, I'll quote an email from Thiemo Seufer, who knows far more on this topic than I.
Thiemo Seufer wrote: | The R10000 does speculative execution, that is, it executes all instructions after a branch through most of it's pipeline stages. But only the instruction actually in the program flow is ever graduated, the other one is thrown away. All is well so far.
However, if this was a store instruction, the R10000 marks the cacheline hit as dirty _despite the store never graduates_. Not much of a problem for I/O coherent machines, it causes just a bit of memory traffic to write the cacheline back.
But non-I/O-coherent machines get in trouble when the cacheline contains parts of a DMA buffer which is changed by the DMA engine at this moment: The write back of the "dirty" line smashes the DMA data.
The only non-I/O-coherent R10000 machines I know of are the IP28 and the IP32. The fix for the IP28 is to write a cache barrier at the begin of each basic block which prevents speculative execution across it. This will help the kernel code. The userland can remain unchanged, because we can just remove the TLB mapping of DMA buffers if there is a DMA transfer pending, and reenable it afterwards. This prevents those erraneous writebacks.
I hope you can make sense of this desription. :-) |
On the topic of the Impact series of graphics cards, virtually no documentation exists, or SGI is really, really hiding it, as no one has gotten anything out of them. I do not believe anyone has managed to successfully reverse engineer the IRIX drivers either. As such, drivers for those cards is pipedream status at the moment.
--Kumba _________________ "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic |
|
Back to top |
|
|
kalisphoenix Apprentice
Joined: 28 Sep 2003 Posts: 211 Location: Ohio
|
Posted: Sun Feb 22, 2004 4:44 am Post subject: |
|
|
Kumba wrote: |
On the topic of the Impact series of graphics cards, virtually no documentation exists, or SGI is really, really hiding it, as no one has gotten anything out of them. I do not believe anyone has managed to successfully reverse engineer the IRIX drivers either. As such, drivers for those cards is pipedream status at the moment. |
I love organizations like Sun and SGI that ostensibly support Linux (both ship servers running Linux, iirc), but that provide absolutely no information to the community...
I'm finding a lot of conflicting information regarding the Elan graphics -- I'm assuming that's as unlikely as Impact.
Well, looks like I'll be ripping apart my IRIX installation and going for the Gentoo some time tonight. At least my Indy has a supported framebuffer Hope to help out someday on the SGI ports, and thanks for the information and work done so far, Kumba. |
|
Back to top |
|
|
Kumba Developer
Joined: 16 Jul 2002 Posts: 393 Location: Sigma 957
|
Posted: Sun Feb 22, 2004 8:22 pm Post subject: |
|
|
kalisphoenix wrote: | I love organizations like Sun and SGI that ostensibly support Linux (both ship servers running Linux, iirc), but that provide absolutely no information to the community...
I'm finding a lot of conflicting information regarding the Elan graphics -- I'm assuming that's as unlikely as Impact. |
Well, as far as I know, Impact documentation has completely disappeared into a Blackhole, or the equivalent of such. Impact is something weird like multiple embedded m68k processors on board that'd need activating and other voodoo-like magic to even get a character to print out. Elan as far as I know also lacks documentation, but there is a donation request on the mips/xfree86 page which to me implies that given appropriate hardware, the guy running that site can decipher Elan gfx and maybe make it work. That's just pure speculation though, but until SGI Either gives out docs or such, guess we're all stuck with Newport.
kalisphoenix wrote: | Well, looks like I'll be ripping apart my IRIX installation and going for the Gentoo some time tonight. At least my Indy has a supported framebuffer ;-) Hope to help out someday on the SGI ports, and thanks for the information and work done so far, Kumba. |
np, have any problems, you probably know where to find help & info. Plus the 2004.0 of Gentoo will be the first official release of mips on Gentoo as well. Future releases will hopefully bring many new things.
--Kumba _________________ "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic |
|
Back to top |
|
|
kalisphoenix Apprentice
Joined: 28 Sep 2003 Posts: 211 Location: Ohio
|
Posted: Sun Feb 22, 2004 10:41 pm Post subject: |
|
|
Damn.
I was about ready to sing you some more praises, but my Indy didn't boot all the way.
It got past the dhcp, I assume, because it said "$netaddr set to 192.168.0.7 by server" or something along those lines. However, it then went back to "Unable to execute bootp."
Since then it just says "No server for :." Hmm. I'm pretty sure that means there's a variable unset somewhere, but I'm not sure how to correct that.
I assume that means it's a problem with the tftp, which I wasn't really clear on. I wouldn't mind writing a tftp-hpa howto, when this is all over with... the one regarding PXEbooting doesn't seem to be applicable
EDIT: Hmm. Looks like you can bootp():/tftpboot/gentoo-r5k.img root=/dev/ram0. That seems to be doing something interesting (according to tcpdump), but I'm not actually sure if it's the img being transferred or just SGI and Gentoo messing with my head. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|