Some questions to new SHR images (ubifs, gps)

Sylvain Paré sylvain.pare at
Mon Jul 26 00:35:44 CEST 2010

Thanks for your feedback/tests.
Just one question

> GTA02A5 with no capacitor on SD clock
for me  this 05 rev means there is a capacitor  on µSD . no ?
In my case I have a GTA05 with capacitor.
I am on shr-u on NAND with kernel 2.6.32 so with Qi too and all uptodate.
I will test it like you tomorrow.

2010/7/26 Al Johnson <openmoko at>

> 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]:
> > [2]:
> 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.
> _______________________________________________
> Openmoko community mailing list
> community at
-------------- next part --------------
An HTML attachment was scrubbed...

More information about the community mailing list