Hooray!!! Rockchip SDK!

[sid6581]

Originally Posted by flasher86

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..... :-/

[flasher86]

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.

[sid6581]

Originally Posted by flasher86

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

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...

[flasher86]

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:

I2C_Init                                ; CODE XREF: CodecCommandSet+10p
ROM:600094FC                                         ; sub_60027CC4+14p ...
ROM:600094FC                 STMFD   SP!, {R4-R6,LR}
ROM:60009500                 MOV     R6, R0
ROM:60009504                 MOV     R4, R1
ROM:60009508                 LDR     R0, =0x60210394
ROM:6000950C                 BL      RockSemObtain
ROM:60009510                 LDR     R0, =0x1801C000
ROM:60009514                 LDR     R0, [R0,#0x18]          <------
ROM:60009518                 MOV     R1, #0x100000
ROM:6000951C                 BIC     R0, R0, R1
ROM:60009520                 LDR     R1, =0x1801C000         
ROM:60009524                 STR     R0, [R1,#0x18]          <------
ROM:60009528                 ADD     R5, R1, #0x4000         <------
ROM:6000952C                 LDR     R0, [R5,#0x28]
ROM:60009530                 ORR     R0, R0, #0x80
ROM:60009534                 STR     R0, [R5,#0x28]
ROM:60009538                 MOV     R0, #1
ROM:6000953C                 BL      USDELAY

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:

ROM:60009514                 LDR     R0, [R0]              <- means [R0, #0x00]
ROM:60009518                 MOV     R1, #0x100000
ROM:6000951C                 BIC     R0, R0, R1
ROM:60009520                 LDR     R1, =0x1801C000
ROM:60009524                 STR     R0, [R1]               < - means [R1, #0x00]
ROM:60009528                 LDD     R5, R1, =0x18a1C000       <- seems to be constant instead of variable

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.

[nlite]

Originally Posted by sid6581

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.

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

I think I found a few ZSP500 opcodes:

f801 0100  mov r1,0x100
5d01       st r0,r1
5521       ld r2,r1
ae01       add r0,1
f000 fffd  br -3
0000       nop

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.

[sid6581]

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

[sid6581]

Originally Posted by nlite

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

I think I found a few ZSP500 opcodes:

f801 0100  mov r1,0x100
5d01       st r0,r1
5521       ld r2,r1
ae01       add r0,1
f000 fffd  br -3
0000       nop

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.

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 ???

[AleMaxx]

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.

[nlite]

Originally Posted by AleMaxx

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.

[AleMaxx]

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