This section summarizes briefly some of the information I could gather from reverse engineering the SPL. A lot more information is available on the Xanadux wiki.
IPL/SPL (Flash ROM) -> | EOL (miniSD) -> | Linux (miniSD) | |||||||||||||||||||||||
|
|
|
When booting in diagnostic mode, the SPL checks for the presence of a miniSD. If it finds one, it checks if an HTC header is present in the first sector of the card. This header contains a magic identifying the card type, for example a full or partial ROM image (to be flashed) or a diagnostic card. If the type is a diagnostic card, the content of the card is loaded to RAM and executed instead of being flashed to the Disk-On-Chip. However, before loading the content to RAM, the security level is checked and if it is too high (lower means more priviledges), the operation is aborted and the "Not allow update!" message is printed. The security level depends on two parameters. The first one is whether the Disk-On-Chip identifier contains always the same character (like '11111111'), in which case the security level is 0 and all operations are allowed (this is called a Super-CID). Otherwise the miniSD itself is checked to see if it is signed.
Signing the card means combining its unique identifier with one of the three keys specific to the phone model (providing security levels 0-2). Any security level <= 2 is enough to load the diagnostic card, so we don't have to bother using the proper key, provided the model is correct. These keys are known by the typhoonnbfdecode.pl program (they are present at the end of the SPL image for your phone model), so what you need to provide is the SD card unique identifier. Every SD card in the world has a 128-bit identifier available by sending special commands to the SD. This means only a SD controller can provide that kind of information, USB adapters cannot (since they only know how to read/write the SD card flash memory, not how to access its registers). Some laptops have integrated controllers, or other devices like PDAs, or even a unlocked HTC smartphone running Linux :), so you can use such devices to retrieve it.
The OMAP Platform provides general I/O pins which can be used for sensing or signaling. How these pins are used is unfortunately totally machine-dependent. From what I could find in the SPL, it seems the following GPIO are used.
GPIO # | dir | purpose |
---|---|---|
7 | OUT | unknown |
15 | OUT | LCD_Panel_Reset (HIGH: reset, LOW: no reset) |
16 | OUT | unknown |
18 | OUT | MS_Lock (LOW) / VTCXO (HIGH) |
19 | OUT | ARM7_RF_Enable |
31 | IN | unknown |
32 | IN | unknown |
33 | OUT | USB_En |
34 | OUT | Vibrator_En |
35 | IN | USB D- ? |
36 | IN | USB D+ ? |
40 | IN/OUT | unknown |
41 | IN | unknown |
42 | IN | unknown |
43 | IN/OUT | unknown |
61 | OUT | unknown |
62 | OUT | unknown |
69 | IN | LCDPanel_ID0 |
70 | IN | LCDPanel_ID1 |
72 | OUT | FrontLight_Dim |
73 | OUT | unknown |
74 | OUT | KeypadLed |
77 | OUT | LCD_out_en |
78 | IN | unknown |
77 | OUT | Led_1 (pullup) |
80 | OUT | unknown |
81 | OUT | unknown |
82 | OUT | BTCom |
84 | OUT | unknown |
116 | IN | LightSensor |
121 | OUT | LCD_Power_1 |
122 | OUT | unknown |
124 | OUT | LCD_out_data |
125 | IN | unknown |
126 | IN | FrontLight_En |
127 | OUT | LCD_out_clock |