PSPLinux project kick-off??

[DairyKing]

I've recompiled the PSPBoot and got Jasonm's PSPLinux running on my phat dsd (www.peidaqi.com). But even after days of effort, I cannot get the toolchain, nor the kernel built. I wonder if there is a group of people interested in this, and we could work together to bring this up. I've gone through Jasonm's code. It seems not hard to understand, but need some serious polish. The PSP itself resembles a very good linux box to me, the powerful dual mips processor, 32MB/64MB ram, memory card access, and wireless. I hope we can have a better working edition, a more formal project site (with svn, or hosted in ps2dev.org), just like ipodlinux (ipodlinux.sf.net), or dslinux (dslinux.org).

The ultimate goal might be:
1. Mouse simulation with analog stick
2. User can choose to use on-screen keyboard or Infrared keyboard (this is more usable)
3. kind of dual core support (if it's possible?)
4. Wireless network (with X support and dillo working maybe?)
5. A more user-friendly build system (like dslinux, simple make menuconfig, not patching by hand)
6. A toolchain/sdk for cross-compiling, or compiling on the go

That's just what I think. Actually, if we can fully utilize the psp hardware power in psplinux, we might be able to bring the homebrew development to a new phase, like psp-linux-homebrew? And with rich libraries provided by linux, we can have much more freedom.

[Pirata Nervo]

this is a very interesting project :D

[hlide]

3. kind of dual core support (if it's possible?)

up to a certain extent. The second processor has no VFPU support. GE VRAM is also unaccessible. In fact, most hardware addresses are probably not usable on the second processor.

So you need to be sure to let the kernel run on the first processor so a user thread in the second processor would run a kernel routine on the first processor. There is also the problem of synchronization of memory since they both have their own caches.

[jean]

kind of dual core support (if it's possible?)

VFPU absence or memory accessibility are not the main problems. These days i'm working on a presentation about shared-memory architectures. PSP is one of them: 2 processors with identical core at least, communicating one to each other trough fast memory. Despite MIPSR4000 (allegrex's base) is multiprocessor-ready, as far as i know there is no cache-coherence mechanism on PSP. This means that each code executing on both processor in some parallel way needs to know about this and wisely use the CACHE instructions. I.e.: dedicated code only, unless you keep track of cache state with some hard-as-hell algorithm in the scheduler.

jean

[hlide]

kind of dual core support (if it's possible?)

Fpu absence is not the main problem.

If you are speaking about standard FPU, the second processor has one.

And yes, Allegrex has no cache-coherence mechanism.

[jean]

ops...i missed a "V"...let me edit my post...

[DairyKing]

Thanks for those explanation. For my understanding, cache coherence problems would occur only when two client processes are sharing data. So it should be possible for letting some certain kernel process to run on one core, without exposing its resources, while all the other tasks are done by the main core?

And anyway it'll be great to have a working linux environment for PSP even if we can have only one core working.

[vijay]

hi DairyKing
i have built the toolchain long back ...... here i shared my complete builtroot image
http://montamer.blogspot.com/2008/07/psp-linux.html
if that might help.
i have faced many problems while building it ... but dont exactly remember how i solved them.
recently im into embedded linux and all that stuff; what exactly is the diff between mmu and non-mmu systems?; and psp has a non-mmu processor right?

[jean]

MIPSR4000 has a full Memory Management Unit and Translation Lookaside Buffer. This means that memory addresses (and addresses of memory mapped hardware) are lying in non-contiguous pages to access wich you must use a translation mechanism for indirect addressing. Sony removed this mechanism from PSP's Allegrex because with plain 32bit direct addresses you can address up to 2Gb of RAM/memory mapped hardware, and PSP has only 64 Mb ATM. BUT this screws up a large part of kernels just because of the non-standard mechanism (nothing impossible, you just would have to rewrite a lot of stuff). AFAIK McLinux uses direct addressing and hence can be adapted on PSP.

[DairyKing]

MMU is key to virtual addressing, which is implemented in nearly all the modern mainstream OSes.

In virtual addressing, each process will 'think' that they own a continous 4GB memory (32bit systems) - well in fact only 2GB/3GB available for them to play with coz the OS will take 2GB/1GB.

But most of the time the physical memory is much less, say 512MB. The OS kernel will divide the 4GB virtual address into 4KB ~ 64KB frames, use a certain algorithm to maintain a table of those virtual address frames, and only those need to be accessed will be in the physical memory.

MMU is used to assist this. Or this process will be very, very slow.


PS: Jean, you were trying to say ucLinux? I've never heard of mcLinux...
Actually it's not a very painful process, ucLinux has been implemented in many systems already, and proved to be robust.

[jean]

ucLinux as you said...that "u" stands for "mu", a greek letter for micro, because at the end we are both speaking of "Micro Controller Linux" said for extent.

But most of the time the physical memory is much less, say 512MB.
...
MMU is used to assist this.

If i'm not wrong here you're misunderstanding TLB with virtual memory and paging...That is _NOT_. MMU is for doing exactly viceversa: see a big whole universe of addresses (memory itself, aliases, memory mapped devices, ecc...) small piece by small piece to use smaller addresses. PSP does not need this because it has a silly amount of memory compared to desktop (even if they are many for an handheld), and a single 32 bit address is enough for
* cached memory
* uncached memory alias
* memory mapped hardware
in all of the three user/kernel/supervisor modes. Absence of MMU/TLB in hardwares that need it would make it impossible to work, not simply slow.

PS: i basically said "if you haven't a kernel supporting direct addressing you would have to rewrite lots of stuff, but you have one: ucLinux does the trick but seems too basic to me"

PPS: there is another 10000000 post long topic on linux,ucLinux and PSP somewhere here in ps2dev forums.

[hlide]

ucLinux?

µcLinux to be precise.

[DairyKing]

Well, we are both talking about the same idea. What I want to point out is just TLB is the buffer and MMU is the unit.

PSP doesn't need multi-processing and I think that's why Sony didn't put in a MMU. Some 32MB systems do have MMUs, like PDAs with PXA270.


It's good that we discussed about the hardware implementation but in fact I'm just hoping to get some people interested in PSPLinux and start work on it, not really some tech jargons.

[hlide]

It's good that we discussed about the hardware implementation but in fact I'm just hoping to get some people interested in PSPLinux and start work on it, not really some tech jargons.

well, at least two persons already tried to make a psplinux, but curiously we don't hear about them now (or at least here). The major issue is about hardware. Those both psp linuxes are very restrictive and not very attractive in my opinion because of the hardware issue.

[jean]

PSP doesn't need multi-processing and I think that's why Sony didn't put in a MMU.

sorry, i don't want to be pedant, but i really don't catch it. What does "PSP doesn't need multi-processing " mean?? If we have a second CPU, let's use it in a way or another...we just cannot see it as a multi core (and hence we are forced to a delegation-of-service mechanism) because setups are different for 1st and 2nd processor. But this has nothing to do with TLB. PDAs can have MMU for various reasons:
1) producer don't plan to sell so many units to justify repackage of a CPU ready-to-mout (sony revisited R4000 because she wanted to introduce new features, too)
2) PDA is upgradable, so you cannot hard wire addresses

As a second note, please notice that on PSP there is no cache-coherence mechanism THAT WE KNOW OF. Original MIPS R4000 is multiprocessor-ready, indeed.
Finally, let me repeat what someone else said: what advantages could a linux porting take to us? you'll never be able to execute a program not specifically intended for PSP on it just because it runs something called linux...

[DairyKing]

Sorry if I didn't state myself clear enough. I should have said 'Multi-Tasking' rather than 'Multi-Processing'. Yes, PSP does have multi-threading, but as it doesn't need to have more than one process running at the same time, it doesn't really need MMU. WinCE PDAs need MMU because WinCE is a multi-tasking OS - though most of the time WinCE devices are built to run in 'full kernel mode', in which one process could have direct access to another, due to performance. It is said WinCE 6 has eliminated this, but I'm not sure as no CE6 PDAs have been produced yet.

As for myself, porting linux, being able to have some programs running on PSP is kind of interesting. If I want a box for some serious task, I'd rather go for a laptop, or eeePC. (size-wise) And I think that's the whole purpose of homebrew - for fun. ~_~

[jean]

I should have said 'Multi-Tasking' rather than 'Multi-Processing'.

aaahhhhhh...ok, now i understand.

as it doesn't need to have more than one process running at the same time, it doesn't really need MMU

again, maybe i'm missing something crucial but i think this is clearly wrong (again i think you're confusing with protected memory). MultiProcess environment could be implemented flawlessly on this hardware; it's sony's choice not to do so (remember that PSP's main purpose are GAMES) as well as it's sony's choice to implement non preemptive multithreading (there's no hardware motivation for it AFAIK). MMU absence is due to 32/64 shitty Mb of RAM. period.
As for linux-porting motivation, you're right...fun is enough! (but if we get serious for a moment, you see is big pain for quite no gain)

