Latest SHR-?

[William Kenworthy]

On Fri, 2010-01-29 at 09:15 +0100, neo at el-hennig.de wrote:
> > I'm not using shr-t or any .29-rc3 kernel, so I cannot comment. But on
> > shr ML and trac there was few reports about not getting GPS lock or GSM
> > channel (even with debug kernel) and at least 3 people said that they
> > are having this problem more often with nodebug kernel.
> 
> I am one of those people ;-) the problem with registering GSM is not caused by the 'fast' kernel. However it occurs more often using the 'fast' kernel. Obviously there is something going wrong in FSO if the system responds much quicker than before with the debug kernel. I discussed that with Mickey last week during our regular munich openmoko meeting nd he is currently working on a solution for that problem, time permitting.
>  
> > So I asked spaetz (maintainer of shr-t) and he said that we should
> > rather revert back to debug (as it's slower but as some say more
> > stable). If we want to test nodebug kernel, we should do it rather in
> > shr-u and *after* testing use it in shr-t too.
> 
> With the new kernel I was able to register GSM only when I gave the system something to do (start navit for example). Then the modem registered correctly and the PIN dialogue popped up. Sounds strange, but it's just like that (a tribute to the mouse ;-) ). At the moment the debug kernel is better suited for every day use, but on the other hand the system speed the freerunner is capable of is amazing.
> 

The GSM chipset in my a5 FR worked ok on the 24 kernel, so-so on the .28
kernel - often took a number of reboots before the serial port would
work to allow the OS to configure GSM.  A *standard* unmodified .29 has
never worked :( 

The fix for me was to make .29 behave like a .28 kernel and enable the
GSM ... and leave it enabled.  In .29 the kernel was changed to follow
the specs and "strobe" the enable line (enable, wait 500ms, disable)
which seems to work for everybody else but me (!)  This current,
modified kernel is perhaps the best behaved as far as GSM serial port
goes that I have had up until now.  And yes, there were a number of bug
reports made and investigated with the consensus that my GSM chipset is
faulty - however I am of the opinion that the kernel and framework
handing of GSM is still not quite right and my chipset is just far
enough out to cause problems.

If you check the logs and it seems that the serial port is the problem,
try the kernel and modules below.

"http://wdk.dyndns.org/freerunner/"

unpack the modules to /lib/modules - it will be in 2.6.29-rc3-wdk so
wont overwrite your current modules :)
flash the kernel and boot.

To return to your original, just reflash the old kernel and delete the
new modules if finished with them.

Use at own risk, yadda yadda ...

This kernel been working very well for me for about a week, the gsm mod
for about 6 months - have fun,
Billk

* Note that most of the fixes were from the mailing list, only the GSM
one is mine.

"http://wdk.dyndns.org/freerunner/"

Mods: 
* there are a couple of other msleeps in this file I set as well, but
this was the critical fix for me!
neo1973_pm_gsm.c
	neo1973_gpb_setpin(GTA01_GPIO_MODEM_ON, 1);
        msleep(500);
        /* neo1973_gpb_setpin(GTA01_GPIO_MODEM_ON, 0); leaves line high
so serial stays working*/

Config was basic shr-t nodebug, with more debug items off, slub
allocator and -O2 optimisation.  It also has a 100ms delay for wifi as
discussed on the list (where they recommended 10ms, neither value makes
a difference to me, but I am not sure I suffer from the problem anyway -
experimentation :) and a patch to wm8753.c to allow -O2 optimisation to
compile.  The .config (as config-wdk) is at the above address.  
All functions (wifi, usb, gsm, bluetooth, ...) seem to work
well.