nokia phone as SingleBoardComputer

[ilmarsj]

Hello,

I got an idea to use GSM phone for other purposes than phone conversations. For example as computer driving via serial port some piece of hardware. Peoples throwing away their phones containing alot of memory and processing power...

Somebody already did it?

At first I looking for appropriate (older, so, cheaper) phone model with plenty of hardware programming info - DCT3? 3310? Most important is working firmware(flash) loader source, then keyboard, display and serial stuff, maybe something else that I missed to mention (oh, yes, programmer h/w & s/w).

Any info & ideas?

Thanx in advance,

Ilmars

[wumpus]

I have a *lot* of info concerning the hardware level programming on nokia phones. (the 3310 in my case)
To be precise, an idea like yours came to me a while ago and I already started working on it.
I wanted to make my own Phone OS, with eCos or ucLinux or another open source RTOS as starting point. And I'm very close to having gathered the needed information and actually commencing development.

Things in my /home :
- Working and patched flash loader source - ready to send arbitrary programs
- located and researched the I/O for FIQ/IRQ handling, serial port (MBUS IRDA and FBUS) programming, lights, vibrator, buzzer, CCont (battery charger and power), keyboard, LCD

Well, maybe we could get some people to work on a project like that.

[sagarka]

hi m8s can u plz to explan that how the software work in the fone chep i mean to say that as we compair the mobile fone the cisco router in that a ram nvram flash and some other memory device and the a boot process
so can u plz to tell me that how mobilefone booting process or how the software comunicate with hardware or plz to give some usefull link which can help in this way
thanks in advance

[alberto_fiol]

A good project would be to have your phone disable your car in case that it might get stolen.

[ilmarsj]

Good project would be to make at first simple "phone OS", as wumpus said. Even without GSM functionality - only I/O. Then you can make "applications".

Have to say that "remote controllers" based on GSM phone call+hangup (one action) or call+keytones (many commands) are already available comercially...

[wumpus]

Adding GSM functionality would be something for later, and certainly a lot of work (unless someone has an open source GSM stack laying around, but I don't suppose so)

sagarka: I don't give all the information just yet, but concerning how the boot process works:
- Some boot ROM is invoked at address 0 (which later maps itself out, so address 0 is RAM ever after)
- The boot rom does some basic I/O initialisation mumbo jumbo
- It looks for a high serial line to see what action to do next
- If no flasher found on the serial port, jump to the flash ROM, offset 200040
- If a flasher program is found, send an ACK and receive a halfword 'length'
- Read 'length' bytes from the serial line into the DSP/MCU shared RAM (0x10000)
- Jump to address 0x10000 where the bootstrap is loaded

[g3gg0]

hi, nice to see someone who knows more than the most
nokia haxxors ;)

- will it enter 0x00010000 or 0x00010001 (ARM/THUMB) ?
- buzzer handling is done via DSP i thought (?)
i already found IO for buzzer access but it seemed, the DSP still has control over it ;(

[pico]

nokia haxxors
nokia patchers :p :rolleyes:

[wumpus]

It enters in THUMB mode (0x10001); really strange, but try to disassemble the bootstrap loader of your favorite flash program, it starts with CODE16 instructions (but the AlgoCode, loaded after that by the bootstrap at 0x0 DOES start with CODE32)
The bootstrap can only be 4k! (the size of the DSP shared ram) That's why I use modified algocode not bootstrap for testing purposes, it can use the whole first 64k of phone ram.

About the buzzer, It could be it is controlled by the DSP, although it doesn't look like it. It is not controlled by sending commands to the 0x10000 range. Or maybe it could, for example, serial (FBUS/IRDA) looks like it is hooked to both the MCU and DSP.

The exact numbers could be different between phones, but, on a 3310 I found this:


0002001C [2b][w] buzzer frequency
0002001E [1b][w] buzzer volume


The best way to find out would be to write a little program that buzzes a bit without initialising the DSP, and send that as AlgoCode..

[wumpus]

By the way, do you know why and what is written to 40000 at startup, and only at startup? (around 200040 still in ARM mode)
The first four bytes of flash at 200000 are reversed and written to 40000, one of the few mystery ranges still left in my I/O map.

[AlexD]

Write to 0x40002 some values (0x61, 0x55 ...) maps boot ROM out. Some other addresses in this range and/or other values do the same.
In attach listing of boot ROM (5110).

[wumpus]

Thanks! That's a great help

Other addresses in that range ought to do the same, because the memory range is only 4 bytes long.
(40004 40008 4000C until 7FFFC are mirrors of 40000, 80000 is the same as 00000 again)

Well, that's one mystery explained, this boot ROM is probably the same in all DCT3 models, as it's embedded into the MAD.

[wumpus]

I added some more comments explaining most of the I/O performed. (except for the Mr Memory Mapper part at 0x40000, which IMO does not map out the ROM, but maps in the Flash, because else it would kick itself out under it's own ass :-)
ARMs prefetch is not large enough to hold the remaining instructions... the ROM is either mapped out in the flash rom itself by that write to 0x40000, OR by the first write to the 0x000000 range (as in some other embedded systems)

[AlexD]

ROM maps out by writing to 0x4000x. I checked it directly, using debugger, CPU was stopped at this moment.
Flash is always mapped to address space. You may see code at 0x7c - this is reading from 0x200001. It checks for blank Flash.
I don't know how big is ARM prefetch, but executing this code in normal speed works OK, and executing it step-by-step fails at address 0x86 - ROM doesn't exist.

[wumpus]

well, then the prefetch *is* big enough

using debugger? how do you do that? Do you need special hardware?

[AlexD]

There are JTAG pins on pcb - I use them.
Hardware is special - XDS560, emulator from TI.
It is a bit expensive, but I think there are another tools, wiggler, for example. But I did not try them.

[g3gg0]

wooow.. :)
finally something new outta there :))

