QPST-Emergency Download Support

What is this feature?
The QPST Software Download app shows an option called "Use Emerg. Host D/L". This option was introduced in QPST 2.7.335 and higher. When enabled, it makes QPST look for a flash programmer named eNPRGxxxx.hex. If that file isn't present in the AMSS build then the download will fail. The only implementation in QPST for the Emergency Boot Loader is to prefix an "e" to the flash programmer name if the user selects "Use Emerg. Host D/L".  See document 80-VP758-1 (Emergency Download Feature).

Once the flash has been altered, you may have damaged any recovery code that is part of the AMSS image. To get around this, the emergency downloader is actually part of the MSM itself, resident in a ROM along with the primary boot loader (PBL). It can't be overwritten. This should even allow you to enter download mode if you have a blank flash. The secure boot architecture has validation code that checks the digital signature of the next block of code. If it doesn't match (either because of a corrupted, hacked, or blank image) it would activate the emergency downloader.At this stage, using QPST's Emergency Download option couldbe selected and the ehostdl binary could be downloaded to the IMEM. This wouldfacilitate the download of entire AMSS image through the ehostdl downloadmechanism. Ifthere is any error seen in accessing flash or any error seen in PBL, then thephone would go to download mode in PBL. Hence the entire boot, AMSS images canbe re-flashed or downloaded using this emergency download feature.

Some targets, such as the 8650 or M9k based ones, do not support the "Emergency Download" through USB, even though the USB function is supported. The selection of USB or UART for Emergency Download has already been made in the Boot ROM of the chip, and cannot be changed without a new chip revision. All chips released in 2009 and beyond will support USB.



Which targets support this feature?
Please refer to 80-VJ116-1 (Secure Boot 2.0 Architecture) to see which targets support emergency download ePRGxxx.hex using which serial interface (UART2, UART1, HS-USB) for those targets which uses Secure Boot 2.0. 

• QSC6195 using HS-USB
• QSC6295 using HS-USB
• QSC6240 using UART2 at 115 kbps.
• QSC6270 using UART2 at 115 kbps.
• MSM6246 using UART2. (Tested on SURF only)
• MSM6290 using UART2. (Tested on SURF only)
• MSM7x30 using HS-USB.
• MDM8200 (No eNPRFxxx.hex as of 1/16/2009)
• MDM8900 (No eNPRFxxx.hex as of 1/16/2009)
• FRB has recently (1/2009) approved supporting it on QSD8650 using UART1.
• FRB has recently (1/2009) approved supporting it on QSD8250 using UART1.
• All others need JTAG recovery.

Secure Boot 2.0 Architecture is supported on the following targets:

• QSC6195™
• QSC6240™
• QSC6246™
• QSC6270™
• QSC6295™
• QSC1100™
• MSM7x30
• MDM8200™/MDM8900™
• QSD8250™/QSD8650™

• All future chipsets will have it as default boot mechanism

Emergency download mode in PBL is supported on the following targets:

• MSM6246™ (UART2)
• MSM6290™ (UART2)
• QSC6195™ (HS-USB)
• QSC6295™ (HS-USB)
• QSC6240™ (UART2)
• QSC6270™ (UART2)
• QSC7x30 (HS-USB)
• MDM8200™/MDM8900™ (No eNPRGxxx.hex at this point 01/16/09)
• QSD8650™ (UART1)

What about targets that support Secure Boot 1.0?
MSM6290 uses Secure boot 1.0 and is not covered by 80-VJ116-1 (Secure Boot 2.0 Architecture). We do not have any other document listing all the targets supporting emergency download. However, the MSM6290 also supports ePRGxxx.hex.


How does a customer implement this feature in their PST like tool?
The only implementation in QPST for the Emergency Boot Loader is to prefix an "e" to the flash programmer name if the user selects "Use Emerg. Host D/L".

The emergency downloader has to be created by the AMSS build.


Automating the emergency download feature
Starting with QPST version 2.7.362 there will be an example of how to automate this feature.  The example Perl script is "swdl_DownloadBySettings.pl".

We have support for blank flash programming of partition 0 using rawprogram0.xml and patch0.xml.  We don't have support for meta builds or other partitions at this time. The download support is independent of the device (MSM8960), but is dependent on the flash programmer that is built during the AMSS build process for a device.


The emergency download a second time on the same device.
You cannot use this feature twice consecutevly on one device.  This feature is for use with blank flash when the device is running in the PBL.  Once the eNPRGxxx.hex file was loaded once, you need to use the normal download mode (uncheck 'use emerg...' box).


Secure Boot 3.0 support
Secure Boot 3.0 is only supported by eMMC flash devices and not used on NAND flash. For eMMC the download is controlled by the XML document produced by the AMSS build. In this case the images used by SB 3.0 are just loaded into partitions on the eMMC device like other AMSS images.

You need to use emmcswdownload.exe to download to devices that use eMMC flash devices. However the current version of QPST does not completely support the 8660 eMMC device.

There is no automation support for Secure Boot 3.0 via the QPST automation interface.  The "swdl_DownloadBySettings.pl" script does not support Secure Boot 3.0 therefore it will not work with devices that have this type of boot.


Document error on element type "root" and name/value"<image> tag no longer supported" error
This type of programming, using partition.xml, is no longer supported. Start with version 2.7.370 and going forward, QPST only supports rawprogram0.xml format. You will have to modify your build process to create the new XML file.

If you still cannot load the rawprogram0.xml file, verify there are no lines that have sparse="true" value.  Sparse file format is not supported by QPST. You either have to convert the file to a non-sparse format or skip these items entirely.

Please note that in our builds we do not arbitrarily create this sparse tag. The sparse tag is needed because Android targets use "sparse" files that are meant to be loaded via fastboot.  In a nutshell the sparse tag saves you from accidentally loading a "sparse" file that fastboot needs to uncompress first.