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

Search This thread
By:
Advanced…
A

adfree

Senior Member
Jun 14, 2008
11,176
6,394
Smart Watches
Samsung Galaxy Watch 4
Please, I need some help/ basic knowledge.


My background...
Tests with MSM7x30 stuff on GT-S8600 device...
With Firmware from I9001, I8150, I8350...

Found an way to write MBR + DBL + OSBL to S8600 with QPST...
And this MPRG7x30.hex (MD5 65C709DE0E03BD8A7B8A338B41BE27B6)
allows to write "bigger" DBL...

As S8600 uses partition 1 for DBL... I can write Single Image... maybe whole 3,5 GB... for now only tested with 150 MB.

My tests are here in this Thread... on this post Video attached:
http://xdaforums.com/showpost.php?p=52806552&postcount=281

My QuestionS :eek:

For Flasher .HEX QPST helps you to find RAM address. For the other files seems barin mandatory. :D :eek:

Please I need help for RAM addresses from:
Code: 
[B]DBL[/B]
[B]OSBL[/B]
appsboot/eMMCboot

http://xdaforums.com/showpost.php?p=52812603&postcount=283
S8600_QPSTv6.rar
This is my package with DBL + OSBL inside...

For these 2 files I need please RAM addresses. :angel:

Thanx in advance.

@E:V:A
:eek:
Please, maybe you would help me to find RAM addresses for DBL and /or OSBL.

Thanx in advance.

@all
Any help is welcome.

And thank you very much, for all these Threads about Qualcomm stuff.
These helped me alot. :good:

Best Regards
 
A

adfree

Senior Member
Jun 14, 2008
11,176
6,394
Smart Watches
Samsung Galaxy Watch 4
Please I need help for RAM addresses from:
Click to expand...
Click to collapse

Okidoki... it looks like forgotten "old" stuff like Header files... :rolleyes:
Code: 
oemsbl.mbn
oemsbl[B]hd[/B].mbn

Header files seems 40 Bytes...

Now with open eyes...
OSBL.MBN...

Look at first 40 Bytes... Header is inside 1 file...
Address seems for OSBL:

Code: 
OSBL		RAM address
GT-S8600	0x40000000
GT-I8150	0x04000000
GT-I9001	0x40000000
SGH-I847	0x04000000


DBL seems liitle bit "trickier" for me... because more then 40 Bytes at start...

appsboot/eMMCboot... I think also 40 Byte Header...

Need more time to understand real address and virtual address...

Best Regards
 
V

VBlack

Senior Member
Oct 31, 2004
140
220
Hi, we have some strage situation with the phone.
we have MSM8974 based phone which is in HS_USB QDLOAD mode (05c6:9008)
but it is responding strange to any command sent to it. Maybe someone could indentify this protocol, and point me to proper description document name?
On connect to /dev/ttyUSB0 (which is correspond to this device) we have following pack:
01 00 00 00 30 00 00 00 02 00 00 00 01 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Click to expand...
Click to collapse
Next on any command (No-op, version request, magic, ... I also trying AT commands...) it is responding:
04 00 00 00 10 00 00 00 0d 00 00 00 01 00 00 00
Click to expand...
Click to collapse
It is looks like for me that first 4 bytes is some command id, next 4 bytes is total pack length (first pack 48 bytes = 0x30, second pack 16 bytes = 0x10), rest is some command data. But I could not find such protocol description in available Qualcomm documents.
Maybe it is falimiar to someone - point me please document to look for.
 
  • Like
Reactions: E:V:A
V

VBlack

Senior Member
Oct 31, 2004
140
220
Yes, same packet. I found something similar in the code of DBLTool for iPhone, but it is referred to device (05c6:900e)

Sent from my XT1080 using Tapatalk
 
darkspr1te

darkspr1te

Senior Member
Sep 24, 2012
970
614
Over all protocol is HDLC, that 'carries' the qdloader commands, i dont have my reference data to hand plus am very rusty on the whole subject so may be wrong.
I would assume your return packet is no-op or cmd rejected.
Qcom chips can get stuck half between the pure qdloader (Total fail to PBL) and oem boot loader , this could be one of these cases, can you give more info on the dbl code you saw.
 
V

VBlack

