Cowon D2

[GMelchett]

I'm not 100% sure that I got an D2+ with PCF50635. I bought the 16 GB variant a few days ago and it came with firmware 2.11 installed and my own built rockbox.bin (3.4.7) didn't work when loading it via tcctool.

However, all tests with provided binaries were executed successfully, except sound. It is very quiet.

That sounds very much like you have the hardware I'm talking about - thanks for testing it out. If that is the case, you will also find the touchscreen won't work because I haven't written the driver for it yet (although it's in progress). If the touchscreen works, you have the older hardware revision.

Yepp, the touchscreen doesn't work.

I'm a bit confused by the quiet sound - I'm not sure what would cause that. Can I ask you a really stupid question, just to check the obvious things like the volume settings and whether you have replaygain enabled? Also, does the FM radio work (is that quiet too)?

Well, booting your rockbox image was my first, no questions are stupid. And you are right,
some "replaygain" feature was enabled. When I switched it off, both audio and FM radio worked fine 

I've done a fair amount of work on it already to build the above test images, so I'll get those changes into SVN so you and/or others can test things out some more and try tweaking things yourself... help is always welcome!

Good! I was just about to ask you for patches.

I write Linux drivers on the same ARM architecture as the D2 got for a living.

Excellent, we need more people with low-level experience to get interested in this port! What sort of devices are you working with?

Custom made ASICs. Platforms for mobile phones.

I haven't had the chance to get the emulator working yet myself,

The EEPROM is mapped to an 8KB section of memory at 0xE0000000. You'll need to write some code to dump this from the player - either to SD card or via USB. Maybe ask Toni if he already has the code to do it?  Or you/I could write a plugin to do the job.

Sounds like an good task to begin with. I'll begin with it tomorrow.

Similarly the raw NAND flash needs to be dumped either to SD card (if you have a large enough card!) or over USB. Again some custom code will be needed to do this (dd isn't enough as that won't get you the raw NAND blocks / oob).

