Here is source of main() from attached rkp.
As you can see it uses loop without returning from main().
Could you tell me codes for each your key?

int main()
{
int iOldPwr = read_mem(CLOCK_PWRCON);
int nKey;
int i;
unsigned int iAddr = 0;
unsigned int imask_tmp;
int iSec =0;
read_creg(%imask, imask_tmp);
write_creg(%imask, 0x0000);

initConsole();
printf(" Start...\n");
while ( 1 ) {
nKey = waitKey();
printf("Pressed %04x\n",nKey);
if ((nKey & KEY_VAL_PLAY) ) {
break;
}
}
setCursor(0,14);
setColor(COLOR_WHITE);
setColorBg(COLOR_BLACK);
printf("\n\n\n");
printf("FAP vers. 0.3\n");
printf("(C) 2010 by Y.Pokhilko (sig11@mail.ru)\n");
printf("Latest version always at:\n");
printf("http://ypokhilko.vn.ua/apps/\n");
printf("Press any key to continue\n");
waitKey();
waitKey();
write_creg(%imask, imask_tmp);
SetGameFreq(72);
write_mem(CLOCK_PWRCON,iOldPwr);
(*GameExit)();
}

I noticed that they are all the same for no matter what key I press (either 66 or 64 randomly). It reminds me trying to init my touchpad using firmware from SDK (rk26). My touchpad seems to be using completely different way of getting input values rather than simple reading GPIO pin states.

But your app seems to work even if main() function does not finish quickly. What's the trick? Everytime I (and knob also) lengthen the time of executing this function above 2 secs it crashes. Is this caused by this (*GetKeyVal)() function?

Also I noticed you added CPU management to your apps, that's something I planned to do for a long time (I noticed huge battery consumption while running some RKP app because of that).

btw. It somehow reads that I touch my touchpad, but its rather caused by reaction of back-light (of touchpad) driver which is mainly operated by KEY_PORT mem address (the higher value in there, the brighter lights of touchpad are).

It is very bad..
Probably needed to use another port?
I have disabled any interrupt

My application works above 6 hours from battery :)

What do you suggest? I tried to make driver for my touchpad but with no success, I don't have enough experience. I even asked WANNABE to disassemble my original firmware to elicit this driver, but ASM code is too confusing to me so I gave up.

#define DMA_DISABLE_INTERRUPT { read_creg(%imask, imask_tmp); bitclear_creg(%imask, 15); }
#define DMA_ENABLE_INTERRUPT { write_creg(%imask, imask_tmp);}

is this enough? I used it to disable interrupt while managing SDRAM transfer. But I always enable it once transfer is done. If I disable it completely, it wont crash then? How about this screen refresh, it refreshes screen after main() is ended. Are you uploading graphics directly to LCD_DATA memory?

No wonder why, if you can manipulate sys freq in game Another improvement would be turning off the screen. I was messing around with the screen, and I managed to manipulate backlight driver of the screen that it can gradually get darker or brighter but I don't know if it can be introduced to RKP platform because of different LCD drivers (tested only on mine).

I have no ideas for this case, but I will think.

I have disabled timer interrupt too.(all interrupts at all)
I am using LCD_DATA port to generate bitmap and I do not use SDRAM yet.
I do not know how to do it yet

I remember that AleMaxx tried to do something with my driver, and he mentioned some interruptions are used, maybe that's why backlight of my touchpad is always turned on in your app? Maybe not all interruptions should be disabled?

Gosh, I wish I had player with normal keyboard. This touchpad is driving me crazy, not only because of this whole mess, but it happens that touchpad locks up sometimes and I need reset - developers of my player did lazy job in creating their driver.

Also if I was able to do my own driver I would be able to use touchpad more efficiently (for example finger sliding detection is supported by the chip but it's not supported by built-in driver). So some sort of mouse-like input would be possible - just dreaming :-)

I have been thinking of getting a 2nd, spare, rk26xx player, but the only one I have found for sale that supports .rkp is this one:-
DealExtreme: $41.90 Stylish 2.4-inch 1GB MP4 Player with SD Card Slot
http://www1.dealextreme.com/producti...23_1_small.jpg



Not sure if this one supports .rkp:-
206K Full Color 1GB MP4 Player - Easy Navigation Keys China Wholesale - ***************
Buy China wholesale - 206K Full Color 1GB MP4 Player - Easy Navigation Keys
http://www.davismicro.com/bookpic/20085222045067430.jpg
I really like this player best, with a removable nokia phone battery too, full size SD card,
buttons look nice (I count a total of 10!), would be better in 2GB though.


update. found a 2Gig one. ;)
http://www.onvon.com/206k-full-color...5e3558cb38f782

