Am I mad? - linux on PSP...

white rabbit · Post by **white rabbit** » Thu Apr 06, 2006 7:10 pm

Quick bit of background:
I spend about 4.5 hours a day commutting to work, 3+ hours of which is on a train. To take the tedium away I tried to make myself a laptop style micro-PC with a mini-ATX motherboard and some other gubbings last year. The main point of it was to run linux and allow me to code for the PSP on the train.
Needless to say I didn't do all that well, and now have a lot of respect for the guys and girls that make laptops properly. (though the battery on mine powered the PC running full tilt for 16 hours!)

Yesterday my mate showed me his new PalmOne, for which he has a little fold away keyboard that uses the IR port on the Palm.

This got me thinking that I could use one to communicate with the PSP. With a port of vi and/or emacs, possibly even the pspsdk to compile stuff too? I was looking at using a USB keyboard, but this thing was small and could be easily modified to cradle the PSP instead of a Palm.

How mad is that?
Does anybody think it's feasible to run a tiny linux kernel on the PSP?

That way I would effectivly have a 2GB root drive in about 20MB of RAM... Going back to when linux was born I was running a PC with a massive 16MB RAM and 1GB HDD, so I'm hoping you will say it's possible to squeeze it in, but may take some work to get it running on the PSP. I'm happy to put my game dev on the back burner for now to get it sorted as I'm not working to any deadlines.

Flame away!

Edit - just seen in the HW forum that the PalmOne wireless keyboard (the one I mention above) has some work going on for it, so that's that bit sorted! Yeay!

__count · Post by **__count** » Thu Apr 06, 2006 9:21 pm

The low amount of memory is going to be the main problem, especially if you're planning on running gcc.

It would be an interesting project though. I say go for it and obtain the respect of neckbearded linux fans worldwide! ;)

groepaz · Post by **groepaz** » Thu Apr 06, 2006 9:35 pm

na, low memory will be no prob IF you use a swap device (memstick for example). the main problem is that the allegrex cpu doesnt have a mmu, so you'd be stuck with uclinux - for which no mmu-less port exists (except for a very old one based on the 2.2 kernel)

white rabbit · Post by **white rabbit** » Thu Apr 06, 2006 9:46 pm

What kernel is used for the PS2 dev kit? - I assume that the PS2 CPU is pretty similar to the PSPs?

junkmonkey · Post by **junkmonkey** » Thu Apr 06, 2006 10:41 pm

uClinux is specifically designed to run on processors without MMUs.
I don't know how up to date the MIPS version is though. I know of at least one person who claims to have the kernel loading on the PSP.

http://rapidshare.de/files/16915465/psplinux.tgz.html

Not that I'm recommending trying it mind.

hubevolution · Post by **hubevolution** » Thu Apr 06, 2006 10:41 pm

PSP has a custom version of R4000 series MIPS called Allegrex.

white rabbit · Post by **white rabbit** » Fri Apr 07, 2006 12:07 am

Google has a page cached from a php board on http://www.amazingspringthing.com/pspforums/ but it appears to be offline at the moment as only the cached pages work. Or maybe they gave up?

Anyways it seems that there are a few people out there trying the same thing, and coming up against various problems - like weather or not to unload the PSP kernel (!)

There's also the MIPS support for the standard linux kernel with its own site, but whilst it mentions the PSP, there's no direct mention of the allegrex derivertive.

The uCLinux has no mention of MIPS, but I haven't dug all that deep into that yet.

Looking less promising all the time, but I'll have a proper dig around tonight and over the weekend.

groepaz · Post by **groepaz** » Fri Apr 07, 2006 12:23 am

There's also the MIPS support for the standard linux kernel with its own site, but whilst it mentions the PSP, there's no direct mention of the allegrex derivertive.

The uCLinux has no mention of MIPS, but I haven't dug all that deep into that yet.

like i said, porting the standard kernel is a no-go, since the psp has no mmu. and as you found out (and said before :=P) uclinux doesnt currently have a mips port, so to port this someone would have to create this first. a lot of effort and time (and knowledge) needed here - and thats without even thinking of the problems that will occur when trying to run it on an actual psp :)