so, are you interested in sharing knowledge about LCD also?

now im trying to hack some test function for basic I/O
into flash..

what compiler yo u use for your tests? i tried GCC as crosscompiler
but i didnt get lucky with its THUMB code generation (endian suckness)
so im still hacking pure asm ;(


EDIT:
hmm i run in trouble... tried to place my own code an the flash
entry point 0x00200040...
but as i expected nothing will happen ;(
are the IOs always mapped, or do i have to map them in
somehow before i try to access them?

.sub main
dd e28f0001
// ADR R0, [PC, #1]
dd e12fff10
// BX R0

@loop:
ldr r0, @addr
mov r1, 0x02
strb r1, r0, 0
b @loop

@addr:
dd 00020033

[Ice Draagon]

I LIKE IT, I LIKE IT! (Sorry got me excited)

Well, 3310 would be an appropriate starting point since it has an ample flashRAM and emulated EEPROM. Then maybe later we could move on to 6210 with bluetooth features for more controlling power.

Although you might have started the project already, I just need to know how to disassemble the ARM/Flash content and what programs to use, like to debug and/or emulate the ARM assembly commands.

Then references/links to the ARM assembly commands/op codes will also be needed.

Various maps to the Nokia memory on how it uses it and where and how the data are stored and retrieved.

Anyway, what I'm trying to say is you can count me in with the project.

PS: Regards to Wumpus, I'm seeing another Tibor/Knok in the making :D I mean I admire your determination about this subject (flash program reversing and re-programming)


Originally posted by ilmarsj
Hello,

I got an idea to use GSM phone for other purposes than phone conversations. For example as computer driving via serial port some piece of hardware. Peoples throwing away their phones containing alot of memory and processing power...

Somebody already did it?

At first I looking for appropriate (older, so, cheaper) phone model with plenty of hardware programming info - DCT3? 3310? Most important is working firmware(flash) loader source, then keyboard, display and serial stuff, maybe something else that I missed to mention (oh, yes, programmer h/w & s/w).

Any info & ideas?

Thanx in advance,

Ilmars

[wumpus]

Originally posted by g3gg0
wooow.. :)
finally something new outta there :))

so, are you interested in sharing knowledge about LCD also?

They use a Philips PCD8544 chip for the 3310, there are datasheets for that thing everywhere around :)


Programming ports having to do with LCD:
2002D GENIO control write
Write 0x2D here before LCD or CCont programming
2002E LCD data write
20032 Generic parallel I/O
bit 5 LCD controller reset
2006D LCD command ready register
bit 0 LCD controller data/command write ready
bit 1 GENIO control write ready
bit 2 CCont read ready
2006E LCD command write




what compiler yo u use for your tests? i tried GCC as crosscompiler
but i didnt get lucky with its THUMB code generation (endian suckness)

Pure assembly... But there ought to be a command line option for GCC to set endianness? No? :( That would sooo suck.
Although endian reversing the GNU assembler would not be that much work, I'd rather spend my free time hacking nokia flash instead of GNU tools..



EDIT:
are the IOs always mapped, or do i have to map them in
somehow before i try to access them?

AFAIK the I/Os are always mapped, but some devices need an explicit initialisation sequence. (the DSP being the worst by far..)



@loop:
ldr r0, @addr
mov r1, 0x02
strb r1, r0, 0
b @loop
@addr:
dd 00020033
[/quote]
This is not enough to enable the lights on a newer 3310, you need to set:
20033 bit 2 (you did)
20020 bit 2
20024 bit 2

[wumpus]

Originally posted by Ice Draagon
Well, 3310 would be an appropriate starting point
I have a 3310, that's why I use it as a starting point :) And it has nice firmware tracing and debugging 'features'


Although you might have started the project already, I just need to know how to disassemble the ARM/Flash content and what programs to use, like to debug and/or emulate the ARM assembly commands.

I don't have an ICE (in circuit emulator) like AlexD, I just disassemble the flash in IDA.


Then references/links to the ARM assembly commands/op codes will also be needed.

Enough of those floating around on the net...


Various maps to the Nokia memory on how it uses it and where and how the data are stored and retrieved.

Yeah, we'd all really like to have those, the problem is we have to research those ourself as Nokia would never publish them :-)
I have made a quite large map already which I'll post in the near future.


Anyway, what I'm trying to say is you can count me in with the project.

Cool :)


PS: Regards to Wumpus, I'm seeing another Tibor/Knok in the making :D I mean I admire your determination about this subject (flash program reversing and re-programming)

Thanks... Actually I started with Knok source, and changed it into something far more evil :D
I now execute code from RAM, not ROM, so I won't have to reflash my phone for every little test.

I only need a good ARM+THUMB compiler.. The GNU stuff is great, provided you can set the endianness to the lesser braindead setting. I'd really go MAD if that wouldn't be the case, they have zillions of features and switches, why not that one..

Hmm I'll do some research into that soon.. I'm stuck in the GSM LAPDm packet layer right now.

[g3gg0]

Originally posted by wumpus

