The OpenTSM Project

This wiki is writeable for everyone. Add what you know. Delete what is wrong.

1. STATUS

2008-3-30:

  1. Some spanish resources: Tuxsm linux on tsm project, develpoment forum, etc. (see links)

2007-12-30:

  1. We have the Texas Instrument Specification for the digital baseband chip on the TSM30 (HERCROM400G2 (Calypso)).
  2. We can dump the flash of the 'new' tsm30 phones via irda. (It only works with some irda ports. The ACTiSYS irda dongles seems to be the best).
  3. We are working on updating the flash via irda.

Contents

  1. STATUS
  2. About
  3. Current Problems and TODOs
  4. Getting Started
    1. SDK
    2. Getting a Phone
    3. Compiling the Source
      1. Writing the Flash
  5. OS Infos
    1. Memory Map
    2. How Irda flashing works
  6. Hardware Infos
    1. Chips identified by robert
  7. Software
  8. TODO
  9. Projects
    1. Receive Debug Info via Irda
    2. Writing Files / FS infos
    3. Trace Mobile
    4. TX
    5. Flashing the TSM30 with a serial IRDA
  10. Research & Development
    1. Can not update flash
    2. Extracting the flash
  11. Notes on TSM30 boot process
    1. Introdution
    2. MCU
    3. DSP
      1. Loading the DSP miniboot
      2. Executing the DSP miniboot and loading the DSP loadableboot
      3. Executing the DSP loadableboot and loading the DSP application
  12. Tricks
    1. Hard Reset
    2. Key Codes
  13. Specs
  14. Links

2. About

The goal is to modify and recompile the source of a TSM30 mobile
phone and to amazing things with it! Check out the 'Project'
section and 'TODO' section.
The mailinglist is the main gsm@lists.segfault.net mailinglist for
the moment.
Thanks to Steve G. and Pasquale for helping getting this started.
We ordered 25 TSM30 phones bulk. If you need one please let me know.
GET A PHONE FOR FREE
====================
    I'll give out 3 phones for free to the first 3 active developers: E.g.
    get started with compiling the source and the 3 people who find out
    most about the source and what/how we can do things get free phone each!
    (Check the TODO/Project section on the wiki).
hope this kicks ass,
steve


There is the full source code of the multi-media DSP. There is no source code of the baseband DSP. The interface between Application Processor (AP) and Baseband Processor (BP) is fully documented (FIXME: Where are the documents? anyone?).

The available documentation is in the source code. Please look at the comments in:

  1. vitel-tsm\MCU\Layer1\L1c\Inc\l1_defty.h
  2. vitel-tsm\MCU\Layer1\L1c\Inc\l1_trace.h

The baseband code is completly in the Calypso HERCROM40G2 firmware. The DSP firmware is in:

  1. vitel-tsm\MCU\Layer1\L1d\src\Dsp_Code.c
  2. vitel-tsm\MCU\Layer1\L1d\src\Dsp_Data.c
  3. vitel-tsm\MCU\Layer1\L1d\src\Dsp_patch.c

So it should be possible to disassemble the firmware with IDA version 5.0.0.879 ;-) Any detailed informations about the Calypso chip are welcome. These informations are hard to get, but they would help to understand the baseband firmware. It looks like it is possible to disassemble and to change the firmware without problems. This is an advantage compared to Nokia DCT-3 phones where a dump of the firmware is only possible via firmware bugs and where we can change the firmware only via certain hooks.

It looks like it contains the baseband code (?) or at least the part that generates the GSM messages:

  1. /MCU/Layer1/L1c/Src/
  2. /MCU/Protocol/RR/Src/
  3. /MCU/Protocol/MM/Src/
  4. ...

this does the calypso dsp commn stuff(i guess)

3. Current Problems and TODOs

