Porting To New System

Porting To New System

[developer]

Hello all,

I'm a long time Linux user, and computer engineering student. I've recently become interested in porting Linux to Sony's PSP gaming system. I'm wanting to do this mainly as an exercise in understanding the kernel better, also I just think it would be neat :). The PSP system has a MIPS R4000 CPU which is already supported so it is my understanding that the port should not be so difficult, not to say that I think it will be easy. At this time I have a gcc toolchain set up which allows me to write and execute code on the PSP, however I have never attempted a kernel port so I'm a little unsure on what to do. I'm looking for someone who wouldn't mind assisting me with my project by helping me with my questions on the porting process. I you have time to answer a few emails here and there, and would like to help me, I would greatly appreciate it.

Thanks,
Cameron Cooper

Re: Porting To New System

[Stanislaw Skowronek]

First, does the PSP's processor have a MMU? If not, then there is not much
point in porting Linux (or for that matter, anything else). A machine
without a MMU is pretty worthless under Linux except as a fixed-function
embedded system; to wit, mmap(2) will not work.

Next, see http://www.linux-mips.org/wiki/index.php/Porting - it's
excellent. I don't know if a PSP has an accessible serial port - if not,
then you are somewhat screwed (OK, so not that bad; I've done a port that
used graphical display from the beginning for all debugging purposes).

You've got to do three things:
 1) use lines no longer than 80 chars in your mails ;)
 2) get all docs on the PSP you can get - reverse engineering is fun but
    only if you enjoy hacking for 14 hours a day,
 3) take a look at some directory in arch/mips.

Of course, the hardest of them is (2) in my experience, unless Sony felt
generous at the time and released all PSP docs. My port was completely
reverse-engineered but I wouldn't advise to do that unless you are sure
you can spare the time and effort.

Oh, and one more thing: USE THE CVS LINUX-MIPS.ORG TREE! The kernel.org
tree is so out of sync that it's virtually worthless.

Cheers,

Stanislaw Skowronek

Re: Porting To New System

[Ed Okerson]

> Hello all,
>
> I'm a long time Linux user, and computer engineering student. I've
> recently become interested in porting Linux to Sony's PSP gaming system.
> I'm wanting to do this mainly as an exercise in understanding the kernel
> better, also I just think it would be neat :). The PSP system has a MIPS
> R4000 CPU which is already supported so it is my understanding that the
> port should not be so difficult, not to say that I think it will be easy.
> At this time I have a gcc toolchain set up which allows me to write and
> execute code on the PSP, however I have never attempted a kernel port so
> I'm a little unsure on what to do. I'm looking for someone who wouldn't
> mind assisting me with my project by helping me with my questions on the
> porting process. I you have time to answer a few emails here and there,
> and would like to help me, I would greatly appreciate it.

You should probably have a look at http://www.psp-linux.org/ click on
messages boards at the top of the page to get to all the action.  I am
sure these guys can answer all your questions.

Ed Okerson

Re: Porting To New System

[Stanislaw Skowronek]

> You should probably have a look at http://www.psp-linux.org/ click on
> messages boards at the top of the page to get to all the action.  I am
> sure these guys can answer all your questions.

Hurm, hurm. I think that the closed-circle development model is, uhm, less
efficient - there are no tech info on the forums which means nobody can
try and follow. They just finished organizing themselves, and it took them
*three months*. Three months wasted on choosing developers. He he he.

That said, they have really hard work to do - I wish them all the luck
they need, which is *a lot*. Cracking locked-down systems with proprietary
formats is incredibly hard. It's hard enough when they aren't proprietary,
or when they aren't deliberately locked-down.

Stanislaw Skowronek

PS. There are also some funny things there, like "Off-Topic: please keep
related to the PSP". Maybe I'm just an anal-retentive paranoid (OK, I know
I am), but when I see something like that I feel put upon. It's like all
those "keep off the grass" and "private property, survivors will be shot
again" signs. Placed in the middle of Sahara.

Re: Porting To New System

[Kumba]

Stanislaw Skowronek wrote:
> 
> That said, they have really hard work to do - I wish them all the luck
> they need, which is *a lot*. Cracking locked-down systems with proprietary
> formats is incredibly hard. It's hard enough when they aren't proprietary,
> or when they aren't deliberately locked-down.

With this in mind, I'm watching the port of Linux to the Nintendo DS.  They 
apparently just got 2.6 and framebuffer working, so it'll be interesting to see 
where they go with it.  Given the DS is a far more constrained system, and 
Nintendo not very forthcoming on their hardware specs, I'm surprised at the 
speed with which they've gotten things working.

And PSP isn't entirely closed -- it is based to a certain degree off PS2 
hardware, of which Sony release 6 of a supposed 7 total technical documents 
regarding the innards of the system.  Now I imagine alot of the custom hacks 
needed to support the R5900 in PS2 aren't needed in PSP, since it uses a more 
standard CPU, this might have an impact on how fast or slow they wind up porting 
the kernel.


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: small hands 
do them because they must, while the eyes of the great are elsewhere."  --Elrond

Re: Porting To New System

[Cameron Cooper]

