Up to the first 512 bytes of the flash memory on OMAP34xx systems can be occupied by the Configuration Header, as described in section 26.4.8.2 in the OMAP34xx TRM. This table is loaded by the OMAP boot ROM in order to set various options before delivering control to the bootstrap code (X-Loader, included in the Initial Software image located at NAND position 0x00000208).
Support for the Configuration Header (CH) within this signed image
Since this statement is inside the “Diagnostics module” section, and the word “support” can be interpreted as being able to continue the diagnostic without interrupting by the CH which wasn't expected in earlier version. In fact, by the practical use of CSST 2.5, there is no evidence showing that the CH is a part of the ISW that would affect the value of CertISW. An experiment has been done to sign an image with the CH options altered, the resulting binary diff shows only the difference in CH.
Inspection of the Milestone's “mbmloader dump”, which spans this flash area, shows that it does contain a CH table, and that it differs from the Droid's (thanks to droid001 for noticing and for proposing the packed-fields format)2).
| Position | Droid CH | Milestone CH | Meaning |
|---|---|---|---|
| 0x125 | 0xb9 | 0xae | This sets the refresh countdown timer in the memory controller to 0x04b9 (Droid) or 0x04ae (Milestone). Thus, the Milestone's memory is refreshed about 0,9% faster than the Droid's, at least at boot time (this might be changed later according to this). Whether the Milestone's hardware supports running at Droid's lower refresh rate is unknown. |
| 0x1a3 | 0x02 | 0x00 | This value lies outside any CH ITEM, in a padding area. Whether it has a purpose or not is unknown. |
In order to boot a Droid image on a Milestone (see mbmloader replacement attack) one might want to keep the Milestone CH. The abovementioned cryptographic protection may also preclude us to merge the Milestone CH with the Droid bootstrap code.
Parsing the CH table was not trivial. When reading the table with the usual fixed 32-bit word from the raw NAND, little-endian ordering, the results were somewhat surprising (CH present but inactive, “must be 0”'s that weren't, etc). Although it has not been fully understood why it might be being used, the following packed-fields mapping obtains more likely results:
1-byte field: 0x12 as quoted on the TRM corresponds to byte 12 at the immediate next storage position 2-byte field: 0x1234 as quoted on the TRM corresponds to bytes 34 12 at the immediate next storage positions 4-byte field: 0x12345678 as quoted on the TRM corresponds to bytes 78 56 34 12 at the immediate next storage positions
The resulting CH looks like the following:
CH TOC
CH ITEM 1
0000: a0 00 00 00 50 00 00 00 00 00 00 00 00 00 00 00 0010: 00 00 00 00 43 48 53 45 54 54 49 4e 47 53 00 00
| Field name | Value | Meaning |
|---|---|---|
| Start | 0x000000a0 | Points to start of Item 1 |
| Size | 0x00000050 | Length of Item 1 |
| Reserved | 0x00000000 0x00000000 0x00000000 | |
| Filename | “CHSETTINGS” | Type of Item 1 |
CH ITEM 2
0020: f0 00 00 00 5c 00 00 00 00 00 00 00 00 00 00 00 0030: 00 00 00 00 43 48 52 41 4d 00 00 00 00 00 00 00
| Field name | Value | Meaning |
|---|---|---|
| Start | 0x000000f0 | Points to start of Item 2 |
| Size | 0x0000005c | Length of Item 2 |
| Reserved | 0x00000000 0x00000000 0x00000000 | |
| Filename | “CHRAM” | Type of Item 2 |
CH TOC closing mark
0040: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0050: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
EMPTY DATA SPACE
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ITEM 1: CHSETTINGS BLOCK
00a0: c1 c0 c0 c0 00 01 00 00 01 00 00 02 00 00 00 00 00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
| Field name | Value | Meaning |
|---|---|---|
| Section key | 0xc0c0c0c1 | this verifies that it's a CHSETTINGS block, ok |
| Valid | 0x00 | this block is DISABLED, so it's not used!!! |
| Version | 0x01 | correct |
| Reserved | 0x0000 | |
| Clock settings | 0x02000001 | Clock configuration applied = 1 [yes] |
| Reserved = 0 | ||
| Perform clock configuration = 0 [no] | ||
| Set and lock DPLL4 PER = 0 [no] | ||
| Set and lock DPLL1 (MPU) = 0 [no] | ||
| Set and lock DPLL3 (CORE) = 0 [no] | ||
| Bypass DPLL4 before setting clocks = 0 [no] | ||
| Bypass DPLL1 before setting clocks = 0 [no] | ||
| Bypass DPLL3 before setting clocks = 0 [no] | ||
| System clock ID = 0x02 [13 MHz] |
ITEM 2: CHRAM BLOCK
00f0: c2 c0 c0 c0 01 00 00 00 00 00 04 00 00 01 00 00 0100: 08 00 00 0f 00 00 00 00 00 00 00 00 03 00 00 00 0110: 99 80 58 03 32 00 00 00 20 00 00 00 c6 b4 9d ba 0120: 20 22 02 00 02 ae 04 00 03 00 00 00 00 00 00 00 0130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0140: 00 00 00 00 00 00 00 00 01 00 00 00
| Field name | Value | Meaning |
|---|---|---|
| Section key | 0xc0c0c0c2 | this verifies that it's a CHRAM block, ok |
| Valid | 0x01 | this block is enabled |
| Reserved | 0x000000 | |
| SDRC_SYSCONFIG (LSB) | 0x0000 | |
| SDRC_CS_CFG (LSB) | 0x0004 | |
| SDRC_SHARING (LSB) | 0x0100 | |
| SDRC_ERR_TYPE (LSB) | 0x0000 | |
| SDRC_DLLA_CTRL (LSB) | 0x0008 | |
| SDRC_DLLA_CTRL (MSB) | 0x0f00 | |
| Reserved | 0x0000 | |
| Reserved | 0x0000 | |
| SDRC_POWER (LSB) | 0x0000 | |
| SDRC_POWER (MSB) | 0x0000 | |
| Memory type (LSB) | 0x0003 | Mobile DDR |
| “Must be 0” | 0x0000 | ok |
| SDRC_MCFG_0 (LSB) | 0x0008 | |
| SDRC_MCFG_0 (MSB) | 0x0358 | |
| SDRC_MR_0 (LSB) | 0x0000 | |
| SDRC_EMR1_0 (LSB) | 0x0000 | |
| SDRC_EMR2_0 (LSB) | 0x0000 | |
| SDRC_EMR3_0 (LSB) | 0x0000 | |
| SDRC_ACTIM_CTRLA_0 (LSB) | 0x0003 | |
| SDRC_ACTIM_CTRLA_0 (MSB) | 0x0000 | |
| SDRC_ACTIM_CTRLB_0 (LSB) | 0x2220 | |
| SDRC_ACTIM_CTRLB_0 (MSB) | 0x0002 | |
| SDRC_RFRCTRL_0 (LSB) | 0xae02 | this value differs between the Droid and the Milestone; the Droid uses the 0xb902 value here. See the next comment. |
| SDRC_RFRCTRL_0 (MSB) | 0x0004 | SDRC_RFR_CTRL_0[23:8]: ARCV = 0x04ae for Milestone or 0x04b9 for Droid. This is the autorefresh counter value to set the refresh period. The autorefresh counter is uploaded with the result of (tREFI / tCK)-50 |
| SDRC_RFR_CTRL_0[7:2]: Reserved = 0 | ||
| SDRC_RFR_CTRL_0[1:0]: ARE = 0x2 This means refresh counter is loaded with 4xARCV: Burst of 4 autorefresh commands when autorefresh counter reaches 0 | ||
| Memory type (LSB) | 0x0003 | Mobile DDR |
| “Must be 0” | 0x0000 | ok |
| SDRC_MCFG_1 (LSB) | 0x0000 | |
| SDRC_MCFG_1 (MSB) | 0x0000 | |
| SDRC_MR_1 (LSB) | 0x0000 | |
| SDRC_EMR1_1 (LSB) | 0x0000 | |
| SDRC_EMR2_1 (LSB) | 0x0000 | |
| SDRC_EMR3_1 (LSB) | 0x0000 | |
| SDRC_ACTIM_CTRLA_1 (LSB) | 0x0000 | |
| SDRC_ACTIM_CTRLA_1 (MSB) | 0x0000 | |
| SDRC_ACTIM_CTRLB_1 (LSB) | 0x0000 | |
| SDRC_ACTIM_CTRLB_1 (MSB) | 0x0000 | |
| SDRC_RFRCTRL_1 (LSB) | 0x0000 | |
| SDRC_RFRCTRL_1 (MSB) | 0x0000 | |
| Reserved | 0x0000 | |
| Reserved | 0x0000 | |
| Flags | 0x0001 | CS0 is configured |
| “Must be 0” | 0x0000 |
MORE EMPTY DATA SPACE
0140: 00 00 00 00 0150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
CH END