PlayStation 2 - Major progress, help me finish!

roarinelk · Guru Joined: 04 Mar 2004 Posts: 520

Did you find out what causes epatch to fail? I run into the exact
same problem on SH-4 arch. epatch fails although the log says the patch
was applied.

Chewi · Posted: Thu Jul 27, 2006 9:29 am Post subject:

I didn't figure it out and it's one of the most annoying problems so if you do figure it out, please let me know! Unfortunately epatch is a mess of pipes and redirects so it's hard to see what's really going on.

lannocc · n00b Joined: 01 Dec 2004 Posts: 14 Location: Billings, MT

Just hopping aboard this discussion... very fascinating! I have the PS2 linux kit and played around with it a couple years ago until the hard drive died. Now that I've been using Gentoo for the last two years I'm ready to dust off my ps2 again and see what she can do with Gentoo! Ultimately I'd like to see how far I can get turning my ps2 into a mythtv front-end on gentoo. Thanks for all the hard work, keep it up!

Redhatter · Posted: Thu Aug 10, 2006 1:30 pm Post subject:

lannocc · n00b Joined: 01 Dec 2004 Posts: 14 Location: Billings, MT

Redhatter · Posted: Fri Aug 11, 2006 5:56 am Post subject:

Well... it all depends on the format of the videos.

It's worth noting that on the MIPS architecture, there's no CPU acceleration for any of the decoders, and no video acceleration for the framebuffer in general.

XINE, for instance, has great difficulty running on MIPS. Even something as strong as an Octane, chokes.

A PS2, with its whacky non-conformant CPU, 32MB RAM, and an ancient kernel, would have no chance.
_________________
Stuart Longland (a.k.a Redhatter, VK4MSL)
I haven't lost my mind - it's backed up on a tape somewhere...

Gentoo/MIPS Cobalt developer, Mozilla herd member.

SpanKY

garlicbread · Apprentice Joined: 06 Mar 2004 Posts: 182

I remember trying gentoo before on the PS2 with a much older stage 1 / snapshot that someone had put together and posted around here (The thing was that old that mips support wasn't even supported in the ebuilds and it didn't work too well)

I've taken a new interest in this recently from what's been posted here
(also just because I want something to stick on my web page

)
I've recently tried to seperate out just the patches that Sony had applied to the 2.2 kernel to see what they had added
I've found that they started off with an odd CVS release of the kernel from the linux mips website
then added LVM support, followed by UDF support and USB support
then finally the Sony related stuff that talks to the IOP
I'll try to do the same with the 2.4 kernel mentioned when I've got the time, to figure out just the Sony related stuff for the R5900 (I'm aware that it works but the 2.4 kernel doesn't have all the drivers that were in the original 2.2 patch)
but it's a good starting point
If I can get a toolchain that's up to date I might start off with 2.6 to try and add in the code for the R5900 and just the network driver in combination with an initird so I can openssh into it to see if it works

I realised that for a 2.6 kernel at the very least I'm going to need a much more up to date toolchain
so I've started looking at this so that I can try and create a seed stage for catalyst to then use to create a stage 1

I've recently patched binutils up to 2.15 and I'm in the middle of patching it for 2.16.1 using the original patch from the ps2dev site for 2.14, I hope to get these posted on the web soon
(working your way up though the versions makes it easier when your not aware of the full details)

garlicbread · Apprentice Joined: 06 Mar 2004 Posts: 182

I've just uploaded some patches
url for binutils patches for 2.15 and 2.16.1
http://homepage.ntlworld.com/garlicbread/Projects/PS2Linux/patches/binutils/

it's possible to also apply the gentoo patches as well to 2.16.1
although the ps2 patch has to be applied before the gentoo ones for a clean patch with no failures
not much testing done other than seeing if it compiles and running make check
I don't seem to be getting any more warnings than 2.14 so it should be okay

I'll have a look at gcc next to see what's possible

SpanKY · Posted: Thu Sep 14, 2006 12:44 am Post subject:

garlicbread · Apprentice Joined: 06 Mar 2004 Posts: 182

