comparison pirelli/flash2-chksum @ 215:d69f7512e3c1

Pirelli: documented and verified the checksum scheme used for the factory block
author Mychaela Falconia <falcon@freecalypso.org>
date Sun, 25 Dec 2016 23:48:16 +0000
parents
children
comparison
equal deleted inserted replaced
214:6b40617d00e6 215:d69f7512e3c1
1 Pirelli's flash usage scheme allocates 3 "magic" areas in the flash2 bank:
2
3 offset 0x480000 thru 0x7DFFFF: staging area for high-level fw updates
4 offset 0x7E0000 thru 0x7EFFFF: fw update control/state structure
5 offset 0x7F0000 thru 0x7FFFFF: factory record with IMEI and RF calibration
6
7 The image or record stored in each of these "magic" areas ends with the
8 following 12-byte signature and checksum structure:
9
10 Offset[1] Type[2] Contains
11 xxFFF4 32-bit word 0x12345678
12 xxFFF8 32-bit word Length of the fw update image or factory or
13 fw update state record
14 xxFFFC 16-bit word Checksum 1
15 xxFFFE 16-bit word Checksum 2
16
17 [1] The offset is from the beginning of the flash partition in question, the
18 xx digits will be 35 in the case of the 0x360000 byte fw update staging
19 area partition or 00 in the case of the two 64 KiB sectors.
20
21 [2] All 16-bit and 32-bit values are in little-endian byte order.
22
23 Checksum computation
24 ====================
25
26 The checksum is computed in two stages. First all 16-bit words in the main
27 body of the image (using the image length from the xxFFF8 word) are added
28 together as a ripple-carry sum, and this 16-bit sum is written into the 0xFFFC
29 word. Then the 5 16-bit words from xxFFF4 through xxFFFC (inclusive) are added
30 together (again as a ripple-carry sum), and this sum is written into the xxFFFE
31 word. Remember the little-endian byte order throughout!
32
33 The ../miscprog/pircksum2.c program verifies this checksum computation scheme.