A new port of uClinux on PSP (with accessibility to ms0)

[roge]

root@bransk:/opt/kernel/uclinux/linux-2.6.22# make ARCH=mips CROSS_COMPILE=mipsel-uclibc- vmlinux.bin
CHK include/linux/version.h
CHK include/linux/utsrelease.h
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/docproc
CALL scripts/checksyscalls.sh
HOSTCC scripts/mod/mk_elfconfig
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/pnmtologo
HOSTCC scripts/conmakehash
CC init/main.o
Assembler messages:
Error: trap exception not supported at ISA 1
init/main.c: In function `start_kernel':
init/main.c:506: warning: implicit declaration of function `arch_early_setup'
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2


:((((

[M.Jackson]

root@bransk:/opt/kernel/uclinux/linux-2.6.22# make ARCH=mips CROSS_COMPILE=mipsel-uclibc- vmlinux.bin

You must have been using the toolchain I published in my website, which is too old to compile the 2.6 kernel. To build the kernel, you must have a more up-to-date toolchain which is always available at GNU's website.

[roge]

ok
i have installed a new toolchain based in ps2dev svn..
its lasted, right? but nothing

now:

root@bransk:/opt/kernel/uclinux/linux-2.6.22# make ARCH=mips CROSS_COMPILE=psp- vmlinux.bin
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
LD init/mounts.o
psp-ld: unrecognised emulation mode: elf32ltsmip
Supported emulations: elf_mipsallegrexel_psp elf32elmip
make[1]: *** [init/mounts.o] Error 1
make: *** [init] Error 2
root@bransk:/opt/kernel/uclinux/linux-2.6.22#


the toolchain installs binutils with target elf_mipsallegrexel_psp


damn :/


i am compiling a new toolchain now, with the packages updated, without patches for psp, only for compile kernel

[M.Jackson]

hoho, guess you might need to read the descriptions in my website more carefully, cos I did mention that neither the mips toolchain I provided nor the psp toolchain (the one that ps2dev provides) can compile the 2.6 kernel due to various reasons...anyway, that doesn't matter any more, cos you are now in the right direction. Just keep going to build the new toolchain and don't give up, cos I think this constant battle with bugs and frustration is just what we do as programmers.

[Apeiron]

This should be my last question for a bit...

switch_root doesn't work on the root file system, and pivot_root can't be run from anywhere other than pid 1, so in order to switch to the disk, the init script requires modification.. so this brings me to my question, is there a way to modify initrd without rebuilding the kernel as well? Like, a way to "split" initrc out of vmlinux.bin, expand initrd into a file tree, modify what's needed, repack initrd, and put it back in vmlinux.bin?

[M.Jackson]

These days I have been wandering in websites talking about homebrew development on Nintendo DS. Amazingly, they have very specific hardware references as detailed as what kind of interrupts certain hardware handles and what are the purposes of certain registers serve for. Those information covers almost every pieces of h/w available on DS (including wifi and audio), and perhaps that's why the dslinux they developed can almost drive the machine as good as the original firmware (or there is still a firmware running beneath linux so that linux can take advantage of it?).

Honestly in terms of hacking I thought the YetAnotherDoc for PSP was already a heck of a job regarding detail levels. But looking at what have been dug out from the DS, it is just...I don't know, but I guess PSP developers would only be too happy to see if that kind of information is available for us.

Is it true that Nintendo had once disclosed those h/w information on purpose or inadvertently? Or is it just because that DS (and its predecessor) had been around for such a long time that people had had it all figured out?

[M.Jackson]

so this brings me to my question, is there a way to modify initrd without rebuilding the kernel as well? Like, a way to "split" initrc out of vmlinux.bin, expand initrd into a file tree, modify what's needed, repack initrd, and put it back in vmlinux.bin?

It is possible to modify the "initrd" (actually in 2.6 it is often referred to as "rootfs" which is basically a cpio package embedded inside the kernel), but you still need to recompile the kernel to carry the new initial file system. To do away the recompiling, I guess you could simply not to use any "initrd" at all (you still need to rebuild the kernel one more time to switch off the initrd option) and then specify a new root device residing in other places at boot time (like ms0). For example, try to build a root file structure on ms0 and add "root=/dev/ms0" to the boot command line to see if it works (Perhaps it needs more work to be done that this).

[futaris]

Building initramfs images (into the kernel) is simple enough using Openembedded. There is even a userspace bootloader for selecting for booting from NFS, loopback ext2 images, etc.

I'll try and merge your patches into the tree this weekend. It should also make building the toolchain, kernel etc simpler for everyone else.

[shadash]

I know there are several people that are very interested in running linux on the PsP. Can you give a specific step by step examples showing exactly how you got this working. I know it's annoying but if you can show...

1. Where you got the source
2. What files you modified
3. What modifications were implemented (step by step how to)
4. How you compiled the kernel (step by step how to)
5. How the kernel was modified
6. What modifications were implemented (step by step how to)

Do I need to create a filesystem on the PsP? (step by step how to)

As soon as all the steps above are documented Linux will take off on the PsP. Because it will be put on wikis everywhere.

Personally I want to try and run MythTV frontend on the PsP or write a remote control application to control it.

[danzel]

IMO:
The DS low level stuff has been figured out because they needed to figure it out, there is no firmware like we have on the PSP to handle the hardware for them.
On the PSP we have figured out the firmware really well as that is what we need to aim at to run homebrew on it.

[Apeiron]

I know there are several people that are very interested in running linux on the PsP. Can you give a specific step by step examples showing exactly how you got this working. I know it's annoying but if you can show...

1. Where you got the source
2. What files you modified
3. What modifications were implemented (step by step how to)
4. How you compiled the kernel (step by step how to)
5. How the kernel was modified
6. What modifications were implemented (step by step how to)

Do I need to create a filesystem on the PsP? (step by step how to)

As soon as all the steps above are documented Linux will take off on the PsP. Because it will be put on wikis everywhere.

Personally I want to try and run MythTV frontend on the PsP or write a remote control application to control it.

1. Read his site.
2. Read his site.
3. Read his site.
4. Well, you can always read his site.
5. See answers 1 through 4.
6. You could look at the patch on his site.

File system exists on the PSP, and it is mounted at boot (not rootfs though), for this answer you could of just read his site.

The above was already documented for those who know where to look and what for.

MythTV front end probably can't run due to hardware limitations (lack of RAM or too low processor), though I've never looked into it. I've only heard of "MythTV" mentioned, don't know what it is though.

Currently there are no drivers for the IR port, and if I remember what it said on his site, he's not going to write them himself.


All in all, if you had looked around, all your questions would of been answered. What code to modify? Look at the patch files. Where he got the source? They're linked to in their respective areas on his site.

So, in case you missed the link(s) to his site somehow..
http://jacksonm88.googlepages.com/linuxonpsp.htm
or the mirror if the above is down..
http://jacksonm80.googlepages.com/linuxonpsp.htm

I don't mean to sound rude with the above, it's just you asked questions easily answered at the same place you would of had to go to download it.

[M.Jackson]

I know there are several people that are very interested in running linux on the PsP. Can you give a specific step by step examples showing exactly how you got this working. I know it's annoying but if you can show...

1. Where you got the source
2. What files you modified
3. What modifications were implemented (step by step how to)
4. How you compiled the kernel (step by step how to)
5. How the kernel was modified
6. What modifications were implemented (step by step how to)

Do I need to create a filesystem on the PsP? (step by step how to)

As soon as all the steps above are documented Linux will take off on the PsP. Because it will be put on wikis everywhere.

Personally I want to try and run MythTV frontend on the PsP or write a remote control application to control it.

I am working on an unified toolchain so that both the kernel and all the applications can be built by one toolchain only (instead of two like today) whereby the steps can be simplifed a bit. After that, maybe I will compile another detailed step-by-step guide to those who are interested in this port. But for the moment, you can visit http://jacksonm88.googlepages.com/linuxonpsp.htm or http://jacksonm80.googlepages.com/linuxonpsp.htm where you can find all the downloads you need and some high-level descriptions of the steps. If you are very experienced in kernel development, those information should be enough to help you start.

[M.Jackson]

Ok, this is weirder than the weirdest thing i had ever seen. I was testing the new toolchain incorporating the latest uClibc 0.9.29 by using the classic hello world program. At first, nothing showed up on the screen, but the program exited normally. Nothing crashed. Initially i thought it could have been some sort of relocation problem when loading the executable whereby the program could not locate the correct address housing the Hello World string. However, later when I tried printf( "%d %s\n", 1234, "Hello, world" ), it worked!!? After looking into the disassembly code, I discovered that gcc 4.2 was so damn smart that it automatically optimized my code replacing printf( "Hello World\n" ) with puts( "Hello World\n" ), and even printf( "%s\n", "Hello World" ) would still be caught by the optimization (truly smart, no doubt about that. But if the logic gets more complex like the previous one with numbers, it will skip optimization). That's cool, I mean, it shouldn't hurt and could even shrink down the size of my app. But the problem is, neither does puts nor fputs work! They didn't crash the program, but didn't output anything neither as they should have. Then I thought maybe it was some sort of data buffering trick and calling a fflush afterwards would do, but neither did that work...

How could this even be possible that printf/fprintf/vfprintf work just fine while only puts/fputs does not? Does anyone have any possible theories on this? Could it be caused by some new features in this uClibc version that i can turn off?

[shadash]

I'm just reaching but this might help you.

libc6: fputs can lose data in buffer on signal
http://lists.debian.org/debian-glibc/20 ... 00163.html

But this one seems more likely

http://www.uclibc.org/lists/buildroot/2 ... 02618.html

Specifically...
/* Note: Nonportable as fputs need only return nonnegative on success. */

Since the PSP is mips it may apply

[M.Jackson]

damn!!! I finally figured out what the hell was going on in the puts/printf issue...It turns out to be the fact that one of the key instructions in Allegrex is not compliant with the stardard MIPS instruction set. To be exact, when the following instructions were executed:

li a1, 1
li a2, 6
mul a1,a2,a1

a1 doesn't contain the result of 6 after line 3. Instead, a1 retains its initial content of 1!!! This is totally bizarre compared to any standard MIPS implementation. As a result this behavior completely messes up the subsequent logic of puts/fputs, and the worse thing is that if the mul instruction widely spreads across uClibc, the whole thing will undoubtedly become a nightmare for its unpredictability and unreliability.

But interestingly, if I copy the same code of fputs out of uClibc and place it into my app (with a different function signature off course), the compiler will somehow translate the multiplication into a "mult" instruction (instead of a "mul") which appears functioning normally in Allegrex. Is there a way I can tune gcc into using "mult" always rather than "mul"?

[hlide]

damn!!! I finally figured out what the hell was going on in the puts/printf issue...It turns out to be the fact that one of the key instructions in Allegrex is not compliant with the stardard MIPS instruction set. To be exact, when the following instructions were executed:

li a1, 1
li a2, 6
mul a1,a2,a1

a1 doesn't contain the result of 6 after line 3. Instead, a1 retains its initial content of 1!!! This is totally bizarre compared to any standard MIPS implementation. As a result this behavior completely messes up the subsequent logic of puts/fputs, and the worse thing is that if the mul instruction widely spreads across uClibc, the whole thing will undoubtedly become a nightmare for its unpredictability and unreliability.

But interestingly, if I copy the same code of fputs out of uClibc and place it into my app (with a different function signature off course), the compiler will somehow translate the multiplication into a "mult" instruction (instead of a "mul") which appears functioning normally in Allegrex. Is there a way I can tune gcc into using "mult" always rather than "mul"?

Allegrex has no 3-register MUL.

the exact instructions to call is :

li a1, 1
li a2, 6
mult a2,a1
mflo a1

[MythosGR]

Hi all,

It seems that version 0.2 doesn't work with new firmware 3.80.

I get "The game could not be started (80020148)" when I try to run it.

Any help will be appreciated.

Thanks

[hlide]

Assuming you compile your gcc,

in gcc-X.X.X/gcc/config/mips/mips.h :

Code: Select all

/* Generate three-operand multiply instructions for SImode.  */
#define GENERATE_MULT3_SI       ((TARGET_MIPS3900                       \
                                  || TARGET_MIPS5400                    \
                                  || TARGET_MIPS5500                    \
                                  || TARGET_MIPS7000                    \
                                  || TARGET_MIPS9000                    \
				  || TARGET_MAD				\
                                  || ISA_MIPS32	                        \
                                  || ISA_MIPS32R2                       \
                                  || ISA_MIPS64)                        \
                                 && !TARGET_MIPS16)

/* Generate three-operand multiply instructions for DImode.  */
#define GENERATE_MULT3_DI       ((TARGET_MIPS3900)                      \
				 && !TARGET_MIPS16)

i cannot find if there is an option to disable this generation though

[Wally]

Hi all,

It seems that version 0.2 doesn't work with new firmware 3.80.

I get "The game could not be started (80020148)" when I try to run it.

Any help will be appreciated.

Thanks

This would be because 3.80 is not hacked, please Google Pandora's Battery or ask over in http://www.dcemu.co.uk/vbulletin or irc.malloc.us #psp-hacks thanks

[hlide]

Hi all,

It seems that version 0.2 doesn't work with new firmware 3.80.

I get "The game could not be started (80020148)" when I try to run it.

Any help will be appreciated.

Thanks

OMG, are you telling us that you upgrade your PSP with the official firmware 3.80. SONY does *NEVER* support homebrews. And this PSP-Linux is a homebrew. Just bite your fingers for your stupidity.

[Raphael]

Hi all,

It seems that version 0.2 doesn't work with new firmware 3.80.

I get "The game could not be started (80020148)" when I try to run it.

Any help will be appreciated.

Thanks

This is worthy for hall of shame :/

[a_noob]

Raphael: At least he knows how to spell better than half of the other idiots out there.

[riverful]

incredible works. very glad to meet this sites. :)