We do not know how to upgrade the firmware. Seems like that the phones that we have use a different irda update protocol. Pasquale managed to update his firmware via mmc and irda (com2).

  1. Reverse update protocol (kay? possible? what do we know about the protocol?)
  2. search newer version of tsm30 updater (newer than download 6.3)
  3. try mmc update (and patch version/revision number to be higher than installed firmware number)
  4. try find older phones (need pasquale to confirm his version number). (pasquale, which version/revision are you using? ####9999)

4. Getting Started

4.1. SDK

Install cygwin for windows. Cygwin is a powerful unix environment for windows and comes with subversion (svn). Otherwise please use the svn binary for windows from http://scm.tigris.org/.

Check out the development environment and TSM30 source from our subversion server to C:\opentsm\: 

cd c:\\
svn co svn://freeworld.thc.org/opentsm opentsm

Write access to the svn is given to contributing developers. Contact steve at segfault.net.

If you do no want to use subversion get the source from the internet:

  1. Download ISO file from http://sourceforge.net/projects/plabs.

  2. Mount ISO with Daemon tools.

  3. The source is inside Offical.zip.

4.2. Getting a Phone

The TSM30 is hard to find and discontinued by Movistar/Vitel. The OpenTSM project bought 50 phones bulk and chargers. We are selling them through http://www.ebay.co.uk for 49GBP. Search for 'Vitel TSM30'. If you can not find a phone there please contact steve at segfault.net.

Other sources:

  1. http://www.ebay.com

  2. http://www.cmrecycling.co.uk/stock/index.php

  3. Pijus (see mailinglist)

  4. http://mercadolibre.com.mx/ or the EBay/Spain

4.3. Compiling the Source

You need windows to compile the sources. Sorry, no unix for now, because they use some ugly bat scripts and a very *SLOW* c55 compiler to do the job:

Dos windows: 

C:\opentsm> mount.bat
C:\opentsm\src\Common\INTEGRATOIN\bin>dmakeall.bat

The source is in C:\opentsm\src. The "integration\bin" subpath contain compilation "scripts". dmakeall.bat will do a full compilation.

Example:

Take a look at dmakeall.bat: 

cd ..\..\..\dsp\integration\bin
call dmakeall.bat
cd ..\..\..\mcu\integration\bin
call dmakeall.bat
cd ..\..\..\common\integration\bin
call merge.bat

merge.bat, though a proprietary program, will create the 2 flash images (gsm_dsp.mmc and gsm_dsp.cpt in common\integration\bin directory) ready to be sent to phone.
Screenshot of a successfull compilation:

Tips: dmakeall.bat clean all .obj file and then compile. if you edit only some file and you want to recompile only them, run MCU\integration\bin\makeall.bat if you edit mcu files, and\or DSP\integration\bin\setenv.bat and DSP\integration\bin\mk.bat if you edit dsp files. After this, you need to generate flash images with merge.bat in Common\integration\bin.

Ah, if you don't want simlock support, comment out #define SIMLOCK at line 366 in MCU\Integration\bin\option.h

4.3.1. Writing the Flash

The most simple way to update tsm30 with our fresh compiled firmware, is to put these two files onto the mmc card. SD cards will not work. Get a mmc. It should be FAT filesystem and less than 256 MB: 

gsm_dsp__.mmc
download.chk

Turn the phone on. The screen shows 'Flashaendo'. This process takes 1-2 minutes. Remove the mmc. Turn the phone off and on again and wait another 4 minutes for the flashing to complete.
If you prefer using irda, you have to use tsm30_upgrade.exe . It is a gui tool but you have to pass parameters via command line: 

tsm30_upgrade.exe [ filename.cpt] [IrdaComPortNumber]

when you start it, phone must be turned off.

happy compiling :D

Pasquale a.k.a. c0sm4ky

5. OS Infos

(info mostly by pasquale)

The flash is divided in many "partitions" (MMCFS, CONFFS, MMIFS, MSGFS, DEBUGFS,EMAILFS etc).

About the OS, there are 2: one for MCU (MCU/Sos/Src directory) and one for dsp (DSP/DSOS/src). They are mailboxes-based and seems to be made only for this phone.

5.1. Memory Map

src/MCU/Integration/bin/link.cmd 

SEE file above. Someone please post the content here and confirm that this is
the program memory. (small update by darkscout - has to be extended)
Stack Size: 0x1000
Heap Size : 0x0400
FLASH (4 MBytes: 3 lower MBytes used for program and constants, 1 upper MByte for filesystem)
Interrupt Vectors (RXI): 0x00000000 (len = 0x00000100 = 256 bytes)
Download Intit    (RXI): 0x00000100 (len = 0x00000F00 = 3840 bytes)
Download Code    (RWXI): 0x00001000 (len = 0x00001000 = 4096 bytes)
Mobile Init       (RXI): 0x00010000 (len = 0x00000020 = 32 bytes)
Version Number    (RXI): 0x00010020 (len = 0x00000008 = 8 bytes)
Program Memory 1  (RXI): 0x00010028 (len = 0x002EFFD8 = 3080152 bytes)
Filesystem         (RW): 0x00300000 (len = 0x00100000 = 1048576 bytes)
RAM (512KByte internal and 512KByte external = 1MByte)
D_MEM1 [internal]  (RW): 0x00800000 (len = 0x00000000 = 4 bytes)
D_MEM2 [internal]  (RW): 0x00800004 (len = 0x00000020 = 32 bytes)
D_MEM3 [internal] (RWX): 0x00800024 (len = 0x0007ffdc = 524252 bytes)
D_MEM4 [external]  (RW): 0x01000000 (len = 0x00080000 = 524288 bytes)
SECTIONS
        .intvecs:       INTERRUPT VECTORS
        .download_init: DOWNLOAD INIT
        .mobile_init:   MOBILE INIT
        .version_number: VERSION NUMBER
        .download: DOWNLOAD CODE
        .download_iram: DOWNLOAD CODE
        .text: PROGRAM CODE
        .cinit: INITIALIZATION TABLES
        .const: CONSTANTS
        .bssInit:       Init variables
        .bssreconf:     Init variables
        BSS for modules running from internal RAM
                        (
                        .bssdwn :
                        .IntBss:
                                (lcd, l1c, l1d, sos, frm, tid, dsim, ts, dir, irda, psm, kbd, pcom, pdis, pedrseg)
                        )
        .Extbss: BSS for modules running from FLASH
        .sysmem: RAM system (library)
        .stack: RAM system (library)

from loadableboot.cmd: 

LoadableBoot is mapped to the end of the RAM:
Stack Size: 0x1000
Heap Size : 0x1000
P_MEM  (RXI)   0x00877ff8 len = 0x3000 (Program Memory (ROM))
D_MEM1 (RW)    0x0087aff8 len = 0x2000 (Data Memory (RAM))
D_MEM2 (RW)    0x0087cff8 len = 0x2000 (Data Memory (RAM))
PRODUCT_ID_SECTION (RW) 0x0087eff8 len = 0x4 (Product ID)
LB_ENTRY_POINT     (RW) 0x0087effc len = 0x4 (Loadable Boot Entry Point)
Sections:
.text   P_MEM    (Code)
.cinit  P_MEM     (Initialization tables)
.const  P_MEM     (Constant data, non writeable)
.bss    D_MEM1    (Global & static variables)
.stack  D_MEM1    (Software system stack)
.sysmem D_MEM2    (heap)

5.2. How Irda flashing works

There are 2 bootloader: one is "miniboot" and the other is "loadableboot".
When phone is powered on, miniboot is executed: it sends over irda some bytes, and if it receive ack from pc,
then it enters in a loop waiting somedata that will be written in ram. Pc software can specify any address.

That data is 4 bytes for PRODUCT_ID (written at 0x0087EFF8), 4 bytes for LB_ENTRY_POINT (written at 0x0087EFFC)
and arbitrarianlen data written wherever you want :) (but max 2048 per packet).
At the end there is product_it check, and if it is passed , a jump to code loaded in ram; otherwise the phone will be powered off.
Whit this method, "loadableboot" code is executed. It does pratically the same things as miniboot, except it allows you to erase
and write arbitrarian areas of the flash.

