Printable View
Done.
Attachment 37480
gsxinit.c: 579:
gsxScreens[screenNum].margin_y = margin_y;
A few errors while testing vmlinux2.6_v10.gz:
module request: runaway loop modprobe personality-8
My PS2 is slim, so i do tests with initrd_busy.gz through ethernet cable. udev can't be started because i losing contact with loop-file using network while start_udev.
The code includes several instructions which can't be disassembled by gdb, because these are R5900 specific. One of it is:
0x10097448 <ddxProcessArgument+2076>: 0x70400013
Disassembled with the ps2dev toolchain this is:
mtlo1 v0
Interesting is that the "EE Core Instruction Set Manual" from Sony has an error. It tells that mtlo1 is 0x7000011 and not 0x70000013. The "TX System RISC TX79 Architecture" doesn't contain this error.
After this line there is another undefined instruction:
0x10097450 <ddxProcessArgument+2084>: 0x72821000
This is:
madd v0,s4,v0
I don't know why gdb doesn't know about this. This is also available on other mips CPUs. This instruction uses the lo0 register and not the lo1 register. I think it uses the wrong register for calculation.
How to solve this: I assume you used your patched compiler. Don't use mtlo1, mthi1, mfhi1 and mflo1 in the GCC. Remove everything what you have added. hi1 and lo1 are good for nothing. It is not needed, it is not faster and breaks everything.
Mega Man, i want to ask you to modify your simply toolchain a little. Consider patches which it includes, please, add to gcc an "march=r5900" option and opcodes pextlh and pcpyld to opcodes/mips-opc.c. Will you?
Yes, I will try to make something which increases R5900 support, removes slow stuff and keeps compatibility. Please collect everything you can find. I don't have an overview what is available, even if I made something of it. I mean I need all patches for binutils and gcc for all versions (including gcc 2.95, gcc 3 and gcc 4.3, Linux and ps2sdk/ps2dev.org, Chewi gcc 3 and gcc 4.0-4.3, my ubuntu toolchain, my simple toolchain and patches which you used). Please provide comments where it is from and what is working or not working (e.g. "GCC doesn't compile only xgcc working" or "Original toolchain from Sony, reference toolchain"). I want to sort the stuff, but I need all resources available. It will be easier when everything is prepared. Please include comment when you didn't find something or didn't get a patch (only source code). I don't need the binaries or build scripts. I am interested in an archive with all patches, descriptions and links to source code. You can also include stuff which were an epic fail, but you need to add the comment that it failed.
Also I need the information which combination of gcc and binutils are used.
Please provide information which patch did you used to get support for TI. I mean support for 128 bit registers (u128, uint128_t).
If you find a patch for glibc/newlib to provide fast user space mutex, please also include this. There must be a patch for libc which uses register k0 or k1 instead of instructions sc and ll. I saw a powerpoint which explained the speed enhancement.
I only asked for addition of -march=r5900 option for gcc... but this news of better.
Have i sooo bad english, reason you can't understand me?)) I did not apply any patches for TI mode - issue foundself when you made port of mips64el N32 linux. mips64elN32 compiler already have such mode by default.Quote:
Originally Posted by Mega Man
Treasure.7z
All here. Patches, comments.
Needed compiler - mipsEEel. We need to upgrade it. So, we need to pay attention for patches from mipsEEel-toolchain. All except - for acquaintance.
I commited a new version to CVS.
This uses binutils 2.22 (updated) and gcc 4.3.4 (old).
The binutils support all R5900 specific instructions except VPU0. The working instructions include pextlh and pcpyld.
The GCC supports -march=r5900. This tweaks the GCC a little bit. This is not enough to get ps2dev/ps2sdk stuff running. For Linux this is no problem. This should increase the speed of programs which used the special stuff.
mipsr5900el-linux-gnu-gcc and mips64r5900el-linux-gnu-gcc are preconfigured to -march=r5900.
I also fixed the handling of unaligned 64 bit accesses in the Linux kernel. Programs like NetworkManager received a SIGILL, because the kernel didn't emulated the access in 32 bit mode. This is now fixed.
I have built two types of this toolchain for mips64r5900el and for mips64el targets. Neither mips64r5900el-unknown-linux-gnu-gcc nor mips64el-unknown-linux-gnu-gcc -march=r5900 can't use special opcodes from binutils.
Option -march=r5900 exists, yes. But it doesn't making any effect of r5900 processor.
Error: opcode not supported on this processor: mips3 (mips3) 'sq... (or pextlw, etc.)'
These opcodes - sq, pextlw, pextlh, etc. uses T5 of R5900, so they do not supported on mips3 processor. Binutils is all right and must not be changed.
Option -march=r5900 must mean r5900 processor, not r4000, in spite of the fact that r5900 includes r4000. Oh, what i try to explain?! - you know it better than me! Just look at toolchains's codes one more time.
Parameter -march=r5900 is working here.
The following variants are working:
mips64el-linux-gnu-gcc -march=r5900
mips64r5900el-linux-gnu-gcc
If you have mips64r5900el-unknown-linux-gnu-gcc or mips64el-unknown-linux-gnu-gcc, you don't use my build script or even my toolchain.
Aa.. i doubt about word "unknown" between mips64r5900el and linux... but i have rebuilt it for mips64r5900el-linux-gnu.
It not works too. How you know is your toolchain support special r5900 opcodes? What program you use as prove for yourself?
I'm trying to compile XFree86-3.3.6-gsx. With Chewi's mips64r5900el-toolchain it can be compiled, but it not works. With your's mips64r5900el-toolchain it can't be compiled, even if it will work.
Of course i don't! You are ubuntu-lover)) All these "sudo" and apt-gets... besides, i always build by own hands.Quote:
Originally Posted by Mega Man
Yes, i do not sh your build.sh, but i see all include of it and do it by own hands.
Correct me, if i wrong on some place:
I did download of:
binutils-2.22-mipsel-ps2.patch
gcc-4.3.4-mips-ps2.patch
binutils-2.22.tar.bz2
gcc-4.3.4.tar.bz2
I have glibc-2.12.1 compiled and installed on /usr/local/mips64el-unknown-linux-gnu, did a symlink "mips64r5900el-linux-gnu" to it nearly;
For binutils:
tar -jxvf binutils-2.22.tar.bz2; cd binutils-2.22
patch -p1 < /path_to/binutils-2.22-mipsel-ps2.patch
mkdir build; cd build
../configure --prefix=/usr/local --target=mips64r5900el-linux-gnu --enable-shared --enable-targets=mips64r5900el-linux-gnu --enable-plugins --disable-werror
make -j 2; make install; cd ../../
For gcc:
tar -jxvf gcc-4.3.4.tar.bz2; cd gcc-4.3.4
patch -p1 < /path_to/gcc-4.3.4-mips-ps2.patch
mkdir build; cd build
../configure --prefix=/usr/local --target=mips64r5900el-linux-gnu --enable-languages=c,c++ --includedir=/usr/local/mips64r5900el-linux-gnu/include --disable-multilib
make -j 2; make install
Try to do as in Chewi's toolchain:
In patch №97 there is elf32l5900.sh
Section ARCH="mips:5900"
Try to include this when target=mips64r5900el-...
Normally I use /linux/minimalistic for testing. I also compiled a kernel which was successfully tested with Fedora 12.
I also tried the following test program:
This program doesn't make anything what is usable or runable, but it tests the R5900 instuction "lq":Code:void r5900_test(void)
{
__asm__ ("lq $3, 0($4)\n");
}
mips64el-linux-gnu-gcc -O2 -c -march=r5900 -o r5900test.o r5900test.c
mips64r5900el-linux-gnu-objdump -d r5900test.o
My script starts with deleting old stuff. You need something like:Code:r5900test.o: file format elf32-ntradlittlemips
Disassembly of section .text:
00000000 <r5900_test>:
0: 03e00008 jr ra
4: 78830000 lq v1,0(a0)
...
rm -r /usr/local/mips64el-unknown-linux-gnu
Otherwise you can't know if you use my toolchain or not.
My toolchain uses ubuntu-linux2.6-mips-headers.tgz and ubuntu-linux2.6-mips-libs.tgz. I don't know what you have in /usr/local/mips64el-unknown-linux-gnu.
--disable-multilib should disable support for ABI n32. The compiler gets unusable.Quote:
Originally Posted by archicharmer
I didn't tried c++.
I don't see any sense in changing this. Even r4000 doesn't need such adaption. The default elf32ltsmipn32.sh is good. Also this seems only to be used by the linker, but you have a problem with the assembler.Quote:
Originally Posted by archicharmer