No, you don't. A fact that people are so happy to ignore :).cheqmate wrote:psppet: i think you're misunderstanding the purpose.
sure nid imports are much nicer, but to get there we need to use kernel functions somehow, dont we ?
2.0 - user space mode - syscall
maybe we dont HAVE to (just maybe, how would you know for sure?). doesnt mean they couldnt be helpful the one or the other way at all. if anything, a complete list could enable ppl to recompile stuff for 2.0. it'd be ugly no doubt, but it'd work no less. cant see the point in discouraging anyone to do that if he likes to.No, you don't. A fact that people are so happy to ignore :).
> a complete list could enable ppl to recompile stuff for 2.0. it'd be ugly no doubt, but it'd work no less. cant see the point in discouraging anyone to do that if he likes to.
Very true. To each his own.
However this marks a fork in the road for PSP homebrew.
BTW: The Kxploit 1.5 hack was reasonably backward compatible with the 1.0 version. No major PSPSDK changes, and the binaries are essentially the same [give or take packaging]
The 2.0 TIFF exploit runs programs in a totally different world.
To support it would require a bit of work in the PSPSDK (using SYSCALLs, limited to modules already loaded into memory, true user mode, no kernel tricks - at least yet). A lot of the existing samples would not work.
FWIW: I'm not suggesting the PSPSDK support it -- based on my theory that 'homebrew' people will be happy to downgrade (and keep both 1.50 and 2.0 UPDATE programs on their memory stick just in case)
FWIW: much more interesting to me is if we can get the 2.0 binaries to load under a 1.0/1.50 homebrew. The web browser library and hopefully newer binary releases (perhaps USB hosting support?). However, by the time new features come out, the TIFF exploit will most likely be plugged.
In comparison, the 1.0/1.50 world is very stable and we don't have to play "catchup" with every 2.x release.
To each his own.
Very true. To each his own.
However this marks a fork in the road for PSP homebrew.
BTW: The Kxploit 1.5 hack was reasonably backward compatible with the 1.0 version. No major PSPSDK changes, and the binaries are essentially the same [give or take packaging]
The 2.0 TIFF exploit runs programs in a totally different world.
To support it would require a bit of work in the PSPSDK (using SYSCALLs, limited to modules already loaded into memory, true user mode, no kernel tricks - at least yet). A lot of the existing samples would not work.
FWIW: I'm not suggesting the PSPSDK support it -- based on my theory that 'homebrew' people will be happy to downgrade (and keep both 1.50 and 2.0 UPDATE programs on their memory stick just in case)
FWIW: much more interesting to me is if we can get the 2.0 binaries to load under a 1.0/1.50 homebrew. The web browser library and hopefully newer binary releases (perhaps USB hosting support?). However, by the time new features come out, the TIFF exploit will most likely be plugged.
In comparison, the 1.0/1.50 world is very stable and we don't have to play "catchup" with every 2.x release.
To each his own.
hehe well...as for pspinside, the 1.0 compatible version needs to be build seperatly since it is using some features that 1.0 doesnt have or implements differently... :)PspPet wrote:> a complete list could enable ppl to recompile stuff for 2.0. it'd be ugly no doubt, but it'd work no less. cant see the point in discouraging anyone to do that if he likes to.
Very true. To each his own.
However this marks a fork in the road for PSP homebrew.
BTW: The Kxploit 1.5 hack was reasonably backward compatible with the 1.0 version. No major PSPSDK changes, and the binaries are essentially the same [give or take packaging]
dont think it would terribly much work....basically you'd need a lib with all syscalls wrapped in functions. probably a little script could be used to generate that from the header files and a list of syscalls :=PThe 2.0 TIFF exploit runs programs in a totally different world.
To support it would require a bit of work in the PSPSDK (using SYSCALLs, limited to modules already loaded into memory, true user mode, no kernel tricks - at least yet). A lot of the existing samples would not work.
FWIW: I'm not suggesting the PSPSDK support it -- based on my theory that 'homebrew' people will be happy to downgrade (and keep both 1.50 and 2.0 UPDATE programs on their memory stick just in case)
however -to me- using syscalls on 2.0 is a temporary solution, which just might help us out for the time we dont have something proper.
yep, i would also favour that approach...i'd rather not update to 2.0 if i can avoid it, yet i might play the one or other commercial game (maybe...a well...probably not. but i'll get some anyway just for curiosity :=P) having something like that firmware launcher (certainly needs to be a lot more advanced i'd think) to run 2.0 without flashing would be the ideal solution (to me).FWIW: much more interesting to me is if we can get the 2.0 binaries to load under a 1.0/1.50 homebrew. The web browser library and hopefully newer binary releases (perhaps USB hosting support?). However, by the time new features come out, the TIFF exploit will most likely be plugged.
In comparison, the 1.0/1.50 world is very stable and we don't have to play "catchup" with every 2.x release.
-
27Bstroke6
- Posts: 23
- Joined: Thu Jul 07, 2005 3:56 pm
/me wonders how you would do anything on a 2.0 psp without syscalls right now.No, you don't. A fact that people are so happy to ignore :).
however since i just started hacking my psp a few days ago i obviously dont really know what im talking about... so go ahead and enlighten me :)
on the catchup issue i think we shouldnt accept the fact that sony wont let homebrew coders play (bought!) new games.
so if new games actually relied on new kernel functionality(or even worse custom protections that actually LIKE to rely on new versions) we'd have to hack it to the extend that we can dump that anyway.
in the end we cant really stop hacking their updates, so why not do it completely, as long as its possible.
*Sigh*:
- Someone writes an EBOOT loader (stefan mentioned he was working on one).
- Said loader kills off all of the VSH threads. Knowing Sony, there's approximately 1 billion of them running.
- Said loader resolves 2.0 syscalls using a static list compiled from some other source.
- Nothing in PSPSDK or the toolchain has to change.
duh
i never suggested anything about using hardcoded syscalls in pspsdk or for anything more than a proof of concept pong, which sure is nonsense. so it was a misunderstanding from the start. all i wanted to say is that compiling a list of syscalls is a good idea atm.
since writing a pbp loader that handles imports "manually" is trival i think most people are concentrating on doing the mode transition anyway. so without a list of syscalls you'd be pretty much lost trying to "get there". on the way you may want to dump some memory, read the controller, see if you can dma into kernel memory...
i never suggested anything about using hardcoded syscalls in pspsdk or for anything more than a proof of concept pong, which sure is nonsense. so it was a misunderstanding from the start. all i wanted to say is that compiling a list of syscalls is a good idea atm.
since writing a pbp loader that handles imports "manually" is trival i think most people are concentrating on doing the mode transition anyway. so without a list of syscalls you'd be pretty much lost trying to "get there". on the way you may want to dump some memory, read the controller, see if you can dma into kernel memory...
Since I would like to downgrade and do some 1.50 homebrew, I'll release my unfinished 2.00 loader (for EBOOT.PBP files) project. I Don't think I will finish it in the near future, because I have still some PS2 projects that I would like to finish first. And it's pretty hard to debug, since it's coded in assembly ;)
It runs Nem's hello world for the 1.00 just fine. But other programs I've tested just crash (tested ~6).
It resolves the NIDs to syscalls from a list of 83 NIDs (used groepaz' syscall list). Don't know if other programs crash because of missing NIDs or because of a bug in my code or something else.
But anyway, enough talking, here's the code, and "compiled" tiff file:
psp200loader.zip.
Maybe someone finds it usefull for his own loader project, although I doubt anyone can read my code :P
To test it put an EBOOT.PBP (nem's hello world for example) into "ms0:/PSP/GAME/BOOT/" and the tiff into PHOTOS.
Btw. it has an intergrated disassembler (some instructions missing), so you can view the code before running it :)
It runs Nem's hello world for the 1.00 just fine. But other programs I've tested just crash (tested ~6).
It resolves the NIDs to syscalls from a list of 83 NIDs (used groepaz' syscall list). Don't know if other programs crash because of missing NIDs or because of a bug in my code or something else.
But anyway, enough talking, here's the code, and "compiled" tiff file:
psp200loader.zip.
Maybe someone finds it usefull for his own loader project, although I doubt anyone can read my code :P
To test it put an EBOOT.PBP (nem's hello world for example) into "ms0:/PSP/GAME/BOOT/" and the tiff into PHOTOS.
Btw. it has an intergrated disassembler (some instructions missing), so you can view the code before running it :)
infj
Did you do anything about allocating the extra RAM required, to break the supposed 64k limit?
One guess is that the crashes are due to trying to do kernel-priv stuff. Any idea if exception handlers require kernel privs? I'm starting to think it's about time I tried setting up exception handlers to make debugging this stuff a lot easier.
One guess is that the crashes are due to trying to do kernel-priv stuff. Any idea if exception handlers require kernel privs? I'm starting to think it's about time I tried setting up exception handlers to make debugging this stuff a lot easier.
Why should there be a 64k limit anyway? Do you have any sources? I thought it's just a missunderstanding, because the first loader which loads the "h.bin" is written to load only 64k. I heard from jonny2002 from the pspupdates forum that he was able to load a 128k binary (and I think he's a reliable source, since he helped me a lot with this tiff exploit stuff).Fanjita wrote:Did you do anything about allocating the extra RAM required, to break the supposed 64k limit?
infj
Ah, that's good to hear. I wasn't sure if that was the case or not - I thought perhaps it might be an issue with memory segmentation or similar.
I've started experimenting with allocating quantities of memory and loading into it, although it looks like the syscall IDs for the memory management routines aren't the same for 2.0 vs 1.5.
One thing I definitely don't understand - what kernel features are actually required for homebrew to run? It seems that the API has most of the kernel functionality exposed via syscalls - are special priv levels required to call some of those?
I've started experimenting with allocating quantities of memory and loading into it, although it looks like the syscall IDs for the memory management routines aren't the same for 2.0 vs 1.5.
One thing I definitely don't understand - what kernel features are actually required for homebrew to run? It seems that the API has most of the kernel functionality exposed via syscalls - are special priv levels required to call some of those?
Is anyone still working on compiling the NID -> syscall lists?
I've been playing around with Saotome's loader (I see the credit has been stolen by some other guys, who published exactly the same source... :( ), the most likely issue with non-trivial PBPs is that a lot of the NIDs (including a lot of interesting ones) are still not resolved.
I've been working on trying to find the mem alloc syscall IDs, using the method described by Saotome, but so far I haven't had very much luck at all - must be doing it wrong.
I've been playing around with Saotome's loader (I see the credit has been stolen by some other guys, who published exactly the same source... :( ), the most likely issue with non-trivial PBPs is that a lot of the NIDs (including a lot of interesting ones) are still not resolved.
I've been working on trying to find the mem alloc syscall IDs, using the method described by Saotome, but so far I haven't had very much luck at all - must be doing it wrong.
http://hitmen.c02.at/files/releases/psp/syscalls.txt updated, thanks to a nice list provided by vampire
BTW Groepaz, you mentioned that you thought a generic loader is more complex than just NID resolution.
Do you happen to know what the various hurdles are likely to be? I'm still feeling my way with the PBPs, ELFs and NIDs, etc., and trying to continue developing Saotome's loader.
I'm working with what I hope is a fairly straightforward EBOOT ('Portable Tetris'), and I can confirm that having resolved all the NIDs (thanks to Vampire's recent work), I still can't get the EBOOT to run.
The only thing I can currently think of is code relocation : I'm not sure how much absolute addressing goes on in these images, but I can imagine that would be an issue. Any pointers on opcodes that take absolute addressing would be great.
Do you happen to know what the various hurdles are likely to be? I'm still feeling my way with the PBPs, ELFs and NIDs, etc., and trying to continue developing Saotome's loader.
I'm working with what I hope is a fairly straightforward EBOOT ('Portable Tetris'), and I can confirm that having resolved all the NIDs (thanks to Vampire's recent work), I still can't get the EBOOT to run.
The only thing I can currently think of is code relocation : I'm not sure how much absolute addressing goes on in these images, but I can imagine that would be an issue. Any pointers on opcodes that take absolute addressing would be great.
i havent looked in much detail at how the kernel loads elfs (ie, pbp files) but i would think that it builds an internal list of which syscalls resolve to which NID (however thats done in detail) since it needs that kind of information for loading modules dynamically later. the problem i see here is that your loader would need to use, and also do proper additions to exactly that list or else things might go wrong later. so while resolving some syscalls (which are already resolved by the kernel) from a static list might work, anything further would (probably) require access to that internal list, which in turn is likely to reside in kernel memory space.
that said, i'm unaware of a user mode function that allows to register a certain syscall to a certain NID (and something simelar) - if that exist it would be whats needed, but i highly doubt it.
that said, i'm unaware of a user mode function that allows to register a certain syscall to a certain NID (and something simelar) - if that exist it would be whats needed, but i highly doubt it.
I suspect that because we're running under VSH, it's already loaded most of the PRXs and therefore resolved most of the NIDs.
At present the loader does just statically resolve the NIDs from a list, which as far as I've seen does seem to work - unless Nem's Hello World really doesn't contain any NIDs at all.
It might also be possible to do dynamic NID resolution algorithmically for any new modules, by hooking the module loading syscalls, since the resolution does seem to be deterministic.
But at the moment, I'm pretty sure that the problem lies with relocatable symbols or some other general complication of the ELF loading process, so I'm digging around to try to understand what exactly makes Nem's ELF so different to all the other samples I've tried.
At present the loader does just statically resolve the NIDs from a list, which as far as I've seen does seem to work - unless Nem's Hello World really doesn't contain any NIDs at all.
It might also be possible to do dynamic NID resolution algorithmically for any new modules, by hooking the module loading syscalls, since the resolution does seem to be deterministic.
But at the moment, I'm pretty sure that the problem lies with relocatable symbols or some other general complication of the ELF loading process, so I'm digging around to try to understand what exactly makes Nem's ELF so different to all the other samples I've tried.
More syscall trivia:
> it builds an internal list of which syscalls resolve to which NID (however thats done in detail)
"sceKernelRegisterSystemCallTable" and related "sceKernelQuerySystemCall" (resolved to kernel address, the NID mapping is on top of that - technically the same NID can be used in two separate places)
However they are part of "InterruptManagerForKernel", not available to user mode apps.
As mentioned already, the order of the "syscalls" is the order of the export table for that one module. With the syscall number in increasing order. You only need to know the next to be allocated.
I haven't figured out how the module order is assigned (it isn't the module load order). It appears the order is fixed, but I don't know if that will always be true (technically it doesn't have to be - the actual SYSCALL numbers aren't meant to be hard-coded inside your app)
> it builds an internal list of which syscalls resolve to which NID (however thats done in detail)
"sceKernelRegisterSystemCallTable" and related "sceKernelQuerySystemCall" (resolved to kernel address, the NID mapping is on top of that - technically the same NID can be used in two separate places)
However they are part of "InterruptManagerForKernel", not available to user mode apps.
As mentioned already, the order of the "syscalls" is the order of the export table for that one module. With the syscall number in increasing order. You only need to know the next to be allocated.
I haven't figured out how the module order is assigned (it isn't the module load order). It appears the order is fixed, but I don't know if that will always be true (technically it doesn't have to be - the actual SYSCALL numbers aren't meant to be hard-coded inside your app)
some missing functions in the list
Code: Select all
0x20da,0xCC1D3699,sceKernelStopUnloadSelfModule
0x20f4,0xB77905EA,sceGeEdramSetAddrTranslation
0x20f5,0xDC93CFEF,sceGeGetCmd
0x20f6,0x57C8945B,sceGeGetMtx
0x20f8,0x0BF608FB,sceGeRestoreContext
0x20fb,0x5FB86AB0,sceGeListDeQueue
0x214a,0xB4F378FA,sceDisplayIsForeground
0x214c,0x9C6EAAD7,sceDisplayGetVcount
0x214d,0x4D4E10EC,sceDisplayIsVblank
0x2154,0x773DD3A3,sceDisplayGetCurrentHcount
0x2158,0x02BAAD91,sceCtrlGetSamplingCycle
0x215c,0xC152080A,sceCtrlPeekBufferNegative
0x215e,0x60B81F86,sceCtrlReadBufferNegative
0x215f,0xB1D0E5CD,sceCtrlPeekLatch
0x2160,0x0B588501,sceCtrlReadLatch
0x217e,0x87440F5E,scePowerIsPowerOnline
0x217f,0x0AFD0D8B,scePowerIsBatteryExist
0x2180,0x1E490401,scePowerIsBatteryCharging
0x2182,0xD3075926,scePowerIsLowBattery
0x2186,0x2085D15D,scePowerGetBatteryLifePercent
0x2187,0x8EFB3FA2,scePowerGetBatteryLifeTime
0x219c,0xDFA8BAF8,scePowerUnregisterCallback
0x219e,0x843FBF43,scePowerSetCpuClockFrequency
0x219f,0xB8D7B3FB,scePowerSetBusClockFrequency
0x21a3,0xBD681969,scePowerGetBusClockFrequencyInt
0x21a5,0xB1A52C83,scePowerGetCpuClockFrequencyFloat
0x21a6,0x9BADB3EB,scePowerGetBusClockFrequencyFloat
I've released my updated version of Saotome's eboot loader to my website:
Clicky!
Improvements:
- more syscalls supported (thanks to this thread!)
- sets up $ra before calling the app, helps avoid problems with apps that launch a 'user_main' thread before exiting (default for PSPSDK apps)
- ported to C so easier to maintain
- disassembler completed, now dumps to file on memory stick
- lots of debugging info displayed to screen in case of problems
If anyone wants the source, just yell. I plan to work on various improvements over the next week or so.
I'm particularly interested to hear of EBOOTs that don't work. Kernel-mode ones are a given (although some patches _might_ be possible), but I'd still like to hear about those too.
Clicky!
Improvements:
- more syscalls supported (thanks to this thread!)
- sets up $ra before calling the app, helps avoid problems with apps that launch a 'user_main' thread before exiting (default for PSPSDK apps)
- ported to C so easier to maintain
- disassembler completed, now dumps to file on memory stick
- lots of debugging info displayed to screen in case of problems
If anyone wants the source, just yell. I plan to work on various improvements over the next week or so.
I'm particularly interested to hear of EBOOTs that don't work. Kernel-mode ones are a given (although some patches _might_ be possible), but I'd still like to hear about those too.
http://hitmen.c02.at/files/releases/psp/syscalls.txt updated again. contains all info i could gather from libdoc.xml. if anyone wants to provide further info he probably needs to examine the prx files (go for it :) please provide fw version, syscall, nid and function name :))
Can anyone confirm that the API used by pspDebugRegisterExceptionHandler() (sceExceptionManager(), if I'm not mistaken) requires kernel mode?
I'd like to incorporate exception handlers into the EBOOT loader (it would make debugging non-working eboots much easier, but I'm blocked by 2 things:
- Judging by the PSPSDK sample, I assume that it requires kernel-privs.
- We don't yet know the syscall number for this function.
It's worth my while to try to dig around to find the syscall number if there's a chance that it will work, but if someone can confirm that there's no hope of using it without kernel privs, then I won't waste my time on it.
I'd like to incorporate exception handlers into the EBOOT loader (it would make debugging non-working eboots much easier, but I'm blocked by 2 things:
- Judging by the PSPSDK sample, I assume that it requires kernel-privs.
- We don't yet know the syscall number for this function.
It's worth my while to try to dig around to find the syscall number if there's a chance that it will work, but if someone can confirm that there's no hope of using it without kernel privs, then I won't waste my time on it.
i think i've found all syscalls for 2.00 vsh-mode ...
the updated list is here: http://hitmen.c02.at/files/releases/psp/syscalls.txt
the updated list is here: http://hitmen.c02.at/files/releases/psp/syscalls.txt
Last edited by Vampire on Wed Nov 30, 2005 7:55 pm, edited 1 time in total.
yay i was occupied with our homepage for a while....whatever, the update list is here: http://hitmen.c02.at/html/psp_docs.html
Three seems to be a loadmodule/loadmodulebyid error in that list, they are exchanged (in 1.50)Vampire wrote:i think i've found all syscalls for 2.00 vsh-mode ...
the updated list is here: http://hitmen.c02.at/files/releases/psp/syscalls.txt
The syscall of sceKernelLoadModule in 1.50 is 0x20d0 (checked with experimentation), and not 0x20cf.
(and i suppose that then sceKernelLoadModulebyID have to be 0x20cf then)
Last edited by moonlight on Tue Mar 21, 2006 5:57 pm, edited 1 time in total.