Porting of Linux 2.6 to PS2

[Mega Man]

Yes, single float is default for o32. There is no o32 for 64 bit. You get o32 with mipsr5900el or when enabling multilib with mips64r5900el and using -mabi=o32.

[archicharmer]

-mabi=o32

There is no flag -mabi=o32, but -mabi=32 both for mipsel-toolchain and for mips64elo32-toolchain.

Yes, i was wrong about -march=r5900 is forced to provide N32.

Ok now, recompiling mips64r5900el-toolchain into mipsr5900el-toolchain. And that strange for me: i'm building this toolchain without multilib, only for O32. And i'm using only 32bit libs from ubuntu-linux2.6-mips-libs.tgz Compiled toolchain provide MIPS-III files, but libs of glibc is MIPS-I. However, it working.

And one more thing. If enable -msoft-float patch for gcc - i'm getting messages: libgomp uses hard-float, but libgcc uses soft-float
Without -msoft-float patch: libgomp uses single-float, but libgcc uses double-float
And for printf testprogram:
With: testprogram.o uses hard-float, but crtXXXS.o uses soft-float
Without: testprogram.o uses single-float, but crtXXXS.o uses double-float
While libgcc compiling i saw flag -D__GCC_FLOAT_NOT_NEEDED - that's all right? And decimal FP not supported for this (perhaps means mips) target.

What configuration should i use??? What about these flag and decimal FP support?
BTW, please also tell me if you know how to know about which FP is used in compiled files with the help of such progs like readelf or objdump.

[Mega Man]

There is no flag -mabi=o32, but -mabi=32 both for mipsel-toolchain and for mips64elo32-toolchain.

Yes, this was what I meant.

And one more thing. If enable -msoft-float patch for gcc - i'm getting messages: libgomp uses hard-float, but libgcc uses soft-float
Without -msoft-float patch: libgomp uses single-float, but libgcc uses double-float
And for printf testprogram:
With: testprogram.o uses hard-float, but crtXXXS.o uses soft-float
Without: testprogram.o uses single-float, but crtXXXS.o uses double-float

Everything needs to be compiled with the same parameters from scratch. Old stuff should not be used. The mips*r5900* toolchains forces the configuration for floating point and could ignore the -m*-float parameters.

While libgcc compiling i saw flag -D__GCC_FLOAT_NOT_NEEDED - that's all right? And decimal FP not supported for this (perhaps means mips) target.

Currently I don't know.

BTW, please also tell me if you know how to know about which FP is used in compiled files with the help of such progs like readelf or objdump.

-msingle-float leads to this:
mips64r5900el-linux-gnu-objdump -xs single.o | tail -n 1
0000 410f0000 00676e75 00010700 00000402 A....gnu........
-mdouble-float leads to this:
mips64r5900el-linux-gnu-objdump -xs double.o | tail -n 1
0000 410f0000 00676e75 00010700 00000401 A....gnu........
-msoft-float leads to this:
mips64r5900el-linux-gnu-objdump -xs soft.o | tail -n 1
0000 410f0000 00676e75 00010700 00000403 A....gnu........

I updated the toolchain in CVS, but it is still not finished.

[archicharmer]

I updated the toolchain in CVS, but it is still not finished.

Multiple definitions of __muldi3 __negdi2 __lshrdi3 __ashldi3 __ashrdi3 __cmpdi2 __ucmpdi2 __divdi3 __moddi3 __udivdi3 __umoddi3 __udivmoddi4

Currently I don't know.

Please search, maybe this is important. Still there are mismatches with single and double float at least while libgcc compiling.

[Mega Man]

Multiple definitions of __muldi3 __negdi2 __lshrdi3 __ashldi3 __ashrdi3 __cmpdi2 __ucmpdi2 __divdi3 __moddi3 __udivdi3 __umoddi3 __udivmoddi4

This happened only with mipsr5900el. I fixed this now.

Please search, maybe this is important. Still there are mismatches with single and double float at least while libgcc compiling.

This happens when you still have old files like crti.o and crtn.o. You need to build GCC at least twice times to have it correctly. The first must have all libraries disabled. The uClibc can build crti.o and crtn.o. The full version of GCC can be build after this.
This is now correctly done in my build.sh from the simple-toolchain. The new version installs the files to /usr/local/ps2.

