Big Buffer in Kernel & Service mode

[FaderX]

OK,

im trying to do some stuff with a psar and i need to load it & im having trouble with buffers in kernel mode. Every other mode works, vsh, user etc. just not kernel.


here's what im using...or tried using,

Code: Select all

static u8 g_dataPSAR[23*1000*1000] __attribute__((aligned(64)));
static u8 g_dataOut[30*1000*1000] __attribute__((aligned(0x40)));
static u8 *g_dataOut2; 

Code: Select all

static u8 g_dataPSAR[23*1024*1024] __attribute__((aligned(64)));
static u8 *g_dataOut;[30*1024*1024] __attribute__((aligned(0x40)));
static u8 *g_dataOut2;

Code: Select all

u8  g_dataPSAR[10*1024*1024] __attribute__((aligned(64)));
u8  g_dataOut[3*1024*1024] __attribute__((aligned(64)));
u8  g_dataOut2[3*1024*1024] __attribute__((aligned(64)));

Code: Select all

u8  g_dataPSAR[23*1024*1024] __attribute__((aligned(64)));
u8  g_dataOut[3*1024*1024] __attribute__((aligned(64)));
u8  g_dataOut2[3*1024*1024] __attribute__((aligned(64)));

Code: Select all

u8  g_dataPSAR[23*1024*1024] __attribute__((aligned(64)));
u8  g_dataOut[30*1024*1024] __attribute__((aligned(64)));
u8  g_dataOut2[3*1024*1024] __attribute__((aligned(64)));

Code: Select all

static u8 g_dataPSAR[20500000] __attribute__((aligned(64))); 
static u8 g_dataOut[3000000] __attribute__((aligned(0x40)));
static u8 *g_dataOut2;

then i try this,

Code: Select all

static u8 *g_dataPSAR; 
static u8 *g_dataOut;
static u8 *g_dataOut2;

and it works until it gets to the function that uses the buffs then i get i nice little crash. argh

I'm required to use kernel as well because nearly all the functs can't be put in a prx. :s

If you have any idea about what may be wrong (don't say me, don't say me) please tell me.

Once again Cheers,
FX

[hlide]

pretty insane I must say what you are doing and not shameful you are. If you PRX is loaded in a kernel partition, it wouldn't be able to fit your data size requirements : 24 MB + 30 MB ! Kernel partition can only be 8 MB at most.

[FaderX]

pretty insane I must say what you are doing and not shameful you are. If you PRX is loaded in a kernel partition, it wouldn't be able to fit your data size requirements : 24 MB + 30 MB ! Kernel partition can only be 8 MB at most.

I'm booting straight into a elf that hasn't loaded any other prx's yet and it won't work.

Should i add a PSP_HEAP_SIZE_MAX(); thing to it?? *fairly sure that won't work after what you have said*

or what do you think i should do?

[J.F.]

The KERNEL partition is 8MB max PERIOD. All the rest of the memory is the user partition. You can't change that. The heap size only tells how much the app will take from the user partition.

[FaderX]

The KERNEL partition is 8MB max PERIOD. All the rest of the memory is the user partition. You can't change that. The heap size only tells how much the app will take from the user partition.

oh, now i know what you's mean,

So is there a way to use the user portion to use the buffers, like a user mode prx?

[J.F.]

Instead of trying to embed huge arrays in your thingy, you should instead be trying to allocate the memory. There are routines for allocating memory from the various partitions... consult the docs or look at existing source.

[FaderX]

Instead of trying to embed huge arrays in your thingy, you should instead be trying to allocate the memory. There are routines for allocating memory from the various partitions... consult the docs or look at existing source.

Code: Select all

void allocatmemory(void) 
{
     g_dataPSAR = (u8 *)memalign(64, 20500000); //Did have 0x44 but still didn't work
     if (!g_dataPSAR) { printf("Cannot allocate memory for PSAR data.... (0x%08x)\n", (int)g_dataPSAR); }
   
     g_dataOut = (u8 *)memalign(0x40,  2000000);
     if (!g_dataOut) { printf("Cannot allocate memory for buffer 1.... (0x%08x)\n", (int)g_dataOut); }  
}  

Thats what im trying now......crash lol :(

Is it to do with the size, idk

[hlide]

again, don't ever ask a question if you couldn't provide enough source for us to check. And please no source à la Ne0h.

1) why on earth do you need to have such big arrays ?

2) what is the source dealing with those arrays ?

3) are you creating a kernel pluggin only for slim version (because an overall of 24 MB is max on fat version !) ?

[jas0nuk]

Looks like he's wanting to extract PSARs (which can be up to 22mb), but it'd be better to stream them. :/

[FaderX]

again, don't ever ask a question if you couldn't provide enough source for us to check. And please no source à la Ne0h.

1) why on earth do you need to have such big arrays ?

2) what is the source dealing with those arrays ?

3) are you creating a kernel pluggin only for slim version (because an overall of 24 MB is max on fat version !) ?

Yes thats what im doing jas0nuk,

oh hlide how much of the src should you need

p.s. its based off RS psar dumper.


thx

[moonlight]

psar dumper has to be changed to allow streaming and not a full load, not just for cases like this, but also because the fat is almost running out of memory to hold lates updatest, a bit more and it will be impossible to hold it.
I was planning to do it if they changed encryption in 4.00... but they didn't.

[FaderX]

psar dumper has to be changed to allow streaming and not a full load, not just for cases like this, but also because the fat is almost running out of memory to hold lates updatest, a bit more and it will be impossible to hold it.
I was planning to do it if they changed encryption in 4.00... but they didn't.

Ohhh, thanks man,
this is because the fat has only 32mb & the slim has 64mb isnt it? oh and arent you getting rid of the 1.50 kernel coz of space, like flash space?


Thanks. :)

[Hellcat]

the slim has 64mb isnt it?

IIRC even on the Slim, those 64MB are split up into two partitions (apart from the other partitions, the memory is broken into), and are not "in one pice".

So, even on the Slim you can't do a malloc() of 60MB, or such thing....

[FaderX]

IIRC even on the Slim, those 64MB are split up into two partitions (apart from the other partitions, the memory is broken into), and are not "in one pice".

So, even on the Slim you can't do a malloc() of 60MB, or such thing....

yea, i get what you mean, thx

[Torch]

the slim has 64mb isnt it?

IIRC even on the Slim, those 64MB are split up into two partitions (apart from the other partitions, the memory is broken into), and are not "in one pice".

So, even on the Slim you can't do a malloc() of 60MB, or such thing....

I haven't tried allocating 56MB (available user space on slim) in one go, but I HAVE been able to gradually use up the entire 56MB until there was just a few KB left, without any problems.