Hauwei’s Rapid Rise to Third Place in the Smartphone Race

Huawei has quickly grown to become one of the world’s biggest … more

OnePlus 2 Bares All in New Tear Down Gallery

Last year, the launch of the OnePlus One, dubbed ‘the flagship killer’, visibly … more

Focus – An Attractive But Raw Gallery Replacement

Focus is an attractive new app built by XDA members Liam Spradlin … more

How to Root the LG G4 and Install TWRP Recovery – XDA TV

A rooting method has finally been found for the flagship LG G4. In this … more

[REF][R&D] MSM8960 Info, Architecture and Bootloader(s)

1,407 posts
Thanks Meter: 2,008
By E:V:A, Recognized Developer on 27th August 2012, 05:48 PM
Thread Closed Subscribe to Thread Email Thread
MSM8960 Info, Architecture and Bootloader(s)

A documentation, research and development thread for the Snapdragon S4
processor/modem/memory combination.
Posting Rules

Do NOT post general questions/requests on how to
do this or that, they will not be answered here.
ONLY post if you have additional tricks, hacks or
information that can help/benefit this thread.
This is a pure research and development thread
and will be aggressively moderated!


1) To continue the documentation effort of the Qualcomm Snapdragon S4 (MSM8960).
2) To construct a MSM8960 "Hack-Pack" with documents, info, code, pictures, tools and drivers etc..

This will be done in the same spirit as the excellent and already epic
(Verizon) Samsung Galaxy S3 (SGH-I535) "[R&D] Unlock Bootloaders" thread. In
fact this thread should be considered as the advanced continuation to that
effort. Many of the key introductory documents about the MSM8960 can be found
in that thread, so before you post what you think may be new information here,
please make sure you have read and searched that thread.


As Qualcomm are keeping even the most basic hardware information secret from
the development community, it has triggered an enormous annoyance-driven
effort to try to map out the basic inner workings and behavior of our mobile
phone processors. As more people are actively developing using the NDK and
getting more familiar with kernel compiling, tweaking and modifications at
the hardware level, more information is needed about the processor and its
supporting hardware.

Qualcomm (and Samsung) should know and be told again, that we are not
interested in industrial espionage and to copy their inner workings of their
flagship processors, but rather understand how they are connected and can be
programmed for the infinite various purposes that may help improve our common
future of mobile platforms.


