Wiki > Main > LogikDaxPort (compare)
Difference: LogikDaxPort (r8 vs. r7)
30 October 2007: Some initial code has been committed to SVN. A simple application can be built and executed on the device, with working LCD driver and button input.
Logik is the own-brand of electronics sold by the Dixons and Currys high-street electrical shops in the UK. More info on the Logik DAX is available here: Logik DAX 1GB MP3 Player with Digital DAB Radio
This appears to have been designed by Telechips on behalf of Dixons, and the same design appears to have also been used for the ATMT DAB MP3 (MP170). As of October 2007, the Logik DAX appears to have been discontinued by Dixons/Currys (they are selling the last stock), but ATMT's version is widely available. No firmware updates appear to be available for the ATMT to confirm this suspicion though.
The Alba PRDAB210MP3 also appears to be a clone of the DAX/ATMT MP170, but this hasn't been confirmed, and it is also discontinued. PRDAB210MP3? also appears to be a clone of the DAX/ATMT MP170, but this hasn't been confirmed, and it is also discontinued.
Alba also sell the PRDAB200MP3 which is a different form factor (2-colour OLED display, SD/MMC card slot), but is based on a Texas Instruments chipset, not Telechips. PRDAB200MP3? which is a different form factor (2-colour OLED display, SD/MMC card slot), but is based on a Texas Instruments chipset, not Telechips.
R G M1-RGB B 0YOOO1B-38-MO2
A firmware update and other information is available at http://support.thetechguys.com/2921. The firmware is distributed in a self-extracting zip file (called Firmware.exe) - the actual firmware is called player.rom and can be extracted from the .exe using an unzip utility.
To upgrade the firmware, the file player.rom needs to be copied to the root of the device. Upon reboot, the user is prompted to upgrade. If yes is selected, the firmware is upgraded and the file deleted from the FAT partition. A reboot is required to actually start the new firmware - the existing version will continue to run. Random notes/thoughts
Based on the observation that the existing firmware continues to run after a firmware update, it would seem that the firmware itself is executing from RAM, rather than executing in place from a ROM.
The firmware upgrade process itself displays the message "Upgrade NAND firmware". This would suggest the firmware is stored in the main 1GB NAND flash. The firmware doesn't appear to be in the part of the NAND flash visible as a drive via USB, so it is most likely hidden (similar to the Sansa E200R). E200R?).
The Telechips website states that there is 4KB of "internal boot ROM" with various boot procedure (NAND, UART, USB, EHI). On the main PCB, there are two visible pairs of contacts near the CPU, with one pair marked as "USB" and one pair marked as "NAND". The "NAND" pair of contacts are soldered together. It seems likely that unsoldering the NAND contacts and soldering the USB contacts would cause the device to boot via USB - presumably meaning that you could safely upload and run code without fear of bricking.
If you disassemble the device and physically disconnect the NAND module from the main PCB, and then connect a USB cable, the device doesn't appear to power on (the LCD remains off), but it does make a USB connection to the PC. On a Linux PC, the following entry appears in /proc/bus/usb/devices:
T: Bus=05 Lev=02 Prnt=03 Port=03 Cnt=02 Dev#= 51 Spd=480 MxCh= 0 D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=140e ProdID=b021 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none) E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms
These are different Vendor and Product IDs to either UMS or MTP USB modes, which would suggest this is the USB boot mode mentioned on the Telechips website. i.e. the device appears to default to USB boot mode if the NAND boot mode fails.
Running lsusb shows the following info:
Bus 005 Device 043: ID 140e:b021 Language IDs: none (cannot get min. string descriptor; got len=-1, error=110:Connection timed out) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 0 Interface bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x140e idProduct 0xb021 bcdDevice 1.00 iManufacturer 0 iProduct 0 iSerial 0 bNumConfigurations 1 cannot get config descriptor 0, Connection timed out (110) Language IDs: none (cannot get min. string descriptor; got len=-1, error=110:Connection timed out)
In order to develop an alternative firmware, we need a way to safely run our own code - i.e. be able to recover the device when our attempts inevitably crash and burn. Some possible approaches to this are:
Because the Telechips website refers to a "boot ROM", it is probably safe to assume that this is not modifiable by the device manufacturer. So all the various devices using the same Telechips CPUs are very likely to have the same or very similar USB boot mode protocol. So working out how this works on one device should open up all of them to this method of attack.
r8 - 20 May 2009 - 15:45:28 - RobertMenesRevision r8 - 20 May 2009 - 15:45 - RobertMenes
Revision r7 - 21 Oct 2008 - 15:58 - DaveChapman
Copyright © by the contributing authors.