Just what I though. Hmm.. since I only have a 2 GB SD card, I need like 16 rounds with a plugin
that dumps out 1 GB+oobs each round. I think that several rounds will work since nobody is
modifying anything on the flash between external boots. (I would be suprised if the TCC chip
touches the flash when doing an external boot. If it does, it won't do wear-n-tear anyway.)
However, it would be much nicer to play around with a raw nand dump from a 2 GB D2.
Oh well, I start with the eeprom-dump plugin first.

I haven't looked at the code, but I assume wrdata.bin is a file that gets written to disk by the emulator  (containing NAND writes)?

sounds resonable.

What I might do is write a plugin that can dump all this stuff to SD card, and then get someone with a 2GB D2 to run it for us. That should make things a bit easier to handle...!

Yes, definitly.

EDIT: The above changes for PCF50635 support are now in SVN. Lots more work to do though!

Excellent. I will have a look.

[shotofadds]

I think you should be ok with multiple rounds, nothing is likely to modify the flash inbetween boots (and especially not if you use tcctool).

I did some earlier work like this using Rockbox's USB MSC interface (so I could dd whatever data I liked from the device by modifying the NAND driver appropriately). But that was rather a hacky approach, and the Rockbox USB stack is still too unreliable on Telechips devices. 

btw. I put some information on the wiki about how to read the touchscreen (gleaned from the Cowon firmware), if you feel like playing with that...

[GMelchett]

The eeprom-dump plugin was a piece of cake thanks to the plugin interface.

I guess I understood you wrong, since how to access the touchscreen sounded quite un-i2c-ish to me.
So I just tried to do multiple byte read at register 0x80h and 0x90 from slave 0x90. It works just fine.
Got X and Y in the scale from 0 to 0xFFFF where 0xFFFF is the bottom resp. left end.

I've added some code to button_cowond2.c but not yet got it to work.

I do wonder what chip that sits on address 0x90. But at the moment I'm not curious enough to open up my d2 and have a peak.

Edit: Got the touchscreen to work nicely. It is currently just a hack. @shotofadds: I guess you want a patch. How do you wish to get it "delivered"?

[shotofadds]

Hehe, yes that description does sound silly. But that's actually what the Cowon firmware does!  I will update the wiki to say that normal I2C reads work just fine (note, if you want to put any of your findings on the wiki yourself, you should go to the IRC channel and ask for access).

To submit patches, post them on Flyspray, our bug/patch tracker.  For copyright purposes all code submissions must be accompanied by a real name.

Although, how do we name a driver for a device we haven't yet identified? To keep things simple maybe move all of the touchscreen code from button-cowond2.c out to a separate file eg. touchscreen-cowond2.c, which deals with both types?

You should post the eeprom dumper too, then maybe we can extend it to dump other useful things as well. There's no reason why it shouldn't go in SVN (maybe disabled in plugins/SOURCES by default).

[GMelchett]

Weird. I wonder how any other device could work on the I2C bus if you can access "the touchscreen"-chip in that fashion.

I've added both the touchscreen patch and the eeprom dump on the tracker.

Adding a complete flash, including oob, dumping code would make the eeprom dumper more useful. Then someone might give us a nice 2 GB image.

Yes, we definitly need to break out the touchscreen code from button-cowond2. Looks quite hacky now with my code for the unknown-chip. For the moment, I think we should keep the code regarding
the unknown device in the touchscreen-cowond2 file. When we know what it is and/or we find some
other use of it, then we'll give it its own files.

By the way, does the name have to be unique? IE wonder about the cowond2 appendix.

I will have a look at if I can fix the clock. The date is correct but the clock says 00:00:00.

[shotofadds]

Weird. I wonder how any other device could work on the I2C bus if you can access "the touchscreen"-chip in that fashion.

I may have described it wrongly - a slave address is always sent, so other devices should just ignore the data that follows. It seems the Cowon firmware does something very strange:

- send slave address (0x90) followed by register address (0x80/0x90)
- send slave address (0x90) followed by two byte reads

whereas it could just:

- send slave address (0x90), followed by register address (0x80/0x90), followed by two byte reads.

But anyway, it doesn't seem to matter.

I've added both the touchscreen patch and the eeprom dump on the tracker.

Adding a complete flash, including oob, dumping code would make the eeprom dumper more useful. Then someone might give us a nice 2 GB image.

Thanks, I saw those and started making some comments. I will do some work on the dumper plugin...

By the way, does the name have to be unique? IE wonder about the cowond2 appendix.

No, it's not really necessary, but it's convention for those .c's in the target/ tree to have such a suffix.

I will have a look at if I can fix the clock. The date is correct but the clock says 00:00:00.

It can't be correct unless the date is coming from a file timestamp or some thing - the RTC is currently trying to read from the PCF50606 (check SVN shortly for a fix)

[helloworld1]

I need a volunteer... somebody who has a D2+ that currently does not work with Rockbox (ie. one with the updated power management chip - PCF50635).

Could you unzip this Rockbox build to the root of your D2 (or SD card), then upload this image using tcctool?  Then tell me:

a) if Rockbox boots
b) if the backlight works
c) if you can adjust the brightness in the General > Display > LCD settings menu
d) if battery voltage monitoring works (in the System > Debug menu)
e) if sound works

@grantmasterflash, I didn't see your update until now - glad you got your problem sorted in the end (and for pointing out how these kind of issues can be diagnosed). I wonder what caused that corruption....?