white rabbit · Post by **white rabbit** » Fri Apr 07, 2006 12:33 am

Hmmm.
There's the link above that I've downloaded and will look at tonight, but I'm not holding my breath.
There's also the x86 emulator that can run win95 and linux (so they say) which I'll look into. I guess it'd be really slow, but I only need the console shell.

Just a code editor will do for now, the grander dream of compiler and shell may have to wait for a while ;-)

Looks like it was a mad idea then!

Djakku · Post by **Djakku** » Fri Apr 07, 2006 1:11 am

http://www.psphacks.net/content/view/763/2/
(you probably already know that...)
It seem that PSP on linux is possible, a french guy made a port of Uclinux but you can't do much with it and if you wonder the name of the emu which load win95/linux,the name's Boch i think...
(... and probably know that too)
and theoricly, if linux run fine on PSP, what can be done?

white rabbit · Post by **white rabbit** » Fri Apr 07, 2006 2:02 am

That PSP Hacks page looks good, but seems there's some way to go before it will work - if it can't mount the root device there's some problems (looks like the SCSI driver for a USB mass storage isn't right to me, or hasn't been initialised right).

If you can run linux on the PSP then you effectively have a know OS that you can work in. Ok the tools will need to be recompiled, etc, but that's ok.

My only real aim for this is to be able to use my PSP as a code editor and compiler on the train.
The next step would be to load the executables - like TyRiNaD's PSPLink, but from within the PSP itself. That's not too hard - just make a simple module loader.

So a full linux install isn't needed, but I'm sure if it was available, people would do some cool things with it.

Edit - D'oh! Just realised that's the same one as I've already downloaded. Oh well, there may be some slight differences.

white rabbit · Post by **white rabbit** » Fri Apr 07, 2006 5:20 am

Well, the uCLinux port does boot, and does pretty much exactly as it says on psphacks.

The real problem is that no source code has been released, so no chance I can check out my theory about the root device.

Though it has prompted me to get hold of the uCLinux source to have a go myself.

Still winning the eBay bid for the keyboard too, so fingers crossed it will be an A-team moment: "I love it when a plan comes together"
;-)

danzel · Post by **danzel** » Fri Apr 07, 2006 8:58 am

That uCLinux 'supposed' port was released on april 1st.
Perhaps someone could take a look over it with a decompiler.

chrismulhearn · Post by **chrismulhearn** » Sat Apr 08, 2006 10:44 am

Groepaz- How do you intend to swap, with no MMU? ;)

In order for swapping to work, you need to be able to generate a "page fault" exception when someone tries to access a virtual memory region that is no longer mapped to ram (swapped out), in order to swap it back in.

No page faults on that baby.

groepaz · Post by **groepaz** » Sat Apr 08, 2006 6:47 pm

Groepaz- How do you intend to swap, with no MMU? ;)

In order for swapping to work, you need to be able to generate a "page fault" exception when someone tries to access a virtual memory region that is no longer mapped to ram (swapped out), in order to swap it back in.

on MMUless targets this is usually done by using "handles" instead of "pointers". Too much of a topic to be explained here, google is your friend :=P

No page faults on that baby.

thats what i'm saying - and thats why you need ucLinux and can not use regular linux.

chrismulhearn · Post by **chrismulhearn** » Sun Apr 09, 2006 3:41 am

Groepaz-

We aren't talking about some high level behavior that has been abstracted with function calls or class methods. We are talking about the simple act of dereferencing a pointer (Or any of the zillions of other things you do that cause memory to be accessed). When a program wants to read from memory, it _reads from memory_. It doesnt "Do the read from memory method that I can implement any way I want to".

Therefore, without hardware on your CPU that can virtualize that operation for you, there is no way for a program, running on a target with no mmu, to make use of virtual memory addresses.

Short of rewriting the entire program to abstract /every single memory reference/, that is. Seems pretty daunting...

Another interesting approach might be to locate a program at an invalid memory region, so that _every_ memory access causes a bus error or somethin', where you could come up w/ a fancy handler to virtualize all program memory io. Programs read from memory a lot though. :)

groepaz · Post by **groepaz** » Sun Apr 09, 2006 11:05 pm

