ISW
Initial Software image
Since the NAND flash cannot be used to XIP (eXecute In Place), and since there must be public-key certificates inside the ISW block, there's a header on the ISW (Initial SoftWare) block. This header is not publicly documented (i.e., not in the TRM) for HS devices like the Milestone and the Droid. User droid001 has compared the Droid dump, the Milestone dump and the example CSST HS image, proposing an ISW structure like this one:
For GP devices:
For HS devices:
ISW Block
ISW Block Headers
X-LOADER Header
0200: 00 24 00 00 8c be 00 00 00 00 00 00 00 00 00 00 0210: 00 00 00 87 58 2d 4c 4f 41 44 45 52 00 00 00 00
| Offset (mbmloader img) | Value | Meaning | Comment |
|---|---|---|---|
| 0x0200 | 0x00002400 | ISW offset((ISW offsets are relative to the start of the ISW block (0x200).)) to X-LOADER | |
| 0x0204 | 0x0000BE8C | X-LOADER block length | This is the number of bytes to load into RAM, since the whole X-LOADER block is copied.
This value differs on the Droid (it's 0x0000862C). |
| 0x0208 | 0x00000000 0x00000000 | ||
| 0x0210 | 0x87000000 | RAM load address. This is the RAM location where the X-LOADER block is copied into RAM. | The RAM execution starts at (this value+ 0x350), which is the ISW Entry Point, because CertISW's length is fixed (0x350). |
| 0x0214 | 'X-LOADER' | Id |
KEYS header
0220: 00 02 00 00 60 09 00 00 00 00 00 00 00 00 00 00 0230: 00 00 00 00 4b 45 59 53 00 00 00 00 00 00 00 00
| Offset (mbmloader img) | Value | Meaning | Comment |
|---|---|---|---|
| 0x0220 | 0x00000200 | ISW offset to CertPK | |
| 0x0224 | 0x00000960 | Lenght of CertPK | |
| 0x0228 | 0x00000000 0x00000000 | ||
| 0x0230 | 0x00000000 | ||
| 0x0234 | 'KEYS' | Id | Public Keys (plural?) |
PRIMAPP header
0240: 00 0c 00 00 50 16 00 00 00 00 00 00 00 00 00 00 0250: 00 00 00 00 50 52 49 4d 41 50 50 00 00 00 00 00
| Offset (mbmloader img) | Value | Meaning | Comment |
|---|---|---|---|
| 0x0240 | 0x00000C00 | ISW offset to CertPPA | |
| 0x0244 | 0x00001650 | Length of CertPPA | This value differs on the Droid (0x00001604). |
| 0x0248 | 0x00000000 0x00000000 | ||
| 0x0250 | 0x00000000 | ||
| 0x0254 | 'PRIMAPP' | Id | Primary Application |
ISW Block Headers closing mark
0260: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0270: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
Empty space
0280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 03f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
KEYS block
| Offset (mbmloader img) | Value | Meaning | Comment |
|---|---|---|---|
| 0x0400 | 'CertPK_' | Public Key Certificate((CSST_UserManual 2.5 p.77 4.2.5)) | Ends at 0x0200+0x0200+(0x0960-0x0001) = 0x0d5f |
Empty space
0d60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 0df0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
PRIMAPP block
| Offset (mbmloader img) | Value | Meaning | Comment |
|---|---|---|---|
| 0x0e00 | 'CertPPA' | Primary Protected Application Certificate((CSST_UserManual 2.5 p.4 0.3)) | Ends at 0x0200+0x0c00+(0x1650-0x0001) = 0x244f |
Empty space
2450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ... 25f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
X-LOADER block
This storage area contains the signed ISW. We have named it "X-LOADER" for naming consistency reasons, and to avoid having too many data blocks called "ISW". This is not to be confused with the X-Loader or X-Load program, which is the name of a **program** that is not used in Motorola Milestone/Droid but in TI OMAP development boards. In fact, Motorola itself (or picked this up by some patch from TI) labeled the whole 0x00000-0x7ffff NAND area as "X-Loader-NAND" in this code added by Motorola to the Linux kernel. And TI's eFuse patent mentions that the "X-LOADER" string is required for the system to boot in HS mode.
CertISW
| Offset (mbmloader img) | Value | Meaning | Comment |
|---|---|---|---|
| 0x2600 | 'CertISW' | Initial Software Certificate((CSST_UserManual 2.5 p.77 4.2.5)) | Fixed length 0x350 Bytes |
ISW Code & Data
| Offset (mbmloader img) | Value | Meaning | Comment |
|---|---|---|---|
| 0x2950 | 0f 10 a0 e1 | See disassembly below. | ISW Entry point |
| 0x2954 | lots of code and data here | This contains the Motorola mbmloader code (anything else?). | Ends at 0x0200+0x2400+(0xbe8c-0x0001) |
Here is a disasembly of the Entry Point:
/* Starting to disassemble from this point brings a meaningful flow. It is the initial portion of the whole ca. 48kB or 34kB by droid image loaded into RAM (SDRAM Q2-ChipSelect-0 512MB starts at 0x8000 0000 [see TRM]) It is the check for the PC if it was 0x87000350, which fits with the recorded "Load Address"+"Initial SW Entry Point" in CSST that is 0x87000000 + 0x0350. When the ISW entry point is changed in CSST, its value will be added to a value with base value 0x350 at 0x27B4 of the .img file. So in a nutshell, the first 0x0350 bytes in RAM are likely a copy of the CertISW. */ ROM:00000000 0F 10 A0 E1 MOV R1, PC ; Subtract 8 for the address of THIS ROM:00000004 08 10 41 E2 SUB R1, R1, #8 ; due to pipelining. ROM:00000008 C0 20 9F E5 LDR R2, =0x87000350 ROM:0000000C 02 00 51 E1 CMP R1, R2 ; Checks whether it is running at the correct RAM location. ROM:00000010 1B 00 00 1A BNE loc_84 ; If it's not, branches into a dead loop. : : ROM:00000084 loc_84 ; CODE XREF: ROM:00000010 ROM:00000084 ; ROM:loc_84 ROM:00000084 FE FF FF EA B loc_84 ; This is a Dead Loop.
Latest disassembly - see the here
Here is an older, barely readable tools:disassembling decompilation of mbmloader by maui.
ISW Block End
Initial conf from registers table from CertISW
DCD 0x48004D30 ; reg_table.reg_address
DCD 0 ; reg_table.reg_value
DCD 0x48004934 ; reg_table.reg_address
DCD 0 ; reg_table.reg_value
DCD 0x48004948 ; reg_table.reg_address
DCD 0 ; reg_table.reg_value
DCD 0x48004944 ; reg_table.reg_address
DCD 1 ; reg_table.reg_value
DCD 0x48004940 ; reg_table.reg_address
DCD 0x1F419 ; reg_table.reg_value
DCD 0x48004D40 ; reg_table.reg_address
DCD 0x8A00C00 ; reg_table.reg_value
DCD 0x48004D00 ; reg_table.reg_address
DCD 0x770077 ; reg_table.reg_value
DCD 0x48004904 ; reg_table.reg_address
DCD 0x37 ; reg_table.reg_value
DCD 0x48004924 ; reg_table.reg_address
DCD 0 ; reg_table.reg_value
DCD 0x48004D20 ; reg_table.reg_address
DCD 0
Here we can see these registers:
0x48004D30 - CM_AUTOIDLE_PLL 0x48004934 - CM_AUTOIDLE_PLL_MPU 0x48004948 - CM_CLKSTCTRL_MPU 0x48004944 - CM_CLKSEL2_PLL_MPU 0x48004940 - CM_CLKSEL1_PLL_MPU 0x48004D40 - CM_CLKSEL1_PLL 0x48004D00 - CM_CLKEN_PLL 0x48004904 - CM_CLKEN_PLL_MPU 0x48004924 - CM_IDLEST_PLL_MPU 0x48004D20 - CM_IDLEST_CKGEN
