[R&D][QUALCOMM] Using QDL, EHostDL and DIAG interfaces & features

Search This thread

SouL Shadow

Senior Member
Jun 17, 2010
466
325
Stratford, CT
www.soulshadow.net
for information, dump is not raw dump from memory.
it "processed" by HDLC packet escape and need to be cleaned with something like this:

Code:
iCount:=0;
oCount:=0;

while iCount<=FileSize-1 do  

begin
if input[iCount]=$7D then 
  begin
  output[oCount]:=input[iCount+1] xor $20;
  inc(iCount);
  end
else 
output[oCount]:=input[iCount+1];

inc(iCount);
inc(oCount);
end;

Thanks. What language is that?

-SLS-
 

SouL Shadow

Senior Member
Jun 17, 2010
466
325
Stratford, CT
www.soulshadow.net
Didnt work with QPST_2.7_378 and Samsung Rugby Pro I847C MSM8690
-> Cookie not Present Error :crying:

But anyway, very BIG THX :fingers-crossed:


Short answer:

The "Cookie not Present Error" means you're phone is not in the PBL's EhostDL.


Long answer:

Because the same qhsusb_dload (aka download mode) is built in to each stage of the boot process (pbl, sbl1, sbl2, sbl3) and different features are only available at certain stages, the "boot cookie" is used to help identify to QPST when you're in the pbl.

Think of it this way, download mode is a type of fatal error handler. If during the boot process an error is encountered preventing further boot up, that error is logged to memory and control is transfered to the download mode built in to the highest successfully loaded bootloader.

  • Turn phone on -> Load PBL from SoC
  • PBL does very basic hardware init and loads SBL1 from emmc
  • SBL1 does more hardware init and loads SBL2 from emmc
  • SBL2 does other hardware init and eventually loads SBL3 from emmc
  • SBL3 does final hardware init and loads APSBL (aka OEMSBL: aboot, hboot, etc...)

At any stage above, if a fatal error is encountered, then download mode in the corresponding bootloader is entered. EhostDL (aka Emergency Host Download or Emergency Download) is ONLY available from the PBL and is only used to load the corresponding .hex file which will do just enough basic hardware init to allow the rest of the bootloaders (and the emmc partition table) to be downloaded and flashed to the phone.

This is just a quick overview. For a more in depth look at the entire boot process, please look at the documents linked from E:V:A's msm8960 thread (there's a link to his thread in the OP). In particular, there is a 30-40 page pdf which details the boot process, including memory addresses, and has some nice flow charts which help to visualize what I briefly touched upon.

-SLS-
 
  • Like
Reactions: fairsimple

saketh91

Senior Member
Sep 10, 2011
577
94
Denver
OnePlus 9 Pro
Short answer:

The "Cookie not Present Error" means you're phone is not in the PBL's EhostDL.


Long answer:

Because the same qhsusb_dload (aka download mode) is built in to each stage of the boot process (pbl, sbl1, sbl2, sbl3) and different features are only available at certain stages, the "boot cookie" is used to help identify to QPST when you're in the pbl.

Think of it this way, download mode is a type of fatal error handler. If during the boot process an error is encountered preventing further boot up, that error is logged to memory and control is transfered to the download mode built in to the highest successfully loaded bootloader.

  • Turn phone on -> Load PBL from SoC
  • PBL does very basic hardware init and loads SBL1 from emmc
  • SBL1 does more hardware init and loads SBL2 from emmc
  • SBL2 does other hardware init and eventually loads SBL3 from emmc
  • SBL3 does final hardware init and loads APSBL (aka OEMSBL: aboot, hboot, etc...)

At any stage above, if a fatal error is encountered, then download mode in the corresponding bootloader is entered. EhostDL (aka Emergency Host Download or Emergency Download) is ONLY available from the PBL and is only used to load the corresponding .hex file which will do just enough basic hardware init to allow the rest of the bootloaders (and the emmc partition table) to be downloaded and flashed to the phone.

This is just a quick overview. For a more in depth look at the entire boot process, please look at the documents linked from E:V:A's msm8960 thread (there's a link to his thread in the OP). In particular, there is a 30-40 page pdf which details the boot process, including memory addresses, and has some nice flow charts which help to visualize what I briefly touched upon.

-SLS-

hi soulshadow thanks for you keen interest in helping others with this.I am still waiting for the solution for my problem.can I expect any solution for unbricking my phone in a few days.(sorry lost hope).
thank you
 

darkspr1te

