Subject: Re: Porting To New System

From: "Cameron Cooper" <[email-masked]>
Date: Fri, 27 May 2005 16:59:49 +0000

>  > So even if this is a bad way of doing it, is it even possable?
>  
>  It's certainly a good way to get started. Several ports began by using
>  boot firmware drivers and then eventually replaced them.
>  
>  Does the firmware give you the ability to control MMU mappings ?

At this time only a few firmware functions are known. Well, to be more exact, only a few are usable. While we know many of the functions provided by the firmware, we do not know many of thier arguments. At this time we know how to maniuplate the frame buffer, read button presses, read/write to the memory stick, and play back audio, but we do not have a way to control MMU mappings. We have only had the ability to write/execute code on the PSP for a month. Discoveries are being made all the time, so we will certainly know more about the firmware in the coming weeks.

---

From: Stanislaw Skowronek <[email-masked]>
Date: Fri, 27 May 2005 19:30:12 +0200 (MET DST)

>  Does the firmware give you the ability to control MMU mappings ?

I think we won't - this would be a serious security bug.

Stanislaw

---

From: Alan Cox <[email-masked]>
Date: Fri, 27 May 2005 19:13:07 +0100

> I think we won't - this would be a serious security bug.

That depends who the device is defending against and how. MMU control
cuts both ways in game consoles (if present) - it makes it harder to
defend the console from a hostile writer, but it also makes it easier
for the game authors to debug and to trap/recover from errors when the
game is deployed.

For ucLinux you essentially need a console, an input device (keyboard
etc), a storage device, the ability to allocate memory and a timer
interrupt/callback. Absolutely everything else is optional. So you can
probably run ucLinux as a 'game' which allocates lots of memory,
requests a timer callback and drives the entire world through the
firmware. Whether you can do non-ucLinux depends on MMU access and
control. If you've got some kind of MMU interface then you've probably
got sufficient to do a full Linux but ucLinux would still be a natural
stepping stone in exploration.

Alan

---

From: Cameron Cooper <[email-masked]>
Date: Fri, 27 May 2005 14:21:15 -0400

> stepping stone in exploration.

Thank you, that is a very useful bit of information. I will start with
ucLinux. Once (if?) a MMU interface is discovered then I will do a full
Linux kernel.

Cameron

---

From: Stanislaw Skowronek <[email-masked]>
Date: Fri, 27 May 2005 21:43:32 +0200 (MET DST)

Rest assured, there will be no MMU interface. The machine is so incredibly
well-locked-down, especially the newer versions, that they must have done
that for a purpose (probably to stop pirated/cracked games from running).

All software that is going to run on the PSP is cryptographically signed
(probably also encrypted). The kernel is signed and encrypted, too. There
were some loopholes in 1.0 but nobody found any in 1.5 or later.

I'd suggest attacking the hardware to see what goes on in SDRAM. This is
going to be (relatively) expensive and (very) complex, and the result is
not guaranteed as there is some embedded DRAM inside the processors
(scary). However, if any kernel code is ever placed in external SDRAM, it
would be pretty doable to subvert it (would require stopping the CPU
accesses to the SDRAM, which we can probably do, more or less - for
instance running in a tight loop will probably place everything, including
parts of the timer IRQ, in cache, so no external accesses will be
happening). We can perform some writes to SDRAM then. I see a problem with
this method that it requires overpowering some signals on the bus.
Alternatively, we might want to multiplex those signals although it's not
gonna be easy with DDR at 100-200 MHz (probably - the routing on PCB looks
vaguely high-speedey and there is a nice differential clock pair, so DDR
is likely, and the memory chip itself is rated 6 ns, so DDR333).

Mucking with DDR is a hell of a job, even if you have really good hardware
at your disposal. I wonder how much would it be possible to slow it down
by changing the clock oscillator (probably less than 2x, unfortunately).
Monitoring DDR333 is doable but it is not easy.

That said, I'm seriously thinking about getting myself a PSP. I've already
got some serious digital hardware...

Hmmm.

Stanislaw

---

From: Cameron Cooper <[email-masked]>
Date: Fri, 27 May 2005 15:52:19 -0400

