Xclef MT-500 Hardware Information

Hardware Specifications

Xclef MT-500 (128 MB version) mainboard

Xclef MT-500 (256 MB version) mainboard

1. Telechips TCC730Y? - device controller (CPU), which seems to be a rebadged Samsung S3CC410
2. SST 39VF800A 70-4C-EK - 1 MB (512k x16) flash memory for the firmware
3. a) Samsung K9F1G08U0M-YCB0 - 128 MB flash memory that represents the internal data memory. Alternate Datasheet
   b) Samsung K9K2G08U0M-YCB0 - 256 MB flash memory that represents the internal data memory. Alternate Datasheet
4. Display - We need more information on this, can it be replaced with another LCD of similar size?
5. Microphone
6. USB connector
7. Mode/volume jog
8. Playback control jog

There exists a 64 MB version of this model, which flash chip it use is unknown at present.

Xclef MT-500 mainboard (bottom view)

Xclef MT-500 second board (top view)

Xclef MT-500 second board (bottom view)

Reverse Engineering

Luckily the Archos Gmini has similar hardware to the MT-500. The Gmemu team have already created a working emulator for the Gmini. The best way forward is to use their work as a starting point.

Steps towards an open firmware replacement

1. Disassemble the MT-500 firmware to find out the memory mapped registers that the hardware has built into it. [ in progress by DawidFerenczy ]
2. Reverse engineer the Xclef flash tool, this will give some insight into how to flash the player and whether it's posible to control the hardware over the USB cable. [ awaiting ]
   • This tool is only available for Win32, so having a command line tool that works for Linux would be a good start.
   • It looks like this tool was written in Delphi, I'm not sure about the DLL's that also need to be reversed engineered as well.
   • In the pre-UMS versions there was a different flash tool to the one used now (the UMS enabled version). Does this mean that flashing is also dependent on the current firmware version?
   • When flashing the Xclef it might be possible to place a USB packet sniffer inbetween the Xclef and the Win32 host.
3. Extend the Gmini emulator to handle the MT-500 hardware, so we don't break our hardware. [ awaiting ]
4. Ability to load an existing firmware into the emulator and use emulated flash memory filesystems for the internal and external memories for playing MP3's from. Once this has been achieved it will be possible to start implementing the replacement firmware. [ awaiting ]

What you will need

1. Download the Gmemu tools. It is important to get the tools from the CVS repository, you will need:
   • binutils-2.15
   • gcc
   • gemoss
2. The MT-500 firmware, available from:
   • AdvancedMP3Players (Requires a login) for the 2.0.08 UMS version
   • Xclef for the 2.0.13J version
   • Xclef for the 2.0.17 version. This seems to be the latest version, and the strings are in English too.

The Gmini tools

When you have the source follow you need to build the tools:

• cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/gemoss co -P gemoss
• cd gemoss
• automake -a
• ./configure --prefix=<install-dir> GMINIMODEL=mt-500 LOADADDRESS=10000
• make
• make install

The GMINIMODEL and LOADADDRESS are completely irrelevant at the moment.

wxWidgets Gmemu GUI

As well as trying to understand the logs from runnint the Xclef MT-500's 2.0.17 firmware on the Gmemu program, I'm developing a new GUI with wxWidgets, I'll be placing screenshots and source here.

The GNU tools

Before you can disassemble the firmware you need the GNU tools built, this can be found in the CrossCompiler#CalmRISC16 section.

Disassembling the Xclef firmware

Now you have the tools, you need to create a firmware file that the disasm tool will accept, you need to make sure that you are in the gemoss/reverse/ directory so that the disasm tool picks up the files it needs to handle register symbols in the disassembly.

• cd reverse
• calmrisc16-unknown-elf-objcopy -I ihex -O elf32-calmrisc16 path-to-firmware-version.hex path-to-firmware-version.elf
• calmrisc16-unknown-elf-objcopy -I elf32-calmrisc16 -O binary path-to-firmware-version.elf path-to-firmware-version.bin
• pack path-to-firmware-version.bin path-to-firmware-version.aaz 2000 MUNKEE MASTER
• disasm path-to-firmware-version.aaz

The value of 2000 is the lowest address in the firmware and thus, is where the code starts. The MUNKEE and MASTER values are just dummy parameters which are irrelevant for now.

Replace the text path-to-firmware-version with whatever the path to the firmware is and the filename of the firmware files are.

CalmRISC16

The CalmRISC16 is a 16-bit low power RISC microcontroller. The CalmRISC?'s basic architecture follows Harvard style, that is, it has separate program memory and data memory (both up to 4 MB). Both instruction and data can be fetched simultaneously without causing a stall, using separate paths for memory access. It can operate up to 100 MHz alone or up to 80 MHz, when operating with a MAC24 coprocessor. The instruction set provides no instruction for writing to the program memory.

There exists the CalmRISC16 development environment from the AIJI System called CalmSHINE16.

• Memory mapped I/O
• OP decoding

USB packet sniffing

There are a number of packet sniffers out there, but you need one that can attach to a USB hub or one that doesn't need to restart the device like the SnoopyPro does.

The Xclef needs to be put into upgrade mode in the menu and then the cable is attached, at this point the USB Mass Storage device disappears and something else appears in it's place. Using a USB packet sniffer it may be possible to work out what kind of device this now represents and create a Linux device driver (the USB generic serial driver shows nothing).

Expected features of the open firmware

The replacement firmware must retain as much as possible from the existing firmware feature set, but extending them to the following:

• OGG support
• Playlist support

The USB cable pinout

In the usb-pinout image (which I got from here) of the standard USB to hirose type connector, the pins are mapped, thus:

USB A MALE	MINI USB 4P MALE
1	1
2	2
3	3
4	4
Shield	Shield

In the Xclef's cable this is slightly different:

USB A MALE	MINI USB 4P MALE
1	4
2	3
3	2
4	1
Shield	Shield

What can you do to help

We need more pictures of the internals of this device:

• The other side of the mainboard
• Disassembly instructions
• I have a feeling that there are two PCB's in this thing, but I could be wrong, I can't get into mine at the moment
• Images of the 64 MB version
• Determine whether any other MP3 player's remote controls have the same connector as the one that Xclef was going to release, in other words, would another remote control work with this player? The connector seems to be mechanical compatible, but other remote controls doesn't work with the player. In better case, it could be a FW problem.

We need people who have experience with reverse engineering, especially for the Win32 tools.

If you have some relevant information or you are interrested in developing opensource firmware replacement, please contact me at ferenczy [at server] volny.cz or at ICQ# 85997864. Thanks DawidFerenczy

Useful links and resources

• ferenczy.coex.cz/mt-500 - my personal webpage with the fresheast information about reversing Xclef MT-500 (both - english and czech language versions). I'll try to keep this wiki version up to date too.