To do the interesting stuff we really need file access badly now. Things like station logos would work better with bmps on the flash memory and we could create a good rkp based music player, even better than rk27xx series players I think.

The FM radio app proves we can get stuff from .rfw firmware and use it for a .Rkp app

You can have microsoft playFx on a Rk26xx player, the teclast c260 had it. Does your teclast clone player have playFX? btw. There is code for Playfx in the Rk27xx source code.

Actually, I have Teclast C260 Clone, and it supports PlayFX. It depends on the firmware. My original polish firmware doesnt have it, like many other functions (rkp is not supported), but firmware from Teclast works, and PlayFX also.

I too think that if we had access to the system functions we could do even better music player than in 2706. Capabilities are huge, but companies are very lazy at creating firmwares. They just want to sell it as soon as possible. It's all about the money. For example if they released the source of those libraries it would mean that even Teclast C260 would support videos without converting with subtitles, OGG format, Album Art, SWF player, linux and such. Such player would be worth much more for little money. But its not what companies want, to give these things to us, they just release a new player, with almost the same hardware and just better firmware. Cash cash cash. :mad:

Sometimes I regret I am not a hacker to just hack into their computer and steal the source code. :cool:

In terms of hardware, it has huge capabilities anyway. For example RK260X supports bluetooth!! It supports USB fully, so it would be even possible to connect some devices to the player like pendrive, printer or webcam.

Is there any way to disassemble rfw firmware? Maybe RKP dissassembler could be modified to handle rfw files, I mean the type of code of rkp and rfw is exactly the same, only the header and resources are different and in different offsets.

Hi there all,

I have downloaded the "Rockchip Developer Package".
I am a c/c++ programmer so I should be able to play with the firmware (i hope!)

I would like to experiment with the RK27xx, and the ZSP400 DSP.
First, I need to buy a player, so what Rk27xx player would you recommend, and where can I buy it online ? (knob, yours seems to be good).
Is there a list somewhere ?
I was thinking about the RAmos T9 8GB, with touch screen.

Also, what about the new RK2806, any doc regardig that chip yet ?
I see the T11RK 5.0" sells for only $129.50 online ... Amazing...

Welcome. The more members can get involved the better, especially anyone who is a c/c++ programmer.

We don't have any source code or info on the Rk28xx series players atm only Rk26xx and Rk27xx.
I have successfully compiled and ran the firmware for rk27xx and rk26xx.
The firmware ran ok on my rk27xx from tinydeal, I could play music ok, but there was an issue with screen drivers so I got no display just a backlight.

My unbranded Rk2706 from Tinydeal is quite good to play with, I was able to go into recovery mode using the reset hole without opening up and it's cheap from tinydeal.
There are basically 3 types on this page:- http://www.tinydeal.com/index.php?ma...1v3mc8v4kvb3q3(the touch screen is the worst of the 3)

www.mp4nation.net have a good selection of branded chinese players too, most but not all are rk27xx

Thanks for the reply :)

There are soooooo many MP4 players out there. Do they basically have the same GUI ?
Do you think only the branded name MP4 players like RAMOS/ONDA can afford to modify the firmware to their needs ?

It looks like only rk26xx and rk27xx firmware base are available on the net, is it due to some kind of leak that may not happen anymore for the next generation rk chips like rk28xx ? mmmmmh ...

Have you every come by the actual rockchip developpement kit ?

A few question about the source file.

* What is the difference between the RK27SDK_0722 and RK225_Dict_08_28 directories ?
Is the first one just using libraries of the second one ? I see the second has more files for mp3 decode, in particular some assembly files to speed things up...
* Have you been able to use an emulator so far ?
* How do you do your developement, do you use JTAG or you compile and upload each time you want to test your code ?

Cheers

Well but their source code, isn't it mainly coming from rockchip, actually ?
If that's the case, they probably give it to you if you plan to use their chips in your own products ? I don't know ...

