The datasheet has several references to a MMU.

Are we looking at the same thing? I haven't found anything related to virtual memory support (allowed page sizes and TLB) in the preliminary (Revision A1.4, Feb 2009) product data sheet for the rk2705.

I have a little bit different question. Does RK2705 support TV-OUT? My player doesn't have it, but I've been looking through some datasheets and it seems that tv-out is pretty easily connected to the Rockchip.

If that so, maybe there is a chance to introduce such a feature. I am just wondering how much RK2705 differs from RK2706 (which for sure support TVOUT).

To my knowledge there is no MMU (and Im pretty sure). There is a remapping-feature that allows switching between boot ROM and SRAM and you can mark parts of the memory-map to be non-cacheable but this surely has nothing to do with the features a MMU provides.
Concerning TV out on rk2705, the chip has an RGB interface (RGB+Sync signals) which is primarily intended for LCDs but you could of course hook up a DAC or PAL/NTSC encoder to this and get a TV signal. Btw, here is a spec-sheet for the rk2705: http://www.szxizhuo.com/UploadFiles/...8105248185.pdf.

Well. I have sota fixed the red screen video problem, I just commented out the line causing it for now in videowin.c
btw this 27xx sdk is full of bugs.
Also fixed another where you can't select a song in the "HOLD" list in HoldOnPlay.c

Thanks for the tip.

BTW. I found a perfect idea how to fix the audio, and I am just working on it. I made two almost identical compilations of SDK, but in one of them I artificially changed one value in the Codec_PowerOnInitial function. Then I compared the two BASE.RKW files in Total Commander, and found where this difference in code occurs. I got a correct address and found it in IDA Disassembler.

It's just a start, I have to figure this out, and find out whether this address differs much from the one in original FW.

The address in compiled SDK for Codec_PowerOnInitial is 600288C0. You may also do some experiments with this.

Well, the sdk is full of bugs, I got tons of warnings that some variables are not used (what a dirty waste). But we can clean it up after we get used to the structure of the system.

I've just identified the address of the Codec_PowerOnInitial in our original FW guys. It's 600278A8. Now it's possible to translate it into C and apply it to our compilation.

Of course, I am not sure whether it will fix the audio issue, maybe there is something else that need to be copied from original firmware.

BTW. Knob, and Sid, how does your speaker work? Mine works really badly, and quietly. It's totally useless, unless there is really quiet around. I just wonder if it's my piece issue, or it's normal for this player.

EDIT:
Well, at first I didn't notice that, but this function is exactly the same as in the SDK. It's not the reason of our problem
Perhaps CodecCommandSet is called differently than here just before loading an audio file. What a disappointment :confused:
If you have any ideas, which function may be responsible for this, tell me and I'll give another shot.

I get no sound from my speaker at all.
I can't help wondering if somehow the player is in TV-out mode for the audio.

The TV-out version player could have a different audio socket because the jack plug has an extra contact, however afaik the SDK support all types of player, it might just be an error somewhere in the source, there seem to be quite a few errors and bugs!

I meant if the speaker works well in your original FW. Because even with proper audio it's too quiet. Maybe it's just my piece issue.

With my original firmware my speaker isn't that good, but it's no worse than other rockchip players I have had.
Did you backup your original firmware? Is it exactly the same as mine? Mine is uploaded to Mympxplayer if you want to try it.

That's the data sheet I was looking at.