a. rockbox boots.
b. backlight works.
c. backlgiht brightness works.
d. Battery voltage starts out as 3.925(not correct( but after a while itis 4.098 and is correct.
e. sound works.
f. FM radio works, but the touchscreen is notworking so I cannot select the channel.

GREAT WORK!

[GMelchett]

It can't be correct unless the date is coming from a file timestamp or some thing - the RTC is currently trying to read from the PCF50606 (check SVN shortly for a fix)

@shotofadds: Your rtc patch definitely changed things. On the good side, the seconds are moving and there is a system time that moves at a approximately correct speed. However it says 09:37 when it should be 20:01. The system date says April 23 2005. The date was correct before your rtc patch.

Btw, I'm considering changing the touchscreen calibration code to calibrate two more spots, the (0,0) and (LCD_WIDTH, LCD_HEIGHT) for getting the correct hw values, not just my hardcoded ones.

[shotofadds]

You should find these things work in the main build now, so hopefully there's no need for you to download test images or use tcctool any more! The clock "might" work too, but no promises.

f. FM radio works, but the touchscreen is notworking so I cannot select the channel.

If you can compile your own builds, there is a patch at FS#10671 that implements the touchscreen driver. It still needs a bit of work, but shouldn't be too long before it's in the main build.

ps. it's normal for the battery voltage to start at a set value - it's an average reading and has to start somewhere that isn't zero!

[shotofadds]

@shotofadds: Your rtc patch definitely changed things. On the good side, the seconds are moving and there is a system time that moves at a approximately correct speed. However it says 09:37 when it should be 20:01. The system date says April 23 2005. The date was correct before your rtc patch.

The correct date can't have been read by the old driver, it was probably failing and using the build date as a fallback. The current build reads the correct fields from the PCF chip, but they appear to contain invalid data. What happens if you try to set the time in Rockbox? Does it persist (and does it affect what the Cowon firmware displays)? Maybe the stock firmware is using the TCC7801 RTC instead...

Btw, I'm considering changing the touchscreen calibration code to calibrate two more spots, the (0,0) and (LCD_WIDTH, LCD_HEIGHT) for getting the correct hw values, not just my hardcoded ones.

In theory only the three spots are needed - does it work at all if you remove your hard-coded scaling?

[GMelchett]

Ah, a build date. That fooled me.  Setting time in rockbox seems to work fine. It was there after a power-off-on cycle. When starting the original firmware, the date was in april 2014. The weird thing then was when I set the time+date back to the correct date+time with the original firmware, both rockbox and the firmware started to report the same date+time, the correct one.

I've updated my touchscreen patch in the tracker. I didn't update the touchscreen calibration code to calculate the hw parameters as well. Maybe it isn't needed.


Edit: After playing around with the unknown touchscreen chip, my guess is that it is an: TI TSC2003.
(http://focus.ti.com/docs/prod/folders/print/tsc2003.html)

[shotofadds]

Ah, a build date. That fooled me.  Setting time in rockbox seems to work fine. It was there after a power-off-on cycle. When starting the original firmware, the date was in april 2014. The weird thing then was when I set the time+date back to the correct date+time with the original firmware, both rockbox and the firmware started to report the same date+time, the correct one.

It's very strange, but that's what the PCF50606 version does too. I don't understand it, especially since the Cowon firmware seems to access the RTC registers in exactly the same way we do. Needs some further investigation.

Edit: After playing around with the unknown touchscreen chip, my guess is that it is an: TI TSC2003.
(http://focus.ti.com/docs/prod/folders/print/tsc2003.html)

Well spotted. I've had a look at some similar TI devices and no others seem to match except the more recent TSC2007 (which includes a built in median/windowed average filter) - this might be more likely since you reported very little jitter in the results.

http://focus.ti.com/lit/ds/symlink/tsc2007.pdf

[GMelchett]

Yes, indeed strange regarding the date+time.

I though I should try to figure out if any IRQ is connected to the touchscreen device.
Which IRQs are known? Any IRQs that are shared? Which are currently in use by drivers?
I've looked that the list in system-tcc780x.c, some I can guess what they are used for
some are not as clear.
@shotofadds: If you have a time, an IRQ list on the wiki would be welcome! Thanks!

[shotofadds]

Have a look at the TCC7801 datasheet (there was a link floating around here a while ago, if you can't find it I'll send you one if it still works). That'll tell you if an IRQ can be fired from C26. If not don't worry about it as the current implementation is fine.

As for current IRQ usage, I think we only care about TIMER0 (tick), DAI_TX (I2S) and EXT3 (PCF50606) at the moment, although that list is off the top of my head, so I could be wrong. Most are only listed for completeness, with a default "unhandled" handler.

I think we should be responding to the PCF50635 interrupts (it should be on EXT3 like the PCF50606), especially since it will give us an easy way to detect USB/charger insertion.

We're currently using C26 for that (since it worked on older hardware...) but clearly that isn't going to work if the GPIO is now used for the touchscreen.  Could you go into the Debug > HW info screen and see if any GPIOs change when you insert the AC adapter or USB cable?

[GMelchett]

There is a small flaw in last nights touchscreen patch. Since the "last_btn = btn" ended up inside if(tsc200x_is_pressed()) {} the latest button will be repeated on and on until you press somewhere else and that new button gets repeated on and on. IE the line must be outside the if.

I would really appreciate if you could mail me the tcc7801 datasheet. The link on the forum is dead, or rather Telechips now require a password for the files, and the datasheet is nowhere else to be found.

Thanks for the IRQ information. So there is no IRQ for key press/release. Also, finding out which IRQ that is connected to TSC2007 should be of interested. Although pulling works fine.

I tried many times to see if any GPIO pin changed in the "Hardware info" screen, but none did
when I inserted/removed the USB cable.