Senior Member
Oct 31, 2004
140
220
darkspr1te said:
Over all protocol is HDLC, that 'carries' the qdloader commands, i dont have my reference data to hand plus am very rusty on the whole subject so may be wrong.
I would assume your return packet is no-op or cmd rejected.
Qcom chips can get stuck half between the pure qdloader (Total fail to PBL) and oem boot loader , this could be one of these cases, can you give more info on the dbl code you saw.
Click to expand...
Click to collapse
It does not looks like HDLC for me, it has no CRC of Flags at beginning/end.
DBLTool I meant this: https://github.com/posixninja/DBLTool/blob/master/dbltool/dbl.mm
If it is - first one is DBL Param request, and I need to send some DBL param response. But I don't see documentation on this protocol.
 
  • Like
Reactions: E:V:A
E:V:A

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,226
-∇ϕ
VBlack said:
Hi, we have some strage situation with the phone.
we have MSM8974 based phone which is in HS_USB QDLOAD mode (05c6:9008)
but it is responding strange to any command sent to it. Maybe someone could indentify this protocol, and point me to proper description document name?
On connect to /dev/ttyUSB0 (which is correspond to this device) we have following pack:
Click to expand...
Click to collapse
Well, QC devices are mainly using QMI or Sahara, so probably one of those, unless its waiting for a file, in which case it could be a simple serial transfer prot, like Kermit. What are you using to connect with, and how? Can you also post the output of "lsof | grep ttyUSB" and "getprop | grep ril"?

9008 Qualcomm HS-USB QDLoader 9008 Drivers
900e Qualcomm HS-USB Diagnostics 900E Drivers
 
Last edited:
V

VBlack

Senior Member
Oct 31, 2004
140
220
E:V:A said:
Well, QC devices are mainly using QMI or Sahara, so probably one of those, unless its waiting for a file, in which case it could be a simple serial transfer prot, like Kermit. What are you using to connect with, and how? Can you also post the output of "lsof | grep ttyUSB" and "getprop | grep ril"?

9008 Qualcomm HS-USB QDLoader 9008 Drivers
900e Qualcomm HS-USB Diagnostics 900E Drivers
Click to expand...
Click to collapse
We connect standard usb cable to usb port. From PC side (Ubuntu) we use python do talk with serial port /dev/ttyUSB0 , which correspond to 05c6:9008 device.
As i state before - once we connect - we receive some packet, and then receive next packet on any command sent.
I follow sources of DBLTool https://github.com/posixninja/DBLTool and found that this is almost same protocol.
When I receive
01 00 00 00 30 00 00 00 02 00 00 00 01 00 00 00 00 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Click to expand...
Click to collapse
I respond with (according to DBLTool)
02 00 00 00 30 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Click to expand...
Click to collapse
And the I receive different packet
03 00 00 00 14 00 00 00 0d 00 00 00 00 00 00 00 50 00 00 00
Click to expand...
Click to collapse
Which according to DBLTool is some memory request packet, where 0xd is some file ID, 0x00 - offset, 0x50 - length
Here I stuck, because in original DBLTool handling only two file ID: 0x2 for amss.mbn and 0xb for osbl.mbn. In our case I receive 0xd - and I have no idea which .mbn file it is requested...

About running command on Ubuntu - it produce nothing:
user@pc:~$ lsusb
Bus 001 Device 006: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 002 Device 002: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
user@pc:~$ lsof | grep ttyUSB0
user@pc:~$ lsof | grep ttyUSB
user@pc:~$ getprop | grep ril
user@pc:~$
Click to expand...
Click to collapse

or with sudo:
user@pc~$ sudo lsof | grep ttyUSB0
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
user@pc:~$ sudo lsof | grep ttyUSB
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
user@pc:~$ sudo getprop | grep ril
user@pc:~$
Click to expand...
Click to collapse
 
Last edited:
  • Like
Reactions: mirhl
E:V:A

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,226
-∇ϕ
@VBlack : Sorry mate, I was crazy tired when I answered your post, and forgot to mention that those commands have to be entered on your phone, but that you can't get your phone to boot...

Actually I have no idea how you got into this situation, and I'm also very rusty on the details for fixing it. But I think you should be able to use QPST from THIS post, to try to get out of this mode. Also I think the HTC HOXL people had a binary to take you out of this DLmode, try to search the old HTC One X SOFF threads.
 
Last edited:
E:V:A

E:V:A

Inactive Recognized Developer
Dec 6, 2011
1,447
2,226
-∇ϕ
@VBlack : That is the Sahara protocol. From: 80-N1008-1

Packet processing

The protocol minimizes packet processing by relying on the physical transport
layer to provide reliable transfer of data. No framing, HDLC (High-level Data
Link Control) encoding, or CRC (Cyclic Redundancy Check) is applied to the
packets at the protocol level. Each command packet type has a well-defined
structure which minimally contains a command ID and packet length. Using this
information, the length of each command packet can be validated by comparing the
length of the command packet received to either of two values:

