kernel mode eboot vs kernel mode prx

[pspZorba]

with a 3.90M33 firmware when I do : sceIoDopen("flash0:/kd/");

- inside an Eboot in user mode it returns 8001000D, which is normal, it's EACCESS Permission denied.
- inside an Eboot in kernel mode it returns a valid handle, which is normal.
- inside a prx in kernel mode it returns 8001000D ????

Is it normal that the same code in a kernel mode prx and in a kermel mode eboot has a different behavior?

[pspZorba]

Does someone have an explanation?

[TyRaNiD]

Did you specify you only want kernel libs in your makefile?

[pspZorba]

Well I think so, here the prx makefile

Code: Select all

TARGET = myprx
OBJS = main.o

INCDIR =
CFLAGS = -O2 -G0 -Wall
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)

BUILD_PRX = 1
PRX_EXPORTS = myprx.exp

#USE_KERNEL_LIBC=1
USE_KERNEL_LIBS=1

LIBDIR =
LDFLAGS = -mno-crt0 -nostartfiles
LIBS = 
PSP_FW_VERSION = 371


PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak

and the main.c

Code: Select all

#include <pspkernel.h>
#include <pspdebug.h>
#include <pspsdk.h>
#include <stdlib.h>
#include <string.h>

#define printf pspDebugScreenPrintf

#define MODULE_NAME "myprx"

PSP_MODULE_INFO&#40;MODULE_NAME, PSP_MODULE_KERNEL, 1, 1&#41;;
PSP_MAIN_THREAD_ATTR&#40;0&#41;;




int module_start&#40;SceSize args, void *argp&#41;
&#123;
   return 0;
&#125;

int module_stop&#40;&#41;
&#123;
   return 0;
&#125;



SceUID dopen&#40;void&#41;
&#123;
    SceUID hd=1;

    u32 k1;
	k1 = pspSdkSetK1&#40;0&#41;;  // save the K1 value, and set it to 0

    hd = sceIoDopen&#40;"flash0&#58;/kd/"&#41;;

    pspSdkSetK1&#40;k1&#41;;

    return hd;
&#125;

[TyRaNiD]

what exactly is supposed to be calling your dopen function anyway?

[pspZorba]

I just want to explore flash0:/

inside the eboot (user mode) I can explorer flash0: but not flash0:/kd, and some others directories such as flash0:/vsh/module etc

if I set the eboot in kernel mode I can explore flash0:/kd,
but as it is not clean I don't want to set the eboot in kernel mode just for that.

So I tried using a prx in kernel mode, thinking that the behavior should be the same but I was surprised it wasn't the case.

[Pirata Nervo]

Have you tried secIoChStat the kd folder?
always worked for me

[pspZorba]

in the eboot in user mode?
[I think I did and it didn't work but I may have made an error]

or in the prx in kernel mode?
[I didn't try, as I was surprised it wasn't working, as I thought the prx in kernel mode should have the same behavior as an eboot in kernel mode]

[Pirata Nervo]

I only do sceChStat in vsh mode, should work on kernel mode too.

[pspZorba]

Ah ok you are using vsh mode, in vsh mode it's exactly the same as in an Eboot in kernel mode, you can sceIoDopen( "Flash0:/kd") without error.


But I prefer not creating an Eboot nor in kernel mode neither in VSH mode.
Since there are drawbacks I would like to not have.

So no explanations why i can't sceIoDopen( "Flash0:/kd") in a prx in kernel mode?

[J.F.]

Because your kernel mode prx has bugs? Seems to be the most likely thing from what's been said so far.

Did you remember to set K1 when in the kernel prx? Are you exceeding the stack size with large local arrays?

[pspZorba]

JF

I posted the code just few lines above.

I set K1, and I don't think there is a bug in three lines of code (well it can happen but not here) and it's not a stack overflow (no local variables but K1).

The code works perfectly for all other directories than flash0:/kd/,
sceIoDopen returns 800100D when trying to open flash0:/kd/ while it is not suppose to.

[J.F.]

Oh - sorry about that... my bad. :)

Uh... PSP_MODULE_KERNEL might not work on kernel PRXs. That's for kernel mode programs (as far as I know). If you check, it's defined as 0x1000. You are supposed to use 0x1006 in kernel mode PRXs. At least, that's what every kernel mode PRX I've ever seen uses.

[Pirata Nervo]

Maybe 0x1000 does not work for libraries :/

pspZorba:
0x8001000D = No file access permission
I don't you do this:

Code: Select all

sceIoGetstat("flash0:/kd", &stats);
	stats.st_attr &= ~0x0F;
	sceIoChstat("flash0:/kd", &stats, 3); //Hidden Stat
	sceIoChstat("flash0:/kd", &stats, 4); //Archive Stat
	sceIoChstat("flash0:/kd", &stats, 6); //Write Only Stat ?

PS. I forgot I changed to user mode my installer before releasing NervOS 2.0.5 and I use that so should work for kernel mode too ;)

[TyRaNiD]

Geez, what crack are people smoking these days. PSPLink is 0x1000 and still seems to work. Most like problem is your code :P

[J.F.]

Geez, what crack are people smoking these days. PSPLink is 0x1000 and still seems to work. Most like problem is your code :P

