Sunplus SPMP3050A - General

[pichokues]

Yo need this driver:

http://www.4shared.com/account/file/...SP_driver.html

Once you extracted your firmware, you could post it on this page, (I make an
update and now i can´t play nes games , my plate board is sk613l instead sk613b, the firmware that is in the download section).

Thanks.

[kyur4 th ich]

i have recovered my mp4 player...

ill be uploading my firmware files soon...

my internet connection is very slow...

thanx to aapot for his time...

btw, can I put snes, gb and/or gba emulators on my mpx player?

[Erant]

I've recently been reverse-engineering parts of the JXD201 firmware. So far, I've managed to create a custom firmware that will accept binary format executables over the serial port, and run them.

A dump from my serial terminal:

S+
Ver:1.2
Boot From Nand
S+
Erant's CBL (Crappy BootLoader) BUILD: 5
Press C to continue regular boot.
Press L to load binary data.

Unfortunatly, I havn't been able to find the memory locations for the GPIO pins, nor for the display. I have been able to determine that the original firmware for this device is most likely an RTOS. It uses a function call very similar to: add_thread(void (*ft_pointer)(), char* stack, stack_sz, int priority, char* threadname); to add a shitload of background threads, like KeyDriver, FileSystem, BackGround, GAME_CTL, etc.

I'm willing to share my custom firmware, if anyone wants it. You need a serial link soldered to your PMP, and you need to know your way around C and GCC (I use devkitARM).

What I was wondering was wether there was anyone also involved in reverse engineering these devices, that maybe has some information to share?

[Sprite_tm]

Damn, in the time it took me to set up an account here someone else posted a nice nugget of reverse-engineering-info here And he's Dutch too :P

I myself have made some progress on reverse engineering the .bin-format game-files. They're basically 128 byte headers, with the arm machine code to be loaded at adress 0x24C00000 directly after it. The machine code can then use a standardized OS function table to let the OS do stuff like play midi, display gfx, etc.

I have just finished setting up a wiki and a mailing list for more spmp305x-reverse-engineering. They can be found at http://spmp305x.spritesserver.nl/ . While my main use was to dump info for game-files inthere, I can't see why delicious info like io-mappings can't go in there too, so you're welcome to edit it in.

And to show what I've done up till now: You can download a small demo here: http://spmp305x.spritesserver.nl/demo/demo-0.1.bin
It doesn't do that much (play a midi until a key is pressed) but it's enough to show there's potential, I hope.

Erant: I've been wondering over the display subsystem too. I haven't actually seen any framebuffer-like bit of memory containing the current image in main RAM. Perhaps there's a second bit of memory somewhere inside the sunplus chip?

[Erant]

Nice to see you getting in on this as well Sprite I've been looking at the MMU setup, and you're right. There are some important memory locations but none of them seem like framebuffer material. The only memory region that's marked as non-cacheable is 0x3C... which is later marked as a mirror for the 0x24... memory range. Which is just RAM.

On a different note, I managed to find the offset the 3050ABin0.bin is loaded at. 0x241606E0 (yeah, way to go for logical offsets). If you want to reverse engineer this, I suggest you just stick on the end of the main firmware in IDA, it uses a lot of the firmware's functionality.

Anyway, I've got some information as far as the memory map goes, and stuff like that. I'd love to post it on the wiki, but it doesn't seem to be online yet?

[Sprite_tm]

What I did is create a game to read out the complete 24000000 range out of the serial port, and stick IDA to that. You can then even see what value variables have at the moment the game loads Contact me if you want the code for it, I should have it still lying around.

Mmmm, 0x3c = non-cachable 0x24? I should keep that in mind.

The wiki should be online, but it could take a day or two for the dns-entry to propagate. You should be able to access it now or tomorrow.

[Erant]

Originally Posted by Sprite_tm";p=&quot

What I did is create a game to read out the complete 24000000 range out of the serial port, and stick IDA to that. You can then even see what value variables have at the moment the game loads Contact me if you want the code for it, I should have it still lying around.

Mmmm, 0x3c = non-cachable 0x24? I should keep that in mind.

The wiki should be online, but it could take a day or two for the dns-entry to propagate. You should be able to access it now or tomorrow.

I started reversing in a different place then you did (or rather, from the other end). I patched the firmware, and added a small bootloader (check the wiki, I'll upload it soon) that accepts binary files through XModem. I also added some memory stuff. You should check out the 0x2D... memory range, or at least the first few kb of it. It contains some executable data that I can't find back from the main firmware (probably embedded in the CPU somewhere),and is marked as the iTCM region. (Tightly Coupled Memory, read the ARM926EJ-S documentation). 0x2E is the dTCM region that goes with it.

Edit:

I've been trying to trace back the get_keys OS call to the IO register, without much luck.

I've gotten it down to:
*((int*)0x24287138) = *((int*) *((int*)0x24286130) + 4)

With 0x24287138 being the address the keys are stored for the get_keys call. Unfortunatly, I don't have a running dump, and tracing back the 0x24268130 address is almost impossible. You wouldn't happen to be able to trace this back to a 0x100... address, would you?

[Sprite_tm]

Seems the addresses 0x1000110X have something to do with the keys. As far as I can see in my code, it's an interface which should be modified bytewise (ldrb/strb).

About the iTCM/dTCM: I've seen it being used for a bootloader, perhaps Sunplus has done the same here. If I have time and feel like it, I'll read it out, but I don't think the data there is of much consequence.

[Erant]

Originally Posted by Sprite_tm";p=&quot

Seems the addresses 0x1000110X have something to do with the keys. As far as I can see in my code, it's an interface which should be modified bytewise (ldrb/strb).

About the iTCM/dTCM: I've seen it being used for a bootloader, perhaps Sunplus has done the same here. If I have time and feel like it, I'll read it out, but I don't think the data there is of much consequence.

I came to the same conclusion quite a while ago about those keys, but havn't been able to get anything out of it. Might've made a mistake somewhere though.

I dumped the iTCM a while ago,and didn't find anything massively interesting, it doesn't actually seem to do much, but I thought I'd mention it.

I added you on MSN btw.

[zenitraM]

Wow.. the way to homebrew has just begun

Well, I created before a Wiki for Sunplus studies (and open to other chipsets), it's located at http://mp4.itram.es/wiki/spmp305x/start

If you want to use it, feel free to do it.