1. The expected packet length for the given command ID
2. The length field contained in the packet itself

Sahara can easily be extended to support command packet validation by adding a
CRC field to the end of each packet. Data packets can also be validated for data
integrity using various authentication methods; however, this is beyond the
scope of the protocol.


Synchronous communication

The protocol assumes that all communication between the host and the target is
completely synchronous. Each command packet sent from the target to the host is
acknowledged with a command or data packet sent from the host back to the
target. Similarly, each command packet sent from the host to the target is
acknowledged with a command or data packet.

Although the link between the host and the target is expected to be reliable, if
an error occurs during the transmission of a command packet from the host to the
target, and as a result the target receives an erroneous packet, then the target
will send the host an error response and exit gracefully.

Timer mechanisms can be implemented on both the host and the target to support
the retransmission of packets in case of transmission failures. However, the
implementation of such mechanisms is outside the scope of the protocol – it
specifies only what happens when unexpected or erroneous packets are received on
the target side.

Extensibility The protocol defines a fixed set of command structures and packet
flows. However, it can easily be extended to support additional command
structures and state transitions (as described later in this document).

The 3 Sahara protocol defines two types of packets:
1. Command packets
2. Data packets
Click to expand...
Click to collapse

Code: 
[SIZE=2] Command Packet:                                                      
+------------------+-----------------+------------+------------------+
| COMMAND LENGTH   |  PACKET LENGTH  |  OPTIONAL  |   OPTIONAL       |
+------------------+-----------------+------------+------------------+
                                                                      
 Data Packet:                                                         