about the porting uclinux to PSP, i wanna get some helps.

i) i'm curious Jackson Mo's bootloader src code. what's the Address loading the kernel? and rootfs image?? etc.... i wonder other things except that. i used to U-boot for arm core. i wanna get codes. would you mind send me the code for email?? my email addres is [email protected].

ii) in Uclinux sites, i don't get uclinux-2.6.22-uc1 patch. just 2.6.22-uc0. so, i try to convert the kernel.patch for uc0. but, it's some difficult things. i'm failed uc1 patch into uc0 kernel. the following files is missed.

arch/mips/psp/ipl_sdk/sysreg.c
arch/mips/psp/ipl_sdk/syscon.c
arch/mips/psp/ipl_sdk/memstk.c
arch/mips/psp/ipl_sdk/psp_uart.c

how solve the probelm??? how to get uc1 kernel or patch??

beside this, i has no problem to enjoy it. it's just happy thing for me to see kernel booting messages.

actually, my object is handhelds oscilloscope using PSP gpio port.
i wait Jackson Mo's reply or PSP hacker's messages.
thanks to read~ :)

[Rammsteinfan13]

Is there a possibility to run this on the slim or an other linux client?

[M.Jackson]

incredible works. very glad to meet this sites. :)

about the porting uclinux to PSP, i wanna get some helps.

