Cowon D2

[Frits]

I have a D2+ dab with firmware 4.13
I can't find a Rockbox version for my player.
Will it ever come?

Hi Frits, look here http://andrew92.centelia.net/ to see instructions and links to the patched firmwares. Just make sure to check your FW version. You'll want to be using one 4.xx See here also http://iaudiophile.net/forums/showthread.php?t=25285

I have downgraded the fw version from 4.13 to 4.12 but it won't work.

I have tried this.

 Download mktccboot.exe from here
- Download bootloader-cowond2.bin from here
- Download the original v4.12 D2_P.bin from here
- Put them all in the same folder, eg. C:\firmware
- Open a command window and run the following commands:

Code:

cd /d C:\firmware
mktccboot D2_P.bin bootloader-cowond2.bin D2_P-patched.bin

This should have created a new file, D2_P-patched.bin, which you should copy to your D2 and rename to D2_P.bin. Reboot the D2 and all should be fine...

[motorbit]

hey, i think i found a bug or such.

lately, Ive been expecting some strange dissortions ( a high crackle) when i played audiofiles i  ripped some DVDs @ 16bit/48kHz.
also, Rb became irresponsible once when i was attempting to play one of these files, but a reset fixed it. i do´nt know whitch file caused Te crash and that crash was not reproducible.


i try ed various settings:
fl ac, ogg & ape each with some different settings off gain and with a -6db hard limiter.


to make sure my Rb isn't outdated or such , i made a clean install, what  fixed the problem. the oldest Rb version i tryed was r25836 and the most recent was  r25892.

original d2 Fw wont play flac @48kHz, but both oog and ape played fine with 2.13 cowon Fw.

all files played fine in rockbox after i re sampled them to 16bit/44.1kHz with foobar.

[longfeng328]

Hi there,im a code learner,i want to contribute to the RB's developing on D2.

now i think the usb issues is most necessary to be solved,e.g. usb charging or data transferring.
Onced done,we can set RB the first-boot firmware.

so could anybody tell me which files of the sources' code  should be concerned?

[saratoga]

so could anybody tell me which files of the sources' code  should be concerned?

Check out:

/firmware/target/arm/usb-tcc.c

and

/firmware/target/arm/tcc780x/*

Also, /firmware/SOURCES lists most of the D2 specific files if you search it for "D2".

[longfeng328]

saratoga,Thank you very much!

[saratoga]

It seems USB on the TCC chips is fairly well along, so hopefully with the datasheet and some debugging it can be made to work. 

[shotofadds]

It seems USB on the TCC chips is fairly well along, so hopefully with the datasheet and some debugging it can be made to work. 

It's been used for logf-over-usb and also to dump raw data from the NAND chips via UMS, but reliability is poor and frequently stalls or freezes the player. Unfortunately my knowledge of USB is zero, so I didn't ever look into it further.

Controlling/monitoring charging should be fairly straightforward as it is controlled by the power management chip, but there's a slight complication because we have to runtime-detect whether there is a PCF50606 or 50633 present. There's a datasheet available for both chips, so implementation should be straightforward enough.

Apologies I've been away for so long, but "real life" commitments are keeping me plenty busy enough at the moment.

Edited to add:

Looking at my D2 build, it seems IRAM isn't used for codecs.  Is there a reason for this?  I see its in the lds file.

When I first started the port, I did have IRAM working and used for codecs, but for some unknown reason performance was actually worse than without. It was never investigated fully, so IRAM remains disabled.

[funman]

Looking at my D2 build, it seems IRAM isn't used for codecs.  Is there a reason for this?  I see its in the lds file.

When I first started the port, I did have IRAM working and used for codecs, but for some unknown reason performance was actually worse than without. It was never investigated fully, so IRAM remains disabled.

Looking at crt0.S for D2, IRAM isn't cached or buffered.
s/1001aee0/1001aeec/ in tcc780x/crt0.S should do it.

btw would it be simpler to use map_section/ttb_init/enable_mmu functions from mmu-arm.S, rather than using the OF setup ?

[saratoga]

Looking at my D2 build, it seems IRAM isn't used for codecs.  Is there a reason for this?  I see its in the lds file.

When I first started the port, I did have IRAM working and used for codecs, but for some unknown reason performance was actually worse than without. It was never investigated fully, so IRAM remains disabled.

Looking at crt0.S for D2, IRAM isn't cached or buffered.
s/1001aee0/1001aeec/ in tcc780x/crt0.S should do it.

btw would it be simpler to use map_section/ttb_init/enable_mmu functions from mmu-arm.S, rather than using the OF setup ?

Enabling it would be nice, since I think its real SRAM on the D2.  You'll probably get a little bit of a battery boost. 

[shotofadds]

Looking at crt0.S for D2, IRAM isn't cached or buffered.
s/1001aee0/1001aeec/ in tcc780x/crt0.S should do it.

I had a couple of hours to get my dev box back up to speed tonight, and the results with IRAM and the above tweak are pretty good (if not earth-shattering). On a random sample of FLAC and MP3s I'm getting test_codec results about 10% faster than the figures on the CodecPerformanceComparison page - eg. FLAC is up to 2100%. I'll do some more conclusive testing later and get this committed (if it proves stable), since the improvement is definitely worth having.

btw would it be simpler to use map_section/ttb_init/enable_mmu functions from mmu-arm.S, rather than using the OF setup ?

Almost certainly. 

[shotofadds]

I've run test_codec several times over the full set of sample tracks with IRAM enabled and haven't run into any problems, so things appear to be stable. Improvements against the latest test on the CodecPerformanceComparison wiki (r25447, no IRAM) are:

AAC-HE +6%
Cook +14..16%
FLAC +7%
MP3 +7%
MPC +12%
AAC-LC +10..14%
Vorbis +13..17%
WMA +16%

APE/ALAC/WavPack are all more-or-less unchanged. I've attached the latest test_codec log to this post (tested using r26288 + IRAM).

Regarding battery life, I doubt even these improvements will make a lot of difference. There has been very little experimentation with power management / clocking changes / turning off outputs etc on this device, so I think codec performance is the least of our worries. 

Also, while doing the above tests I did (re)discover that both the core and the MPA codec (at least) will attempt to put things in IRAM sections even if USE_IRAM is undefined. This is the reason for the current .lds hacks for this CPU, and should really be put right as it causes undefined instruction errors in the case of the MPA codec.

EDIT: Looks like some hackery in mad_iram.h is responsible for the MPA codec putting things in .icode/.ibss when it shouldn't. Not sure I'm the best person to tackle that, though.

[longfeng328]

shotofadds,your attached file is empty... 

[shotofadds]

So it was. I've fixed it now.

[saratoga]

http://www.rockbox.org/wiki/CodecPerformanceComparison#Telechips_TCC7801_ARM926EJ_S

Updated.

[mbk1969]

Are binaries of "current build" built with that "IRAM"-optimization ?