Cowon D2

[shotofadds]

Jpeg resizing for album art seems to be messed up.
Take this 200px * 200px image, for example: http://rockbox.andrewbeveridge.co.uk/D2/cover.jpg

Rename to "cover.jpg", stick it in a folder with some tracks and play - it looks awful in the WPS compared to the same image in bitmap format: http://rockbox.andrewbeveridge.co.uk/D2/cover.bmp

Anybody have any light to shed on this?
I thought jpeg decoding was added to the core, so this wouldn't be a D2-specific thing, but after a brief chat on IRC it seems like it is.

The core JPEG decoder has specific optimisations for the ARMv5 architecture used by the D2, and I don't think any supported Rockbox targets use these. So it's entirely possible that this problem only shows up on the D2 at the moment.

Can you identify which build version the problem started with, or has it always happened since the core JPEG decoder was added?

@Arago:

Yours is the second report of a corrupted FS when using very small (16/32Mb) SD cards. I haven't looked at your dump yet (memcard.rar) but I suspect it is either FAT12 masquerading as FAT16 somehow, or the Rockbox FAT driver does not like very small FAT16 partitions (seems unlikely). I have a similar card here that I can use to investigate soon - this needs to either be fixed, or at the very least it should refuse to mount the card rather than destroy the FS.

----

Also a quick update: while on holiday I've been using Rockbox for music playback from a 4Gb SDHC almost every day: on planes, trains, and as the main stereo system in our apartment. The only real problem I noticed was a number of "Unknown instruction" exceptions, and in each case I think this happened when switching between different track formats (eg. from MP3 to FLAC). I guess it needs a cache flush or so when loading a new codec...

[saratoga]

Also a quick update: while on holiday I've been using Rockbox for music playback from a 4Gb SDHC almost every day: on planes, trains, and as the main stereo system in our apartment. The only real problem I noticed was a number of "Unknown instruction" exceptions, and in each case I think this happened when switching between different track formats (eg. from MP3 to FLAC). I guess it needs a cache flush or so when loading a new codec...

Sounds like the bug I fixed for AMS:

http://svn.rockbox.org/viewvc.cgi?view=rev;revision=21647

Are cpucache_flush and cpucache_invalidate defined for the D2?

[Arago]

I tried FAT12 - Rockbox doesn't see this card. I tried different sectors per cluster (32-16 - Rockbox doesn't see card, 8-1 - destroy it). I dd'ed 2gb card to 32mb - Rockbox is thinking some seconds after boot, but not destroy this very strange card! And also it show empty .rockbox directory (but reads config, localization, rockbox.d2 and skin from it during boot process). My Linux says that FAT: Filesystem panic (dev sdd1), File system has been set read-only; not my windows falls into a stupor at the sight of this card and advises to format it. Image of this card is here. Sorry for size, but i can't clean free space, if I try it on base card - dd'ed card is not booting, and dd'ed card is read-only FS.

[shotofadds]

Sounds like the bug I fixed for AMS:

http://svn.rockbox.org/viewvc.cgi?view=rev;revision=21647

Are cpucache_flush and cpucache_invalidate defined for the D2?

Thanks, I remember this being discussed, but I hadn't yet found the revision containing the change. Those functions are not yet implemented for TCC, so that's almost certainly the problem. The generic ARM versions should be fine, so it should be easy to fix when I find the time.

[shotofadds]

Jpeg resizing for album art seems to be messed up.

Fixed in 22577 (it was a typo in the ARMv5+ optimisations, as I suspected).

Lock pin is ignored by Rockbox

Sorry, I missed that when I read your post first time. That's definitely something that needs implementing, but I need to work out how to do it first (probably some GPIO pin). I'll have a look at the OF...

[helloworld1]

Have a good holiday!
I am looking forwards to the good news from you.

Also after massive searches, I also cannot find a datasheet of PCF506035 or PCF50607. Even the only datasheet of PCF50606 is from rockbox website. I will try to mail NXP semiconducts for the datasheet.

I have tried emailing NXP several time for the datasheet but no response at all. Maybe u can also have a try.

Some ipod also uses PCF506035 and works find with rockbox. I have found that they are linking against the pcf50605.c. Maybe you can investigate their works.

[shotofadds]

Some ipod also uses PCF506035 and works find with rockbox. I have found that they are linking against the pcf50605.c. Maybe you can investigate their works.

Well, I looked into that already. The 50605 is largely register-compatible with the 50606 (and also has the same I2C address iirc) so would probably work already. Given that the changes between D2+ firmwares x.02 and x.11 are to support a completely different power management chip, I would say that's a read herring.

Give me a bit of time to go through the firmware disassembly again, and I'll probably be able to make a test build for you that can enable the backlight/LCD - but I wouldn't really expect anything else to work.

Getting something displayed on the screen would be a good start though!

