Porting of Linux 2.6 to PS2

@archicharmer: The sysrq key is described in the kernel documentation: SourceForge.net Repository - [kernelloader] Contents of /linux/linux-2.6.35.4-mipsel-ps2/Documentation/sysrq.txt

@oitofelix: You need to debug it with printf in the SBIOS. On default this will be redirected to printk calls in kernel. You should disable all other stuff, to reduce the amount of unrelated prints on the screen; e.g. Don't load other modules and disable all other PS2 drivers including USB. For testing you need only the kernel. You need to add printf to the interrupt function.
You need to enable the printf in fnction _end_request() in http://kernelloader.cvs.sourceforge....18&view=markup

You should also try to load kernelloader directly without much stuff before. Starting uLauchELF can be already too much.

2.6 32bit kernel for ps2 is a great invention, really. And debian 5/6 as it's OS is not bad, it is true. But, as we know, we have a problem with that Xes is loading so long. n32 mips64el fedora as OS not a decision of this problem. If XFree86 from blackrhino will be compiled, it maybe will work not so fast as in blackrhino, maybe slower that framebuffer driver... who knows...

Maybe it is some syscall is responsible for graphic? Blackrhino have own penguin-in-headpiece. And it, not paints, appears at once.

I think, if penguin will paints as appears - it is strike for Xes problem decidion
on the contrary
if we would found an issue for Xes problem - penguin paints as appears.

Graphic isn't a problem, when another PC's OS is "screening" instead PS2.

Mega Man, do you thinking something about it? How it is possible to decide this problem?

Additionally, please, share me or tell me about files which you changed when you was starting fedora on ps2. So, i finally can to test mips64r5900el-toolchain's work! Fedora12 mips64el in loop-file with compiled mips64r5900el-toolchain on board is ready for it's first launching on it's native system!

Quote:

---

Originally Posted by archicharmer

2.6 32bit kernel for ps2 is a great invention, really. And debian 5/6 as it's OS is not bad, it is true. But, as we know, we have a problem with that Xes is loading so long. n32 mips64el fedora as OS not a decision of this problem. If XFree86 from blackrhino will be compiled, it maybe will work not so fast as in blackrhino, maybe slower that framebuffer driver... who knows...

Maybe it is some syscall is responsible for graphic? Blackrhino have own penguin-in-headpiece. And it, not paints, appears at once.

I think, if penguin will paints as appears - it is strike for Xes problem decidion
on the contrary
if we would found an issue for Xes problem - penguin paints as appears.

Graphic isn't a problem, when another PC's OS is "screening" instead PS2.

Mega Man, do you thinking something about it? How it is possible to decide this problem?

---

The slow painting of the penguin is something which is only related to the penguin and not to other graphic. Increasing this speed will not increase the paint speed of anything else.
A driver for Xorg can increase the speed, because the frame buffer is not mapped and this reduces the used memory. Actually painting is not a problem when running X. It paints at a good speed when it gets a chance to paint.
One problem is that some instructions are not supported by the CPU R5900. The missing instructions are emulated by the kernel. For example ll and sc are emulated. I think the old toolchain didn't used sc and ll. New problems occur with n32: 64 bit floating point is emulated. The CPU supports only 32 bit floating point operations. dmult and dmultu are emulated.
The speed can be increased by using the special features of the PS2. For example SMS uses a vector unit for decoding video. Something simliar can be done in Linux.
I told you already that the limited memory is a problem. The speed can be increased by using programs with less memory foot print.
Optimizing X is not planned in the near time. FIrst I want compatibilty and a working system. I think there are more people which can work on optimizing applications and libraries than on the Linux kernel. There is an interesting course about performance engineering MIT OpenCourseWare | Electrical Engineering and Computer Science | 6.172 Performance Engineering of Software Systems, Fall 2010 | Home. Unfortunately the assembler part is x86_64 only, some of the described speed problems are not applicable for R5900. The lecture "Synchronizing without Locks" explains why emulating sc and ll is a bad idea and what the impact is. The first lecture shows that you need to know what to optimize. It makes no sense to optimize unused code.

Quote:

---

Originally Posted by archicharmer