> stepping stone in exploration.

I've looked into using uClinux, and although it appears as though it
does support MIPS, it is very hard to find any information on it. Do you
have any information regarding using uClinux with MIPS?

Thanks,
Cameron Cooper

---

From: Alan Cox <[email-masked]>
Date: Sat, 28 May 2005 00:12:47 +0100

On Gwe, 2005-05-27 at 20:43, Stanislaw Skowronek wrote:
> Rest assured, there will be no MMU interface. 

You seem remarkably confident for someone who has never taken one apart.
There are numerous ways to present an MMU interface without allowing
arbitary system access providing you do it via the core OS rather than
via the hardware. This is how Xen handles x86 and the same can be done
by other systems.

---

From: Alan Cox <[email-masked]>
Date: Sat, 28 May 2005 00:40:46 +0100

> have any information regarding using uClinux with MIPS?

The 2.6 kernel has uclinux merged but that doesn't include MMUless
support at the moment. The 2.4 uclinux tree is seperate and Xiptech
released a set of patches for 2.4.19 for the mmuless mips and for the
ucLibc if the cpu lacks mipsII and FPU instructions.

---

From: Stanislaw Skowronek <[email-masked]>
Date: Sat, 28 May 2005 07:07:57 +0200 (MET DST)

> You seem remarkably confident for someone who has never taken one apart.

Unless it would be very heavily restricted (rather a mmap-style thing than
a real, direct MMU interface) it would be a serious security breach.

OTOH if the assumption is that PSP is always running trusted code, it is
possible that the game can influence the MMU and there are no security
checks at all. I forgot that the whole ability of running untrusted code
on 1.0 was a bug, and not something planned, so interfaces would not need
be so tight.

By the way, all PSPs you can buy now, except early Japanese version, are
1.5 or higher so the whole point of having a MMU interface is moot
because, as of now, you can't run anything on it at all. Not even a hello
world.

Anyway, I'm going to take one apart :)

Stanislaw

---

From: Stanislaw Skowronek <[email-masked]>
Date: Sat, 28 May 2005 09:30:21 +0200 (MET DST)

> 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 ;)

---

From: Cameron Cooper <[email-masked]>
Date: Sat, 28 May 2005 11:43:03 -0400

> ucLibc if the cpu lacks mipsII and FPU instructions.

It looks like Xiptech only did a port for R3K, which is no good for me.
The issue that I'm running into right now is in
arch/mipsnommu/mm/c-r4k.c

I guess the problem is that it is trying to use things which belong to
the MM code, which are not included from mm.h becuase NO_MM is set.
c-r3k.c was rewritten for NO_MM, but not c-r4k.c. I looked into
rewriting c-r4k.c by taking ideas from c-r3k.c but unfortunatly they are
not similar enough, and I'm afraid I'm not even sure what this file
does. Can you help me understand what this file does, and what I might
do to rewrite it for NO_MM?

Below I've included my compile errors.

Thanks,
Cameron

mipsel-uclibc-gcc -D__KERNEL__
-I/home/cameron/kernel/linux-2.4.19/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer
-DNO_MM -I /home/cameron/kernel/linux-2.4.19/include/asm/gcc -G 0
-mno-abicalls -fno-pic -pipe -mcpu=r4300 -mips2 -Wa,--trap   -nostdinc
-I /opt/toolchain/lib/gcc-lib/mipsel-linux/3.2/include
-DKBUILD_BASENAME=c_r4k  -c -o c-r4k.o c-r4k.c
c-r4k.c: In function `r4k_flush_cache_range_s16d16i16':
c-r4k.c:130: structure has no member named `context'
c-r4k.c:137: warning: implicit declaration of function `find_vma'
c-r4k.c:137: warning: assignment makes pointer from integer without a
cast
c-r4k.c:139: structure has no member named `context'
c-r4k.c:139: structure has no member named `context'
c-r4k.c:147: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s32d16i16':
c-r4k.c:166: structure has no member named `context'
c-r4k.c:173: warning: assignment makes pointer from integer without a
cast
c-r4k.c:175: structure has no member named `context'
c-r4k.c:175: structure has no member named `context'
c-r4k.c:183: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s64d16i16':
c-r4k.c:201: structure has no member named `context'
c-r4k.c:208: warning: assignment makes pointer from integer without a
cast
c-r4k.c:210: structure has no member named `context'
c-r4k.c:210: structure has no member named `context'
c-r4k.c:218: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s128d16i16':
c-r4k.c:236: structure has no member named `context'
c-r4k.c:243: warning: assignment makes pointer from integer without a
cast
c-r4k.c:245: structure has no member named `context'
c-r4k.c:245: structure has no member named `context'
c-r4k.c:253: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s32d32i32':
c-r4k.c:271: structure has no member named `context'
c-r4k.c:278: warning: assignment makes pointer from integer without a
cast
c-r4k.c:280: structure has no member named `context'
c-r4k.c:280: structure has no member named `context'
c-r4k.c:288: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s64d32i32':
c-r4k.c:306: structure has no member named `context'
c-r4k.c:313: warning: assignment makes pointer from integer without a
cast
c-r4k.c:315: structure has no member named `context'
c-r4k.c:315: structure has no member named `context'
c-r4k.c:323: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_s128d32i32':
c-r4k.c:341: structure has no member named `context'
c-r4k.c:348: warning: assignment makes pointer from integer without a
cast
c-r4k.c:350: structure has no member named `context'
c-r4k.c:350: structure has no member named `context'
c-r4k.c:358: warning: assignment makes pointer from integer without a
cast
c-r4k.c: In function `r4k_flush_cache_range_d16i16':
c-r4k.c:374: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_range_d32i32':
c-r4k.c:386: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s16d16i16':
c-r4k.c:401: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s32d16i16':
c-r4k.c:411: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s64d16i16':
c-r4k.c:421: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s128d16i16':
c-r4k.c:431: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s32d32i32':
c-r4k.c:441: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s64d32i32':
c-r4k.c:451: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_s128d32i32':
c-r4k.c:461: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_d16i16':
c-r4k.c:471: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_mm_d32i32':
c-r4k.c:481: structure has no member named `context'
c-r4k.c: In function `r4k_flush_cache_page_s16d16i16':
c-r4k.c:492: structure has no member named `vm_mm'
c-r4k.c:501: structure has no member named `context'
c-r4k.c:508: warning: assignment makes pointer from integer without a
cast
c-r4k.c:525: structure has no member named `context'
c-r4k.c:525: structure has no member named `context'
c-r4k.c:536: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s32d16i16':
c-r4k.c:541: structure has no member named `vm_mm'
c-r4k.c:550: structure has no member named `context'
c-r4k.c:557: warning: assignment makes pointer from integer without a
cast
c-r4k.c:573: structure has no member named `context'
c-r4k.c:573: structure has no member named `context'
c-r4k.c:584: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s64d16i16':
c-r4k.c:589: structure has no member named `vm_mm'
c-r4k.c:598: structure has no member named `context'
c-r4k.c:605: warning: assignment makes pointer from integer without a
cast
c-r4k.c:621: structure has no member named `context'
c-r4k.c:621: structure has no member named `context'
c-r4k.c:632: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s128d16i16':
c-r4k.c:637: structure has no member named `vm_mm'
c-r4k.c:646: structure has no member named `context'
c-r4k.c:653: warning: assignment makes pointer from integer without a
cast
c-r4k.c:670: structure has no member named `context'
c-r4k.c:670: structure has no member named `context'
c-r4k.c:681: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s32d32i32':
c-r4k.c:686: structure has no member named `vm_mm'
c-r4k.c:695: structure has no member named `context'
c-r4k.c:702: warning: assignment makes pointer from integer without a
cast
c-r4k.c:719: structure has no member named `context'
c-r4k.c:719: structure has no member named `context'
c-r4k.c:730: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s64d32i32':
c-r4k.c:735: structure has no member named `vm_mm'
c-r4k.c:744: structure has no member named `context'
c-r4k.c:751: warning: assignment makes pointer from integer without a
cast
c-r4k.c:768: structure has no member named `context'
c-r4k.c:768: structure has no member named `context'
c-r4k.c:779: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_s128d32i32':
c-r4k.c:784: structure has no member named `vm_mm'
c-r4k.c:793: structure has no member named `context'
c-r4k.c:800: warning: assignment makes pointer from integer without a
cast
c-r4k.c:817: structure has no member named `context'
c-r4k.c:817: structure has no member named `context'
c-r4k.c:827: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_d16i16':
c-r4k.c:832: structure has no member named `vm_mm'
c-r4k.c:841: structure has no member named `context'
c-r4k.c:848: warning: assignment makes pointer from integer without a
cast
c-r4k.c:875: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_d32i32':
c-r4k.c:880: structure has no member named `vm_mm'
c-r4k.c:889: structure has no member named `context'
c-r4k.c:896: warning: assignment makes pointer from integer without a
cast
c-r4k.c:924: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `r4k_flush_cache_page_d32i32_r4600':
c-r4k.c:929: structure has no member named `vm_mm'
c-r4k.c:938: structure has no member named `context'
c-r4k.c:945: warning: assignment makes pointer from integer without a
cast
c-r4k.c:973: warning: deprecated use of label at end of compound
statement
c-r4k.c: In function `setup_noscache_funcs':
c-r4k.c:1360: `_dma_cache_wback_inv' undeclared (first use in this
function)
c-r4k.c:1360: (Each undeclared identifier is reported only once
c-r4k.c:1360: for each function it appears in.)
c-r4k.c:1361: `_dma_cache_wback' undeclared (first use in this function)
c-r4k.c:1362: `_dma_cache_inv' undeclared (first use in this function)
c-r4k.c: In function `setup_scache_funcs':
c-r4k.c:1443: `_dma_cache_wback_inv' undeclared (first use in this
function)
c-r4k.c:1444: `_dma_cache_wback' undeclared (first use in this function)
c-r4k.c:1445: `_dma_cache_inv' undeclared (first use in this function)
make[2]: *** [c-r4k.o] Error 1
make[2]: Leaving directory
`/home/cameron/kernel/linux-2.4.19/arch/mipsnommu/mm'make[1]: ***
[first_rule] Error 2
make[1]: Leaving directory
`/home/cameron/kernel/linux-2.4.19/arch/mipsnommu/mm'make: ***
[_dir_arch/mipsnommu/mm] Error 2

---

From: Cameron Cooper <[email-masked]>
Date: Sat, 28 May 2005 11:48:01 -0400

> at the photos, if that helps ;)

A number of people have taken PSPs apart. The only useful thing that has
come from it was a dump of the firmware. Now that we have that it
doesn't seem that there is much else to do since we don't know anything
about the chips and there are not too many visible traces. However, if
you have a new idea of something that could be done to the hardware,
then maybe there would be a reason to sacrifice another.

Cameron

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 28 May 2005 20:27:04 +0100

> arch/mipsnommu/mm/c-r4k.c

Sort of amusing to make that a separate architecture - TLB or not, the
remainder of the CPU stays pretty much the same.

> does.

The key feature of R4000 caches that causes alot of complexity in the
c-r4k code is that it needs to handle virtually indexed caches, especially
avoid cache aliases.  On a TLB-less processors aliases are not possible,
thus c-r4k.c can be significantly simplified making it quite a bit more
similar to c-r3k.c.

> Can you help me understand what this file does, and what I might

Your question would require a very long answer to be somewhat exhaustive,
so here the express version.  Start by reading Documentation/cachetlb.txt
from the kernel sources.  You can find plenty of discussions related to
this code in the linux-mips and linux-kernel archives - especially the
subtle points aren't exactly documented ;-)

  Ralf

---

From: Cameron Cooper <[email-masked]>
Date: Sat, 28 May 2005 15:35:50 -0400

> subtle points aren't exactly documented ;-)

Thanks, I'll check that out. However a new complexity has arisen. It
turns out that in addition to not having access to the MMU, we do not
have access to cp0. I'm afraid that this would require even more
rewriting of the kernel. Although I started this to learn something,
there might be more involved in this than I am prepared for.

Cameron