[DairyKing]

Well.... just think about PDAs like those Windows Mobile devices, you'll find 32MB has no problem for multi-tasking and MMU. Though here, multi-tasking has a different definition, I suggest you to look at some of the WinCE developers' blogs. There're some articles on it.

If you'd still like to have a further discussion with me, you can send me e-mail to me(this sentence acts as the 'at' symbol to prevent spamming)peidaqi.com. So we are not going too far and actually flooding this forum. :)

[shadash]

"well, at least two persons already tried to make a psplinux, but curiously we don't hear about them now (or at least here). The major issue is about hardware. Those both psp linuxes are very restrictive and not very attractive in my opinion because of the hardware issue."

The only thing missing from the current psplinux implementation is networking. Once that is working everything else (X, or whatever) will fall into place. It's just a pain to have to manually transport files between to devices.

PsP development will go crazy once all the opensource apps are able to run on it.

[hlide]

The only thing missing from the current psplinux implementation is networking. Once that is working everything else (X, or whatever) will fall into place. It's just a pain to have to manually transport files between to devices.

PsP development will go crazy once all the opensource apps are able to run on it.

and DMA controllers (for audio, lcd, ms, etc.) ? I mean EFFICIENT implementation of PSP hardware in Linux, not a simple polling serial or ms device.

