PlayStation 2 - Major progress, help me finish!

[Chewi]

Code: Select all

chewi@schwartz /usr/bin $ ls mipsEE*
mipsEEel-scei-linux-uclibc-addr2line  mipsEEel-scei-linux-uclibc-objcopy
mipsEEel-scei-linux-uclibc-ar         mipsEEel-scei-linux-uclibc-objdump
mipsEEel-scei-linux-uclibc-as         mipsEEel-scei-linux-uclibc-ranlib
mipsEEel-scei-linux-uclibc-c++filt    mipsEEel-scei-linux-uclibc-readelf
mipsEEel-scei-linux-uclibc-cpp        mipsEEel-scei-linux-uclibc-size
mipsEEel-scei-linux-uclibc-gcc        mipsEEel-scei-linux-uclibc-strings
mipsEEel-scei-linux-uclibc-ld         mipsEEel-scei-linux-uclibc-strip
mipsEEel-scei-linux-uclibc-nm

cpp and gcc are binaries. The rest are symlinks to /usr/libexec/gcc/mipsEEel-scei-linux-uclibc. Those symlinks are supposed to be created by binutils-config.

Code: Select all

chewi@schwartz /usr/bin $ binutils-config -l
 [1] i586-pc-linux-gnu-2.17 *

 [2] i686-pc-linux-gnu-2.17 *

 [3] mipsEEel-scei-linux-uclibc-2.14 *

 [4] powerpc-apple-linux-gnu-2.17 *

Typing "binutils-config 3" should create the symlinks in the above case.

[Chewi]

Ah you posted while I was making my post. That looks fine. If "/usr/bin/mipsEEel-scei-linux-uclibc-as -v" actually works and /usr/bin is in your PATH when building the kernel then it should just work... in theory.

[rmh3093]

no they dont work actually, its all screwy, I cant tell if my chroot confused things or if is something else

[Chewi]

I guess it doesn't surprise me much, knowing how awkward gcc 3.0.4 is. What happens when you try to run "/usr/bin/mipsEEel-scei-linux-uclibc-as -v" then?

[rmh3093]

where in the gcc ebuild did you put that econf line?

[Chewi]

It's already there near the top. That's what I'm saying, it should have worked already.

http://gps2.aura-online.co.uk/trac/gent ... 0.4.ebuild

See?

[rmh3093]

well the toolchain works in my chroot environment, must have messed something up trying to make it work outside my chroot

[garlicbread]

Haven't checked this thread in a while been busy with other things

I figured some of this might be useful
when I first looked into this I figured I'd try and seperate out the kernel patches to 2.2.1 to isolate the sony related stuff then look at 2.4 afterwards
to give some clues to 2.6, but this kind of got put on hold once I figured out that the toolchain would need to be done first
2.4 is closer the mark but 2.2 seems to have more drivers supported for the hardware
below is some of the results I've got for seperating out the patches for 2.2.1
the original diff against the vanilla kernel was quite big, I've managed to get the unknowns down under 500K so far
some of this involved sifting through very old web pages for old versions of LVM / UDF

broken out patches dir

10-patch-mips-2.2.1.patch - 1.2Mb
CVS mips from http://www.linux-mips.org/ "Sat Jun 12 18:39:27 1999 UTC"

11-patch-mips-2.2.1.patch - 95K
for some reason some of the version numbers in a lot of the mips files had been changed but the code was the same

20-patch-lvm-2.2.1.patch - 138K
LVM support added at some point

30-patch-udf-2.2.1.patch - 323K
UDF support

40-patch-usb-2.2.1.patch - 2.1Mb
some but not all of the USB stuff that they've added to the kernel

80-patch-ps2-obvious-2.2.1.patch - 844K
individual files that relate only to the PS2

90-patch-ps2-leftovercrap-2.2.1.patch - 464K
left over crap I've yet to sift through some R5900 related stuff (ps2)
also some bits of USB in there as well, plus anything else I've missed

applying the above to the 2.2.1 stock vanilla kernel should give you the same kernal as the stock for the PS2

[Chewi]

Can you tell me what drivers 2.4 is missing because I wasn't aware of any?

[garlicbread]

I'm not really sure to be honest
I know that the 2.4 kernel was designed for a different bit of hardware and not for the Sony PS2 (something to do with a broadband device I think)
so I always figured that it may be missing some PS2 specific stuff (perhaps the drivers for the memory cards for example)
although I could be wrong, I've not looked at the 2.4 kernel enough to say for sure
I was going to try and split out the patches for both and see what the differences were

[Chewi]

It wasn't different hardware at all, I think that's a bit of misinformation that's been passed around. The Broadband Navigator was a piece of software that ran on ordinary PS2s through Linux. It was only released in Japan.

http://en.wikipedia.org/wiki/PlayStatio ... _Navigator

I've used 2.4 a fair bit and I haven't noticed anything missing, certainly not the memory card driver. There was talk of "incompatibilities" but that was only because all the previous software had been build for 2.2. If you build all your own software as I have done, there is no problem.

P.S. whereabouts in the UK are you?

[Kumba]

Nifty, I go off and murder my old PS2 model that can support a hard drive (it refused to play a faulty Xenosaga disc), and buy a slimline, then you guys all go and actually make progress. Pffffttt :P

Some little things I recall from when I last visited PS2 kernel bits:

