Related
This is a research & development thread for building your own bootloaders on a
number of modern Qualcomm based devices, utilizing extracted partitions and
corresponding partition table information. We'll focus in particular on those
devices using the Snapdragon SoC/PoP chipset.
Code:
Thread difficulty: [B][COLOR=Red]Hard[/COLOR][/B]
Thread type: Development
Thread completeness: Fair
Building your own Bootloaders on Qualcomm Devices
Table of Content:
Introduction
Qualcomm/Intel HEX files
<WIP> QFIT (Qualcomm Factory Image Tools)
<WIP> The MBR Image
<TBD> BoToX (Bootloader Tool Box)
<WIP> Building for Windows Phone 8
<TBA> Compiling Bootloaders
<WIP> References
INTRODUCTION
All modern Qualcomm mobile chipsets contain some functionality for sideloading
binary code from an external source in case the normal boot procedure fails or
is interrupted by some other HW signal, like JTAG or other JIG debug
connection. In addition this side loading functionality is crucial for the
programming and formatting of additional memory devices like eMMC and SD cards
that are external to the processor and it's accompanying PoP memory. It is
also used by OEMs to revive soft-bricked devices and update the many
bootloaders used in the Qualcomm bootloader chain. However, all these features
and their various functionality are closely guarded secrets usually kept from
the public by very strict NDA for their company employees. Thus it has been
very difficult for the developer community to try to understand, use and
benefit from these most useful functions. Instead the dark side of mobile
phone community have made continuous profits in reversing the manufacturer
schemes by providing their own hacks and programs to offer mobile owners
various solutions for a charge, that is often out of proportion for what is
actually done. This is especially true for services requiring debricking by
various JIGs (such as the proprietary Anyway Jig and various JTAG solutions.)
All these solution rely on the possession of some inside information about the
device in question.
This thread is an attempt to alleviate this situation and allow anyone who
wishes, to freely flash and take charge of their own hardware, in the true
spirit of the XDA community. Here I will present information about how
Qualcomm put together their own bootloaders and how you could do the same, if
you only had the source code or talent to write your own or modify already
existing such. Although, there is one big hitch. Most new chipsets are using
a very secure authentication scheme (Secure Boot 3.0) to prevent
non-developers from flashing and using arbitrary boot code.
The information herein have been collected from older available Qualcomm tools
such as QPST and QXDM, and from pieces of their documents found around the
internet. Another important and challenging source have been the many Chinese
websites where people have managed to get some of this working and actually
bothered writing/blogging about it. Thank you China!
I will not go into details about the various bootloaders as they are already
covered elsewhere, for example, in this thread. I have also chosen to focus
primarily on the Qualcomm Snapdragon processor/modem SoC series, as they are
the most popular chips used in most mid- to upper-level smartphones today.
These devices typically include the MSM8x60 series consisting of the widely
popular MSM8660 and MSM8960 SoCs, currently found around the world. Another
highly relevant chipset is that of MSM8260A which is found in many Windows
Phone's, in particular in WP8.
...REFERENCES
<WIP>==================================================
If you find any errors or have any relevant additional information
that can be important for the correctness and content of this thread.
Please let me know by either posting here or sending me a PM.
Also, please do not ask any questions that is not of direct relevance
or help in the discussions in this thread . They will not be answered
and removed.
==================================================
Enjoy!
Qualcomm/Intel HEX files
This is a text-based (ASCII) file format originally introduced by Intel to
distribute PROM code, that include error checking for redundancy. Today
Qualcomm use this file format to distribute their modem/processor boot code
used in downloading bootloaders in the OEM build-processes or for emergency
download modes etc. There are several dozens of variations on the HEX format,
so we will not go into the details of other formats or uses, but only for that
used in the Qualcomm bootchain.
To convert the Qualcomm provided Intel-HEX files into binaries, you can either
use the simple pre-compiled windows and linux binary hex2bin (src), or you can
compile the much more flexible and complete EPROM file-converter utilities of
srecord, which can handle many more HEX formats including hex-diffing and
hex-merging etc. One of the Qualcomm image build "toolkit" programs, the
"emmcswdownload.exe" already contain a hex-to-bin converter, but it is usually
appending more than one binary file as described in the required XML partition
file. For details about this see the next section about QFIT.
Next we jump right into describing the Qualcomm (aka Intel-32) HEX-file
format. The content of a typical HEX-file, let's say the MPRG8660.HEX are as
follows:
Code:
:020000042A00D0
:10000000D1DC4B843410D773FFFFFFFFFFFFFFFFEE
:10001000FFFFFFFF500000005000002A348802005C
:10002000348802008488022A000000008488022AA2
...
:108850001CAF012A000000005CC4012A8CC4012A5C
:1088600000000000FCBF012AFCC0012A04C0012A4C
:10887000BCC2012AC4C2012ACCC2012A00000000E5
:0488800000000000F4
:040000052A000000CD
:00000001FF
Let's break this down. First things to know are that:
Each line is a record.
Hexadecimal values are always in uppercase.
The sum of all the bytes in each record should be 00 (modulo 256).
So for example, a typical record can be broken down as:
Code:
[SIZE=2]
:[B][COLOR=DarkRed]10[/COLOR]0020[COLOR=Blue]00[/COLOR][/B][COLOR=Green]348802008488022A000000008488022A[/COLOR][COLOR=Red][B]A2[/B][/COLOR]
: 10 0020 00 348802008488022A000000008488022A A2[/SIZE] [SIZE=2]
| | | | ----------------+--------------- |
| | | | | +-- Checksum (1 byte)
| | | | +-------------------- Data (0-255 bytes, here 16)
| | | +--------------------------------------- Record type (1 byte)
| | +------------------------------------------- Address (2 bytes)
| +----------------------------------------------- Data Byte Count (1 byte, here 16)
+-------------------------------------------------- Start of record delimiter[/SIZE]
There are 6 record types defined (for Intel-32 HEX):
'00' = Data Record
'01' = End Of File (EOF) Record
'02' = Extended Segment Address Record
'03' = Start Segment Address Record
'04' = Extended Linear Address Record
'05' = Start Linear Address Record
But only 4 are used for Qualcomm processor/modem HEX-files:
00: Data Record
01: End Of File (EOF) Record
04: Extended Linear Address Record
05: Start Linear Address Record
Where "04" (Extended Linear Address Record) allow for 32 bit addressing (up to
4GiB). The address field is 0000, the byte count is 02. The two data bytes
(two hex digit pairs in big-endian order) represent the upper 16 bits of the
32 bit address for all subsequent 00 type records until the next 04 type
record comes. If there is not a 04 type record, the upper 16 bits default to
0000. To get the absolute address for subsequent 00 type records, the address
specified by the data field of the most recent 04 record is added to the 00
record addresses.
While the "05" (Start Linear Address Record), contain the address that is
loaded directly into the program counter (PC / R15) of the ARM processor. The
address field is 0000, the byte count is 04. The 4 data bytes represent the
32-bit value loaded into the register.
NOTE: The data field endianness may be byte-swapped.
Qualcomm use the following convention for naming their HEX boot-loader
"programmer" files. This is especially true when used in conjunction with
their emmcswdownload.exe. (See this section.)
yPRGxxxx.HEX
where "y" is one of the following:
Code:
[SIZE=2]N = NAND
A = NOR
M = eMMC
arm = Is used to bypass automatic selection by QPST by renaming a custom version to "armprg.hex"
flash = ??
[/SIZE]
<< Here Be More Dragons >>
<< Here Be Snap Dragons 2 >>
<< Here Be Snap Dragons 3 >>
<< Here Be Snap Dragons 4 >>
<< Here Be Snap Dragons 5 >>
<< Here Be Snap Dragons 6 >>
one more awesome guide from E:V:A
It would be cool if someone made a synalysis grammar for the hex codes E:V:A documented above.
For those of us hacking on our Mac OS X machines.
I'm closing this thread until I can actually fulfill my promises.
Sorry! Stay tuned.
Introduction:
This post is a guide to show how to perform the NV edit required to unlock US GSM carriers(AT&T and T-Mobile etc.) on the VZW XT907/926 RAZR M/HD stock modem using a Motorola serviceware tool called RadioComm.
This is simply a different method to perform the same hack that was discovered by Arnold Snarb in the main thread about ATT/T-Mobile here.
http://forum.xda-developers.com/showpost.php?p=37123644&postcount=158
Despite the fact that he thanked me for leading the way in that post, he did some really brilliant analysis of the logs in QXDM to isolate this NV Item and saw something in the them that I had missed as well as guessing correctly about it's significance, and deserves all of the credit for this hack.
Everyone should please go and thank him in that post for the outstanding work.
He used a tool called DFS to access and edit NV Item 8322 and change the value of the first byte from 01 to 00 which disables the checking of the MCC/MNC against a list of banned networks and flags MCC 310 as Invalid Country Code.
That method requires booting into BP Tools mode from the boot menu and loading the Qualcomm diagnostic device interfaces.
The problem is that there are no signed 64bit drivers available and you must force load the drivers on Win7/8 64 bit for the diagnostic port in order to see the device properly and have NV read/write access.
This has been a stumbling block for many users and makes the NV editing unnecessarily difficult.
This method uses Factory boot mode and allows RadioComm to have full diagnostic mode access via the Motorola USB Networking driver that loads normally with the standard USB driver set. I will demonstrate 2 different ways to perform the edit, one manual and one using a preconfigured SEEM table file that writes the value in a single operation.
Neither of these methods is as easy as an update.zip install from custom recovery would be, but we don't have a binary that supports the motorola.update_nv function that we used for prior MDM6600 based devices available to us for the MSM8960 devices.
Given that some form of diagnostic mode software and a PC is required, I feel that RadioComm is probably an easier option for most users as it avoids the driver problems and has a clearer and simpler interface for NV read/write access than DFS.
Once you have the latest Motorola drivers installed and RadioComm loaded, this guide should make it very easy and safe to perform what is generally a complicated and potentially dangerous task of editing the radio NVM(Non Volatile Memory).
RadioComm itself is a terrifyingly complex piece of software with a GUI that can bring even the most seasoned and experienced phone hacker to their knees wondering what all the various windows, modules and buttons do.
It is the premier Motorola serviceware application and is designed by and intended for use by top level radio engineers and technicians.
It is an extremely powerful application that can access all models and chipsets of Motorola devices and perform a vast array of diagnostic testing and configuration operations and can be fully automated via multiple scripting languages.
It's just plain scary and confusing and very dangerous if not taken seriously.
Warning and disclaimer:
DO NOT PLAY AROUND WITH ANY FEATURES OR RANDOMLY HIT ANY BUTTONS IN RADIOCOMM!!!
YOU CAN RENDER YOUR PHONE DYSFUNCTIONAL OR UNBOOTABLE IN SECONDS!!!
This cannot be emphasized strongly enough!
Follow the instructions exactly as they are written and shown in the screenshots and you will find it very simple to use have no trouble doing the edit with either method.
You, the user, are the only person responsible for your actions and performing this hack will absolutely void your warranty the same way rooting or any other modifications to your device's software does!
That said, this hack will be undetectable and have no outward visible signs of having been performed other than the fact that any GSM SIM should work afterward.
Root is NOT required and this can be safely done and undone at will without making any other changes on the device and all normal services function properly on VZW's network with the edit in place. It appears to only affect the US GSM network block and nothing else.
Prerequisites:
You need to have a recent set of Motorola USB drivers v. 5.9.0 or greater installed on your PC with a full USB 2.0 compatible port.
You need a standard Motorola micro USB cable.
RadioComm 11.12.xx I have included a link to 11.12.2 below.
https://dl.dropbox.com/u/7632904/RadioComm_v11.12.2_Install.zip
This has been tested on Win7 64bit and WinXP SP3 32bit with .NET Framework 4.0 installed.
Method:
This guide assumes you already have RadioComm and the drivers properly installed and have rebooted both PC and the phone afterward.
The first instructions and screenshots describe the initial setup and manual method using the FTM Common 1 tab and the NV Access window in RadioComm.
When you first open RadioComm you will get a popup stating that the version is more than 2 months old. Just close it and continue.
Now go to the top left corner and hit the Main button and select the MA: Common/MDM6x00 as shown in the first screenshot.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Next, go to Settings/USB and select PST USB Driver as shown in the second screenshot.
Test Command Format should default to P2K05 lower in Setings menu.
Leave all other options default.
Now we are ready to connect the phone and perform the edit.
Make sure you have Connect as Media Device in USB settings and USB Debugging enabled in Developer Options.
Power off the phone and then hold both Vol Up and Down + Power to enter the boot menu.
Use the Vol Down key to scroll down in the menu to Factory and then Vol Up key to select and the phone will boot.
Connect the USB cable and RadioComm will enumerate the phone and the radio button in the top right will change colors.
It will cycle sever times red to yellow and eventually go green when the device is fully enumerated and shows as XT907 in the status bar
at the bottom of the screen. You can read the Software Version and MEID/ESN/pESN buttons to make sure everything is working properly.
Each successful read the GUI will flash green and the Command buffer will turn green and any selected button will be green.
Any unsuccessful attempt will turn red.
If not, then restart everything and check over all settings again before proceeding.
Now go to the tabs bar across the top middle of the GUI and select FTM Common 1 tab and go to the NV access window in the center right of that tab and select the top menu Item "FFFF Manual Entry" as shown in the third screenshot.
Now hit the Read button and you will get 2 popup windows.
In the first window you will enter the Decimal NV Item ID 8322 and in the second you will enter the byte length to be read 1 as shown in the fourth screenshot.
When you hit ok it will read the NV Item and flash green and display the data in the hex output buffer below and you will see 01 for the value as shown in the fifth screen shot.
Now highlight the 01 and change it to 00 and hit the write button and this time it will only popup once asking for the Decimal NV Item ID 8322. When you hit OK the item will be written and the GUI will again flash green for a successful write as shown in the sixth screenshot.
You are now finished and can either use the restart button at top right of RadioComm to reboot or manually restart the phone.
The last screen shot is edited to show the steps to use the NV/SEEM feature with a SEEM table file I have provided below to do all of the steps as a single operation. Some users may find this easier than manually editing in the NV Access window but it's really almost the same number of steps.
Go to the top left and hit Features and select NV/SEEM and another window will open and the radio button will cycle again a couple time as it re enumerates the device again it will go green finally. Follow the instructions in the seventh screenshot and be sure to use the Restart button in the main window after you close NV/SEEM because its suspends the phone and it will be black screen and unresponsive and require holding Vol keys and Power for 10 secs to reset it otherwise.
Congrats! All done now and the rest is just putting in a SIM and selecting GSM/UMTS in Network Settings and everything should just work!
Below is the link for the .NVM SEEM table file.
https://dl.dropbox.com/u/7632904/TBH_RAZR_M_GSM_Unlock.NVM
Please use this thread to discuss issues relating to this method and RadioComm and keep general discussion of the phone on US carriers in the other thread, thank you!
<Reserved>
Thanks man.. gonna try this when I get home tonight. I was actually just thinking about switching vendors from VZW to someone else and didn't really want to buy a new phone.
Maybe now I don't have to. Proof is in the pudding though, maybe I'll by a cheap month of Straight Talk to see if it works?
Yehudah said:
Thanks man.. gonna try this when I get home tonight. I was actually just thinking about switching vendors from VZW to someone else and didn't really want to buy a new phone.
Maybe now I don't have to. Proof is in the pudding though, maybe I'll by a cheap month of Straight Talk to see if it works?
Click to expand...
Click to collapse
Running RAZR M in US on straight talk now. Works wonderful!!!
Thanks a lot! im a total noob when it comes to most of this, but it worked perfect for me!!
Hmm, MDM6x00? Won't that work on the OG RAZR XT912 / Droid 4 as well?
Skrilax_CZ said:
Hmm, MDM6x00? Won't that work on the OG RAZR XT912 / Droid 4 as well?
Click to expand...
Click to collapse
The MA used in RadioComm is the same chip set base as the RAZR/D4 because it's the closest to the MSM8960 available in this version, which is more than 18 months old now.
What we really need is an updated version of RadioComm with full support for the newer chip sets.
This specific NV Item 8322 does not exist on the MDM6600 chip set devices and I have not been able to find a similar boolean switch item for those phones, unfortunately.
I have been logging with QXDM extensively searching for a way to disable the MCC/MNC block on MDM6600 without success so far.
I have dumps of all of the readable NV items from 0000-12000 from many devices running various builds and even a dump from Chinese engineering build on P3Droid's Dev model where everything is working as it should with open GSM on US carriers.
I would love some help from someone with a better understanding of the radio and diagnostic mode access than myself.
Very few people know how to use the software to even start analyzing the problem.
Remember to install the latest Motorola drivers and *especially* highlight the entire 01 and type 00. I was backspacing only the 1 and it did not "stick" when writing. So HIGHLIGHT, don't backspace. Works perfectly.
is it possible to write the NV item to the Droid 4 then edit ? ?
cellzealot said:
The MA used in RadioComm is the same chip set base as the RAZR/D4 because it's the closest to the MSM8960 available in this version, which is more than 18 months old now.
What we really need is an updated version of RadioComm with full support for the newer chip sets.
This specific NV Item 8322 does not exist on the MDM6600 chip set devices and I have not been able to find a similar boolean switch item for those phones, unfortunately.
I have been logging with QXDM extensively searching for a way to disable the MCC/MNC block on MDM6600 without success so far.
I have dumps of all of the readable NV items from 0000-12000 from many devices running various builds and even a dump from Chinese engineering build on P3Droid's Dev model where everything is working as it should with open GSM on US carriers.
I would love some help from someone with a better understanding of the radio and diagnostic mode access than myself.
Very few people know how to use the software to even start analyzing the problem.
Click to expand...
Click to collapse
Can I use a similar way to unlock XT902(Japanese Razr M)? I can't find 8322 in XT902.......
Followed instructions and worked perfectly. The key for me was the latest Motorola drivers AND the Motorola USB cable that came with the phone. I tried other cables that both charged and synced but the only that worked for this was the Moto cable. Using Win XP SP3 ( 12 year old OS on brand new work laptop. WTF!)
i was wondering if this works on other networks such as boost mobile,net10, criket etc...? i honestly dont have enough money to buy a new phone and whatnot. the whole reason why i did this is because i lost my job and now i cant pay my phone bill and it keeps getting higher and higher.
AKG0214 said:
i was wondering if this works on other networks such as boost mobile,net10, criket etc...? i honestly dont have enough money to buy a new phone and whatnot. the whole reason why i did this is because i lost my job and now i cant pay my phone bill and it keeps getting higher and higher.
Click to expand...
Click to collapse
Boost - No
Cricket - No
They're both cdma. This is to allow the GSM side (SIM CARD based) of the phone to work on other carriers. With that said, your best options are
Net10, Straight Talk, ATT, T-Mobile, Simple Mobile, H20, Orange, and there's a plethora of others out there. Post paid and pre-paid.
@DSDD
I beleive your XT902 is GSM by default. So if what your asking is will this bypass the network lock, no, the device needs to be unlocked by code. Then you can use it outside of the current carrier/country.
after boot, it is set back to 01 again @ address 8322
my phone version is Bsmq_vzw-user 4.1.1 9.8.1Q_27-2 4 release-keysSM_BP_1139.000.32.62P
after write to 8322 with zeros, I read it again the confirm it is written, but after rebooting the phone, the value is back to 01 again.
I guess the verizon driver may override this value during rebooting?
any help?
should I root the phone?
==
thanks
cellzealot said:
Introduction:
This post is a guide to show how to perform the NV edit required to unlock US GSM carriers(AT&T and T-Mobile etc.) on the VZW XT907/926 RAZR M/HD stock modem using a Motorola serviceware tool called RadioComm.
This is simply a different method to perform the same hack that was discovered by Arnold Snarb in the main thread about ATT/T-Mobile here.
http://forum.xda-developers.com/showpost.php?p=37123644&postcount=158
Despite the fact that he thanked me for leading the way in that post, he did some really brilliant analysis of the logs in QXDM to isolate this NV Item and saw something in the them that I had missed as well as guessing correctly about it's significance, and deserves all of the credit for this hack.
Everyone should please go and thank him in that post for the outstanding work.
He used a tool called DFS to access and edit NV Item 8322 and change the value of the first byte from 01 to 00 which disables the checking of the MCC/MNC against a list of banned networks and flags MCC 310 as Invalid Country Code.
That method requires booting into BP Tools mode from the boot menu and loading the Qualcomm diagnostic device interfaces.
The problem is that there are no signed 64bit drivers available and you must force load the drivers on Win7/8 64 bit for the diagnostic port in order to see the device properly and have NV read/write access.
This has been a stumbling block for many users and makes the NV editing unnecessarily difficult.
This method uses Factory boot mode and allows RadioComm to have full diagnostic mode access via the Motorola USB Networking driver that loads normally with the standard USB driver set. I will demonstrate 2 different ways to perform the edit, one manual and one using a preconfigured SEEM table file that writes the value in a single operation.
Neither of these methods is as easy as an update.zip install from custom recovery would be, but we don't have a binary that supports the motorola.update_nv function that we used for prior MDM6600 based devices available to us for the MSM8960 devices.
Given that some form of diagnostic mode software and a PC is required, I feel that RadioComm is probably an easier option for most users as it avoids the driver problems and has a clearer and simpler interface for NV read/write access than DFS.
Once you have the latest Motorola drivers installed and RadioComm loaded, this guide should make it very easy and safe to perform what is generally a complicated and potentially dangerous task of editing the radio NVM(Non Volatile Memory).
RadioComm itself is a terrifyingly complex piece of software with a GUI that can bring even the most seasoned and experienced phone hacker to their knees wondering what all the various windows, modules and buttons do.
It is the premier Motorola serviceware application and is designed by and intended for use by top level radio engineers and technicians.
It is an extremely powerful application that can access all models and chipsets of Motorola devices and perform a vast array of diagnostic testing and configuration operations and can be fully automated via multiple scripting languages.
It's just plain scary and confusing and very dangerous if not taken seriously.
Warning and disclaimer:
DO NOT PLAY AROUND WITH ANY FEATURES OR RANDOMLY HIT ANY BUTTONS IN RADIOCOMM!!!
YOU CAN RENDER YOUR PHONE DYSFUNCTIONAL OR UNBOOTABLE IN SECONDS!!!
This cannot be emphasized strongly enough!
Follow the instructions exactly as they are written and shown in the screenshots and you will find it very simple to use have no trouble doing the edit with either method.
You, the user, are the only person responsible for your actions and performing this hack will absolutely void your warranty the same way rooting or any other modifications to your device's software does!
That said, this hack will be undetectable and have no outward visible signs of having been performed other than the fact that any GSM SIM should work afterward.
Root is NOT required and this can be safely done and undone at will without making any other changes on the device and all normal services function properly on VZW's network with the edit in place. It appears to only affect the US GSM network block and nothing else.
Prerequisites:
You need to have a recent set of Motorola USB drivers v. 5.9.0 or greater installed on your PC with a full USB 2.0 compatible port.
You need a standard Motorola micro USB cable.
RadioComm 11.12.xx I have included a link to 11.12.2 below.
https://dl.dropbox.com/u/7632904/RadioComm_v11.12.2_Install.zip
This has been tested on Win7 64bit and WinXP SP3 32bit with .NET Framework 4.0 installed.
Method:
This guide assumes you already have RadioComm and the drivers properly installed and have rebooted both PC and the phone afterward.
The first instructions and screenshots describe the initial setup and manual method using the FTM Common 1 tab and the NV Access window in RadioComm.
When you first open RadioComm you will get a popup stating that the version is more than 2 months old. Just close it and continue.
Now go to the top left corner and hit the Main button and select the MA: Common/MDM6x00 as shown in the first screenshot.
Next, go to Settings/USB and select PST USB Driver as shown in the second screenshot.
Test Command Format should default to P2K05 lower in Setings menu.
Leave all other options default.
Now we are ready to connect the phone and perform the edit.
Make sure you have Connect as Media Device in USB settings and USB Debugging enabled in Developer Options.
Power off the phone and then hold both Vol Up and Down + Power to enter the boot menu.
Use the Vol Down key to scroll down in the menu to Factory and then Vol Up key to select and the phone will boot.
Connect the USB cable and RadioComm will enumerate the phone and the radio button in the top right will change colors.
It will cycle sever times red to yellow and eventually go green when the device is fully enumerated and shows as XT907 in the status bar
at the bottom of the screen. You can read the Software Version and MEID/ESN/pESN buttons to make sure everything is working properly.
Each successful read the GUI will flash green and the Command buffer will turn green and any selected button will be green.
Any unsuccessful attempt will turn red.
If not, then restart everything and check over all settings again before proceeding.
Now go to the tabs bar across the top middle of the GUI and select FTM Common 1 tab and go to the NV access window in the center right of that tab and select the top menu Item "FFFF Manual Entry" as shown in the third screenshot.
Now hit the Read button and you will get 2 popup windows.
In the first window you will enter the Decimal NV Item ID 8322 and in the second you will enter the byte length to be read 1 as shown in the fourth screenshot.
When you hit ok it will read the NV Item and flash green and display the data in the hex output buffer below and you will see 01 for the value as shown in the fifth screen shot.
Now highlight the 01 and change it to 00 and hit the write button and this time it will only popup once asking for the Decimal NV Item ID 8322. When you hit OK the item will be written and the GUI will again flash green for a successful write as shown in the sixth screenshot.
You are now finished and can either use the restart button at top right of RadioComm to reboot or manually restart the phone.
The last screen shot is edited to show the steps to use the NV/SEEM feature with a SEEM table file I have provided below to do all of the steps as a single operation. Some users may find this easier than manually editing in the NV Access window but it's really almost the same number of steps.
Go to the top left and hit Features and select NV/SEEM and another window will open and the radio button will cycle again a couple time as it re enumerates the device again it will go green finally. Follow the instructions in the seventh screenshot and be sure to use the Restart button in the main window after you close NV/SEEM because its suspends the phone and it will be black screen and unresponsive and require holding Vol keys and Power for 10 secs to reset it otherwise.
Congrats! All done now and the rest is just putting in a SIM and selecting GSM/UMTS in Network Settings and everything should just work!
Below is the link for the .NVM SEEM table file.
https://dl.dropbox.com/u/7632904/TBH_RAZR_M_GSM_Unlock.NVM
Please use this thread to discuss issues relating to this method and RadioComm and keep general discussion of the phone on US carriers in the other thread, thank you!
Click to expand...
Click to collapse
---------- Post added at 11:14 PM ---------- Previous post was at 10:48 PM ----------
tried again for couple of times, this time it actually works.
maybe last time I reboot the phone too early?
sipida said:
my phone version is Bsmq_vzw-user 4.1.1 9.8.1Q_27-2 4 release-keysSM_BP_1139.000.32.62P
after write to 8322 with zeros, I read it again the confirm it is written, but after rebooting the phone, the value is back to 01 again.
I guess the verizon driver may override this value during rebooting?
any help?
should I root the phone?
==
thanks
Click to expand...
Click to collapse
Glad you got it working. There is no VZW software on the phone capable of writing to the radio NV, so it's not being reverted by anything.
If anyone else has similar issues I would suggest trying the NV/SEEM method as that will definitely write the item properly.
queberican351 said:
@DSDD
I beleive your XT902 is GSM by default. So if what your asking is will this bypass the network lock, no, the device needs to be unlocked by code. Then you can use it outside of the current carrier/country.
Click to expand...
Click to collapse
XT902 has sim lock, and there is no way to key in unlock code. So I think it maybe unlocked by modifying another NV item.
Does this tutorial unlock mobile data usage on other carriers. I cannot seem to get data working on my XT907 in Australia. GSM and MMS work fine, so why doesnt Data?
I don't know for certain because I only have experience with domestic US GSM carriers, but I tend to doubt it.
You can try it and see and revert it easily if it doesn't work. You can also try flashing the Telstra XT905 NON-HLOS.bin(modem) and fsg.mbn(carrierEFS/NVM config).
This was the method used to get US GSM service on XT907 before the method shown here was discovered.
It works but is limited to GSM/EDGE data services here in the US.
I am inclined to think it is some other problem with the device because it should work as a global capable phone by default.
dsdd said:
XT902 has sim lock, and there is no way to key in unlock code. So I think it maybe unlocked by modifying another NV item.
Click to expand...
Click to collapse
If it has a sim lock and you can acquire the code open your dialer and press #073887* (#0SETUP*) and it'll prompt you for the code.
Several people have PMd me questions about this method and I would much prefer that they be posted here in the thread so that everyone may benefit from the information.
Please include as much information about your PC and driver versions and be as thorough as possible in explaining your problems.
Hi.
I come from another post looking for a solution to my dilemma (http://forum.xda-developers.com/galaxy-s5/help/switch-stock-rom-t2866861#post55236673), thanks to fffft member found that I can open the band 4 of my cell S5 using the QPST program, however I can not find a modified .qcn file that corresponds to my model (G900F).
What I have done is make a backup of my original .qcn (which understand not share because there goes my IMEI) and I need advice from someone who knows that is the parameter that should change to open the AWS band 4.
Much appreciate your help.
I see that nobody has answered, if it was not for lack of cooperation, or because no one has had this problem.
Continue researching and achieve get qcn file G900M, which is super, but not left so installed as well, the QPST program generates an error and does not let install, so proceeded to compare them to see how different they are, and actually they are very different in their hexadecimal setting.
The issue now is, I need someone to tell me what are the parameter I have to modify my original qcn (my G900F) to enable AWS band 4.
Thank you for your help.
..
Hello again fffft.
I will try to explain everything in the best way. I can not send the file qcn G900M, because I have understood that within the IMEI can be identified, and the first thing I asked the person I give it to me was that change could not deliver it to anyone.
Now step by step to do was the following (taken from this forum http://forum.xda-developers.com/showthread.php?t=2291589 ):
Install phoneutil.apk in my phone.
Install QPST 2.7 build 323.
Choose the usb connection “RNDIS + DM + MODEM” from the menu that comes by typing *#0808#.
On the Ports tab of the program QSPT set the COM port corresponding to the cell (seeing that port recognizes the cell through Device Manager).
Choose “Start Clients” and choose “SOFTWARE DOWNLOAD”.
Hit the “Restore” tab, set port to COM number, choose the QCN file, and start.
Attached two images, one in which it is seen that the process is running smoothly, and a second in which shows the error.
With regard to your question about the RMNET protocol, for I must say I have no idea regards, because as I said I am still a newbie.
Finally and with respect to qcn file G900T me would be very very difficult to get the file G900M was relatively easy (not as easy lol) but because here in my country is the model that is sold, but the model does not get G900T no way.
I remain attentive to your suggestions, and thanks again for the help.
..
I thought S5 supports AWS band as well as other bands? I bought S5 from Rogers and use it with Wind mobile (Canada).
..
Hi.
Well, with my answer are attached to the two qcn files, not if it's okay to post them because I do not know which is the information that I'm giving, but I'll trust you fffft.
Review the entries with IMEI and clear, making this process and I thought this would be a very good explanation of why not to overwrite the original file leaves the cell, because the second IMEI not for the phone, but even if this were true, no understand how in the above forum they spread a qcn file for S4 that everyone could use.
Anyway, I hope that with this we can advance the issue to see if I can get out of this mess.
Thanks again.
..
Ok fffft, I found the parameter you say, but now my question is, as I edit the file qcn? I need some special program?
Loperaco said:
Ok fffft, I found the parameter you say, but now my question is, as I edit the file qcn? I need some special program?
Click to expand...
Click to collapse
Well, download the program XVI32 to edit the hexadecimal, apparently was successful but eventually the program generated the same mistake I had already seen, indicating "Could not reset the phone. COmmunication Errors Occurred".
Will you help me?
..
Hi there.
I have an interesting fact to share, because I could not properly complete the process to overwrite the qcn file then started to review the QPST program and its functions, among these I found the display content on qcn files through this for any entries who had been unable to write and determine that it was possible to write the file so qcn "hot" (ie directly on the phone) Oh and surprise! when I saw that the code / parameter that indicated fffft if I had changed even though the restore process had not been successful.
Anyway achieved modify the parameter in question and probe the cell after this, but still not achieve even connect AWS band 4, so despite the success the result was a failure.
Knowing this now accept suggestions from all of you experts.
..
Got a little further, but the bands did not get enabled...
fffft said:
Docx? Shouldn't those be .qcn files?
Anyway, you should try encouraging someone to post a NV dump from their 900T for comparison. You can check the existing AWS threads to confirm, but as I recall to enable AWS on earlier Galaxy models, required editing NV_RF_BC_CONFIG_l from 80 03 e8 04 to 80 03 e8 06
So ostensibly you will want to make the same change on your 900F. Comparing your NV to a 900T would lend confidence to that presumption.
.
Click to expand...
Click to collapse
fffft, Laperaco,
I am pursuing the same Band change as described here and have an update of the things that I was able to discover:
1) I was able to use QPST and pull NV backup from my phone - see my JJ_ATT_S5_Bands_Tester_No_IMEI (IMEI removed in Line 550)
**Note that I was not able to restore any QCN back to my phone in either USB mode (and I think this is what Loperaco was talking about), but...
2) I was able to program my phone directly using RF NV Item Manager, but did not get desired results (see below):
- a) I changed 1877 NV_RF_BC_CONFIG_l from 80 03 e8 04 to 80 03 e8 06 and nothing changed - i.e. radio still worked and I was still getting EDGE (no HSPA+)
- b) I tried changing the next line 1878 NV_RF_HW_CONFIG_I from f6 to 2c, because I saw that in another QCN file I found online. That actually "killed" my radio altogether, at least until I changed it back to f6
- c) Upon further inspection of the SM-N900T file I found online (too big to upload here), I saw that there are quite a few differences, which leads me to believe that additional configurations must be made to take advantage of the HSPA+ bands.
!! Please !! If someone with T-Mobile SGS5 looking at this, could you pull your QCN, mask IMEI if you'd like and post it here for comparison.
Otherwise, fffft, do you have any other thoughts regarding the changes needed...?
Last note that files are posted as .qcn.txt, becuase forum does not allow posting of qcn file extensions. Just remove .txt and you will have original qcn.
Thanks,
JJ
fffft said:
Your reluctance to document what you have done in detail is unfortunate because it prevents us from confirming that you did as you summarized or possibly discern any errors along the way. Nor did you tell us how you concluded that the phone did not connect to AWS, whether the changes were persistent after a reboot or what the service mode showed for activity after using the diagnostic menu to lock the handset to AWS, et cetera.
Of particular value would be a before and after NV dump from your phone, alongside a 900T NV dump. Which would illustrate both the required changes and any progress made with the attempted write.
To reply to your question, two obvious possibilities are apparent
1. That you changed the parameter as you summarized and that was insufficient to effect the desired change. Which would mean that the required parameter is different for the S5 than preceding Galaxy models for some reason e.g. that a different parameter needs editing or that radio changes are needed as well, even though that was not the case for the S3 & S4.
2. That you made some inadvertent error in your procedure that you didn't discern. No one can look for possible errors in the absence of you providing a detailed, step by step description of what you did though.
.
Click to expand...
Click to collapse
Ok ok, let me see how I can solve this.
First of all is not reluctance, I tried to be clear in how I do things, but I'll try again:
1. I bought a model of cell G900F that has disabled the AWS band 4.
2. I tried using the QPST program to replace the qcn file with one that corresponded to a G900M model, since in this model if the band 4 is enabled, but the process to make it in the program generated the error "Could not reset the phone. Communication Errors Occurred ".
3. I do not know how or if the QPST program writes an error log, so I do not know where to look it can be sent. I explain how to install and run the program each button is a bit wasteful, but I followed the steps in this forum http://forum.xda-developers.com/showthread.php?t=2291589
4. After this, and having received suggestions from fffft, I tried modifying the original qcn file from my phone, because I thought that perhaps the problem was because they were different models and finally the phone would not allow me to put a qcn file of another model. The modifications I did was change the parameter NV_RF_BC_CONFIG_l from 80 03 e8 04 to 80 03 e8 06. This is done by the program XVI32 modifying the hexadecimal.
5. I tried again using the option to restore the qcn file in QPST program, but got the same error "Could not reset the phone. Communication Errors Occurred".
6. I assumed I had to think of something else so it was when using the RF NV Manager (included in the installation program QSPT) for locate the actual file contents qcn on my phone, and I realized that despite the error obtained in restoring the file using the QPST program the parameter indicated in paragraph 4 of this list if it had changed.
7. I proceeded to check the signal and actually still had no access to the 4G network, the most that is connected to the HSDPA + network.
8. I read the comments from fffft and now I'm writing this.
I hope I was clear in my problem and have made a good step by step.
Now the issue is that:
A. I do not know how to access the diagnostic menu that enables or disables the AWS band, so I do not understand fffft what you're talking about.
B. I agree that modify only the parameter in question is not sufficient, otherwise the matter would be solved.
C. It is possible that I made a mistake as you point out, I finally am new to this, but still I explained my process so I am attentive to suggestions.
Thanks for the help.
JJ_Boja said:
fffft, Laperaco,
I am pursuing the same Band change as described here and have an update of the things that I was able to discover:
1) I was able to use QPST and pull NV backup from my phone - see my JJ_ATT_S5_Bands_Tester_No_IMEI (IMEI removed in Line 550)
**Note that I was not able to restore any QCN back to my phone in either USB mode (and I think this is what Loperaco was talking about), but...
2) I was able to program my phone directly using RF NV Item Manager, but did not get desired results (see below):
- a) I changed 1877 NV_RF_BC_CONFIG_l from 80 03 e8 04 to 80 03 e8 06 and nothing changed - i.e. radio still worked and I was still getting EDGE (no HSPA+)
- b) I tried changing the next line 1878 NV_RF_HW_CONFIG_I from f6 to 2c, because I saw that in another QCN file I found online. That actually "killed" my radio altogether, at least until I changed it back to f6
- c) Upon further inspection of the SM-N900T file I found online (too big to upload here), I saw that there are quite a few differences, which leads me to believe that additional configurations must be made to take advantage of the HSPA+ bands.
!! Please !! If someone with T-Mobile SGS5 looking at this, could you pull your QCN, mask IMEI if you'd like and post it here for comparison.
Otherwise, fffft, do you have any other thoughts regarding the changes needed...?
Last note that files are posted as .qcn.txt, becuase forum does not allow posting of qcn file extensions. Just remove .txt and you will have original qcn.
Thanks,
JJ
Click to expand...
Click to collapse
Hi JJ.
We are indeed talking about the same issue, however I see a difference and that is that despite not having the band 4 AWS enabled on your phone, this only gives you the edge band, however my phone without enabling the band 4 gives me HSDPA+, so my question, just out of curiosity, is what is the frequency at which your operator transmits the EDGE network?
Loperaco said:
5. I tried again using the option to restore the qcn file in QPST program, but got the same error "Could not reset the phone. Communication Errors Occurred".
6. I assumed I had to think of something else so it was when using the RF NV Manager (included in the installation program QSPT) for locate the actual file contents qcn on my phone, and I realized that despite the error obtained in restoring the file using the QPST program the parameter indicated in paragraph 4 of this list if it had changed.
Click to expand...
Click to collapse
Laperaco,
1) I was also unable to load qcn file from backup even without modifications, so...
2) I made modifications directly to the phone using RF NV Item Manager*
*Note from my post that changing line 1877 made no difference in connectivity for me.
3) This specific connection is below (although it naturally fluctuates):
Network Type: EDGE:2
GSM RSSI: -89db (63%) 12 asu
GSM Signal Strength: 13db (42%)
Preferred Network Type is LTE/GSM autio (PRL)*
*Non-GSM selections (WCDMA, LTE-only, etc) simply do not connect, so no HSPA+ for me
JJ
JJ_Boja said:
Laperaco,
1) I was also unable to load qcn file from backup even without modifications, so...
2) I made modifications directly to the phone using RF NV Item Manager*
*Note from my post that changing line 1877 made no difference in connectivity for me.
3) This specific connection is below (although it naturally fluctuates):
Network Type: EDGE:2
GSM RSSI: -89db (63%) 12 asu
GSM Signal Strength: 13db (42%)
Preferred Network Type is LTE/GSM autio (PRL)*
*Non-GSM selections (WCDMA, LTE-only, etc) simply do not connect, so no HSPA+ for me
JJ
Click to expand...
Click to collapse
Ok JJ, we are going through the same steps, we must wait for more help, I'll keep researching but I see that not many people have our problem.
I have a question is that with that code or through option that could see data that you send me.
Any information or change that has put it in the post.
..
Hi, using a rooted moto g7. There are /dev/graphics/fb{0,1}. I can not read directly from either device. The error given is "no such file or directory" however the files show up in a directory listing, this means the driver developer chose a bad error code.
How am I supposed to use them, for example to take a screenshot?
I see the sys nodes for the two devices /sys/class /graphics/fb{0,1}. I looked at their properties there, and see that fb1 is a writeback panel. As I understand it this is the one I should attempt to request screen data from.
I've looked at the msm_fb driver in the Linux kernel source but it's still not clear to me what I should do.
Background
It has been a long time since the Qualcomm first launched the IMS support in its AMSS(Adavanced Mobile Subscriber Software) subsytem since CDMA platforms,which is the major function part of VoLTE implementation on MSM platforms,but even years later,almost no one talks about this topic on internet,someone noticed about the Samsung IMS configuration,but it's higher layer and not applicable to original MSM platform phones.
Why no one talked about manual VoLTE configuration in the past
There are many reasons that caused such situation,first,the Qualcomm have NDA on its platform internal scheme,many engineers hesitate to share even some simple magic value about some NV items,which results complete blackbox to the APSS Android environment developers.Second,when there is limited number of available VoLTE phones,the manual configuration methods are hide by the selfish drive-test related device sellers,and they even try to block some useful info on some websites by abuse in order to hide the top business secret.I tried to talk about such topic in past days,but all got blocked in the end.Third,the phone vendors want you just to buy new phones to support the VoLTE,and they just choose to not support the sold devices,in some time,even add barricade,this is something that are not noticed by many customers
How it worked
Most of the Qualcomm IMS feature are implement in the AMSS subsystem,which means the configuration is saved in modem's memory,in this case,the EFS on QC phones,which means you will not got the VoLTE work through some Android side prop modification,like the most talked Magisk VoEnabler.Although these props in android environment are the key switch to launch the IMS function routine,but it will not work when you just opened the switch.They are just some RILJ/RIL control flags that decide which phone to be used(the imsphone or gsmphone in RILJ code).And such prop flags may vary from vendor to vendor,it might need extra prop to be set to make sure the IMS routine are properly called.In English,the Android side is just a client of the IMS-client inside modem AMSS subsystem,all of the actual IMS procedures are all completed in the modem environment.
How is it configured
There are many tools to configure such thing right now,I guess even some private ones,but the major way to configure the IMS configuration is through QXDM,it will have a plenty of NV items and EFS configuration in IMS section,the Qualcomm have internal guide since MSM8960,which talked about how to manually set those values to make the IMS VoLTE work.however I haven't see anyone even talked about it,may due too the reasons I talked above.Obviously,such manual configuration way is user un-friendly,the QC have to find some way else.This had introduced the MBN MCFG when Chinese rolling out the VoLTE,and such methods were invented by the OPPO I guess(patents about it).MBN format had been used by QC for years,but the mcfg mbn is different at least in some way,so no current available tools to parse it on other platform except the AMSS itself.So The MCFG MBN contains IMS related configuration stuff,but how to find what it actual contains?This problem remains unsolve until I found the ORCT by linneman in 2018,a simple and buggy toolkit to parse at least some recent MSM8996 platform MBNs ,and finnally got the proper contents in sw_mcfg.mbn file,Then it's the time to manually add those NV and items file into EFS through QPST,after all that the VoLTE finally worked.
Misconception about MCFG MBN
I guess people noticed something about MBN when some guy tried to use VoLTE on Pixel 2,then they made the Magisk VoEnabler,they thought they had loaded the proper sw_mcfg.mbn by replaceing the MBNs inside vendor partition,but none of them realized that they actually falled back to the generic 3GPP configuration of MSM platform,and after MSM8996,that configuration defaultly enabled the IMS feature to work on some 3GPP lab setting networks,interestingly very coincident work on live network
Further work
Android PDC
In fact,there is an app called MBN test which is considered as bloatware for many users,none of them realized it's the important tool kit like PDC used to choose the MBN for carriers,but on phone it self,it works through the RIL_PDC related command and have the same feature like Windows PDC,but this app got misconfigured when outside the factory,and its configuration methods are highly secreted by the vendors.no one willing to answer this question.
Android IMS NV configuration
After Android Lolipop,Google had introduced the carrierconfig framework,which provided some internal methods like nvReaditem,which can actually be used to configure the IMS parameters in modem side,but it's really weired that no one had realised about this usage on whole internet.I think it will be a more generic and one-click way to DIY VoLTE even on some other platform through those API,but no one ever talked about it
Add the ORCT mirror
GitHub - vtsingaras/orct: Open Radio Calibration Toolkit, an enhanced Open Source Implementation to replace Qualcomm's QRCT
Open Radio Calibration Toolkit, an enhanced Open Source Implementation to replace Qualcomm's QRCT - GitHub - vtsingaras/orct: Open Radio Calibration Toolkit, an enhanced Open Source Implementat...
github.com
Hey I'm wondering if you know how to change the identification domain. My carrier, Bell mobility, uses "ims.bell.ca" instead of the standard "ims.mnc610.mcc302.3gppnetwork.org".
My OnePlus 8 phone uses [email protected] as it's identification and the IMS core answer with 403 Forbidden.
A pixel 5 request [email protected] and it's working.
What do I need to change in the MBN to make it use "ims.bell.ca"?
Any news about this topic?
Based on other guides I am trying to load MBN files from other smartphones rom having the same soc (Snapdragon 845), but the new MBN file is not loaded and I see no error.