Cowon D2

[shotofadds]

I've been trying to reproduce some of these errors tonight, but I can't make anything go wrong using r27966 (or with r27822 as reported in FS#11558). My D2 boots properly each time, I have audio in both ears, and the database appears to work fine.

Can anyone point me to a rockbox.zip that exhibits any of these problems? I have no doubt that a problem still exists somewhere, but it's hard to track down when the symptoms don't show themselves...

[mbk1969]

I`ve met same problems with absent audio (and with audio in one channel) on my D2+. I do work around by loading original firmware and loading back to Rockbox. Build version is r27627. I can mail you the archive file with RB folder...

[shotofadds]

Thanks mbk1969. I tried your r27627 zip and got the "no audio" problem on the 2nd time I booted Rockbox, although it has worked properly every time after that (about 10-15 boots so far).

The strange thing was, on the "no audio" occasion I heard the usual pops and clicks on bootup and shutdown, so the audio outputs are definitely enabled. That suggests to me it might be something in the PCM driver rather than the audio hardware driver, and indeed there was a change in that area in r26253. This sounds ominous:

Everything checks out on supported targets. There wer some compat changes I can't check out on many unsupoorted but if there's a problem it will be a minor oops.

I will check through that code with a fine-toothed comb and get back to you...

NOTE: I haven't seen any black screens or failures to boot up in this build - that is clearly a different problem and will need more investigation.

[shotofadds]

Looking at that PCM change, the driver code changes look sane and in any case the change was made a long time before anyone started reporting issues. And it wouldn't explain muting in one ear only, so I think we can rule that one out.

So... the finger points at EABI again. To try and identify if this is the cause or not I have built two versions of r28000, one without EABI and one with.

Please could everyone who has seen these issues try both versions for a few days and report back for each version:

 a) how many times you have booted it
 b) how many times audio was missing in one or both ears
 c) how many times you got a black screen or freeze on bootup

Version 1: http://www.megaupload.com/?d=41QHGF6S
Version 2: http://www.megaupload.com/?d=CAYFO7X0

[mbk1969]

Results for version 1:
- first load - OK ;
- second load - audio absent ;
- third load - audio only in one channel ;
- fourth load - OK...

Installing version 2...

Results for version 2:
- no failure at all for at least 20 attempts.

[shotofadds]

Can you guess which version was built with the --no-eabi option? 

Now we "just" need to track down the bug, wherever it may be. I fixed some delay loops that got optimised out by the EABI compiler a few months ago, and at the time I verified that the generated code was the same for both compilers. So those shouldn't be the problem.

At least in the meantime people can use the Version 2 link above for a nice new working version of r28000...

[mbk1969]

Yeah, no need to guess. -)


For me it is strange thing - to optimize drivers code. Codecs - may be, but drivers...

[funman]

Here "optimized out" means "removed completely by compiler"

Optimizing drivers (with gcc -O options) is necessary I think, the difference between -O0 (no optimizations at all) and -O (a few optimizations) can be quite big in terms of performance and size.

[mbk1969]

Optimizing drivers (with gcc -O options) is necessary I think, the difference between -O0 (no optimizations at all) and -O (a few optimizations) can be quite big in terms of performance and size.

Definitely, but arn`t stability and predictability more valueable and preferable things for a driver (then perfomance and size)? I mean the code for D2 built without EABI was able to steer the device, and then came EABI and the new code gains more perfomance and less size but also unstability...

[saratoga]

Definitely, but arn`t stability and predictability more valueable and preferable things for a driver (then perfomance and size)? I mean the code for D2 built without EABI was able to steer the device, and then came EABI and the new code gains more perfomance and less size but also unstability...

We didn't switch to EABI because it optimizes better for the D2.  We switched because we wanted all ARM devices using the same compiler.  Discussing what is "more valuable" for a specific port doesn't really make sense since this isn't about the D2 specifically.

[Bkd11]

Hey shotofadds,

Would you mind posting a patch/diff of your r28000 non-eabi build? That way I can update the 'Buttons in Hold Mode' builds with "stable" builds. I tried just reverting r27123 a while ago but that obviously didn't work. 

Thanks in advance.

[mbk1969]

Look, guys... If it sounds like a blame then I failed to deliver my point of view. I only dare suggest (to shotofadds) that it could be easier to disable optimization for driver type of sources (in make files or in sources themselves by pragmas) and forget about such things as `optimized` timeout loops. Such step could eliminate dependency of functionality (operability) from compilers intrinsic  implementations/differences.
I did not touch the compiler choice at all.

[funman]

@Bkd11 : just use tools/configure --no-eabi , no patch needed.

@mbk1969 : disabling optimizations for the whole rockbox build (i.e. using -O0) is:

• Impossible (won't build at all), at least without some modifications, because gcc can't figure some very basic stuff (can't use "i" constraint in disable_irq() for example)
• A very bad idea because rockbox will be both much bigger and much slower

Using -O0 *manually* on individual files is a good idea though it could help figuring out the problem.

Just run make V=1 to see the full gcc command line, and paste it with -O option changed to -O0, it might work with more or less modifications needed without making rockbox too much slow/fat.

EDIT: i don't think gcc support changing optimizations or other parameters through pragmas but if you know how i'd like to know

[Bkd11]

@Bkd11 : just use tools/configure --no-eabi , no patch needed.

Thanks 

Edit: Unfortunately I get a bunch of errors that I don't get when I do a normal ../tools/configure

Code: [Select]

/home/brian/rockbox/apps/dsp_arm.S: Assembler messages:
/home/brian/rockbox/apps/dsp_arm.S:53: Error: bad instruction `ldmpc cond=lt,regs=r4'
/home/brian/rockbox/apps/dsp_arm.S:63: Error: bad instruction `ldmpc regs=r4'
/home/brian/rockbox/apps/dsp_arm.S:118: Error: bad instruction `ldmpc cond=lt,regs=r4-r10'
/home/brian/rockbox/apps/dsp_arm.S:137: Error: bad instruction `ldmpc regs=r4-r10'
/home/brian/rockbox/apps/dsp_arm.S:170: Error: bad instruction `ldmpc cond=lt,regs=r4'
/home/brian/rockbox/apps/dsp_arm.S:181: Error: bad instruction `ldmpc regs=r4'
/home/brian/rockbox/apps/dsp_arm.S:231: Error: bad instruction `ldmpc cond=lt,regs=r4-r6'
/home/brian/rockbox/apps/dsp_arm.S:245: Error: bad instruction `ldmpc regs=r4-r6'
/home/brian/rockbox/apps/dsp_arm.S:308: Error: bad instruction `ldmpc cond=lt,regs=r4-r9'
/home/brian/rockbox/apps/dsp_arm.S:330: Error: bad instruction `ldmpc regs=r4-r9'
/home/brian/rockbox/apps/dsp_arm.S:393: Error: bad instruction `ldmpc regs=r4-r11'
/home/brian/rockbox/apps/dsp_arm.S:450: Error: bad instruction `ldmpc regs=r4-r11'
/home/brian/rockbox/apps/dsp_arm.S:513: Error: bad instruction `ldmpc regs=r4-r11'
/home/brian/rockbox/apps/dsp_arm.S:560: Error: bad instruction `ldmpc regs=r4-r8'

[funman]

Probably too old binutils which don't support the gas macros?

Which version of arm-elf-as do you have? rockboxdev.sh should install 2.16.1