Linux 2.6 on PS2
Hi, I've been following this thread for a while, and I want to start experimenting.
One question though, how do you set up gcc? I downloaded the gcc source, and applied your patch. I ran "./configure --target=mipsel --prefix=/path/in/my/home/dir && make", but it fails some ways in. Not that I expected it to be that easy (this is on linux btw). Any pointers on where to start/how to setup gcc-4?
Thanks.
One question though, how do you set up gcc? I downloaded the gcc source, and applied your patch. I ran "./configure --target=mipsel --prefix=/path/in/my/home/dir && make", but it fails some ways in. Not that I expected it to be that easy (this is on linux btw). Any pointers on where to start/how to setup gcc-4?
Thanks.
I'm just finishing up another small project before digging into this so I haven't tried it yet. I plan to use Gentoo's crossdev to do some of the hard work for me. According to the README, the target machine is supposed to be mips64el. I imagine this might change later if we manage to work some R5900-specific stuff back into the toolchain. Anyway, the CHOST should therefore be mips64el-linux-gnu or perhaps mips64el-scei-linux-gnu if you happen to do a lot of other MIPS work. scei was the manufacturer name chosen by the GNU guys. Before you build gcc though, you also need to build binutils in the same way.
the build command for gcc should be something like that
I was using this patched version because gcc insisted on generating 64 bit instructions not present on R5900. If you manage to run a kernel build with more official compilers let me know
Code: Select all
configure --prefix=/opt/mips64/ --target=mips64el-linux --disab
le-shared --disable-nls --disable-threads --enable-languages=cNice work guys!
It is kind of hard to find many playstation2 related kernel discussions. I first found chewi's post on the official PS2 linux forum, then tracked to his wiki, then his post on Gentoo, and finally here.
I am dying to see the new kernel running because the official PS2 kernel is ancient and does not take advantage of many exciting new features and performance optimizations (like better caching algorithms and interrupt handling). I have worked with 2.6 kernel and I am moderately familiar with it; but I lack knowledge on mips architecture and I am struggling to get a cross compiler working... Will try my best to catch up with your work and see what I can do to help.
One thing I'd like to remind you is that, I remember reading from somewhere that r5900 cpu does not have TAS (test-and-set) instruction that the normal mips cpu has. So implementing a correct spin-lock can be tricky. Here is a research paper on this topic: http://lc.linux.or.jp/lc2001/papers/tas-ps2-paper.pdf (From my limited Japanese vocabulary, I think they gave a viable solution in the paper)
I know it mainly concerns user-level program, however, I remember seeing some spin-lock usage when I was digging in 2.6 kernel network stack. Hopefully this hint helps somewhat. :D
It is kind of hard to find many playstation2 related kernel discussions. I first found chewi's post on the official PS2 linux forum, then tracked to his wiki, then his post on Gentoo, and finally here.
I am dying to see the new kernel running because the official PS2 kernel is ancient and does not take advantage of many exciting new features and performance optimizations (like better caching algorithms and interrupt handling). I have worked with 2.6 kernel and I am moderately familiar with it; but I lack knowledge on mips architecture and I am struggling to get a cross compiler working... Will try my best to catch up with your work and see what I can do to help.
One thing I'd like to remind you is that, I remember reading from somewhere that r5900 cpu does not have TAS (test-and-set) instruction that the normal mips cpu has. So implementing a correct spin-lock can be tricky. Here is a research paper on this topic: http://lc.linux.or.jp/lc2001/papers/tas-ps2-paper.pdf (From my limited Japanese vocabulary, I think they gave a viable solution in the paper)
I know it mainly concerns user-level program, however, I remember seeing some spin-lock usage when I was digging in 2.6 kernel network stack. Hopefully this hint helps somewhat. :D
Alex, could I just ask what your reasoning was behind using the R4600 as a starting point? The Linux/MIPS wiki states that the R5900 is most like the R5000. There is very little detail there but was there any particular reason why you didn't choose the R5000 instead?
I've been busy. ;) I grabbed Alex's patches and had a look. I was actually more interested in the gcc patch than the kernel patch at this stage because the kernel patch is useless without a working compiler. I was very surprised at just how short the gcc patch was but not in a good way. I had a think about whether a patch this short could really meet the bare minimum required to make the R5900 work properly at all. The only conclusion I could draw was that it couldn't possibly.
To be fair, I don't really understand what the patch actually does. Perhaps Alex could explain it in a bit more detail? All he did was remove some d, < and > characters. The big comment in mips.c about PRINT_OPERAND says this...
I can't really see how just removing those characters could effectively disable an instruction but then I still find the machine description file very cryptic so I could be missing something.
One of the best ways to know whether gcc is outputting valid code for the R5900 is to use a version of binutils patched for the R5900. The latest available patch is for 2.16.1, which is still quite recent and more than adequate. I cleaned up the opcodes, something I'd been meaning to do for a while. I stripped out the DVP code because that isn't needed right now. I also stripped out the IRX code because that probably won't be needed at all. I tested it against some files and it gave the same results as the old 2.14 version that most people here use so I deemed that a success.
I then did what was necessary to gcc 4.1.2 (Gentoo/MIPS says there's a problem with 4.2.0) to make it accept a CHOST of mips64vr5900el-scei-linux-uclibc, the same CHOST I had used for binutils. As I expected, gas screamed bloody murder because gcc was outputting instructions not present on the R5900. Using the gcc 3.2.2 patch as a guide, I then starting making the absolutely necessary adjustments. This included adding MASK_SINGLE_FLOAT to TARGET_DEFAULT, enabling floating point emulation, forcing LONG_DOUBLE_TYPE_SIZE to 64 and setting Pmode to SImode. After a few attempts, I eventually got it to build. But what to test it with?
I tried building the kernel using Alex's patch. It fell flat on its face. I then tried building uClibc 0.9.29. Even with most of the options enabled, it got all the way to the final linking before failing with a few undefined references. This was actually a better result than I expected.
I'm not stumped yet. I have a few ideas. I know there are a few things I haven't covered like preventing gcc from emitting the ll/lld/sc/scd MIPS2 instructions. I can't figure out where these are in the machine definition. I'm not even sure if they're there at all. The Linux kernel has options for building with or without ll/sc and lld/scd but what about stuff other than the kernel? I also haven't added support for the movn/movz MIPS4 instructions yet. There are a bunch of other improvements the old patch makes but I don't think these are essential. They include support for the 128-bit instructions.
The old patch includes some code to fix the R5900 short loop length bug. I have read that it would be easier for gas to address this issue but it was done in gcc in case you were using an assembler other than gas. gas already warns the user if the loop is too short so it should just be a case of adding NOPs. That's probably easy if you know how but I don't know how! I did see a mailing list discussion with someone who was attempting to do it though so maybe I'll get in contact with them.
If you're interested in my gcc work, let me know and I'll put it up but regardless of whether you are or not, I highly recommend that you use an R5900-patched version of binutils. If you don't, you could simply be trying to run code on the PS2 that will never work.
To be fair, I don't really understand what the patch actually does. Perhaps Alex could explain it in a bit more detail? All he did was remove some d, < and > characters. The big comment in mips.c about PRINT_OPERAND says this...
Code: Select all
'd' output integer constant in decimal
'<' Turn on .set nomacro
'>' Turn on .set macroOne of the best ways to know whether gcc is outputting valid code for the R5900 is to use a version of binutils patched for the R5900. The latest available patch is for 2.16.1, which is still quite recent and more than adequate. I cleaned up the opcodes, something I'd been meaning to do for a while. I stripped out the DVP code because that isn't needed right now. I also stripped out the IRX code because that probably won't be needed at all. I tested it against some files and it gave the same results as the old 2.14 version that most people here use so I deemed that a success.
I then did what was necessary to gcc 4.1.2 (Gentoo/MIPS says there's a problem with 4.2.0) to make it accept a CHOST of mips64vr5900el-scei-linux-uclibc, the same CHOST I had used for binutils. As I expected, gas screamed bloody murder because gcc was outputting instructions not present on the R5900. Using the gcc 3.2.2 patch as a guide, I then starting making the absolutely necessary adjustments. This included adding MASK_SINGLE_FLOAT to TARGET_DEFAULT, enabling floating point emulation, forcing LONG_DOUBLE_TYPE_SIZE to 64 and setting Pmode to SImode. After a few attempts, I eventually got it to build. But what to test it with?
I tried building the kernel using Alex's patch. It fell flat on its face. I then tried building uClibc 0.9.29. Even with most of the options enabled, it got all the way to the final linking before failing with a few undefined references. This was actually a better result than I expected.
Code: Select all
CC libc/sysdeps/linux/common/ssp-local.os
CC libc/misc/internals/__uClibc_main.os
CC libc/inet/rpc/rpc_thread.os
CC libc/stdlib/atexit.os
AS lib/crt1.o
AS lib/Scrt1.o
AS lib/crti.o
AS lib/crtn.o
STRIP -x -R .note -R .comment lib/libc.a
AR cr lib/libc.a
STRIP -x -R .note -R .comment lib/uclibc_nonshared.a
AR cr lib/uclibc_nonshared.a
AR cr libc/libc_so.a
make[3]: `conf' is up to date.
ln -fs sgidefs.h ./include/
LD libuClibc-0.9.29.so
libc/libc_so.a(difftime.os): In function `difftime':
difftime.c:(.text+0x14): undefined reference to `__floatsidf'
difftime.c:(.text+0x3c): undefined reference to `__subdf3'
libc/libc_so.a(_fpmaxtostr.os): In function `_fpmaxtostr':
_fpmaxtostr.c:(.text+0xc0): undefined reference to `__nedf2'
_fpmaxtostr.c:(.text+0xe8): undefined reference to `__eqdf2'
_fpmaxtostr.c:(.text+0x10c): undefined reference to `__ltdf2'
_fpmaxtostr.c:(.text+0x114): undefined reference to `__divdf3'
_fpmaxtostr.c:(.text+0x1b8): undefined reference to `__muldf3'
_fpmaxtostr.c:(.text+0x344): undefined reference to `__gedf2'
_fpmaxtostr.c:(.text+0x3d8): undefined reference to `__adddf3'
libc/libc_so.a(__psfs_do_numeric.os): In function `__psfs_do_numeric':
__psfs_do_numeric.c:(.text+0x5fc): undefined reference to `__truncdfsf2'
libc/libc_so.a(strtof.os): In function `strtof':
strtof.c:(.text+0x40): undefined reference to `__extendsfdf2'
/usr/lib/gcc/mips64vr5900el-scei-linux-uclibc/4.1.2/libgcc.a(_fixunsdfsi.o): In function `__fixunsdfsi':
: undefined reference to `__fixdfsi'
make[1]: *** [lib/libc.so] Error 1
make: *** [lib/libc.so.0] Error 2The old patch includes some code to fix the R5900 short loop length bug. I have read that it would be easier for gas to address this issue but it was done in gcc in case you were using an assembler other than gas. gas already warns the user if the loop is too short so it should just be a case of adding NOPs. That's probably easy if you know how but I don't know how! I did see a mailing list discussion with someone who was attempting to do it though so maybe I'll get in contact with them.
If you're interested in my gcc work, let me know and I'll put it up but regardless of whether you are or not, I highly recommend that you use an R5900-patched version of binutils. If you don't, you could simply be trying to run code on the PS2 that will never work.
Last edited by Chewi on Mon Jul 30, 2007 1:31 am, edited 1 time in total.
Heh I fixed the problem affecting uClibc a little sooner than expected! Turns out floating point emulation is enabled by default and I'd overridden the correct settings with some incorrect ones. uClibc now builds without any errors. Whether it works or not is another matter. I do get a lot of "cast from pointer to integer of different size" warnings but I'm hoping that's normal. I guess I'll start looking at the kernel next.
Be careful on those warnings. Since you are now building 64bit kernel instead on 32bit, those warning are significant: whenever you cast an 32 bit int to 64 bit pointer it will try to "sign-extend" the address; whenever you cast 64 bit pointer to 32bit int, the number is truncated.Chewi wrote:I do get a lot of "cast from pointer to integer of different size" warnings but I'm hoping that's normal. I guess I'll start looking at the kernel next.
If you happend to have a low address, it will work out OK:
0x0000000000123456 -> 0x00123456 -> 0x0000000000123456
But it is not OK if you have a high address:
0x000000FFFF123456 -> 0xFF123456 -> 0xFFFFFFFFFF123456
Once a strange error of random crash (userlevel program) buged me for hours, and it turned out to be caused by this case.
You are right, indeed that patch does not really address R5900 problems, it just remove doubleword version of some instruction from "<d>" means something like "use doubleword instruction if asked". But I'm easily wrong about that. I've little to none knowledge about gcc internals. That was a quick hack to make the kernel run, and i'm happy to see that removed. Good work Chewi. I'm now leaving for vacation. So i will probably not be active for a month or so.Chewi wrote:I grabbed Alex's patches and had a look. I was actually more interested in the gcc patch than the kernel patch at this stage because the kernel patch is useless without a working compiler. I was very surprised at just how short the gcc patch was but not in a good way. I had a think about whether a patch this short could really meet the bare minimum required to make the R5900 work properly at all. The only conclusion I could draw was that it couldn't possibly.
Greetings,
Alessandro
Time for an update. I've moved up to gcc 4.2.0 after discovering that the problem was only with a patch being applied by Gentoo. It works when I don't apply this patch. I have also added support for the MIPS4 conditional move instructions. That's the good news.
The bad news is I still can't stop those warnings from appearing, though I have dug quite deep into the problem. I initially thought it was because I hadn't redefined POINTER_SIZE as 32 but that didn't fix it. I realised that it wasn't using 64-bit longs by default even though I had added MASK_LONG64 to TARGET_DEFAULT. I fixed that but now I'm also getting the opposite warning of "cast to pointer from integer of different size". I modified the first warning to give me more information.
The pointer type varies but it's always 32-bit. The integer type is always a 64-bit long long int. It should be a 32-bit int. I have no idea where it's getting long long int from but I'm trying to find out. mips.h includes this.
As I said, POINTER_SIZE is now 32 so it should be using the right types. But even if it were 64, neither of these say long long int so where is it coming from? Suggestions welcome!
The bad news is I still can't stop those warnings from appearing, though I have dug quite deep into the problem. I initially thought it was because I hadn't redefined POINTER_SIZE as 32 but that didn't fix it. I realised that it wasn't using 64-bit longs by default even though I had added MASK_LONG64 to TARGET_DEFAULT. I fixed that but now I'm also getting the opposite warning of "cast to pointer from integer of different size". I modified the first warning to give me more information.
Code: Select all
warning: cast from pointer ('void *', 32) to integer ('long long int', 64) of different sizeCode: Select all
#undef SIZE_TYPE
#define SIZE_TYPE (POINTER_SIZE == 64 ? "long unsigned int" : "unsigned int")
#undef PTRDIFF_TYPE
#define PTRDIFF_TYPE (POINTER_SIZE == 64 ? "long int" : "int")Hey Chewi, what version/patch of binutils are you using for that?
I tried compiling alexp's kernel with the ps2dev toolchain (gcc-3.2.2), but it dies early on with an error of
and many of these
I thought it was worth a shot.
I tried compiling alexp's kernel with the ps2dev toolchain (gcc-3.2.2), but it dies early on with an error of
Code: Select all
include/asm/sgidefs.h:18:2: #error Use a Linux compiler or give up.Code: Select all
include/asm/io.h:119: warning: cast from pointer to integer of different sizeI am familiar with that first error, you need to build the toolchain with "linux" somewhere in the CHOST. I doubt that will be enough to make the ps2dev version of gcc work though.
Funny you should mention binutils, I was going to commit my binutils stuff tonight. I've had to delay it though because I want to get the GNU guys to fix the R5900 machine name first. If you look at /usr/share/gnuconfig/config.sub (on Gentoo, at least), you'll see an entry that says mips64vr5900el. This should be mips64r5900el. That v was apparently added in error. As a result, I've had to incorrectly use "vr5900" in all my patches. I'd rather get this fixed now than later. I sent an e-mail with a patch tonight and I await their reply. Once I've heard back, I'll commit binutils and let you know.
Funny you should mention binutils, I was going to commit my binutils stuff tonight. I've had to delay it though because I want to get the GNU guys to fix the R5900 machine name first. If you look at /usr/share/gnuconfig/config.sub (on Gentoo, at least), you'll see an entry that says mips64vr5900el. This should be mips64r5900el. That v was apparently added in error. As a result, I've had to incorrectly use "vr5900" in all my patches. I'd rather get this fixed now than later. I sent an e-mail with a patch tonight and I await their reply. Once I've heard back, I'll commit binutils and let you know.
This is starting to make my head hurt. I hadn't let uClibc finish building for a while and I realised that enabling 64-bit longs by default was causing it to fail. Digging a bit deeper, I realised that uClibc was assuming that if you have 64-bit longs then your word size must also be 64. However, the word size was set to 32, the same as the pointer size, hence the failure. From what little I can gather, the PS2's word size is 32. This makes sense. So why does the ps2sdk gcc 3.2.2 enable 64-bit longs by default? I know the PS2 has 64-bit integer registers but it also has a 32-bit address space. Which should I favour here?
It turns out the guy I contacted about the machine name worked under Cygnus on the toolchain for the original PS2 Linux release! He was sure they'd used "vr5900" but after exchanging a few e-mails, I managed to convince him otherwise. "I stand corrected!" That patch will go into GNU CVS in the next couple of weeks. Unless you're a Gentoo user who uses crossdev, you needn't worry about it though.
I've now committed my latest binutils patchset. Gentoo users need to go here. Others can grab the patchset directly here. The relevant patches are #97, #98 and #99 though only #97 is really needed for now. Note that this hasn't actually been tested on the PS2 yet but it hasn't changed a great deal from the last patchset. You should set a CTARGET of mips64r5900el-scei-linux-uclibc.
I've now committed my latest binutils patchset. Gentoo users need to go here. Others can grab the patchset directly here. The relevant patches are #97, #98 and #99 though only #97 is really needed for now. Note that this hasn't actually been tested on the PS2 yet but it hasn't changed a great deal from the last patchset. You should set a CTARGET of mips64r5900el-scei-linux-uclibc.
Chewi, how does one use a CTARGET?
I tried using --target=mips64r5900el-scei-linux-uclibc for binutils, but it choked on the -uclibc part, so I changed it to -gnu. Then, gcc complained that it couldn't recognize the chost, so I changed it to mipsel-linux-gnu (going for lowest common denominator). gcc died eventually - after rebuilding binutils - with which is baffling to me, as it is apparently a mips1 instruction.
I'm not using portage to install this, as I want to learn how it's put together (and I don't want to fubar my gentoo install :P ). Therefore, everything is being built as a lowly user, and installed with --prefix=~/ps2dev/buildroot
I tried using --target=mips64r5900el-scei-linux-uclibc for binutils, but it choked on the -uclibc part, so I changed it to -gnu. Then, gcc complained that it couldn't recognize the chost, so I changed it to mipsel-linux-gnu (going for lowest common denominator). gcc died eventually - after rebuilding binutils - with
Code: Select all
Error: opcode not supported on this processor: mips1 (mips1) `c.lt.s $f0,$f2'I'm not using portage to install this, as I want to learn how it's put together (and I don't want to fubar my gentoo install :P ). Therefore, everything is being built as a lowly user, and installed with --prefix=~/ps2dev/buildroot
You specified it correctly. Did you apply the patches by hand? You've just reminded me that uClibc support requires some small patches that Gentoo will apply if you use the ebuild. The patchset can be found on the Gentoo mirrors and is called binutils-2.16.1-uclibc-patches-1.1.tar.bz2. Simply changing -uclibc to -gnu should have worked though. I wonder if it's trying to use the config.sub from /usr/share/gnuconfig/config.sub. If so, the vr5900 names need fixing. Using mipsel will not work because it's not specific enough.
I do recommend using crossdev because this stuff is complicated enough already. It'll install everything to the right place and it will not fubar your system. :P You can remove the resulting installation using emerge -C cross-mips64r5900el-scei-linux-uclibc/binutils. I had a user install both binutils and my patched gcc 4 using crossdev tonight and it worked out okay.
I do recommend using crossdev because this stuff is complicated enough already. It'll install everything to the right place and it will not fubar your system. :P You can remove the resulting installation using emerge -C cross-mips64r5900el-scei-linux-uclibc/binutils. I had a user install both binutils and my patched gcc 4 using crossdev tonight and it worked out okay.
Good news! I visited #gcc where I spoke to another guy who'd worked on the original toolchain, a guy who worked for Sony on the PS3 toolchain and another very helpful guy. I was afraid I'd get ignored or insulted but it wasn't like that at all.
The helpful guy explained that most code expects long sizes and pointer/word sizes to be the same, which is what I had suspected. He suggested either using 64-bit pointers or 32-bit longs.
The PS2 guy explained that enabling 64-bit longs effectively changes the ABI, which isn't something we want to do. Based on that, I decided to disable 64-bit longs despite the fact that they were enabled in 3.2.2.
What I ended up with was actually less code than before, which I think is a good sign. I was still getting the cast warnings though. In an attempt to flush out the culprit, I did something a little unusual. I replaced instances of "long long" with "long" in entire parts of the uClibc tree to see what would happen. I eventually tracked down the problem to libc/sysdeps/linux/mips/bits/syscalls.h. The syscalls were being made with long long arguments. The code looks like this...
Defining ARG_TYPE as long does stop the warnings but I'm not sure if this is the right thing to do. I have found a recent interesting post relating to glibc, which appears to be about the same issue. I'll give the technique a try later.
The helpful guy explained that most code expects long sizes and pointer/word sizes to be the same, which is what I had suspected. He suggested either using 64-bit pointers or 32-bit longs.
The PS2 guy explained that enabling 64-bit longs effectively changes the ABI, which isn't something we want to do. Based on that, I decided to disable 64-bit longs despite the fact that they were enabled in 3.2.2.
What I ended up with was actually less code than before, which I think is a good sign. I was still getting the cast warnings though. In an attempt to flush out the culprit, I did something a little unusual. I replaced instances of "long long" with "long" in entire parts of the uClibc tree to see what would happen. I eventually tracked down the problem to libc/sysdeps/linux/mips/bits/syscalls.h. The syscalls were being made with long long arguments. The code looks like this...
Code: Select all
#if _MIPS_SIM == _ABIO32 || _MIPS_SIM == _ABI64
# define ARG_TYPE long
#else
# define ARG_TYPE long long
#endifI'm starting to think the warnings should just be ignored. It occurs because 32-bit pointers are inserted into 64-bit argument registers. Do bad things happen if you insert 32-bit longs into 64-bit integer registers? I don't know enough about assembly yet. I tried asking in #uclibc but I was in the channel for most of the day and no one said a thing.
I tried using your portage overlay, but it still didn't install. (crossdev -t mips64r5900el-scei-linux-uclibc). I've used crossdev before to install sparc and hppa toolchains, though I've only used them with distcc to install stuff. I'm trying again manually with a --target=mips64r5900el-unknown-linux-gnu, to see if it was the scei that threw gcc off. If I understand what its for, we should probably drop it anyways, since this isn't the official ps2 linux w/RTE.
Ok, I downloaded binutils-2.16.1 and gcc-4.2.1 from gnu.org. I patched binutils with patches 97, 98 and 99 from that patch tarball, and gcc with the gcc patch you provided (was I supposed to apply both? does only gcc-4.2.0 work?)
in binutils dir:
./configure --prefix=~/ps2dev/linux-2.6.21-ps2/buildroot --target=mips64r5900el-unknown-linux-gnu
make
make install
export PATH=$PATH:~/ps2dev/linux-2.6.12-ps2/buildroot
in gcc dir:
./configure --prefix=~/ps2dev/linux-2.6.21-ps2/buildroot --target=mips64r5900el-unknown-linux-gnu --enable-languages=c
and it's compiling for now. Does that look right?
[edit]
it just died complaining something about threads:
I'll try disabling them and try again.
[edit2] nope. same spot.
[edit3] ok, cleaned out and tried again. now its complaining about a missing -lc. at least i'm getting closer!
hmm.. how do I build glibc if I don't yet have a compiler?
Ok, I downloaded binutils-2.16.1 and gcc-4.2.1 from gnu.org. I patched binutils with patches 97, 98 and 99 from that patch tarball, and gcc with the gcc patch you provided (was I supposed to apply both? does only gcc-4.2.0 work?)
in binutils dir:
./configure --prefix=~/ps2dev/linux-2.6.21-ps2/buildroot --target=mips64r5900el-unknown-linux-gnu
make
make install
export PATH=$PATH:~/ps2dev/linux-2.6.12-ps2/buildroot
in gcc dir:
./configure --prefix=~/ps2dev/linux-2.6.21-ps2/buildroot --target=mips64r5900el-unknown-linux-gnu --enable-languages=c
and it's compiling for now. Does that look right?
[edit]
it just died complaining something about threads:
Code: Select all
../.././gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directory
../.././gcc/gthr-posix.h:44:20: error: unistd.h: No such file or directory[edit2] nope. same spot.
[edit3] ok, cleaned out and tried again. now its complaining about a missing -lc. at least i'm getting closer!
hmm.. how do I build glibc if I don't yet have a compiler?
If you tried to build gcc from my overlay, it won't have worked because I have only committed 3.0.4 there. I don't want to commit stuff that is likely not to work, though I'm now thinking about adding it with KEYWORDS="-*" or something. The last part of the log from crossdev would be helpful. "scei" isn't the problem, it worked for me and my friend. I think it looks better than "unknown". :P
Your other issues are the sort of things I've seen from trying to do this manually in the past. It's why I use crossdev! You don't need a libc to build a basic C compiler.
Your other issues are the sort of things I've seen from trying to do this manually in the past. It's why I use crossdev! You don't need a libc to build a basic C compiler.
I noticed your gcc overlay, but didn't install it since its so old.
I tried crossdev yet again, this time using both:
crossdev -t mips64r5900el-unknown-linux-gnu
crossdev -t mips64r5900el-unknown-linux-uclibc
This got much farther along, but of course, plain gcc-4.2.1 doesn't build since your patch doesn't get applied (unsupported opcode error, both times). I believe "unknown" is the default/generic vendor name for most systems, with the exception of "pc" in i686-pc-linux-gnu. Sparc, hppa, and amd64 all use unknown.
As far as doing it manually, you're right I don't need libc, just the headers from it and the linux kernel. I believe I have them installed, but it seems to be trying to use the i386 kernel headers instead of mips. I'm going to mess with it some more to see if I can get gcc working.
I tried crossdev yet again, this time using both:
crossdev -t mips64r5900el-unknown-linux-gnu
crossdev -t mips64r5900el-unknown-linux-uclibc
This got much farther along, but of course, plain gcc-4.2.1 doesn't build since your patch doesn't get applied (unsupported opcode error, both times). I believe "unknown" is the default/generic vendor name for most systems, with the exception of "pc" in i686-pc-linux-gnu. Sparc, hppa, and amd64 all use unknown.
As far as doing it manually, you're right I don't need libc, just the headers from it and the linux kernel. I believe I have them installed, but it seems to be trying to use the i386 kernel headers instead of mips. I'm going to mess with it some more to see if I can get gcc working.
Please bear with me, I do intend to make this stuff install more reliably through crossdev soon.
Since uClibc is of no use without a kernel, I've decided to move onto the next stage. That would be the kernel but first I want to see that my gcc patch is working to some extent. This means trying some home brew stuff.
I modified my patches slightly and managed to build binutils and gcc for mips64r5900-scei-elf. crossdev then tried to build the latest version of newlib but this failed. I grabbed the old newlib patch from the ps2toolchain package that's available here. What a mess! Whoever prepared that patch must have been smoking something. Fortunately, it was very easy to pick out the important bits from amongst the mess. I applied these to the latest version of newlib and after a bit of work, I managed to get that to build.
I then tried to build the "ee" part of ps2sdk. There were a lot of cast warnings but this didn't surprise me because it expects 64-bit longs. I had to fix a few code errors due to gcc 4 being stricter than gcc 3. After a while, it asked for a C++ compiler. Uh oh. I hadn't expected that. I told crossdev to build gcc again with C++ for mips64r5900-scei-elf and to my surprise, it worked first time. I carried on building ps2sdk and it eventually asked for some IOP-related stuff that I hadn't built yet. I'll need to build the IOP toolchain before I can continue. I'll probably try that tomorrow.
Since uClibc is of no use without a kernel, I've decided to move onto the next stage. That would be the kernel but first I want to see that my gcc patch is working to some extent. This means trying some home brew stuff.
I modified my patches slightly and managed to build binutils and gcc for mips64r5900-scei-elf. crossdev then tried to build the latest version of newlib but this failed. I grabbed the old newlib patch from the ps2toolchain package that's available here. What a mess! Whoever prepared that patch must have been smoking something. Fortunately, it was very easy to pick out the important bits from amongst the mess. I applied these to the latest version of newlib and after a bit of work, I managed to get that to build.
I then tried to build the "ee" part of ps2sdk. There were a lot of cast warnings but this didn't surprise me because it expects 64-bit longs. I had to fix a few code errors due to gcc 4 being stricter than gcc 3. After a while, it asked for a C++ compiler. Uh oh. I hadn't expected that. I told crossdev to build gcc again with C++ for mips64r5900-scei-elf and to my surprise, it worked first time. I carried on building ps2sdk and it eventually asked for some IOP-related stuff that I hadn't built yet. I'll need to build the IOP toolchain before I can continue. I'll probably try that tomorrow.
Code: Select all
Error: opcode not supported on this processor: mips1 (mips1) `c.lt.s $f0,$f2'Code: Select all
make[2]: Entering directory `/home/chewi/ps2toolchain/ps2sdk/iop/dev9/dev9'
mipsel-scei-irx-gcc -fno-builtin -fno-builtin -nostdlib -s -o bin/ps2dev9.irx obj/ps2dev9.o obj/exports.o obj/imports.o
/usr/libexec/gcc/mipsel-scei-irx/ld: failed to resolve the irx name
collect2: ld returned 1 exit status
make[2]: *** [bin/ps2dev9.irx] Error 1
make[2]: Leaving directory `/home/chewi/ps2toolchain/ps2sdk/iop/dev9/dev9'
make[1]: *** [all-dev9] Error 2
make[1]: Leaving directory `/home/chewi/ps2toolchain/ps2sdk/iop/dev9'
make: *** [all-dev9] Error 2It turned out to be the -funit-at-a-time optimisation. Building with -O0 worked okay. I didn't want to disable optimisation completely though so I made -fno-unit-at-a-time (as well as -fno-merge-constants) a default option. That works great. Now I'm sifting through more code strictness errors.
edit: The IOP part of ps2sdk now builds successfully. :D
edit: The IOP part of ps2sdk now builds successfully. :D
I took IOMANX.IRX, PS2IP.IRX, PS2IPS.IRX and PS2DEV9.IRX and put them on a memory card with uLaunchELF. I'm not sure which IRX's are used for what but I'm guessing the "IP" ones are used for networking. I tried renaming my existing PS2IP.IRX while connected via FTP and it wouldn't let me so I guess that means it was in use. With these new IRX's installed, I was still able to use FTP . I guess that means it works? Can anyone confirm this? The real acid test will be to build uLaunchELF itself. I'll try that soon.