Does anybody know the status of the toolchain update that was going on last year by Chewi?
Ref : Linux 2.6 On PS2
I've tried to access Chewi's gcc and binutils patches at http://gps2.aura-online.co.uk/ without success.
Have they been submitted to the maintainers? Does anybody have a copy of the latest patch?
There is a port I had in mind for sometime that would be easier to do with a newer toolchain.
If Chewi doesn't have the time to work on this anymore, I might consider taking the ball. It would be very sad to see this die after all the efforts that has been put into this.
Regards,
Danny
Status of toolchain update?
You mean this patch?
http://forums.ps2dev.org/viewtopic.php?p=57589#57589
Last I remember there were some problems, but if you can find a working patch I'd be happy to add it to ps2toolchain.
Code: Select all
diff -Naur gcc-4.2.0-old/configure.in gcc-4.2.0-new/configure.in
--- gcc-4.2.0-old/configure.in 2007-09-02 12:50:32.496775367 +0100
+++ gcc-4.2.0-new/configure.in 2007-09-02 12:51:03.509044251 +0100
@@ -737,6 +737,9 @@
mips*-*-linux*)
noconfigdirs="$noconfigdirs target-newlib target-libgloss"
;;
+ mips*-*-irx*)
+ noconfigdirs="$noconfigdirs gprof target-newlib target-libgloss target-libiberty target-libstdc++-v3 ${libgcj}"
+ ;;
mips*-*-*)
noconfigdirs="$noconfigdirs gprof ${libgcj}"
;;
diff -Naur gcc-4.2.0-old/gcc/config/mips/iop.h gcc-4.2.0-new/gcc/config/mips/iop.h
--- gcc-4.2.0-old/gcc/config/mips/iop.h 1970-01-01 01:00:00.000000000 +0100
+++ gcc-4.2.0-new/gcc/config/mips/iop.h 2007-09-02 16:36:18.457254164 +0100
@@ -0,0 +1,8 @@
+#undef MULTILIB_ABI_DEFAULT
+#define MULTILIB_ABI_DEFAULT "mabi=none"
+
+#define DRIVER_SELF_SPECS \
+ "%{!march=*:-march=r3000}", \
+ "%{!funit-at-a-time:-fno-unit-at-a-time}", \
+ "%{!fmerge-constants:-fno-merge-constants}", \
+ "%{!fbuiltin:-fno-builtin}"
diff -Naur gcc-4.2.0-old/gcc/config/mips/t-iop gcc-4.2.0-new/gcc/config/mips/t-iop
--- gcc-4.2.0-old/gcc/config/mips/t-iop 1970-01-01 01:00:00.000000000 +0100
+++ gcc-4.2.0-new/gcc/config/mips/t-iop 2007-09-02 12:51:03.509044251 +0100
@@ -0,0 +1,3 @@
+MULTILIB_OPTIONS =
+MULTILIB_DIRNAMES =
+MULTILIB_MATCHES =
diff -Naur gcc-4.2.0-old/gcc/config.gcc gcc-4.2.0-new/gcc/config.gcc
--- gcc-4.2.0-old/gcc/config.gcc 2007-09-02 12:50:32.533769723 +0100
+++ gcc-4.2.0-new/gcc/config.gcc 2007-09-02 16:36:50.490367312 +0100
@@ -1654,6 +1654,12 @@
tmake_file=mips/t-r3900
use_fixproto=yes
;;
+mips*-*-irx*)
+ tm_file="elfos.h ${tm_file} mips/elf.h mips/iop.h"
+ tmake_file="mips/t-elf mips/t-gofast mips/t-iop"
+ target_cpu_default="MASK_SOFT_FLOAT"
+ use_fixproto=yes
+ ;;
mmix-knuth-mmixware)
need_64bit_hwint=yes
;;Last I remember there were some problems, but if you can find a working patch I'd be happy to add it to ps2toolchain.
I don't think this would be enough ooPo.
I meant the patch(es) that are necessary to:
I meant the patch(es) that are necessary to:
- add support for the r5900 in recent binutils for both Linux and ps2dev
- target definition, new and non existant instructions vs R3000/MIPS III
- The second ALU Pipeline for DIV/MULT LO/HI
- ABI
- etc
- add support for the r5900 in gcc 4.2x so gcc doesn't emit invalid instructions
- newer newlib port
- IOP patches for gcc 4.2, if any
Hey guys. You probably took my server being down as quite a bad sign but actually it's only been down for a week due to it being moved. It's just come back up. As for me, life took over with getting married in May and trying to buy a house now. Unless anyone who seriously knows what they're doing can give me a hand, and I hope that person is poutine, it's unlikely that I'll ever go back to it.
The small patch posted above certainly isn't the entire thing. That's just the GCC patch for the IOP, which only requires trivial changes because it's just an R3000. I'm pretty sure that I tested IRXs built with the new toolchain against EE software built with the old toolchain and they worked fine so it seems that all the IOP/IRX changes are okay. I haven't touched the DVP stuff but I don't think you care about that.
Overall, the code is in the best state that it ever was, with it being able to play a few MP3s through madplay. I can't remember if I still had to make that weird change to madplay that I mentioned in the thread. Perhaps not.
Even when I stopped working on it, I was still wrestling with the PS2's multiple personality disorder over whether it's primarily a 32-bit, 64-bit or 128-bit machine. I have some uncommitted changes where I tried to push the focus to 128-bit but that didn't work at all. 64-bit seems to be the way to go but GCC has serious issues with the word size (UNITS_PER_WORD * 8) being different from the pointer size (POINTER_SIZE). I now at least understand that using 64-bit stuff in the compiler doesn't necessarily mean that we need a 64-bit Linux kernel. A 32-bit kernel would be fine.
Even without trying to treat the machine as 128-bit, optimisations can still be made using the MMI instructions as was done in the GCC 3.2.2 patch. On the other hand, I have doubts about whether GCC is actually smart enough to see where these optimisations can be used. The MMI code that currently exists should be correct but I recommend you disable it until everything else is working. This can easily be done by removing the line that applies MASK_MMI when TARGET_MIPS5900 is enabled.
You mention GCC 4.2 but my patch is actually against a late alpha of 4.3. It should still work against 4.3 final. There were some important MIPS changes in 4.3 to do with move splitting and my patch won't apply against 4.2.
The binutils version I was using was 2.16.1. This isn't so new anymore but it isn't exactly old either. I think there was a complication with 2.17 but I can't remember what it was.
The newlib version I was using was 1.15.0. Again, this isn't very new but should still be sufficient. Having said that, I don't know of any reason why 1.16.0 wouldn't work. From what I recall, all I had to do was readd the R5900 assembly and regenerate the autotools stuff. The old patch against 1.10.0 also included an alternative malloc implementation because it claimed the official one was broken. I figured this wasn't needed anymore so I just dropped it. Reapplying it didn't seem to be an option.
Support for the second pipeline has been added and I think this is okay. It has been done in a totally different way to before because of major changes to GCC. I couldn't get my head around the old method anyway.
Support for some of the advanced MIPS instructions has also been added in the cases where they didn't differ at all or too much from the official ones.
The ABI side of things confused me a lot. Even though support for EABI appears to be deprecated in GCC, it looks like enough of the code has remained for it to still work. I was planning to use N32 for Linux but I think I discovered that O32 is actually required, at least for the kernel. Userland may be different. I didn't get too far down this road because I was trying to get the toolchain working without Linux first.
In terms of what I know remains to be done, the only critical thing I didn't tackle was the short loop length bug. This was originally dealt with in GCC in case an assembler other than GAS was being used. We don't care about this anymore and it would be very much simpler to fix the issue in GAS. It detects the bug and issues a warning so half the work is already done. I couldn't quite figure out how to go about fixing it though.
I don't think the above issue is what is causing things to fail though. I found that it works much better when you build everything with -O0 but even then, it is still very broken, so clearly I must have missed something or not got it quite right. This should come as no surprise since I'd never hacked the toolchain before and I basically taught myself this stuff by just staring at the code for hours. If you know more about it, especially in the context of the PS2, then you're just what we need. If I had to bet on it, I'd say the problem is to do with alignment. I had trouble finding much information on this and the presence of 128-bit registers just made it even more confusing.
So the code's there. Good luck. ;) Feel free to ask me anything.
Edit: I forgot to mention PS2SDK. Even without the new toolchain, it's a bit of a mess, to be honest. I made a patch to get some of the stuff to build against GCC 4 but it's not complete and it doesn't do anything to improve the mess so don't commit it or anything. Just use it as a starting point to test the toolchain. It's also possible that some of my changes here have caused the problems I've been having so I'd appreciate it if you could verify them.
http://www.aura-online.co.uk/~chewi/ps2sdk-gcc4.patch
The small patch posted above certainly isn't the entire thing. That's just the GCC patch for the IOP, which only requires trivial changes because it's just an R3000. I'm pretty sure that I tested IRXs built with the new toolchain against EE software built with the old toolchain and they worked fine so it seems that all the IOP/IRX changes are okay. I haven't touched the DVP stuff but I don't think you care about that.
Overall, the code is in the best state that it ever was, with it being able to play a few MP3s through madplay. I can't remember if I still had to make that weird change to madplay that I mentioned in the thread. Perhaps not.
Even when I stopped working on it, I was still wrestling with the PS2's multiple personality disorder over whether it's primarily a 32-bit, 64-bit or 128-bit machine. I have some uncommitted changes where I tried to push the focus to 128-bit but that didn't work at all. 64-bit seems to be the way to go but GCC has serious issues with the word size (UNITS_PER_WORD * 8) being different from the pointer size (POINTER_SIZE). I now at least understand that using 64-bit stuff in the compiler doesn't necessarily mean that we need a 64-bit Linux kernel. A 32-bit kernel would be fine.
Even without trying to treat the machine as 128-bit, optimisations can still be made using the MMI instructions as was done in the GCC 3.2.2 patch. On the other hand, I have doubts about whether GCC is actually smart enough to see where these optimisations can be used. The MMI code that currently exists should be correct but I recommend you disable it until everything else is working. This can easily be done by removing the line that applies MASK_MMI when TARGET_MIPS5900 is enabled.
You mention GCC 4.2 but my patch is actually against a late alpha of 4.3. It should still work against 4.3 final. There were some important MIPS changes in 4.3 to do with move splitting and my patch won't apply against 4.2.
The binutils version I was using was 2.16.1. This isn't so new anymore but it isn't exactly old either. I think there was a complication with 2.17 but I can't remember what it was.
The newlib version I was using was 1.15.0. Again, this isn't very new but should still be sufficient. Having said that, I don't know of any reason why 1.16.0 wouldn't work. From what I recall, all I had to do was readd the R5900 assembly and regenerate the autotools stuff. The old patch against 1.10.0 also included an alternative malloc implementation because it claimed the official one was broken. I figured this wasn't needed anymore so I just dropped it. Reapplying it didn't seem to be an option.
Support for the second pipeline has been added and I think this is okay. It has been done in a totally different way to before because of major changes to GCC. I couldn't get my head around the old method anyway.
Support for some of the advanced MIPS instructions has also been added in the cases where they didn't differ at all or too much from the official ones.
The ABI side of things confused me a lot. Even though support for EABI appears to be deprecated in GCC, it looks like enough of the code has remained for it to still work. I was planning to use N32 for Linux but I think I discovered that O32 is actually required, at least for the kernel. Userland may be different. I didn't get too far down this road because I was trying to get the toolchain working without Linux first.
In terms of what I know remains to be done, the only critical thing I didn't tackle was the short loop length bug. This was originally dealt with in GCC in case an assembler other than GAS was being used. We don't care about this anymore and it would be very much simpler to fix the issue in GAS. It detects the bug and issues a warning so half the work is already done. I couldn't quite figure out how to go about fixing it though.
I don't think the above issue is what is causing things to fail though. I found that it works much better when you build everything with -O0 but even then, it is still very broken, so clearly I must have missed something or not got it quite right. This should come as no surprise since I'd never hacked the toolchain before and I basically taught myself this stuff by just staring at the code for hours. If you know more about it, especially in the context of the PS2, then you're just what we need. If I had to bet on it, I'd say the problem is to do with alignment. I had trouble finding much information on this and the presence of 128-bit registers just made it even more confusing.
So the code's there. Good luck. ;) Feel free to ask me anything.
Edit: I forgot to mention PS2SDK. Even without the new toolchain, it's a bit of a mess, to be honest. I made a patch to get some of the stuff to build against GCC 4 but it's not complete and it doesn't do anything to improve the mess so don't commit it or anything. Just use it as a starting point to test the toolchain. It's also possible that some of my changes here have caused the problems I've been having so I'd appreciate it if you could verify them.
http://www.aura-online.co.uk/~chewi/ps2sdk-gcc4.patch
Thanks man.
Regarding Linux, I have generally preferred the option of moving towards 2.6 rather than sticking with 2.4 because 2.4 has traditionally not compiled with GCC 4. However, I just discovered that changed with 2.4.34. The fixes for MIPS weren't included in that release but they were mentioned. Even if they didn't make it into a later release, they do exist somewhere. The latest kernel I ever successfully ran on the PS2 was 2.4.20, though it had some signalling problems. 2.4.33 made it all the way to init before panicking, though that was only a half-arsed attempt. I knew it wouldn't work because the memory management code changed significantly in 2.4.21. If we can get GCC 4 to behave and figure out that memory management stuff then that would be a major step forward indeed.
Regarding Linux, I have generally preferred the option of moving towards 2.6 rather than sticking with 2.4 because 2.4 has traditionally not compiled with GCC 4. However, I just discovered that changed with 2.4.34. The fixes for MIPS weren't included in that release but they were mentioned. Even if they didn't make it into a later release, they do exist somewhere. The latest kernel I ever successfully ran on the PS2 was 2.4.20, though it had some signalling problems. 2.4.33 made it all the way to init before panicking, though that was only a half-arsed attempt. I knew it wouldn't work because the memory management code changed significantly in 2.4.21. If we can get GCC 4 to behave and figure out that memory management stuff then that would be a major step forward indeed.
-
ragnarok2040
- Posts: 202
- Joined: Wed Aug 09, 2006 1:00 am
I have an experimental patch that Ed Schouten (http://80386.nl/) made for netbsd's toolchain. Unfortunately I don't know what versions of gcc or binutils for which it was made, though I'm pretty sure it was probably for <gcc-3.2.2. It is fortunate though that his patch has comments that details the problem.
Patch was a little large so I uploaded it to my site, http://homebrew.thewaffleiron.net/ragnarok2040 and click on netbsd-toolchain-playstation2.diff.
Patch was a little large so I uploaded it to my site, http://homebrew.thewaffleiron.net/ragnarok2040 and click on netbsd-toolchain-playstation2.diff.
What about those linux patches?
I know (back in the gentoo days :-) you put a lot of effort into stripping the PS2 specific patches from the MontaVista patches (the 2.4.17_mvl21 kernel), and patching newer kernels. A working 2.4.20 patch (without all the MontaVista stuff making it difficult) would be very welcome, are those patches available somewhere?
I know (back in the gentoo days :-) you put a lot of effort into stripping the PS2 specific patches from the MontaVista patches (the 2.4.17_mvl21 kernel), and patching newer kernels. A working 2.4.20 patch (without all the MontaVista stuff making it difficult) would be very welcome, are those patches available somewhere?
I tried to contact Ed over two years ago through the Gentoo forums but he never read the message - it's still sitting in the outbox. That patch is against the old toolchain and contains just the stuff to handle the short loop length bug. If you were willing to sacrifice performance by only building for MIPS I then this is the only change you would have to make. I guess I plunged straight in at the deep end with GCC 4 in that respect but this route would not have worked for homebrew stuff anyway.
I think this was the last patch I did against 2.4.17. I haven't touched that stuff in a very long time. Getting GCC 4 to work was more important. I didn't release any of it officially because I wanted to fix the USB stuff properly. You could just dump the MontaVista code in there if you wanted to though. As you probably remember, a few weeks after I stripped the patches, Ed Schouten managed to get hold of the original patch from MontaVista. I was a bit miffed about that! *lol* The problems I had with 2.4.20 made me wonder whether I should have tried using the original patch instead. I just tried to grab them but the URL Ed posted is dead now. Hopefully he still has it.
Hello Chewi.
Thank you very much for taking the time answering me.
Unfortunatly, I don't have any experience with porting toolchain and I am no PS2 hardware expert either.
But I am not a complete noob either. I've been studying r5900/TX79 instruction set and lots of code in ps2dev lately with the intend of optimising pgen rendering using MMI instructions. But all this is just a prelude to other projects I have in mind, one of which would require a newer gcc.
Beside that, I've been earning a living as a software developper or as a system/network administrator for the last 16 years. I've been working on Sun/Solaris, HP/HPUX, WinTel, Linux PC and QNX. Finally, I am a bacchelor of computer science.
I don't have as much free time as I would like to work on this so I'm not making any promises. But since you invested so much time into this and you seem so close to succes, it would be very sad to see all these efforts being dropped. I would really like to get to the point where the basic tool chain i.e Binutils, Gcc, libc (based on newlib) are based on "stable, mainstream" released. As for the rest of PS2SDK and/or demos, I don't think it is realistic to count on one or two persons to actualise them to the new toolchain. But I will surely provide the ones I have to do on an "as needed" basis.
Back to the subject...
I've look at your ps2-overlay and I can't find any patches for binutils. Is gas still part of binutils or is it part of gcc now ? Sorry, I did not have the time to fully study the gcc patches yet. Am I missing something?
The r5900 (and the Toshiba TX79) are very weird beast indeed. I would say they are in fact 64bits processor but with only 32bits as its external address bus. This is similar to the MC68000 which is considered a 32 bit processor but has only a 16 bits address bus. As for the 128bits wide MMI instructions, I guess we could look at how gcc threat MMX with the Pentium. Pentiums are 32bits but mmx is 64bits if I remember correctly. Same with the newer Core2, 64 bits processor but with 128bits multimedia extension if memory served me right (SSE or whatever the latest MMI extension are called).
As for alignment, this is again a bit tricky. Contrary to some other MIPS, I think it is possible to Load/Store Halfword, Word and Double word unaligned without any arse effects except for a few cycles penalty. The Quadwords are another thing... The processor will silenty drop (no exception) the lowest bits of any unaligned Quadword access which would cause read from/write to lower memory addresses than intended !
Do you know of any gcc/gas mailing list for CPU porters?
I'll probably take the next few days to setup SVN on my end so I can better track pristine original code vs ps2sdk and your versions... It is hard to get an overall view when you look at a single big patch.
Regards,
Danny
Thank you very much for taking the time answering me.
Unfortunatly, I don't have any experience with porting toolchain and I am no PS2 hardware expert either.
But I am not a complete noob either. I've been studying r5900/TX79 instruction set and lots of code in ps2dev lately with the intend of optimising pgen rendering using MMI instructions. But all this is just a prelude to other projects I have in mind, one of which would require a newer gcc.
Beside that, I've been earning a living as a software developper or as a system/network administrator for the last 16 years. I've been working on Sun/Solaris, HP/HPUX, WinTel, Linux PC and QNX. Finally, I am a bacchelor of computer science.
I don't have as much free time as I would like to work on this so I'm not making any promises. But since you invested so much time into this and you seem so close to succes, it would be very sad to see all these efforts being dropped. I would really like to get to the point where the basic tool chain i.e Binutils, Gcc, libc (based on newlib) are based on "stable, mainstream" released. As for the rest of PS2SDK and/or demos, I don't think it is realistic to count on one or two persons to actualise them to the new toolchain. But I will surely provide the ones I have to do on an "as needed" basis.
Back to the subject...
I've look at your ps2-overlay and I can't find any patches for binutils. Is gas still part of binutils or is it part of gcc now ? Sorry, I did not have the time to fully study the gcc patches yet. Am I missing something?
The r5900 (and the Toshiba TX79) are very weird beast indeed. I would say they are in fact 64bits processor but with only 32bits as its external address bus. This is similar to the MC68000 which is considered a 32 bit processor but has only a 16 bits address bus. As for the 128bits wide MMI instructions, I guess we could look at how gcc threat MMX with the Pentium. Pentiums are 32bits but mmx is 64bits if I remember correctly. Same with the newer Core2, 64 bits processor but with 128bits multimedia extension if memory served me right (SSE or whatever the latest MMI extension are called).
As for alignment, this is again a bit tricky. Contrary to some other MIPS, I think it is possible to Load/Store Halfword, Word and Double word unaligned without any arse effects except for a few cycles penalty. The Quadwords are another thing... The processor will silenty drop (no exception) the lowest bits of any unaligned Quadword access which would cause read from/write to lower memory addresses than intended !
Do you know of any gcc/gas mailing list for CPU porters?
I'll probably take the next few days to setup SVN on my end so I can better track pristine original code vs ps2sdk and your versions... It is hard to get an overall view when you look at a single big patch.
Regards,
Danny
24 bit address bus. The data bus was 16 bits. The 68008 used an 8 bit data bus. The 68000 has a 32 bit design, but is only considered a 16 bit CPU since it used a 16 bit ALU. All 32 bit operations required two (or more) operations to complete (rather like Intel's first AMD64 compatible chips, doing 64 bit operations using their 32 bit ALUs).poutine wrote:This is similar to the MC68000 which is considered a 32 bit processor but has only a 16 bits address bus.
-
ragnarok2040
- Posts: 202
- Joined: Wed Aug 09, 2006 1:00 am
It looks like the Gentoo maintainers might have pruned the patchset directory or moved them somewhere else in their cvs tree so I uploaded the ones I downloaded in September 2007 to my site as well. I put them in binutils-2.16.1-ps2.tar.gz.
I've found some more info and discussion on the short loop length bug as well.
http://gcc.gnu.org/cgi-bin/search.cgi?w ... 25&q=r5900
Mailing lists:
[email protected]
[email protected]
The [email protected] mailing list seems to be more suited for questions pertaining to porting gcc.
I've found some more info and discussion on the short loop length bug as well.
http://gcc.gnu.org/cgi-bin/search.cgi?w ... 25&q=r5900
Mailing lists:
[email protected]
[email protected]
The [email protected] mailing list seems to be more suited for questions pertaining to porting gcc.
Sounds like you have some wider experience than I do. I'm also a Bachelor of CompSci but we didn't do any actual assembly. I did a language and compiler design module but we ran out of time just before getting to the assembly part and that would have been SPARC anyway. Still, it proved useful. I ended up teaching myself MIPS crash course style from here and learned about the R5900 specifics from the Sony documentation.
I use Gentoo Linux most of the time and it has a tool called crossdev that saves me from having to build the toolchain manually all the time. It also ensures that it is built consistently and in the proper manner. I've seen many people here who've tried to build it by hand and not succeeded so it evidently does a good job.
One of the Gentoo staff, vapier/SpanKY, has an interest in exotic systems and included PS2 patches for the old toolchain. He also included a newer patch by a user called garlicbread for binutils 2.16.1 (probably the one ragnarok2040 just posted) but this was never tested and it actually doesn't work at all. It should never have gone into the Portage tree. I have made some improvements to the patch since then and have actually split it into three parts for IRX, the EE and the DVP. The number of changes I have made is evident by the fact the the ebuild revision is now up to r7. ;) Unless you're using Gentoo, the ebuild probably isn't of much interest to you but the tarball is here. Gentoo puts most of its toolchain patches in tarballs so I followed suit with binutils but I broke convention with GCC because of how often I was having to make changes. binutils should not require anymore changes.
That discussion about the short loop length bug was started by Pontus Lidman. I contacted him about it and he came here but quickly left because he couldn't get the toolchain to build. Humph! ;) Actually that was partially my fault because he chose the -linux-gnu target, which I hadn't tested in a while and it was indeed broken. It should work now.
I would approach the GNU guys and the Gentoo MIPS guys with some degree of caution. They become highly sceptical as soon as the PS2 is mentioned because they consider this to be a nearly impossible task and more often than not, the person asking the question has no idea what's involved. I know a guy who was actually kicked from an IRC room because of this. The GNU guys are also not very open to the idea of merging these changes upstream because they are just too messy. That's no fault of ours, it's simply because the R5900 is just too weird. Nevertheless, I have done my best to keep the patch clean and ensure it remains compatible with other MIPS hardware. I don't have any other MIPS hardware to test with but it should be okay. Even if they won't commit it upstream, this should at least help to keep it maintainable.
There is still at least one person who worked on the very first GCC 2.95 toolchain for Sony under Cygnus (Red Hat) and is still active within GNU. The one I know of is Ben Elliston but it took me a year just to convince him to change the incorrect official machine name (mips64vr5900 vs mips64r5900) for the PS2. The others may be more willing to help though.
I've found the Linux MIPS guys to be a bit more enthusiastic but I don't think they can help much with the toolchain. They weren't too interested in Linux 2.4 either but said that if I wanted to go for Linux 2.6 then they were more than willing to help.
I was hoping to attract the attention of mrbrown or MrHTFord, who both worked on the homebrew toolchain, but the former disappeared after being snapped up by a licensed PS2 game company and the latter also seems to have vanished into the ether.
I use Gentoo Linux most of the time and it has a tool called crossdev that saves me from having to build the toolchain manually all the time. It also ensures that it is built consistently and in the proper manner. I've seen many people here who've tried to build it by hand and not succeeded so it evidently does a good job.
One of the Gentoo staff, vapier/SpanKY, has an interest in exotic systems and included PS2 patches for the old toolchain. He also included a newer patch by a user called garlicbread for binutils 2.16.1 (probably the one ragnarok2040 just posted) but this was never tested and it actually doesn't work at all. It should never have gone into the Portage tree. I have made some improvements to the patch since then and have actually split it into three parts for IRX, the EE and the DVP. The number of changes I have made is evident by the fact the the ebuild revision is now up to r7. ;) Unless you're using Gentoo, the ebuild probably isn't of much interest to you but the tarball is here. Gentoo puts most of its toolchain patches in tarballs so I followed suit with binutils but I broke convention with GCC because of how often I was having to make changes. binutils should not require anymore changes.
That discussion about the short loop length bug was started by Pontus Lidman. I contacted him about it and he came here but quickly left because he couldn't get the toolchain to build. Humph! ;) Actually that was partially my fault because he chose the -linux-gnu target, which I hadn't tested in a while and it was indeed broken. It should work now.
I would approach the GNU guys and the Gentoo MIPS guys with some degree of caution. They become highly sceptical as soon as the PS2 is mentioned because they consider this to be a nearly impossible task and more often than not, the person asking the question has no idea what's involved. I know a guy who was actually kicked from an IRC room because of this. The GNU guys are also not very open to the idea of merging these changes upstream because they are just too messy. That's no fault of ours, it's simply because the R5900 is just too weird. Nevertheless, I have done my best to keep the patch clean and ensure it remains compatible with other MIPS hardware. I don't have any other MIPS hardware to test with but it should be okay. Even if they won't commit it upstream, this should at least help to keep it maintainable.
There is still at least one person who worked on the very first GCC 2.95 toolchain for Sony under Cygnus (Red Hat) and is still active within GNU. The one I know of is Ben Elliston but it took me a year just to convince him to change the incorrect official machine name (mips64vr5900 vs mips64r5900) for the PS2. The others may be more willing to help though.
I've found the Linux MIPS guys to be a bit more enthusiastic but I don't think they can help much with the toolchain. They weren't too interested in Linux 2.4 either but said that if I wanted to go for Linux 2.6 then they were more than willing to help.
I was hoping to attract the attention of mrbrown or MrHTFord, who both worked on the homebrew toolchain, but the former disappeared after being snapped up by a licensed PS2 game company and the latter also seems to have vanished into the ether.
That's what I thought too but the key difference is that the PS2 uses GP registers for the MMI instructions and I think that complicates things a bit.poutine wrote:As for the 128bits wide MMI instructions, I guess we could look at how gcc threat MMX with the Pentium. Pentiums are 32bits but mmx is 64bits if I remember correctly.
-
ragnarok2040
- Posts: 202
- Joined: Wed Aug 09, 2006 1:00 am
I accidentally deleted the binutils patches from my filesystem and I can't seem to access http://gps2.aura-online.co.uk/distfiles ... 15.tar.bz2 anymore. I thought I had them backed up but I didn't :/. Does anyone have a mirror?
I also confirmed that the gcc-4.3 patch does apply successfully to the latest gcc-4.3.2 sources. Unfortunately I need the binutils patch to continue any further.
I also confirmed that the gcc-4.3 patch does apply successfully to the latest gcc-4.3.2 sources. Unfortunately I need the binutils patch to continue any further.
Sorry, I've had further problems with my server that are beyond my control. I'm going to start hosting it myself next month. I've uploaded the binutils patches somewhere else in the meantime.
http://dev.gentooexperimental.org/~chew ... 15.tar.bz2
http://dev.gentooexperimental.org/~chew ... 15.tar.bz2
-
ragnarok2040
- Posts: 202
- Joined: Wed Aug 09, 2006 1:00 am
i think sticking with 2.4 would be more reasonable., because it seems more suited to lower memory setups. even at the cost of gcc version restriction.Regarding Linux, I have generally preferred the option of moving towards 2.6 rather than sticking with 2.4 because 2.4 has traditionally not compiled with GCC 4.
that said, i wonder what's more memory efficient - devfs or udev?
i'd like to help, but i guess i have a tons of things to read and try first.
One of the Gentoo staff, vapier/SpanKY, has an interest in exotic systems and included PS2 patches for the old toolchain. [/quot]i saw those patches when i poked around gentoo's cvs few months ago. i was pretty much suprised to see them, given one of the gentoo-mips maintainters opinion on ps2 architecture.
-
luncheonticket
- Posts: 7
- Joined: Sun Nov 30, 2008 2:29 am
hi guys! it'll be great for me to help on this project as much as i can...
i have some C experience (though quite a rookie, and only in x86) and i have access to a ps2 and to a compatible mips machine with gentoo (a Cobalt Qube), so i can compile directly to mips without using a cross-compiler... i also got access to a newer x86 linux box so i can do compilation work that may be too taxing to the qube (it only has a 150mhz cpu so kernel/toolchain compilation there takes time)
this is the machine i got access to:
it's got a 150MHz MIPS R5230 with 64Mb of RAM so if it's binary compatible with the ps2 (not sure about it) executables can be tried here before moving them to the ps2...
i don't know if this is of any help, but i'll try to do as much as i can... i'd really love to see linux working on my ps2 :)
regards,
Alejandro
i have some C experience (though quite a rookie, and only in x86) and i have access to a ps2 and to a compatible mips machine with gentoo (a Cobalt Qube), so i can compile directly to mips without using a cross-compiler... i also got access to a newer x86 linux box so i can do compilation work that may be too taxing to the qube (it only has a 150mhz cpu so kernel/toolchain compilation there takes time)
this is the machine i got access to:
Code: Select all
[0] [root@cobalto64:~] # uname -a
Linux cobalto64 2.6.16.4-mipsgit-20060320-4.1.1 #1 Thu Dec 20 04:10:40 ART 2007 mips64 Nevada V1.0 FPU V1.0 Cobalt Qube GNU/Linux
[0] [root@cobalto64:~] # cat /proc/cpuinfo
system type : Cobalt Qube
processor : 0
cpu model : Nevada V1.0 FPU V1.0
BogoMIPS : 145.40
byteorder : little endian
wait instruction : yes
microsecond timers : yes
tlb_entries : 48
extra interrupt vector : yes
hardware watchpoint : no
ASEs implemented :
VCED exceptions : not available
VCEI exceptions : not available
[0] [root@cobalto64:~] # gcc -v
Using built-in specs.
Target: mips64el-unknown-linux-gnu
Configured with: /var/tmp/portage/gcc-4.1.1/work/gcc-4.1.1/configure --prefix=/usr --bindir=/usr/mips64el-unknown-linux-gnu/gcc-bin/4.1.1 --includedir=/usr/lib/gcc/mips64el-unknown-linux-gnu/4.1.1/include --datadir=/usr/share/gcc-data/mips64el-unknown-linux-gnu/4.1.1 --mandir=/usr/share/gcc-data/mips64el-unknown-linux-gnu/4.1.1/man --infodir=/usr/share/gcc-data/mips64el-unknown-linux-gnu/4.1.1/info --with-gxx-include-dir=/usr/lib/gcc/mips64el-unknown-linux-gnu/4.1.1/include/g++-v4 --host=mips64el-unknown-linux-gnu --build=mips64el-unknown-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --with-abi=n32 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1)
[0] [root@cobalto64:~] # free -m
total used free shared buffers cached
Mem: 59 52 6 0 6 25
-/+ buffers/cache: 20 38
Swap: 295 0 295
i don't know if this is of any help, but i'll try to do as much as i can... i'd really love to see linux working on my ps2 :)
regards,
Alejandro
I'm afraid it's the differences between the PS2 and regular MIPS machines that are the problem so having access to other MIPS hardware doesn't really help very much.
I've wondered whether a PS2 emulator would help instead. I think I did get the stars demo running through PCSX2 at one point. If I recall correctly, it wasn't just a case of feeding it an ELF though. I had to create an ISO just to run it and that was rather irritating. That may have changed now so give it another look. The emulator didn't seem to provide much in the way of debug info though but I didn't look very hard so maybe I missed it.
I've wondered whether a PS2 emulator would help instead. I think I did get the stars demo running through PCSX2 at one point. If I recall correctly, it wasn't just a case of feeding it an ELF though. I had to create an ISO just to run it and that was rather irritating. That may have changed now so give it another look. The emulator didn't seem to provide much in the way of debug info though but I didn't look very hard so maybe I missed it.
-
luncheonticket
- Posts: 7
- Joined: Sun Nov 30, 2008 2:29 am
you're right, i was thinking about what i said earlier and even if the CPU is compatible, the rest of the HW probably isn't....Chewi wrote:I'm afraid it's the differences between the PS2 and regular MIPS machines that are the problem so having access to other MIPS hardware doesn't really help very much.
I've wondered whether a PS2 emulator would help instead. I think I did get the stars demo running through PCSX2 at one point. If I recall correctly, it wasn't just a case of feeding it an ELF though. I had to create an ISO just to run it and that was rather irritating. That may have changed now so give it another look. The emulator didn't seem to provide much in the way of debug info though but I didn't look very hard so maybe I missed it.
anyway, any pointers on where to start?
I think we really need a MIPS guru to take us through these last few steps with the toolchain but I admire your enthusiasm. I didn't know much more than you did when I started on this.
You'll need to know some MIPS assembly. I tried to tinker with GCC before learning this but, in truth, I didn't really know what I was doing till afterwards. You don't need to know every last detail, just a rough understanding of the principles and the basic instructions. This is what I used to teach myself. I didn't bother with any of the practical stuff since hacking GCC generally involves dealing with one instruction at a time rather than several lines of assembly.
You'll need to know some MIPS assembly. I tried to tinker with GCC before learning this but, in truth, I didn't really know what I was doing till afterwards. You don't need to know every last detail, just a rough understanding of the principles and the basic instructions. This is what I used to teach myself. I didn't bother with any of the practical stuff since hacking GCC generally involves dealing with one instruction at a time rather than several lines of assembly.
-
luncheonticket
- Posts: 7
- Joined: Sun Nov 30, 2008 2:29 am
-
luncheonticket
- Posts: 7
- Joined: Sun Nov 30, 2008 2:29 am
I don't know where you got that from.
The most we've seen from 2.6 was the first line of output. That was built with an almost vanilla GCC 4. It was almost like booting a regular MIPS Linux kernel with a PS2 graphics driver and expecting it to work. It wasn't that remarkable really.
I doubt you can build any of the Linux kernels with GCC 3.2.2.
The most we've seen from 2.6 was the first line of output. That was built with an almost vanilla GCC 4. It was almost like booting a regular MIPS Linux kernel with a PS2 graphics driver and expecting it to work. It wasn't that remarkable really.
I doubt you can build any of the Linux kernels with GCC 3.2.2.
this might be a bit offtopic, but what do you make out of this?
http://ftp.kaist.ac.kr/NetBSD/packages/ ... ystation2/
are those real ps2 builds of software, or just mips builds?
they seem pretty recent (at least rtorrent and links2 was, which i was interested in the most). and some of these appear to have been built with gcc-4.1.2.
http://ftp.kaist.ac.kr/NetBSD/packages/ ... ystation2/
are those real ps2 builds of software, or just mips builds?
they seem pretty recent (at least rtorrent and links2 was, which i was interested in the most). and some of these appear to have been built with gcc-4.1.2.
I'm a bit puzzled by that. I know Ed got NetBSD 2 going a long time ago but I thought nothing had been done since due to the toolchain. The official page says as much and it even links back to this place.
http://www.netbsd.org/ports/playstation2/
http://www.netbsd.org/ports/playstation2/
-
cukierek83
- Posts: 2
- Joined: Tue Dec 09, 2008 2:04 am
when i connect via filezilla so the "../NetBSD/playstation2/" is just linked to "../NetBSD/mipsel/" ... as i am new to this i don't know if mipsel means the ps2 cpu ...yoshi314 wrote:this might be a bit offtopic, but what do you make out of this?
http://ftp.kaist.ac.kr/NetBSD/packages/ ... ystation2/
are those real ps2 builds of software, or just mips builds?
they seem pretty recent (at least rtorrent and links2 was, which i was interested in the most). and some of these appear to have been built with gcc-4.1.2.