PlayStation 2 - Major progress, help me finish!

Chewi · Posted: Sat Nov 11, 2006 4:04 pm Post subject:

Yeah! I fixed that problem. int-handler.S wasn't being built with __ASSEMBLY__ defined because the makefile wasn't using the newer standard rules for building .S files. Now to fix the remaining errors.

sh0 · n00b Joined: 04 Nov 2006 Posts: 5 Location: Germany

Wow! Kernel 2.4.33.3 for PS2 sounds great

Have you managed the USB issue ?

Chewi · Posted: Sat Nov 11, 2006 5:52 pm Post subject:

I'm just trying to get 2.4.33.3 working at all first. I'm so close to the end now but who knows if it'll actually run or not. Fingers crossed. I had to sort of blindly remove some FPU-related stuff because it's totally changed and I don't know how to rewrite it. I think it's only needed for R5900-specific core dumps and stacktraces though so hopefully it's not all that important.

Chewi · Posted: Sat Nov 11, 2006 8:47 pm Post subject:

I'm now all the way down to the bottom with just one bitchy undefined reference. C'mooon! :wink:

Chewi · Posted: Sun Nov 12, 2006 1:31 am Post subject:

So I got it to build, modules and all. And did it boot? Well... no.

But it was always gonna be a very remote chance that it was gonna work first time. I've gone back to binutils 2.14 since I know that works. That didn't fix it. I've now disabled just about everything, including the potentially troublesome R5900 Specific Context option. About to give it another go. If that doesn't work, I'll try using the akmem driver, which lets you load one kernel from another. That might allow me to see something.

Chewi · Posted: Mon Nov 13, 2006 2:52 am Post subject:

This is turning out to be pretty damn tricky. I eventually gave up on 2.4.33.3 for the time being. When you're faced with nothing but a blank screen and no viable debugging methods, you have to take a few steps back. I browsed the Linux MIPS GIT archives and found point in time where the cache code was rewritten. It was between 2.4.20 and 2.4.21 - a little earlier than I'd hoped. So I grabbed a copy of 2.4.20 and figured I could quite easily get that to work. It didn't take long to repatch seeing as I'd done half of it already and I'm starting to get the hang of this now. But once again, I was faced with a blank screen.

This was disappointing to say the least. I tried replacing likely problem areas with code from the older kernel but nothing was helping. All I wanted was a kernel where I was would actually be able to see something. At least then I would be able to tell if I was on the right track. I was really clutching at straws by this point so I decided to try something totally ludicrous. I replaced the entire arch/mips folder with the one from 2.4.17 and proceeded to make the necessary adjustments for it to work. I didn't really expect this to work but it was the only thing left I could think of. Despite the odds, I somehow eventually managed to get it to build. I fired it up and...

A result at last! It was only an extremely minimal configuration so I couldn't do anything but at least there was something on the screen! I rebuilt it with a more substantial configuration and tried it again but it kernel panicked just after starting init. That's hardly surprising given the kernel's split personality.

But at least I can now tell whether I'm on the right track or not. I hardly changed anything outside of arch/mips so I will proceed by gradually restoring the 2.4.20 code in that folder.

And yes, you may laugh at me stupid techniques but honestly, can you think of a better way?

Chewi · Posted: Wed Nov 15, 2006 2:31 am Post subject:

I'm down to about 6 files now and I've found the first, and possibly the only, problem file. It's traps.c. There's a lot of differences in that file but I think I can work out exactly where the problem is.

Chewi · Posted: Thu Nov 16, 2006 2:13 am Post subject:

My friends, we have a result!

garlicbread · Apprentice Joined: 06 Mar 2004 Posts: 182

I was about to suggest writing a custom initrd that just ran sshd or a telnet server of some sort to login remotely
first testing with 2.2 then using for the experimental 2.4
that way you only need the network driver working to check what's happening without having to worry about the screen / keyboard / hard disk etc
but it looks as if you've got it mostly working
way to go

Chewi · Posted: Fri Nov 17, 2006 8:14 pm Post subject:

I was getting a blank screen because the kernel wasn't even making it to init, which really limits your options. You need to use something like a serial port to debug at that level but obviously that isn't an option here. I guess I'm okay now though! About to have a stab at this latest problem.

Chewi · Posted: Sat Nov 18, 2006 3:37 am Post subject:

Well I haven't figured out the problem yet. I've tried disabling R5900 Specific Context but that doesn't help. I've tried enabling signal debugging (DEBUG_SIG in signals.c) but that doesn't tell me much. If I try running lsdldoom enough times, it actually does start. I can't play due to the lack of USB but the demos play along just fine. Can anyone tell me exactly what the above output means? I've tried looking on Google but there are too many irrelevant results.

Update: I figured I'd give 2.4.33.3 another go since I managed to figure out what was stopping 2.4.20 from booting. I only tried the bare minimum configuration but I didn't get a blank screen!

I'll see if it can do anymore than that tomorrow. I think I'll need to repatch 2.4.33.3 though because I made a lot improvements when patching 2.4.20 and I've lost track of them all. I'm hoping that 2.4.33.3 might magically fix the problem I've been having with 2.4.20 but I doubt it will.

Pliablemammal · n00b Joined: 02 Oct 2006 Posts: 52 Location: Sacramento