[Voluspa]

Since "r22594: D2: Move ACTION_WPS_STOP" I've experienced two complete shutdowns (with non-hacked svn code) while long pressing BUTTON_TOPRIGHT. That is quite a lot because I usually don't stop the music ;-) It's not a crash. Message on display is just "Shutting down..."

And speaking of erratic touchscreen behaviour, have you seen the ca 8 pixel area left/right of at least bottom and top middle 'buttons'? Pressing those pixels overrides usual scrolling restrictions (like delay) and eternally loops with gusto in the file list view. No stop at top or bottom.

I managed to expand that bug to the whole 'button' area by twiddling with the lines below 171 in firmware/target/arm/tcc780x/cowond2/button-cowond2.c Don't remember if it was through just setting line 178 to "send_touch = false;" or through copying the whole x/y checks down to the else statement at line 182.

It has nothing to do with "#define TOUCH_MARGIN 8" though. I've tried settings of 1 to 64 with little change...

Mvh Mats

[shotofadds]

And speaking of erratic touchscreen behaviour, have you seen the ca 8 pixel area left/right of at least bottom and top middle 'buttons'? Pressing those pixels overrides usual scrolling restrictions (like delay) and eternally loops with gusto in the file list view. No stop at top or bottom.

Hmm.. sounds like the button repeat mechanism isn't working correctly and you are seeing lots of single presses in a row instead. I'd guess this is because the raw data read from the touchscreen has a certain amount jitter, which we make pratically no attempt to correct for.

Have you seen/experimented with the test_touchscreen plugin (in apps/plugins/test_touchscreen.c - you'll need to add it to apps/plugins/SOURCES manually)?

Also, is it possible this started with r22314?

[Voluspa]

Sorry, this gigantic thread reveals that you saw it already at May 01, 2008 when the touchscreen got a separate driver:

http://forums.rockbox.org/index.php?&topic=10164.msg124107#msg124107
"This plugin has already shown up a couple of issues on the D2:

1) Touching on/near the 'line' between two areas causes jitter between the two adjacent rectangles. This causes a stream of distinct button presses."

JdGordon responded in the next message that:
"1) yeah, i noticed that also, i think we need to add a error margin around the joins, or something"

So, an ancient issue.

[fish]

@shotofadds
@helloworld1

I'v opend a bug to track this issue/new port:

http://www.rockbox.org/tracker/task/10607

[shotofadds]

^^ I'm not sure if that's the "correct" thing to do, since we don't normally allow bug reports for unreleased ports like the D2.

btw. The datasheet you linked is for the PCF50603, not the PCF50635 (check helloworld1's post here). And it's not a full datasheet anyway, since it doesn't contain any details of register addresses, etc.

Based on my disassembly of FW4.11 I can probably make a test build that turns on the screen/backlight, but I doubt very much that anything else will work... watch this space.

[fish]

Ok sorry. I hoped it would help you to track is there. So I will try to help you here

I'v googled a bit and stumbled about that:

https://electronics.wesrch.com/User_images/Pdf/16_1178305668.pdf

We de-potted the Philips part, revealing it to be a PCF50635, apparently a smaller version
of the PCF50607 used in the original nano

...and for that chip you have already some support, right? For the ipod nano?


amiconn suspects that the pcf50607 is a smaller version of the pcf50605:
http://www.rockbox.org/irc/log-20080311#21:12:28

That would make the PCF50635 = PCF50607 = PCF50605:

http://www.rockbox.org/wiki/pub/Main/DataSheets/pcf50606.pdf
http://svn.rockbox.org/viewvc.cgi/trunk/firmware/drivers/pcf50605.c?view=markup

[shotofadds]

If that's really true, Rockbox would already work on your D2+, and Cowon would not have needed to add support for an entirely new power management chip in the x.11+ firmwares.

I can see from the disassembly that every time a power management function is needed (eg. to turn on the backlight) a decision is made which results in calling code which either communicates with the PCF50606, or some new chip. I explained all this several posts ago...

[Toni]

I own a CowonD2+ with 4GB flash K9LBG08U0M. I have modified the ARM emulator to run the original CowonD2 code (4.59) for this flash type. The emulator supports some basic flash access emulation, basic lcd emulation, basic i2c emulation and rudimentary timer interrupt handling. It needs a complete dump of the flash for input. To keep the data clean, I bypass all flash write accesses into a different memory location. With this I come to the startup screen and can navigate between the menues. The code is still kind of hackish and compatible to MSVC6.0 only. If someone is interested, I have appended the code here (rename *.pdf to *.zip). The tool dumps all register and flash accesses and the latest (500000) executed instructions to files. Feel free to experiment with this but I will not have much time in the near future for any support.

Edit by karashata: removed attachment, moved it to CowanD2Info wiki page.