Cowon D2

[Tigerite]

I tried to follow the manual instructions at http://www.rockbox.org/wiki/CrossCompiler but binutils wouldn't build, I had a stack trace error. Mind you, those look pretty out of date, so maybe using a previous version of the shell script is a better option - I'll have another bash at it.

Ideally, I'd like to find out what is causing the EABI build to have the problems, as I think long-term it's got to be the better solution, but I don't really know where to start on that..

[saratoga]

The  pre eabi version of roxkboxdev.sh should work fine. We all used it back in those days.

[Tigerite]

Well, I got binutils to compile but gcc is another matter, as http://www.rockbox.org/gcc/rockbox-multilibs-arm-elf-gcc-4.0.3_3.diff seems to no longer exist.. does anyone happen to have a copy? Google threw up a blank, I'm afraid..

EDIT: Never mind, found it in the tracker: http://www.rockbox.org/tracker/task/10436?getfile=20040

[bluebrother]

The patches are also available in the www git repository: http://git.rockbox.org/?p=www.git;a=tree;f=gcc

Looks like version 3 of that patch was forgotten though (which is a bit strange if rockboxdev.sh used it)

[Tigerite]

Thanks for all the help, I managed to get the latest rockbox to compile with --no-eabi! I had to change lib/rbcodec/dsp/eq.c slightly though as gcc 4.0.3 is fussier than 4.4.4 - it was giving me an "initializer element is not constant" error. Does the below seem sane, I've never been too hot when it comes to C++ pointers?

Code: [Select]

--- a/orig/rockbox/lib/rbcodec/dsp/eq.c
+++ b/dev/rockbox/lib/rbcodec/dsp/eq.c
@@ -75,9 +75,9 @@ void dsp_set_eq_coefs(int band, const struct eq_band_setting *setting)
                                                  unsigned long Q, long db,
                                                  struct dsp_filter *f) =
     {
-        [0]                    = filter_ls_coefs,
-        [1 ... EQ_NUM_BANDS-2] = filter_pk_coefs,
-        [EQ_NUM_BANDS-1]       = filter_hs_coefs,
+        [0]                    = &filter_ls_coefs,
+        [1 ... EQ_NUM_BANDS-2] = &filter_pk_coefs,
+        [EQ_NUM_BANDS-1]       = &filter_hs_coefs
     };
 
     if (band < 0 || band >= EQ_NUM_BANDS)
@@ -98,8 +98,8 @@ void dsp_set_eq_coefs(int band, const struct eq_band_setting *setting)
 
         /* Convert user settings to format required by coef generator
            functions */
-        coef_gen[band](0xffffffff / NATIVE_FREQUENCY * setting->cutoff,
-                       setting->q ?: 1, setting->gain, filter);
+        (*coef_gen[band])(0xffffffff / NATIVE_FREQUENCY * setting->cutoff,
+                          setting->q ?: 1, setting->gain, filter);
     }
 
     if (mask == eq_data.enabled)

I believe the last change isn't strictly needed, as the compiler should figure it out anyway, but I decided to err on the side of caution (and clarity)..

[Tigerite]

I spoke too soon.. although the firmware compiles fine under 4.0.3 and binutils 2.16.1, the codecs don't; libtremor has lsl instructions which 2.16.1 doesn't like. I tried instead to use 2.20.1 but that causes problems in mod.c with "relocation truncated to fit: R_ARM_PC24" errors. So now I'm a bit stuck really..

[saratoga]

What was compiling a current build with the old compiler going to accomplish exactly?  I don't see that its really worthwhile if you're trying to troubleshoot a problem in the audio driver. 

[Tigerite]

My reasoning was that, back on page 59, shotofadds managed to fix the problem of audio either not working or only coming through one channel (and that's with a much older release than the current) by building with the --no-eabi option. The problem is that this issue only happens intermittently - and it's still occurring with the firmware built with the older gcc and binutils, so it must be something in the codecs. If it was every time then I'd have at least a fighting chance of finding the problem..

[saratoga]

My reasoning was that, back on page 59, shotofadds managed to fix the problem of audio either not working or only coming through one channel (and that's with a much older release than the current) by building with the --no-eabi option.

Yeah, but once you got that to compile, how would that help you actually solve the problem?

[phr]

I'm glad to see renewed interest in the D2 port.  The D2 is really excellent hardware and crappy OEM firmware.  It's compact, has good audio, long battery life, relatively easily replaceable battery, and a full sized SD slot that's known to accept 128GB SDXC cards (though there is apparently some trouble using them with rockbox).  This feature has gotten more interesting very recently, with the introduction of 256GB cards from Lexar (available from bhphoto.com though very expensive, at least for now).  I still use my D2 regularly.

[v0rtex99]

Hello All,
Not sure if this is the correct place to discuss new features for Rockbox on the D2, but I have an addition that would really make my day. I have two D2+ players and I would like to use one with my home stereo as my full time music player. For this to work easily I would like to have the player plugged into a USB power adapter all the time so I don't have to worry about it being charged. The only catch with the way Rockbox works on the D2+ now is that the player can't be turned off when charging. So on to my question, would it be possible to enable turing off the player while using Rockbox and charging?
Thanks so much!

[saratoga]

Probably not.

[[Saint]]

It would be fairly trivial to wire a USB cable with a switch on the power lines. That would work for your uses if I understand correctly.
Then, you could also use the car adapter mode which automatically pauses playback and shuts down after the idle timeout period when no power is detected, and wakes the device and resumes playback when power is detected.

This seems like it would be a good, albeit fairly hacky, semi-solution (obviously the device will only be charging when it's on, as opposed to full-time, but this should be sufficient as long as the USB port is providing the full 500mAh) to your problem.


[Saint]

EDIT: If you wanted to get really geeky, there are in-line switches out there that can take input from a programmable IR remote.
*EDIT 2: Bums... it seems car adapter mode functions from DC alone, and not USB.

[phr]

If anyone cares, a new version of the D2 has been announced, called the D20.  It may be different enough internally to not be able to run the D2 Rockbox port, but it looks similar on the outside.  Some info is here and there is also an anythingbutipods thread:

http://iaudiophile.net/forums/showthread.php?t=41643

[niggle]

Hi everybody!
Is anyone with this problem since one year maybe??

It makes me very unhappy not be enjoying the last builds...
Please help!

Cheers!