Porting of Linux 2.6 to PS2

[AKuHAK]

Is it possible to add support for apa partitions in kernel? I was trying to launch it from HDD formatted with ps2fdisk_0.9.3 but kernel 2.6 doesn't see partitions at all but all other kernels give me dma bind error

[Mega Man]

When you run apascan from an initrd, it should be possible to use it.

@archicharmer: The atomic operations and the graphic driver need to be optimzed for r5900, but I am still at the toolchain. After discussing with people from the GCC mailing list I came to the result that -msoft-float must be used for o32 and n32. This is currently the only way to get full compatibility with IEEE 754. The kernel can also be configured to emulate it, but this would be slower.
When you build everything from scratch, it is quite normal that you run into problems which were already solved. I don't want to handle these problems, that's why I used buildroot.

[archicharmer]

When you run apascan from an initrd, it should be possible to use it

For kernel2.6 we have only busybox initrd which have no apascan.

the result that -msoft-float must be used for o32 and n32

Actually, i noted it but thought that it just coincidence - kernel recompiled for single-float loads init a bit slower than yours compiled for soft-float.

What about VU using in linux?
We can use VU for O32, but O32 has no TImode;
N32 handle TImode, but VU should be optimized for N32.

run into problems which were already solved. I don't want to handle these problems

Whose system? Who are creator of The Gold Kernel?)))
Of course from my side i need your assist and from your side you can pre-fix little disagreements maybe in your sources. The questions wrote here not for you become suffering to answer to each of them)) - for cooperative agreement.
Before rebuilding system i want to complete at least one. The decision for alsa-lib is editing iatomic.h all extern of atomic_sub/add/return to static.
And next all is simple - alsa-plugins and mpg123. That's all. Output device is /dev/dsp (it is oss)
Ready to rebuild system. Next that i want:
Recompile base and init for N32;
Compile distcc and if needed gcc and OpenSSH;
Prepare all for launching from usb - initrd issue, network configure, distcc configure;
What need to be compiled? - of course Xfree86-Xgsx.
Will use old video driver in kernel cause i think system forced to use framebuffer video driver.

I want to know some info:
Do N32 system spend more resources than O32?
What about VU and N32?
I can load from partition (sda2/3) on my flash without initrd with the help of kloader, right?
And the main - where i need to switch on the large files support? - in uClibc or only in bash? If in uClibc - please write here a needed option.

[Mega Man]

Do N32 system spend more resources than O32?

n32 could be faster than o32 when FPU is not used.

What about VU and N32?

VU is not ready for use.

I can load from partition (sda2/3) on my flash without initrd with the help of kloader, right?

No, because the kernel detects the flash after trying to mount it. Then it is too late.

And the main - where i need to switch on the large files support? - in uClibc or only in bash? If in uClibc - please write here a needed option.

uClibc: UCLIBC_HAS_LFS=y
The configure script of the bash could have problems detecting it because of cross compiling.

[archicharmer]

uClibc: UCLIBC_HAS_LFS=y
The configure script of the bash could have problems detecting it because of cross compiling.

System recompiled. Even with --enable-largefile, Bash still have SegFault. Init also has SegFault:
INIT PANIC: segmentation violation! sleeping for 30seconds
- after "wake up" - sleep for 30secs again. And again...

However, it is possible to chroot in it.
Mega Man, what you'll say? Should i add smth to compiling? (I used --enable-largefile -fPIC flag everything where it is possible.)
Or do you want to i upload tsystem_loop? - so you can debug bash and init by yourself. If you do want - i need to compile some debug prog, right?..
The taste thing of all of it is i cross-compiled (!) Xfree86-4.3.0 and if you want and can - enter to loop and test it off. On your rest of course)

[Mega Man]