+--------------------------------------------------------------------+
|                   RAW DATA (arbitrary number of bytes)             |
+--------------------------------------------------------------------+
[/SIZE]
(Special thanks to http://asciiflow.com/ )


The Sahara Commands:
Code: 
[SIZE=2]
-----------------------------------------------------------
ID      Command                         Description
-----------------------------------------------------------
0x00    -                               Invalid
0x01    Hello                           Initialize connection and protocol
0x02    Hello Response                  Acknowledge connection/protocol, mode of operation
0x03    Read Data                       Read specified number of bytes from host
0x04    End of Image Transfer           image transfer end / target transfer failure
0x05    Done                            Acknowledgement: image transfer is complete
0x06    Done Response                   Target is exiting protocol
0x07    Reset                           Instruct target to perform a reset
0x08    Reset Response                  Indicate to host that target is about to reset
0x09    Memory Debug                    Indicate to host: target debug mode & ready to transfer memory content
0x0A    Memory Read                     Read number of bytes, starting from a specified address
0x0B    Command Ready                   Indicate to host: target ready to receive client commands
0x0C    Command Switch Mode             [1]
0x0D    Command Execute                 Indicate to host: to execute a given client command
0x0E    Command Execute Response        Indicate to host: target command execution status
0x0F    Command Execute Data            Indicate to target that host is ready to receive (more) data
all     -                               Invalid
-----------------------------------------------------------
0x0-0x8 Protocol Version [B]1.0[/B] and above
0x9-0xA Protocol Version [B]2.0[/B] and above
0xB-0xF Protocol Version [B]2.1[/B] and above
-----------------------------------------------------------
[1] Indicate to target to switch modes:
- Image Transfer Pending mode
- Image Transfer Complete mode
- Memory Debug mode
- Command mode
[/SIZE]
 
  • Like
Reactions: bigsupersquid, SouL Shadow, VBlack and 2 others
darkspr1te

darkspr1te

Senior Member
Sep 24, 2012
970
614
E:V:A said:
@VBlack : That is the Sahara protocol. From: 80-N1008-1



Code: 
[SIZE=2] Command Packet:                                                      
+------------------+-----------------+------------+------------------+
| COMMAND LENGTH   |  PACKET LENGTH  |  OPTIONAL  |   OPTIONAL       |
+------------------+-----------------+------------+------------------+
                                                                      
 Data Packet:                                                         
+--------------------------------------------------------------------+
|                   RAW DATA (arbitrary number of bytes)             |
+--------------------------------------------------------------------+
[/SIZE]
(Special thanks to http://asciiflow.com/ )


The Sahara Commands:
Code: 
[SIZE=2]
-----------------------------------------------------------
ID      Command                         Description
-----------------------------------------------------------
0x00    -                               Invalid
0x01    Hello                           Initialize connection and protocol
0x02    Hello Response                  Acknowledge connection/protocol, mode of operation
0x03    Read Data                       Read specified number of bytes from host
0x04    End of Image Transfer           image transfer end / target transfer failure
0x05    Done                            Acknowledgement: image transfer is complete
0x06    Done Response                   Target is exiting protocol
0x07    Reset                           Instruct target to perform a reset
0x08    Reset Response                  Indicate to host that target is about to reset
0x09    Memory Debug                    Indicate to host: target debug mode & ready to transfer memory content
0x0A    Memory Read                     Read number of bytes, starting from a specified address
0x0B    Command Ready                   Indicate to host: target ready to receive client commands
0x0C    Command Switch Mode             [1]
0x0D    Command Execute                 Indicate to host: to execute a given client command
0x0E    Command Execute Response        Indicate to host: target command execution status
0x0F    Command Execute Data            Indicate to target that host is ready to receive (more) data
all     -                               Invalid
-----------------------------------------------------------
0x0-0x8 Protocol Version [B]1.0[/B] and above
0x9-0xA Protocol Version [B]2.0[/B] and above
0xB-0xF Protocol Version [B]2.1[/B] and above
-----------------------------------------------------------
[1] Indicate to target to switch modes:
- Image Transfer Pending mode
- Image Transfer Complete mode
- Memory Debug mode
- Command mode
[/SIZE]
Click to expand...
Click to collapse
Nice spotting eva.
 
  • Like
Reactions: Surge1223
SouL Shadow

SouL Shadow

Senior Member
Jun 17, 2010
466
327
Stratford, CT
www.soulshadow.net
Nice find and info VBlack and E:V:A

Glad to see people are still working toward using these features.

Personally I've been all but disconnected from computing for most of 2014. I also switched from a HTC Evo Lte to a Nexus 5. My first non-HTC android phone.

Anyway, I won't have much of anything to contribute here but I do encourage others to use this thread, to continue to share and discuss these topics.

XDA mobile app tagline goes here
 
M

mman1982

Senior Member
May 29, 2010
203
41
Hi all,

Is it possible to change sbl and pbl in qdl mode?I am just thinking about to load pbl sbl from an old security phone to a new security phone.(for enable fastboot later)
 
darkspr1te

darkspr1te

Senior Member
Sep 24, 2012
970
614
The pbl is primary boot loader which is hard coded into the CPU. This then loads the boot loader from the emmc. That would be the sbl1.
 
  • Like
Reactions: mman1982
mnomaanw

mnomaanw

Senior Member
Jul 29, 2011
1,036
533
Hello, I have a HTC EVO 3D (MSM8660). It was S-OFF and suddenly turned off while using and now it is not powering on. NO bootloader access nothing except a dim red LED when power button is pressed.
On connecting to windows without battery, it shows "Android 1.0" for about 2 seconds then switches to QHUSB_DLOAD. Then it automatically found and installed some drivers and now it shows Qualcomm HS-USB QDLoader 9008 in COM ports.
QPST can see the port.
On UBUNTU, with lsusb it shows
Bus 002 Device 021: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
The device is bricked for about 6 months now.
I have tried everything I could, and I know I will probably get ignored for asking this but can anyone help me get this thing to work? I live in rural area and JTAG/RIFF are out of reach.
Is it possible to manually flash with no access to bootloader?
 
Y

Yogesh1969

Senior Member
Oct 2, 2012
287
50
Mumbai
darkspr1te said:
UPDATE:
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.
Click to expand...
Click to collapse

Sorry for asking a noob question, but can you give the linux command lines for using qdloader.pl ? QPST doesn't work.
Also how to install drivers in linux/ubuntu ?
 
Last edited:
You must log in or register to reply here.

Similar threads

autoprime
[Qualcomm] Complete List of NV Items
Replies
124
Views
390K
W
wilsonztw
E:V:A
[R&D] Hacking the Huawei E589 (4G LTE Mobile Router)
Replies
70
Views
327K
adrscu
adrscu
E:V:A
  • Locked
[REF][R&D] Building Bootloaders on Qualcomm Devices
Replies
9
Views
30K
E:V:A
E:V:A
AdamOutler
[R&D] Port SDCard Recovery to Other Exynos4412 Devices
Replies
45
Views
45K
P
Phatboyj420
J
  • Locked
International GS3 Qualcomm usb setting
Replies
6
Views
33K
xHausx
xHausx

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 29
    SouL Shadow
    SouL Shadow
    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.
    View
    9
    SouL Shadow
    SouL Shadow
    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...
    View
    8
    darkspr1te
    darkspr1te
    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.
    View
    7
    G
    ghassani
    --
    View
    6
    SouL Shadow
    SouL Shadow
    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.
    View

New posts