Do you actually see USB host drivers in the source code ? It looks like there is only some USB device stuff, so you can see the ramdisk, sd disk or NAND flashdisk, am i missing something ?

I think without the source code it is going to be very difficult, it would take you a looooong time to disassemble everything and especially to understand it.
Hopefully it is possible to do a lot with the current source code and hopefully some new source code will be leaked !!! :)

Most RK260X players uses almost the same firmwares, with small changes only. So I would say that companies dont create their own firmwares from scratch. They must be well equiped by rockchip company with developing resources.In terms of USB, rockchip has abilities to handle all the usb devices, but there is no drivers for that, although its possible to write them.Rockchip SDK provides config files for compiling in which you decide which features need to be included (line in recording, fm radio, even CDROM!). So companies probably do little job with their firmwares.

I think you are exactly right.

That's why nearly all those MPx players out there look the same, have the same number of buttons etc etc.
The manufacturers only put their own logo/graphics and that's it.

Now, maybe some companies (Ramos?) are willing to be a little bit further and invest in some developers in order to create better GUI and so worth... Or is it just the Rockchip company that does this ? After all it is in Rockchip's interest to make their chips attractive and they totally get it right buy creating a "plug and play" customizable firmware.

Maybe I should ask some people I know in China to contact Rockchip and see how much business they are willing to do with foreigners. That could be interesting.

Regarding the USB drivers, the Rockchip 27xx has USB host capability, so yes, it can handle all the USB devices out there. However, if it looks like you would have to go for Linux if you want to handle them all.

So far I haven't seen what USB Devices the RK27SDK_0722 can handle. The only thing I see is making the MPx player appear as a device to a computer ? Anyone ?

This code is for touchkey suport for RK2606A_SDK_1.08_Release project.
Tested on "acme v500x"

This is working lcd driver tested on acme v500x for RK2606A_SDK_1.08_Release project

oh maaan, thanks a looot!!!!!!!!!!!!!!!!!! I have touchkeys and LCD320x240!

This acme players is really not so different from mine Teclast C260. My polish brand of the plauyer is called Pentagram, and this company released exactly the same player as your ACME, so there is a pretty good chance to finally do something with the firmware for my player ;-)

I looked through the code you've posted and it seems that the binary values for keys are the same as in mine player, despite different key layout.