There was one combination where you need to use static libraries or the first executed program will crash, but I thought this was related to ABI n32 and large file support. The last thing what I remember that I fixed in kernel was pread64 and 64 bit offsets loff_t in some n32 syscall. Does the bash also crash when it is linked static? I would prefer a static linked binary for debugging. I want to start it directly from my installed Debian or Fedora.

[archicharmer]

Does the bash also crash when it is linked static? I would prefer a static linked binary for debugging

I didn't try. Means, recompile bash with --disable-shared --enable-static, right? Sysvinit too?
And should i cross-compile gdm additionally? (i too late for answer. Our with you difference in time zones is when it is 6:30 on my clock - on yours it is 3:30. And you goes away)
-------------------------------------------------------------------
Guessing 'yes' for all my questions.

[Mega Man]

It think these parameters would do it. This is also required for sysvinit.
If gdm is not working, you also need it for this, but with each program it will become bigger.

[archicharmer]

There is no --disable-shared --enable-static parameter available for bash configure. Sysvinit has no configure at all.
Sysvinit recompiled with -static flag for gcc. With bash things not same - it cannot be compiled with -static flag - some error of multiple definitions of getenv: in uClibc/libc/stdlib/getenv.c and first define here: bash/lib/sh/getenv.c
Gdb compiled.

tsystem_loop.7z
-------------------------------------------------------------------------

It is interesting:
I compiled file gs-test.o:

#include "gsos.h"

#include <stdio.h>

#include <assert.h>
#define AssertGsosCommandBufferExecuted() assert(ps2count==0)
    // assert command buffer in gsos is flushed

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/ioctl.h>
#include <signal.h>
#include <linux/ps2/dev.h>

static int ps2sprfd;		/* ScratchPad fd */
GSOSbit64 *ps2sprp;		/* ScratchPad */
GSOSbit64 *ps2dbp_spr[2] ;	/* double buffered IMAGE base pointer */
int ps2dbf_spr = 0 ;		/* double IMAGE buffer flag */
int gsos_maximage_size;

int ps2gsfd = -1 ;

int main(void)
{    if (ps2gsfd >= 0)
	return 0;

    /* open driver */
    ps2gsfd = open(PS2_DEV_GS, O_RDWR ) ;
    if( ps2gsfd < 0 ){
	fprintf (stderr,"gsosOpen: can't open driver(" PS2_DEV_GS ")\n" ) ;
        return -1 ;
    }

    /* open ScratchPad driver */
    ps2sprfd = open( PS2_DEV_SPR, O_RDWR ) ;
    if( ps2sprfd < 0 ){
	fprintf (stderr,"gsosOpen: can't open driver(" PS2_DEV_SPR ")\n" ) ;
        return -1 ;
    }

    /* memory allocation for ScratchPad Memory */
    if( ps2sprp == NULL ){
        ps2sprp = (GSOSbit64 *)mmap( NULL, 16384,
            PROT_READ | PROT_WRITE, MAP_SHARED, ps2sprfd, 0 ) ;
        if( ps2sprp == NULL ){
	    fprintf (stderr,"gsosOpen: ScratchPad memory allocation error\n");}
	else{fprintf (stdout,"gsosOpen: ScratchPad ready\n");}
        }
    }

- this is actually a piece of code from gsos.c. This file i placed to XFree86-3.3.6-Xgsx/xc/programs/Xserver/hw/gsx/gsos/ directory, where it able to be compiled.
Executing on O32 uClibc target system with kernel which have edited ps2dev.c (for enable ps2spr and ps2vus) gives StrachPad ready.

Mega Man, if you have some thinks about StrachPad test (i'd'know, maybe read/write/ioctl or else you understand better) - let me know.

[Mega Man]

I think there are still unsupported instructions used. The parameters -mips1,-mips2 and -mips3 must not be used when compiling for r5900, see patch:
SourceForge.net Repository - [kernelloader] Contents of /linux/uclibc/uClibc-0.9.33.2-ps2.patch

You requested the toolchain. The toolchain is still the first in the queue. The scratchpad is the last in the queue.