i) i'm curious Jackson Mo's bootloader src code. what's the Address loading the kernel? and rootfs image?? etc.... i wonder other things except that. i used to U-boot for arm core. i wanna get codes. would you mind send me the code for email?? my email addres is [email protected].

ii) in Uclinux sites, i don't get uclinux-2.6.22-uc1 patch. just 2.6.22-uc0. so, i try to convert the kernel.patch for uc0. but, it's some difficult things. i'm failed uc1 patch into uc0 kernel. the following files is missed.

arch/mips/psp/ipl_sdk/sysreg.c
arch/mips/psp/ipl_sdk/syscon.c
arch/mips/psp/ipl_sdk/memstk.c
arch/mips/psp/ipl_sdk/psp_uart.c

how solve the probelm??? how to get uc1 kernel or patch??

beside this, i has no problem to enjoy it. it's just happy thing for me to see kernel booting messages.

actually, my object is handhelds oscilloscope using PSP gpio port.
i wait Jackson Mo's reply or PSP hacker's messages.
thanks to read~ :)

Actually the four files you are missing are not part of the kernel source at all. They are the source files I took from Booster's IPL SDK (marvelous stuff) with a little modification allowing the kernel to drive some of the PSP h/w at lowlevel. I think applying the kernel patch I posted on my site should have created those files for you (or maybe you have to create an empty directory named "ipl_sdk" at that location beforehand) 'cos the content of those 4 files are already contained in the patch file.