you dont have much of an idea what the difference between linux and uclinux is do you? ofcourse for real virtual memory using direct pointer references you need hardware (mmu) support. that however doesnt mean you cant implement swapping using handles - it only means that your whole virtual memory stuff will be more limited (for example there is no mmap in uclinux)

chrismulhearn · Post by **chrismulhearn** » Mon Apr 10, 2006 1:43 pm

Groepaz- I must be missing something here, so if you could fill in whatever I dont understand here, I'd appreciate it! What you are describing has nothing to do with uClinux, as far as I can tell. Its just a method you have of accessing a nonstandard storage mechanism. OK. Thats not memory. I can't write a program like

int x;
int * y;

main() {
y = &x;
*y++;
*y--;
*yWhateverIWannaDotoY;..............
}

And have Y magically appear in swap space for me, if that process gets halted or whatever, without an MMU. Only with an mmu will the data be able to be shuffled somewhere else ___without the program knowing____.

And that IS the magic of "swapping".

But yes, you are right, if I wanted to rewrite every single program that exists on my distribution in order to make use of this proprietary "handle" mechanism, it would certainly work.

uClinux kernels just don't get page faults. You relocate all your programs so that they can live in their little memory space that they are placed in, and you can allocate more space to them throughout the physical memory map, and if they access a region they werent supposed to, uh oh, you'll never know (until something crashes) and thats it! Its a Linux kernel. And it just doesnt recieve page faults. And its memory allocator is different. But you are still just a program dereferencing pointers. No "handles" or anything magic like that.

Am I missing something?

groepaz · Post by **groepaz** » Mon Apr 10, 2006 10:49 pm

And have Y magically appear in swap space for me, if that process gets halted or whatever, without an MMU. Only with an mmu will the data be able to be shuffled somewhere else ___without the program knowing____.

And that IS the magic of "swapping".

thats just one way to implement swapping/virtual memory. ofcourse its the most common and most useful one, doesnt mean you couldnt do it somehow else though.

But yes, you are right, if I wanted to rewrite every single program that exists on my distribution in order to make use of this proprietary "handle" mechanism, it would certainly work.

uClinux kernels just don't get page faults. You relocate all your programs so that they can live in their little memory space that they are placed in, and you can allocate more space to them throughout the physical memory map, and if they access a region they werent supposed to, uh oh, you'll never know (until something crashes) and thats it! Its a Linux kernel. And it just doesnt recieve page faults. And its memory allocator is different. But you are still just a program dereferencing pointers. No "handles" or anything magic like that.

yes and yes. and programs that want or need more memory than physical ram _are_ commonly rewritten to use "handles" (which is just a table of pointers to pointers anyway) on platforms without a mmu.

white rabbit · Post by **white rabbit** » Tue Apr 11, 2006 1:54 am

Could you re-write the malloc functions to point to swap memory directly?

All seems quite hard really. I was just going to hope it would squeeze into the 20-odd Megs and cross my fingers, or wiat for the kernel to panic...

chrismulhearn · Post by **chrismulhearn** » Tue Apr 11, 2006 3:10 am

No! See entire discussion leading up to this.

malloc() gives you a pointer.

A POINTER, the *simplest* abstraction in programming, represents a memory location that is accessable on the system bus.

Reading and writing a pointer requires no effort on the CPU's part, aside from executing a LOAD or STORE instruction.

There is no way to have a LOAD or STORE instruction, which takes a pointer as an argument (and remember what a pointer is! Its just a MEMORY LOCATION) to somehow magically do all the work that is necessary in order to read and write to the Memory Stick, which is a complex storage device with a filesystem layered on top of it.

Therefore, you would have to implement what Groepaz is talking about, which
A. Is nonstandard, and requires a hefty rewrite of your entire code base, and really fundamentally alters the way you write your code.
B. Has *nothing* to do with uClinux
C. Still offers NO PROTECTION, because my program could choose to just not hop through the "handle" level of indirection, and just start dumping wherever it wanted to throughout the memory.

chrismulhearn · Post by **chrismulhearn** » Tue Apr 11, 2006 4:02 am

p.s. white rabbit, do you have any pictures of your homemade ATX laptop? Sounds interesting. My first computer was a 286 motherboard in a wooden box.

