Used to flash mobile phones with QC chipset...
DOCS AND DOWNLOADSSUPPORT Logged in as
[email protected] History Help Quick Search
Search within Results Technology 1x (1) 1x GPS (1) 1x/EV-DO (1) 1xEV-DO (1) 3D Graphics (1) Show All VAP Development: Software Build, Debug, Test (1) Drivers: Board Support Package (1) Factory Test Mode (1) Content Type pdf (3) Size Under 1M (3) Type SW Doc (3) Solution (1) Latest Posting Date > 3 Months (4) «« First « Prev Results 1 to 4 of 4Next » Rows Per Page 80-N3887-1_A_Factory_Image_Download_Tool_QFITRevision: 80-N3887-1_A_Factory_Image_Download_Tool_QFITR evision: AType: pdfSize: 494922 PRESENTATION: FACTORY IMAGE DOWNLOAD TOOL - QFIT ALTERNATIVES 80-VP758-1_B_Emergency_Download_FeatureRevisio 80-VP758-1_B_Emergency _Download_FeatureRevision: n: BType: pdfSize: 408555 EMERGENCY DOWNLOAD FEATURE QPST-OEM Development Support QPST-OEM Development Support Solution Number 00004731 Type Solution Documents needed to develop a PST-like tool If you have an ICD agreement you should have access to the necessary documents p osted on the download website. If you do, here are some pointers. You should start with the DMSS ICD (80-V1294-1) since it discusses the basic com mand structure, how to set a mobile offline, how to read NV items, and how to sw itch the mobile mobile to download mode. This will also give you the chance to do a lo t of the basic communication algorithm development in an environment that won't destroy the mobile mobile if you do something wrong. wrong. You should also add lots of error checking and information logging capabilities to their software or they will ne ver find the errors that happen once in a thousand times... Stop the download if you get the Error (0x0D) response. You should also compare the address in the Block Written response (0x08) to what you sent and make sure it is valid and always increasing. You should also make sure to respect the Maximum Block Size and Window Size valu
es returned by the Hello response (0x02). Finally, you should understand that if you send the Partition command (0x19) wit h the Override set to 0x01, this will erase the flash if the new partition table doesn't match the current flash partitioning. In that case you have to download all the images, not just a subset of them. Once in download mode, document 80-39912-1 (DMSS Download Protocol Interface Spe cification and Operational Description) and 80-VF459-1 (Supplement to Streaming Download Protocol) describe the command set. Note: the Supplement to Streaming Download Protocol document, 80-VF459-1 only ap plies to Gobi. You would load the flash programmer into the mobile's RAM with these commands. The last command you issue in this mode is "Go", to start the flash programmer. You haven't altered flash up to this point, so you can reset the mobile and sta rt over if something in your tool goes wrong. After you issue the "Go" command the flash programmer takes over. The flash pro grammer commands are described in document 80-V5348-1. You should make sure you understand how the flash programmer works with the flash device you're using si nce that affects what commands you have to send to initialize the flash programm er. The flash programmer protocol uses sliding window flow control. You should spend extra time analyzing its requirements and testing all boundary conditions . It is recommended you conduct this part of the development with a SURF or FFA that has a JTAG connector so you can restore your device if the programming fai ls. You probably also want to use JTAG to read the flash back and compare it to what you wrote to make sure flash was written correctly. For Sahara Protocol use document use ara Protocol works a lot differently d above. In Sahara, the download is starts of by sending a Hello command in the Sahara Protocol document.
document 80-N1008-1 - Sahara Protocol. Sah than the regular software download describe driven by the device itself, so the device to the PC. See the sequence in figure 4-1
For a flashless device this process starts on power on but also whenever you res et the device with a mode reset command. This means the PST download process has to be configured somehow to take place in the background. The Sahara Protocol also supports memory debug, and it can can download a flash programmer to a devices that use flash. We have not tested this on our side so if you want to implement this in your tool we do not have any troubleshooting st eps for this. List of ICDs needed: 80-39912-1 Rev B for the Downloader Protocol 80-V5348-1 Streaming Download Protocol Specification 80-V1294-1 CDMA Dual-Mode Subscriber Station Serial Data You may also need the other technology ICDs if your devices are based on CDMA, G SM, WCDMA or UMTS technologies. For non-MSM licensees, the ICDs require a license and an upfront fee. Please co ntact your account manager in order to inquire about ICD licensing. Software Download Protocol Implementation Tips The implementation of the software download protocol is difficult and should be attempted by someone that has done something like this before, because of the sl iding window flow control and all the corner cases you have to consider. Assumin g you have gotten far enough to where the AMSS image is being transferred, we as sume you are using a window size of 1, which would account for the slow speed.
Using the 0x07 write command gets a bit complicated. The flash programmer uses a "sliding window" type of flow control, similar to the way TCP uses a sliding wi ndow for flow control. The "window size" returned by the "Hello" command gives y ou the maximum window size.
You start with the window equal to the window size returned by "Hello". Every ti me you send a block to the flash programmer with command 0x07 you decrease the w indow by 1. Every time you get a reply to 0x07 you can increase the window by 1. If the window reaches 0, you must stop sending new data until you get a reply t hat increases the window size > 1. QPST uses one thread to write blocks and anot her one to process the phone's replies.
In practice the sliding window algorithm to write images is very difficult to wr ite and test because of a number of boundary conditions:
Each reply contains the write address. What do you do if, based on monitoring th e reply addresses, you notice a gap in the reply addresses? In other words, you get replies for blocks 100, 200, 400 but not 300. How do you handle the end of the sequence when you run out of data? How do you handle the case where you have fewer blocks then the window size? How do you handle the end of the sequence when you discover a missing reply? How do you handle timeouts where you don't get a reply to a write at all? What i f the last block written times out? ... possibly other conditions... Factory Image software download implementation To implement the factory image, you should use the Open Packet command 0x13 with a Mode of 0x04. To close the downloader use command 0x15. You can use the same stream write command (0x07) to write the blocks as you use for multi-image downl oad.
Not all packets during the download begin with flag 0x7E The packet always has to end with 0x7E. You can look backwards in the data strea m to the byte following the previous 0x7E to find the start of the packet. Starting a packet with 0x7E is optional in the Qualcomm version of HDLC. For mor e information, refer to document 80-39912-1 for the Downloader Protocol
Multi-image loader for UNDP The documents that describe how to implement the multi-image loader for UNDP are UNDP QDL and Firmware Download Overview 80-VJ830-3 C
UNDP-1 Carrier Image Selection Implementation Guide 80-VK867-1 A CEFS Documentation The above documents are correct for CEFS implementations. The 80-V5348-1 documen t is slightly out of date for CEFS. You should use the "Open multi-image packet" to open the downloader for CEFS. The command "type" is 0x09 for the modem CEFS and 0x0B for the apps processor CEFS. The command does not use a payload it flas hes the raw data of the CEFS image. For command type 0x09, it flashes the data to the modem EFS partition, and for command type 0x0B the Apps EFS partition. Command 0x07 in document 80-39912-1 This command has nothing to do with multi-image download. Document 80-39912-1 on ly describes how to load the flash programmer into the mobile's RAM. The only us eful information in the response is the Min version, since that tells you if 32bit write is supported, and the Max write size. Device size and type are meaning less. We don't use the Model or the Version field. The multi-image download does n't start until you start using the flash programmer, which is described in 80V5348-1. RNDIS driver support A WinMobile phone only uses RNDIS when it is running in its normal diagnostic mo de. When you switch it to download mode it runs as a USB composite device, so yo u will have to reconnect to it. Also, the phone uses a completely different set of commands in download mode. The 0x0C command is Status in diagnostic mode, bu t it means "Software Version" in download mode. For development including this driver in addition to everything else we have to add... The mobile runs as a client and the PST tool runs as a server, using the standar d concepts of client and server. The PST tool should bind to INADDR_ANY and listen to TCP port 2500 for new conne ctions. It would then hand off the new socket to code that would handle this mob ile. The data over the socket connection still uses HDLC. QPST uses the standard Winsock APIs. QCN file format For customers developing their own NV back up/restore tool, it's not necessary t o use the QCN format. They should use whatever is easy for them. NV items can b e read and stored as an XML document, comma-separated values, etc. We do have a customer document, 80-VC992-1, but we need to update it to explain the new NV item format. Are the \mjnand\*.* and \hostdl\*.* files related to QCN Backup? These files do not related to the NV items. The NV items are stored in the file system. NV backup retrieves the items, one-by-one using the NV read command (doc ument 80-V1294-1, command 38. If you have an ICD license and agreement you can a ccess this document). So to do the NV backup you have to either know the set of NV items in your build , or have an idea of the range of item numbers, like 0 through 6000. You also ha ve to know which items are indexed, since you will have to read these once for e ach possible index to to completely retrieve that item.
QPST keeps sending "Get Phone Status" command QPST uses the status command to make sure the phone is still working correctly. This command also returns the online/offline status, which is necessary to know before issuing commands that only work in offline (or online) mode. For WinMobile and RNDIS, the code that runs on the phone expects to see occasion al status commands from the PC. If it doesn't see them it will close the current socket and attempt to open a new connection to the PC. How to determine NV items to support Not all NV items are used by a particular target. Many are obsolete or replaced by others. NV Items can be technology or subsystem-specific and they can also be obsolete, so QPST would not unnecessarily read those when a specific model is d etected. Sources as to which NV items are obsolete or technology or subsystem-sp ecific are the AMSS source code itself, the interface control documents and the target itself. For example, DIAG tools such as QXDM can be used to read every si ngle NV item in series and if the target says the NV item is inactive, then it c an be skipped. Is the QCN restored every time and which items are overwritten? When the backup is performed the backup application records the values of NV ite ms NV_VERNO_MAJ_I and NV_VERNO_MIN_I. When the restore operation begins, the application reads these values from the A MSS build that's currently running. If they are unchanged it does not restore th e items from the QCN file. Problems opening the port and is requesting an example Unfortunately we do not have any recommendations for this type of question. You can request help internally within your company and/or find examples on the MSDN website. There are a lot of examples for what you're asking on the Internet. Documentation describing the NOR flash The current version of the document contains the information for NOR flash: In table 3-23, use mode 0x02 (bootable image download) with the "Open" command. Use the "Stream Write" described in section 3.2.7, to write the image. Use the "Close" command described in section 3.2.21 after writing the image. New image types in the flash programmer document 80-V5348-1 The documents needs to updated to include the new image types. You can extend t able 8-32 for the new image types using the information below: value 0x0B 0x0C 0x0D 0x0E 0x0F 0x10 0x11 0x12 0x13 0x14
payload required no no no no no no no no no }
payload max length n/a n/a n/a n/a n/a n/a n/a n/a n/a
open image type Apps EFS2 CEFS WinMobile QDSP6 #1 user partition SB 2.0 DBL SB 2.0 OSBL SB 2.0 FSBL QDSP6 #2 raw filesystem
payload description
through } reserved 0x1F } 0x20
no
n/a
NOR+MoviNAND MBR
"Diag Ping Command" and "Ping Request" This is the "No-op" command, see document 80-39912-1. We send it to see if the m obile is working. The size of NPRG60X5.HEX file does not match QPST writes the NPRG60X5.HEX file which is in Intel hex format. You have to conv ert it to binary if you want to compare the size. Converting the HEX file to binary We work with the hex file directly, we don't use hex2bin. We can provide you wit h an Intel document which describes in detail the Intel hex format. Does QPST use command "Erase Flash Packet" (0x1D)? The command Erase Flash Packet (0x1D) defined in document 80-V5348-1 F (Streamin g Download Protocol Specification) is not used by QPST. The only time the flash is ever erased is if you download a build and the partition table changes. The flash programmer has to erase the flash before it can re-partition it. However w e don't use the erase command, just the partition command with override enabled. How to switch the phone to download mode and verify the status We use CMD_CODE 68 to switch the phone to offline mode and then and then into do wnload mode using CMD_CODE 58. To test what mode the phone is in after sending t he command to switch to download, we use the "NOP" command (0x06), expecting an ACK (0x02) response. If that does not work, we test for streaming download mode using the flash programmer "Hello" command (0x01), expecting a "Hello" (0x02) r esponse. Note that the response code is 0x02 in both cases but the length is different an d the Hello response contains a text string. How The ere see use
to set the FCS to a certain frame check sequence is the is no easy way to calculate how it works, the same code in QPST.
value. same CRC that is used for any other command. Th the FCS, it uses a CRC polynomial. If you must used in the serial port code in AMSS is what we
If you're sending a command you calculate the CRC over the command bytes, and ap pend the CRC to the end of the command. Then you HDLC-encode the command+CRC and append 0x7E to the end. Programming devices with a blank flash For devices with a blank flash (i.e. 8960) you donât need the supplement document, j ust the 80-39912-1 and 80-V5348-1 documents. From the point of view of programmi ng flash, the commands for blank/non-blank flash are the same. You just need to load the emergency flash programmer hex file (using the protocol in 80-39912-1) for the blank flash case. Keep in mind that for blank flash download mode is implemented in the PBL (in th
e chipâs ROM), and for non-blank download mode is implemented in the boot code. If y ou want to tell the difference, in the Memory Dump send the "Get Regions" comman d. It will NAK in PBL but should return data in the boot code. Documents needed to develop a PST-like toolIf you have an ICD agreement you shou ld have access to the necessary documents posted on the download website. If yo u do, here are some pointers. You should start with the DMSS ICD (80-V1294-1) si nce it discusses the basic command structure, how to set a m... 80-V5348-1_J_Streaming_DLoad_ProtocolRevision: JType: pdfSize: 541015 STREAMING DOWNLOAD PROTOCOL SPECIFICATION «« First « Prev Results 1 to 4 of 4Next » © 2010 - 2012 QUALCOMM Inc. All rights reserved. Export of this technology may be controlled by the United States government. Div ersion contrary to US law is prohibited.