Additionally, please, share me or tell me about files which you changed when you was starting fedora on ps2. So, i finally can to test mips64r5900el-toolchain's work! Fedora12 mips64el in loop-file with compiled mips64r5900el-toolchain on board is ready for it's first launching on it's native system!

---

Basically I told you already what I changed in Fedora 13. I disabled all startup scripts except S*local*. I didn't tried Fedora 12.

Ok, i has loaded fedora12 from qemu to ps2. I did all same,what you, Mega Man: all S*, except S*local*, from strartup from /etc/rc.* has been deleted, Alt+PrntScrn+... is kill for all process. Login as root. No evbug module disturbs. r,e,i,s,b is not the way to shutdown on fedora12

And... mips64r5900el-toolchain isn't working. Same problem - when i want to execute - permission denied. Sudo binary_file - unable to execute: success. Chmod/chown gives no effect.

Then, i has compiled mips64el-toolchain from package-sources from mips64r5900el-toolchain and did a tests with printf-testprogram:
mips64el-unknown-linux-gnu-gcc testprogram.c -o -mabi=n32 testprogramn32.o
mips64el-unknown-linux-gnu-gcc testprogram.c -o -march=r5900 testprogramr5900.o
Both of them are launched and working on qemu-mips64el. I think, printf-testprogram not using something special from r5900 or -march=r5900 has no effect.

However, compiling in N32 ps2linux itself is a dull action. Only printf-testprogram is being compiled for 2 minutes.

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

with -mabi=32 i got error: unable to emulate TI, with -mabi=n32 - no such error. Maybe with -march=r5900 i also will not got this error.
mips64r5900elo32-toolchain can be compiled just with replacing MIPS_ABI_DEFAULT from ABI_N32 to ABI_32 in file gcc/config.gcc for target-in mips64*-*-linux*)
Anyway, libgcc can't be compiled because special r5900 things. I don't know how to explain... But it is possible to compile mips64r5900elo32-toolchain if to adapt these "special things".

So, TI can be emulated in N32 by default?.. mipsEEel-toolchain isn't N32-toolchain. It's O32-toolchain.

Quote:

---

Originally Posted by archicharmer

And... mips64r5900el-toolchain isn't working. Same problem - when i want to execute - permission denied. Sudo binary_file - unable to execute: success. Chmod/chown gives no effect.

---

I don't know what you could have done to get this error. I assume it is not a correct ELF, the ABI is incorrect or any library is missing.

Quote:

---

Originally Posted by archicharmer

However, compiling in N32 ps2linux itself is a dull action. Only printf-testprogram is being compiled for 2 minutes.

---

I assume your are using the slim PSTwo. The internal hard disc would make it usable (particulary it increases swap speed). The compiler included in Fedora 13 works and compiles a "hello world" surprisingly fast compared to Debian 5.0. This still takes several seconds which will be slow for real stuff. The only way to solve the speed problem is distcc which redirects the work to a normal PC. The normal PC needs the cross compiler. This should also work with qemu (instead of PS2).

Quote:

---

Originally Posted by archicharmer

with -mabi=32 i got error: unable to emulate TI, with -mabi=n32 - no such error. Maybe with -march=r5900 i also will not got this error.
mips64r5900elo32-toolchain can be compiled just with replacing MIPS_ABI_DEFAULT from ABI_N32 to ABI_32 in file gcc/config.gcc for target-in mips64*-*-linux*)
Anyway, libgcc can't be compiled because special r5900 things. I don't know how to explain... But it is possible to compile mips64r5900elo32-toolchain if to adapt these "special things".

So, TI can be emulated in N32 by default?.. mipsEEel-toolchain isn't N32-toolchain. It's O32-toolchain.

---

The last version of the Ubuntu toolchain was optmized to much in this way. I tried to disable 64 bit pointers in o64 and I tried to use TI with o32. Both failed. At this time I didn't know about n32 which has both features. I hoped that n32 is able to handle TI, but I haven't tried this yet. TI are the 128 bit registers. The trick is to change as less as possible. While keeping compatibility and stability, you can gain higher speed.
I assume that you try to compile the old libc. This is no good idea. Normally it is always better to use newer libc or a new embedded variant like ulibc or klibc. The library can then be optimized.

Quote:

---

Originally Posted by Mega Man

I don't know what you could have done to get this error

---

