I started investigating this in sbrissen's AOSP JB thread when I was running Alpha 5 (Awesome ROM btw). In the interest of not hijacking/derailing this thread, I think it is time we finally figure out why in the world our phone's GPS is so flaky. The solution is almost assuredly in software.
Items of note:
Modem - Our devices GPS is housed within the Qualcomm QSC6085 silicon. Within there, according to http://xdaforums.com/showthread.php?t=1343072 indicates that we have a pretty powerful SiRFStarIV chip. Thus, flashing new modems can affect our interaction with the GPS chip.
Additionally, the aforementioned thread indicates the AGPS is not used on our phone.
I've confirmed that AGPS is not used on our phone via the following logcat:
Perhaps with enough digging, we can find where our GPS gets stuck.
-GP
(FYI: Getting a fix on a GB ROM and then immediately flashing is not the solution. At best, the ARM Cortex M3 that operates our baseband, must store data in its own cache since it was recently accessed.)
Update: We have evidence that, in order to save costs on the SPH-D710, the SurfStarIV was removed and our AP (Exynos 4210) handles all GPS duties.
----------------------------------------------
Update 01/23/2013:
First off, I'm sorry for the lack of communication. Second off, I wish I had better news. To respond to a lot of the posts in the thread... this development is all but dead for a couple reasons:
1. IDA Pro is >$1000. IDA Free is free, but doesn't support ARM. I've been using IDA Pro Evaluation, but it only allows a certain amount of use before exiting and does not allow me to save my IDB files (Files that contain refactoring, comments, and changes). I dealt with it for a while, but it is extremely cumbersome to try and deal with while reversing an application of this size.
2. Despite the fact that it would be neat for us to completely understand the modem, it is unlikely that the modem image is directly related to our problem. Our phone has the Qualcomm QSC8085 CDMA Baseband processor. The modem.bin contains, in essence, a completely separate OS that runs in real time all the time (Commonly referred to as an RTOS or Real Time Operating System).
This OS has a lot of responsibilities such as tower negotiations and handoffs, maintaining account information with Sprint, among other things. It likely interfaces with a data buffer that is handled, in part, by the RIL (Radio Interface Layer) which is part of the Android Kernel. Aside from that, it is unknown everything else that the radio has access/control over.
With all of this in mind, it is *possible* that it has some manner of control over the GPS; however, the extent is unclear. Given that we can wipe the EFS partition, flash new Radio Images, and reprovision our phone with virtually no effect on GPS, we can conclude that the problem is unlikely to reside in this image.
--------------------
There are a couple things to consider:
1. Based on all of the above data, it is possible/likely that a small portion of flash memory (Perhaps SRAM (Synchronous RAM) - very small, very fast, very expensive, used for processor cache) is located on the die of the Qualcomm chip that stores data. Because this storage is not accessible to us (Though perhaps the radio OS has access in some way) it persists across data wipes. This would explain why a lock achieved on a TW based ROM will persist across flashes.
2. If we assume the above conclusion has any merit, it is possible/likely that the GPS Daemon or a similar closed source driver packaged with the kernel is not working entirely as expected. It would be very prudent to look into some of these closed source binaries and see what information could be extracted from them; however, they are, ARM binaries and would run into the same obstacles as I outlined above.
3. The tweaks and applications (ie: GPS Status, AngryGPS) that are so widely spread around our forums, while they are useful in optimizing a currently operational GPS, they will NOT/NOT suddenly make a GPS begin to work (This is not meant as a slight to those developers publishing the tweaks. They are, I'm sure, excellent developers who have found fantastic ways to optimize/tweak the functionality of various functions).
When flashing these tweaks, it is important to remember that you are dealing with an extremely complex piece of electronics with many shifting variables. In other words, coincidences happen. A bug fix is only truly a bug fix if it works consistently over a wide set of cases.
--------------
If there is enough developer interest (ie: ONLY those who have significant assembly language or RE experience) and if someone can come up with another way of disassembling ARM binaries, PM me and we can entertain a group effort over a few files that may yield some results.
-Gamingphreek
Edit: Just thought of this... objdump is not a viable disassembler for a binary of this size/complexity. Refactoring and Cross Referencing is all but a necessity.
Items of note:
Modem - Our devices GPS is housed within the Qualcomm QSC6085 silicon. Within there, according to http://xdaforums.com/showthread.php?t=1343072 indicates that we have a pretty powerful SiRFStarIV chip. Thus, flashing new modems can affect our interaction with the GPS chip.
Additionally, the aforementioned thread indicates the AGPS is not used on our phone.
I've confirmed that AGPS is not used on our phone via the following logcat:
Code:
D/GPSD ( 1767): load_xtra_bin: buf_len 50000
E/GPSD ( 1767): load_xtra_bin: open /data/gps/xtra.bin failed. Permission denied.
E/GPSD ( 1767): No cached xtra.bin. request to download new binary.Perhaps with enough digging, we can find where our GPS gets stuck.
-GP
(FYI: Getting a fix on a GB ROM and then immediately flashing is not the solution. At best, the ARM Cortex M3 that operates our baseband, must store data in its own cache since it was recently accessed.)
Update: We have evidence that, in order to save costs on the SPH-D710, the SurfStarIV was removed and our AP (Exynos 4210) handles all GPS duties.
----------------------------------------------
Update 01/23/2013:
First off, I'm sorry for the lack of communication. Second off, I wish I had better news. To respond to a lot of the posts in the thread... this development is all but dead for a couple reasons:
1. IDA Pro is >$1000. IDA Free is free, but doesn't support ARM. I've been using IDA Pro Evaluation, but it only allows a certain amount of use before exiting and does not allow me to save my IDB files (Files that contain refactoring, comments, and changes). I dealt with it for a while, but it is extremely cumbersome to try and deal with while reversing an application of this size.
2. Despite the fact that it would be neat for us to completely understand the modem, it is unlikely that the modem image is directly related to our problem. Our phone has the Qualcomm QSC8085 CDMA Baseband processor. The modem.bin contains, in essence, a completely separate OS that runs in real time all the time (Commonly referred to as an RTOS or Real Time Operating System).
This OS has a lot of responsibilities such as tower negotiations and handoffs, maintaining account information with Sprint, among other things. It likely interfaces with a data buffer that is handled, in part, by the RIL (Radio Interface Layer) which is part of the Android Kernel. Aside from that, it is unknown everything else that the radio has access/control over.
With all of this in mind, it is *possible* that it has some manner of control over the GPS; however, the extent is unclear. Given that we can wipe the EFS partition, flash new Radio Images, and reprovision our phone with virtually no effect on GPS, we can conclude that the problem is unlikely to reside in this image.
--------------------
There are a couple things to consider:
1. Based on all of the above data, it is possible/likely that a small portion of flash memory (Perhaps SRAM (Synchronous RAM) - very small, very fast, very expensive, used for processor cache) is located on the die of the Qualcomm chip that stores data. Because this storage is not accessible to us (Though perhaps the radio OS has access in some way) it persists across data wipes. This would explain why a lock achieved on a TW based ROM will persist across flashes.
2. If we assume the above conclusion has any merit, it is possible/likely that the GPS Daemon or a similar closed source driver packaged with the kernel is not working entirely as expected. It would be very prudent to look into some of these closed source binaries and see what information could be extracted from them; however, they are, ARM binaries and would run into the same obstacles as I outlined above.
3. The tweaks and applications (ie: GPS Status, AngryGPS) that are so widely spread around our forums, while they are useful in optimizing a currently operational GPS, they will NOT/NOT suddenly make a GPS begin to work (This is not meant as a slight to those developers publishing the tweaks. They are, I'm sure, excellent developers who have found fantastic ways to optimize/tweak the functionality of various functions).
When flashing these tweaks, it is important to remember that you are dealing with an extremely complex piece of electronics with many shifting variables. In other words, coincidences happen. A bug fix is only truly a bug fix if it works consistently over a wide set of cases.
--------------
If there is enough developer interest (ie: ONLY those who have significant assembly language or RE experience) and if someone can come up with another way of disassembling ARM binaries, PM me and we can entertain a group effort over a few files that may yield some results.
-Gamingphreek
Edit: Just thought of this... objdump is not a viable disassembler for a binary of this size/complexity. Refactoring and Cross Referencing is all but a necessity.
Last edited:
