Cowon D2

[RockBoxy]

I'm not a programmer myself but may I ask you guys a question?

I'm really interested in the wavpack lossles recording function for my cowon D2+.

Do you think there is a chance the voice record function will be ready soon?
If not would someone be so kind to start working on this function?

[BasculeTheFule]

Hi.

I have just bought what I am guessing is one of the last new Cowon D2+ to be had in the UK.

I've been using an X5 and latterly an X5L with Rockbox for some time and had forgotten how frustrating the default Cowon UI can be.

I'd like to Rockbox the D2+ but note that the D2 port is currently unstable. Given that the D2 seems to be making way for the D3, what are the chances of the port progressing to a stable state and further developed?

Also, just how usable is the unstable build, and is there any risk associated with installing it at this point? Is it correct that I will need to get an SD card if I want to be able to save any changes I make to Rockbox (should I install it) at this point?

Cheers,

BTF

[shotofadds]

I'd like to Rockbox the D2+ but note that the D2 port is currently unstable. Given that the D2 seems to be making way for the D3, what are the chances of the port progressing to a stable state and further developed?

Also, just how usable is the unstable build, and is there any risk associated with installing it at this point? Is it correct that I will need to get an SD card if I want to be able to save any changes I make to Rockbox (should I install it) at this point?

Unfortunately the D2/D2+ port has reached a bit of a dead-end, as there is really only one developer (me) involved in the port, and it works "well enough" for me as it is. Since no-one else seems to be interested in developing it, this is where it will stay for the time being. All the good work done by the rest of the Rockbox team will still be built into the D2 port, but there might not be any D2-specific updates for a while.
 
Having said that, the port is quite usable in its current state (especially if you download one of the designed-for-touchscreen themes from the themes site). "Unstable" just means that some significant features are missing, it doesn't mean that the player is unstable while running Rockbox.

And yes, the recommended way to run the D2 port at the moment is to install Rockbox to an SD card - you will need this to save settings/playlists etc as Rockbox can only access the internal memory in read-only mode.

I hope that helps, and you aren't scared off trying Rockbox by the "unstable" tag. If you have any trouble there are some very helpful people around here or at the iAudiophile forums. 

[BasculeTheFule]

Thanks for the update!

I had a feeling the project might have ground to a halt, hence the post.

I am waiting for an SD card to arrive in the post and will load up Rockbox just as soon as it gets here in the hope that it does a better job than the 2.13 firmware I currently have installed!

I was thinking about selling my X5L, but to be honest would have to think twice about that if it meant being stuck with the Cowon UI on the D2+.

Cheers,

BTF

[cowonoid]

I am curious: there were so many hours and days of work spent on backwards-engineering the D2 by disassembling the firmware;
wouldn't it be more effective to find out about the exact shematic? Look for some defect D2s or buy one (everyone interested spents a few $) or even use the own one cautiously and disassemble it (like the guys from anythingbutipod)? Measure each pin of a chip with an ohmeter and look where it is connected to and during that tipping the information into Eagle layout designer?

With the shematic and the datasheets one could do the greatest things! Even get more out of the hardware than Cowon does (f.e. unused ports of ICs). The "rockbox module" could then be built on a platform, which has the most basic controls over the hardware and is not driven by pieces of disassembled code (which is maybe the reason for annoying "bugs" like just 20% of battery life).

Knowing all the hardware and how it is connected would give a feeling like I build the whole device myself. That would contribute to motivation and speed of development.

I mean: this device is really nice! With a better firmware than the original one I probably would use it for the next 40 years without getting tired of it (buying 2 more now for spare .

Wouldn't it be worth it to get fully familiar with all the devices structure? I even guess, that doing that from the beginning would have spared time.


Or am I wrong?

[torne]

wouldn't it be more effective to find out about the exact shematic? Look for some defect D2s or buy one (everyone interested spents a few $) or even use the own one cautiously and disassemble it (like the guys from anythingbutipod)? Measure each pin of a chip with an ohmeter and look where it is connected to and during that tipping the information into Eagle layout designer?

Not really, for several reasons:
1) Not every component in a given player has a public datasheet, or can even be identified at all. It doesn't help to know how something is connected if you don't know what it *is*.
2) Most connections are obvious and boring (e.g. buses), there's no need to figure most things out this way at all.
3) Testing with an ohmmeter doesn't actually guarantee there's a plain trace between two things.
4) You have to basically destroy the player to be able to get anything like a full picture, since there's no other way to get to the contacts of a BGA package
5) It's really time-consuming and tedious. It's not at all guaranteed to be faster than disassembling the firmware...

Occasionally it's useful to know how certain things are connected (e.g. GPIOs that have no obvious function) and someone will investigate the hardware, but generally a schematic would add little value, and it's really not as easy to produce one as you suggest.

[saratoga]

I am curious: there were so many hours and days of work spent on backwards-engineering the D2 by disassembling the firmware;
wouldn't it be more effective to find out about the exact shematic? Look for some defect D2s or buy one (everyone interested spents a few $) or even use the own one cautiously and disassemble it (like the guys from anythingbutipod)? Measure each pin of a chip with an ohmeter and look where it is connected to and during that tipping the information into Eagle layout designer?