For detailed protocol description, i suggest you to look at down1init.c file.

PRODUCT_ID, LB_ENTRY_POINT and loadableboot code, as well as DSP, MCU code, filesystem and other things are in .cpt files.
After decrypting whole file with the first TEA key (thanks to key2 whofound this :) ), we have a file starting with a header like this:

"877FF8 2700 87EFF8 4 87EFFC 4 0 20 100 50 1000 8BE 2000 19CC 39CC B254 FFF8 4 A00000 21 FFFFFFFF "

the first 3 couples of values (877FF8 2700 87EFF8 4 87EFFC) are used for miniboot, the others for loadableboot.
for example, 877FF8 is the RAM start address to write 2700 bytes, found immediately after the header.
then there are 4 bytes, the product_id, then 4 bytes for LB_ENTRY_POINT pointer.

the same is for loadableboot, the differences is that here we have FLASH memory address instead of RAM one's.

6. Hardware Infos

Pasquale's HiRes pictures:

  1. Front

  2. Back

  3. Pads for JTAG and UART

  4. Charger

The main chip seems to be a Texas Instruments OMAP (http://www.ti.com/omap), C55x DSP plus an ARM processor. At first I thought the chip was a OMAP5910, but I've double checked and it can't be a OMAP5910 based on the date stamps in the code, it could be very similar or code compatible though.

The baseband chip is a Calypso HERCROM40G2, a combination of a TI C55 DSP + another small ARM.

  1. RF3110 tsm30 gsm power amplifier (datasheet)

Most wanted Datasheets and user guides:

  1. TMS320DA250 CPU+DSP
  2. D741979 Digital baseband chip
  3. TWL3012 Analog baseband chip

6.1. Chips identified by robert

7. Software

  1. TTPCom TCP/IP stack http://www.ttpcom.com/

8. TODO

  1. Compile the source and flash the phone with the compiled binary. Does it still work?
  2. Find out if there is any kind of debug functionality. E.g. can we printf() to the serial cable?
  3. Can we tune the DSP to send/receive on a complete different frequency? e.g. can we turn a mobile phone into a basestation? (reverting receiving/sending frequency).

9. Projects

9.1. Receive Debug Info via Irda

Irda config Host PC: 115200bps / 8n1
Patched files:

  1. irda_test.c

  2. pidl04debug.c 


There are a lot of debug mechanisms (see TRACE_EVENT macro)
pratically everywere in the source(especially in layer1 part);
generally they format some text and then send it over the serial TTL
line. Until now sending via Irda is working. We should change the macros to send
via irda instead of serial TTL.
put irda_test.c and pidl04debug.c files in MCU\Presentation\Idle\Src, then add this function definition to pidl04debug.hp
GLOBAL_EXT u8 pidl04_testirda( char *p_Str );
After, add this element to a_pidl_KeyTable[] array (in pidl04debug.hv):
"####53",   pidl04_testirda
then comment #define MONITOR_LOCK (e.g. disable the define) at line 59 in
Common\includes\common_option.h and recompile the whole mcu.
now, to execute  pidl04_testirda routine, made a call to the "magic
number" ####53...
on the pc side, irda com port must be set to 115200bps, 8bit, no
parity, 1 stop bit.
At every my_irdaSend() call, you will receive some FF, then a 0xC0
(LAP_BOF), your data and then a 0xC1 (LAP_EOF).
btw, If you look in the files,  will be more clear to you :)
Pasquale

