Some Questions and Issues, still to be resolved
There are some burning issues that still have not been addressed/resolved
that I think may be essential for further unlock development. And unless there are some recent tantalizing developments, that I'm not yet aware of, I'd like to see a plan of action. Perhaps something like this.
My Strategy / Way Points:
1. Find out if any Qfuses are blown, and which ones.The Issues
(What is the meaning/behavior of the various Qfuses on MSM8960?)
2. If we are not using Qfuses, how are the GPIO boot pins set?
3. If we are using Qfuses, what alternatives do we have to circumvent to reach code execution?
4. What is the meaning of the BOOT_CONFIG pins in (2).
5. How can we change GPIO to do what we want?
a) What do we want?
b) Is this a SW/FW hack or a HW hack?
6. How can we get our code to run?
a) Does it still need to be signed?
b) Where and when should it run?
A) What are the:
a) cold-start BOOT_CONFIG settings?
b) warm-start BOOT_CONFIG settings?
We raised this issue in post #212
, but we had a different opinion (#206
of how the MSM_RESOUT_N signal behaves during cold/warm boot. The point
being that the pins internal pull-up/down strength and behavior is decided
programatically, while the reference design was updated/changed at some point,
and thus the true behavior it was never resolved and verified.
What to do:
We need someone to measure what happens on the following
pins (see #212
) during cold/warm boots, respectively.
also BC[0:1] to verify...
B) How can we read all the GPIO settings as shown in #228 ?
On the SGS2 running stock GB (and many others), we can simply issue the command:
and the result is in the form:
GPIOs 168-175, GPL0:
gpio-171 (TSP_LDO_ON ) out lo
gpio-172 (GPB ) in lo
gpio-173 (_3_GPIO_TOUCH_INT ) in lo irq-537 edge-falling
gpio-174 (USB_SEL ) out lo
But this doesn't work on our I535. This is probably because it doesn't have the debugfs
mounted by default. This can be fairly easily done, but does not guarantee a positive result anyway.
So how do we do it on this device? We're not sure yet, so try we try the following commands to find GPIO info.
# To find all directories called "gpio":
find / -type d -iname "gpio"
#To find all regular files called "gpio":
find / -type f -iname "gpio"
If you find a regular file called "gpio", try to print it with:
What to do:
Post the results of the previous commands.
If this still doesn't work, we can try to use the modem to send an AT
commands that may show the GPIO settings etc. See below.
C) How to connect to your modem from a PC terminal when connected with USB cable?
This was first discussed in #231
, but without any conclusion, since the user
managed to connect, but only one of his AT commands worked. No follow up.
The modem AT command interface is firmware (radio) dependent, so the available
commands can vary widely, but generally there is a standard (3GPP TS 27.007
that the device need to comply to, regarding the minimally supported AT command
set. However, when connected under normal circumstances (with phone in normal
operation) the AT commands to the modem may be filtered by either the internal
Adnroid device driver RIL daemon "drexe" or something like it. Therefore you may
need to put your phone in some kind of service mode, or change the Qualcomm
connection settings to bypass this filter, to have full access to all avialble
AT commands. It has been suggested that one way to do this on the I535, is using
the "hidden meny", reached by dialing "*#22745927
" (???), and then selecting the
Or you can try this
, which was used for the HTC EVO3D.
For the Sprint SGS3 you have to enter the "IOTHiddenMenu" menu by
) and then long press "Qualcomm USB Settings".
Then select "DM + MODEM + ADB
", as shown here
, or watch
According to that post, for the AOSP SGS3 you can also use:
echo 0 > /sys/class/android_usb/android0/enable
echo 04E8 > /sys/class/android_usb/android0/idVendor
echo 6860 > /sys/class/android_usb/android0/idProduct
echo diag > /sys/class/android_usb/android0/f_diag/clients
echo 1 > /sys/class/android_usb/android0/f_acm/instances
echo diag,acm,adb > /sys/class/android_usb/android0/functions
echo 1 > /sys/class/android_usb/android0/enable
setprop sys.usb.state sys.usb.config
To make your settings stick: Use Chainfire
" App as posted here
Then when you finally have modem connection. A few basic commands to test are:
AT // OK?
ATI // device info
ATZ // "reset" modem to default configuration (safe)
ATE1 // turn on echo
ATV1 // turn on verbose results
AT+CLAC // lists all officially available AT commands
AT+CGMI // Manufacturing Identification
AT+CGMM // Model Identification
AT+CGMR // Firmware Revision
AT$QCDMG // Should cause phone/modem enter to diagnostic mode. (May be hard to exit...)
These are all standard ("+") AT commands. If all of these works, you are on
the right track. Next we'll lok at some specialized ("@", "$", "#", "%")
proprietary AT commands. Qualcomm proprietary AT commands usually have
the format: "AT$<command>". However, its becoming more popular for OEMs to
implement entire new sets of ATs. For example Intel/infineon have a whole
new programmable world (to be discovered). [E.g. Try on your XG626 with at@help
AT$QCDMG // Transitions to Diagnostics Monitor (DM) operation
AT$QCDMR=? // Sets DM baud rate (default 115200)
AT&V // Dumps configuration paramters
AT$CNTI* // Displays the access technology;
// (Proprietary AT commands, AT&T Connection Manager)
According to this source
, and for the HTC [(US T-mobile) G2] == [Desire Z] ==
[Vision], we can use the proprietary AT commands:
...to get EBI, GPIO, and PMIC info.
<< To Be Continued... >>