Great Idea! I also was searching from time to time for a new rk26 player, its more simple than rk27 and thats the beauty. Besides, my rk26 player supports so much (flv, flac, ape, avi and rkp which is all I need). Another thing, I noticed that I have better sound in my rk26 player than in rk27 :confused: Though I wouldn't complain if I had rk27 player with RKP platform support (I meet one of these once on Ebay but it was a long time ago)

This player's firmware is similar to mine, and I don't have the killing "memory effect".
Also, the firmware is really good (IMHO) ;)
I think I can recommend it.

Wow, your player is awesome! :rolleyes:

Tried to place an order for this player here:-
206K Full Color MP4 Player and Easy Navigation Keys - Wholesale free shipping mp4 players - Wholesale electronics

It DOES support .rkp, but sadly the seller has just informed me they are no longer made. :(

will try to find one elsewhere.

If these rk26xx players are no longer made then we need to create a .rkp launcher and patch to the rk27xx series players to keep the .rkp format alive.

I believe that some manufacturers are still making the RK26xx players.
And these chips are still available for order (Fuzhou Rockchip Electronics Co., Ltd?)

About the BMP Opener: is it possible to open ANY file when running the application ?
(not the file with a name which was selected before the compilation, like bitmap.bmp)

I found a perfect player. Check this out:

PASEN ONION1 2.4''MP4 PLAYER AVI,FLV,PLAYFX AND MINI SD SLOT
Pasen Onion1 4GB - Mp4 Players

Also, it has similar firmware to mine - the very latest update of the rk26 firmware which includes support for PlayFX, FLAC, APE and FLV besides RKP. Also most propably it has a new MusicLIB id3tag based system included (very well known from RK27 players). It has normal button layout and speaker.

Also this one has MiniSD slot, not MicroSD which is awsome because the maximum capacity of SD inside RK26 is 4gb (MiniSD) and 2GB(MicroSD) - caused by the fact that 4gb microsd is made already as SDHC while 4gb MiniSD is still made as non-SDHC.

----------
ouchhh... I haven't read that it's out of stock :/
but its available in other shops
ex. http://shop.pasen.it/index.php?main_...82&language=en

I am sorry for delay in releasing it but I had very little time lately. I will try to release my work by the night (recurring through folders is done, but there are some bugs that cannot be released in current state). The answer is yes it is all possible, you can pick the file by run-time choice.

hi antotamara
What sort of player have you got?
can you post a photo?

I think that you're in the wrong topic.
Go to the Mods and Themes

Okay, so much rk26 stuff, I think Ill just throw in some rk27 topic. ;-)
Here is a dump of the rk27xx internal boot rom: http://alemaxx.al.funpic.de/rk27/rk27xxboot.rom.bz2 (actually its four times the same 8k).
This loads the first few pages of the nand, decrypts it and executes it. These pages normally contain the bootloader that in turn loads the BASE.RKW. Actually I think its quite funny that the ROM loader expects encrypted data. Its kinda soft encryption though. Btw, the firmware on SPMP8000 based players uses 3DES for their proprietary .bin game format (for the 1st k).

Explorer
 

Please, could you release the beta version?
We can test it and find out how to fix some bugs.

Hi, I just found these potential rk28xx datasheet download links:

Èðо΢ ¿ª·¢ÊÖ²á RK28xx+DATASHEET+V0.2.pdf - ÏÂÔØ - ¹²Ïí×ÊÁÏ
ÈðоÍƳöRK2808оƬ·½°¸(¸½´øоƬÊÖ²á) ¡û NewMsgÎÞÏßARM¿ª·¢Æ½Ì¨ ¡û NewMsgÎÞÏßͨÐÅ