We're not talking about apps, we're talking about kernel mode prx's loaded by apps.

[Pirata Nervo]

I believe he is talking about his kernel prx too :P

[pspZorba]

JF:

I think 0x1000 and 0x1006 is the same cf :
http://forums.ps2dev.org/viewtopic.php? ... highlight=

in which moonlight wrote:

The 6 of 0x1006 is nothing specific.

I've just realized seing the modules of sce that they use the number 6 for modules that would act like a library, altough it would work fine with 0x1000, 0x1007 or whatever (x & 0x1000 = 0x1000) you want :)
(libpsar.prx 0x1006, libhttp.prx 0x0006, etc) Although it could be a coincidence ;)

Just for a rerminder, the code is not buggy I know that 0x8001000D = No file access permission (third line of my post)

the problem is in an eboot in kernel mode (or in vsh mode) the same code works and give no error, in a kernel mode prx for this particular directory (and for /modules/vsh) it gives an EACCESS Error, althought I've always thought that the behavior should be the same.

Do you think it's a bug or there is a real difference between an eboot in k mode or a prx in k mode ?

[Pirata Nervo]

I think there's a difference btw kernel eboot and kernel prx

[J.F.]

JF:

I think 0x1000 and 0x1006 is the same cf :
http://forums.ps2dev.org/viewtopic.php? ... highlight=

in which moonlight wrote:

The 6 of 0x1006 is nothing specific.

I've just realized seing the modules of sce that they use the number 6 for modules that would act like a library, altough it would work fine with 0x1000, 0x1007 or whatever (x & 0x1000 = 0x1000) you want :)
(libpsar.prx 0x1006, libhttp.prx 0x0006, etc) Although it could be a coincidence ;)

Just for a rerminder, the code is not buggy I know that 0x8001000D = No file access permission (third line of my post)

the problem is in an eboot in kernel mode (or in vsh mode) the same code works and give no error, in a kernel mode prx for this particular directory (and for /modules/vsh) it gives an EACCESS Error, althought I've always thought that the behavior should be the same.

Do you think it's a bug or there is a real difference between an eboot in k mode or a prx in k mode ?

I see, it's sort of an internal identifier code.

Seems there is a difference in the two. We've seen a few threads recently on launching an EBOOT from another - maybe you could launch a VSH EBOOT to handle the access for the app.

[SilverSpring]

http://forums.ps2dev.org/viewtopic.php?t=8917

So 1006 means a kernel module that is loaded and started (and can be stopped).

[moonlight]

One of the two number that make the 6 of the 0x1006 seems to avoid another module of same name to be loaded, and the other avoids it to be started, as normally you could load tons of modules with same name.

0x1007 (well, 0x1001 should also do it) is used when you don't want your module to be stopped. In these modules, module_stop has no sense, instead they use module_reboot_before to execute some finalization code when the kernel goes to reboot.

So, in other words, 0x1000 should be fine ;)

[moonlight]

By the way, how have you been supossed to execute a kernel eboot.pbp in M33 under 3.XX kernel?

Well, now to the real question.

I have not tested, so these are only thoughts. I think that the sony code may be checking your thread user level. Even if your code is executing in kernel mode, it belongs to a user thread who has called it.
You may try to create a kernel thread in the module_start, and check if from that thread, sceIoDopen works. If it works, then rewrite the code using thread communication mechanisms, so the thread that calls sceIodopen performs the operations on request of the thread with the syscall.

[moonlight]

IF the above solution works, you may try another one, to avoid wasting memory and time with threads. (hasn't been tested either).
The M33 function sctrlKernelSetUserLevel may work for this, call it inside the syscall of the prx:

Code: Select all

int oldlevel = sctrlKernelSetUserLevel(newlevel);
int k1 = pspSdkSetK1(0);
int res = sceIoDopen("flash0:/kd");
sctrlKernelSetUserLevel(oldlevel);
pspSdkSetK1(k1);
return res;

I don't remember which value of newlevel you should use, so just do a loop withing some range until it works... if it works :)

[pspZorba]

Thank you Moonlight for the clarification on 0x1000,0x1001,0x1006.

I will try your two suggestions.

I'll keep you posted guys, and thx all for trying to help.

[pspZorba]

Code: Select all

...... snip 


PSP_MODULE_INFO(MODULE_NAME, PSP_MODULE_KERNEL, 1, 1);
PSP_MAIN_THREAD_ATTR(0);

...... snip 

SceUID dopen(void)
{
    SceUID hd=1;

    u32 k1;
    int oldlevel = sctrlKernelSetUserLevel( 4);
    k1 = pspSdkSetK1(0);  // save the K1 value, and set it to 0

    hd = sceIoDopen("flash0:/kd/");

    pspSdkSetK1(k1);
    sctrlKernelSetUserLevel(oldlevel);


    return hd;
}

I've tried only the easiest solution and it works !!!!!

So both Eboot in km and prx km have probably the same behavior and

Moonlight wrote:
I have not tested, so these are only thoughts. I think that the sony code may be checking your thread user level. Even if your code is executing in kernel mode, it belongs to a user thread who has called it.

seems to be the right explanation. Thx Moonlight.


[Soccer] Go Spain[/Soccer]