partitions:isw [And Developers]

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:

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¹⁾ 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.
0x0204	0x0000BE8C	X-LOADER block length	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²⁾	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³⁾	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⁴⁾	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.

A nice disassembly of mbmloader has been provided by Yakk IDA DB of mbmloader. He used IDA version 5.5.

Here is an older, barely readable decompilation of mbmloader by maui.

ISW Block End

¹⁾ ISW offsets are relative to the start of the ISW block (0x200).

²⁾ , ⁴⁾ CSST_UserManual 2.5 p.77 4.2.5

³⁾ CSST_UserManual 2.5 p.4 0.3