[Verizon Samsung Galaxy S III] E:V:A:
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.

[SIZE=2]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)
[/SIZE]

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.

[SIZE=2][B]PBL[/B]

• 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
• [B]For cold boot, next step is to detect Flash device that chip will boot from,
based on the boot options[/B]
• When detected, PBL downloads SBL1 (RPMSBL) from Flash to System IMEM
• SBL1 authenticates SBL2 (Krait PBL)
• RPM uses [I][COLOR=Red]Crypto Engine 4.0[/COLOR][/I] to authenticate images
• SBL1 jumps to start of SBL2 (Krait PBL)

[B]SBL1[/B]

• SBL1 configures MIMEM and GMEM, then loads and authenticates the SBL2 there;
MIMEM is [B]192 KB[/B], 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

[B]SBL2[/B]

• After being taken out of reset, Krait jumps to start of SBL2
- Krait boot address is software-configurable via register [B][I]APCS_START_ADDR[/I][/B]
• SBL2 increases Krait clock speed
• SBL2 downloads TZ image to TZ-dedicated system IMEM
- TZ image occupies at least [B]188 KB[/B] 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

[B]SBL3[/B]

• 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

[B]SBL3/APPSBL/HLOS[/B]

• 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
[/SIZE]

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.

[SIZE=2]-------------------------------------------------------------------------------
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)
-------------------------------------------------------------------------------
[/SIZE]

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:

[SIZE=2]------------------------------------------------------------------
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)
------------------------------------------------------------------
[/SIZE]

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 ... >>