Rockbox Development > New Ports
Cowon D2
GMelchett:
--- Quote from: shotofadds on October 10, 2009, 11:18:41 AM ---
--- Quote from: GMelchett on October 09, 2009, 02:45:25 PM ---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.
--- End quote ---
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.
--- End quote ---
Yepp, the touchscreen doesn't work.
--- Quote from: shotofadds on October 10, 2009, 11:18:41 AM ---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)?
--- End quote ---
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 :)
--- Quote from: shotofadds on October 10, 2009, 11:18:41 AM ---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!
--- End quote ---
Good! I was just about to ask you for patches.
--- Quote from: shotofadds on October 10, 2009, 11:18:41 AM ---
--- Quote from: GMelchett on October 09, 2009, 02:45:25 PM ---I write Linux drivers on the same ARM architecture as the D2 got for a living.
--- End quote ---
Excellent, we need more people with low-level experience to get interested in this port! What sort of devices are you working with?
--- End quote ---
Custom made ASICs. Platforms for mobile phones.
--- Quote ---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.
--- End quote ---
Sounds like an good task to begin with. I'll begin with it tomorrow.
--- Quote ---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).
--- End quote ---
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.
--- Quote ---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)?
--- End quote ---
sounds resonable.
--- Quote ---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...!
--- End quote ---
Yes, definitly.
--- Quote ---EDIT: The above changes for PCF50635 support are now in SVN. Lots more work to do though! :-\
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version