forums.ps2dev.org

assume my function is running at pc=01e01234 and i would link to jump to 00172345, then i use jal or execps2, but both not work. i am puzzle and do not know how to do!

lezy wrote:assume my function is running at pc=01e01234 and i would link to jump to 00172345, then i use jal or execps2, but both not work. i am puzzle and do not know how to do!

It would be easier to know what is wrong if you showed us the assembly code you are using.

If he's trying to jump to 0x172345 then it's pretty obvious what's wrong :).

Indeed :)

mrbrown wrote:If he's trying to jump to 0x172345 then it's pretty obvious what's wrong :).

Good point. :) But isn't 0x00172345 mapped into user space ? I don't have my eedocs with me at the moment, but I thought mappings at 0x0000000-0x0FFFFFF would be user space mapped through the TLB, and as long as he is in user mode...

Ahh...indeed. Its quite doubteful he properly setting up the TLB...

Yo! See other thread about syscalls, interrupts, and subsequent references to exceptions, to which a properly configured TLB table and handler would be a necessity. ;)

my code is like this,i use naplink to execute it.when i do not define LOADFROMMEM,the rom0:TESTMODE can be load.buf if i defint LOADFROMMEM,it did not work;
#include <stdio.h>
#include <tamtypes.h>
#include <kernel.h>
#include <sifrpc.h>
#include <compat.h>
#include <malloc.h>
#include <fileio.h>
#include <loadfile.h>
#define LOADFROMMEM
#ifdef LOADFROMMEM
u32 cmdbuf[]={0x3c040016,0x24847cb8,0x0000282d,0x0000302d,0x24030006,0x0000000c};
#endif
void loadtestmode()
{
#ifndef LOADFROMMEM
asm volatile ( " .word 0x3c040016\n"// lui $4,0x16
" .word 0x24847cb8\n"// addiu $4,$4,0x7cb8
" .word 0x0000282d\n"// daddu $5,$0,$0
" .word 0x0000302d\n"// daddu $6,$0,$0
" .word 0x24030006\n"// addiu $3,$0,6
" .word 0x0000000c\n");// syscall
#else
asm volatile("nop\nnop\nnop\nnop\nnop\nnop\n");
#endif

}

int main()
{
u32 *p;
p=(u32 *)loadtestmode;
memcpy((u32*)0x00167cb8,"rom0:TESTMODE\0",16);
#ifdef LOADFROMMEM
memcpy(p,cmdbuf,sizeof(cmdbuf));
#endif
asm volatile ( "sync.p\n"
"sync\n"
"jal %0\n" :: "r" (p));
return 0;
}

Your code is really complex for something which is really simple...


Anyway, the problem here shouldn't belong to the "jal" you're doing, since you say the code works when not defining LOADFROMMEM. For me, the function "loadtestmode" has obviously a prolog. Your memcpy doesn't write at the first byte of your asm, but at some bytes in the prolog. Your solution should be to use the __attribute__((naked)) on your loadtestmode function so that no extra code is added by the compiler. But this still sound strange...


I wouldn't have done it like this at all anyway, and I still wonder what you're trying to achieve :)

gorim wrote:

mrbrown wrote:If he's trying to jump to 0x172345 then it's pretty obvious what's wrong :).

Good point. :) But isn't 0x00172345 mapped into user space ? I don't have my eedocs with me at the moment, but I thought mappings at 0x0000000-0x0FFFFFF would be user space mapped through the TLB, and as long as he is in user mode...

Ahh...indeed. Its quite doubteful he properly setting up the TLB...

Yo! See other thread about syscalls, interrupts, and subsequent references to exceptions, to which a properly configured TLB table and handler would be a necessity. ;)

I hope you are joking, seriously you are, right ?

thank you everybody.i have found the point.i add flushcache(0),flushcache(2) afer memcpy,then the code run well.
but could come one say something about flushcache,i do not know what it does.

blackdroid wrote:I hope you are joking, seriously you are, right ?

Would it help if you know that at that time: I had not slept, from the local food became possessed by the spirit of tubgirl, and had a plane flight to catch in the next few hours ?

Worse, driving home from the airport on arrival, I barely kept the car on the road, and ended up causing my tire to get blown out, losing a hubcap, and damaging the rim (and took me longer than it should have to remember there are such things as spare tires).

I honestly had a hard time thinking straight for about 2 days. Looking back on what I wrote, I can't even explain why I arrived at what I said.

lezy wrote:thank you everybody.i have found the point.i add flushcache(0),flushcache(2) afer memcpy,then the code run well.
but could come one say something about flushcache,i do not know what it does.

When you copy the memory, generally some of it (or all of it if it's small enough) remains in the data cache instead of memory. On CPUs with separate data and instruction caches, this means that if you then try to execute the code, it won't be found in the instruction cache and then loads it from main memory despite the fact that the main memory is invalid with the valid contents residing in the data cache. Flushing the data cache causes the data to be stored into main memory where it can then be fetched for execution by the CPU.

So be sure to flush the caches when copying or DMAing code around. Copying -> flush after moving via CPU. DMA -> flush before moving via DMA. You should really also invalidate the instruction cache for the area where the code is moved to make sure any old code that may have been overwritten isn't still in the instruction cache.