MyMPx.org
Page 43 of 68 « First 33404142 43 44454653 Last »
Show 40 post(s) from this thread on one page

MyMPx.org (http://mympx.org/forum/)
-   General Discussion (http://mympx.org/forum/general-discussion/)
-   -   Hooray!!! Rockchip SDK! (http://mympx.org/forum/general-discussion/43348-hooray-rockchip-sdk.html)

sid6581 18th Oct 2009 11:02 am
Quote:
Originally Posted by flasher86 (Post 283612)
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 18th Oct 2009 11:12 am
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 18th Oct 2009 2:03 pm
Quote:
Originally Posted by flasher86 (Post 283614)
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 18th Oct 2009 2:26 pm
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:
Code:
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:
Code:
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 18th Oct 2009 2:39 pm
Quote:
Originally Posted by sid6581 (Post 283603)
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:

Code:
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 18th Oct 2009 2:43 pm
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 18th Oct 2009 2:44 pm
Quote:
Originally Posted by nlite (Post 283621)
240 MIPS versus 704 MIPS: why bother with the ARM :-)

I think I found a few ZSP500 opcodes:

Code:
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 ??? :p

AleMaxx 19th Oct 2009 2:53 am
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 19th Oct 2009 5:20 am
Quote:
Originally Posted by AleMaxx (Post 283632)
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 19th Oct 2009 5:39 am
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


All times are GMT -7. The time now is 8:38 pm.
Page 43 of 68 « First 33404142 43 44454653 Last »
Show 40 post(s) from this thread on one page

Powered by vBulletin® Version 3.8.6
Copyright ©2000 - 2015, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.6.0 RC 2