 |
forums.ps2dev.org Homebrew PS2, PSP & PS3 Development Discussions
|
| View previous topic :: View next topic |
| Author |
Message |
StrmnNrmn
Joined: 14 Feb 2007 Posts: 46 Location: London, UK
|
Posted: Fri Dec 21, 2007 7:43 pm Post subject: |
|
|
Ok, just to confirm, the following does appear to work:
| Code: | void dcache_wbinv_all()
{
int i;
for(i = 0; i < 8192; i += 64)
{
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
} |
(As does iterating up to 16384 with a single call to __builtin_allegrex_cache, or performing the loop twice).
Does this imply that the other cache invalidation routines need similar tweaking (i.e doubling up)? I haven't found any issues to date with dcache_inv_all, dcache_inv_range or dcache_wbinv_range, but I'll post back here if I spot anything. |
|
| Back to top |
|
 |
Raphael

Joined: 17 Jan 2006 Posts: 646 Location: Germany
|
Posted: Sat Dec 22, 2007 2:07 am Post subject: |
|
|
| crazyc wrote: | | Raphael wrote: | | Isn't the cache 16kb? | I believe the entire cache (i+d) is 16kb, but i'm not 100% sure. |
| http://en.wikipedia.org/wiki/PlayStation_Portable wrote: | | Both CPUs contain 16KiB of two-way set associative instruction cache and data cache respectively. |
Though not the best source of information, I understand that as 16kb for each.
Someone reversed the sony function for wbinvall to check?
@StrmnNrmn: The inv_range ops definitely shouldn't need the doubling, as those operate on addresses and not indices. _________________ <Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
 |
crazyc
Joined: 17 Jun 2005 Posts: 410
|
Posted: Sat Dec 22, 2007 7:15 am Post subject: |
|
|
| Raphael wrote: | Though not the best source of information, I understand that as 16kb for each.
Someone reversed the sony function for wbinvall to check?
| The code in sceKernelWritebackInvalidateAll looks like:
| Code: | int sceKernelWritebackInvalidateAll(void) {
int i, j;
j = mfc0(0x16); // Config register
j = (j >> 6) & 3;
j = 2048 << j;
for(i = 0; i < j; i += 64)
{
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
} |
mfc0 0x16 is 0x480 so 2048 << 2 is 8192, but after testing, it does appear the dcache is 16kb. I don't know why it's done this way. |
|
| Back to top |
|
 |
Raphael

Joined: 17 Jan 2006 Posts: 646 Location: Germany
|
|
| Back to top |
|
 |
hlide
Joined: 10 Sep 2006 Posts: 750
|
Posted: Sat Dec 22, 2007 8:13 am Post subject: |
|
|
| crazyc wrote: | | Raphael wrote: | Though not the best source of information, I understand that as 16kb for each.
Someone reversed the sony function for wbinvall to check?
| The code in sceKernelWritebackInvalidateAll looks like:
| Code: | int sceKernelWritebackInvalidateAll(void) {
int i, j;
j = mfc0(0x16); // Config register
j = (j >> 6) & 3;
j = 2048 << j;
for(i = 0; i < j; i += 64)
{
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
} |
mfc0 0x16 is 0x480 so 2048 << 2 is 8192, but after testing, it does appear the dcache is 16kb. I don't know why it's done this way. |
Being a two-way set, you have two entries for the same index, so 2 x 128 x 64b = 16kb. You need to do it twice only if you want to invalidate and/or writeback an index in both cache-lines. The reason is probably because those cache operations would handle the oldest entry (using LRU algorithm ?).
EDIT:
| Quote: |
For a two-way set associative cache, the replacement algorithm is a bit more complex. [...] However, remember the principle of temporal locality : if a memory location has been referenced recently, it is likely to be referenced again in the very near future. A corollary to this is "if a memory location has not been accessed in a while, it is likely to be a long time before the CPU accesses it again." Therefore, a good replacement policy that many caching controllers use is the "least recently used" or LRU algorithm. The idea is to pick the cache line that was not most frequently accessed and replace that cache line with the new data. An LRU policy is fairly easy to implement in a two-way set associative cache system. All you need is a bit that is set to zero whenever the CPU accessing one cache line and set it to one when you access the other cache line. This bit will indicate which cache line to replace when a replacement is necessary
|
So if we suppose whenever we call CACHE instruction we are setting or resetting this bit LRU, it makes sense we need to do it twice to clear both cache-lines, since this LRU bit acts as a selector for WayA or WayB cache-line. |
|
| Back to top |
|
 |
crazyc
Joined: 17 Jun 2005 Posts: 410
|
Posted: Sat Dec 22, 2007 9:03 am Post subject: |
|
|
| hlide wrote: | | Being a two-way set, you have two entries for the same index, so 2 x 128 x 64b = 16kb. You need to do it twice only if you want to invalidate and/or writeback an index in both cache-lines. The reason is probably because those cache operations would handle the oldest entry (using LRU algorithm ?). | I guess by this dcache_inv_all should be wrong too, and looking at sceKernelDcacheInvalidateAll does 4096 << 2 so it is.
| Code: | static void dcache_inv_all() {
int i;
store_tag(i, 0, 0);
for(i = 0; i < 16384; i += 64) {
__builtin_allegrex_cache(0x13, i);
__builtin_allegrex_cache(0x11, i);
}
}
|
|
|
| Back to top |
|
 |
hlide
Joined: 10 Sep 2006 Posts: 750
|
Posted: Sat Dec 22, 2007 10:56 am Post subject: |
|
|
indeed,
| Code: |
int sceKernelWritebackInvalidateAll(void) {
int i, j;
j = mfc0(0x16); // Config register
j = (j >> 6) & 3;
j = 2048 << j;
for(i = 0; i < j; i += 64)
{
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
}
|
and
| Code: |
int sceKernelWritebackInvalidateAll(void) {
int i, j;
j = mfc0(0x16); // Config register
j = (j >> 6) & 3;
j = 4096 << j;
for(i = 0; i < j; i += 64)
{
__builtin_allegrex_cache(0x14, i);
}
}
|
should have similar effect if we suppose CACHE index operation truncates index in the range between 0 and 8191. |
|
| Back to top |
|
 |
Raphael

Joined: 17 Jan 2006 Posts: 646 Location: Germany
|
Posted: Sat Dec 22, 2007 11:09 am Post subject: |
|
|
| hlide wrote: | indeed,
| Code: |
int sceKernelWritebackInvalidateAll(void) {
int i, j;
j = mfc0(0x16); // Config register
j = (j >> 6) & 3;
j = 2048 << j;
for(i = 0; i < j; i += 64)
{
__builtin_allegrex_cache(0x14, i);
__builtin_allegrex_cache(0x14, i);
}
}
|
and
| Code: |
int sceKernelWritebackInvalidateAll(void) {
int i, j;
j = mfc0(0x16); // Config register
j = (j >> 6) & 3;
j = 4096 << j;
for(i = 0; i < j; i += 64)
{
__builtin_allegrex_cache(0x14, i);
}
}
|
should have similar effect if we suppose CACHE index operation truncates index in the range between 0 and 8191. |
I wonder why SCE decided to use both ways in different functions though. Must have a reason why. _________________ <Don't push the river, it flows.>
http://wordpress.fx-world.org - my devblog
http://wiki.fx-world.org - VFPU documentation wiki
Alexander Berl |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Sat Dec 22, 2007 1:10 pm Post subject: |
|
|
| Could just be two different programmers who think about things differently. One thought of writing the same index twice because of the two entries, while the other thought of the aliasing present on the opcode that handled it automatically. |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Sun Sep 21, 2008 3:02 pm Post subject: |
|
|
| Wow, been a while since anything new on the ME was posted. I have always had a sneaking suspicion that since the Slim doubled the GPU EDRAM from 2MB to 4MB that they probably doubled the ME local EDRAM as well. I FINALLY got around to testing my hypothesis... and it seems I was right! The local memory for the ME seems to extend all the way to 4MB now. Trying to check memory beyond 4MB hangs the ME... probably generates an exception. |
|
| Back to top |
|
 |
hlide
Joined: 10 Sep 2006 Posts: 750
|
Posted: Sun Sep 21, 2008 9:24 pm Post subject: |
|
|
does it make sense to double this ME local EDRAM ? I wonder why... could the latest 2 MB for VRAM fit the first 2MB of ME EDRAM and the latest 2MB for ME EDRAM the first 2MB of VRAM ? It would be awesome but probably wrong.
EDIT: "couldn't" !? sometimes i should reread my sentences :/
Last edited by hlide on Mon Sep 22, 2008 9:09 am; edited 2 times in total |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Mon Sep 22, 2008 5:43 am Post subject: |
|
|
| hlide wrote: | | does it make sense to double this ME local EDRAM ? I wonder why... the latest 2 MB for VRAM couldn't fit the first 2MB of ME EDRAM and the latest 2MB for ME EDRAM the first 2MB of VRAM. It would be awesome but probably wrong. |
If they keep frames in the local memory for use when decoding video, it makes lots of sense to double the local memory. Just as you couldn't fit two full video frames (720x503) into vram, you can't fit them in local memory either unless you double it.
That might not be the case as the ME can't directly access the vram, but if the ME is used in any way to help decode the video, doubling the local memory would be useful since the move to TV resolutions.
And yes, making the ME EDRAM the "extra" 2MB for the extra vram (and vice versa) would be a cool hack by Sony, and my test did NOT test that possibility. |
|
| Back to top |
|
 |
tailerb
Joined: 01 Jun 2008 Posts: 3 Location: Russia
|
Posted: Sat Jan 10, 2009 2:45 am Post subject: |
|
|
| Please tell me, when media engine runs my function how big the stack size is and at what adress(in case of mediaengine.prx)? |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Sat Jan 10, 2009 8:49 am Post subject: |
|
|
| tailerb wrote: | | Please tell me, when media engine runs my function how big the stack size is and at what adress(in case of mediaengine.prx)? |
Looking at the code, you find:
So the stack for the ME defaults to the end of local memory... at least, the end of local memory on the Phat. As mentioned above, the Slim has 4 MB of local memory instead of 2 MB. The 0x80000000 means kernel space+cacheable - most references I've seen to local memory use kernel space pointers to it.
Since nothing is currently using local memory, your stack is therefore 2 MB in size. |
|
| Back to top |
|
 |
tailerb
Joined: 01 Jun 2008 Posts: 3 Location: Russia
|
Posted: Sat Jan 10, 2009 5:16 pm Post subject: |
|
|
| Thanks a lot! And one more question: what happens with ME when power saving mode activated/deactivated ? |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Sun Jan 18, 2009 4:06 pm Post subject: |
|
|
| crazyc wrote: | | Shazz wrote: | Short question, what do we have in 0xbc100080 ?????? (And the value 7 for ?)
| Code: |
li k0, 0xbc100000
li t0, 7
sw t0, 80(k0)
|
Shouldn't it be 0xbc100050 to enable the ME clock ?
Thx |
Access to system memory causes an exception unless that is done.
|
Err - I just ran across something interesting today. The ME can't access the extended system memory in the Slim. Accesses to 0x08000000 to 0x09ffffff are fine, but trying to access 0x0a000000 on up hangs the ME.
I tried modifying the code above a few ways to see if I could "unlock" the extra mem, but it didn't work. I also tried accessing the memory through kernel mode (|0x80000000) which also fails. So far as I can tell right now, the ME can only access the first 32M of system memory. |
|
| Back to top |
|
 |
hlide
Joined: 10 Sep 2006 Posts: 750
|
Posted: Sun Jan 18, 2009 11:31 pm Post subject: |
|
|
| or there is a new mmio register to unlock access on the upper 32 MB we don't know about. Or the same mmio register may be written with a different value to do so. Did you ever try different values like 15 instead of 7 ? I guess you already did : "I tried modifying the code above a few ways to see if I could "unlock" the extra mem, but it didn't work", right ? |
|
| Back to top |
|
 |
hlide
Joined: 10 Sep 2006 Posts: 750
|
Posted: Mon Jan 19, 2009 2:40 am Post subject: |
|
|
| what about setting bit0-1 of 0xbc100040 to 2 ? (0 = 16 MB, 1 = 32 MB, 2 = 64 MB, 3 = 128 MB) ? dunno if it works and can have an effect on bus exception. |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Mon Jan 19, 2009 8:26 am Post subject: |
|
|
| hlide wrote: | | or there is a new mmio register to unlock access on the upper 32 MB we don't know about. Or the same mmio register may be written with a different value to do so. Did you ever try different values like 15 instead of 7 ? I guess you already did : "I tried modifying the code above a few ways to see if I could "unlock" the extra mem, but it didn't work", right ? |
Yes, exactly. 15 instead of 7 didn't work. I even tried writing -1 out to 60 instead of 30 as well. I'll check if changing 40 has any affect. Thanks for the tip.
EDIT: Good call. Changing the start of the stub to this worked.
| Code: | me_stub:
li k0, 0xbc100000
li t0, 7
sw t0, 80(k0)
li t0, 2
sw t0, 64(k0)
|
Is there anything else in that reg I should worry about? You mentioned setting particular bits, but I'm just overwriting the whole thing. It DOES work though. You can now write to the second 32 MB with the ME with that change (the last two lines in the code above). |
|
| Back to top |
|
 |
hlide
Joined: 10 Sep 2006 Posts: 750
|
Posted: Tue Jan 20, 2009 7:03 am Post subject: |
|
|
| J.F. wrote: |
| Code: | me_stub:
li k0, 0xbc100000
li t0, 7
sw t0, 80(k0)
li t0, 2
sw t0, 64(k0)
|
Is there anything else in that reg I should worry about? You mentioned setting particular bits, but I'm just overwriting the whole thing. It DOES work though. You can now write to the second 32 MB with the ME with that change (the last two lines in the code above). |
I don't think you should worry about anything else in that register : its purpose is probably only for setting memory size, and i was speaking about those both bits according to what I read in Groepaz's pspdoc. |
|
| Back to top |
|
 |
emufan
Joined: 16 Feb 2009 Posts: 2
|
Posted: Mon Feb 16, 2009 6:29 pm Post subject: |
|
|
Why MediaEnginePRX-v1.0a can not run correct on my psp2000(3.71m33-4)?The result is:
| Quote: |
mediaengine.prx loaded/started
Initialized MediaEngine Instance
Now testing MediaEngine functions
Testing BeginME...passed!
1 0 0
1 0 0
:
:
1 0 0
1 0 0
Result is 00000000
Testing CallME...failed! Error calling CallME.
Testing SignalME...failed! Error calling BeginME.
|
|
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Tue Feb 17, 2009 2:55 pm Post subject: |
|
|
| emufan wrote: | Why MediaEnginePRX-v1.0a can not run correct on my psp2000(3.71m33-4)?The result is:
| Quote: |
mediaengine.prx loaded/started
Initialized MediaEngine Instance
Now testing MediaEngine functions
Testing BeginME...passed!
1 0 0
1 0 0
:
:
1 0 0
1 0 0
Result is 00000000
Testing CallME...failed! Error calling CallME.
Testing SignalME...failed! Error calling BeginME.
|
|
Remember that 3.71 had different NIDs for the ME stuff, and no NID resolver. If you look at my MediaEngine PRX, you'll see have have special support for detecting 3.71 and using the 3.71 NIDs. |
|
| Back to top |
|
 |
emufan
Joined: 16 Feb 2009 Posts: 2
|
Posted: Wed Feb 18, 2009 11:10 am Post subject: |
|
|
| J.F. wrote: |
Remember that 3.71 had different NIDs for the ME stuff, and no NID resolver. If you look at my MediaEngine PRX, you'll see have have special support for detecting 3.71 and using the 3.71 NIDs. |
Thanks for your reply! So that's why DisplayTest-v1 can run correct on psp2000(3.71m33).
:) |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Wed Feb 18, 2009 5:15 pm Post subject: |
|
|
| Yep! I had to do some RE to find those NIDs... it was "fun". :D |
|
| Back to top |
|
 |
Kreationz
Joined: 18 May 2008 Posts: 53
|
Posted: Thu Jun 25, 2009 6:32 pm Post subject: Current Version |
|
|
A few quick questions:
1. Is the current version of your code still "MediaEnginePRX-v1.0a"?
2. This is what we are using in DX64 correct?
3. Is there some short example code for using the MediaEngine? (I'm looking for something other than DX64 as I'm currently tearing it apart to be rebuilt and want to run some tests without interference from other parts of the code.)
(And sorry I resurrected anther old thread J.F.) |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Fri Jun 26, 2009 12:00 am Post subject: Re: Current Version |
|
|
| Kreationz wrote: | A few quick questions:
1. Is the current version of your code still "MediaEnginePRX-v1.0a"?
2. This is what we are using in DX64 correct?
3. Is there some short example code for using the MediaEngine? (I'm looking for something other than DX64 as I'm currently tearing it apart to be rebuilt and want to run some tests without interference from other parts of the code.)
(And sorry I resurrected anther old thread J.F.) |
1-2 ) The MediaEngine code in DX64 is the latest. You can tell because it has some fixes to the cache code compared to the original.
3 ) I think I posted this before, but never hurts to post again... this was my original test app for the media lib.
main.c
| Code: | #include <pspsdk.h>
#include <pspkernel.h>
#include <pspctrl.h>
#include <pspiofilemgr.h>
#include <pspdebug.h>
#include <psppower.h>
#include <pspdisplay.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "me.h"
#define printf pspDebugScreenPrintf
#define VERS 1
#define REVS 1
PSP_MODULE_INFO("DisplayTest", 0, VERS, REVS);
PSP_MAIN_THREAD_ATTR(PSP_THREAD_ATTR_USER);
PSP_HEAP_SIZE_KB(-256);
__attribute__((aligned(64))) unsigned int frame[512*272];
unsigned int *frameBuf;
volatile struct me_struct *mei;
__attribute__((aligned(64))) struct me_struct meinst;
/*
* ME functions
*
*/
int ColorCycle(volatile struct me_struct *mei)
{
int x, y;
int c = 0;
unsigned int *buffer;
buffer = (unsigned int *)((int)frameBuf | 0x40000000);
while (!(mei->signals & 0x00000001))
{
if (mei->signals & 0x00000002)
for(y=0;y<272;y++)
for(x=0;x<480;x++)
buffer[y*512+x]=(x&255)+((y&255)<<8)+((c&255)<<16);
c++;
}
return 0;
}
/*
* SC functions
*
*/
void *malloc_64(int size)
{
int mod_64 = size & 0x3f;
if (mod_64 != 0) size += 64 - mod_64;
return((void *)memalign(64, size));
}
int main(void)
{
//unsigned int b;
int mode, width, height, bufferwidth, pixelformat, x, y;
void *topaddr;
int hasME = 1;
int err;
pspDebugScreenInit();
pspDebugScreenSetBackColor(0x00000000);
pspDebugScreenSetTextColor(0x00ffffff);
pspDebugScreenClear();
sceCtrlSetSamplingCycle(0);
sceCtrlSetSamplingMode(PSP_CTRL_MODE_DIGITAL);
SceUID mod = pspSdkLoadStartModule("mediaengine.prx", PSP_MEMORY_PARTITION_KERNEL);
if (mod < 0)
{
printf(" Error 0x%08X loading/starting mediaengine.prx.\n", mod);
hasME = 0;
}
printf("\n Display Test\n\n");
// mei = malloc_64(sizeof(struct me_struct));
// mei = (volatile struct me_struct *)(((int) mei) | 0x40000000);
mei = (volatile struct me_struct *)((u32)&meinst | 0x40000000);
sceKernelDcacheWritebackInvalidateAll();
if(hasME)
if (InitME(mei, sceKernelDevkitVersion()) != 0)
{
printf(" Couldn't initialize MediaEngine Instance\n");
hasME = 0;
}
printf(" Media Engine Instance initialized\n");
sceKernelDelayThread(2*1000*1000);
// FILE *fh = fopen("dump.bin", "w");
// fwrite(0x49000000, 1, 0x10000, fh);
// fclose(fh);
KillME(mei, sceKernelDevkitVersion());
printf(" Media Engine Instance destroyed\n");
sceKernelDelayThread(2*1000*1000);
InitME(mei, sceKernelDevkitVersion());
printf(" Media Engine Instance initialized\n");
sceKernelDelayThread(2*1000*1000);
sceDisplayGetMode(&mode, &width, &height);
sceDisplayGetFrameBuf(&topaddr, &bufferwidth, &pixelformat, 0);
printf(" mode = %d, width = %d, height = %d\n", mode, width, height);
printf(" fbuf = 0x%08X, bufferwidth = %d, pixelformat = %d\n", (int)topaddr, bufferwidth, pixelformat);
sceKernelDelayThread(5*1000*1000);
// frameBuf = (unsigned int *)0x09000000; // phat
// frameBuf = (unsigned int *)0x0b000000; // slim
frameBuf = (unsigned int *)((u32)&frame | 0x40000000);
for(y=0;y<272;y++)
{
for(x=0;x<480;x++)
{
frameBuf[y*512+x]=(x&255)+((y&255)*256);
}
}
sceKernelDcacheWritebackAll();
sceDisplaySetMode(0,480,272);
sceDisplaySetFrameBuf(frameBuf, 512, PSP_DISPLAY_PIXEL_FORMAT_8888, PSP_DISPLAY_SETBUF_NEXTFRAME);
sceKernelDelayThread(2*1000*1000);
pspDebugScreenSetBase((u32 *)(0x40000000 | (int)frameBuf));
pspDebugScreenSetXY(0, 0);
printf(" Display Test");
sceKernelDelayThread(2*1000*1000);
if (hasME)
{
err = BeginME(mei, (int)ColorCycle, (int)mei, 0, 0, 0, 0);
if (err < 0)
printf(" failed! Error calling BeginME.\n");
}
if (hasME)
SignalME(mei, 0x00000002, 0x00000002); // start 480x272 ColorCycle
sceKernelDelayThread(3*1000*1000);
if (hasME)
SignalME(mei, 0x00000002, 0x00000000); // stop ColorCycle
sceKernelDelayThread(3*1000*1000);
if (hasME)
SignalME(mei, 0x00000002, 0x00000002); // start 480x272 ColorCycle
sceKernelDelayThread(3*1000*1000);
if (hasME)
SignalME(mei, 0x00000002, 0x00000000); // stop ColorCycle
if (hasME)
{
SignalME(mei, 0x00000001, 0x00000001); // exit ColorCycle
err = WaitME(mei);
}
sceKernelDelayThread(3*1000*1000);
sceKernelExitGame();
return 0; /* never reaches here - just to suppress warning */
}
|
makefile
| Code: | TARGET = DisplayTest
OBJS = main.o me.o MediaEngine.o
INCDIR =
CFLAGS = -O2 -G0 -Wall
CXXFLAGS = $(CFLAGS) -fno-exceptions -fno-rtti
ASFLAGS = $(CFLAGS)
PSP_FW_VERSION=500
BUILD_PRX = 1
PSP_LARGE_MEMORY = 1
LIBDIR =
LIBS = -lpspdisplay -lpsppower
LDFLAGS =
EXTRA_TARGETS = EBOOT.PBP
PSP_EBOOT_TITLE = Display Test
#PSP_EBOOT_ICON="icon0.png"
#PSP_EBOOT_PIC1="pic1.png"
#PSP_EBOOT_SND0="snd0.at3"
PSPSDK=$(shell psp-config --pspsdk-path)
include $(PSPSDK)/lib/build.mak
|
|
|
| Back to top |
|
 |
Kreationz
Joined: 18 May 2008 Posts: 53
|
Posted: Fri Jun 26, 2009 5:47 am Post subject: Just what I needed. |
|
|
| Thx, that's exactly what I needed. Also if you did post it before, thx for the repost. I was lazy and didn't read all 5 pages of this topic. |
|
| Back to top |
|
 |
Gaby_64

Joined: 19 Dec 2008 Posts: 33
|
Posted: Fri Jun 26, 2009 11:40 am Post subject: ME interfearing with Mp3Resources |
|
|
Well since the thread has been revived I might as well ask my question here.
Has anyone ever had problems using mp3lib after using ME to do another task. In AirCrack-PSP for the wpa cracker I use ME to give it a little boost, so for every passphrase tested I do CallME with the crack function then KillME once its done (this is done in a seperate thread from the main thread and is deleted after KillME). After you run the wpa cracker and try using the scanner it just freezes at sceMp3InitResource(); (when scaner finds a new AP and attemps to beep, this is also in a seperate thread so the psp isnt really frozen but stuck in that function)
I will post some code:
Where variables are defined (at begining of app)
| Code: |
//Do this once. because i think it causes memory leaks.
mei = malloc_64(sizeof(struct me_struct));
mei = (volatile struct me_struct *)(((int) mei) | 0x40000000);
me_param = malloc_64(sizeof(struct me_param_struct));
//me_param = (volatile struct me_param_struct *)(((int) me_param) | 0x40000000);
sceKernelDcacheWritebackInvalidateAll();
|
Where ME is initialized in the main thread
| Code: |
else if (!strcasecmp(files[y + scrllpos].d_name+(strlen(files[y + scrllpos].d_name)-5), ".dict")) {
PrinToBox(LINESPACING, AUTOSCROLL, COPYPRINT, "Opening dict file %s\n", files[y + scrllpos].d_name);
fp = fopen(files[y + scrllpos].d_name, "rb");
if (fp == NULL) {
PrinToBox(LINESPACING, AUTOSCROLL, PRINT, "Error opening dictfile %s\n", files[y + scrllpos].d_name);
goto failed;
}
PrinToBox(LINESPACING, AUTOSCROLL, COPYPRINT, "Starting dictionary attack. Please be patient.\n");
sceKernelDelayThread(1500000);
gettimeofday(&start, 0);
if (InitME(mei) != 0)
{
PrinToBox(LINESPACING, AUTOSCROLL, PRINT, "Couldn't initialize MediaEngine Instance\n");
goto failed;
}
SceUID me_attack = sceKernelCreateThread("me_dict_attack_thread", me_dict_attack_thread, 0x30, 512 * 1024, PSP_THREAD_ATTR_USER, NULL);
if (me_attack < 0) {
PrinToBox(LINESPACING, AUTOSCROLL, PRINT, "Could not create me_dict_attack_thread!\n");
goto failed;
}
sceKernelStartThread(me_attack, 0, NULL);
}
while ((!keyfound) && (!stop) && (me_done+done != 1)) {
sceKernelDelayThread(100000);
sceCtrlReadBufferPositive(&pad, 1);
if((pad.Buttons & PSP_CTRL_CIRCLE) || (stop)) {
stop = 1; //Needs to be invalidated for the ME to see it
sceKernelDcacheWritebackInvalidateAll();
sceKernelDelayThread(300000);
}
}
|
ME function and thread
| Code: |
int me_attack(){
calc_pmk((char*)me_param->me_word, (char*)me_param->me_essid, (unsigned char*)me_param->me_pmk);
dcache_wbinv_all();
return 0;
}
int me_dict_attack_thread(SceSize args, void *argp){
u8 ptk[80];
u8 keymic[16];
char tpassphrase[MAXPASSLEN+1];
int fret;
sprintf((char*)me_param->me_essid, ssid);
while (!keyfound && !stop) {
while(eventwarn) {
cracking = 0;
sceKernelDelayThread(100000);
}
cracking = 1;
totalwords++;
menu.statusbox[0] = R_NULL;
PrinToBox(LINESPACING, AUTOSCROLL, COPY, "Reading word #%d, %d tested, %d invalid\n", totalwords+1, wordstested, badwords);
fret = nextword(tpassphrase, fp);
if (fret < 8 || fret > 63) {
if (fret == -1) {
PrinToBox(LINESPACING, AUTOSCROLL, COPYPRINT, "EOF!\n");
break;
}
else if (fret == -2) {
badwords++;
PrinToBox(LINESPACING, AUTOSCROLL, COPYPRINT, "Error reading file!\n");
continue;
}
else {
badwords++;
PrinToBox(LINESPACING, AUTOSCROLL, COPY, "Invalid passphrase length: (%d) %s\n", strlen(tpassphrase), tpassphrase);
continue;
}
}
wordstested++;
PrinToBox(LINESPACING, AUTOSCROLL, COPY, "Calculating PMK for \"%s\"\n", tpassphrase);
sprintf((char*)me_param->me_word, tpassphrase);
sceKernelDcacheWritebackInvalidateRange((struct me_param_struct*)me_param, sizeof(struct me_param_struct));
if (CallME(mei, (int)me_attack, 0) < 0) {
PrinToBox(LINESPACING, AUTOSCROLL, PRINT, "Error calling CallME.\n");
me_done = 1;
}
PrinToBox(LINESPACING, AUTOSCROLL, COPY, "Calculating PTK with collected data and PMK.\n");
wpa_pmk_to_ptk((unsigned char*)me_param->me_pmk, cdata.aa, cdata.spa, cdata.anonce, cdata.snonce, ptk, sizeof(ptk));
PrinToBox(LINESPACING, AUTOSCROLL, COPYPRINT, "Calculating hmac-MD5 Key MIC for this frame.\n");
hmac_hash(cdata.ver, ptk, 16, cdata.eapolframe, sizeof(cdata.eapolframe), keymic);
if (memcmp(&cdata.keymic, &keymic, sizeof(keymic)) == 0) {
strcpy(passphrase, tpassphrase);
keyfound = 1;
break;
}
cracking = 0;
}
KillME(mei);
sceKernelDcacheWritebackAll();
//sceKernelIcacheClearAll();
me_done = 1;
sceKernelExitDeleteThread(0);
return 0;
}
|
EDIT:
Oh and JF could you post a link toan archive containing the source you posted above and mediaengine.prx source, seems I dont have the latest. _________________ <a><img></a> |
|
| Back to top |
|
 |
J.F.
Joined: 22 Feb 2004 Posts: 2906
|
Posted: Fri Jun 26, 2009 1:38 pm Post subject: |
|
|
| Just pull the MediaEnginePRX from the DX64 source. Also, it's unlikely that the ME code we use right now will work properly with the PSP use of the ME. It bangs on the ME pretty directly. There's a number of things you can't do if you use the ME with the code we have now - namely, change the CPU rate or sleep. Doing either after initializing the ME with MediaEnginePRX will hang the PSP. I've not yet found any way to turn off the ME so that you can sleep or change the cpu rate, so I doubt any of the PSP ME stuff will work either. More research into the PSP ME libs needs to be done. |
|
| Back to top |
|
 |
Kreationz
Joined: 18 May 2008 Posts: 53
|
Posted: Fri Jun 26, 2009 1:45 pm Post subject: |
|
|
Here is the ME code we use for DX64 along with the Demo Code above in a nice neat VSExpress compatible package for those using MinPSPw. http://www.sendspace.com/file/wmmo8o
BTW: The Demo and the MediaEnginePRX are just set up as different Projects in the Same solution with the only alterations being the copy destination and the includes pointed correctly for how it's set up and one #include I added to make it compile on my system. |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|