A. Understand the MSM8960 Memory Map
B. Understand the MSM8960 HW registers (GPIO, GSBI, I2C, UART, SPI, Qfuses etc.)
C. Understand the bootloader code (Secure Boot 3.0)
D. To provide a permanent and early alternative boot-route that
cannot be disabled or hijacked by rogue firmware updates.
(Sound funny, doesn't it, when you change perspective!?)
E. Collect additional information on the MSM8960


(A) This is the most difficult to obtain without any documentation,
because certain regions of memory is not readable from/by userspace
applications/code. One can only hope that there are some readable shadow
regions or that some new information/documentation will spill the details.
If not, then publicly available kernel code and programs like viewmem and
lime may help us here.

(B) Most registers should be readable by shadow memory locations and if not
there are other TLMM registers that should tell us just which registers are
not readable. Then we'll have to figure out how to read them anyway, with JTAG
as a last resort, although JTAG may also be protected!

(C) This is difficult although possible to do by anyone with some IDA
experience, since it requires extensive RE of the entire boot-loader chain.
(PBL --> SBL1 --> SBL2 --> SBL3) But it is heavily dependent on the success
of (A) and (B).

(D) Probably impossible without (A-C)

(E) Difficult because of the extreme lack of public documentation. A leaked
document such as one or both of the following, would provided us all the detail
needed to fulfill (A-C) and part of (D).
Here are the most useful documents we have so far:
The 8960 Boot Architecture Overview             80-N5009-1 Rev.B
MSM8960, PM8921, and WCD9310 Baseband           80-N1622-41 Rev.D
We may also find other documents, to similar processors useful. The most similar processor AFAIK, is the MSM8660,
but others may be any or all of the later ones in the series: MSM8930, MSM8228 and MSM8974. So please look out for these:
MSM8260/MSM8660 Boot Qfuses and Configuration       80-VU872-17
Software Interface                                  80-VU872-2
User Guide                                          80-VU872-3
However, the documents we need most are:
MSM8960 Qfuses and Security (Application Note)                          80-N1622- ?? 
MSM8960/MSM8270/MSM8x60A Mobile Station Modem Software Interface        80-N1622-2 Rev.C 
MSM8260/MSM8660 Mobile Station Modem Software Interface                 80-VU872-2 Rev.D


All the information in this thread have been acquired by searching on-line
and researching the hardware and software used by Qualcomm-based mobile
devices containing this hardware. Thus any documentation linked within
this thread and labelled within that document as "confidential", can no
longer be considered as such, as it is openly and readily available on
internet by simple searches. XDA is in no way to be held responsible for
any leaked material linked in this thread. If by any chance, someone does
directly link to illegally obtained and singularly accessible documents,
please contact OP starter and such links or posts will be removed after

References & Sources:

Lots of useful documents and manuals (Thanks to Antagonist42)
Explanation of the Qualcomm Proprietary protocols (QMI, DM)
LiME - Linux memory Extractor (XDA feature)

Jan 2013 Qualcomm Documentation Leak (~140 files): HERE

Last edited by E:V:A; 6th February 2013 at 11:10 PM. Reason: fixed link!
The Following 39 Users Say Thank You to E:V:A For This Useful Post: [ View ]
27th August 2012, 05:48 PM |#2  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
Previous Results (from this thread)

0. A picture of the BGA pad layout for the MSM8960 (#214)

In post #241 you will find:
1. The MSM8960 Boot Code Flow (#241)
2. The Secure Boot 3.0 Process
3. PBL Boot Options (BOOT_CONFIG[0:6])

In post #242 you will find:
4. The Secure Boot Loaders (where and how the bootloader chain is executed.)
5. The PBL Memory Map
6. The PBL Error Handler (structures and operation flow)

7. How to temporarily turn on/off Secure Boot Authentication using JTAG (#247 and #296)
8. How to read the secure boot option from memory (#296)
9. Explanation of bootloader failure and emergency download behavior (EhostDL). (#277 and here)
10. Explanation of how the SEC_BOOT and Qfuses are checked in PBL (#302)
Table of Content
  1. Boot Configuration & Options) (#3)
  2. [WIP] Boot-up & restart procedure (#xxx)
  3. [WIP] Qfuses (a.k.a. Efuse, QFPROM) (#xxx)
  4. [WIP] Pin/pad functions (#xxx)
  5. [WIP] Registers (#xxx)
  6. [WIP] GPIO (#xxx)
  7. WIP (#xxx)
Other processors in the Snapdragon S4 Plus series to be considered:


The complete list of the Snapdragon Series is:

APQ8055         no modem

APQ8060        no modem

S4 Prime
MPQ8064         no modem

S4 Pro
APQ8064         no modem

S4 Plus
APQ8030         no modem
APQ8060A        no modem

S4 Play
Then it may be good to know that for Windows Phones, there is a limited set of QC chips used.
QSD8650/8250            ==> WP 7        (CE 7.07)
MSM8255T/8655T/APQ8050  ==> WP 7.5      (CE 7.10) 
MSM8260A/8227/8960/T    ==> WP 8        (NT)
Attached Thumbnails
Click image for larger version

Name:	MSM8960_diagram.jpg
Views:	79077
Size:	42.7 KB
ID:	1296105  
Last edited by E:V:A; 18th October 2012 at 10:46 PM.
The Following 14 Users Say Thank You to E:V:A For This Useful Post: [ View ]
27th August 2012, 05:49 PM |#3  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
Boot Configuration & Options

The boot-up behavior of the MSM8960 is determined in the Primary Boot Loader (PBL) that is loaded from IROM,
and executed in IMEM. The PBL code determine the boot procedure to follow, from two sources that control it.
  1. By the BOOT_CONFIG Qfuse settings (aka Efuse and QFPROM)
  2. By the externally hardwired BOOT_CONFIG[0..6] pins/pads via the MSM GPIO.

    Here (1) take precedence over (2), if used.
However, it's worth noting that according to the MSM8660 document, PBL only checks the "secure boot 1" region.
Other regions can be checked in later stages (bootloaders). But according to the MSM8960 documentation change log,
some updates could have been made to this behavior...

The BOOT_CONFIG[0..6] GPIOs or BOOT_CONFIG fuses (see Section #xxx ) can be used
to select the boot option, as shown below. Once the fuse chain is blown, the GPIOs used for the
boot option are free to be used as common GPIOs.

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]
SDC2 = SD2 (if used)
SDC3 = SD1 (if used)
BC[6] = (0 - Secure Boot, 1 - Fast Boot)
This table is according to the Qualcomm MSM8960 specification. However, the
reference design schematic (that many devices are based upon) 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.
However, for some reason not all boot configurations are currently supported.
So the table can be simplified, and is what is used in most internal mobile phone configurations.

Simplified table:
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)
(See section for the MSM8260/8660 below, for comparison.)


pad     gpio    name                    connection      boot    Rxxx
AH32    119     BOOT_FROM_ROM           ANT_SW_SEL0             
AH33    118     BOOT_CONFIG_0           ANT_SW_SEL1     *       R-0
AM31    117     BOOT_CONFIG_1           ANT_SW_SEL2     *       R-1
AM30    116     BOOT_CONFIG_2           ANT_SW_SEL3
AN30    115     BOOT_CONFIG_3           BC0_SW_SEL0
AM29    114     BOOT_CONFIG_4           BC0_SW_SEL1
AN29    113     BOOT_CONFIG_5           BC1_SW_SEL0
AK28    112     BOOT_CONFIG_6           ANT_SW_SEL4     *       R-6
C30     -       RESOUT_N                MSM_RESOUT_N
BOOT_FROM_ROM = (0 - Boot from RPM code RAM, 1 - Boot from ROM)
BOOT_CONFIG pins have internal Pull Down (PD)
R-n = 10K @ 5%,1/20W SMT-0603

Modem Reboot Procedure

(Source: anyclub)

Normally, in the modem restart process, we have following procedure:
  1. Shutdown modem SW
  2. Shutdown modem FW
  3. Power up modem FW
  4. Power up modem SW
Below we show the detail on the reboot procedure and how to configure
related registers in Kernel and TZBSP.
A. Modem SW Shutdown

1. Halt AXI bus port
2. Invoke TZ Modem SW Teardown routine (Refer to heading B. below)
3. Disable Modem SW Voltage Regulator
4. Remove (cancel) MSM XO votes

B. TZ Modem SW Shutdown

1. Put Q6SW in reset. Keep SS ON since we still need to access SS registers. 
   (Set SW_QDSP6SS_RESET = 0x1E)
2. Delay 2 microseconds for reset to propagate
3. Clamp I/O
4. Disable Q6SW core clock
5. Turn off memory footswitches
6. Put Q6SW SS into reset. Set SS bit to 1 in SW_QDSP6SS_RESET register
7. Disable MSS Q6SW AXI clock

C. Modem FW Shutdown

1. Halt AXI bus port
2. Invoke TZ Modem FW Teardown routine (Refer to Heading D below)
3. Disable Modem FW Voltage Regulator
4. Remove (cancel) MSM XO votes

D. TZ Modem FW Shutdown

1. Put Q6FW in reset. Keep SS ON since we still need to access SS registers. 
   (Set FW_QDSP6SS_RESET = 0x1E)
2. Delay 2 microseconds for reset to propagate
3. Clamp I/O
4. Disable Q6FW core clock
5. Turn off memory footswitches
6. Put Q6FW SS into reset. Set SS bit to 1 in FW_QDSP6SS_RESET register
7. Disable MSS Q6FW AXI clock
8. Disable MSS clocks
        a. Put MSS into reset. Set ASYNC_RESET=1 in MSS_RESET register
        b. Disable MSS sleep clock
        c. Disable MSS slave AHB clock
        d. Disable SFAB MSS slave AHB clock
        e. Disable SFAB MSS master AXI clock

E. Modem FW Powerup sequence

1. Vote with RPM to turn on MSM XO
        a. Schedule a Timer (40sec) at expiry of which cancel the XO vote
2. Set Modem voltage regulator's Min and Max Voltage to 1.05 V
3. Set Modem voltage regulator's optimum operating mode (load current= 0.1 amps)
4. Enable Modem FW voltage regulator (LDO28)
5. Unhalt AXI bus port
6. Call into TZ to authenticate and Reset Modem FW. (See heading F. below)

F. TZ Modem FW Powerup

1. Authenticate Modem FW image
2. Clock Setup for Modem Firmware
        a. If not configured already, configure and enable PLL6 @ 460.8MHz non-FSM mode
        b. Setup MSS Clocks (Refer Heading G. below)
        c. Enable MSS Q6FW AXI clock
        d. Bring Q6FW SS out of reset (FW_QDSP6SS_RESET = 0x1E)
        e. Program Q6 GFMUX - input A
        f. Delay 2 microseconds for reset to propagate
        g. Disable core clock:

        The reason for enabling clock in step (c) and then disabling it in this 
        step is to make sure Q6 reset propagates to the core before we enable 
        footswitch settings.

        h. Enable memory footswitch settings (FW_QDSP6SS_PWR_CTL = 0x7F)
        i. Delay 2 microseconds.
        j. Enable core clock (FW_QDSP6SS_GFMUX_CTL, CLK_ENA = 1)
        k. Un-clamp I/O (FW_QDSP6SS_PWR_CTL, CLAMP_IO = 0)
        l. Delay 5 microseconds for the rail to charge
        m. Clear all the bits, except STOP_CORE. STOP_CORE will be cleared after boot 
           address is programmed. (FW_QDSP6SS_RESET = 0x10)
        n. Enable MSS Q6FW JTAG clock (MSS_Q6FW_JTAG_CLK_CTL)

3. Program the reset address
        a. FW_QDSP6SS_RST_EVB = 0x08D40000

4. Clock Enable for Modem Firmware (take Modem FW out of reset)
        a. FW_QDSP6SS_RESET set STOP_CORE to 0

G. MSS Clock Setup

 1. Enable SFAB MSS master AXI clock
 2. Enable SFAB MSS slave AHB clock
 3. Enable MSS slave AHB clock
 4. Enable MSS sleep clock
 5. Bring MSS out of reset since we have to set Q6 bus clocks that are inside MSS. 
   (Set MSS_RESET and ASYNC_RESET to 0)
 6. Wait 2 microseconds
 7. Set MSS bus frequency to 19.2MHz (using XO source)
 8. Trigger DIV update (MSS_CLK_BUS_TRIG, 0x1)
 9. Delay 5 microseconds
10. Check to make sure update is taking place while 
    ((HWIO_IN(MSS_CLK_BUS_STATUS) & 0x1) != 0);
11. Select XO source (MSS_CLK_BUS_CFG, set SRC_MUX_SEL=0)
12. Delay 2 microseconds
13. Enable AHB, AXI Slave clocks of the Q6FW and also Q6SW AHB clock
14. Enable TCXO clock to Q6 and rest of the system.
15. Delay 2 microseconds

H. Modem SW Powerup sequence

1. Vote with RPM to turn on MSM XO
        a. Schedules a Timer (40sec) that cancels the XO vote
2. Set Modem voltage regulator's Min and Max Voltage to 1.05 V
3. Set Modem voltage regulator's optimum operating mode (load current= .1amps)
4. Enable Modem SW voltage regulator (LDO27)
5. Unhalt AXI bus port
6. Call into TZ to authenticate and Reset Modem SW (Refer to heading I. below)

I. TZ Modem SW Powerup

1. Authenticate Modem SW image
2. Clock Setup for Modem Firmware
        a. Enable MSS Q6SW AXI clock
        b. Bring Q6SW SS out of reset (SW_QDSP6SS_RESET, 0x1E)
        c. Configure Q6SW GFMUX - input A
        d. Delay 2 microseconds for reset to propagate
        e. Disable core clock: 

        The reason for enabling clock in step (a) and disabling it in this step is 
        to make sure Q6 reset propagates to the core before we enable footswitch 

        f. Enable memory footswitch settings (SW_QDSP6SS_PWR_CTL, 0x7F)
        g. Delay 2 microseconds
        h. Enable core clock (SW_QDSP6SS_GFMUX_CTL, CLK_ENA, 1)
        i. Un-clamp I/O (SW_QDSP6SS_PWR_CTL, CLAMP_IO, 0)
        j. Delay 5 microseconds for the rail to charge
        k. Clear all the bits, except STOP_CORE. STOP_CORE will be cleared after boot 
           address is programmed to SW_QDSP6SS_RESET = 0x10.
        l. Enable MSS Q6SW JTAG clock (MSS_Q6SW_JTAG_CLK_CTL)
        m. Enable Q6SW AXIS_CLK

3. Program Reset Address
        a. SW_QDSP6SS_RST_EVB =0x08900000

4. Clock Enable for Q6SW. Bring Q6SW core out of reset by setting SW_QDSP6SS_RESET and 
   STOP_CORE to 0.

5. Delay 5 microseconds for Q6 SW to come out of reset
6. Enable HW gating for Q6SW AXIS_CLK (SW_QDSP6SS_CGC_OVERRIDE set AXIS_ACLK_EN to 0) 
Some Qualcomm nomenclature:
SW      - Software Watchdog
FW      - Firmware Watchdog
TZ      - Trust Zone
XO      - spin-lock voting (ON, OFF, PIN_CTRL)
Q6      - The Qualcomm DSP (QDSP) (Audio)
Q6SW    - "Q6" watchdog
SSR     - SubSystem Restart
The MSM8260 / 8660 BOOT_CONFIG and options...

As we have no access to the 8960 document, but only the 8260/8660, we show some of the relevant tables,
for comparative purposes. But we expect these to be the same for the 8960.
The logic behind the GPIO pins and Qfuses are shown in the following diagram.

<< to be continued >>
Attached Thumbnails
Click image for larger version

Name:	MSM8660_SecureBoot_2.jpg
Views:	75327
Size:	35.6 KB
ID:	1411543   Click image for larger version

Name:	MSM8660_SecureBoot_3.jpg
Views:	75195
Size:	39.1 KB
ID:	1411544   Click image for larger version

Name:	MSM8660_SecureBoot_4.jpg
Views:	74966
Size:	71.4 KB
ID:	1411545   Click image for larger version

Name:	MSM8660_SecureBoot_5.jpg
Views:	75018
Size:	29.4 KB
ID:	1411546  
Last edited by E:V:A; 18th October 2012 at 03:35 PM.
The Following 11 Users Say Thank You to E:V:A For This Useful Post: [ View ]
1st September 2012, 04:51 PM |#4  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
A list of previously posted pictures for quick reference

Simplified Block Diagram

(Courtesy MobileTechWorld )

MSM8960 BGA pad layout (top view, bottom pads):

Secure Boot 3.0 Code Flow:

Secure Boot 3.0 Boot Loader Structure:

Secure Boot 3.0 Boot Procedure:

RPM PBL Memory Map:

Secure Boot 3.0 Error Handler:

Last edited by E:V:A; 14th September 2012 at 11:13 PM.
The Following 13 Users Say Thank You to E:V:A For This Useful Post: [ View ]
3rd September 2012, 10:39 PM |#5  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
The Secure Boot 3.0 Process

The boot procedure is in the order as follows.


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


• 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 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 (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

<< to be continued >>
Last edited by E:V:A; 16th September 2012 at 12:22 PM.
The Following 11 Users Say Thank You to E:V:A For This Useful Post: [ View ]
4th September 2012, 06:38 PM |#6  
I thought I may add to this... I was working with the Galaxy S3. I took your processor pinout and laid over the top of the Verizon GS3. Maybe it is useful here.. Either way, you can clearly see there are 7 resistors near the 7 xOM pins.
Last edited by AdamOutler; 11th September 2012 at 03:24 AM.
The Following 7 Users Say Thank You to AdamOutler For This Useful Post: [ View ]
4th September 2012, 08:37 PM |#7  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
Qualcomm Technical Terms & Acronyms

AMON    ARM9 Monitor
AMSS    Advanced Mobile Subscriber Software     
APPSBL  Applications Processor Secondary Boot Loader
CE      Crypto Engine
DBL     Device Boot Loader                      
EBI     External Bus Interface
EFI     Extensible Firmware Interface
ETM     Embedded Trace Macrocell
FEC     Forward Error Correction
IMEM    Internal Memory
OSBL    Operating System Boot Loader            
REX     Real-Time Executive (RTOS)
RUU     Remote Update Utility
SD3     Security Domain 3                       
SMC     Security Mode Control (module)
SMEM    Shared Memory                           
SMSM    Shared Memory State Machine
TAP     Test Access Port
TSIF    Transport Stream Interface
LK      Little Kernel (bootloader) 

PBL     Primary Boot Loader
SBL     Secondary Boot Loader
RPM     Resource Power Management
SMC: The security mode control module (SMC) supplies the software interface
to the NV memory content. It also aggregates all of the logic for secure debug
and boot mode selection. The SMC implements a slave AHB interface and is
connected to the modem bus.

===> Seem like they have changed name to SCM (Security Control Module)
===> See: Kernel:: ./arch/arm/mach-msm/scm.c

Other Qualcomm Device Type Nomenclature:
SURF    - Subscriber Unit Reference (Development board.)
FFA    - Form Factor Accurate (A reference design phone.)
Last edited by E:V:A; 16th September 2012 at 10:10 PM.
The Following 4 Users Say Thank You to E:V:A For This Useful Post: [ View ]
9th September 2012, 12:47 AM |#8  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
<< for reference ! >>

The MSM8260 / 8660 Memory Map

There are very good reasons to believe this is very similar to that for the MSM8960...

<< To Be Continued .. >>
Attached Thumbnails
Click image for larger version

Name:	MSM8660_MEM_1.jpg
Views:	73588
Size:	51.4 KB
ID:	1411627  
Last edited by E:V:A; 18th October 2012 at 03:52 PM.
The Following 2 Users Say Thank You to E:V:A For This Useful Post: [ View ]
16th September 2012, 12:46 PM |#9  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
Qfuses in the MSM8960

In order to simplify the design and satisfying the requirements for a wide
range of hardware external to the MSM. Qualcomm has incorporated a reserved
One-Time-Programmable (OTP aka PROM) memory region, onto their SoC's, that
they call QFPROM. This region contain a collection of all necessary HW related
configuration settings for the operation of the MSM itself, as well as for
most popular peripheral devices such as PMIC, HDMI, eMMC, SD, USB and many

The actual content of the QFPROM in the MSM8960 is a 4KB (4096 byte) region
of registers, that can be burned (fused) permanently by either Qualcomm
and/or the OEMs like Samsung and HTC, by themselves. Most of the registers
are related to peripheral HW settings, but there is also a region specifically
allocated for various chip security features, such as configuring the boot
process and setting various locking, authentication, JTAG and other
accessibility and debug features.

In older Qualcomm SoC models the various PROM registers was referred
separately to as Efuse-registers and Security/Boot registers, etc. Now,
however, they just use the acronym "Qfuses" for this entire collection,

Knowing what Qfused features are incorporated and activated in a particular
device, can be extremely helpful, if not necessary, for the debugging and
revival of "bricked" devices. In those cases where a recovery is possible, we
refer to the device as having been "soft-bricked". However, in some cases when
no other method of revival is possible, we label the device as "hard-bricked".
In the most extreme case, a company or government may choose to build their
devices so tightly locked down, that any manipulation attempts detected by the
IROM bootloader, may trigger a range of fuses to make the device impossible to
boot or extract information from.

For the developer community this is both a challenge and a pain in the arse.
We get bricks from left and right, but we have absolutely no useful or freely
accessible documentation for how to determine the internal HW settings that
can be useful to revive our phones and tablets. This is an attempt to lighten
those problems, by properly and openly documenting the interior functionality
of our PoP SoC chips. In this case the widely popular MSM8960 aka
"Snapdragon 4S".

As the QC empire only speaks in terms of $$$, we have to expect that there
will never be any publicly available documentation on this (or any future)
top-model chip-sets from Qualcomm. Security by obscurity is their motto,
because that is what their sales numbers and marketing officers are telling
them is right. So we have to collect the moldy bread-crumbs to glue together a
dough that we can hopefully bake into a piece of bread. The crumbs in question
are scattered throughout the Kernel source-code, old and outdated
documentation and reverse engineering of bootloaders and other firmware,
sprinkled with an occasional document leaks, that temporarily brighten our
dark days of hardware development.

The Qfuses discussed herein are separated into three categories:
  1. Boot-up and Security settings
  2. Other internal MSM settings
  3. External peripheral device settings

A Qfuse register map would of course have been heaven, but we'll have to
settle with trying to map out approximate locations and by time-consuming
trial-and-error methods.

Current Status

What we know so far can be summarized in a few lines. Below I have also added
some unreliable register specifications for some older chips, as a comparative
reference. Hopefully at least part of these will have some resemblance to
those used in the 8960.

One thing that seem fixed in all mobile phones PBL's and Kernel sources is
the QFPROM base address location. This can be somewhat confusing because
apparently the QFPROM fuses cannot be simply read directly at their base
addresses. Probably because some Kernel or HW security feature is preventing
these memory reads from user-land. Instead the Qfuse registers are shadowed
into another RAM region that is used by bootloaders to find the true Qfuse
values. According to some documents this shadow region also contain an error
correction value. However, it is not clear if the entire 4K region is
shadowed or only part of it...

From an older MSM document:
The CONFIG chain includes shadow registers that relatch sensed fuse values
upon completion of fuse-sense operations. This latching is done in the
security mode control block and is necessary because with JTAG access to the
CONFIG chain, it is possible to scan any value into fuse cell latches, making
a blown fuse appear unblown to the rest of the logic. Shadow registers store
the actual fuse values immediately after sensing and maintain them even if
different values are scanned into the fuse cells.

QFPROM SHADOW BASE:     0x00706000
QFPROM SIZE:            0x1000  (4K)
Reading Qfuse registers

So how can we use this info to read the values from the Qfuse block? Well,
its actually not very difficult at all. The hardest thing is to be able to
confirm that what you think you read, is what is actually there. There are
many ways to corrupt simple memory reads, ranging from standard linux security
measures to Qualcomm-specific memory protection. Luckily, at the moment, these
are rarely implemented.

The easiest tool to use is viewmem. There is also another tool called devmem2,
(src) originally made for the RasberryPi, that also support writing to memory.
Both tools depend on the /dev/mem device. If this is not present or accessible
on your system, these tools will not work. Finally there is a memory forensic
tool called LiME (Linux Memory Extractor), which is a kernel module that take
an image snapshot of the entire system, regardless of /dev/mem presence or
other memory protection schemes.

These are all general memory utilities. However, Qualcomm have their own tool
to read and write Qfuse blocks. The device driver is present in the CodeAurora
repository for their MSM specific Kernel here: ./drivers/misc/qfp_fuse.c
So for the real brave ones, you can try to compile your own Qfuse reader or
writer. (I'd like to have a copy!)

Now to the slighlty tricky part of correctly reading the memory. When reading
a memory register of, let's say, 32bits. It's important you understand how ARM
based Android devices handle endianess. Although ARM processors are bi-endian
since version 3, the ARM is used as little endian by default when used in
Android mobile devices.

The viewmem program uses /dev/mem to output raw data to whatever device you
specify, or to your terminal if none is specified. In order to see this data
you need to either use a hexeditor or filter the output through hexdump.
However, hexdump have some little quirks when it come to data ordering. To get
the same byte ordering as in the raw file, you need to use the "-C" switch,
otherwise the MSB and LSB, byte-pairs will be switched around with respect to
the raw input. So to make a few examples.

Example-1: Reading and displaying the OEM_CONFIG0 Qfuse register
viewmem 0x706024 0x4 |hexdump -C

00000024  00 00 c0 19

Raw Hex:        00 00 C0 19

Little Endian:
=> Hex:         [0000 C019]
=> Bin:         [0000 0000  0000 0000  1100 0000  0001 1001]
                 |                                        | 
=> Byte#:       LSB  4          3          2          1  MSB
Here "Byte#" refers to the byte number reading order, so if the above
4 bytes was an address, it would have been "0x19c00000".

Example-2: Reading/dumping the raw Qfuse region (probably provides false data)
viewmem 0x700000 0x1000 >/path_to_sd_card/qfprom_raw.bin
Example-3: Reading/dumping the Qfuse shadow region (?)
viewmem 0x706000 0x1000 >/path_to_sd_card/qfprom_shadow.bin
Example-4: Reading/dumping PBL from IROM
viewmem 0x0 0x18000 >/path_to_sd_card/pbl.bin

QFPROM Register Map for the MSM8260 / 8660

The document gods have been good, and we have been blessed with some 8660 documentation
that may help shed some light on the 8960. Here is the Qfuse (QFPROM) register map, showing the 2K block.
(The 8960 apparently use a 4K block!)

In addition the QFPROM programming algorithm is already included in the code.
(Probably in one of the secondary bootloaders; SBL1-3...)
Attached Thumbnails
Click image for larger version

Name:	MSM8660_QFPROM_1.jpg
Views:	75669
Size:	73.5 KB
ID:	1411604  
Last edited by E:V:A; 18th October 2012 at 03:47 PM.
The Following 8 Users Say Thank You to E:V:A For This Useful Post: [ View ]
16th September 2012, 12:47 PM |#10  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
1. Boot-up and Security settings

PAO     Qfuse Name              [bits]                  Function        
0x      QFPROM VID/PID                                  USB Vendor/Product ID (support?)

0x24    OEM_CONFIG0             [0:7]?  

        bit     Function                        Setting                 
        0x0     EhostDL Disable                 (1="disable EhosdDL")
        0x2     90s USB enumeration timeout     (0=disable*, 1=enable)

0x      FEATURE_CONFIG2 [0:31]?
        0x16            90s image download timeout      (0=disable*, 1=enable)

0x      AUTH_USE_SERIAL_NUMBER                                  PBL serial number read
0x      QFPROM_CORR_PTE_LSB                                     <the serial number> 
0x      OEM_PK_HASH             [0:2048]?                       The OEM Public Key Hash
0x      MSM_HW_ID               [0:63]  
                                [63:32] (32 MSB) MSM_REVISION_ID
                                [31: 0] (32 LSB) = SERIAL_NUM if (AUTH_USE_SERIAL_NUMBER) else OEM_ID    
Where PAO = "Physical Address Offset" from QFPROM_SHADOW_BASE.

The documentation states that there is some commands that are used for reading.
It is currently unknown where and how these commands are entered.

CMD_SERIAL_NUM_READ     0x16    Read the <serial number>/<OEM_ID> 
CMD_HASH_KEY_READ       0x18    Read the root cert hash from boot ROM or in OEM_PK_HASH

Some other unconfirmed Qfuses:

PAO     Qfuse Name              (#)[bits]       Function        Comment
0xBC    QFPROM_PTE_ROW0_MSB     (4)[]           PTE ??          
0xC0    QFPROM_PTE_ROW1_LSB     (4)[]           PTE/CPU speed/ PVS classification (aka QFPROM_PTE_EFUSE_ADDR)
                                (3)[10:12]      PVS (a) 
                                (3)[13:15]      PVS (b)

Address         Qfuse-function  Arithmetic                      What
0x706034        BOOT_CONFIG[X]  (@0x706034 & 0xFC) >> 2         upper 6 bits
0x706038        SECURE_BOOT[?]  (0x706038 & 0x20)               6th bit
Other Devices (for reference)

Then, and just for reference, we have some documents with Qfuses used on some older devices.
Here are some for the MSM7x25 and MSM7200.

MSM7x25:        Security Registers
Name                            #bits   Purpose 
DEBUG_EN_KEY                    105             Debug enable key
SECONDARY_HW_KEY                195             Secondary HW key that OEMs can use

Configuration Chain:

PRIMARY_BOOT_FROM_ROM           [0]*            Ensure that MSM boots from on-chip PBL  
FORCE_TRUSTED_BOOT              [6]             Force PBL to authenticate off-chip SBL
BLOW_FUSES_CHAIN_DIS            [18]            Prevents any changing of any other fuse values.
DEBUG_EN_KEY_CHAIN_DIS          [30]            Prevents any changing of the customer-specific debug key
SEC_HWKEY_CHAIN_DIS             [20]            Prevents any changes to the Secondary HW key
SW_FUSE_PROGRAM_DISABLE         [53]            Disable SW fuse programming ability
DISABLE_DBG_KEY_READ            [62]            Disable reading the DBG_EN_KEY register from SW. Reading return all 0.
MARM_ANY_MODE_DEBUG_DISABLE     [47]            Disable access to the modem ARM9 debug TAP port for all modes

COM_GOVT_SELECT                 [216:218]       Public key select. Three fuses for majority vote encoding.
COM_PUBLIC_KEY_SELECT           [1:5]           Commercial public key select (select one of 32 (2048 bit keys) from ROM).

OEM_HW_ID_AUTH_ENABLE           [69]            
OEM_ID(9:0)                     [32:39,45,46]   
OEM_PRODUCT_ID(6:0)             [81-75]         

PRI_HW_KEY                      (256 bits + FEC)
SEC_HW_KEY                      (256 bits + FEC)
CONFIG                          (170 bits + FEC)

Device manufacturer identification code (administered by JEDEC);
Qualcomm’s code is 0000_0111_0000 (0x070).

MSM7200:        Security Registers
OFS     #bits   Name            Function
0x38    2       SEC_BOOT_MODE           
0x44    32      CONF_FUSE_1     The CONF_FUSE_1 register contains additional configuration fuses, as defined in the "Efuse registers"
0x48    32      CONF_FUSE_2     HW_REVISION_NUMBER + DISABLE various HW
0x4C    32      CONF_FUSE_3     SERIAL_NUMBER
0x50    32      CONF_FUSE_4     COM_GOV_SEL etc.
0x50    1       VDD_BLOW_EN     Setting this bit to 1 will switch the Efuse VDD_4_BLOW pad switch to blow.

                Efuse Registers
OFS     #bits   Name            Function
0x0     32      EF_CHAIN_SEL    The EF_CHAIN_SEL register controls which efuse chain to program. 
                                Large chains are broken into multiple blocks.
0x4     8       EF_BLOW_TIMER   This register is for programming the time to hold VDD_blow_fuse active to blow the fuse.
                                Number of clocks minus 1 that the blow_fuses signal is held high, applying blow voltage to the fuse.
0x8     8       EF_BLOW_VALUE   This register holds the data to be shifted into the selected chain.
0xC     12      EF_SHIFT_VALUE  This register describes how far to shift the EF_BLOW_VALUE into the selected chain.
0x10    2       EF_STATUS       Writing to bit 0 in this register starts a state machine that will blow the appropriate fuse.
                                SW must poll bit 1 of this register to see when the programming is done.
0x14    -       EF_SEL_NO_FEC   To use the forward error correction, the ENABLE_FEC fuse must be blown.
0x18    7       EF_FEC_ERR      This read-only register reports when the FEC block was not able to correct an error.

Last edited by E:V:A; 16th September 2012 at 09:27 PM.
The Following User Says Thank You to E:V:A For This Useful Post: [ View ]
16th September 2012, 12:47 PM |#11  
E:V:A's Avatar
OP Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,008
2. Other internal MSM8960 settings

HDMI:                   ./drivers/video/msm_8x60/hdmi_msm.c
qfprom_aksv_0 = inpdw(QFPROM_BASE + 0x000060D8);
qfprom_aksv_1 = inpdw(QFPROM_BASE + 0x000060DC);

Sensor: Temperature     ./drivers/thermal/msm_tsens.c
#define TSENS_QFPROM_ADDR (MSM_QFPROM_BASE + 0x000000bc)

TODO: Needs to read calibration data from QFPROM. Right now, assume it is 0x5a at 30 degC If direct access to QFPROM is reasonable with the "legal team", physical addr 0x7040bc bit [16,31] is where data resides for 8660. You need the physical addr. -> virtual addr. translation block in the msm_iomap-8x60.h before accessing the data using virtual addr.

------------------------------------------------------------------------------- CPU Clock ./arch/arm/mach-msm/acpuclock-8960.c ------------------------------------------------------------------------------- /* PTE EFUSE register. */ -#define QFPROM_PTE_EFUSE_ADDR (MSM_QFPROM_BASE + 0x00C0) #define QFPROM_PTE_ROW0_MSB (MSM_QFPROM_BASE + 0x00BC) #define QFPROM_PTE_ROW1_LSB (MSM_QFPROM_BASE + 0x00C0) pte_efuse = readl_relaxed(QFPROM_PTE_EFUSE_ADDR); pvs = (pte_efuse >> 10) & 0x7; if (pvs == 0x7) pvs = (pte_efuse >> 13) & 0x7;
Last edited by E:V:A; 16th September 2012 at 09:36 PM.
The Following User Says Thank You to E:V:A For This Useful Post: [ View ]

Read More
Thread Closed Subscribe to Thread

architecture, bootloader, msm8960, qualcomm, schematics
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes