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