EDIT: There is now a buildroot environment available which builds using MIPS ABI n32 and soft-float. The new patch for GCC is used and the old patch for binutils is used. The old patch includes better support for VU instructions, but doesn't detect if bad instructions are used by the compiler.
One big problem with MIPS ABI n32 is that it requires large file support. Maybe there is a bug in the syscalls for the normal file size calls. It is difficult to debug this, because the shell is affected by the bug and the debugging utility "strace" requires large file support.
The buildroot environments supports also MIPS ABI o32. It should be possible to build everything with it, including X-server.

http://kernelloader.cvs.sourceforge....nux/buildroot/

[archicharmer]

I am not trusting buildroot as your's builds.sh. E-v-e-r-y source need to be compiled manually. Yes, it is long and need to know more. But it is detailed and any stage can be fixed faster.

A little notes. The superfluous modes in uclibc's build.sh. Now it has modes: build, install_headers, build_crt and install. The build mode includes build_crt; the install mode includes install_headers. All modes can't be activated until oldconfig is not made. If it is, then we need only make and install.
Algorithm mistake in simple-toolchain's build.sh. To use uClibc's headers we need to compile it by another gnu toolchain. For what i need another? For gcc-without-libs compiled we no need any (kernel/uClibc) headers. And then we can compile uClibc with it.
You removed the --with-llsc=no --with-float=single from gcc's configure and changed flag from -msingle-float to -msoft-float in uClibc's .config. Now mipsr5900el-toolchain (not 64) provide soft-float binaries - objdump shows 00000403. And that's normal, right?

If everything right, can i rebuild target-system to O32 and to not of single but of soft float? Agree?

Also, please download libps2dev-1.0.tar.bz2 and try to compile libvu0.c by these:
mipsr5900el-unknown-linux-gnu-gcc -S -Wall -fno-common -o libvu0.s libvu0.c
mipsr5900-unknown-linux-gnu-as -mr5900-legacy-vu0 -march=r5900 -o libvu0.o libvu0.s
- i am getting impossible constraint in 'asm' errors. See if you can rewrite asm volatiles right.

[Mega Man]

I am not trusting buildroot as your's builds.sh. E-v-e-r-y source need to be compiled manually. Yes, it is long and need to know more. But it is detailed and any stage can be fixed faster.

A script makes repeating it easier (because of changing -msoft-float and -msingle-float stuff).

A little notes. The superfluous modes in uclibc's build.sh. Now it has modes: build, install_headers, build_crt and install. The build mode includes build_crt; the install mode includes install_headers. All modes can't be activated until oldconfig is not made. If it is, then we need only make and install.
Algorithm mistake in simple-toolchain's build.sh. To use uClibc's headers we need to compile it by another gnu toolchain. For what i need another? For gcc-without-libs compiled we no need any (kernel/uClibc) headers. And then we can compile uClibc with it.

Compiling GCC without headers was always a problem in the past. It seems it is working with GCC 4.3, so I cleaned up the scripts.

You removed the --with-llsc=no --with-float=single from gcc's configure and changed flag from -msingle-float to -msoft-float in uClibc's .config. Now mipsr5900el-toolchain (not 64) provide soft-float binaries - objdump shows 00000403. And that's normal, right?

If everything right, can i rebuild target-system to O32 and to not of single but of soft float? Agree?

O32 can still use single float, soft float is not needed here. I was working on N32 and O32 is working with both single and soft, so I ignored this.

Also, please download libps2dev-1.0.tar.bz2 and try to compile libvu0.c by these:
mipsr5900el-unknown-linux-gnu-gcc -S -Wall -fno-common -o libvu0.s libvu0.c
mipsr5900-unknown-linux-gnu-as -mr5900-legacy-vu0 -march=r5900 -o libvu0.o libvu0.s
- i am getting impossible constraint in 'asm' errors. See if you can rewrite asm volatiles right.

Floating point registers are not available in GCC anymore because of -msoft-float. The compiler uses normal registers to store it. There must be fixes like:

