Some questions to new SHR images (ubifs, gps)

[Al Johnson]

On Saturday 24 July 2010, Neil wrote:
> If you read the SHR wiki page[1] you will find a list of features. The
> ones with a red background are broken. GPS is broken and links to a
> ticket on the SHR bug tracker[2]. GPS not working after suspend is a
> known issue. If you have any insight into the bug (like "it stopped
> working when I upgraded from the x.y.z kernel to the to the2.6.32
> kernel), please post it to that thread.
> 
> Thanks,
> 
> Neil
> Another who has the problem
> 
> [1]: http://wiki.openmoko.org/wiki/SHR
> [2]: http://www.shr-project.org/trac/ticket/1085

I just did some tests on a recently installed shr-u and had no problems 
getting a fix, even when trying to provoke a problem. Details:

GTA02A5 with no capacitor on SD clock
Qi
shr-full-eglibc-ipk--20100721-om-gta02.rootfs.tar.gz on ext3 mmcblk0p1, no 
updates
Time set manually to nearest minute (SIM is outdated so no time via GSM), 
timezone Europe/London set by SHR not by me
WiFi off, bluetooth off, gsm antenna power initially off, then on in later 
tests

Procedure:
Press power button to resume from suspend
Press power button and use quick settings to disable screen dimming and 
suspend since I don't want to have to keep poking the screen to see what's 
going on
Use settings app to remove agps data
Start tangogps and put phone by the window, keep watching to see how long it 
takes to get a fix.
Shut down tangogps, enable dimming and suspend, manually suspend, and repeat.

The constellation must have been favourable because all 3 tests got a fix in 
less than 2 minutes. Just in case there's a problem with restoring agps data I 
repeated the tests but without removing the agps data. Again 3 tests, each 
with fix in ~45s. I repeated the tests just over an hour later with the gsm 
antenna power on in case that made a difference, and hoping the constellation 
may be less advantageous, but the results were similar.

Now to try provoking it in a way that used to cause problems...
Delete agps data.
Start tangogps, let it connect to the gps but exit before it has time to get a 
fix.
Wait, check in settings that the gps is showing 'unknown' for everything, and 
that the 'remove agps data' button has appeared. Do not remove the agps data.
Start tangogps and see how long it takes to get a fix.

This used to cause problems by loading invalid almanac and ephemeris data 
after powering up the gps. Depending on how lucky you were this could cause 
delays in getting a fix, prevent it getting a fix at all, or even cause the 
gps to crash and restart, leaving ogpsd rejecting the NMEA data it then 
produced as invalid because it wasn't in the ubx format it was looking for.

Either I was very lucky, or that problem is now fixed. Again all 3 tests got a 
fix in under 2 minutes.

To some extent I have been lucky in these tests as it is unusual to get a fix 
that fast that often in that location. Does anyone have any suggestions as to 
how I might reproduce the problems people are reporting? Setting the time to 
something significantly incorrect or deliberately corrupting the agps data 
should do it, but those shouldn't be normal occurrences.