Porting of Linux 2.6 to PS2

Quote:

---

Originally Posted by archicharmer

Many lines scrolling up from my view. Last lines:
Starting
Running simple prog
test2
My PID is 1

---

This means that it is fully working. You can't get more with the test files.

Quote:

---

Originally Posted by archicharmer

About new kloader2.4 - i see the flashing lines on my mediaplayer (i use it instead of TV)

---

I don't know what you mean. Is there an error? Do you use component cable or composite cable?

Quote:

---

Originally Posted by archicharmer

Changing initrd to another...
initrd.usb2.smb.gz or initrd.usb2.install.gz

interesting line:
mount: fs type ps2mcfs not supported by kernel

There is no way yet to load for test any Linux destribution by any knowing ways because all initrds copy some files to mc0

---

I didn't tested the old initrds. I didn't expected that any message is printed because of incompatibilty between Linux 2.4 and 2.6, but there is more working.
Yes, there is no hardware device supported, but maybe it is easier to get mc0 working than USB.
You need to setup your own initrd with the tests you want. I don't have more at the moment.

Quote:

---

Originally Posted by archicharmer

About new kloader2.4...

---

Quote:

---

Originally Posted by Mega Man

Is there an error?

---

No, it just differ from kloader2.3 and below. And i have no any RGB cables. All normal.

About initrds: i think there is no reason to differ they between if they for kernel 2.4 or redone for 2.6. Only kernel modules for launch will in another directory

Quote:

---

Originally Posted by Mega Man

You need to setup your own initrd with the tests you want

---

And this thing i can not do. I not found any instructions on Russian for creation initrd.
I only know that there is 2 types of initrd: ext2 loop and ASCII cpio archive

Here it's working as expected (SCPH-77004)
Please continue your nice work, (Mega)Man!

@Mega Man:
I see that a few days ago you enabled the ethernet port for the slim ps2 in the kernel config.
Is this supposed to work already?

Yes, ping was working. On fat PS2 I tested a little bit more.
The user space applications sometimes encounter random errors (like segmentation faults, illegal instructions and unresolved symbols). On retry everything works. This is very complicated to debug. I need an error which could be easily reproduced to be able to fix it.
The time is not accurate enough. A simple sleep fails at an assertion.
The kernel itself never crashed.

Great to hear!
You boldly go where no man has gone before :-)

You can see the current state here:

[ame=http://www.youtube.com/watch?v=MF-miJJjg9w]YouTube - Linux 2.6 on Playstation 2[/ame]

The Playstation 2 was configured to 1080i, so you will need to configure youtube to 1080p to be able to read the text.

Very cool. Is the segfault limited to the first run only or is it intermittent? Wouldn't you want to remove the apt cache between failed attempts to give a better chance of success "rm -rf /var/cache/apt/*.bin"? Was apt compiled with your 2.6 compiler/toolchain? Can some mipsel binaries run on the PS2 that were compiled for Debian mipsel (other similar platform) already?

The video line display problem is gone and network seems to be working. Great progress!

I agree, this is really amazing!
Do you have any clue what causes this error?

The segfaults seems to be fully random. It is not limited to the first run. I didn't compiled any user space stuff. The programs and library are unchanged from the debian mipsel distribution. I already uploaded it to sourceforge some time ago. Some programs from debian are working. For example the editor vim seems to work.
I thought that the errors are caused by the missing support for the 128 bit registers. The current exception handlers of Linux 2.6 only save 32 bit of the 128 bit registers. The timer interrupt stops user space programs every 10 ms. The actual instruction which gets interrupted is somehow random. This could lead to random behaviour if there is an error in the exception handler. So I tested if saving only 32 bit would cause errors, but I couldn't find any scenario where it will cause an error which was compiled for 32 bit only (like debian).
It is not easy to debug because of the random behaviour.
The sleep bug should be easier to debug, but I didn't tried it yet (a simple "sleep 1" in the bash fails always with an error).