They use a Philips PCD8544 chip for the 3310, there are datasheets for that thing everywhere around :)


Programming ports having to do with LCD:
2002D GENIO control write
Write 0x2D here before LCD or CCont programming
2002E LCD data write
20032 Generic parallel I/O
bit 5 LCD controller reset
2006D LCD command ready register
bit 0 LCD controller data/command write ready
bit 1 GENIO control write ready
bit 2 CCont read ready
2006E LCD command write



ahhha, thx :)



Pure assembly... But there ought to be a command line option for GCC to set endianness? No? :( That would sooo suck.
Although endian reversing the GNU assembler would not be that much work, I'd rather spend my free time hacking nokia flash instead of GNU tools..


yes, there is such option but in my case the assembler that is
called by gcc complained about endian mismatch although i
gave GCC the little endian parameter... maybe it was a bug in
the version i used.. i tried it under cygwin 'cause i didnt want
to compile it... gcc takes much tooooooo long *g




AFAIK the I/Os are always mapped, but some devices need an explicit initialisation sequence. (the DSP being the worst by far..)



This is not enough to enable the lights on a newer 3310, you need to set:
20033 bit 2 (you did)
20020 bit 2
20024 bit 2 [/QUOTE]

hmm didnt work either ;(

hmm wasnt it on the old ones just:
0x02 -> 0x00020033 (all leds)

and on the newer (split kbd/lcd leds):
0x02 -> 0x00020033 (kbd leds)
0x08 -> 0x00020024 (enable lcd LED ctrl)
0x08 -> 0x00020020 (lcd leds)


BTW:
do u have ICQ/MSN/Y! ?
icq: 59768616
msn: [email protected]
y!: g3gg0

[wumpus]

hmm wasnt it on the old ones just:
0x02 -> 0x00020033 (all leds)

and on the newer (split kbd/lcd leds):
0x02 -> 0x00020033 (kbd leds)
0x08 -> 0x00020024 (enable lcd LED ctrl)
0x08 -> 0x00020020 (lcd leds)

So port 20024 masks port 20020 or something alike... makes sense, the Nokia 3310 schematics I have is the old version without seperate led control.
I actually didn't know what the exact ports did, and I was wrong with saying bit 2 of register 20033, it's bit 1 of course (I've been reading too many of thsoe braindead GSM standards documents that start counting bits at 1 lately..)


BTW:
do u have ICQ/MSN/Y! ?
icq: 59768616
msn: [email protected]
y!: g3gg0
Yes I do, I'll add you when I'm on MSN again

[g3gg0]

jippie it works now.....

i left the ARM initialization code at 0x00200040 in the flash...
and inserted my code at 0x00200148
so now i have some new kind of playground ;)
thx

@wumpus/AlexD:
interested to join the nok5rev group?

[AlexD]

I'm using compiler from TI, it works fine (both ARM and THUMB).
There is eval version (time limited) and this restriction can be removed...

I only recently began work and try to research DSP stuff.
Are there any DSP rom listings?


interested to join the nok5rev group?
It would be interesting
icq:39461884

[g3gg0]

Originally posted by wumpus
[B]
They use a Philips PCD8544 chip for the 3310, there are datasheets for that thing everywhere around :)


Programming ports having to do with LCD:
2002D GENIO control write
Write 0x2D here before LCD or CCont programming
2002E LCD data write
20032 Generic parallel I/O
bit 5 LCD controller reset
2006D LCD command ready register
bit 0 LCD controller data/command write ready
bit 1 GENIO control write ready
bit 2 CCont read ready
2006E LCD command write



hmm are you sure about the 0x2D -> 0x0002002D?
or was it 0x25 -> ...?

[wumpus]

From the firmware:


ROM:002EC26E LDR R4, =unk_20000
ROM:002EC270 MOV R1, #0x2D
ROM:002EC272 MOV R0, #0x25
ROM:002EC274 STRB R0, [R1,R4]

So yes it is 0x25 for LCD... I was kind of in a hurry when I typed that, so I got it wrong

What does the nok5rev group exactly do? If it's decyphering the firmware/hardware I'm interested for sure..

[g3gg0]

Originally posted by wumpus
From the firmware:


ROM:002EC26E LDR R4, =unk_20000
ROM:002EC270 MOV R1, #0x2D
ROM:002EC272 MOV R0, #0x25
ROM:002EC274 STRB R0, [R1,R4]

So yes it is 0x25 for LCD... I was kind of in a hurry when I typed that, so I got it wrong

What does the nok5rev group exactly do? If it's decyphering the firmware/hardware I'm interested for sure..

u guessed right ;)
http://www.geocities.com/nok5rev/

just contact me @ [email protected]
and i will manage that nok5rev will add you


EDIT:
okay, update :)
i made the LCD ready for access, yippie it works
krisha makes the keypad things (already has) and we have basic IO :)

so now we need some IO's so we can control something
external (2 lines would be enough for I2C)

[wumpus]

Okay I made a heck of a lot of progress today..

On my linux dev box I built a GCC cross compiler tool chain for arm big endian, thumb mode. (cygwin compiles slowwww) I fooled somewhat around with linker scripts and managed to create binaries without the ELF header with objcopy.