>  > You should probably have a look at http://www.psp-linux.org/ click on
>  > messages boards at the top of the page to get to all the action.  I am
>  > sure these guys can answer all your questions.
>  
>  Hurm, hurm. I think that the closed-circle development model is, uhm, less
>  efficient - there are no tech info on the forums which means nobody can
>  try and follow. They just finished organizing themselves, and it took them
>  *three months*. Three months wasted on choosing developers. He he he.

That project is pretty much a joke. There is literally no work being done there. After three months of selecting developers they chose 12 people, and of those twelve were me and an application someone submitted under the name Dennis Ritchie. Since they have chosen developers over a month ago, they have not done a single thing. Beyond that, I don't like their closed development model. I have started a Sourceforge project for PSP Linux at psplinux.sf.net .
  
>  That said, they have really hard work to do - I wish them all the luck
>  they need, which is *a lot*. Cracking locked-down systems with proprietary
>  formats is incredibly hard. It's hard enough when they aren't proprietary,
>  or when they aren't deliberately locked-down.

I understand that cracking a closed system is very hard, so I would rather not do it that way. I have never ported a kernel, so I don't know what I will suggest is possable, but it seems like it could be. 

At this time I can write code for the PSP. I have access to the keypad, MemoryStick, and the frame buffer. The programs that I compile can be placed on the memory stick and launched from the PSP's OS. All I/O in the program is done through calls to libraries provided in the firmware, which are part of the PSPs OS. Becuase the PSP makes heavy use of encryption, it has been very hard to reverse engineer the software. We can't simply look at the libraries to understand the hardware better, because they are encrypted. They only way we have been able to discover anything about the libraries is through the small bits of uencrypted code that were extracted from the firmware chip.

What I would like to know is if it would be possable to do what User Mode Linux has done. Would it be possable to run Linux on top of the PSP's current OS, and write drivers for Linux which will use the libraries provided by the firmware? I know that this is not an ideal solution, but when the PSP being as closed as it as, I see it being a very long time until we will know enough about the hardware to do it another way. Mostly because the PSP makes much use of many custom chips and almost every executable is encrypted.

So even if this is a bad way of doing it, is it even possable?

Thanks,
Cameron Cooper

Re: Porting To New System

[Alan Cox]

On Gwe, 2005-05-27 at 17:28, Cameron Cooper wrote:
> 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 ?

Re: Porting To New System

[Cameron Cooper]

>  > 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.

Re: Porting To New System

[Stanislaw Skowronek]

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

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

Stanislaw

Re: Porting To New System

[Alan Cox]

On Gwe, 2005-05-27 at 18:30, Stanislaw Skowronek wrote:
> >  Does the firmware give you the ability to control MMU mappings ?
> 
> 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

Re: Porting To New System

[Cameron Cooper]

> 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.

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

Re: Porting To New System

[Stanislaw Skowronek]

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

Re: Porting To New System

[Cameron Cooper]

> 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.

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

Re: Porting To New System

[Ralf Baechle]

On Fri, May 27, 2005 at 03:11:23AM +0000, developer wrote:

> I'm a long time Linux user, and computer engineering student. I've recently become interested in porting Linux to Sony's PSP gaming system. I'm wanting to do this mainly as an exercise in understanding the kernel better, also I just think it would be neat :). The PSP system has a MIPS R4000 CPU which is already supported

Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.

  Ralf

Re: Porting To New System

[Alan Cox]

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.

Re: Porting To New System

[Alan Cox]

On Gwe, 2005-05-27 at 20:52, Cameron Cooper wrote:
> 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?

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.

Re: Porting To New System

[Stanislaw Skowronek]

> 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

Re: Porting To New System

[Stanislaw Skowronek]

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

Re: Porting To New System

[Cameron Cooper]

> 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.

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

Re: Porting To New System

[Cameron Cooper]

> PS. Besides, does taking one apart actually impart any knowledge? I looked
> 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

Re: Porting To New System

[Ralf Baechle]

On Sat, May 28, 2005 at 11:43:03AM -0400, Cameron Cooper wrote:

> 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

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

> 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.

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
> do to rewrite it for NO_MM?

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

Re: Porting To New System

[Cameron Cooper]

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

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

Re: Porting To New System

[Cameron Cooper]

> Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.

It's a R4000.

http://www.linux-mips.org/wiki/index.php/PSP

Cameron

Re: Porting To New System

[Thiemo Seufer]

Cameron Cooper wrote:
> > Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.
> 
> It's a R4000.
> 
> http://www.linux-mips.org/wiki/index.php/PSP

That's what the press release claims, but it is most likely wrong.


Thiemo

Re: Porting To New System

[Ralf Baechle]

On Sat, May 28, 2005 at 03:43:44PM -0400, Cameron Cooper wrote:

> > Nitpicking - it's probably an 4K, not R4000 which is ~ '91 vintage.
> 
> It's a R4000.
> 
> http://www.linux-mips.org/wiki/index.php/PSP

Don't believe everything you read ...  Sony claims the processors are two
R4000 32-bit cores.  Which is obvious nonsense, the R4000 is 64-bit.

  Ralf

Re: Porting To New System

[Cameron Cooper]

> Don't believe everything you read ...  Sony claims the processors are two
> R4000 32-bit cores.  Which is obvious nonsense, the R4000 is 64-bit.

Thanks, that is very useful to know.

Cameron