I'm not sure but looking at how they work I have a feeling that they may interfere with the normal mips operation
as some of the opcodes are just replaced with others instead of there being conditional statements to choose one or the other (in other words having these patches applied while using a different mips setup may break stuff)
I used 2.16.1 since that seems to be the current stable version at the moment
for 2.17 it should just be a case of trying it to see if the patch works then going through any rejection files to manually add anything in

I'll have a look at going from gcc-3.0.4 to 3.1 next to see if that works, I've found it's best to move up a version at a time to not get overwhelmed with the number of differences that need to be looked at
glibc is going to be the nightmare one, (is it possible to build the 2.6 kernel with uclibc?)

SpanKY · Posted: Thu Sep 14, 2006 3:23 pm Post subject:

garlicbread · Apprentice Joined: 06 Mar 2004 Posts: 182

I've just had a look at binutils-2.17
looking at include/opcode/mips.h and gas/config/tc-mips.c
some of the symbols for the opcodes that used to be used for the PS2 are now used for other purposes within mips
so there's some amount of overlap with this version
it should be possible to re-jig it if I can figure it out, perhaps using a different extension for the PS2 related stuff but this in turn will probably affect the patch for gcc as to which op-codes to use
so for now I'll just stick with 2.16.1

SpanKY · Posted: Thu Sep 14, 2006 8:24 pm Post subject:

garlicbread · Apprentice Joined: 06 Mar 2004 Posts: 182