I also made a crt0.o that does the basic ARM setup mumbo jumbo the stuff at 0x20040 does and calls my thumb main() function.
Now I have a minimal OS running with routines to control
- keypad
- ccont (including read A/D converters and dumping statistics to the host pc) (used for with power-off on shutdown)
- LCD with contrast effects (was more work than I thought, on a certain moment I misplaced a lcd controller reset instruction somewhere and wondered why I didn't see anything :P)
- bidir synchronous serial communication (flash cable). I could do MBUS but for debugging it's easier to just leave that cable attached.
- read timestamp for exact millisecond delay
- buzzer
- vibrator
So much for the device driver part, now I'm going to look into a real operating system. (and I'm probably going to need timer and more IRQ/FIQ handler than "blink the lights")

I2C.. hmm.. actually that should be possible, you have three lines; FBUS RX (in), MBUS(switchable tx/rx) and FBUS TX (out).
Standard mapping in synchronous mode is:
- FBUS RX -- SCLK in
- FBUS TX -- SDA out
- MBUS -- SDA in
Reading is done byte by byte, sending must be done by bit on a each low SCLK.
But that would make it a I2C slave, not master, not really that useful

[g3gg0]

i really would be pleased if you somehow could send me that bunch
of code to [email protected]

how the hell did u get GCC to litlle-endian mode?! :)
now finally my lovely C on a nokia phone..

....dreams come true....



krisha and me also did some 'os' but not so comfrotable as yours
but all in asm;)

- keypad routines (dont work, because IOs need to have configured?)
- LCD control
- LED control
- used nokia's 20040 code

but... its rather minimalistic *g
all written in ASM


u know? the int handlers are at ram addr 0
INT0-INT7 each one 1 ARM opcode (which will be an EA xx xx xx, a longjump with 0x00200000+4*x bytes )
thats the reason why nokia maps out the rom and maps in the
RAM at this address.. so the ARM chip has the OS's intvectors
not the BIOS' ones

but i guess u already figured out :rolleyes:

[g3gg0]

$ /home/-gamez-/gccarm/arm-thumb-elf/bin/as -mlittle-endian -mthumb-interwork -EB -mcpu=arm7tdmi crt0.s
$ /home/-gamez-/gccarm/arm-thumb-elf/bin/arm-thumb-elf-objcopy.exe -Obinary a.out b.out

finally worked...
mixed up big endian and little endian
thats the reason i got confused ;)

EDIT:


are the "header" bytes until 0x00200040 somehow important
for the MAD BIOS?
did u leave the bytes in the header or did u a completely clean
flash with 00's in header?
except the 2nd byte that gets written to 0x40000

[wumpus]

great you got it too work too :)

I'll publish some code in the very near future but it's still a such gory mess I don't dare release anything :-)

I have looked at ucLinux and it's great, but it doesn't work with less than about 2MB RAM (the 2MB ROM/flash is more than enough, but the ram is so very limited..), yuck.. the choice of eCos remains (although a tight fit), or some other mini realtime embedded OS.

AFAIK the flash at 20004-20040 is never referenced, so you could use 20004-20040 if you really wanted to squeeze out the few extra bytes. (but some flashers might not recognize it as a nok firmware anymore)

I have not tested it yet as I use a different approach, my O/S currently does not use flash at all but loads into RAM at 0 and runs..
Mind it I don't have a seperate phone to play with, I'm going to get one soon, but until then I'll have to keep this firmware running.

[g3gg0]

hi!

i also made much progess :)

http://64.246.26.121/forum/showthread.php?t=56927

this is a little demo.. it wont run on all 3310/3330's but i
dont know why ;( the LCD stays blank...
i can try to push up the contrast to maximum but it wont help
i also did a pause of half a second BEFORE reset LOW, a half
second pause after the LOW, then raised reset and did again
half a second pause... nothing helped

krisha tested for me, since i dont have a non-working lcd..
i just have three working phones/LCDs, shit ;(

if i'm at home again, ill send u my code...
it relies on GNU GCC compiler suite for ARM-THUMB...

--
@all:
i set up a complete cygwin package for those who dont
want to mess around with configuring it.....
the complete package just is <20MB and contains all u need
i'll give u an URL where u can DL it
--

its a compile.sh that will:

- compile the crt0.s which will be the header and init code
- compile all .c files
- link the resulting objects
- dump the objects and create a 65k flash file out of it (using dd)
- this file i ready to flash without further modification

and a compile_pc.sh that will compile all the .c code into a .exe
so one can test the graphic things without the need to flash..
its somewhat helpful for these tweaky graphic overlays/merge ;)

the cr0.s does:

- 1st two bytes header "0x20 0x65"
- set up some io crap (dont know what exactly *g)
- set up the irq table
- copy .data section into RAM (static non-const variables with init value)
- call the C code in THUMB mode

the .c files already support:

- LED control/fade
- LCD init / contrast / fade / char rendering
- IO routines for smarter coding / io_wait_bit to wait for a bit

maybe we can merge code somewhen :)
if u think ur code is a mess just send it to me, i will clean it up
and merge it myself so we can release it
is it written in C or ASM?
i prefer to WRAP the basic things that are written in ASM into C code..
the rest is better some high-level laguage (C)
the C compiler produces really good code (at least sometimes ;p )
some other times it was too braindead ;(
but only when i tried to combine C and ASM code in one function..
..."volatile" is your friend...



2 questions...
did u already analyse how the flash bootloader will disable
the damn watchdog timer? when my code starts up directly
after it was flashed, the CCONT (?) WONT take off the power
supply... the code runs and runs... but if i normally start up the
phone with pwr button after 30 secs the watchdog will bite my
power ;)
nokia datasheet says, i have to raise the WD line every 8 secs
(at least orig soft does)
do u have the knowledge how to disable the WDT or even
how to raise the WD line so the dog will keep sleeping?

