[Galaxy Grand 2 General] vrushabh sutar:
Following is a detailed explaination of quacomm MSM Boot

Process

(thanks to the original author "TJ world")

hope it helps DEVs in order to bypass SecureBoot.

An examination of how the

Qualcomm Mobile Station Modem

(MSM) Snapdragon 7x30 system-on-

chip boot-straps the processors into

an operating system.

There are two processors in the

MSM 7x30, an ARM9 for the radio

and an ARM11 auxiliary applications

processor. Each processor has its

own JTAG and can be independently

controlled using it.

ARM9 Boot Process

The ARM9 is the primary processor.

It boots first, executing the Primary

Boot Loader (PBL) from on-board

ROM at 0xFFFF0000 .

The MSM platform has the facility to

force Secure Boot using the status of

the FORCE_TRUSTED_BOOT Qfuse

on-chip or a high-state BOOT_SCUR

pin connected to GPIO95. In this

mode the PBL verifies the signature

of the SBL/OSBL before executing

it,which verifies the REX/AMMS

signature in the same way.

After some hardware initialisation the

PBL reads the Device Boot Loader

(DBL) from the first partition of the

flash memory device (In Linux,

mmcblk0p1).

DBL is part of Qualcomm's

SecureBoot, which uses

cryptography to guarantee that the

boot-loader images haven't been

tampered with. DBL configures the

Cryptographic Look-aside Processor

(CLP), a dedicated cryptographic co-

processor, and other hardware

sufficient to load and execute the

Secondary Boot Loader (SBL) from a

Flash memory device on EBI2

(External Bus Interface 2) from

partition 3 (Linux mmcblk0p3).

The SBL, also known as the

Operating System Boot Loader

(OSBL), is loaded into memory at

0x8000000 (IMEM - Internal Memory,

the MSM7230 package-on-package

(PoP) RAM). This is the ARM9

Monitor (AMON). It provides an

Extensible Firmware Interface (EFI) -

like environment for controlling the

boot process. After doing more

hardware configuration including

UARTs and USB (for potential remote

console connections to the monitor)

it loads the Applications processor

Secondary Boot Loader (APPSBL

a.k.a. hboot) on the ARM11

applications processor from partition

18 (Linux mmcblk0p18) into memory

@ 0x8D000000 virtual, 0x00000000

physical.

It then loads and executes the

combined REX/AMSS from partition

5 (Linux mmcblk0p5). The image

contains the REX (Real-time

EXecutive) which is an L4A

Pistachio embedded micro-kernel

and Iguana operating system

combination, with extensive

Qualcomm and HTC modifications

and extensions.

REX is responsible for loading the

firmware into the ancillary micro-

controller (microP), digital signal

processor and voice processor and

initialising them. It runs in Security

Domain 0 (SD0).

When the ARM11 starts REX

unloads/disconnects its eMMC driver

and from then on relies on remote

procedure calls (RPC) via shared

memory (SMEM) to the ARM11

application processor to read and

write the eMMC. On the ARM11 side

the Linux operating system uses the

rmt_storage (remote storage) driver

to handle such requests.

Finally on the ARM9 REX executes

the Advanced Mobile Subscriber

Software (AMSS). AMSS runs in

Security Domain 1 (SD1).

ARM11 Boot Process

The ARM9 running REX loads the

eMMC "hboot" partition into memory

at 0x8D00000 (virtual) and starts the

ARM11 auxiliary applications

processor executing at this location.

It runs in Security Domain 3 (SD3).

The core of the boot-loader can be

found in the Android source-code

repository in the platform/bootable/

bootloader/legacy.git project. This

source-code maps well to current

hboot images when they are reverse-

engineered; allowing the libc and

core functions and structures to be

identified.