W.r.t. the MMU, I hoped the rk2705, being newer than the rk2706, would support virtual memory. But still a superscalar (4-issue) DSP with 8-stage pipeline and general-purpose 32-bit instructions is slightly intriguing (assuming it hasn't been lobotomized by Rockchip and can function on its own).

If someone familiar with rk2705 firmware can suggest a small piece of DSP code, I'll try to find some ZSP G2 instructions, perhaps hack a simple (open source) disassembler because there doesn't seem to be one.

Have you looked at DSPLoader.c? There are references to a few files e.x. C:\SYSTEM\jpg.bfw

Knob, I didn't check precisely whether we have the same original FW, but I made a backup. But I am pretty sure we have the same, this is non-brand player, noone cares about FW for our player.

BTW. I've been digging through the code all day today. I successfully identified at least 20 functions e.x. I2C_Init, IOMUX_SetI2CType and many others.

I noticed very few differences between original FW and the one from SDK but they exist. Especially with function IOMUX_SetI2CType.

I have problems with understanding the structure of the original function. It's weird because I don't know where the function really starts. In the original IOMUX_SetI2CType function it has some extra code at the beginning, but other functions call it not to it's beginning address but to somewhere in the middle.

Although I haven't been able to fix this audio yet, I am really glad because I have a chance to learn ASM ) After some time it's not so creepy language.

I was looking at this which has references to mmu_ctrl mmu_addr etc.

MEGAUPLOAD - The leading online storage and file delivery service

I haven't looked but that would be surprising. An ARM7E is not supposed to have MMU (?) Now, RK28xx that's an other story :)
About the DSP, i still think it is ZSP500 with those G2 instructions for which we don't have the opcodes, vs ZSP400 for RK26xx.

I have RK2705 too, and 240 MHz for ARM7E and 176 MHz for ZSP500 is actually pretty impressive.

These mmu_ctrl and mmu_addr registers seem to belong to the SD/MMC controller, possibly related to DMA transfers. I dont know what MMU stands for here, but this has got nothing to do with a MMU in the usual case (in my opinion).

I think that too, I read somewhere that this CPU doesn't support MMU, but there are some wicked MMU-like features for better handling SD Card. I am not sure where I read it, but it was some site with comparision of ARM7 and ARM9 which is the main CPU of WIZ game console.

BTW. Does any one know what are the functions in IOMUX for? I am trying to fix the audio problem in my RK2705 player. And all my clues go to this function. But I don't want to waste time if that has nothing to do with audio.

The audio has kind of weak signal, it doesn't work properly if there isn't any addition amplifier connected to the player. Maybe someone know which functions in the SDK are resposible for headphone amplifier?

Knob, and Sid6581 I uploaded IDA project (BASE ORIGINAL.rar) for our original FW. There is huge load of functions in NAME window. If you wish to play a little with IDA Disassembler it will definitely help you.

Many pins in the RK27xx chip can have several usages.
IOMUX functions selects the particular usage for a pin.
They multiplex pins to reduce the number of pins for the chip, which is supposed to reduce cost.

Have a look at system/drivers/hwapi_iomux.h and look at the datasheet for pinout.

For example,
pin #30 is GPIO A1 or LCD data bit 16 or UART0 rxd
pin #31 is GPIO A2 or LCD data bit 17 or UART0 txd

So, if you want to use UART0 to have a nice debug console on your PC, you simply have to do:
IOMUX_SetUart0Port(UART0_UART_TYPE);
and then configure UART0.

You would have to solder TX, RX and GROUND to a board that translates UART <-> RS232 or UART <-> USB.
I would advise this Future Technology Devices Intl - FT2232H Modules
You will have a regular com port appearing on your PC and can use your favorite terminal...