and do u know the data direction registers for the keypad io's?
AlexD told me some for 5110, but the io's used in the same code
piece in 3310 didnt help me :( nothing happened

either the code that will read out the keypad pots is buggy
(i dont think so because we use it for months now injected in nokias code)
or i miss something in setting up the IO's
i already tried to do the first x tons of IO port writes also
in my routines but no success...
keypad reading routine didnt work...

what did u do that your keypad reading worked?



hmm i also set up not a JTAG interface on a test-6110...
wow this was easy ;)
right left of the MAD there are some VERYYYYY small pads
i think some 15 or 16 solderpads
just wired the TRES to VCC with an 100Ohm res
and connected

TDI -> LPT pin2
TCK -> LPT pin3
TMS -> LPT pin4
TDO -> LPT pin13
GND -> LPT pin25

then got some linux/cygwin jtag test app (jtag-0.4)
set it up for cable "Xilinx DLC5" (above wiring)
and it recognised an unknown device.. :)
then i "just" made a JTAG description file for that device
and i could do something via JTAG yippiee.....
at least i got some resets *g

but didnt help much since i want a user interface with data
reading and single stepping etc etc... odd, i didnt find something
working for free ;(


maybe i find some time again to experiment with the JTAG
commands like SCAN_N for chain 2 where i may have the chance
to stop the cpu and set some breakpoints
but its all too new for me... i didnt even know how the
JTAG chain works internally....

tooooo fewww time ;(

[wumpus]

Hey I want one of those too (JTAG connector) :-)

AFAIK the dog programming:


Turn it off: (might induce sleepmode, more like coma)
io_write 0x20003 0xFF
ccont_write 0x06FF 0x3F (nokia os style ccont register addr, real register is 0x05<<3)

Reset to 32 seconds:
io_write 0x20003 0x31
ccont_write 0x06FF 0x31 (nokia os style ccont register addr, real register is 0x05<<3)

Turn off phone @ now:
ccont_write 0x06FF 0x00 (nokia os style ccont register addr, real register is


The data direction registers for the keypad are


20028,2002A input/output register
200A8,200AA configuration (1=output,0=input)

It has more registers for generating Interrupts and other arcane and yet unknown purposes..
What are those for the 5110? I could match them against the info I have and determine which have to do with data direction.
Did you find the init_keypad code in Nokia flash?


ROM:002E8ED8 LDR R4, =unk_20000
...
ROM:002E8EEA MOV R1, #0x6A ; 'j'
ROM:002E8EEC MOV R0, #0x20 ; ' '
ROM:002E8EEE STRB R0, [R1,R4]
ROM:002E8EF0 MOV R1, #0x2A ; '*'
ROM:002E8EF2 MOV R0, #0x3F ; '?'
ROM:002E8EF4 STRB R0, [R1,R4]
ROM:002E8EF6 MOV R0, #0x6B ; 'k'
ROM:002E8EF8 MOV R1, #0x60 ; '`'
ROM:002E8EFA STRB R1, [R0,R4]
ROM:002E8EFC MOV R1, #0xAB ; '½'
ROM:002E8EFE MOV R0, #0x1F
ROM:002E8F00 STRB R0, [R1,R4]
ROM:002E8F02 MOV R1, #0xA8 ; '¿'
ROM:002E8F04 STRB R0, [R1,R4]
ROM:002E8F06 MOV R2, #0x28 ; '('
ROM:002E8F08 MOV R1, #0
ROM:002E8F0A STRB R1, [R2,R4]
ROM:002E8F0C MOV R1, #0x68 ; 'h'
ROM:002E8F0E STRB R0, [R1,R4]
ROM:002E8F10 MOV R1, #0x69 ; 'i'
ROM:002E8F12 STRB R0, [R1,R4]
ROM:002E8F14 MOV R1, #0xA9 ; '®'
ROM:002E8F16 STRB R0, [R1,R4]


Strange thing:
ROW5 pin on MAD is used for LCD Data/Command
COL5 pin on MAD is used for LCD CSX
Somehow they are not routed to the default registers.

[g3gg0]

hi :)

thanxx for that info!
did u analyse how the ccont_write routine works yet?
or is this ccont write not necessary?

here is the code snippet of the 5110 initialisation
routine... AlexD found it via JTAG... its called by the
first function in tha task0



ROM:0029042E LDR R4, =unk_20000
...
ROM:00290440 MOV R1, #0x2E ; '.'
ROM:00290442 MOV R0, #0x20 ; ' '
ROM:00290444 STRB R0, [R1,R4]
ROM:00290446 MOV R1, #0x30 ; '0'
ROM:00290448 MOV R0, #0x3F ; '?'
ROM:0029044A STRB R0, [R1,R4]
ROM:0029044C MOV R0, #0x33 ; '3'
ROM:0029044E MOV R1, #0x60 ; '`'
ROM:00290450 STRB R1, [R0,R4]
ROM:00290452 MOV R1, #0x32 ; '2'
ROM:00290454 MOV R0, #0x1F
ROM:00290456 STRB R0, [R1,R4]
ROM:00290458 MOV R1, #0x2F ; '/'
ROM:0029045A STRB R0, [R1,R4]
ROM:0029045C MOV R2, #0x31 ; '1'
ROM:0029045E MOV R1, #0
ROM:00290460 STRB R1, [R2,R4]
ROM:00290462 MOV R1, #0x23 ; '#'
ROM:00290464 STRB R0, [R1,R4]
ROM:00290466 MOV R1, #0x26 ; '&'
ROM:00290468 STRB R0, [R1,R4]
ROM:0029046A MOV R1, #0x27 ; '''
ROM:0029046C STRB R0, [R1,R4]

[hanzelko]

Hi, all

Count with me on this project, too. I want to make OS for phonia phones too.
For studing and reversing I have made an Nokia 5110 v. 5.24 Simulator. ARM/Thumb emulator taken from GCC GDB and added nokia IO watching and emulating. So far the phone can boot in emulator and ends with Insert SIM card message, but keys can be pressed and showed. The phone volume control works,too. It behaves as N5110 with no SIM card inserted. There are some bugs in the emulator but it can be usefull somewhat. (You can see history what was written/readed to ports, from which address, in which task and so on. It can enter debug mode (but without dissasemebler). It is something like WinARM but without dissasembler but with history of writes/readings to IO ports or RAM and a little bit speedy.
). It is useable only from source code (Configuration of watched calls, watched addr, debug entry must be typed in source code for now). It is MFC VC++ project.
Source can be downloaded from nok5devel yahoo group.

[pico]

@hanzelko,
where is that group please?
i searched yahoo groups..

[hanzelko]

This group is not public like nok5rev is not public group.

[capotixplus]

So, can you invite us? can you provide group's moderator email for entrance apply ??

[hanzelko]

send mail to [email protected]

[pico]

mail sent. 10x thanks:)