white rabbit · Post by **white rabbit** » Tue Apr 11, 2006 5:40 pm

chrismulhearn wrote:p.s. white rabbit, do you have any pictures of your homemade ATX laptop? Sounds interesting. My first computer was a 286 motherboard in a wooden box.

Sounds good! Did it run hot?

I'll fish them out for you, I'm sure I still have a load of version 1 and 2 on my home PC. Not sure if I have any pics of version 3 or 4 (v1 & 2 = cardboard, 3 = metal mesh case, 4 = using a Motorola V3 Raza shipping case (worked best)). I was making a diary of it to post on mini-atx.com but as it never really worked I never sent it them.

white rabbit · Post by **white rabbit** » Tue Apr 11, 2006 5:54 pm

Does uCLinux with no-mmu have any idea what a swap device looks like then? I can see that the swap fs code could be made for the uC kernel, but it would seem churlish to include something like that when it can't work.

As I said, it seems much harder than I had thought.

How about just trying to get a minimal kernel to boot onto the PSP for now though? Cross fingers and hope it fits?

If we try to get hold of memory we can't, what would happen? What would happen if we had an mmu and a full (or even no) swap on normal linux, or uC?
What happens when you try to de-ref a pointer that goes well beyond the memory? I haven't tried any of these things - they just haven't occured to me till now.

My experience of linux has always been on x86 architecture, and whilst I've made kernel modules and hacked around (hack being a very good word here) with the kernel code, I've never really had to worry about RAM as the size of the kernel has always been pretty small in comparision. As time's gone on and it's swelled up, the RAM and storeage has increased in size quicker, so no problems have occured.

This is the first time I've looked at using an esoteric piece of hardware with what effectivly needs to be an ebedded size OS.

white rabbit · Post by **white rabbit** » Mon Apr 17, 2006 2:08 am

Lost the eBay keyboard, but found it was a blessing, as another company makes the same sort of thing (with the same protocol) but has a more flexible craddle for the PSP to sit in.

Now have a working text editor, and it's not very good, but at least I can now type on the train - once I'm back to work anyway.

uCLinux looks much harder than I had expected, especially as I just wanted to stick it on and hope for the best. Anybody else having any luck?

Jim · Post by **Jim** » Mon Apr 17, 2006 3:21 pm

With no MMU, there's no swap file. With uClinux when physical RAM runs out malloc/kalloc returns NULL and it's all over.

Jim

white rabbit · Post by **white rabbit** » Tue Apr 18, 2006 8:51 pm

Jim wrote:With no MMU, there's no swap file. With uClinux when physical RAM runs out malloc/kalloc returns NULL and it's all over.

Jim

That's pretty much what I was thinking would happen. but a tiny kernel and shell with vi should easily run in 20meg. Granted the compiler may cause some issues, but I'd have hoped it could sit inside the limit for most files...? I've never profiled it to know how much RAM it needs.

Jim · Post by **Jim** » Tue Apr 18, 2006 11:13 pm

You'd hope so.

Jim

white rabbit · Post by **white rabbit** » Wed Apr 19, 2006 6:07 pm

chrismulhearn wrote:p.s. white rabbit, do you have any pictures of your homemade ATX laptop? Sounds interesting. My first computer was a 286 motherboard in a wooden box.

Hmmm, I can't find them at home, but I'll carry on looking in all the random places I keep stuff.
I want to warn you though - it's a real mess, and bears no resemblance to a laptop - I now realise that actually laptops are cheap for what you get and are made by clever people!

white rabbit · Post by **white rabbit** » Fri Apr 28, 2006 7:26 pm

Can't find the pics anywhere :( I guess I lost them when my desktop was rebuilt last year. I'm a bit miffed about that. I only threw out my design book a couple of weeks ago too, otherwise I could have scanned some of that in - I had a great design for the screen to spin out.

Not got anywhere with uCLinux but my house move is dragging out and taking up pretty much all my free time right now. Pretty convinced the release in early April wasn't genuine and was just a splash screen type thing.

I do have a basic text editor and a little folding keyboard for the train though. Just need to make it into more of and IDE with multiple files, c-tags and colour-coded text.