Latest SHR-?

[Arigead]

William Kenworthy wrote:
> 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.
> 

Thanks a million Billk

I've been out of the FR since just before Christmas but got back to it
last week and installed the latest SHR-U My GSM refused to work with it
but this kernel did the trick.

Have a load of catching up to do,but thanks for the fix