--- libps2dev-1.0.orig/libvu0/libvu0.c	2012-12-31 11:02:53.000000000 +0100
+++ libps2dev-1.0/libvu0/libvu0.c	2012-12-31 17:34:30.621700779 +0100
@@ -135,7 +135,7 @@ void ps2_vu0_outer_product(ps2_vu0_fvect
 
 float ps2_vu0_inner_product(ps2_vu0_fvector v0, ps2_vu0_fvector v1)
 {
-	register float ret;
+	float ret;
 
 	asm __volatile__(
 	"lqc2    vf4,0x0(%1)\n"
@@ -144,8 +144,8 @@ float ps2_vu0_inner_product(ps2_vu0_fvec
 	"vaddy.x vf5,vf5,vf5\n"
 	"vaddz.x vf5,vf5,vf5\n"
 	"qmfc2   $2 ,vf5\n"
-	"mtc1    $2,%0"
-	: "=f" (ret)
+	"mr    $2,%0"
+	: "=&r" (ret)
 	: "r" (v0),
 	  "r" (v1)
 	: "$2");
@@ -343,8 +343,7 @@ void ps2_vu0_div_vector(ps2_vu0_fvector
 {
 	asm __volatile__(
 	"lqc2    vf4,0x0(%1)\n"
-	"mfc1    $8,%2\n"
-	"qmtc2    $8,vf5\n"
+	"qmtc2    %2,vf5\n"
 	"vdiv    Q,vf0w,vf5x\n"
 	"vwaitq\n"
 	"vmulq.xyzw      vf4,vf4,Q\n"
@@ -352,8 +351,7 @@ void ps2_vu0_div_vector(ps2_vu0_fvector
 	:
 	: "r" (v0),
 	  "r" (v1),
-	  "f" (q)
-	: "$8");
+	  "r" (q));
 }
 
 //==========================================================================
@@ -375,8 +373,7 @@ void ps2_vu0_div_vector_xyz(ps2_vu0_fvec
 {
 	asm __volatile__(
 	"lqc2    vf4,0x0(%1)\n"
-	"mfc1    $8,%2\n"
-	"qmtc2    $8,vf5\n"
+	"qmtc2    %2,vf5\n"
 "\n"
 	"vdiv    Q,vf0w,vf5x\n"
 	"vwaitq\n"
@@ -386,8 +383,7 @@ void ps2_vu0_div_vector_xyz(ps2_vu0_fvec
 	:
 	: "r" (v0),
 	  "r" (v1),
-	  "f" (q)
-	: "$8");
+	  "r" (q));
 }
 
 //==========================================================================
@@ -409,8 +405,7 @@ void ps2_vu0_inter_vector(ps2_vu0_fvecto
 	asm __volatile__(
 	"lqc2    vf4,0x0(%1)\n"
 	"lqc2    vf5,0x0(%2)\n"
-	"mfc1    $8,%3\n"
-	"qmtc2    $8,vf6\n"
+	"qmtc2    %3,vf6\n"
 "\n"
         "vaddw.x    vf7,vf0,vf0\n"
         "vsub.x    vf8,vf7,vf6\n"
@@ -422,8 +417,7 @@ void ps2_vu0_inter_vector(ps2_vu0_fvecto
 	: "r" (v0),
 	  "r" (v1),
 	  "r" (v2),
-	  "f" (t)
-	: "$8");
+	  "r" (t));
 }
 
 //==========================================================================
@@ -529,15 +523,13 @@ void ps2_vu0_scale_vector(ps2_vu0_fvecto
 {
 	asm __volatile__(
 	"lqc2    vf4,0x0(%1)\n"
-	"mfc1    $8,%2\n"
-	"qmtc2    $8,vf5\n"
+	"qmtc2    %2,vf5\n"
 	"vmulx.xyzw	vf6,vf4,vf5\n"
 	"sqc2    vf6,0x0(%0)"
 	:
 	: "r" (v0),
 	  "r" (v1),
-	  "f" (t)
-	: "$8");
+	  "r" (t));
 }
 
 //==========================================================================

This is still incomplete. The remaining errors are more complex and the code need to be written in a different way. For O32 you can use single float and it should work again without a patch. You need to use the old binutils patch from ragnarok2040 for this (not the one currently in CVS), because the current version doesn't have VU instructions.

[archicharmer]

Happy New Year!

I has recompiled glibc and now r5900el-gnu O32 toolchain provides msingle-float! Additionally i compiled binutils with ragnarok2040's VU support.

libps2dev compiled fine, but the samples of it are not. Mega Man, call for ragnarok again))

What's this - IMPORT_VPU_SYMBOL ??? Is it the definition?

----------------------------------------------------------------------------

Recompiling uClibc with make V=2. Saw -msoft-float using |:|.
I found what provides this - UCLIBC_HAS_FLOATS. We need this option, right? But it do add the -msoft-float flag while compiling!!! Perhaps we need to fix this.
Anyway, uClibc compiled fine without UCLIBC_HAS_FLOATS. Need advice.

[Mega Man]

Happy new year!

What's this - IMPORT_VPU_SYMBOL ??? Is it the definition?

IMPORT_VPU_SYMBOL puts symbols in a special section "__vpu_symtab". I think you to have linker script which contains this section. The symbols seem to be surrounded by __start___vpu_symtab and __stop___vpu_symtab. So you need to find the linker script which was used in the past for this.

Recompiling uClibc with make V=2. Saw -msoft-float using |:|.
I found what provides this - UCLIBC_HAS_FLOATS. We need this option, right? But it do add the -msoft-float flag while compiling!!! Perhaps we need to fix this.
Anyway, uClibc compiled fine without UCLIBC_HAS_FLOATS. Need advice.

"-msoft-float" is not activated by UCLIBC_HAS_FLOATS, but enabled by the disabled CLIBC_HAS_FPU. So you need to enable UCLIBC_HAS_FPU.

[archicharmer]

make[3]: Entering directory `/root/libps2dev/sample/basic3d/core'
mipsr5900el-unknown-linux-gnu-gcc -O2 -g -DDEBUG  -I /root/libps2dev/inst_incs -Wall -fno-common   -c -o main.o main.c
main.c:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token
main.c:27: error: 'My_texture1' undeclared here (not in a function)
main.c:42: error: expected specifier-qualifier-list before '__u128'
main.c: In function 'MakePacket':
main.c:211: error: 'QWdata' has no member named 'ul128'
main.c:212: error: 'QWdata' has no member named 'ul128'
main.c:234: error: 'QWdata' has no member named 'ul128'
main.c:234: error: '__u128' undeclared (first use in this function)
main.c:234: error: (Each undeclared identifier is reported only once
main.c:234: error: for each function it appears in.)
main.c:234: error: expected expression before ')' token
main.c:235: error: 'QWdata' has no member named 'ul128'
main.c:235: error: expected expression before ')' token
main.c:236: error: 'QWdata' has no member named 'ul128'
main.c:236: error: expected expression before ')' token
main.c: In function 'options':
main.c:287: warning: implicit declaration of function 'strcmp'
main.c: In function 'main':
main.c:384: warning: dereferencing type-punned pointer will break strict-aliasing rules
main.c:386: warning: dereferencing type-punned pointer will break strict-aliasing rules
main.c:531: warning: dereferencing type-punned pointer will break strict-aliasing rules
make[3]: *** [main.o] Error 1

- from executing Makefile as make CC=mipsr5900el-unknown-linux-gnu

Note that compile command not using -lps2dev, so i added -L/root/libps2dev/inst_objs/ -lps2dev (inst_objs directory contain libps2dev.a). No effect. I added -lps4dev - of course no effect, but there is no "cannot find -lps4dev" error! Trust me, i do not have it in my system))
It not search for libs only while VU sample progs compiling.
----------------------------------------------------------------------------

Gettext-0.17:

mipsr5900el-unknown-linux-uclibc-gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I.. -I../intl -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I../intl -I./libcroco -I/usr/local/ps3/mipsr5900el-unknown-linux-uclibc/include -g -O2 -c lock.c -o lock.o
/bin/sh ../libtool --tag=CC   --mode=compile mipsr5900el-unknown-linux-uclibc-gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I..  -I../intl -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I../intl   -I./libcroco  -I/usr/local/ps3/mipsr5900el-unknown-linux-uclibc/include  -g -O2 -c -o mbchar.lo mbchar.c
/bin/sh ../libtool --tag=CC   --mode=compile mipsr5900el-unknown-linux-uclibc-gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I..  -I../intl -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I../intl   -I./libcroco  -I/usr/local/ps3/mipsr5900el-unknown-linux-uclibc/include  -g -O2 -c -o mbslen.lo mbslen.c
 mipsr5900el-unknown-linux-uclibc-gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I.. -I../intl -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I../intl -I./libcroco -I/usr/local/ps3/mipsr5900el-unknown-linux-uclibc/include -g -O2 -c mbslen.c -o mbslen.o
 mipsr5900el-unknown-linux-uclibc-gcc -std=gnu99 -DHAVE_CONFIG_H -DEXEEXT=\"\" -DEXEEXT=\"\" -DEXEEXT=\"\" -I. -I.. -I../intl -I../intl -I.. -I.. -DDEPENDS_ON_LIBICONV=1 -DDEPENDS_ON_LIBINTL=1 -DLIBXML_STATIC -I../intl -I./libcroco -I/usr/local/ps3/mipsr5900el-unknown-linux-uclibc/include -g -O2 -c mbchar.c -o mbchar.o
In file included from mbslen.c:26: (lines 25-27 are #if HAVE_MBRTOWC #include "mbuiter.h" #endif)
mbuiter.h:112: error: expected specifier-qualifier-list before 'mbstate_t'
mbuiter.h: In function 'mbuiter_multi_next':
mbuiter.h:126: error: 'struct mbuiter_multi' has no member named 'next_done'
mbuiter.h:131: error: 'struct mbuiter_multi' has no member named 'cur'
mbuiter.h:142: warning: implicit declaration of function 'mbsinit'
mbuiter.h:142: error: 'struct mbuiter_multi' has no member named 'state'
mbuiter.h:145: error: 'struct mbuiter_multi' has no member named 'cur'
mbuiter.h:145: warning: implicit declaration of function 'mbrtowc'
mbuiter.h:146: error: 'struct mbuiter_multi' has no member named 'cur'
mbuiter.h:177: error: 'struct mbuiter_multi' has no member named 'state'
mbuiter.h:181: error: 'struct mbuiter_multi' has no member named 'next_done'
mbuiter.h: In function 'mbuiter_multi_reloc':
mbuiter.h:187: error: 'struct mbuiter_multi' has no member named 'cur'
mbuiter.h: In function 'mbuiter_multi_copy':
mbuiter.h:194: error: 'struct mbuiter_multi' has no member named 'state'
mbuiter.h:194: error: 'const struct mbuiter_multi' has no member named 'state'
mbuiter.h:194: error: 'mbstate_t' undeclared (first use in this function)
mbuiter.h:194: error: (Each undeclared identifier is reported only once
mbuiter.h:194: error: for each function it appears in.)
mbuiter.h:196: error: 'struct mbuiter_multi' has no member named 'state'
mbuiter.h:197: error: 'struct mbuiter_multi' has no member named 'next_done'
mbuiter.h:197: error: 'const struct mbuiter_multi' has no member named 'next_done'
mbuiter.h:198: error: 'struct mbuiter_multi' has no member named 'cur'
mbuiter.h:198: error: 'const struct mbuiter_multi' has no member named 'cur'
mbslen.c: In function 'mbslen':
mbslen.c:40: error: 'mbui_iterator_t' has no member named 'state'
mbslen.c:40: error: 'mbstate_t' undeclared (first use in this function)
mbslen.c:40: error: 'mbui_iterator_t' has no member named 'next_done'
mbslen.c:40: error: 'mbui_iterator_t' has no member named 'cur'

- something superfluous in uClibc is switched on. Now we have mbrtowc. Fix?
----------------------------------------------------------------------------------

To the question of O32 Tmodes. Maybe the decimal float is alternative for it?
It is not so easy to trick the compiler for using Tmodes. It wants that such mantissa need to be = 113:
__LDBL_MANT_DIG__ == 113 | 106 (from gcc/config/fp-bit.h)
MIPS target just can be built with decimal float support. It includes decimal128.
I mean __uint128_t or __u128 should to be replaced with same parameter of decimal128. Simple, i do not know with which)
And how to know the sizes of __uint128_t (which is not supported) and of decimal128 in O32 ??? Are they same?
Comments?