-∇ϕ
The MSM8960 Boot Architechture
The MSM8960 Boot Architecture (Ref: 80-N5009-1 B)
We still have not understood how the MSM8960 Boots up. Here is an attempt to
summarize the content in the only document available on the topic. If we do not
understand this properly there will little or no hope to unlock our bootloader.
First thing to understand is that the MSM contains several processors, each
designated to work an a particular subsystem. The table below lists the
processor types and boot addresses.
The boot code flow through the subsystems can be visualized like this:
Compared to other Snapdragons, the MSM8960 seem to employ much more strict
security measures by default. It is using the Secure Boot 3.0 (SB3) Call Stack
to accomplish this. Here is picture how this look.
Next we have a look at the entire boot process.
The Secure Boot 3.0 Process
The boot procedure is in the order as follows.
The pictorial diagram:
Here the blue and white parts are executed in the RPM ARM7, while the grey parts are executed in the Krait.
Eventually the Krait takes over completely and we are left with the following flow .
PBL Boot Options
The BOOT_CONFIG[0..6] GPIOs or BOOT_CONFIG fuses can be used to
select the boot option, as shown below. Once the fuse is blown, the
GPIOs used for the boot option are free to be used as common GPIOs.
But this was all according to the Qualcomm MSM8960 specification. However, the
reference design schematic was simplified by omitting some of these
BC[x] pins, specifically the BC[2-5] pins, which are just used as regular
GPIO's, by just tying them directly to the antenna switch chips.
Thus the resulting configuration is as follows:
However, this is not necessarily what is happening inside our SCH-I535,
because it is not confimed that the Service Manual schematics (which seem
to follow most of the reference schematic) is what is actually present on
the PCB. The reasons are that:
1) The reference schematic states that BC[0:6] are internally pulled-down.
2) Pull-ups are not needed if related Qfuses has been blown.
3) That (1) and (2) refers to Revisions C & D of reference design.
Thus we have to manually test what is going on on our device!
<< To Be Continued ... >>
We still have not understood how the MSM8960 Boots up. Here is an attempt to
summarize the content in the only document available on the topic. If we do not
understand this properly there will little or no hope to unlock our bootloader.
First thing to understand is that the MSM contains several processors, each
designated to work an a particular subsystem. The table below lists the
processor types and boot addresses.
Code:
Subsystem Processor Boot address --------------------------------------------------------------------- RPM ARM7 0x0 DSPS ARM7 0x0 (hardware remap) KxPSS Krait Configurable Modem (FW) Hexagon Configurable Modem (SW) Hexagon Configurable LPASS Hexagon Configurable RIVA SS ARM9 0x0(hardware or software remap)
Compared to other Snapdragons, the MSM8960 seem to employ much more strict
security measures by default. It is using the Secure Boot 3.0 (SB3) Call Stack
to accomplish this. Here is picture how this look.
Next we have a look at the entire boot process.
The Secure Boot 3.0 Process
The boot procedure is in the order as follows.
Code:
PBL • RPM processor starts executing PBL in boot ROM • PBL determines cold boot or warm boot • PBL increases RPM clock speed from XO to 60 MHz • RPM processor start address is 0x0 • For cold boot, next step is to detect Flash device that chip will boot from, based on the boot options • When detected, PBL downloads SBL1 (RPMSBL) from Flash to System IMEM • SBL1 authenticates SBL2 (Krait PBL) • RPM uses Crypto Engine 4.0 to authenticate images • SBL1 jumps to start of SBL2 (Krait PBL) SBL1 • SBL1 configures MIMEM and GMEM, then loads and authenticates the SBL2 there; MIMEM is 192 KB, so when SBL2 grows, it will spill to GMEM • SBL1 takes Krait out of reset • SBL1 waits for signal from Krait SBL • When desired signal is received, SBL1 executes RPM firmware, which is downloaded by SBL2 • If RPM firmware image authentication/download fails, Krait SBL2 resets MSM and enters into Boot ROM Emergency Download mode SBL2 • After being taken out of reset, Krait jumps to start of SBL2 - Krait boot address is software-configurable via register APCS_START_ADDR • SBL2 increases Krait clock speed • SBL2 downloads TZ image to TZ-dedicated system IMEM - TZ image occupies at least 188 KB in system IMEM - TZ image sets up security environment (configures xPU, etc.) • SBL2 authenticates TZ image - SBL2 uses CE-4.0 to perform authentication • SBL2 downloads RPM firmware to Code RAM and authenticates it • SBL2 configures DDR • SBL2 sends RPM firmware-ready signal to RPM and lets RPM continue to execute RPM firmware • SBL2 jumps to SBL3 SBL3 • SBL3 bumps the system clock • SBL3 loads and authenticates APPSBL • SBL3 waits for the RPM process ready interrupt • Once the interrupt is coming, SBL3 jumps to APPSBL SBL3/APPSBL/HLOS • SBL3 (Krait SBL) loads and authenticates APPSBL and apps kernel • Krait executes APPSBL and HLOS • Krait loads and authenticates modem Hexagon firmware and Hexagon software images, then takes them out of reset as needed • Krait loads and authenticates LPA Hexagon image, then takes it out of reset as needed • Krait loads and authenticates DSPS ARM7 images, then takes them out of reset as needed • Krait loads and authenticates RIVA ARM9 images, then takes them out of reset as needed • Order of loading modem Hexagon, LPA Hexagon, and DSPS ARM7 can be decided by HLOS
Here the blue and white parts are executed in the RPM ARM7, while the grey parts are executed in the Krait.
Eventually the Krait takes over completely and we are left with the following flow .
PBL Boot Options
The BOOT_CONFIG[0..6] GPIOs or BOOT_CONFIG fuses can be used to
select the boot option, as shown below. Once the fuse is blown, the
GPIOs used for the boot option are free to be used as common GPIOs.
Code:
------------------------------------------------------------------------------- BC[5:0] BOOT_CONFIG MSM8960 Comments ------------------------------------------------------------------------------- 00000 0 BOOT_DEFAULT_OPTION 00001 1 BOOT_SDC_PORT3_THEN_SDC_PORT1_OPTION 00010 2 BOOT_SDC_PORT3_THEN_SDC_PORT2_OPTION 00011 3 BOOT_SDC_PORT1_OPTION 00100 4 BOOT_SDC_PORT2_OPTION 00101 5 BOOT_SPI_ON_GSBI1_OPTION 00110 6 BOOT_SPI_ON_GSBI2_OPTION Not supported 00111 7 BOOT_SPI_ON_GSBI3_OPTION Not supported 01000 8 BOOT_SPI_ON_GSBI4_OPTION Not supported 01001 9 BOOT_SPI_ON_GSBI5_OPTION 01010 0x0A BOOT_SPI_ON_GSBI6_OPTION Not supported 01011 0x0B BOOT_SPI_ON_GSBI8_OPTION Not supported 01100 0x0C BOOT_NAND_OPTION Not supported 01101 0x0D BOOT_USB_OPTION 01110 0x0E BOOT_SDC_PORT1_4BIT_OPTION 01111 0x0F BOOT_SDC_PORT2_4BIT_OPTION 10000 0x10 BOOT_SPI_ON_GSBI9_OPTION ------------------------------------------------------------------------------- BC[5:0] = BOOT_CONFIG[5:0] SDC1 = eMMC SDC2 = SD2 (not used) SDC3 = SD1 (built in) ------------------------------------------------------------------------------- BC6 = (0 - Secure Boot, 1 - Fast Boot) -------------------------------------------------------------------------------
reference design schematic was simplified by omitting some of these
BC[x] pins, specifically the BC[2-5] pins, which are just used as regular
GPIO's, by just tying them directly to the antenna switch chips.
Thus the resulting configuration is as follows:
Code:
------------------------------------------------------------------ BC[5:0] Mapping ------------------------------------------------------------------ 0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS 0b00001 SDC3 followed by SDC1 (eMMC) 0b00010 SDC3 followed by SDC2 (if used) 0b00011 SDC1 (eMMC) ------------------------------------------------------------------
because it is not confimed that the Service Manual schematics (which seem
to follow most of the reference schematic) is what is actually present on
the PCB. The reasons are that:
1) The reference schematic states that BC[0:6] are internally pulled-down.
2) Pull-ups are not needed if related Qfuses has been blown.
3) That (1) and (2) refers to Revisions C & D of reference design.
Thus we have to manually test what is going on on our device!
<< To Be Continued ... >>
Chicago - Northwest Suburbs
Linear Mode