9.2. Writing Files / FS infos

Example1: 

fp = IOs_open("MMIFS:" "MmiSettings", O_RDONLY); //where MMIFS is the
"partition" and MmiSettings is the filename; if you wanna access MMC
then use MUSICMMC instead.
IOs_read(fp, (U8 *) & buffer, len);
IOs_write(fp, (U8 *) & buffer, len);
IOs_close(fp);

Example2: 

i tested this with this code i added to pidl04_50DisplayMMCInfo()
function in MCU\Presentation\Idle\Src\pidl04debug.c
---------------------------------------------------------------------------------------------
vl_MMCId=IOs_open("MUSICMMC:test.txt", O_RDONLY);
if ( vl_MMCId == FS_ERROR )
{
   pcom02_10SimpleBox( (u8 *)"error opening file READING", (u8 *)"error", PPMT_EOL_DUMMY_PROMPT_SPT2, PPMT_EOL_DUMMY_PROMPT_SPT2, 0);
   return TRUE;
}
IOs_read(vl_MMCId, (U8*)al_Title, 15);
pcom02_10SimpleBox( (u8 *)al_Title, (u8 *)"read worked", PPMT_EOL_DUMMY_PROMPT_SPT2, PPMT_EOL_DUMMY_PROMPT_SPT2, 0 );
IOs_close(vl_MMCId);
vl_MMCId=IOs_open("MUSICMMC:test.txt", O_WRONLY|O_APPEND);
if ( vl_MMCId == FS_ERROR ){
   pcom02_10SimpleBox( (u8 *)"error opening file WRITING", (u8
*)"error", PPMT_EOL_DUMMY_PROMPT_SPT2, PPMT_EOL_DUMMY_PROMPT_SPT2, 0
);
   return TRUE;
}
IOs_write(vl_MMCId, (U8*)"lolololololololololololol", sizeof("lolololololololololololol")-1);
IOs_close(vl_MMCId);
return (TRUE);
---------------------------------------------------------------------------------------------
ah, remember you MUST insert your mmc card before swiching phone on,
otherwise it will not be recognized.

