Even more good news, I just enabled the ps2 frame buffer in the config and it works! I also added an initrd image. The image gets loaded so the kernel doesn't panic anymore. But when it tries to run something off the initrd it fails. I guess the initrd I am using is no good, but other than that everything seems to work fine!

I see my own website is down, so that's why you can't see the image for now. It should be up again soon and then I'll add another image of the ps2 running with its frame buffer.

Because you said framebuffer, I thought you must be using my kernel or at least my framebuffer patch. Judging by the console output, that appears to be the GS console driver. Still I'd imagine mine would work. So that's excellent!

No, I've used the standard 2.4.17-mvl21 for this, since that's what Mega Man used for his loader. I also managed to get a working initrd. It mounts and the kernel runs busybox (with a lot of page fault exceptions however). My list of things now looks like this:

- Test the smaller patches (finally get rid of the huge mvl version)
- Create a simple initrd for as long as there is no hdd driver
- Get irx modules to load using kernelloader (version 0.2 should do this but I somehow can't seem to get it to work)
- Set up communication to the IOP/IRX files (test with something simple like the shutdown button)

Perhaps there is some people over at ps2dev who can help. They seem to know a lot about compilers and stuff. You could also try to finish the 3.2.2 compiler from ps2dev, as stated in the readme:

Quote:

The Playstation 2 Linux kit is NOT supported in this release. There are a
number of issues related to the deployment of this version of GCC in that
environment. This is left as an exercise for the ps2linux folks.

You'll see that I tried for a long time to make 3.2.2 to work if you look back through this thread. But I didn't really know what I was doing back then and I was trying to make it work in 32-bit. I could probably make it work now if I tried but I've had good enough results with 4.2.0 to make me think we should stick with that. Even if I can't make the IOP work using 4.2.0, I can still use 4.2.0 for the EE.

So 4.2.0 can already be used to produce ee ps2dev code and ee ps2linux code?

While trying to use some ps2dev code in linux I found out that I had to change "long" into "long long" to get a 64 bit integer? Would this mean that a ps2dev compiler will never be compatible with a ps2linux compiler?

The assembly code also failed for some instructions, saying that instruction was only supported on mips3 and newer. Looking at the compile parameters I see -mips2.... do you know why this is? It explains the errors but it's clear that the code I get now is not optimized for 5900 at all!

Well I did say it was working earlier but then I hit that problem with madplay. I'll look at that once I'm done with IRX.

You cannot simply build ps2dev stuff to run inside Linux, it was never designed to and it needs a different compiler target. The patchset is the same but you build two different compilers from it, one for mips64r5900el-scei-elf and one for mips64r5900el-scei-linux-uclibc.

Edit: To clarify, apart from the fact that it wouldn't work anyway, the main reason you received those errors is because you were trying to build 64-bit code using a 32-bit compiler on a 32-bit OS. I'm guessing that the 32-bit compiler only targetted MIPS 2 because the instructions added by MIPS 3 are all 64-bit. As I stated previously, I will be working towards running Linux in 64-bit using the N32 ABI. This ABI expects "long" to be 32-bit and so you would need "long long" for a 64-bit integer. The home brew stuff, on the other hand, uses the EABI ABI. This ABI can have either 32-bit or 64-bit "long" but ps2sdk expects 64-bit so I have made the -mlong64 option enabled by default on mips*r5900*-*-elf*.

I tried the framebuffer patch. First it wouldn't compile becouse of some missing ps2 functions. When I looked at the functions it looked as if they didn't do anything with the IOP so I enabled them, and it compiled without a probem. And guess what, it works! Well... at least partially. I've never seen the patch in action so I guess it would look just like the console driver, only stretched... As that's what I'm looking at right now.

There is only one problem, again, the unhandled page request, dammit. I have included another picture of this, looks like something is accessing user space memory?! Could be the frame buffer, could also be the enabled "PS2 integrated device"?

I can't remember what the default framebuffer resolution is but that looks right to me. For it not to look stretched, you'd need to switch to an interlaced mode. I used to use fbset to switch between modes.

I'm trying to remember whether that was an error I encountered in the past. I don't quite recall. I know that disabling the optical drive initialisation seemed to prevent the network adapter from working, strange as that may seem. I also know that using HDLoader prevented Linux from being able to see the hard drive, which is kind of expected. Page fault errors would suggest something memory related though.

The page faults look almost random. Mega Man has the same problem. It is probably coused by some uninitialized hardware. The Sony loader seems to set up things differently. Perhaps it's CPU initialization or some other hardware like the DMA/GIF/GS/IOP? I don't know. For more information you could look at the ps2dev thread:
http://forums.ps2dev.org/viewtopic.php?t=8860