well I've just had a look at gcc
binutils was extremley easy to patch by comparison
I had a look at the 3.0.4 patchset and it looks as if there are a load of duplicated defines within gcc/config/mips/linux.h
it looks as if a lot of the defines that used to be in there in earlier versions were moved into other headers (like gcc/config/linux.h
which is the reason you get lots of warnings about redefines when compiling 3.0.4
I tried to patch 3.1 based on this and cleanup linux.h but it was no good (ended up with a load of blarb about syntax errors from a file that was autogenerated by some other file)

tried to work my way up from 2.95.2, got as far as 2.95.3
but the differences between 2.95.3 and 3.0 were too great

If we ever hope to get this up to GCC-4.0 level I think it'll have to be re-done from scratch with some understanding how the internals of gcc / binutils work with the mips architecture (instead of just blindly patching stuff based on really old stale patches)

I've not given up on this though
the PDF's on the Linux PS2 DVD describe the EE processor pretty well
this is an old PDF about porting other devices into gcc which might be of some use ftp://ftp.axis.se/pub/users/hp/pgccfd/
I'm going to try and start by mapping out the differences first between the EE Processor and other mips processors
from what I understand it has all of MIPS1 some (but not all) of MIPS2 / MIPS3 / MIPS4 / plus some other assembler instructions

sonyman · n00b Joined: 30 Nov 2005 Posts: 31

Any updates? I'm anxiously awaiting a functional port.

rmh3093 · Posted: Tue Oct 24, 2006 4:28 pm Post subject:

Chewi · Posted: Tue Oct 24, 2006 7:00 pm Post subject:

Shit guys, I'm so sorry, for some reason I didn't any receive recent e-mail notifications until that last post. Don't know what the hell happened there.

First of all, garlicbread, that is awesome.

I'd appreciate it if you could IM when you can.

Thanks for the tip, SpanKY. I think I did try building patch natively but I'm not sure if I ever tried bash.

rmh3093, thanks for the offer but I've since realised that's not so important after all. You can use any partition format you like as long as your PS2 kernel can read it. The format you use is only important if you want to share the drive with HDLoader or HDAdvance. Still, it could be useful.

Okay, update time. I gave the whole thing a rest for a while but started getting back into it a few weeks ago. After receiving my own brand new copy of the Linux DVD (yay), I set up Trac on my web server and started fleshing out the wiki. You may be glad to hear that I'm a developer who's not afraid of writing a bit of documentation.

I want to flesh it out a bit more before letting you all loose on it because otherwise we'll all start going in different directions. I was half-way through writing about what a pain in the arse cross compiling is when I suddenly had an amazing idea...

Magic Cross was working in a really horrible, hacky, unreliable way, using regular expressions to prepend $ROOT to gcc's arguments and such like. Ugh. My new idea was much better - I would run gcc processes inside a chroot of $ROOT. I would need to mount --bind enough stuff in order for gcc to work while not mounting over the all-important /lib and /usr/lib folders. I wasn't sure if it would work but I gave it a shot. After a while, it did look as though this would be a viable solution! I sharpened it up by rewriting the Bash/Ruby scripts in C (man, my C was rusty) and successfully managed to build gcc.

gcc is smart enough to not need Magic Cross normally but if you enable Fortran support (was testing this for the Mac, not sure if we have Fortran on the PS2), it needs to link against mpfr, something it would usually stumble on. I need to test it some more but it's looking very promising.

Another interesting Magic Cross development is how it now handles binaries that need to be run at build time. You used to have to pass in a list of the problematic binaries using the MX_BUILDBINS variable beforehand. Hardly ideal. It now uses the binfmt_misc kernel feature to run a wrapper script every time the system attemps to run a non-native binary. Instead of simply trying to run the binary and dying, it moves it, compiles a native version, moves that, restores the non-native version and runs the native version. The native version is kept in place in case the system tries to run the non-native version again. It sounds long-winded but it really works, at least for simple cases so far. If the binary needs to be linked against other object files then things get a bit more tricky but I'll try to make it as intelligent as I can.

Finally, I added a line to crossdev to allow the PS2 Linux toolchain to be built easily. crossdev already supported the PS2 but not for Linux. Despite gcc 3.0.4 being ancient, it seems to work. I haven't built uclibc with it yet because I'm going to start using a recent SVN checkout instead of 0.9.27. Apparently 0.9.29 isn't too far around the corner so we might as well start aiming for that.

Oh yeah, two more things, XDirectFB has been updated for xorg 7.0 so I'm definitely going to try that and GTKDFB seems to be alive and kicking. I thought it was dead. Running the GIMP without X is just too tempting.

I might have to do a few tricks to tie it in nicely with Portage though.

Chewi · Posted: Tue Oct 24, 2006 11:47 pm Post subject:

garlicbread, you mentioned separating out the kernel patches. This is something I had already considered but hadn't got around to yet. The thing about the 2.4 kernel is that it's based on MontaVista's Hard Hat kernel, which is a quite a strange animal. I tried diffing it against the vanilla Linux and Linux/MIPS kernels of the same version. The resulting patch was about the same size for each - 3.8MB bzip2 compressed in the case of vanilla!! That's a pretty hefty patch but very little of that is PS2-specific. This might lead to you to consider taking the patches from 2.2 instead but when working on the framebuffer driver, I found that a lot of the PS2 stuff was reorganised between 2.2 and 2.4. I'm wondering if it's worth contacting MontaVista to see if they can provide us with the sources for a more generic version of their kernel. It's all GPL so they shouldn't have anything to hide. Otherwise we'll have to separate them out by hand, which might not be all that hard really.

rmh3093 · Posted: Wed Oct 25, 2006 12:26 pm Post subject:

rmh3093 · Posted: Wed Oct 25, 2006 12:28 pm Post subject:

rmh3093 · Posted: Thu Oct 26, 2006 3:02 am Post subject:

I was thinking, with the memory card exploit not being illegal, it cant be that hard to modify one of the elf launchers to load a linux kernel
_________________
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.

SpanKY · Posted: Thu Oct 26, 2006 3:10 am Post subject:

it's already been done i thought ... the problem still though is how to do you get the exploit onto the memory card in the first place ? you still need a modded playstation or someone with one

rmh3093 · Posted: Thu Oct 26, 2006 5:55 am Post subject:

SpanKY · Posted: Thu Oct 26, 2006 6:10 am Post subject:

those cheaper still, but i'd like to get as close to $0 and no work for end users as possible

i'm not worried about myself (mod+hdloader+original linux kit == access to everything), but about how to do actual releases