[wumpus]

I'm making a site with the info I gathered myself, not sure yet whether to make it open or closed.

[rani_bracha]

[rani_bracha]

Originally posted by AlexD
There are JTAG pins on pcb - I use them.
Hardware is special - XDS560, emulator from TI.
It is a bit expensive, but I think there are another tools, wiggler, for example. But I did not try them.


I try to debug 5110 code (ARM only) with Lauterbach ICD I put my hands on lately (!!). I get no response to reset.

Do I need to foloow some steps? namely turn on the mobile, wait some seconds, etc. ?
Do I need to do something with EMUL0 and EMUL1 ?
Do I need special script to run on the debuger ?
There are two clock pins in the ICD. which one to use ?
thanks
:confused:

[AlexD]

Originally posted by rani_bracha



I try to debug 5110 code (ARM only) with Lauterbach ICD I put my hands on lately (!!). I get no response to reset.

Do I need to foloow some steps? namely turn on the mobile, wait some seconds, etc. ?
Do I need to do something with EMUL0 and EMUL1 ?
Do I need special script to run on the debuger ?
There are two clock pins in the ICD. which one to use ?
thanks
:confused:

I didn't work with this emulator, so only common things.
I use no special steps, no special scripts.
Emu0 and emu1 may be left unused, i think.
You must remember one thing: internally jtag chain of MAD2 consists of ARM (4 bit) and DSP (8 bit), connected serially. So your software must understand jtag chains and be capable to put DSP in bypass mode.
Texas has c547x series, which are quite similar to MAD2 (but not the same). They can be put in ARM-only jtag mode by using pins emu0/emu1, but i couldn't achieve this at 5110. May be you will be more lucky.

[rani_bracha]

Originally posted by AlexD


I didn't work with this emulator, so only common things.
I use no special steps, no special scripts.
Emu0 and emu1 may be left unused, i think.
You must remember one thing: internally jtag chain of MAD2 consists of ARM (4 bit) and DSP (8 bit), connected serially. So your software must understand jtag chains and be capable to put DSP in bypass mode.
Texas has c547x series, which are quite similar to MAD2 (but not the same). They can be put in ARM-only jtag mode by using pins emu0/emu1, but i couldn't achieve this at 5110. May be you will be more lucky.

I read in the C5470 datasheet that if the EMU0 and EMU1 are low during reset, the DSP will be in bypass. But I have another problem. When I look on the TRST, TCLK and TDI with my (good old) scope I see the bits, but I can't see no activity with the TDO !
The 5110 just don't response to the ICD commands.

I just might get an old XDS510 (not (560) in couple of days. Which software did you used to run the XDS?
Did had to make a special cable (short some pins/pullup/pull down) or just simple pin to pin cable?

thanx a lot !!
:)

[AlexD]