I'd love to help flog it but where the hell can I get a Sony PS2 Linux kit for less than $200? I wanna buy a few PS2's when they come cheap for setiathome! (But again, I still can't get a copy of PS2 Linux anywhere) :-(

[quote="Chewi"]Now before you say I'm flogging a dead horse, hear me out. :wink:

I've made some serious progress! After a lot of blood, sweat and determination, I more or less have Gentoo running on my PlayStation 2. Here's what I have at the base.

Pliablemammal · n00b Joined: 02 Oct 2006 Posts: 52 Location: Sacramento

oh dude also can you tell me if the mips pro compiler can compile for the ps2 mips processor?

Chewi · Posted: Sat Nov 18, 2006 12:03 pm Post subject:

Unless you're loaded, getting the actual kit isn't really an option anymore. In some areas, you can still get the DVD on its own but not in the US. Take a look at my guide. http://gps2.aura-online.co.uk/trac/gentoo-ps2/wiki/WhatDoYouNeed

I've never heard of that compiler but I had a look and I'm quite confident that it will not work at all unless you compile for MIPS I but even then I'm not sure.

garlicbread · Apprentice Joined: 06 Mar 2004 Posts: 182

the R5900 supports all of the MIPS I instructions, I think all of the MIPS III instructions
but I know it definitley doesn't support all of MIPS II (just part of it)
(plus it supports bits of IV and it's own custom instructions, not to mention the VU0 / VU1 co-proccessor stuff)
I've been trying to put a spreadsheet together with a side by side comparison
as there's some pdf's on the official DVD's that give full info on what's available
this means using an unpatched compiler the highest level you can compile at is MIPS I

I think gentoo only supports Mips at level II officially but I could be wrong
one thing I haven't tried yet is re-doing the toolchain using the bootstrap scripts for binutils
if that worked ti get around having to need custom patches for everything, but the system would probably be a bit slow

Chewi · Posted: Sat Nov 18, 2006 4:27 pm Post subject:

I gave 2.4.33.3 a shot with a bigger configuration. My girlfriend was trying to watch TV at the time so I only had a quick look! It kernel panicked for some reason. Not too surprising really. I'll focus on fixing 2.4.20 first.

Chewi · Posted: Sun Nov 19, 2006 5:48 pm Post subject:

Still stumped, I headed over to #mipslinux. They're not overly interested in looking at 2.4, which is understandable. Someone suggested I stick something up on their wiki. Whether I figure this out soon or not, I'll probably do that anyway.

There is some good news though. I gave 2.4.19 a try and that does work fine. That narrows down the number of changes I have to look at. I'm starting to think it's related to the FPU context stuff but I'm not sure yet.

One thing I've also noticed is that the network adapter seems a lot faster in 2.4.20. I still don't think it's full speed but it does seem faster. I'm pretty sure I'm not imagining it.

Chewi · Posted: Tue Nov 21, 2006 1:46 am Post subject:

No luck yet but I still have some ideas. One of them is that I may need to rebuild my system using 2.4.20 kernel headers. It's a long shot but worth a try and it means I get to have a break from this kernel stuff. It's starting to do my head in.

I've created an ebuild for binutils 2.16.1 (which I've committed) as well as ebuilds for ps2-sources 2.4.20 and ps2-headers 2.4.20 (which I haven't committed). I'll then build a new snapshot of uClibc and attempt to build a new system.

Chewi · Posted: Tue Nov 21, 2006 5:38 pm Post subject:

I don't believe this! Those kernel sources have been available for over two years and just NOW, mere weeks after I weeded out the patches by hand, someone manages to get the patches directly from MontaVisa!? *bangs head on wall* Oh well. It was fun, I suppose.

https://playstation2-linux.com/forum/message.php?msg_id=50036

Chewi · Posted: Fri Nov 24, 2006 1:03 pm Post subject:

I've built the entire toolchain including a snapshot of uClibc (complete with PS2-built locale files) and gcc with C++ support but I'm not having much luck building a system with Magic Cross. The new Magic Cross seriously needs the --sysroot option to work. This is present in binutils 2.16.1 but not in gcc 3.0.4. It was only backported as far back as gcc 3.3. I tried backporting it to 3.0.4 myself but I wasn't confident that it was going to work so I tried to make do without it. Now I'm quite sure we need it. Maybe it's time I had another stab at gcc 3.2.2.

It would probably save us a lot of other problems in the long run.

Redhatter · Posted: Sat Nov 25, 2006 4:14 am Post subject:

Chewi · Posted: Sat Nov 25, 2006 4:26 am Post subject:

Redhatter · Posted: Sat Nov 25, 2006 6:20 am Post subject:

Chewi · Posted: Sat Nov 25, 2006 12:06 pm Post subject:

I meant for the PS2 Linux distribution, I know that Linux can do either.

I thought the MIPS CPU itself could be switched to either endian in software because of what I read here though I guess not all MIPS systems will allow you to do that. But then you should never trust what you read on Wikipedia.

Redhatter · Posted: Sat Nov 25, 2006 12:57 pm Post subject:

Some can, the Broadcom SWARM is one that can be switched by flipping a jumper.

My PDA can, but I'd have to rip out all the tracks connecting CPU to memory/IO, and re-wire them in Big-endian configuration. Not something an end user can do.
_________________
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.