They use a silly coin based credit system and you can only download after registration and when you have some coins. Maybe someone of you can tear it down from one of these servers.

I have absolutely no time recently. I know a lot of people will appreciate it (I even started to receiving emails in WhatEverTheHellItIs language asking for it) so I am releasing what I have done so far.

• FatFS implementation (currently Read Only, but if you just try a little, you will manage to enable writing - a matter of two functions that need to be handled)
• OpenDialog BETA (going through folders work, but I haven't finished it, so you can't pick a file acording to the current state)
• BMP decoder
• AntiAliased font support (tool for converting fonts is even more buggy so I am not releasing it, I am uploading just a few ready fonts, if you wish I can convert any font at any size or style, just give me details or attach *.ttf file and mail it to me; if I finish my font tool it will be able to manage all the rockchip fonts, inclusing rk26 FW fonts, rk27FW fonts and my own special AA format)

I put there some README files which you really should read before you start to do anything. Also, during my work I tried to comment every action inside the functions so it can be understandable for everyone. I think it can be very useful, especially that I spent so much time testing how fast those functions can be.
(check out SD_Ram functions for controlling current CANVAS of the screen, and also Bitmap converting MACROS for convertions between RBG888 and RGB565 and mixing two colours with alpha channel - they are fast as hell in opposite to the ones I found on the internet).

Also I recommend using PlatformEx.c file for DMA support. You may also find there a lot of interesting things

Attachment 550

Any problems you encounter, it will be much more efficient to e-mail me. I check email very often in my cellphone, therefore I will definitely answer it soon, as currently I have absolutely no time to sit in front of the computer. Enjoy.I hope you'll create some great stuff, and I hope I'll have more time also. ;)

KNOB:
I also think that RKP is dying. It's a shame that rockchip hadn't released SDK for so long. If the SDK was available from the beginning then maybe there would be more interest in supporting it even in RK27 players. If I am not wrong, someone already has started developing RKP Emulator for Windows. We could port it to RK27, I think it would handle it perfectly, including 100% proper speed (as most slowing down functions are the drawing ones, they would work nativley). If it was done, we could do some patching of our original FWs, perhaps replace ugly and stupid STOPER app with the game menu.

Where can I find the SDK?
 

Hello,

After reading nearly the whole thread, I still can not find a working link, where I can download the SDK. Can someone help me?

I have a ODDO S9K player with RK27 or RK28, I dont know exactly.

Thanks a lot,
dydimos

Links
 

Hi!
I'm newbe at this forum, but not at programming for ARM, arm asm and Ida:)
Some time ago I bought rk2705-based player (ritmix rf-8900). That player has 320x240 Mcu16 Lcd, touchscreen, radio and G-sensor.
I've read all topic and download SDK. I've read that people with touchscreen players can't run SDK'S firmware. But all you need is disassemble original firmware and find function HWTouchGetPixelPoint. I write my own function based on disasm and now touchpad works for me! Also I write display init function and keyboard handler (he-he, "keyboard" sounds very loud, it's only one poweroff key:) ) But interface isn't adapted for touchpad, so I append some code to RockChipEmu to emulate touchpad on PC. Now, if somebody wants, I can upload modified source and emulator at Saturday or Sunday, and if you has player with touchpad, you can try it and help to adapt interface.
I agree that .rkp is dying, so I port so-called "elfloader". This is function that load *.elf file from disk to ram and give control to it's main() function. At this time I trying to make swi-handler, sdk's firmware doesn't have one.

So, at this time I have working swi handler and can run following simple *.elf:
int main()
{
FS_FILE *f;
f = FS_fopen("C:\\data.txt", "wb");
FS_fwrite("Hello!", 6, 1, f);
FS_fclose(f);
return 0;
}
But now we need to create swi library, first 5 functions are reserved:
FS_fopen
FS_fclose
FS_fread
FS_fwrite
malloc_addr
...to be continued...
Any suggestions? Do we need "daemons", elfs that starts on player poweron? Where store data, on registry or we need our format, such as *.bcfg on Siemens? Questions, questions, questions...

Barracuda72 you are my god. I've been wondering about how to load and run external binary from file but its way above my asm abilities.

What do you mean by this "daemons"?

I think what we all need is something similar to RKP format, file access support, quick and universal access to the screen display and inputs.

Another question would be, if its possible to implement this ELF loader into already compiled firmware.

I'm looking forward to everything u will discover.

And I regret RKP is dying. My player with RKP support is almost dead (battery is weak, screen is scratched, and jack-socket is cracked) so it's pointless to create anything for it.

But my other player RK2705 is something I would like to develop for ;-)

