First up, please excuse the long-ish post, but im unsure how to word this exactly, so please bear with me...
SO.
Basicially, I'm wondering what the pre-existing kernel does and what it doesn't. I assume it does its stuff by catching the software interrupt instruction and going from there.
More importantly, even though its there in ROM, is it possible to bypass it or replace functionality by overwriting the exception vector(s) and doing everything manually?
I ask because i'm nearing the end of a Comp Eng degree and it becoming time to choose an undergrad thesis. I've just finished a course on Advance Operating Systems: implement a simple OS on top of the L4 micro-kernel (http://l4ka.org) on a 100 MHz MIPS R4700 processor - "to our knowledge the world's fastest kernel for that architecture".
I was speaking to a couple of guys today on where to take it and they said its(undergrad thesis) just a big-ass project to do. So i suggested something like porting L4 to the ps2 and they said "exactly".
As a bonus, if this works, there is a Linux server available of L4 (currently up to 2.6.9) that is binary compatible with linux-mips apps... no more need for a propritary RTE... with the help of some drivers courtesy of the good people here at ps2dev.org =)
I just want to put some feelers out to see what people's reactions are, if you reckon its feasible (and worthwile) etc. And any other thoughts.
What would people think of a fully-open source (initially bsd license) on the ps2, supporting all the standard OS stuff like paging, swapping, multii address space (current research at uni is on a single address space OS, but i dunno about that just yet..) etc...
This is kinda exciting for me, and if i can pull it off, it'd be pretty sweet...
thanks
- cheriff
PS keep in mind that other people have ported L4 to arm, x86, IA32, IA64, ppc, alpha and AMD, so if its anything, its portable... ta again!!
what does and doesn't the ps2 kernel do?
what does and doesn't the ps2 kernel do?
Damn, I need a decent signature!
-
Guest
Yes, you can do it. Its something I have been wanting to do for the longest time, install my own embedded OS (well not one I made myself) on the PS2, just haven:t made the time for it.
You have full access to the CPU and memory. You know where the exception vectors are. You can replace anything in memory with your own. There is no reason why you can:t put your own operating system in memory.
So go for it! The CPU, memory, hardware devices, they are all yourse for the taking. Nothing holds you to what software pre-exists in ROM, once there is an opening for you to inject your own code anywhere.
You have full access to the CPU and memory. You know where the exception vectors are. You can replace anything in memory with your own. There is no reason why you can:t put your own operating system in memory.
So go for it! The CPU, memory, hardware devices, they are all yourse for the taking. Nothing holds you to what software pre-exists in ROM, once there is an opening for you to inject your own code anywhere.
good to hear...
I was just really wondering if there were any fundamental road blocks that would get in my way, if i got started... apparantly not (and not from what i've read as well....)
only thing i did find is that
but there has to be a way arond that, right? i mean the linux kit and so forth have to have some way of dealing with this... should that cause any headaches??
I was just really wondering if there were any fundamental road blocks that would get in my way, if i got started... apparantly not (and not from what i've read as well....)
only thing i did find is that
in oopo.net's ee-syscalls.txtthe r5900 MIPS variant
within the EE doesn't support normal software
interrupts
but there has to be a way arond that, right? i mean the linux kit and so forth have to have some way of dealing with this... should that cause any headaches??
Damn, I need a decent signature!
-
Guest
There is absolutely NO roadblock.
Dunno what is meant by not supporting normal software interrupts. Probably means that interrupts are only done by hardware. Thats no big deal.
There are tons of interrupts, and many interrupt/exception vectors. To take over the system completely with your own code, you only need to do this:
1. Load your code somewhere in memory.
2. Disable interrupts.
3. Install your own interrupt handlers at the appropriate vectors.
4. Move your code to its final location, if necessary.
5. Re-enable interrupts.
Voila, you are in full control with your own operating system.
There is nothing to stop you but your own knowledge of the EE
and the IOP.
This is a good time to acquite the linux kit, second hand if necessary,
if you have not yet done so. The supplied PDF documents on programming
the internals of the EE are invaluable. There ARE resources for much of
the information if you can:t get a linux kit, but the linux kit is the best of
all.
Good luck!
Dunno what is meant by not supporting normal software interrupts. Probably means that interrupts are only done by hardware. Thats no big deal.
There are tons of interrupts, and many interrupt/exception vectors. To take over the system completely with your own code, you only need to do this:
1. Load your code somewhere in memory.
2. Disable interrupts.
3. Install your own interrupt handlers at the appropriate vectors.
4. Move your code to its final location, if necessary.
5. Re-enable interrupts.
Voila, you are in full control with your own operating system.
There is nothing to stop you but your own knowledge of the EE
and the IOP.
This is a good time to acquite the linux kit, second hand if necessary,
if you have not yet done so. The supplied PDF documents on programming
the internals of the EE are invaluable. There ARE resources for much of
the information if you can:t get a linux kit, but the linux kit is the best of
all.
Good luck!
dual CPU
But wouldn't the fact, that the PS2 has 2 separate (and different) CPUs mean, that you would have to run 2 separate kernels, one for each CPU?
I've been working with the OSE kernel (real time bla-bla) for some time and found the multi CPU capabilities of this kernel quite nice... It's a message passing based kernel, and it takes care of transfering messages among different CPUs automatically... this would be needed for the PS2 also, if I understand things correctly...
I myself would be interested in a similar project (have thought about it, but it's a bit too much for me at this time), and is one of the "issues" I came across...
Adding: Having said that... How's the porting going? :)
I've been working with the OSE kernel (real time bla-bla) for some time and found the multi CPU capabilities of this kernel quite nice... It's a message passing based kernel, and it takes care of transfering messages among different CPUs automatically... this would be needed for the PS2 also, if I understand things correctly...
I myself would be interested in a similar project (have thought about it, but it's a bit too much for me at this time), and is one of the "issues" I came across...
Adding: Having said that... How's the porting going? :)
-
Guest
Yes and no.
Considering that the EE and IOP run essentially the same kernel, you would only need, in theory, one "port" of your OS, and then run the kernel image on each CPU. Naturally, one could design the kernel so that it had slightly different behaviors/characteristics depending on which cpu it executed. But yes you would still be otherwise running two kernels.
The other path is the one chosen by the PS2Linux kerrnel, which was developed to be compatible with communicating with the native IOP kernel (communications slightly modified via the RTE code that sat between the EE linux kernel and the IOP native kernel).
I have been wanting to port an embedded OS to the PS2 for years, but time is always hard to come by. I hope Cheriff has gotten further than I have. :)
Considering that the EE and IOP run essentially the same kernel, you would only need, in theory, one "port" of your OS, and then run the kernel image on each CPU. Naturally, one could design the kernel so that it had slightly different behaviors/characteristics depending on which cpu it executed. But yes you would still be otherwise running two kernels.
The other path is the one chosen by the PS2Linux kerrnel, which was developed to be compatible with communicating with the native IOP kernel (communications slightly modified via the RTE code that sat between the EE linux kernel and the IOP native kernel).
I have been wanting to port an embedded OS to the PS2 for years, but time is always hard to come by. I hope Cheriff has gotten further than I have. :)
Umm, yeah, sure... I've gotten "real far"... =)
Seriously though, I figured I really should get some practice with something a little more simple first. So i've been playing around with other stuff, trying to work up the courage to jump into this project.
One of these days I'l have to bite the bullet and actually get started =)
Seriously though, I figured I really should get some practice with something a little more simple first. So i've been playing around with other stuff, trying to work up the courage to jump into this project.
One of these days I'l have to bite the bullet and actually get started =)
So sorry to disappoint, but thanks for a much needed kickstart in the pants!! ;)I hope Cheriff has gotten further than I have. :)
Damn, I need a decent signature!
Ok, so I guess I misunderstood the fact, that the EE and the IOP had different CPU core's? That's the main reason I thought that you would need two separate kernels (as in built for different CPUs)gorim wrote:Naturally, one could design the kernel so that it had slightly different behaviors/characteristics depending on which cpu it executed
I was lying in bed last night and trying to fall asleep when I realised that this was also an option, yes... Running your own kernel on the EE, and treating the IOP as a "simple" I/O gateway (as designed, I guess)... In this case you could leave it alone...gorim wrote:The other path is the one chosen by the PS2Linux kerrnel, which was developed to be compatible with communicating with the native IOP kernel
I think I have to get my hands on the Linux kit after all... Is there a way to build the Linux kernel for running on the PS2 without the kit?
yeah, tell me about it... :Dgorim wrote:I have been wanting to port an embedded OS to the PS2 for years, but time is always hard to come by
-
Guest
They are separate chips, each with a MIPS core, connected by a bus. The IOP is MIPS R3000A (no fpu) and the EE is a MIPS R5900 ("almost" MIPS IV). Therefore, it is possible to make one kernel that will run on both, so long as it can work within the 2MB footprint of the IOP. Or better, the EE kernel can be a superset of the IOP kernel.goranb wrote:Ok, so I guess I misunderstood the fact, that the EE and the IOP had different CPU core's? That's the main reason I thought that you would need two separate kernels (as in built for different CPUs)
Not yet. However, if you are truly interested in this level of dev work, you will *want* the linux kit anyhow. The PDF hardware docs on the EE and GS are invaluable, although you can find almost similar information elsewhere. Its just better to have the official Sony docs. (no, there are no docs on the IOP, but there is enough information out there now that it shouldn't be a barrier to getting started).goranb wrote:I think I have to get my hands on the Linux kit after all... Is there a way to build the Linux kernel for running on the PS2 without the kit?
Ok, I see... So the CPUs aren't all that different...
I think The vmips Project might come in handy for porting purposes, as it's a MIPS 3000 emulator...
I think The vmips Project might come in handy for porting purposes, as it's a MIPS 3000 emulator...
-
Guest
Just checked the link, looks like it could indeed be useful.goranb wrote:Ok, I see... So the CPUs aren't all that different...
I think The vmips Project might come in handy for porting purposes, as it's a MIPS 3000 emulator...
You might also consider the "pcsx2" emulator, which is specifically intended to emulate the PS2 hardware. Its not a complete emu (although there are many people working hard on that part) but it is getting close enough to be able to execute some commercial PS2 games. For OS porting purposes, it probably is more than plenty to "bootstrap" an initial OS port.
Once you get far enough into the port, you can just use the tools from this site (cross compiler toolchains and loaders) to build and execute stuff directly on the PS2.
-
fulasypescados
- Posts: 6
- Joined: Sat Dec 25, 2004 4:54 am
I don't know if this help but take a look at the old linux for playstation (RUNIX) that runs in native mode in the old PSX and PS1.
Here is a link for download the kernel for psxlinux .
http://www.toojays.net/~toojays/misc/?C=M%3BO=A
I hope to be helpfull.
Thank you for your work :)
Here is a link for download the kernel for psxlinux .
http://www.toojays.net/~toojays/misc/?C=M%3BO=A
I hope to be helpfull.
Thank you for your work :)
Well, I've downloaded some stuff and played around a bit and here's where i'm at.
(Apologies to those on #ps2dev today, i'm not too great at makefile / gcc flag hacking, thanks for your help, esp Drakonite..._)
Anyways, http://www.cse.unsw.edu.au/~dmir396/pis ... s2.tar.bz2 (1.9meg) is it so far.
after you untar it
and you end up with mips64-kernel, targeted for An R4700 CPU, running at 100Mhz, so should be close to ps2.
Following the instructions on http://www.cse.unsw.edu.au/~cs9242/04/project/m0.shtml I'm down to the bit where it says
At the moment I'm not sure about the appropriateness of this for ps2link uploading, or if I need a special build of ps2link to that it is out of the way of all this.
I guess I (someone?) need to sit down and figure out a memory map to work this out.
Just sharing FYI, since link scripts and cryptic makefiles might be a little beyond me (any help??)
Once the micro-kernel is up and running, the possibilities open right up.. L4Linux, i can port a GS driver (gsLib) to it, pre-empting multi-tasking... would be a great environment to dev in... (well for me, anyway!!) =)
(Apologies to those on #ps2dev today, i'm not too great at makefile / gcc flag hacking, thanks for your help, esp Drakonite..._)
Anyways, http://www.cse.unsw.edu.au/~dmir396/pis ... s2.tar.bz2 (1.9meg) is it so far.
after you untar it
Code: Select all
cd pistachio-0.4/build/u4600-kernel/
makeFollowing the instructions on http://www.cse.unsw.edu.au/~cs9242/04/project/m0.shtml I'm down to the bit where it says
Im not sure where to go from here, since the linker script seems specific to the boxen we were working on at uni. And the final archive is aimed at PMON network boot environement.Building the L4 User Code (libl4, sigma0)
At the moment I'm not sure about the appropriateness of this for ps2link uploading, or if I need a special build of ps2link to that it is out of the way of all this.
I guess I (someone?) need to sit down and figure out a memory map to work this out.
Just sharing FYI, since link scripts and cryptic makefiles might be a little beyond me (any help??)
Once the micro-kernel is up and running, the possibilities open right up.. L4Linux, i can port a GS driver (gsLib) to it, pre-empting multi-tasking... would be a great environment to dev in... (well for me, anyway!!) =)
Damn, I need a decent signature!
I had a "quick" look at the stuff yesterday evening (I think I'll be single soon) and got the impression it would be best to add a platform to the MIPS64 CPU definition. This shouldn't be too hard to do and it would allow one to add (or copy/modify) PS2 specific code separate from the rest of the kernel...cheriff wrote:I guess I (someone?) need to sit down and figure out a memory map to work this out
The "magic" is hidden in the makeconf.* files, I think you will figure it out, it's not that hard...
Also, take a look at kickstart (IIRC it's called kickstart), that's the bootstrap code for Pistachio... I tried modifying it a bit, but for a PowerPC based platform (an emulator I have working)... The code is pretty straightforward and gives a lot of info on how the kernel expects to be booted...
It would be usefull to know what the kernel expects to have platformwise (like hardware interrupts and stuff) and how to redirect those to it (this would probably be done in kickstart, steps like: load kernel to memory, disable all interrupts, adjust all interrupt vectors to appropriate places in the kernel, jump to kernel, kernel enables interrupts)...