I just might get an old XDS510 (not (560) in couple of days. Which software did you used to run the XDS? Did had to make a special cable (short some pins/pullup/pull down) or just simple pin to pin cable?

XDS510 will be OK.
I use Code Composer Studio 2.2 from TI. There is free eval version, but it doesn't support emulators, but AFAIR eval 2.1 did it. Anyway, normal commercial version works ok.

Cable is simple pin-to-pin.
To power-on phone and disable watchdog I use switch, which shorts WDDIS to ground.

[rani_bracha]

Originally posted by AlexD
I just might get an old XDS510 (not (560) in couple of days. Which software did you used to run the XDS? Did had to make a special cable (short some pins/pullup/pull down) or just simple pin to pin cable?

XDS510 will be OK.
I use Code Composer Studio 2.2 from TI. There is free eval version, but it doesn't support emulators, but AFAIR eval 2.1 did it. Anyway, normal commercial version works ok.

Cable is simple pin-to-pin.
To power-on phone and disable watchdog I use switch, which shorts WDDIS to ground.

I grounded WDDIS, but I just can't get no response from the 5110 to reset request, TDO is silent.. any more lines to handle (besides TDO, TDI, TRST, TCLK, TMS and WDDIS)? special JTAG command to wake it?
:confused:

by the way, I can't find AFAIR debugger. Which company makes it? where can I find it?
thanks!

[AlexD]

I used jtag with 3310 and 5110 - everything was ok.
Run some diagnostic software.
Does your software know about DSP, connected serially with ARM? You must handle it.

AFAIR == As Far As I Remember

[rani_bracha]

Originally posted by AlexD
I used jtag with 3310 and 5110 - everything was ok.
Run some diagnostic software.
Does your software know about DSP, connected serially with ARM? You must handle it.

AFAIR == As Far As I Remember

ok..
which diagnostic software? the 5110 seems to work fine (make calls, etc..)
Are you using the C5000 CCS or OMAP version?
Is the CCS handles the distinguishing between the ARM code and the DSP code? Do you handle it somehow? (you said you couldn't disabled the DSP in 5110 by EMU0 and EMU1).
Can you see both (ARM & DSP) code, or just one of them?
thanx!!

[AlexD]

I mean diagnostic software for jtag path, not for phone.
For XDS510 run:
xdsprobe -F -p 0 -i -o results.txt
Until you get something like that you cannot move further.
-------------------------------------------------------------------
The test for the JTAG IR instruction scan-path length succeeded.
The JTAG IR instruction scan-path length is 12 bits.

The test for the JTAG DR bypass scan-path length succeeded.
The JTAG DR bypass scan-path length is 2 bits.

The scan-path appears to consist of exactly two devices.

If the scan-path consists of only TI DSP chips, TI ARM cores
and TI micro-controllers, or 8-bit long bypassed devices,
then the measured lengths indicate that both the
link-delay and scan-path are configured correctly.
-------------------------------------------------------------------

Software must be CCS OMAP. It is a combination of CCS for ARM and for c5000.
Because jtag for DSP disabled (security fuse), you may work only with ARM code.
In normal chips (c547x) both subsystems work.

[rani_bracha]

Originally posted by AlexD
I mean diagnostic software for jtag path, not for phone.
For XDS510 run:
xdsprobe -F -p 0 -i -o results.txt
Until you get something like that you cannot move further.
-------------------------------------------------------------------
The test for the JTAG IR instruction scan-path length succeeded.
The JTAG IR instruction scan-path length is 12 bits.

The test for the JTAG DR bypass scan-path length succeeded.
The JTAG DR bypass scan-path length is 2 bits.

The scan-path appears to consist of exactly two devices.

If the scan-path consists of only TI DSP chips, TI ARM cores
and TI micro-controllers, or 8-bit long bypassed devices,
then the measured lengths indicate that both the
link-delay and scan-path are configured correctly.
-------------------------------------------------------------------

Software must be CCS OMAP. It is a combination of CCS for ARM and for c5000.
Because jtag for DSP disabled (security fuse), you may work only with ARM code.
In normal chips (c547x) both subsystems work.
-------------------------------------------------------------------

After the '-F' in the xdsprobe command should be file name of the emulator? such as?
I've installed the OMAP version (and not TMS470) as the XDS510 drivers. OK?
Could you please attach the right dvr file? the gel file?
which processor to choose from the list in the available processors (System configuration->board properties->processor configuration)?
By the way, did you short pins 9 & 11 in the JTAG connector (RTCK & TCK)? left RTCK un connected?
thanx a lot :) :)

[AlexD]

1. No. -F means: Avoiding Use of Configuration Files.
2. OMAP is OK.
3. You MUST connect together TCK and RTCK. It is self-evident.
Wires must have minimal length. It is better to connect TCK and RTCK directly on phone board.
4. In CCS Setup choose File->Clear
On right side press Install a Device Driver, choose tixdsarm7.dvr
From middle column drag this driver to left column.
In Processor configuration add single tms470r13
and add single bypass (8 bit) (In this order!)
Do not choose any gel file.

[rani_bracha]

Originally posted by AlexD
1. No. -F means: Avoiding Use of Configuration Files.
2. OMAP is OK.
3. You MUST connect together TCK and RTCK. It is self-evident.
Wires must have minimal length. It is better to connect TCK and RTCK directly on phone board.
4. In CCS Setup choose File->Clear
On right side press Install a Device Driver, choose tixdsarm7.dvr
From middle column drag this driver to left column.
In Processor configuration add single tms470r13
and add single bypass (8 bit) (In this order!)
Do not choose any gel file.


I've got responses from the 5110 !!
Sdconfig succeeds in resetting and succeeds to identify the chain.
But when I run CCS it says it can't reset the target and therefore shuts down.
By the way, in my tixdsarm7.dvr there is no tms470r13, but tms470r1x only. Might be that my driver is different? I'm using eval CCS (2.1).
When I config the CCS with sdgoarm7.dvr (taken from drivers supplied by Spectrum Digital) the CCS is satisfied, and I see something like code, but the 5110 clears its screen (shuts down??), and I can't do "single step", set breakpoints, etc. CCS claims the DSP is halted (down, left) but when I ask it to run, I get an error that its already running !! What can I actually do with the CCS ?
Is your 5110 seems working (LCD) while you debug it?
ideas??
:)

[st1]

Originally posted by wumpus
By the way, do you know why and what is written to 40000 at startup, and only at startup? (around 200040 still in ARM mode)
The first four bytes of flash at 200000 are reversed and written to 40000, one of the few mystery ranges still left in my I/O map.