I think it must be here:
flasher86,
I am very sad that mympx.org is down:( Do you know something about it?
I received last you reply in theme by mail, so I think I can reply.
No, I'm not god, just student:) Elfloader isn't my creature, it was created by unsurpassed hacker Rst7 for Siemens mobile phones (phones based on ARMv9 processor without arithmetic soprocessor), I'm just port it to our players:)
"Daemons" is a programs that runs on device startup and works in background. Termin "daemon" is from Unix, on Windows such programs called "services".
swi hook is a small program that calls function by it's swi number. For example, if you want call
FS_fopen()
on all players, all you need it to define it as
#pragma swi_number=0x0
__swi __arm FS_FILE *FS_fopen(const char *name, const char *mode);

and call it as usual. This syntax is specific for IAR Embedded Workbench for Arm. If you want to write elf's, you need this IDE (version 4.41a at least, freely available from internet).
Yes, it's possible to integrate elfloader into original firmware (originally elfloader is a patch for Siemens firmware), but I think that we need to test it and produce complete, working, full-featured thing. So I have many questions for now...

Well I knew that there is a way to port things created initially for any ARM based processor but as I said, ASM is very very hard for me to understand, though I am able to make a tool for patching such code in terms of changing variables, redirecting code to another piece of code and such - it's just I can't write code in pure ASM yet - easier to modify already existing code.

I don't know nothing about mympx.org getting down, but what is sure that most developers left this place, including me. It's hard to keep yourself motivated if there is so many obstacles in your way. I put so much effort to work on RKP platform while it's almost gone from all the players on the market. It's like all this time went in vain.

If there is a chance to include elf loader in any firmware then I will be glad to start creating stuff for this player. Perhaps we will be able to create an RKP emulator (someone has already started to do this for PC).

Currently development for RK27x is blocked by the fact that we cannot run external executables from files - we need the whole firmware to be applied which often ends in total corruption of the Rock OS and a need to painful restoration process.

I assume that in order to patch original firmware we need to locate basic functions inside BASE.RKW such as draw pixel, bitmap, button events, upload pcm stream and play it and so on. I think it's quite easy as we have SDK and can easily locate them by comparison of the code.

ps. is that mean that we no longer need to use ADS compiler to run some code?

At this time I trying to write *.elf that creates window and response on key events. No success:( But I will try to write tool for applying Elfloader to any base.rkw (I'll get as base RKPatch :) ). For now, Elfloader consists of following parts:
swi hook. Platform-independent.

int elfload(char *path, void *a, void *b, void *c); Loads *.elf file to ram and give control to it's main(). Platform-independent.

void LoadDaemons(); Finds all *.elf files from C:/ZBIN/Daemons and loads them one by one by elfload(). Platform-independent.

void LoadLibrary(); loads swi library from file C:/zbin/swi.blib. Platform-independent.

swi.blib file. Platform-specific.
So that's we need else?
No, we don't need nothing but rk27sdk (for function prototypes) and Iar 4.41a

try at first get it working with your own player, then we will provide our own pieces of the code which stand for our own keyboard input.

Every RK27xx player has unique "way" of getting an input - whether it's keyboard or touchscreen. In most cases keyboard works but not all of the keys are compatible.

It is quite easy to disassemble original firmware therefore I would suggest that you should just put a maximum effort on your own firmware. Essential offsets of the basic vectors can be provided or determined later.

Perhaps I can help somehow, I will do the best I can. I assume you are Russian, I am Polish so our communication is limited. But I hope we (rather you) can do some breakthrough.

Thanks for ready to help, flasher86:)
I don't work with keys, I simply try to catch any RockKeyMsg, with no luck at now:( I think rk27 players with touchpad are compatible, because RockTouchMsg consists only from 3 fields - state, X coordinate and Y coordinate.
At this time I partially disassembled my original base.rkw, about 70% from total, most of important functions found. But is where a way to dump full RAM from working player? It will really help in disasm. I can write a simple elf, but maybe special software exists?

I believe it is possible via serial port on the RK27xx - as far as I know serial port is sharing its pins with other parts of the player. Someone here (long time ago) claimed that he is able to debug and access memory via this serial port. But It's beyond my capabilities.

I think writing simple code for dumping ram into file will be the best and easy way.

Also, there may be some possibility in Rock USB mode, but I don't think anyone has figured it out.

So, I think patch original firmware by elfloader and write simple elf is much easy than write our own debug tool...
I will try to upload my work at evening or tomorrow

Looking forward, and many many many thanks for your involvement.

Can't wait to see hello world on my player ;-)

So, this link:
Deposit Files
sorry for Deposit, but it's only one way for me :(
Readme included.
Small how-to:
1) I assume that you have working rk27sdk build for you player. If not, it's not for you at now, I will try to finish Patch on next week...
So, copy directory /Application/Elfloader from my rk27sdk to you working build. Also you need to replace file System/Cpu/arm/boot/startup.s with one from my archive.
2) Open you project and add files elfloader.c, elfloader.h and swilib.c to it.
3) Now you need to make entrypoint. For example, see file Application/MainWin/MainWin.c, function OtherFuc in my archive - instead of stupid stopwatch player will run "C:/elf.elf".
4) Now install iar 4.42 (included in archive), unpack RockElf.7z and open file pbl6a/fonarik.eww in IarIdePm.exe (located at InstallDir/common/bin/). Compile and copy result file Release/Exe/elf.elf onto system partition of player.
5) Reboot player with new Fw, go to stopwatch and run elf:) Then connect player to pc and on system partition you should see surprise;)
Good luck!:)