The link is broken! :(

By the way, this is a super useful module.
From your PC, you can control devices via UART, SPI, I2C ... the most common protocols out there, and have a bunch of GPIO.

Hmm speedyshare server seems to be broken now.

Here is another download: Download BASE ORIGINAL.rar from Sendspace.com - send big files the easy way

So Sid, Tell me, is it possible that IOMUX can be responsible for bad audio? Because I am lost. I digged through ASM code of our FW, and found some additional functions in Main(). GPIO_PowerOnInit is completely removed and replaced by something else. Can a set of GPIO pins do something with our problem?

I am not sure really.

It's true an error in IOMUX config ( ie. a pin is not configured correctly ) could be responsible for having audio issues.

You imagine that if I2C was used as external port instead of internal when configuring the internal CODEC, you would have trouble. But i assume they did this part correctly.

Same goes for I2S, IOMUX_SetI2SType(UINT32 codectype)
it could be set to talk to the internal CODEC (our player), or an external codec like wolfson, hence prohibiting the usage of GPIO port C pins. If it is configured for external CODEC, i am not sure what would happen..... :-/

HW_rockcodec is configured correctly. I checked all the functions (CodecCommandSet etc) from this file and they are exactly the same as in our original FW. It do not calls external codec. Also initially they are called with the same arguments.

Another thing is that FM works properly so Codec must be good. There is a problem with digital audio only.

I2S_PowerOnInit is little bit different from the one in SDK. Have a look at the file I uploaded, this function is listed there.

IOMUX_SetI2SType is also there, and it is the same. Perhaps it's called with different arguments.

I am almost sure that we have our solution in function UHInitializeFirst and UHInitializeLast, both for audio and keyboard.

Btw, the datasheet for the FM modules used in most MPx players can be found here:
SparkFun Electronics - FM Receiver Module

I am quite not sure if the FM input is fully processed thru the CODEC (FM -> ADC -> CPU -> DAC).
I know we can record FM, so it must at least go to the ADC but it is not sure it goes to CPU, and be copied to an output buffer (audio streaming). By the way, when recording, it looks like you can choose between MIC,FM,LINE inputs because there is an analog switcher in the internal CODEC.

When you hear FM, it might be analog, but to prove that you'd have to look at the code...

You are absolutely right. FM playback run without use of ADC and processing data. Only for recording it goes into PCM stream.

BTW, I found something in I2C_Init which makes a little bit worried. Just check this out:
this is the beginning of this function from original FW, in SDK it is very similar but it has 3 differences.

In the SDK the same function looks like this:
I tried to test it out and find out whether it has something to do with the audio, but I can't apply such a difference to the SDK. I tried to include it in __asm in ADS but with no success. Also I tried to modify BASE.RKW in Hex Editor but after that the FW didn't work at all.

Sorry for spam, my posts are huge.

240 MIPS versus 704 MIPS: why bother with the ARM :-)

I think I found a few ZSP500 opcodes:

This is a bit of silly code to illustrate some debugger commands. In C-like notation: r1 = 0x100; while (1) { *r1 = r0; r2 = *r1; r0 += 1; }

The interesting thing is that mov and br seem to be 32-bit instructions here.

Don't worry about the length of your post, this thread is HUUUUUUUUGE anyways :)
Really i think we should have our separate section on this website, for developers like us, so we could have separate threads for specific topics.

Ok, well, i think i had played with the codec initialization to see if I2C communication was working and i seem to remember it was.
You can play with the volume for example, set it to super low level... and if it works, it means our I2C drivers works (and i think it does).

They might have slightly modify the driver from a version to an other, i don't know... but i do think I2C works :)

WOW ! you are on something.
You are right, i read somewhere that ZSP500 instructions are a mix of 16 bits and 32 bits instructions.
Where/how did you find this code ??? :p

I guess he found it here: http://www.fs2.com/lsi_download/Zsp-Getting-Started.pdf. In that directory you can download the debugger as well so maybe downloading, ... we might have it ;-).
Now, the installation program is pasword protected.

I don't use Microsoft products (including .doc files) and I won't use anything that might endanger a clean room implementation of open source tools. There's enough information available in the form of publicly available PDF files from vendors, academic literature and, above all, firmware.

Hoho, I think we have an assembler (zdas.exe) - "GNU assembler version %s (%s) using BFD version %s" !!! It uses cygwin though and it crashes when I start it with wine and no cygwin installed, how can that be? ;-) Comes with linker too (zdld.exe).
Here it is: http://www.sendspace.com/file/nkeeji

On the audio issue, has this been solved? I have a 16GB 3" touchscreen 2706 based player with a speaker. One of the player's annoyances is that with sensitive earbuds, you can hear the display chirp like a ticker when it scrolls text, so I hoped that different firmware might improve the problem. (You can only hear the ticker when the display is lit.)

I installed some different firmware and the chirp went away. Also, the external speaker went away. I thought it was a good trade-off until I really listened to some songs, and realized they sounded like something in karaoke mode (which I think removes the similarities between channels, in an attempt to remove the vocals which tend to be spatially in the center of a stereo song), or like when my PC's audio drivers are misconfigured for a surround system, when I've actually only got two speakers.

Would it help to compare the two firmwares in a disassembler? If you knew where to look, it might be revealing.