References:

Common\Filesystem\iolib\src

abstraction library that handles "partitions"

MCU\drivers\Filesystem\fileSystem\Src

abstraction library that handles filesystem devices (flash and mmc), also contains flash filesystem format handler

MCU\drivers\Filesystem\flshDev\src

Memory flash device driver

MCU\drivers\Filesystem\mmcDev\src

MMC Device handler task, this task comunicates with real mmc low-level driver is in multimediaDSP via spi bus (high-priority serial messaging system between multimediaDSP and MCU)

DSP_DRIVERS\Filesystem\mmc

real MMC low-level driver

9.3. Trace Mobile

We want to turn the TSM30 into a trace mobile to receive any GSM messages the baseband processor processes. This will help us understand what kind of packets the Basestations sends and what packets the mobile phone responds with.

  1. Let's start with dumping the messages to the local phone memory. Later on we can implement a mode to transfer the dump via cable to PC (live capture).
  2. If you look at the source there seems to be some kind of trace functionality already implemented. It should be explored if this can be used for our purpose.
  3. Each gsm message is 23 octet fixed in size.

Tracing via USB

First of all remove the simlock of the phone 

 1. Comment out #define SIMLOCK at line 366 in MCU\Integration\bin\option.h (Pasquale mentioned it before).This enables the other keycodes also.Look into official/mcu/Presentation/Idle/Src/pidl04debug.hv for more details.
 2. Replace the line no:354 in official/mcu/Application/Mfw/Src/mfw_simlock.c  with  return MFW_SIM_ENABLE;
 3. Then set v_TraceOnUSB=1 This variable can be found in official/mcu/drivers/vuart/Src/vuart01main.c and official/mcu/Presentation/Idle/Src/pidl08usbmode.c Thanks to dieter for pointing me out this variable slh03_01MediumChangeRequest(SLH_CLIENT_ID_TRACE, SLH_UARTVIRT); in vuart01main.c does the job. Similary I think you can redirect it through irda too. Just go through slh.hv for more details.
 4. Then connect phone to USB and select the modem mode..In linux cdc_acm driver support this. "modprobe usbserial vendor=0x0451 product=0x5520" will do the job if you have cdc-acm loaded already.If you face any problem in configuring the modem driver just go through the kernel doc (Documentation/usbgadget_serial.txt).

 5. Just start cutecom/minicom and then get the data by using
  . "####70",   ( pidl04_18IntegrationTrace,          // Trace L1, TIL and RR)
  . "####71",   (pidl04_20MMITrace,                    // Trace MMI messages)
  . Go through pidl04debug.hv for more details
  For usb trace enabled working flash in HW:205 //with layer1 trace compiled (#define L1_TRACE uncommented in option.h) find compiled_flash in the attachments
----

TO DO...

  1. Format the data to readable mode by checking the sending format.
  2. official/Common/tools has some .ini files which we need to look

-0x0

9.4. TX

The TX projects tries to turn the TSM30 into a custom gsm message sending device. If you can send custom gsm messages you can have a lot of fun with the GSM network (including free calls :>).

  1. Load the phone with packet and information and what framenumber/Timeslot the packet should be send. Once the framenumber/TS comes around the packet should be send to the BTS.
  2. Tricky. Possible depends on implementing the trace mobile first.

9.5. Flashing the TSM30 with a serial IRDA

TODO: write text and attach flash tool

Currently supported HW revisions by firmware: HW205

10. Research & Development

10.1. Can not update flash

Our phones have different versions and it seems that the 'Download 6.3' does not work with any of these versions: 

HW revision: 00000210
SW version: 30100025
SW revision: 00000009
MMC loader: 01050800
HW revision: 00000205
SW version: 30100027
SW revision: 00000032
MMC loader: 01070800
HW revision: 0000A206
SW version: 31100027
SW revision: 00000025
MMC loader: 01070800
HW revision: 0000A210
SW version: 31100025
SW revision: 00000009
MMC loader: 01050800
HW revision: 0000A211
SW version: 31100027
SW revision: 00000025
MMC loader: 01070800

}

There seems to be a problem with updating the flash on the phones. The tsm_upgrade.exe program does not seem to work under windows. Updating via mmc was unsuccessful. Diablo send me a flash that he compiled year ago which is known to be working. Yet I failed to get it onto the phone:

Diablo's compiled flash

The problem is that nothing happens after i insert the MMC and start the phone. The phone boots normally without any indication of the flash beeing updated.

We believe the reason is a new protocol. The byte send over the irda when powering on is: 

ab ba 00 05 b2 00 08 03 00

See Down01_02MB_SendRecognitionString(void) in MCU/src/drivers/init/Src/init1mobile.c.

The download 6.3 software expects 0xa2 instead of 0xb2. See INIT_RECOGNITION_MB_CHAR in MCU/drivers/download/Src/down.hc.

It expects: 

ab ba 00 05 a2 00 01 03 00

The second problem is that we do not know the PRODUCT_ID associated with the PRODUCT_NB=0x08. See MCU/drivers/download/Src/down.hc for more infos. It only lists PRODUCT_NB=0x01 .. 0x06.

There is a check in down1init.c 

// check the product ID of the software to download (contained in the loadable boot)
if(PRODUCT_ID_TO_LOAD != PRODUCT_ID)
{
    Down01_15SwitchOffMobile();
}

There is a vitel_tsm100_tsm30.tar.bz2 package on sourceforge. The BSTSM30-02.pdf (translated) document details how to upgrade from previous versions to our version. The .cpt to upgrade to the same versions that our phones have is included in the .bz2. We are hoping to find the Product ID in 30100025sub9 or MigrateBoot_from_TSM30iO_to_TSM30iN.cpt.

The PRODUCT_ID in the compiled binaries from our source is 0x94527ae4 and is stored in little endian byte order in the binaries. Searching for it: 

grep `perl -e 'print "\xe4\x7a\x52\x94";'` -r MCU Common DSP

The load.exe program packs and compresses the binaries into the .cpt file (see merge.bat ).

Key2 did some good reverse engineering and wrote a decode tool. Pasquale enhanced this decode tool ( decode_cpt.c ) to decrypt a .cpt file and output the product id.

pasquale reversed the PRODUCT_ID=0x1516bd07

10.2. Extracting the flash

The available .cpt updates on the internet do not work on our phones after we patched in the correct PRODUCT_ID. There must be some difference in our hardware. The goal is to extract the current flash and analyze it. For this pasquale wrote a loadableboot.bin that extracts the flash from one of our phones.

Download: tsm_flash_reader.tar.bz2 

I'm using it now for reading the flash of my phones, but it is
sloooooow because my crappy irda interface loses many packet, so the
program has to retransmit the same command lot of time before getting
a valid data. I'm getting about 100K per hour..anyway it works ;)
You need to have a look at the source to understand how it works.
It takes no command-line parameters: when executed, it try to open a
serial port (the device name is hardcoded), send loadableboot.bin and
then read the flash.
Loadableboot.bin is a modified version of the original one to allow
flash reading.
enjoy ;)
c0sm4ky