Attachment 36419 - try it and you'll see same as me. Maybe YOU can to launch it.
File was created with mips64r5900el-toolchain for target mips64r5900el-unknown-linux-gnu based on glibc-2.12.1, which compile's configure: --prefix... --target=mips64el-unknown-linux-gnu --enable-add-ons --with-headers=$prefix/include(from_kernel-2.6.35.4)

Quote:

---

Originally Posted by Mega Man

I assume that you try to compile the old libc

---

Wrong assume. Yeah, it would be good, but no, i do not do this.
I thought, if o32-toolchain can't handle TI, maybe it possible to handle it not with -mabi=n32, but with -march=r5900 which would give o32. But, -march=r5900 gives n32.

Old glibc is good when one use it, he use this with kernel, which have similar syscall, memcpu - files: memchr.S, memcmp.S, memcpu.S, memmove.S, memset.S, strcat.S, strchr.S, strchrnul.S, strcmp.S, strcpy.S, strlen.S, stncat.S, strncmp.S, strncpy.S --- haves something similar like in scallxx-xx.S. And i sure, if to compare files in mipsEEel-glibc-2.2.2 and files in arch/mips/kernel/scall... from first ps2linux-kernel source - maybe these have something same.
So, just to upgrade them.
----------------------------------------------------
Attachment 36439
- busybox initrd for flesh_fat_partition/ps2linux/ps2linux_loop loading. This file is worth to be nearly initrd_busy_vX.gz at sourceforge. Useful thing.

I'm trying to launch initrd_busy_v9.gz. SharedDocs from PC are mounted, but it now wants to mount /mnt/debian...bin loop-file. I want to rename it to /mnt/ps2linux/ps2linux_loop. And did a try to rebuild busybox. It self can't be compiled:
miscutils/ionice.c: In function 'ioprio_set':
miscutils/ionice.c:23: error: 'SYS_iopio_set' not declared (first use in this function)
same as for iopio_get

Quote:

---

Originally Posted by archicharmer

Attachment 36419 - try it and you'll see same as me.

---

In the file should be a string pointing to the dynamic loader. This is wrong or lost. I can start it in Fedora 13 with the command:
/lib/ld-2.12.so ./testprogram.o
The program ld has a parameter "--dynamic-linker" for setting the correct dynamic linker.

Quote:

---

Originally Posted by archicharmer

I'm trying to launch initrd_busy_v9.gz. SharedDocs from PC are mounted, but it now wants to mount /mnt/debian...bin loop-file. I want to rename it to /mnt/ps2linux/ps2linux_loop. And did a try to rebuild busybox. It self can't be compiled:
miscutils/ionice.c: In function 'ioprio_set':
miscutils/ionice.c:23: error: 'SYS_iopio_set' not declared (first use in this function)
same as for iopio_get

---

Did you changed the source code? It is "SYS_ioprio_set" and not "SYS_iopio_set".

Did you try to execute testprogram.o in fedora13 which run on ps2? In qemu i got "Illegal instruction", and /usr/local/ps3/mipsEEel-linux/lib/libc-2.11.so testprogram.o - "Segmentation fault". If it so, that's great! Then how to execute it without adding "path to system's ld...so"??

Quote:

---

Originally Posted by Mega Man

It is "SYS_ioprio_set" and not "SYS_iopio_set"

---

No, i did not change anything! Yes, it SYS_ioprio_set. I did a "grammatic" error in that post)
Busybox's source was downloaded from SourceForge.net Repository - [kernelloader] Index of /linux/busybox

It printed "Test program" in Fedora 13 and it seemed to terminate normally. You need to fix the --dynamic-linker parameter in the spec files and copy the dynamic linker to the target file system.

I think you need to get a consistent build to create busybox. You need to get everything at SourceForge.net Repository - [kernelloader] Index of /linux and call build-all.sh. I changed the path for some stuff because of n32.

Quote:

---

Originally Posted by Mega Man

It printed "Test program" in Fedora 13

---

Yes, it do. Ask second time: in fedora13 - you run on ps2 or on qemu?

With busybox it seems like i have bad mipsel-linux-gnu toolchain...

In your LiveDVD v3, how fast is loading Xes??? Or it is not a 2.6 liveDVD?) My dream - is LiveDVD without mouse/keyboard control and with dendy and sega emulators