linux-mips
[Top] [All Lists]

Re: Porting To New System

To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Porting To New System
From: Stanislaw Skowronek <sskowron@ET.PUT.Poznan.PL>
Date: Sat, 28 May 2005 09:30:21 +0200 (MET DST)
Cc: linux-mips@linux-mips.org
In-reply-to: <1117235565.5730.255.camel@localhost.localdomain>
Original-recipient: rfc822;linux-mips@linux-mips.org
Sender: linux-mips-bounce@linux-mips.org
> > Rest assured, there will be no MMU interface. 
> You seem remarkably confident for someone who has never taken one apart.

Hi.

Sorry if you felt it was overconfident. However I can't think of a really
good reason to give developers a MMU interface, and if I was a Sony
designer I would not do anything that might endanger the "trusted system"
position - so the KISS principle would be my guiding light.

Xen-style MMU access is not KISS at all. This is why I think that there
would be no such thing. The DMA is handled by kernel, so no need for
user-level physical memory access. I would assume that the VRAM is
probably constantly mapped in userspace or something like that - in a
gaming system it would be only natural. And so on. Especially, they are
not interested at all in emulators/virtual machines. Communicating with 3D
engine is done by sceGe* functions that take display lists, so you don't
even have to send them by hand. In the leaked parts of SDK there are few
candidates for functions that might influence the MMU (granted, one is
enough).

I would really like to do the h/w hack. It seems that it will be doable
(although not really easy). And having real-time access to external SDRAM
of the PSP might solve most of our problems. There is exactly one trouble:
time (I have the required hardware, and I can do a FPGA design that would
mirror PSP's SDRAM in external memory, and I can find somebody to do the
tricky BGA soldering). But I don't have the time.

The h/w hack would work unless the PSP is capable of decoding code on it's
way from SDRAM to cache (which would be very wasteful, but if they are
really paranoid, quite justified). However, on published block-diagrams,
the crypto hardware is on a DMA bus, and quite far from the DDR SDRAM in
question. Other dire possibility would be of the kernel never being placed
in external memory (always in internal eDRAM). I don't know how to counter
that.

I think the ucLinux way is the best thing to do right now. It will be
quite impressive. Pity 1.5 won't take it :/

Cheers,

Stanislaw

PS. Besides, does taking one apart actually impart any knowledge? I looked
at the photos, if that helps ;)



<Prev in Thread] Current Thread [Next in Thread>