Download of several dumps (by pasqual, darkscout and 0x0):

SW 30100023 Rev 00 (HW 205) flashdump_HW_205_SW_30100023_REV_0.tar.bz2

SW 30100023 Rev 03 (HW 204) flashdump_HW_204_SW_30100023_REV_3.tar.bz2

SW 30100023 Rev 03 (HW 205) flashdump_HW_205_SW_30100023_REV_3.tar.bz2

SW 30100027 Rev 32 (HW 205) flashdump_HW_205_SW_30100027_REV_32.tar.bz2

SW 31100025 Rev 09 (HW A210) flashdump_HW_A210_SW_31100025_REV_9.tar.bz2

SW 31100027 Rev 25 (HW A211) flashdump_HW_A211_SW_31100027_REV_25.tar.bz2

TSM 100 SW 141053BB Rev 06 (HW 102) flashes_tsm100.tar.bz2

11. Notes on TSM30 boot process

11.1. Introdution

The following are notes on how the TSM30 boots, based on reading the source code.

11.2. MCU

  Real boot process (only essential functions and labels)
  Down01_01MB_Load() ; miniboot
  MobileInit ; offset 0x2000
  Down07_01RunDownloadMMC() ; checks for bootloader on MMC and boots it if present
  SoftInit ; label with offset 0x10000
  StartSoftware ; label (see MCU\download\init\int.asm)
  auto_init ; ??? FIXME (see MCU\download\init\int.asm)
  Init01_23Relocate() ; copies firmware from Flash to RAM
  Sos7_05SosInit()  ; (already in RAM) memory management, ...
  Init01_01SoftwareInitialisation();
  prop_InitializeApplication(??);
  Application_Initialize(??);
  /* setup tasks */
  Sos1a_06Schedule(); (scheduler)