I guess using 2.6.22-uc0 as the base version would probably be ok as well, as I don't think there should be many differences between uc0 and uc1 that are significant enough to break the kernel from running on PSP.

As to the source code of the bootloader, I just forgot to post it on my website previously. But actually it is no more complex than a single function that copys the kernel image out of flash into RAM and then jumps to the starting location. I think everyone with hands and eyes and, most importantly, the PSPSDK will be able to write one on his own :) But anyway, I will keep it in mind to post it on my website next time.

[M.Jackson]

I won't bet on chances that anyone would happen to know the answer to this, but i am kind of running out of ideas right now and I got nowhere else to turn for help. I was working on the new toolchain which will be capable of building both kernel and apps. But when loading busybox produced by the new toolchain, the system threw out an error stating "relocation outside program". when I looked into it closely, I discovered that it was trying to relocate a virtual address of fffd4a54, which is obviously absurd, 'cos the linking address begins with 00400000 and the file size is no larger than 00064000 and hence there is no way any code insde the program would want to reference an address soooo huge.

When I tried to examine the original ELF image (which has not yet been transformed into a flat executable), I found that this "unusual" virtual address was contained in a relocation entry that appears different from other workable normal relocation entries, which may be a clue to unravel ths mystery. Here is how the relocation entry is defined in the standard ELF ABI:

typedef struct {
Elf32_Addr r_offset; // 32 bits
Elf32_Word r_info; // 32 bits
} Elf32_Rel;

Those workable "normal" entries usually look like:
24 0C 46 00 02 02 00 00 (little endian)