Senior Member
Sep 24, 2012
951
590
hi soulshadow thanks for you keen interest in helping others with this.I am still waiting for the solution for my problem.can I expect any solution for unbricking my phone in a few days.(sorry lost hope).
thank you

I doubt SLS will have chance to come up with a solution in the next few days, if he is half as busy as me he little to no time to spare, devs tend to 'just' have a bit of time and its not planned time either, its not our main source of income and we often have wife's/kids/husbands/parents all also seeking our time. I am lucky if I get a hour every two days to do development, and often a bit of that time is taken up by getting into the mind set.
What I am saying is don't be too disappointed if you hear nothing, progress often goes in jumps.

sent from the Darkspr1te's lair
 

SouL Shadow

Senior Member
Jun 17, 2010
466
325
Stratford, CT
www.soulshadow.net
hi soulshadow thanks for you keen interest in helping others with this.I am still waiting for the solution for my problem.can I expect any solution for unbricking my phone in a few days.(sorry lost hope).
thank you

No. Your phone requires an HTC signed hex file to enable repair of your partition table. Without the signed file we have no way of fixing your phone (and many other ppl's phones).

-SLS-
 

starteam

Member
Apr 20, 2013
28
1
my phone is LG Optimus G Pro and korean F240L;it is bricked ,when connected PC,apear "QHSUSB_Dload",after installed its driver,become “QualcommHS-USB QDLoader 9008 (COMx)”
I want use QPST emmcswdownload fix it,but how can I get the HEX file of APQ8064T(SnapDragon 600), MPRG8064?.hex .
Who can Tell me ?
 

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,449
2,218
-∇ϕ

  • To provide a partial Open Source (Linux) replacement for QPST and QXDM
Are we getting any closer to this? (Or are there already some other free software out there we can use? [Unfortunately I've been out of the loop for a while, so I'm not well updated on what people are doing...] I'd love to see an open source QXDM prototype...
 

darkspr1te

Senior Member
Sep 24, 2012
951
590
[/LIST]
Are we getting any closer to this? (Or are there already some other free software out there we can use? [Unfortunately I've been out of the loop for a while, so I'm not well updated on what people are doing...] I'd love to see an open source QXDM prototype...

I am not currently working on anything due to not having a Qualcomm device at the moment.
But I am will to assist anyone who does continue the work.

Sent from my A210 using Tapatalk HD
 

rafael_mfr

Senior Member
Jul 14, 2011
361
69
Recife
I've 3 Padfone 2 devices. Two of them are with qhsusb_dload state and don't turn on. But there is one in properly conditions, how can I fix the others? Can I use QPST EMMCSOFTWAREDOWNLOAD to repair them? I tried already without successfull. Thanks!

Sent from my PadFone 2 using Tapatalk 2
 

SouL Shadow

Senior Member
Jun 17, 2010
466
325
Stratford, CT
www.soulshadow.net
[/LIST]
Are we getting any closer to this? (Or are there already some other free software out there we can use? [Unfortunately I've been out of the loop for a while, so I'm not well updated on what people are doing...] I'd love to see an open source QXDM prototype...

I've been busy with other real life events. I also under estimated both the massive scope of such a project and the limited interest others have shown in it. The original goal was to create an app that could be used instead of QPST to help recover bricked phones. To do that in a forward thinking way, I wanted to implement the core protocols that underlie both QPST and QXDM. With the changes to Qualcomm's security (ex: sec boot 3), such a program seems less useful, until it supports a lot of QXDM-like features, which would take a while to implement (tens of thousands). Despite being out of work since May, I've actually had less free time as I have been taking many classes to update and expand my computer skills.

I've been so busy that I've only flashed 2 different ROMs in the past 6 months!

For anyone interested, the Gobi3000 source contains most of the needed backend written in C++. The trick is to further separate the Gobi features from the protocol implementations, fill in the blanks and begin adding higher level services using these protocols. That is what I was planning to do. It's faster and easier than starting from scratch, but you'll need a good understanding of C++ namespaces, classes and templates.

Anyway, I'll continue to watch this thread and others for miracles news. Anyone who wants to actively work on this is free to use this thread. Being an R&D thread, active and on-topic discussion is always encouraged! I get email notifications of thread and private messages so I can update the OP or answer a question if needed. Anyone asking for unbricking help or qualcomm docs will be ignored.
 

insink71

Senior Member
Nov 9, 2010
610
252
Greenville, SC
teamblueridge.org
interested

I am not currently working on anything due to not having a Qualcomm device at the moment.
But I am will to assist anyone who does continue the work.

Sent from my A210 using Tapatalk HD

I would be interested in such and have a few qualcomm devices. Also, I have my stand-by riff box ;) Good news I suppose is I could disassemble resurrect dll's [riffbox also uses windows] to see what critical portions of radio are rewritten to debrick [for target devices]. Translating it to python might be a learning experience. Might could help w/ providing a hosting mirror as well ref: https://teamblueridge.org/projects/files

Rob

PS more interested in per device unbricking [like you did] [perhaps adding other service options like sim unlock, supercid but probably not off-s] since I have a comparative tool; developing open source qpst beyond my skill set.
 
Last edited:

Heathcliff74

Inactive Recognized Developer
Dec 1, 2010
1,646
2,609
Qualcomm msm8960 on Windows Phone 8 devices

Hi,

I'm from the Windows Phone camp. In the past I've been working on a lot of Windows Phone 7 devices. Currently I'm working on 2 Windows Phone 8 devices: Samsung Ativ S (I8750) and Nokia Lumia 920 (RM-821). The Samsung device is an R&D device which has non-blown fuses, which means that QPST and other goodies are available on this device. The Nokia device is a retail device, which is fully secured. Both have the Qualcomm msm8960 chipset.

I'm quite new to hardware-hacking. I've been reading in this forum and other docs to catch up a little. But I'm still in the dark on some things. This thread seems to be the most appropriate one to ask my question.

For my current research I'm interested in one thing specifically: I want to read the OEM_PK_HASH from the QFuse of the devices. The Nokia has its fuses blown, so that won't be possible. But I'd like to be able to read the QFuse data from the Samsung.

I know how to put the Samsung in Qualcomm COM mode and Qualcomm DLOAD mode. In both cases I can connect QPST. In COM mode I can use the normal Software Downloader (to make a backup of NV) and other tools. In DLOAD mode, I can run the eMMC Software Download app. In the eMMC Software Download app, a QFuse button is available. There I can add addresses and then press the Read button. I'm not able to get this working correctly. First of all, I do know the address where OEM_PK_KEY should be, but I don't know the values for LSB and MSB. When I try to read an address, I always get this error:

Code:
Fuse blowing - QfpromRead - response command field (0x3) not equal to 0x35
Fuse read completed

ReadQFuse.png

I read that it might be necessary to send a Flash Programmer image to the chip first. It will be loaded in RAM and then communicate with the client on the PC. So I tried that. I selected MPRG8960.hex, but when I try to send it to the chip, the eMMC Software Download app just becomes unresponsive.

DownloadProgrammer.png

When I forcibly restart the eMMC Software Download app, nothing is changed; same error when I try to read the QFuse data.

My questions are:
- Why do I get the error message and how do I get around that?
- Which LSB and MSB values do I need to have, to be able to read the OEM_PK_HASH?

Any other information that could help me in the good direction is welcome.

Thanks a lot all, for posting all this info on XDA.

Ciao,
Heathcliff74
 
Last edited:

darkspr1te

Senior Member
Sep 24, 2012
951
590
Have a look at cdmatools and rev, I cover the usage of them plus other Qualcomm tools in my debrick of shv-e160, Qpst also has companion progs like qdart and qdm

Sent from my a210 using Tapatalk
 

stepw

Senior Member
Feb 11, 2007
589
16
- Why do I get the error message and how do I get around that?
- Which LSB and MSB values do I need to have, to be able to read the OEM_PK_HASH?

Any other information that could help me in the good direction is welcome.

Thanks a lot all, for posting all this info on XDA.

Ciao,
Heathcliff74

According to DMSS Download Protocol specs (attached to this thread) Command (0x03) = NAK response packet. This must be the response you receive when command 0x35 is sent to the phone to read QFPROM. The phone doesn't seem to support this command, or command parameters were not accepted.

Perhaps if you sniff the entire packet with a USB sniffer, you can get extended NAK reason and if it's listed in Table 3-5 NAK reason codes in the same document, that should give you an idea why phone rejects command 0x35.

LSB/MSB values are likely OEM specific. Some OEMs include backdoors in their ROMs or bootloaders that can be used to read QFPROM and map QFuses to MSB/LSB.

PS Have you reviewed http://forum.xda-developers.com/showthread.php?t=1856327? Plenty of useful info over there, MSM8960 in general and QFuses in particular, specifically for LG handsets...
 
  • Like
Reactions: dazza9075

Top Liked Posts

  • There are no posts matching your filters.
  • 27
    This thread is for the research, development and discussion of open source tools (initially Linux) to communicate with and utilize the various proprietary interfaces available on Qualcomm devices.

    Initial development is centered around the MSM8660 and MSM8960 devices, but should be applicable to nearly any Qualcomm device which includes a modem and USB port. Older devices with a Serial port may also work. Components to be supported: DMSS Download Protocol (QDL mode), Streaming Download Protocol (EHostDL), and parts of other HDLC structured Qualcomm protocols.


    An expanded description, examples, references, and test programs to follow shortly.


    Goals
    • To provide a partial Open Source (Linux) replacement for QPST and QXDM
    • To enable the full recovery of various Android devices based on supported Qualcomm SoC's
    • To gain a better understanding of the underlying hardware in Qualcomm based Android devices


    Change Log:
    • 2013-01-06
      Initial creation to consolidate OT discussions from other threads.
    • 2013-01-07
      Expanded description
      Added external thread and web links
      Added #QDL_Dev on IRC Freenode for open discussion
    • 2013-01-28
      Updated a few posts to correct prior mistakes.


    Internal Thread Links
    • coming soon...


    External Thread Links


    External Web Links
    • Code Aurora Forum https://www.codeaurora.org/
      Home to various Open Source projects related to Qualcomm technologies.
    • Gobi https://www.codeaurora.org/contribute/projects/gobi/
      A Code Aurora Forum project fueled by Qualcomm which serves as a reference for these protocol implementations.
    • AnyClub Blog http://www.anyclub.org/
      A blog with limited yet specific information regarding Qualcomm MSM, MDM, QRD and related products. Can get technical at times and references closed source and proprietary files/programs.


    Join us for live discussion in #QDL_DEV on IRC Freenode


    Credits/Thanks:
    • E:V:A for various reference threads which both sparked my interest and fueled my initial research.
    • Darkspr1te for his involvement with initial and ongoing development.
    • Ralekdev for providing additional insight in to msm8960 PBL
    • .
    • Yarrimapirate for creation of JET (Jewel Evita Toolkit) which served as my first hands-on with QDL and led me down the path to here.
    • Fuses for his emmc_recover program, which gave me my first glimpse of using HDLC to communicate with a Qualcomm based phone. Also for his typically brief and discouraging posts, which in turn drives my desire to prove him wrong :)
    • Captain_Throwback for providing firmware zips, testing, and more bricked phones then anyone else I've met.
    • others whom I'll add as I think of them.
    9
    Knowledge Base

    Definitions:
    • PBL = Primary Boot Loader
    • SBL = Secondary Boot Loader
    • RPM = Resource and Power Management
    • TZ = Trust Zone
    • HDLC = High-level Data Link Control
    • MSM = Mobile Station Modem
    • DMSS = Dual-Mode Subscriber Station
    • QDL = Qualcomm Download
    • QHSUSB_DLOAD = Qualcomm High Speed USB Download
    • EhostDL = Emergency Host Download
    • DCN = Document Control Number, used by Qualcomm to track their thousands of documents

    Qualcomm has built in to their firmware multiple methods of communication with outside "hosts" (a computer connected to the phone). Each method serves a particular function. AT commands are used to communicate with the modem while it is "online" and their multiple diagnostic protocols communicate with the modem in "offline" mode. These diagnostic protocols use HDLC (both synchronous and asynchronous) for the framing. It is a low overhead frame/packet transport which includes a 16 bit CRC for error checking, originally used over serial connections to the phone. Today these protocols are still being used over USB. Under Linux a usb-serial connection can be established by the qcserial kernel module via a /dev/ttyUSB (ex: /dev/ttyUSB0, /dev/ttyUSB1)

    HDLC: A brief overview.
    The basic HDLC structure is:
    Each field is a multiple of 8-bits (1 byte).
    HDLC uses 0x7e for the header and flag. For AsyncHDLC the header is optional, but Qualcomm always uses it. Also, the flag of one HDLC frame is allowed to be used as the header of the next frame. It also uses 0x7d as an escape for occurrences of 0x7e and 0x7d. All escaping is done after calculating the CRC and is applied to both the packet and CRC.

    The packet is further broken down in to:
    The packet header consists of:

    The command is a 1 byte (0x00) code that determines the layout of the packet.
    The parameters vary by command and specify different command specific options and the size of any data being transferred.

    The CRC is generated using the standard CRC-CCITT-16 generator polynomial of: f(x)=x^16+x^12+x^5+1
    Google it for more info.

    Examples:
    • NO-OP: 7e 06 4e 95 7e
    • ACK: 7e 02 6a d3 7e
    • Software Version Request: 7e 0c 14 3a 7e
    • Software Version Response: 7e 0d 0f 50 42 4c 5f 44 6c 6f 61 64 56 45 52 31 2e 30 37 41 7e

    Full Documentation:
    • DMSS Download Protocol: DCN 80-39912-1 Revision E
      Describes in detail the commands used with QHSUSB_DLOAD (both SBL and PBL)
    • Streaming Download Protocol: DCN 80-V5348-1 Revision J
      Describes in detail the commands used with the Flash Programmer (MPRGxxxx.hex)
    • CDMA DMSS Serial Data: DCN 80-V1294-1 Revision YP
      Describes in detail the basic commands used with the modem Diagnostic mode. This protocol supports a MASSIVE amount of extentions covered in numerous other specialized documents. There is no current plan to implement these extensions.


    ...more to follow...
    8
    DMSS And Streaming Protocol Tool

    UPDATE: Code updated as of 17-01-2013, post will update to follow new code soon - Darkspr1te

    First POC, Thats Proof of concept , not piece of c**p.

    The concept behind this came from Soul Shadow, who like me feel that in a world without walls and fences who need windows and gates.
    The original script was pulled from some git/website i dont remember belonging to a person i only know as scotty (please step forward )
    JCSullins over from rootzwiki went running with the script to give us this working concept.

    What is it?
    This script fire's HDLC encoded frames at the serial port, namely qcserial for a Qualcomm HS_USB QDLOAD device 05c6:9008
    within these frames are commands for various functions with great names like Hello, and Open MI.
    Here is a example frame
    Code:
    0x7e 0x0a 0x63 0x74 0x7e

    0x7e start of frame
    0x0a command (this one is with out data)
    0x63 crc low bit
    0x74 crc high bit
    0x7e close of frame

    HDLC is all well document around the net so i wont go over it too much just yet. the important part is knowing the commands, what they do and what the payload, if any is and how that's formatted.

    Why Do We need it?
    The QDLOAD and EDLOAD protocols allow further control over your device, possible debrick solutions too, thats why we are developing it, some have mentioned other possible benifits but to reduce the google crew sending eveyone here looking for off-s solution and this thread going off topic we are avoiding that.Please can you also avoid topics of that nature.

    What About Windows
    You already have QPST and QXDM, us poor linux users dont. I am sure cygwin can help you there, some code changes may be required.

    Enough Already, Gimme
    https://github.com/jcsullins/qdloader


    How Do I use it?
    First you need to get the hex file for your device, if it's a msm8660 then your need mrpg8660.hex, they are found elsewhere, links will be posted later but for now use the search
    then you need to run hex2bin on the hex file to have mrpgXXXX.bin which you rename hex.bin
    then you need your emmc payload, this normally would be xxxx_msimage.mbn which you rename hex2.bin
    then perl qdload.pl while you device is plugged in, there will be some debug output showing first and second stage uploads.

    It's Didnt work,my device is still bricked, Answer my PM dammit!!
    As I mentioned , this is a proof of concept file for study and not really ment to be a oneclick solution. Feed back is most welcome but dont mail the developers with questions for debricking the device, this is a tool to study and develop.

    I REPEAT, stay away from this tool if you are not already familiar with qualcomm boot procedures, emmc system and the like.

    EDIT: We have Found the original author of the script which we based the above on.
    Scotty Walker
    https://github.com/tmzt/g2root-kmod/tree/master/scotty2/pbl
    Credits to The Man for making his work public.
    6
    SPECIAL NOTE ABOUT THE NEXT POST:

    If you attempt to use the msimage.mbn,YOU MUST CREATE IT USING THE SAME VERSION (or newer) FIRMWARE ALREADY ON YOUR PHONE. I'm not 100% sure if this applies to older models, but at least with msm8960 and newer.

    Why?

    Because, in addition to checking the signature of the image, the PBL also checks the firmware version against an efuse value for rollback prevention. If the OEM enables this feature then an older firmware will cause an error and will jump back to the last successfully loaded version of QDL mode. (ie: pbl, sbl1, etc...) This behavior has been the cause of many bricks for HTC Evo 4g LTE (jewel) owners who try to downgrade their firmware via ruu or recovery (sorry captn).

    The firmware images involved are:
    sbl1, sbl2, sbl3, tz and rpm.