Every thing seems to be controlled and coordinated by the MCU. FIXME miniboot() is in /MCU/drivers/download/Src/down0main.c and calls

  1. Down00_02##_InitHardware() - Init memory mappings, write protections

  2. Down01_01##_Load()

Down01_01MB_Load()

  1. Down01_02MB_SendRecognitionString to detect PC

  2. Download code to memory from PC (if PC wants to. And write to RAM)
  3. Load Loadable Boot Entry Point from RAM(LB_ENTRY_POINT at 0x0087effc)
  4. Compare Product ID in RAM with Product ID in Flash (PRODUCT_ID_SECTION at 0x0087eff8)
  5. IF Product ID matches - CALL Loadable Boot Entry Point

Note1: Memory mappings are different for LB or MB

Note2: If only (correct) product ID is written to ram, the phone turns on and boots normally

Init01_01SoftwareInitialisation

  1. Setup GPIO pins
  2. Init filesystems (internal, mmc)
  3. Init WAP cache
  4. Check Keyboard for Hardreset
  5. Init EEprom
  6. Init SPI bus (for communication with DSP)
  7. Omega Initialisation ???
  8. Init layer1 ???
  9. Init Backlight and LED
  10. Init Sound
  11. Start Realtimeclock
  12. Detection of the switch-on condition

  13. Read settings from ("MMIFS:" "MmiSettings")

  14. Download DSP code via SPI bus

