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