forums.ps2dev.org Forum Index forums.ps2dev.org
Homebrew PS2, PSP & PS3 Development Discussions
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Media Engine?
Goto page Previous  1, 2, 3, 4, 5, 6  Next
 
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development
View previous topic :: View next topic  
Author Message
StrmnNrmn



Joined: 14 Feb 2007
Posts: 46
Location: London, UK

PostPosted: Fri Dec 21, 2007 7:43 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website MSN Messenger
Raphael



Joined: 17 Jan 2006
Posts: 646
Location: Germany

PostPosted: Sat Dec 22, 2007 2:07 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
crazyc



Joined: 17 Jun 2005
Posts: 410

PostPosted: Sat Dec 22, 2007 7:15 am    Post subject: Reply with quote

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
View user's profile Send private message
Raphael



Joined: 17 Jan 2006
Posts: 646
Location: Germany

PostPosted: Sat Dec 22, 2007 8:11 am    Post subject: Reply with quote

Well, makes sense then to do it that way :) thanks
_________________
<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
View user's profile Send private message Visit poster's website
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Sat Dec 22, 2007 8:13 am    Post subject: Reply with quote

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
View user's profile Send private message
crazyc



Joined: 17 Jun 2005
Posts: 410

PostPosted: Sat Dec 22, 2007 9:03 am    Post subject: Reply with quote

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
View user's profile Send private message
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Sat Dec 22, 2007 10:56 am    Post subject: Reply with quote

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
View user's profile Send private message
Raphael



Joined: 17 Jan 2006
Posts: 646
Location: Germany

PostPosted: Sat Dec 22, 2007 11:09 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Sat Dec 22, 2007 1:10 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Sun Sep 21, 2008 3:02 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Sun Sep 21, 2008 9:24 pm    Post subject: Reply with quote

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
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Mon Sep 22, 2008 5:43 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
tailerb



Joined: 01 Jun 2008
Posts: 3
Location: Russia

PostPosted: Sat Jan 10, 2009 2:45 am    Post subject: Reply with quote

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
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Sat Jan 10, 2009 8:49 am    Post subject: Reply with quote

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:

Code:
li      sp, 0x80200000


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
View user's profile Send private message AIM Address
tailerb



Joined: 01 Jun 2008
Posts: 3
Location: Russia

PostPosted: Sat Jan 10, 2009 5:16 pm    Post subject: Reply with quote

Thanks a lot! And one more question: what happens with ME when power saving mode activated/deactivated ?
Back to top
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Sun Jan 18, 2009 4:06 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Sun Jan 18, 2009 11:31 pm    Post subject: Reply with quote

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
View user's profile Send private message
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Mon Jan 19, 2009 2:40 am    Post subject: Reply with quote

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
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Mon Jan 19, 2009 8:26 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
hlide



Joined: 10 Sep 2006
Posts: 750

PostPosted: Tue Jan 20, 2009 7:03 am    Post subject: Reply with quote

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
View user's profile Send private message
emufan



Joined: 16 Feb 2009
Posts: 2

PostPosted: Mon Feb 16, 2009 6:29 pm    Post subject: Reply with quote

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
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Tue Feb 17, 2009 2:55 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
emufan



Joined: 16 Feb 2009
Posts: 2

PostPosted: Wed Feb 18, 2009 11:10 am    Post subject: Reply with quote

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
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Wed Feb 18, 2009 5:15 pm    Post subject: Reply with quote

Yep! I had to do some RE to find those NIDs... it was "fun". :D
Back to top
View user's profile Send private message AIM Address
Kreationz



Joined: 18 May 2008
Posts: 53

PostPosted: Thu Jun 25, 2009 6:32 pm    Post subject: Current Version Reply with quote

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
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Fri Jun 26, 2009 12:00 am    Post subject: Re: Current Version Reply with quote

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
View user's profile Send private message AIM Address
Kreationz



Joined: 18 May 2008
Posts: 53

PostPosted: Fri Jun 26, 2009 5:47 am    Post subject: Just what I needed. Reply with quote

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
View user's profile Send private message
Gaby_64



Joined: 19 Dec 2008
Posts: 33

PostPosted: Fri Jun 26, 2009 11:40 am    Post subject: ME interfearing with Mp3Resources Reply with quote

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
View user's profile Send private message
J.F.



Joined: 22 Feb 2004
Posts: 2906

PostPosted: Fri Jun 26, 2009 1:38 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Kreationz



Joined: 18 May 2008
Posts: 53

PostPosted: Fri Jun 26, 2009 1:45 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.ps2dev.org Forum Index -> PSP Development All times are GMT + 10 Hours
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 5 of 6

 
Jump to:  
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