11.3. DSP

  1. DSP processor loads the DSP miniboot.
  2. DSP miniboot loads the DSP loadableboot.
  3. DSP loadableboot loads and uncompresses the main DSP application.

11.3.1. Loading the DSP miniboot

When the DSP is reset it runs a read-only on-chip bootloader which copies a block of code/data (64? Kilobytes) using a serial boot memory (eeprom?) mode.

The exact mode used (?) is dependant on the external pins BOOTM[3:0] (GPIO's). See SPRA375 from TI for more information. The block is formatted as a Boot Table, which contains information about where the code and data sections are load, how big the are, and the entry point for the execution.

The TMS30 build process uses a secure boot (secboot.exe) option which encrypts the bootloader, exact details aren't know but it seems to be just used to stop the bootloader from being tampered with. The result is the same as if the secboot option had not been used.

11.3.2. Executing the DSP miniboot and loading the DSP loadableboot

For the TSM30 the initial code entry point is at symbol _c_int00, this symbol is defined in rts55x.lib a C runtime support library provided by Texas Instruments.

The library sets up an execution environment (stack, bss, initialization code, etc.) and then calls miniboot's main method in dsp/dsp_drivers/download/src/down01miniboot.c . The main method initialises some of the DSP hardware (PLL, EMIF/SDRAM and SPI) needed to load the loadableboot.

Using the SPI interface the DSP initiates communication with the MCU to load the loadableboot image. The MCU will respond with the load address and execute address of the loadableboot image (set by load.exe?). The loadableboot image will then be downloaded and loaded into the load address.

The miniboot will then uses some assembly to call into the new loadableboot code.

11.3.3. Executing the DSP loadableboot and loading the DSP application

Initialization is similar to miniboot. FIXME

12. Tricks

12.1. Hard Reset

  1. Phone off. Hold all 3 keys on the left side of the phone while turning the phone on.
  2. Hold keys until phone is booted.
  3. Reboot phone.
  4. You should see --000%-- .. --100%--
  5. The process takes about 3-4 seconds

12.2. Key Codes

  1. Dial '####9999' to get the version number. (for tsm100: ####9999 or ####90 or *#9999#)
  2. Dial '##*#9374' to reset to factory defaults.
  3. Dial '####9998' to turn on monitor mode. Then use buttons on the left side of the phone to scroll through menus.
  4. Dial '####9997' to turn off monitor mode.
  5. Dial '####50' to turn on monitor mode(TSM100). Slide down the keypad and click on the battery in the left upper corner. (then uses as for tsm30)
  6. Dial '####51' to turn off monitor mode(TSM100).

13. Specs

The TI HERCROM400G2 (Calypso) Specification were found here:

  1. http://rapidshare.com/files/97747237/CAL207_V10.5.pdf.html

  2. http://rapidshare.com/files/97747378/calypso_c035.pdf.html

For legal reasons are we only allowed to publish the Index of the two documents on the wiki:

  1. Index TI HERCROM400G2 (Calypso) Specification

  2. Index TI HERCROM400G2 (Calypso) Register Mapping

14. Links

  1. MoviStar TSM30 Manual.

  2. TSM Bible in spanish (W.I.P)

  3. GSM DoS attack

  4. http://opensource.purplelabs.com/. Let's try to contact the original developers of the TSM software. Let's gather email adresses and infos.

  5. here you can download the firmware sourcecode

  6. Download 7.0 (to upgrade TSM30)

  7. TSM30 MMC firmware debugger

  8. TSM linux project spanish

  9. unfinished TSM linux bootloader spanish

  10. TSM 30 & 100 Forums spanish