• The EmotionEngine is a MIPS-III core that supports several MIPS-IV functions (making it a hybrid) as well as adding on 128bit capabilities. Why they chose "R5900" makes no sense, but then again, the entire MIPS naming scheme makes no sense (R6000 was MIPS-II and only found in Cray systems; R4000 and R5000 are MIPS-IV).
• The 2.4 kernel for the BBN software/device was based on 2.4.17, and from what I read about it over at the old PS2 linux site, was that it was somewhat better than the 2.2 kernel on things (video mainly, if memory serves). But it had issues with the networking driver, I think. The other problem was some really nasty security flaws were found in 2.4.18 that existed in all prior versions, making 2.4.17 somewhat unsuitable (in my opinion). My feeble attempts to patch it up to 2.4.19 and greater met with total disaster, though.
• The IOP is an R3000 MIPS-I core, which basically acts as the main CPU when playing PSX games. I doubt this can ever be used for anything other than basic IOP functions. The Vector units, however, might be more useful, as they're clocked at the same speed at the EE, I believe (300MHz). No idea what their underlying architecture is, though. I don't think anyone ever got them to work in PS2Linux. It's a stretch, but I'd wonder if they could somehow be tapped as extra cores or some variant of a hyperthread device of sorts.

[rmh3093]

oh we can take the 2.4 kernel higher than 2.4.19, thats an easy task, I might work on that next if I give up trying to get the ps2fs module to compile in 2.6

[Kumba]

oh we can take the 2.4 kernel higher than 2.4.19, thats an easy task, I might work on that next if I give up trying to get the ps2fs module to compile in 2.6

Probably better to aim for 2.6 actually, more so if you can base the code off of a git checkout of the linux-mips.org tree. If you hang on freenode any, drop into #mipslinux for pointers, as you'll find people from MV and the gcc/binutils side of things that may be able to offer pointers. AFAIC, 2.4 is dead :)

[SpanKY]

oh we can take the 2.4 kernel higher than 2.4.19, thats an easy task, I might work on that next if I give up trying to get the ps2fs module to compile in 2.6

Probably better to aim for 2.6 actually, more so if you can base the code off of a git checkout of the linux-mips.org tree. If you hang on freenode any, drop into #mipslinux for pointers, as you'll find people from MV and the gcc/binutils side of things that may be able to offer pointers. AFAIC, 2.4 is dead

the point is to pull out the ps2 specific code first and then start updating to 2.6 mips git

[rmh3093]

forget about the kernel, we need a GPL bootloader that be started from the mem card

[Chewi]

But it had issues with the networking driver, I think.

I hadn't heard that but I've certainly noticed it. Network performance is really really bad.

[Kumba]

forget about the kernel, we need a GPL bootloader that be started from the mem card

Looked into uboot? I know that's used for a variety of self-booting applications on embedded hardware (which the PS2 partially classifies as due to low memory). Getting around the PS2's protections legally is the more challenging part, though.

[Chewi]

As I said above, an attempt was already made. It was called TGE (The Great Experiment) but it was never finished.

http://gps2.aura-online.co.uk/trac/gent ... Experiment

[rmh3093]

As I said above, an attempt was already made. It was called TGE (The Great Experiment) but it was never finished.

http://gps2.aura-online.co.uk/trac/gent ... Experiment

quoting that project is good for nothing, its like 1% done.... I think you could get more info out of looking at the source source for uLauchELF, as it actually compiles and launches binaries, i just dont how a kernel which is an elf binary is different from the elf binaries that uLauchELF can run

[Chewi]

I don't think normal bootloaders have to do very much but in the case of the PS2, it really isn't that simple. The official bootloader abstracts any communication with the IOP so that Linux never talks to it directly. The IOP is responsible for controlling the DVD drive, memory cards, controllers, and sound processor. It is also responsible for data transfers to and from the network adapter, hard drive, and USB ports. This was done to prevent piracy and to prevent people from gaining too much knowledge about how the PS2 actually works. Removing this abstraction layer would mean that certain parts of the kernel would have to be rewritten. Only some of the most skilled developers over at ps2dev.org would have a clue how to do this which is why I haven't even considered trying.

[rmh3093]

yes, bootloaders are like mini-operating systems, but it seems like to there are many 3rd party apps out there for the ps2 that take advantage of PS2 hardware, the sony bootloader has more functions that we need, we dont need to be able to browse the contents of a disk or mem card, we dont need to be able to install linux from the bootloader, it just needs to copy kernel to the proper stop in memory basically, some init functions from the sony bootloader would probably have to be moved into the kernel, but its doable

[Chewi]

You're welcome to try if you think you can do it.

Progress on the kernel front. I've come up with a 63000 line patch that strips out all the patches rmh3093 mentioned plus a few others. I've successfully compiled and booted it. It's still a little way from being in line with the MIPS kernel but this is a good sign. I was half expecting it to not work because some of the PS2-specific files were making use of the preemption patch but I figured that if 2.2 worked without preemption then 2.4 should be okay. Preemption is a nice thing to have so we can add support for it back in when we reach a kernel that includes it as standard. I presume some of the later 2.4 kernels do.

[Chewi]

I've now got a 1.3MB patch (about 48000 lines) that adds mostly PS2-specific stuff to MIPS 2.4.17. It can't be stripped down much more. The bad news is that it doesn't build but the good news is that it nearly does! If I disable USB (messy, will come back to that) and PS2 APA partitioning support (not that important, could be fixed), it actually gets all the way down to the final step where it links the kernel and then it bombs with a bunch of undefined references, mostly relating to IRQ stuff. This is really a better result than I was expecting so I think this is good news. I'll press on and keep you posted.

[rmh3093]

do you have a copy of that patch i could help clean up compile errors