forums.ps2dev.org

[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--
NO to K1.5 !

[pspZorba]

Does someone have an explanation?
_________________
--pspZorba--
NO to K1.5 !

[TyRaNiD]

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

[pspZorba]

Well I think so, here the prx makefile

[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.
_________________
--pspZorba--
NO to K1.5 !

[Pirata Nervo]

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

Upgrade your PSP

[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]
_________________
--pspZorba--
NO to K1.5 !

[Pirata Nervo]

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

Upgrade your PSP

[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?
_________________
--pspZorba--
NO to K1.5 !

[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.
_________________
--pspZorba--
NO to K1.5 !

[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:

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

[Pirata Nervo]

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

Upgrade your PSP

[pspZorba]

JF:

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

in which moonlight wrote:

[Pirata Nervo]

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

Upgrade your PSP

[J.F.]

[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:

[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--
NO to K1.5 !

[pspZorba]