gpio question

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
phobox
Posts: 127
Joined: Mon Mar 24, 2008 6:22 pm

gpio question

Post by phobox »

looking at lowio.prx I discovered how sceGpioPortRead, sceGpioPortSet and sceGpioPortClear are defined:

Code: Select all

int sceGpioPortRead ()
{
  return = *((int *) 0xBE240004);
}

void sceGpioPortSet (int arg1)
{
  *((int *) 0xBE240008) = arg1;
  __asm__ ("sync;");
  return;
}

void sceGpioPortClear (int arg1)
{
  *((int *) 0xBE24000C) = arg1;
  __asm__ ("sync;");
  return;
}
knowing that sceGpioSet(0x80) will turn on the WLAN led and sceGpioSet(0x40) will turn on the MS one
and that sceGpioClear(0x80) will turn wlan led off and with arg 0x40 the ms led..

so.. portSet will set the value passed as an argument at address 0xBE240008

but if i do something like
sceGpioSet(0x80)
sceGpioSet(0x40)

both leds are on, BUT the value at 0xBE240008 is overwritten

then another thing that i cannot understand is why in the three functions the addresses are different...

and what about the "sync"?

thanks
Ciao! from Italy
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

They use separate addresses because it's hardware. Writing to one address will cause the set bits to be set in the hardware. They will stay set until you write to the other address, where set bits will clear that bit in the hardware. It's pretty common in various things. You could combine the LED and MS by writing 0xC0, which is just both bits 0x80 and 0x40. Anywho, it's pretty common to put a sync after writing to hardware - it makes sure the hardware bus transfer is done before continuing.
phobox
Posts: 127
Joined: Mon Mar 24, 2008 6:22 pm

Post by phobox »

ok, i understand thank you!.
but from now on, things can be discovered only by testing, is no more possible to "reverse" i mean, to discover the 0x80 an 0x40 values i can only look (for example) at led.prx, but not "inside" gpio..
am i right?

and since i'm writing, where can i get more info on gpio?, what is it in psp hardware? is it a chip? is it like syscon?

thanks
Ciao! from Italy
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

phobox wrote:ok, i understand thank you!.
but from now on, things can be discovered only by testing, is no more possible to "reverse" i mean, to discover the 0x80 an 0x40 values i can only look (for example) at led.prx, but not "inside" gpio..
am i right?

and since i'm writing, where can i get more info on gpio?, what is it in psp hardware? is it a chip? is it like syscon?

thanks
Once you hit the hardware, you either need to know more functions like the one to set the power or ms leds, or you just have to poke the hardware with different values and see what happens. The latter can sometimes get you in trouble if the values do something bad, so it's better to RE functions if you have them.

GPIO means General Purpose Input/Output. It's a register in the hardware that simply buffers lines that do things, like control the LEDs or connect to switches or similar hardware related things. I seem to remember old threads with some info on the GPIO - you might try searching the old threads.
Dariusc123456
Posts: 388
Joined: Tue Aug 12, 2008 12:46 am

Re: gpio question

Post by Dariusc123456 »

phobox wrote:looking at lowio.prx I discovered how sceGpioPortRead, sceGpioPortSet and sceGpioPortClear are defined:

Code: Select all

int sceGpioPortRead ()
{
  return = *((int *) 0xBE240004);
}

void sceGpioPortSet (int arg1)
{
  *((int *) 0xBE240008) = arg1;
  __asm__ ("sync;");
  return;
}

void sceGpioPortClear (int arg1)
{
  *((int *) 0xBE24000C) = arg1;
  __asm__ ("sync;");
  return;
}
knowing that sceGpioSet(0x80) will turn on the WLAN led and sceGpioSet(0x40) will turn on the MS one
and that sceGpioClear(0x80) will turn wlan led off and with arg 0x40 the ms led..

so.. portSet will set the value passed as an argument at address 0xBE240008

but if i do something like
sceGpioSet(0x80)
sceGpioSet(0x40)

both leds are on, BUT the value at 0xBE240008 is overwritten

then another thing that i cannot understand is why in the three functions the addresses are different...

and what about the "sync"?

thanks
the "int argX" stands for the number of arguments for that function. Its runs differently than what you might think.
PSHN - Playstation Hacking Network
PSX/PS1 - HACK - Game Shark
PS2 - HACK - Swap
PSP - HACK - Pandora
PS3 - ?
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Why are you posting a non-answer to a question I already answered? Try reading the thread to see if there are still questions before posting, especially when your post doesn't give any extra info.
phobox
Posts: 127
Joined: Mon Mar 24, 2008 6:22 pm

Post by phobox »

thank you very much JF,
do you mean this?
http://forums.ps2dev.org/viewtopic.php?t=7338
Ciao! from Italy
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

That's the one I remember - notice that someone made defines for the bits/lines handling the LEDs and the IRDA, among other things.
phobox
Posts: 127
Joined: Mon Mar 24, 2008 6:22 pm

Post by phobox »

ok in this one are wiriiten strange things...
eg
sceGpioPortSet(0x00000003);
is
_sw(0xBE240008, _lw(0xBE240008) | 0x00000003);

and another one
sceGpioPortClear(0x00000003);
is
_sw(0xBE240008, _lw(0xBE240008) | 0x00000003);


now there are two things to consider: i did't understand that that code is right (but i don't think so) OR that info is incorrect or old.

-----------
by my self ( a bit of testing) i figured out that if I call
sceGpioPortSet(0x80)
to turn the wlan led on, the value returned with
sceGpioPortRead(); is the default value + 0x80.

the default value is 0x07000027.

if i do (for example)

sceGpioPortSet(0x80)
sceGpioPortSet(0x40)

sceGpioPortRead() will return 0x070000E7, that is 0x07000027 + 0x80 + 0x40

in other words, portSet will add the arg value to the gpio and portClear will subtract it....

EDIT: another thing, if I simply call sceGpioPortSet(led) the led will simply flash and then it turns off, to keep it on you need to keep calling that function.
don't know why this....
Ciao! from Italy
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

Yeah, there probably are some problems with some of that old hardware info... remember that most of that stuff is only slightly researched - there wasn't much need for that for the majority of homebrew.

The LED flashing is probably due to a system function setting the LEDs to what it thinks they are supposed to be periodically. You'd have to find where it stores its copy of what to set the GPIO to, or hook that function to make the LEDs not flash. Again, that's something that really hasn't been looked into much.
Post Reply