CompalRamloader » History » Version 2
laforge, 02/19/2016 10:48 PM
recer to osmocon and indicate it is vendor firmware
1 | 1 | laforge | [[PageOutline]] |
---|---|---|---|
2 | = The Compal RAM Loader = |
||
3 | |||
4 | 2 | laforge | The Compal Ramloader is part of the original vendor firmware and what is executed first when a Compal phone like the [wiki:MotorolaC123] boots. |
5 | |||
6 | In the OsmocomBB project we only use this loader as it is stored in the original flash. We have implemented a host PC program |
||
7 | called [wiki:osmocon] that can talk to this Compal RAM loader. |
||
8 | 1 | laforge | |
9 | It is flashed to the first block[s] of the NOR flash, which in turn is mapped to address 0x0000'0000 |
||
10 | |||
11 | The tasks of the Ramloader are as follows: |
||
12 | * Initialize the minimally neccessary hardware (PLL, clock, GPIO, UART, ...) |
||
13 | * Check if a program on a PC is interested in downloading code into the phone |
||
14 | * if yes, actually perform the serial download into RAM and execute that code |
||
15 | * if no, continue booting the OS stored in the NOR flash |
||
16 | |||
17 | == Download Protocol == |
||
18 | |||
19 | The download protocol is relatively simple, although device-specific quirks complicate it: |
||
20 | |||
21 | === Negotiating the existance of a PC download software === |
||
22 | |||
23 | * The phone sends the PROMPT1 message (0x1b, 0xf6, 0x02, 0x00, 0x41, 0x01, 0x40) |
||
24 | * The PC responds with DNLOAD_CMD messge (0x1b, 0xf6, 0x02, 0x00, 0x52, 0x01, 0x53) |
||
25 | * The phone responds with the PROMPT2 message (0x1b, 0xf6, 0x02, 0x00, 0x41, 0x02, 0x43) |
||
26 | |||
27 | === Actual download of the executable code === |
||
28 | * The PC downloads the software |
||
29 | * Optionally (C155) by starting with the byte 0x02 (the XOR initialization value) |
||
30 | * Sending two bytes length, containing the length of the code to be downloaded |
||
31 | * Sending the actual download data |
||
32 | * Sending a single byte containing the XOR sum of all characters sent, including the length bytes |
||
33 | * The phone responds with a DNLOAD_ACK message (0x1b, 0xf6, 0x02, 0x00, 0x41, 0x03, 0x42) |
||
34 | |||
35 | ==== Error cases ==== |
||
36 | If something goes wrong, you will get |
||
37 | * DNLOAD_NACK (0x1b, 0xf6, 0x02, 0x00, 0x45, 0x53, 0x16) |
||
38 | * DNLOAD_NACK_MAGIC (0x1b, 0xf6, 0x02, 0x00, 0x41, 0x03, 0x57) |
||
39 | |||
40 | == Execution Environment == |
||
41 | |||
42 | All the downloaded data (excluding the length bytes) is stored at the base address {{{0x0080'0100}}}. |
||
43 | |||
44 | '''However, since there is a 4byte header prepended by compal_dnload, use 0x0080'0104 as linker base address!''' |
||
45 | |||
46 | The RAM loader already initializes the stack pointer. It points to a 1020 bytes large location in memory. |
||
47 | |||
48 | On the C118, C121, C123 and C140, the CPU runs in ARM mode when jumping to the base address. |
||
49 | |||
50 | On the C155, the CPU runs in THUMB mode when jumping to the base address. This is why the ramloader |
||
51 | automatically prefixes your payload with a 4-byte header that switches to ARM mode. |
||
52 | |||
53 | == Restrictions == |
||
54 | |||
55 | * Since the length field is only 16 bits, you cannot download more than 64kBytes of code |
||
56 | * Since the exception vectors point to NOR flash, you cannot use Interrupts from your RAM-loaded code |