Cowon D2

[reabsind]

Basic Hardware info,

System-On-Chip: Telechips  TCC7801 [Core: ARM926EJ-S]
Codec: Wolfson WM8985
Memory:
   Internal: Samsung K4M56323PG  
   Storage: Samsung K9LAG08U0M-PCB0 (2GB)
Power Mgmt: Philips PCF50606

Source:
1) http://www.enet.com.cn/article/2007/0131/A20070131415958_6.shtml
2) http://www.anythingbutipod.com/archives/2007/02/cowon-iaudio-d2-disassembled.php#more

[reabsind]

Firnware,

Before disassembling, need to understand the layout of the bin file.

Conclusions on just scanning the binary and strings
1) Layout of D2 firmware similar to U3
2) Layout of D2 firmware similar to M-bird rom !!!!

The firmware for M-bird XY-22 Player can be downloaded here
http://www.m-bird.se/software/XY-22/XY22SMV1320.rom

Further,
M-bird XY-22 based on TCC76x (ARM 940T core)
Cowon U3 based on TCC77x (ARM 946 core)
Cowon D2 based on TTC78x (ARM 926/946 core)


My analysis suggest this is 'coz all three use a common format created by Telechips SDK for ARM. Possibly even the preloader is the similar for all three These are encouraging signs....crack one and we are close to all!
I am sure many telechip licencees that are looking for smaller time to market will use their reference solution as is (including IRiver??)


I suggest the U3 progress ought to be relooked and taken forward 'coz my current knowledge (from iaudiophile forums) tells me that there is
*****             NO RECOVERY MODE      *****
in D2

U3 Page --> http://www.rockbox.org/twiki/bin/view/Main/IaudioU3Info

[music065]

processor info:

http://www.telechips.com/product/p_025.htm#

Successful rockbox of this unit would be a breathrough appreciated worldwide.  

This unit and its progeny, with its support of SDHD expandable flash memory, have the potential to make much of the current hard-drive based devices obsolete with the next few years.

[Michalaq]

Cowon were recently forced to release a recovery tool for their U3.
It was mentioned here that the D2 and U3 have very similar architectures.
Perhaps this recovery tool could be used for recovery of the D2.

