Cowon D2

[Bkd11]

Well this might not be the proper forum to continue this discussion, but I ran tools/rockboxdev.sh selecting all options.

Then preceeded with tools/configure --no-eabi  as you instructed.

Code: [Select]

Normal build selected
Using source code root directory: /home/brian/rockbox
Using arm-elf-gcc 4.0.3 (400)
Using arm-elf-ld 2.16.1

But still received same errors as in my post above. 

[mbk1969]

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

http://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html
:
#pragma GCC optimize ("string"...)
This pragma allows you to set global optimization options for functions defined later in the source file. One or more strings can be specified. Each function that is defined after this point will be as if attribute((optimize("STRING"))) was specified for that function. The parenthesis around the options is optional. See Function Attributes, for more information about the optimize attribute and the attribute syntax.

The `#pragma GCC optimize' pragma is not implemented in GCC versions earlier than 4.4.

http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes
:
optimize
The optimize attribute is used to specify that a function is to be compiled with different optimization options than specified on the command line. Arguments can either be numbers or strings. Numbers are assumed to be an optimization level. Strings that begin with O are assumed to be an optimization option, while other options are assumed to be used with a -f prefix. You can also use the `#pragma GCC optimize' pragma to set the optimization options that affect more than one function. See Function Specific Option Pragmas, for details about the `#pragma GCC optimize' pragma.

This can be used for instance to have frequently executed functions compiled with more aggressive optimization options that produce faster and larger code, while other functions can be called with less aggressive options.

http://gcc.gnu.org/onlinedocs/gcc/ARM-Pragmas.html#ARM-Pragmas

[torne]

Yes, it's possible, but the point you are missing is that GCC with no optimisations produces *spectacularly* wasteful code, since it doesn't generally bother to even keep local variables in registers... -O0 even for what you consider to be not-performance-critical code will generally turn out to be super slow...

[shotofadds]

There's also no point in adding #pragmas to individual files, because once you have figured out which file(s) to change, you might as well solve the problem properly rather than working around it. Don't fret, it will get fixed soon enough.

Also note, the D2 build no longer works "out of the box" with the --no-eabi option (for a different reason to without Bkd11's errors): you also need to disable use of IRAM in apps/codecs/libmad/mad_iram.h.

[AsusFreak]

Hi all.

By the way: an old problem came back I think:
r28058 does not start anymore. Only the bootloader is shown then i get the blackscreen and have to wait some minutes before being able to boot into OF.
We had a same issue some weeks ago (see closed FS#11558).
My last actual working build is r28051.

See FS#11618:
http://www.rockbox.org/tracker/task/11618

[mneedes]

(NEVERMIND... I just found it.  It is in an assembly language file, LOL.  firmware/target/arm/tcc780x/crt0.S)

The telechips bootloader used by the D2 is different from several other bootloaders (e.g.: ipod bootloader) in that it doesn't poll the HOLD button in its main() entry point (bootloader/telechips.c).  My question is WHERE is the source code that polls the HOLD button for the D2 ?

(NEVERMIND... I just found it.  It is in an assembly language file, LOL.  firmware/target/arm/tcc780x/crt0.S)

Thanks!
Matt

[shotofadds]

r28058 does not start anymore. Only the bootloader is shown then i get the blackscreen and have to wait some minutes before being able to boot into OF.
We had a same issue some weeks ago (see closed FS#11558).
My last actual working build is r28051.

I can re-create this problem here, and it looks like r28054 triggered it (r28051,52,53 all work correctly for me). It seems to be a code alignment problem, since inserting 3 NOPs into main.c makes the problem go away, at least temporarily. But I don't understand why we haven't hit this problem any time in the past 3 years...

Leave it with me a while longer and I'll find a proper fix.

I've also spotted a potential cause of the missing audio channels - but I need to do some more testing to confirm it.

EDIT: It's the MCFG |= 1 line in system-tcc780x.c that causes the black screens in some builds. I'm trying to work out whether this is even needed at all, but can't for the life of me work out why this hasn't been a problem before.

[AsusFreak]

I can re-create this problem here, and it looks like r28054 triggered it (r28051,52,53 all work correctly for me). It seems to be a code alignment problem, since inserting 3 NOPs into main.c makes the problem go away, at least temporarily. But I don't understand why we haven't hit this problem any time in the past 3 years...

Leave it with me a while longer and I'll find a proper fix.

Thanks for taking care of it, shotofadds.

Edit:
r28078 is starting correctly again. I do not know what causes the right booting now but it rocks again - hooray!

So for me the last point's not working is the aspect of redrawing conditionals with timing but this is a minor point...

[shotofadds]

r28078 is starting correctly again. I do not know what causes the right booting now but it rocks again - hooray!

I can 100% guarantee that this is temporary, it'll stop working again in a few builds time. I can put in a temporary fix, but to solve it permanently I need to better understand why this has only just started happening after nealry 3 years of working builds...

EDIT: I've been working on this some more tonight and have come to the conclusion that this whole area in system-tcc780x.c smells fishy. It claims to "do with the OF does", but that's not quite true. The OF runs this code before the ARM caches have been enabled, whereas we run it with the caches enabled.

Lo and behold, if I disable the data cache before running this code the problem goes away.... so it looks like I have found a workaround (though I still need to test this works in bootloader builds before I can commit a "fix"). This whole area is in need of some  tidying up and further investigation as to what the code is actually doing, though.

[motorbit]

The OF runs this code before the ARM caches have been enabledif

if I disable the data cache before running this code the problem goes away.... so it looks like I have found a workaround

workaround? to me* it rather sounds as if you found the surce and a proper fix to the problems we faced with some of the later builds.

nice work



*me no know nothing about this code^^

[funman]

BTW would replacing the MMU setup in crt0.S by calls to mmu-armv4.S help debug this?

(with respect to caches)

[Alex_Nsk]

Hi! Is there are anybody who really knows in what formats audio data is transfered into the codec from SoC Telechip? Right now I'm trying to use more audiophile version of DAC with D2+ DAP. Just cant establish connection in both I2S and Left justified/right justified 16/24 bit formats. There is or digital noise or very very quiet sound in most lucky case...Is there are DSP/PCM mode??? Is it could be changed by rockbox software??

[saratoga]

Hi! Is there are anybody who really knows in what formats audio data is transfered into the codec from SoC Telechip? Right now I'm trying to use more audiophile version of DAC with D2+ DAP. Just cant establish connection in both I2S and Left justified 16/18/20/24 bit formats. There is or digital noise or very very quiet sound in most lucky case...Is there are right justified standart???

According to the WM8985 datasheet, it supports all of those formats, see the "device description" chapter, and register 0x04 specifically.

[BurntOfferings]

Hello there! can I an any way help with getting Line-in working? That feature is really important for me, but I have no clue where to start... I'm not a total newbie in programming, but I have no clue how reverse-engineering a firmware is done. Nonetheless, I'll try my best to get that working

[preglow]

Hello there! can I an any way help with getting Line-in working? That feature is really important for me, but I have no clue where to start... I'm not a total newbie in programming, but I have no clue how reverse-engineering a firmware is done. Nonetheless, I'll try my best to get that working

I'm actually kinda working on this at the moment. Line in seems to be what is connected to the audio interface by default, so it should just be a matter of configuring the 7801 correctly and writing interrupt handlers. Making the builtin mic work will require some disassembly work to figure out where the input select multiplexer is connected.