I think that the registers at 0x40000 control the system bus timing and flash memory/boot rom mapping.

Try writing to 0x40001 - it looks like bits 0-6 adjust the cpu speed. On my nokia 3410, it is 0x0f by default. If I write 0x01 into this location, the cpu runs a lot faster.

Maybe there is a PLL for generating the CPU clock from the 13MHz input and 0x40001 is the output clock divider?

example values (defaults on 3410 AFAIK):

addr hex binary
0x40000 0x59 (b01011001)
0x40001 0x0f (b00001111)
0x40002 0x65 (b01100101)
0x40003 0x20 (b00100000)

I've also seen:

addr hex binary
0x40000 0xee (b11101110)
0x40001 0x17 (b00010111)
0x40002 0x65 (b01100101)
0x40003 0x20 (b00100000)

[st1]

Originally posted by wumpus
It enters in THUMB mode (0x10001); really strange, but try to disassemble the bootstrap loader of your favorite flash program, it starts with CODE16 instructions (but the AlgoCode, loaded after that by the bootstrap at 0x0 DOES start with CODE32)
The bootstrap can only be 4k! (the size of the DSP shared ram) That's why I use modified algocode not bootstrap for testing purposes, it can use the whole first 64k of phone ram.

About the buzzer, It could be it is controlled by the DSP, although it doesn't look like it. It is not controlled by sending commands to the 0x10000 range. Or maybe it could, for example, serial (FBUS/IRDA) looks like it is hooked to both the MCU and DSP.

The exact numbers could be different between phones, but, on a 3310 I found this:


0002001C [2b][w] buzzer frequency
0002001E [1b][w] buzzer volume


The best way to find out would be to write a little program that buzzes a bit without initialising the DSP, and send that as AlgoCode..

Yes, it works.

I've had to set bit 5 of 0x20015 first before I could get any sound from the phone (my bootcode doesn't initialise all the hw yet).

It looks like that 0x2001c sets the period, the buzzer frequency can be calculated as follows:

fBuzzer = fSys / period

fSys = 13MHz
period = 32768 (for example)
so the output frequency, fBuzzer is 3.17kHz.

I would assume that 0x2001e sets the output PWM duty cycle:

0 = 0% (totally off)
127 = 50% (loudest)
255 = 100% (totally on)


Good work there :)

[wumpus]

Yup that is exacly how it works :)

the bits in 0x20015 switch certain things like MBUS, Vibro and Buzzer on and off

the bit numbers are on my site (see PM), didn't know yet the buzzer PWM went from 00-FF in the full range though

[AlexD]

Originally posted by rani_bracha
I've got responses from the 5110 !!
Sdconfig succeeds in resetting and succeeds to identify the chain.
But when I run CCS it says it can't reset the target and therefore shuts down.
By the way, in my tixdsarm7.dvr there is no tms470r13, but tms470r1x only. Might be that my driver is different? I'm using eval CCS (2.1).
When I config the CCS with sdgoarm7.dvr (taken from drivers supplied by Spectrum Digital) the CCS is satisfied, and I see something like code, but the 5110 clears its screen (shuts down??), and I can't do "single step", set breakpoints, etc. CCS claims the DSP is halted (down, left) but when I ask it to run, I get an error that its already running !! What can I actually do with the CCS ?
Is your 5110 seems working (LCD) while you debug it?
ideas??
:)

I see tms470r13 in tixds560arm7.dvr (for XDS560). It doesn't matter.

LCD clears because CCS resets CPU and hence LCD is in reset too. You need to re-init it.
CCS is a little buggy with MAD2, I don't know why.
To bring it to work, I usually do hw reset to MAD2 (short PURX to GND) and then do Debug->Reset CPU. It helps.

Do not forget that usual breakpoints do not work in flash. You must use hardware breakpoints.
The other things work as expected.
To switch between 32 and 16 bit code use Option->Disassembly style.

[pseudonym]

Hey guys,

I got quite some years of reverse engineering experience on x86
processors but I know sh*t about mobile phone technology and ARM
processors. Anyway, I had some nice ideas which I want to try to achieve at least (one of them would be learning ARM assembly) ;)
What do you think about the idea to implement a little encryption
(I'd say XOR at first, as it should be quite easy) into the phone, so your phone can not be scanned by usual frequency scanners.
If this is possible at all (I know even less about hardware than about software) we could even implement some algorithms to change (pitch etc.) your voice. The reason for saying "if this is possible at all" is that I don't know how the voice will internally be converted from an analogue signal to the digital equivalent. The phone might convert it using a seperate chip, but the converted data might be processed by the firmware in some way, which would be good for us, since we want to modify it.
I'll mainly use IDA Pro (www.datarescue.com) to analyze the firmware.
I would really be looking forward to some people who could help me getting started in Nokia reverse engineering, writing technical documents and maybe build a little team (wampus I'm impressed by your findings).
Are you guys on iRC ?

cheers

[cyriliano]

guys did someone try to make software for comunicate with phone cpu thru jtag.I make soft to flash motoorola t191 with jtag the hardware is very simple just 5 wires but cannot get 2 ID's on TI and ARM on jtag chain.Do you have any experience with this?

[g3gg0]

on DCT3 (6110) i managed to get the IDs at least.
DCT4 has JTAG disabled :(

[muchie]

Can someone tell me where to find the JTAG points on the Nokia 5110, 3310 or 6110? Thanks!