About 99% of the interesting stuff is all on the main system on a chip, so the traces wouldn't tell you much.

[cowonoid]

1) Not every component in a given player has a public datasheet, or can even be identified at all. It doesn't help to know how something is connected if you don't know what it *is*.

For sure. However, every part of the D2 seems to be identified and there was a time at which even the TCC7801 datasheet was available to the public (and for some people it probably still is)

3) Testing with an ohmmeter doesn't actually guarantee there's a plain trace between two things.

Then an oscilloscope and applied AC to the contacts. There surely is a way to check on physical connection.

4) You have to basically destroy the player to be able to get anything like a full picture, since there's no other way to get to the contacts of a BGA package

If I have the datasheet and thus the PIN descriptions and locations; couldn't I guess the traces? (the traces must leave the chip somewhere)

5) It's really time-consuming and tedious. It's not at all guaranteed to be faster than disassembling the firmware...

Occasionally it's useful to know how certain things are connected (e.g. GPIOs that have no obvious function) and someone will investigate the hardware, but generally a schematic would add little value, and it's really not as easy to produce one as you suggest.

Probably it would be much work, but with a different result than disassembling the firmware: you would know the whole architecture and could build up your own rockbox low-level firmware, which has nothing todo with the original one.

About 99% of the interesting stuff is all on the main system on a chip, so the traces wouldn't tell you much.

You mean, it's in the software for the TCC processor? With rockbox all the original soundprocessing software is screwed up anyway, isn't it?

What I mean is: there are people in this forum speaking about building an own DAP dedicated for rockbox (which is amazing!)
What would be the difference between this player and the D2? Isn't it, that you know every connection and the intention of every single part?

[saratoga]

You mean, it's in the software for the TCC processor?

Hardware and software.  What I'm saying is theres very little of the player on the board.  Most of it is inside a single chip.  Finding traces doesn't help if nothing of importance uses traces. 

What I mean is: there are people in this forum speaking about building an own DAP dedicated for rockbox (which is amazing!)
What would be the difference between this player and the D2? Isn't it, that you know every connection and the intention of every single part?

You pick parts that are all well documented, and then you don't bother with ones that would require reverse engineering software (like the D2's flash translation layer).

[peaceful1]

guys in the last few weeks I cant use new rockbox builts, mostly they don't boot any more, can anyone give me a clue what to do ?!

[mc2739]

guys in the last few weeks I cant use new rockbox builts, mostly they don't boot any more, can anyone give me a clue what to do ?!

This problem was reported on the bug tracker: FS#11558

But it was reported to be fixed as of build r27864 and the task was closed.  Please try the latest build to see if the problem has indeed been resolved.

[shotofadds]

There's no reason why this behaviour would have changed between r27860 and r27864, so the problem is not "fixed" - it's just not manifesting itself at the moment.  r27646 did change some drivers, but the code changes are trivial and won't have caused the problem.

I think these kind of issues started happening intermittently after the build was switched to the EABI compiler - I've also seen reports of strange things like one or both earphones sometimes not having any sound.

But at the moment I don't have the time to investigate and fix it, unfortunately.

[peaceful1]

There's no reason why this behaviour would have changed between r27860 and r27864, so the problem is not "fixed" - it's just not manifesting itself at the moment.  r27646 did change some drivers, but the code changes are trivial and won't have caused the problem.

I think these kind of issues started happening intermittently after the build was switched to the EABI compiler - I've also seen reports of strange things like one or both earphones sometimes not having any sound.

But at the moment I don't have the time to investigate and fix it, unfortunately.

Well shotofadds, it’s not important we all can use the old builts ,I just thought it’s good to say the details happening that’s all. We all appreciate all you did for D2 I personally don’t see any need of more development it does all we need.
Thanks again.

[funman]

But at the moment I don't have the time to investigate and fix it, unfortunately.

Do you know at which point / in which driver it fails?

Perhaps developers who don't have a D2 could give a hand on this.

[Bkd11]

Do you know at which point / in which driver it fails?

For me the problems started at r27123. Like shotofadds said, right after the EABI was enabled. I've seen various intermittent problems. I think andrewthecoder over at http://iaudiophile.net//forums/showthread.php?t=37064&page=2 described the most common ones best, so here is a quote from him.

Revision 27090 is what I'm using, and have been using since whenever it was it was committed.
I've tried various times to update to newer builds, but I've intermittently experienced one of the following:
1) Freezing on a black (but backlight on) screen immediately after the bootloader
2) Muted audio, despite all functions seemingly working fine
3) Audio heavily panned to one channel, output volume lower than usual

Usually hard-resetting (holding power switch for 10 seconds), then switching on again worked to get it to boot normally, but sometimes it would require several of these reset cycles before it would work, "several" ranging from 1 to 20.
This frustrated me enough to revert to an older build, in my case 27090.

Building the database also seems to cause it to freeze/lockup in my experience. There have been a few times I actually had to delete all the database files from the .rockbox folder on my sd card just to get it to boot again.

I've been happily running rockbox on my d2 for over 2 years now and haven't experienced these specific problems until after r27123.