I think what you're encountering is probably a feature, not a bug. ;) Is there a channel mixer somewhere in all the goodness? I think you can swap the left/right channels in "software", since there's an icon for it in my bmp0, but my player doesn't have that functionality.

I can compile the SDK to run on my player, but the buttons don't work, not to mention the touchscreen. It's not reading them at all, as it turns the backlight off and I can't wake it back up (I think this is what's happening, I suppose it could be crashing). The off-button doesn't even work, so I have to either reset it or plug in the USB to wake it back up.

I have this exact player:
Amazon.com: Pro Ebiz NEW 16gb 3" TFT Touchscreen Mp3 / Mp4 / Mp5 Player (Plays Avi/rm/rmvb/flv Without Conversion): Electronicss=electronics&qid=1255963455&sr=8-1

It's a nice player. I've had it opened and it has two visible Samsung chips but most of the electronics are covered by a large "Sony Fukushima Sew UP42367A6H" battery. The screen is an "AA003AH", which works with the FD5420 driver in the SDK. You have to change the backlight PWM frequency in hw_backlight.c, BL_Init() from 10000 to 15000 to keep the screen from giving an audible whine. I got the 15000 value from analyzing the original firmware.

Welcome, Molitor.

We have the same issue as you have with audio. Check whether this decrease of the voice happens when you plug your player to some speakers or amplifier. It works well for me if I plug it into Creative PC Speakers, it is probably the same situation with you.

I am also curious where to look at ASM to explicit the right config for our audio problem. Please send me your FW (the one with audio working) to my email: flasher86@gmail.com. It will be easier for me to compare 3 FW with 2 well working audio.

Disassembling is not a problem for me, I can identify almost every function which the SDK has, unless some new wicked structure functions has been introduced into FW by the seller.

The keyboard is also applicable for the SDK. It is easy to identify GPIO set of pins, so SDK may work for you in the future. Of course I am talking about standard buttons without some weird chip to control the whole thing.

Have you managed to modify already compiled FW by ASM? Or do you just work on the current SDK C compiler?

Ok so I see you found the few opcodes you mentioned in that Zsp_getting_started.pdf
Do you think there is really enough information out there to have the list of *all* the opcodes ? :)

When you modify the code you must calculate a new correct crc32 value or turn of crc32 checks. For crc32 code have a look at this: http://alemaxx.al.funpic.de/rk27/rkwpatch.tar.bz2

I think that using information even from Microsoft for this purpose is not a crime even for linux-fan community. The reason for this is simple, this project can OPEN the way to open source software on RK27XX players. Microsoft is a monster, but sometimes you can beat the enemy with its own... source code :D

Thanks a lot. I tried to modify the code in Hex Editor. And although I knew I haven't recalculated crc32 I thought it will work anyway (rk26XX doesn't care about crc32, there is only warning, button IGNORE, and off you go ;))
btw. Is the program you mentioned a linux console tool? I don't use linux, how to compile it into Windows console tool?

Its a simple c-program which only needs std. library functions, it should compile on nearly every system. But thats a pretty old version and I dont remember what its exactly doing. I would recommend using it as a starting point for your own special-purpose tool.

Btw, I dont know why nlite cites me and then starts talking about Microsoft???

I wonder if FSF and RedHat know that somebody is using their GPL'd products without providing source.

Compiles with Mingw but you need Admin rights on Vista and Windows 7

MEGAUPLOAD - The leading online storage and file delivery service

I am trying to create a simple base.rkw patching utility but I have had problems repairing the crc, rk26xx was easy, just a MD5 at the end of the file.

I compiled the 2 base.rkw's (with a 1 byte change)and compared them to find the crc, it seems to be the last 8 bytes of the file which changes, that would suggest crc64?

I used rkwpatch.exe in a batch file with
rkwpatch.exe BASE.RKW no.bin
pause

no.bin is just an empty 0 byte file. Managed to patch base.rkw in my original firmware to get 24 size fonts in the id3 display and it works great.

Thanks for the rkwpatch.exe tool AleMaxx, I can now mod my original firmware. I might try and create a tool now that anyone can use to patch base.rkw.