Cowon D2

[shotofadds]

Thanks, that's very helpful. The ID codes show that:

a) the 8Gb D2 is comprised of 2 banks of 4Gb flash (since 2/3 are replicated), rather than the 4 banks of 2Gb I was half expecting.

b) but we know the reading code still partially works, since you managed to display some tag information.

The ID codes suggest the 8Gb contains 2x SAMSUNG K9LBG08UOM, which at first glance seems to have the same characterstics as mine except each page is 4Kb in size rather than 2Kb. I'll update the wiki with this information later.

More reports from other D2s are welcome... but please PM them to me to avoid cluttering the forum, thanks.

[linuxstb]

Nice work on getting the NAND working - I'm looking forward to having the time to try porting your code to the TCC77x.

Regarding the block translation, have you looked at the NAND driver for the iFP7xx port?  IIUC, this does something similar, so may be of help/inspiration.  It's in firmware/drivers/ata_flash.c

[shotofadds]

I've looked at the iFP7xx code briefly, but not in much detail yet. My task for the next week is to establish how the OF block translation works, so I don't yet know how similar it may turn out to be.

I also need to update the existing code to detect the different chips used in the 2/4/8Gb models and adjust for the different page sizes, but that should be fairly trivial.

[Voluspa]

More reports from other D2s are welcome... but please PM them to me to avoid cluttering the forum, thanks.

I'm not allowed to PM (too new a user?) but my test confirms andiator's. On a European 8Gb player - Sweden, bought last week, came with 2.51 FW - bank 0 is mirrored on bank 2 and bank 1 on bank 3. The NAND IDs are the same as andiator's as well.

Pressing a button while running rockbox/build/bootloader/bootloader.bin started a memory count (check ?) during which I could make coffee ;-) After ca 10 minutes - the count stopped at 2Gb or so - some dumps were showed when pressing buttons. Then came the "Helo world" screen.

A note regarding tcctool:

I'm always using fresh kernels in linux but tcctool relies on an old technique being present.  So to make it work one has to compile the kernel with this checked:

Device Drivers ->

• USB support ->
• USB device class-devices (DEPRECATED)[...]
  This option provides backward compatibility for libusb device nodes
  (lsusb) when usbfs is not used, and [...]
  
  And furthermore, the /proc interface is completely gone even with this checked:
  
  root@sleipner:~# uname -a
  Linux sleipner 2.6.24 #1 PREEMPT Sat Jan 26 21:46:22 CET 2008 x86_64 GNU/Linux
  root@sleipner:~# lsusb -t
  cannot open /proc/bus/usb/devices, No such file or directory (2)
  
  Mvh
  Mats J
  

[Yeeze]

I looked through the I2c code, that is used to receive input from the touchscreen, and noticed that it only receives the x and y position of the "cursor", my question is, is it possible to receive an array of  all actually touched spots on the screen?
Because when I for example touch the screen with two fingers, the position of the "cursor" is in between the two spots I touched...
It would be very convenient, but my guess is it will be very time consuming... But if it is possible it would be nice... Does anybody know?

[andiator]

It seems like D2's touchpanel and PCF50606 are not multitouch able. That's a hardware issue and there is no workaround. The only thing working are the gestures.

[Yeeze]

Would have been nice, but I can live without multi touch...

[shotofadds]

It's only possible to receive the X/Y coordinates and an indication of the size of the area touched (this can be calculated from the P1 and P2 values, somehow). With this information, could "multi touch" be simulated by testing whether the area touched grows or shrinks?

It's a thought for the future, anyway. I personally don't intend to do much with the touchscreen for the moment (priorities are getting the filesystem working, booting the Rockbox menu, and then sound).

On a European 8Gb player - Sweden, bought last week, came with 2.51 FW - bank 0 is mirrored on bank 2 and bank 1 on bank 3. The NAND IDs are the same as andiator's as well.

Thanks for that - I've updated the code in SVN now to detect the various combinations. Could you check it displays "2 banks * 1048576 pages * 4096 bytes" for the 8Gb player and "1 banks * 1048576 pages * 2048 bytes" for the 2Gb?

I'm always using fresh kernels in linux but tcctool relies on an old technique being present.

I avoided the issue completely by building tcctool on Windows XP - I realise that doesn't help you...

[Voluspa]

Thanks for that - I've updated the code in SVN now to detect the various combinations. Could you check it displays "2 banks * 1048576 pages * 4096 bytes" for the 8Gb player and "1 banks * 1048576 pages * 2048 bytes" for the 2Gb?

Confirmation from me on the 8Gb player that it's detected correctly as stated by the above figures (this time I used the rockbox.iaudio file). And I still have time to brew some coffee while it counts memory. After 10 minutes it's at 2.4Gb... Should I walk the dog while it goes to 8 .-) No way to cancel the count, it seems.

/Mats

[andiator]

2 banks, * 1048576 pages, * 4096 bytes per page for 8GB model

Multitouch... yes, I didn't see the plate resistance stuff, so it may be possible to have two finger gestures. But it's a long way to get a good and native support for touchscreens in rockbox. At first let's simulate some buttons. I've found a good description for touchscreen interface under http://www.atmel.com/dyn/resources/prod_documents/doc8091.pdf.

@shotofadds
In open moko project I've found some source code for PCF50606 except touchscreen handling. The first one is a patch file with battery/rtc stuff in it. The second one simulates PCF50606 for qemu. I can pm them if you want.
And besides, can we (the others) somehow help? I'm a software developer so I can code. Is there anything that can be done without deep D2-hardware knowledge?

[Bagder]

In open moko project I've found some source code for PCF50606

Right and there's also existing Rockbox code for it...

[Yeeze]

My problem: When I compile the bootloader for the D2, and then start the device using tcctool and the newly compiled bootloader, it still runs old code.
For example I add a printf ("test"); to the code, and compile it upload it to the D2 it won't print this line...
I checked the newly compiled bootloader file, it has a different size than the old one that did not have the additional printf ("test");

I tried a make clean, svn update, svn revert, deleting the whole rockbox folder and re downloading the source. Nothing helped.

This was not always the case, I used to be able to make changes compile them and the code worked on the player...
Now the code does only seem to change when I do very sensitive changes like adding a return in the main function...

I don't know where my problem is, but my thoughts are:
 - somehow I am compiling an old version of my code
 - an old bootloader file is uploaded on my player
 - an old version of the bootloader file is run on my player for some reason

Has anybody had a similar problem or has any idea what my problem is?

[zivan56]

IIRC lcd_update() needs to be called to update the screen.

[Yeeze]

thanks zivan56, but with printf that was only an example, another example I commented out the nand_test () (in ata_init() file: "ata-nand-tcc780x.c") function call, to skip the scanning of the complete flash. Compiled the whole thing uploaded it. But it would still scan the flash...

[shotofadds]

IIRC lcd_update() needs to be called to update the screen.

That won't be the problem - the D2 lcd driver is currently implemented in a slightly hacky manner (the frame buffer is directly read by the hardware, with no copying) so this call isn't necessary at the moment.

Yeeze, I've had a similar problem once or twice - in my case I think this was because I compile under VMware and run tcctool from WinXP (don't ask why ) and for some reason WinXP was still picking up an old version of the file from Samba. I haven't seen that problem for a while, though - and your situation might be entirely different of course.

I'm assuming that the compile had no errors, and that the timestamp on the new file has actually been updated?