which makes r_offset=0x460c24 and r_info=0x202. But when it comes to those abnormal entries, they look like:
38 D7 45 00 0C 01 00 00

and the address of 0x45d738 is pointing to a word of 0xfffd4a54 waiting to be relcoated, which is obviously a mission impossible. I am guessing, maybe this special type of entries with r_info=0x10c requires special treatment during relocation compared to the normal procedure applied to the type of 0x202, but I just can't figure out how. I had looked through the "ELF ABI Spec" and "MIPS ABI Supplement" where no section talks about the composition of r_info (what does 0x202 or 0x10c mean? how does it relate to definitions like R_MIPS_32 or others), let alone the right way to translate r_offset under r_info=0x10c.

Does anyone have any idea about this?

[hlide]

I won't bet on chances that anyone would happen to know the answer to this, but i am kind of running out of ideas right now and I got nowhere else to turn for help. I was working on the new toolchain which will be capable of building both kernel and apps. But when loading busybox produced by the new toolchain, the system threw out an error stating "relocation outside program". when I looked into it closely, I discovered that it was trying to relocate a virtual address of fffd4a54, which is obviously absurd, 'cos the linking address begins with 00400000 and the file size is no larger than 00064000 and hence there is no way any code insde the program would want to reference an address soooo huge.

When I tried to examine the original ELF image (which has not yet been transformed into a flat executable), I found that this "unusual" virtual address was contained in a relocation entry that appears different from other workable normal relocation entries, which may be a clue to unravel ths mystery. Here is how the relocation entry is defined in the standard ELF ABI:

typedef struct {
Elf32_Addr r_offset; // 32 bits
Elf32_Word r_info; // 32 bits
} Elf32_Rel;

Those workable "normal" entries usually look like:
24 0C 46 00 02 02 00 00 (little endian)

which makes r_offset=0x460c24 and r_info=0x202. But when it comes to those abnormal entries, they look like:
38 D7 45 00 0C 01 00 00

and the address of 0x45d738 is pointing to a word of 0xfffd4a54 waiting to be relcoated, which is obviously a mission impossible. I am guessing, maybe this special type of entries with r_info=0x10c requires special treatment during relocation compared to the normal procedure applied to the type of 0x202, but I just can't figure out how. I had looked through the "ELF ABI Spec" and "MIPS ABI Supplement" where no section talks about the composition of r_info (what does 0x202 or 0x10c mean? how does it relate to definitions like R_MIPS_32 or others), let alone the right way to translate r_offset under r_info=0x10c.

Does anyone have any idea about this?

try : objdump -dr <your offending object file>

-r displays relocation entries in disassembly code so you may look at 0x00(4/0)5d738 what kind of relocation it is

you may need -R if it is a dynamic relocation.

EDIT: there is also Elf_Rela with an additional r_addend member, but you probably checked it too.

[hlide]

DELETED

[J.F.]

The last time I had a relocation outside of program error, adding -g to the CFLAGS "fixed" the problem.

[M.Jackson]

man, this looks like a dead end. I have tried all the methods i can think of(including J.F.'s one though I knew it standed little chance to succeed) but no good result was yielded.

But I did find out more info about this. the BAD relocation entries are actually of the type of R_MIPS_GPREL32, instead of R_MIPS_32 for those normal entries. And according to the mips abi, the formula used for its reloc calculation should be:
A + S + GP0 – GP

in which:
A: Represents the addend used to compute the value of the relocatable
field.
S: Represents the value of the symbol whose index resides in the relocation entry, unless the the symbol is STB_LOCAL and is of type
STT_SECTION in which case S represents the original sh_addr minus
the final sh_addr.
GP0: Represents the gp value used to create the relocatable object.
GP: Represents the final gp value to be used for the relocatable, executable, or shared object file being produced.

it doesn't make much sense to me either, 'cos I just can't imagine what kind of formula can translate a value from 0xfffxxxxx to a reasonable address that looks like 0x891xxxxx.

One thing interests me, though, is that all the programs i wrote, either as simple as hello-world or more complex ones, do not contain relocation entries of the type of R_MIPS_GPREL32, making me wonder what kind of code could have generated the demand for such type of relocation. If I can understand the nature of this relocation type and the scenario in which it is used, maybe I can work around the problem by revising those code accountable for this type of relocation a little bit in busybox. And i think the best way to do this is to write a short program that can also result in this special type of reloc. I had tried ".gpword" which is said to be capable of leading to a GPREL32 entry, but turned out it was not supported by GAS. Could anyone give me an example demonstrating what kind of coding would produce this type of relocation?