well, I compiled the firmware with these, and the good news is that the screen is working (little bit flickering but you seemed to have the same experience), although the source is prepared for smaller screen, so all the bitmaps are up to the left. The bad news is that this touchkey driver is not working for me :(

The backlight of the keys are turned on all the time, and the keys do not response. I have a power button to turn it on, and it turns on, shows animation, but thats all, I can't even turn it off, fortunately there is another power slide button to cut off the power. Despite that, the firmware seems to work, it gets into usb mode and main menu, also access to the flash memory works (so I was right - TeclastC260 has MLC flash), as low level format is being done successfully.

Interesting thing is that it works much faster than original firmware, It shows main menu just a second after pushing the button, not like in my original where I have to wait 4-5 seconds and watch stupid animation. Also when I connect it to the computer I dont have to wait like 2 seconds before it go, it goes into USB Mode immediately.

Yes the screen is blinking, and I dont know why meanwhile. And for the touchkeys you have to disasemble your player and tell me what chip is controling keys in your player, and I try to help you with that, for my player it is CP2508. And I try to make the touchkey driver more ajustable for you.

The screen is blinking because there is set the wrong resolution for the screen.
though, when I changed these values to 320x240 the screen worked only for a second, so no go. When I changed only YSIZE it worked and did not blinking. I think some of the displaying bitmap functions gets crazy because of wrong screenwide value. I think I handle it after some time.

I disassembled the player, but it was really hard to get to the key chip, it is located behind main board where all the cables go, and I was afraid that I will broke them.

There was a small chip in the middle called: KT6400 ABWJ, just below on this chip there was 0650K BDO (or zero). I found no result on google for that.
But, on the board of the key there was a caption "C230KEY V9..." I dont know what was after 9 because it was too risky to bend the board more, as I could break the cable connected to the screen and kill my player forever.

Also, I noticed something else while playing with the screen. I can readout LCD Driver using RKP application. It will require to write down about 100 values and put them into the source. Maybe later I will prepare rkp app, so every player which supports RKP platform will be able to run his own firmware with the screen working.

Keys are my only problem. I think i am left with scanning the memory using RKP platform and trying to get some response in the code without using standard GetKeyVal function.

I've made a mistake. I disassembled it once again, and the chip is called eKT8100 ABWJ. These letters are just so tiny! Now google showed me a lot of results.

Could you help me with my keypad driver?

this is the datasheet
http://www.ic-cn.com.cn/static/pdf/E...EMC_987110.pdf

On the PDF I posted there is list of bits which must be sent. Unfortunately I don't have an oscilloscope.

But there is a bunch of little cables which connects to the Rockchip, will it be enough if I tell you to which pins they are connected to?

Yes tell me please.

I will check them out later, because I am now at work and don't have access to it. Thanks anyway.

I've just look into it, and its really hard to figure this out :( The cables are connected from behind the board with Rockchip, there is 8 of them, and they seemed to be connected to the pins between 28 and 42 with some space between each of the cable. (its the lower to the left side of the Rockchip).

I just can't precisely find it out. Could you tell me maybe, how to check the status of these pins? Which address in memory they are?

Another thing, I noticed that whatever I do with your GetKeyVal function, the player dont run! I even replaced your function with simple blank one which always returns 0 but then it don't run. I'm stuck. I can't even get standard POWER button working, which has nothing to do with touchpad. The only thing I was able to do was to manipulate the level of backlight of the touch keys. I simply use write_mem(GPIO_PDAT0, 202) and the lights got darker.

Edit: I was playing with RKP, and reading values from all the gpio controller, and I noticed huge activity at very high speed on GPIO_PDAT2 where goes especially two values and sometimes some other while hitting some button. Am I on the right track to make a driver? Is it possible to simulate these values in the source so it could work?

To make a driver you need to know exacly how this chip connected to the CPU, could you make a fiew photos of this chip and connections?

I'll make photos and post them later.

But how the data is transfered between the other chip? Does it uses the whole variable GPIO_PDATx or just one bit of this var depending on the pin used? Or do you config which pins they are by setting GPIO_PCONx??

No, it dont use whole variable GPIO_PDATx bits, keyboard chip uses some of them. And yes I config which pins they are by setting GPIO_PCONx, thats why I need to know how do they connects to the CPU. Your keyboard chip uses I2C bus to comunicate with CPU about it you can read here

Ok, I will post pictures, but what if I tell you the values of the GPIO_PCONx from working original firmware? I can read them out using RKP platform. I did that with GPIO_PCON0 and put that value to the SDK source and now finally POWER button responses.

Maybe you can figure out which pins are used by this value?

Even if not, maybe this will help you somehow:
GPIO_PCON0 = 22822
GPIO_PDAT0 = 202 - 252 (its the value to set the level of backlight of the keyboard, dont confuse it with lcd backlight also its the value of POWER button)
GPIO_PCON1 = 9229
GPIO_PDAT1 = 151 (and sometimes 22 but rarely)
GPIO_PCON2A = 66
GPIO_PCON2B = 3003
GPIO_PDAT2 = 61116 and 53035 changing between every 1 ms (sometimes there is some else value 61199 and some that I didnt put down on paper)

Values PCON0, PCON1, PCON2A and PCON2B are steady, they do not change, while others seem to be changing all the time.
btw, all the values are decimals, not hex.

the power button responses because it connects straight to the GPIO_PCON0 pin, you can tell me the value of it that I could include it in sources, but with I2C interfase is not that simple.

ok, I will make a photos then

if these values are corect, then it seems that your original firmware keyboard driver uses interrupts to drive the keyboard chip, it whill take time to figure out how to work with CPU interrupts first.

is this what you're looking for?

No, it is part of 1 of 4 interrupts configuration, if 1 of these interupts are enabled and used by hardware interrupt request, then CPU goes to that interrupt function and executes it, and I need to figure out how to write this function. Rockchip is like a computer CPU, like Pentium 1 at least :D

By the way, if you dont know how to use the DEC values, or asign them with the rockchip CPU datasheet file, I made a simple explanation in attachment, it whill be intresting for everyone.

Gulp! all I can say is I'm glad I don't have a touch screen Rockchip. I just hope you don't break your player! :-)

Hmmm, thanks Nemesis. I know how to manipulate with hex dec and bin, but actually I didn't know it reacts with hardware. I am a high-level programmer, its hard for me to understand low-level operations and their relations to the electronics and such. I hope I will get into this, because such knowledge is useful as hell!

I regret I bought a player with touchpad, but at that time it was the best player on the market. It was the only one which supported AVI instead of AMV and MTV. So I thought touchpad will be great too, but its not, its even tiresome. Touchpad often gets crazy in extreme temperatures. Winter outside, or Summer exposed to sun and touchpad barely works.

I made some photos. As you can see I don't have full physical access to it. On the first one I figured out (I hope I was precise and did not make a mistake, though i might be wrong by one pin to the left or right) to which pins it is connected.

don't know why, but something with links is broken (it linked to thumbs only), here they are again:
http://img245.imageshack.us/img245/6664/connections.png
http://img16.imageshack.us/img16/2096/dsc00345v.jpg
http://img6.imageshack.us/img6/73/dsc00346kw.jpg
http://img14.imageshack.us/img14/7256/dsc00354lt.jpg

http://img245.imageshack.us/img245/6...ections.th.png
http://img16.imageshack.us/img16/2096/dsc00345v.th.jpg
http://img6.imageshack.us/img6/73/dsc00346kw.th.jpg
http://img14.imageshack.us/img14/7256/dsc00354lt.th.jpg

From what you drew, it looks like one of the pins of the cable goes to the DP pin of the Rockchip (pin #5), which is one of the two USB data pin ... very suspicious. Mmmmh, are you sure about that information ?

Soon our own PCEmulator for Rockchip ?
 

I haven't received my player yet, still I wish I could already toy around with the firmware, so I looked a little bit more into that emulator everybody has tried to compile...

Well, I don't think we have that "PCEmulator" that is shown in RK27_PC_Emulator_V1.0.pdf
I don't think compiling that RK27xx.dll file is difficult at all, I am almost there using VC++ 8.0 after handling a few missed files (debug stuff, mainly).

Rockchip people have been very smart in their approach of developing the OS for their chips :p
The bulk of the code is good ansi C and is platform independent, it will compile on both ARM and i386.

Of course, there is a bunch of exceptions when it comes to low-level, and for that, they have to have two different source files for both processors.
Also, I am not sure that for the i386, any mp3/video decode is available since those have many parts written in ZSP400 assembly. However, I am seeing some code that open sound channel on the PC, in that RK27xx.dll

Anyways, I simply believe that video and audio playback on the PC is not at all the goal of the PCEmulator
I presume the goal is about the OS.
Writing games and improving the user interface can be done faster than with using the target (although, I presume you can probably do that using JTAG directly on their ARM chip).

So yeah, we all want that emulator...

In fact, the code is already there in that rk27xx.dll (It is really a dll, so don't try to rename it to .exe or so forth...)
That dll is just the i386 version of the actual ARM+ZSP code.
The problem is, we do not have the GUI front-end that is driving that little DLL :(

But ..... I do not think it is that a big deal to write our own !! :D

The DLL interface is fully described in rk27dll.h
You can see about 15 useful functions there, and that is what the GUI front-end must play with !
For most of them, just looking at their names and parameters is enough to understand what they do and how our GUI front-end should use them.
However if it is not self-explanatory, we can always look at their C implementation to be sure we get it right.
It seems very easy by looking at pccore.cpp

Let's see .......

The GUI probably first have to call PCCoreSystemStartup(HWND hwnd , int ep);
At the end it should nicely call RK27DLL_API void PCCoreSystemShutDown(void);

Those TR functions that I had to #define to nothing can be written by us in that missing debug.c file
This is very useful to display textual debugging info in the GUI (like you can see on the right side of PCEmulator).
Then, the GUI uses
RK27DLL_API char* RPCGetTraceBuffer(void);
RK27DLL_API void RPCSetTraceBuffer(void);
to retrieve the debug trace info ....
Those functions are not defined anyways in the SDK so i presume they were really part of that debug.c
We just have to write our own, it is easy.

Buttons and touchscreen must be simulated by the GUI front-end by calling
RK27DLL_API void PCKeySetKeyState(int keyScancode , int UporDown);
RK27DLL_API void PCTouchSetTouchState(int state , int x , int y);
As you can see it is very self-explicit.

To draw the actual screen, the GUI must first question the size:
RK27DLL_API INT16U PCGetLcdWidth(void);
RK27DLL_API INT16U PCGetLcdHeight(void);
RK27DLL_API INT16U PCGetLcdDisplayFlag(void); (always returns 0, not very interesting)
Finally, with those infos, the GUI can correctly display the screen from the pixel buffer:
RK27DLL_API LCD_RGBDATA* PCGetLcdLogicBuffer(void);

There are 2 functions left about simulationg IRQ :
RK27DLL_API void PCIGenerateIRQ(int irq);
RK27DLL_API void PCISetIrqData(INT32U irqIndex , INT32U irqData);
(for that I would have to see in the C code what behavior we can trigger, it might not be that useful for us at the beginning...)

There is one function for which I quickly looked at the C implementation
void __stdcall RkPCTimerTick(
HWND hWnd, // handle of CWnd that called SetTimer
UINT nMsg, // WM_TIMER
UINT nIDEvent, // timer identification
DWORD dwTime // system time
)

There is a comment in chinese that i don't understand and i see a 5ms.
That's the info i wanted ;) Our GUI front end should call this function every 5ms (which is pretty tight, btw).
I guess a "multi-media timer" will have to be used for this in the GUI.

This periodic timer is probably necessary for their multitask OS to function.
To handle any sort of animation on the screen for example.
(although I bet most of the important stuff is interrupt-driver, which switch tasks depending on the task priority)


That's all for now .. ;)

sid6581
Do you have the doc for the emulator? here is a dump what the interface supposed to look like.

The buttons below the image represent the buttons on the player , you got up, down, left, right menu, ok etc. Like you say not much to it, but missing from the source. Ought to be possible to recreate the interface though..

I have the chinese PDF file yes, so I know what it looks like.
I am going to try to do something very simple without button, just using keys for up/down etc etc, and using SDL to render the screen....
If it works we will be to see the trace in the command line window....

I have just compiled rk27xx.dll
I have to add my own functions for TR (trace)
Then I will try to start the system .....

I will let you know :)

We all have doc for PC_Emulator, it's inside This link was deleted archive with other documents.
But if you don't want to download 20 Mb just because of small document,
HERE it is

It's cool but unfortunately it does not help much.

I almost gave up on everything when I realized that the pccore.cpp is using source file that we don't have for implementing their OS on the PC-side.
Fortunately, they provide us with a precompiled pccore.obj !!! So it's ok to not have those files :)

I hope I am not going to find out other issues like this that make this impossible to achieve .... I am crossing my fingers and continuing digging into this .....

Here is what I got so far when I start "the emulator" :

Sys Disk Writable[0]
User Disk Writable[1]
SYSTEM INIT!
Open File[C:\RESOURCE\BID\BMP0.BIN] Failed!
Open File[C:\RESOURCE\BID\BMP0.BIN] Failed!
INIT SYS BMP STYLE FAILED!
Open File[C:\RESOURCE\FONT\FT12.BIN] Failed!
Open File[C:\RESOURCE\FONT\FT16.BIN] Failed!
Open File[C:\RESOURCE\FONT\FT24.BIN] Failed!
OPEN ASCII WIDTH FILE[C:\RESOURCE\LANGUAGE\ENGLISH\CWIDTH12.BIN]FAILED!
OPEN ASCII WIDTH FILE[C:\RESOURCE\LANGUAGE\ENGLISH\CWIDTH16.BIN]FAILED!
OPEN ASCII WIDTH FILE[C:\RESOURCE\LANGUAGE\ENGLISH\CWIDTH24.BIN]FAILED!
OPEN LANG TRANS FILE[C:\RESOURCE\LANGUAGE\CHINESE\GBK2U.BIN]FAILED!
Open File[C:\RESOURCE\SID\STRINGID.BIN] Failed!
Open File[C:\RESOURCE\SID\STRINGID.BIN] Failed!
INIT SYS LANGUAGE FAILED!
BMP BUFF SIZE[6c90fc] , NEED SIZE[200000]

I use the LCD functions and query some info:

-> Pointer on framebuffer = 103ba6a0
-> LCD Width = 320 LCD Height = 240

So I still have good hope everything can be achieved :)
I am going to relocated the resource to the right directory and try to get rid of all those "failed" messages.

Once it's error-free, I will display the framebuffer to my SDL window .....

Ouch that thing is trickier than expected...

The rk27dll.dll is compiled with the ROCK_FS define, by default.

Rockchip guys are probably testing their filesystem on the PC-side.
Maybe a disk image representing the NAND flash is created (?)
The problem is, the pc-side implementation of the file-system is masked to us and is pre-compiled in Library\PC\fs_vc_lib.lib that we statically link to rk27dll.dll
So, I have no idea where and what kind of disk image it wants to read, how to generate that image and so on.
It might be described in the docs, but it is all in chinese, and it does not seem they talk about this anyways.

So, I have removed the ROCK_FS preprocessor definition from the vc++ config.
I had a few errors related to audio that i simply commented in the code, so I can still generate my rk27dll.dll
I have spent a bunch of time looking at the whole code about FS, and i see that if ROCK_FS is not used, the PC-side code will use normal disk functions to open a disk, read/write files.

I went to the resource folder and started getResourc.bat, which generate a bunch of stuff in the Output directory.
I copied the Outout\Resource to C:\Resource and now the OS does not complain about anything anymore and it seems it has read the whole stuff.....

So ...... I am ready to finally try and display what's going on on the virtual LCD ...............

When trying to generate BMP0.bin, i get a bunch of messages due to chinese folder names :

Open File:C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\MusicguageBack174_223.bmp
Failed Cmd Failed!, argc=1,argv[0]=C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\M
usicguageBack174_223.bmp,Ret=1
Open File:C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\MusicMiddleBack0_102.bmp F
ailed Cmd Failed!, argc=1,argv[0]=C:\Rockchip Developer Package\RK27SDK_0722\Resource\input\bmp\RK2701\001 music\?????\Mu
sicMiddleBack0_102.bmp,Ret=1

And so forth .....

How did you guy solved that one ? I need to generate this bmp0.bin properly it seems ....

I generated the BMP0.bin in the end. I had to rename all the bmps and the resource file.
I'll upload my build, then you can use it if you want.

Send big files the easy way. Files too large for email attachments? No problem!

If nothing can be done with the emulator the firmware does work on the player itself.

btw it expects a the path to be C:\rk27sdk_new\Resource\input\bmp\ etc

You're doing well, I was stumped with the emulator.;)