Omg! this is excellent! :shock: :shock: :shock:

http://i203.photobucket.com/albums/a...pboard02-2.jpg

Maybe would could port some old .rkp games to Rk27 now!


:shock: :shock: :shock: :shock: :shock:

Such a pity about the audio problem in the RKSDK, I suppose if we could patch our good firmware.
This is a great idea to create an elf platform, there is a good chance we can create some homebrew for rk27xx series now. ;-)

Ow, audio issue isn't just my problem?.. Bad, bad, bad:( Do you know more about it?

Add: I think that games is not so important as good applications, such as reader. Also, swilib at this time is not functional for application's bigger than "Hello, world!". We need important, key, "must have" functions in it, but I don't know that functions are most important than others. At this time swilib can have no more than 4096 functions, but this is not principial and can be changed later

Audio is a problem mainly in RK2705 chips.

From my observations it doesnt work well if the external headphones or other type of speaker lack of built-in amplifier. If you plug in the player into speakers with Line-In support then the Audio is as good as normal (I checked it on my Creative 5.1 Speakers). But If I plug the player to any kind of headphones it seems that the signal from the player is too weak so we hear only background phase with lack of "common for both channels" phase (center).

I tried to figure this out long time ago, but with no success. Sometimes (on original firmware) when I plug in the connector the player has this weak signal for about 1 sec, then it turns into full sound. Perhaps there is cyclic functions linked to main() which checks jack-socket regardless RK_SDK original functions - it would explain the delay I've just talked about.

About games... yeah it's pretty long way to achieve such platform.

I assume that now, we can only run some code at boot and thats it. We must create some sort of app menu, where we can execute the code from the menu.

I was experimenting with running my own code months ago, and was able to replace STOPWATCH from my menu with my own piece of simple code. But this was harsh and didnt include executing external file - just patching existing base.rkw

I am currently downloading the package, I'll try to understand how it works exactly, maybe then I will be able to help more.

---------
Just wondering, whether it will be hard to patch firmware the way that we will be able to open files in explorer that are currently unsupported. There is a lot of variables and links to be patched, but it would be cool if we can make new file types supported easily, so appropriate elf will be executed if we CLICK on some file in explorer regarding the file extension.

If that is doable, then a lot of excitement just wait for us ppl :-)