[shadash]

"and DMA controllers (for audio, lcd, ms, etc.) ? I mean EFFICIENT implementation of PSP hardware in Linux, not a simple polling serial or ms device."

A lot of this stuff is probably already handled by the Linux kernel.

I'm telling you manually "sneaker neting" files from one device to another sucks. Once you can ssh into a psp running Linux development will take off. It's just easier to prod and poke hardware when all you have to do is try different code.

Oh, and btw there is a wifi driver that appears like it might work for the psp. Unfortunately it hasn't been integrated into the linux kernel yet.

http://lists.infradead.org/pipermail/li ... 01459.html

It appears that marvel developers and the linux kernel libertas-dev developers think the driver should be created 2 different ways. Most likely the libertas-dev linux kernel driver authors are creating it correctly while the marvell developers have created the driver that "just works". Hopefully both camps will be able to come together so we can get a working driver in the main Linux kernel.

[hlide]

A lot of this stuff is probably already handled by the Linux kernel.

For the first implementation, surely not. I haven't a look on the second implementation but I'm quite doubtful it has the right implementation for psp specific interrupts and dma handling on psp-linux. If it were the case, I would expect an instructive doc to tell us in details how to implement them. Ok, I should really check the last psp-linux to see how they are far.

I'm telling you manually "sneaker neting" files from one device to another sucks. Once you can ssh into a psp running Linux development will take off. It's just easier to prod and poke hardware when all you have to do is try different code.

In this regard, you'd better try to see how psplink does (as it is basically like remote shell through USB). Why Wifi, USB is not enough to avoid "sneaker netting" ?

Anyway, I would rather think psp-linux development would be marginal as long as PSP is not a open hardware.

[shadash]

"Why Wifi, USB is not enough to avoid "sneaker netting" ?"

Yea usb would solve the problem as well. It's just that wifi is more ideal.

This would be sweet if usb worked. :-(

http://thoralt.ehecht.com/projects/SIO2USB/SIO2USB.html

[hlide]

I had a look on psplinux patch and as I feared, there is no interrupt or dma implementation for PSP hardware, so any hardware accesses are through poll method, which is not efficient for multi-tasking.