This has been suggested by NeoDeever over at the iaudiophile.net forums (http://www.iaudiophile.net/forums/showthread.php?t=14750&page=5).
He seems to have had some success with this utility (only the device addresses and the firmware files to be written had to be changed).

The D2 is a unique device, both because of its innovative processor and its touchscreen. A rockbox mod would be absolutely amazing.

[zivan56]

This player apparently has the same FM chip that the Sansa e2xx  series have, the Sanyo LV24020LP.

[slack]

it seems as if someone has managed to get hold of recovery drivers. Users are reporting of a successful recovery on a faulty D2. This is pretty gd news.

Page 9 and on wards:

http://iaudiophile.net/forums/showthread.php?t=14750&page=9

[torrentseed]

I can provide the recovery driver if anyone is willing to port Rockbox to Cowon
D2

[punit]

I'm a 3rd year eng. student with some experience in digital processors, hardware & coding. I also have a colleague who is 3rd year electrical eng, so that oughta help too.
I have a feeling it's gonna be a lot of work...
http://www.rockbox.org/twiki/bin/view/Main/NewPort

After posting I did a bit of research - going through the datasheets of various ICs and all that. One thing I am not sure is how different the Telecips TCC7801 is from the ARM926EJ-S reference manual. I couldn't find the datasheet for TCC7801  .

I think there are two plans of action we can take - please feel to add or suggest better ways -
1. Try to understand the structure of the firmware binary - organisation and disassembly.
2. Try to trace the schematics and connections of the circuit board.

I found a few forum posts via google on some south east asian (thai I think) forums which had the disassembly pictures. Also the iRiver Clix uses the TCC7801 (again through SE Asian forums).

What's your take on the issue?

[man.dovvn]

anythingbutipod has a disassembly set of pics. We'll have to take a look at any progress made on the clix that we can transfer over, I'm not expecting much though. If we have recovery drivers, we can write test programs for the D2 according to the ARM926EJ-S manual and see what works. If we trace the schematics we can use a program to simulate the hardware, making testing & design a much easier and faster process. & I haven't any experience in decompiling/reverse engineering firmware. I am pretty good with coding though, & I have had some experience with ICUs & the coding limitations of hardware.

[punit]

Even if we can trace the schematics we still have no way of knowing the internal topology of the 7801. If I understand correctly it contains two processors - ARM926EJ-S and ARM946E-S and many peripheral controllers - LCD, Touch scree, SD card, USB etc.

To understand all these we'll have to reverse engineer the firmware. And possibly probe the pins when we can get a program running on the processor.

I also don't have much experience with reverse enginneering so am struggling a bit. Current plan is to get the recovery drivers and snoop at the USB traffic to see what commands are being sent. Am also trying to get hold of an ARM simulator which we can simulate the firmware in. Do you know of one?

Did you try anything since your last post?

[punit]

I was studying the firmware for the D2 and noticed that the firmwares started with a string "Ver:0071".

The same was the case with the other firmwares mentioned near the top of this thread too. I was wondering if anybody had an idea as to what format this is?

Another thing I noticed was that certain strings appeared more than once in the firmware. "Pure virtual fn called" for example. My hypothesis is that the bin files are actually packed file containing multiple files (possibly the flash filesystem) with individual binaries stored within them.

Would anybody know anything about this string 'Ver:0071" and the file format used? Or alternately is there a way to detect if the bin files are image of filesystem?

Would really appreciate any help I can get.

[punit]

An update on my last post - I tried a few things and had the scare of my life.

Currently there are two unidentified fields in the header - at address 10h and 18h. In order to know more about them, I changed a character in a string in the firmware binary and tried loading it on the D2. On reboot of the D2, a firmware update screen shows up, but the progress bar reaches about 1/5th and then straight goes to the opening menu. The file is deleted from the root directory of the D2.

This points to a checksum which fails and prevents D2 from updating the firmware.

Next I tried to change the unidentified fields in the firmware header on an original firmware binary. On changing the field at 18h I got similar results with the firmware being rejected (i.e., not loaded and deleted from root directory).

After this things got a little hazy. I lost patience and didn't document the changes I made in the binary. From memory, I kept the field at 18h unchanged and zeroed the four bytes starting at 10h. And next I know, the D2 is not booting.

Oh shit. I am glad I had the recovery drivers. But it is a windows application and I am not very good with windows. After a couple of tries and lots of tense moments I am able to use the recovery drivers to get the D2 back from the land of the dead.

My thoughts from these fiddling is that the field at 18h is a 32bit checksum. No idea what format. Still don't know what the field at 10h is or could be.

A few things I failed to notice -
1. After installing the firmware update from the recovery drivers whether the same upgrade bars shows up or not.
2. I chickened out after the recovery but a worthy thing to try would be try loading a modified firmware from the recovery software. Would give a clue as to the firmware checksum being checked even after loading via the recovery software.
3. Using a USB snooper to monitor the data and command sent over the USB during the recovery procedure.

I would appreciate if somebody could provide a confirmation of the results - the ones related to field 10h and 18h.

I will continue to fiddle around, but my knowledge of reverse engineering is small. So if there are others interested we could pool our resources and hopefully make faster progress.

[Reposted from iaudiophile forum]

[man.dovvn]

I say we continue trying to reverse engineer. The first thing we can try is simply decompiling the firmware files into some common languages. After that fails (hopefully not but...) our main problem will be the checksum. If we can crack that we can modify the firmware, load it up and docment changes. Hopefully we'll work out what to do from there. Check out http://iaudiophile.net/forums/showthread.php?t=14618 as well. It looks like we're gonna have some trouble with telechips. Perhaps someone on the inside of a company could pass on the manuals.

[man.dovvn]

http://forums.rockbox.org/index.php?topic=3320.180

someone mentions using ms visual studio debugger, analyisng the recovery program could prove useful.

[Taustin Powers]

Seems like the folks at iaudiophile.net made some interesting progress:

http://www.iaudiophile.net/forums/showthread.php?t=15966&page=2

"Tried testing out the CRC generating method in the link given in my last post. I modified firmware 3.51 (just changing a couple of strings), re-generated new checksums and loaded the custom firmware onto the D2. Works perfectly.

Have to explore the firmware file in more detail now to figure out how stuff works..."