yashsingh1/xdaforums huggingface dataset:
[Touch CDMA Android Development] kallt_kaffe:
I figured I'd share the new image if anyone else want to give it a try.

Please use a hex editor like i.Hex to change kernel parameters if you intend to use the NBH. It's preconfigured for panel 1 and nordic hardware keyboard.
[Touch CDMA Android Development] kallt_kaffe:
3 hours and 30 minutes of running GPS Test and still going... This I believe is the longest I've been able to use the GPS without phone freezing.

I'll keep it running for another two hours or so.
[Touch CDMA Android Development] kallt_kaffe:
After 4 hours the GPS symbol in the status bar dissappeared and GPS Test has stopped updating. BUT, the phone is still running, and restarting GPS Test got the GPS symbol back and a fix within seconds.

So far this certainly is an improvement.

EDIT: In fact every now and then when I start, for example, Google Maps, the GPS symbol does not appear and I have to restart the application. I can't remember that I've seen this behaviour before the new changes. However, I very much prefer that compared to the whole phone freezing. This is just a minor glitch.
[Touch CDMA Android Development] Dark-Side:
I'm going to test your new kernel on my KAIS130...

I saw GPS don't work properly last time, make mistakes with wifi and freezing phone... I suppose it was broken here : http://git.linuxtogo.org/?p=groups/...ff;h=13044ba065ef88ed75b9cfc035d7cf07fd9d5472

Thanks for all :)
[Touch CDMA Android Development] Dark-Side:
I use Incubus26Jc's My Touch Slide 2.1 RLS2; i can't install update for wifi...

# df -h
Filesystem Size Used Available Use% Mounted on
/dev/block/mmcblk0p1 1.4G 996.9M 404.4M 71% /sdcard
/dev/block/mtdblock2 128.0M 128.0M 0 100% /system
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /data
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /cache
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /shared_prefs
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /tmp
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /system/bin/su
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /bin/su
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /system/etc/ppp
/dev/block/mtdblock3 86.1M 51.1M 35.1M 59% /smodem
tmpfs 45.6M 12.0K 45.6M 0% /dev
tmpfs 4.0M 0 4.0M 0% /sqlite_stmt_journals
#

edit: my kaisimg.nbh panel2, azerty, 480x320
[Touch CDMA Android Development] jnadke:
The bug I had you get rid of would only fix the "phone freezes when turning on GPS issue".

To test that, you'd start and exit GPS a bunch of times, repeatedly.

Sounds like there might be another issue somewhere. I'm not surprised. I'll see if I notice anything suspicious.
[Touch CDMA Android Development] kallt_kaffe:
I noticed that you submitted the GPS enable/disable fix so I'm going to update my source tree.

Those last_kmsg that I've posted from three freezes. Are those of any help? Is there any point in posting more of them? Seems like the same kind of error so I guess not, correct?

btw, thanks for spending time on this.
[Touch CDMA Android Development] jnadke:
Np.

Aside from the fact that it crashes while GPS is active, the calltrace doesn't indicate it's a GPS issue.

I'll see what I can find, but this problem might be for dzo's expertise.

Re-enable the printk's and give me a new log. They may help in telling me what's going on just before this happened. It'll give me a direction to look.
[Touch CDMA Android Development] kallt_kaffe:
There is a sys_read in the backtrace and the only sys_read in board-kaiser-gps.c is this:

408 count = sys_read(fd, buf, sizeof(buf));
[Touch CDMA Android Development] kallt_kaffe:
I have them enabled again and I'll get a log as soon as it crashes again. But it may take some time. However the two first logs have printk enabled so if there are any clues it should be there.
[Touch CDMA Android Development] kallt_kaffe:
Seems like others have experienced the same error:

http://groups.google.com/group/android-kernel/browse_thread/thread/a8b03d48f07c2d80?pli=1

Also the I found the wakelocks_read_proc here: http://git.linuxtogo.org/?p=groups/...7;hb=7bb61a44047608e814c1fc489463929e1a4b6911
[Touch CDMA Android Development] jnadke:
Good catch.

Question:

Does it crash on the first time you use it? Or does it only crash after you use it several times (i.e. exit and go back into google maps several times)?

There are resources GPS re-uses from the last time its started up. Knowing how long it takes for the bug to pop up is useful.
[Touch CDMA Android Development] jnadke:
That's messed up. The NMEA buffer is only 256 bytes. The call shouldn't be able to return 335 bytes of data.

Could be a buffer overflow. After that, memory is hosed and who knows what could happen.

Replace:

396 char buf[256];

With:

396 static char buf[1024];

I threw the static in there to avoid any run-time allocation issues.
[Touch CDMA Android Development] kallt_kaffe:
As I wrote I changed to char buf[512] and added msleep(100) to the loop, before that it never went above 256.
[Touch CDMA Android Development] jnadke:
Whoops, didn't catch that part!
[Touch CDMA Android Development] kallt_kaffe:
Btw, I'm back on char buf[256] and no msleep and doing the first start test again.

I also stumbled upon this article containing an example on how to do sys_read from within the kernel: http://www.linuxjournal.com/article/8110?page=0,1

Can that be a clue to why we get a NULL pointer?

EDIT: Oh and I realize why my increased buffer broke it down... Found this in nmea.h

22 typedef struct nmea_state {

23 sats_callback *sats_cb;

24 pos_callback *pos_cb;

25 gsv_callback *gsv_cb;

26 vtg_callback *vtg_cb;

27 rmc_callback *rmc_cb;

28

29 enum State state;

30 char line[256];

31 int count;

32 } nmea_state;

33
[Touch CDMA Android Development] jnadke:
I've never tried reading files from the kernel (I know not to do it, and why).

I'm not sure what's causing that particular error, but the article does have a point.

sys_ are for user-space calls. We should be calling vfs_read directly. Also, we should be using filp_open like that page mentions. This in addition to the other changes it mentions.

I'd try that.
[Touch CDMA Android Development] kallt_kaffe:
I'll have a look at it tomorrow.

I'm back at buf[256] and I've done some testing with GPS Test from fresh boot and it worked for several hours at home, then I brought in the car, then home again, and then for a walk with the dog. Worked very well until I ran out of battery.

I'll put in the charger and let it sit during the night and see how it goes.

Once it is 100% stable I will have a look at the nmea parsing. My 512-byte buffer failure proves one thing and that is that the NMEA commands can be longer than 256 bytes because state->line should only hold one command at a time. I suspect we are dropping some commands, but stability is main priority.
[Touch CDMA Android Development] kallt_kaffe:
Froze after 3-4 hours.

I read up on NMEA and had another look at the code and my assumption above is wrong. It only proves adding a delay can make us loose information and if we lose a "*" we can get long and corrupt NMEA sentences.

There should be a check to avoid overflowing state->line and invalidate the data if it does. I will add that because even without a delay I believe it can happen in rare circumstances.
[Touch CDMA Android Development] kallt_kaffe:
Update: I first disabled the setfs calls just to see if it made any difference. But it still froze on volume up/down. So now I also decreased buf to 64 bytes and volume up/down doesn't freeze the phone anymore.

Still not sure wheter setfs calls should be there or not when using the more lowlevel file read functions.

EDIT: Died on the wakelocks thing again, I've put the setfs commands back and I'll give it another go.
[Touch CDMA Android Development] kallt_kaffe:
Btw, what controls the GPS status icon? I got a strange phenomena where the GPS icon stayed on but GPS is not running (No GPS activity in /proc/kmsg)

I also could not start GPS Test again, or well, I could start it but it seems stuck waiting for GPS to enable or something like that.

Could the gps_rpc_thread still be running while the gps_nmea_thread is not? Or is it just a variable somewhere that contains the wrong information.

It didn't even help to switch the GPS off and on again with the Power control widget so I had to reboot the phone.
[Touch CDMA Android Development] kallt_kaffe:
Seems like I cannot get rid of those null pointer panics at the wakelocks_read_proc whatever I do.

What code puts data into /dev/smd7? Could it be that the actual problem is there? Or do we need to find another way to access the NMEA data that does not include reading from the filesystem?
[Touch CDMA Android Development] kallt_kaffe:
This is where I am right now:

Changed nmea_state in gps/nmea.h:

typedef struct nmea_state {
sats_callback *sats_cb;
pos_callback *pos_cb;
gsv_callback *gsv_cb;
vtg_callback *vtg_cb;
rmc_callback *rmc_cb;

enum State state;
char line[80];
int count;
char checksum;
char checksumstr[3];
} nmea_state;

Updated nmea_parse code in gps/nmea.c (I'm certain this one can be optimized a bit but my C skills aren't what they were 15 years ago, and they weren't great then either):

void nmea_parse(nmea_state *state, char buf[], char len)
{
int i;

for (i = 0; i < len; i++) {
char ch = buf[i];
if (ch == '$') // Reset parsing if a $ is detected
state->state = StateWaitStart;
switch (state->state) {
case StateWaitStart:
if (ch == '$') { // Wait for start of NMEA Sentence
state->state = StateProcessing;
state->count = 0;
state->checksum = '\0';
state->checksumstr[0] = '\0';
}
break;

case StateProcessing:
if (state->count < sizeof(state->line)) {
state->line[state->count++] = ch;
// Catch the checksum
if (ch == '*')
sprintf(state->checksumstr,"%02X",state->checksum);
state->checksum ^= ch; // Calculate checksum (XOR)
if (ch == '\r') {
state->line[state->count-1] = '\0'; // NMEA Sentence
state->line[state->count-4] = '\0'; // Checksum

// Only process sentence if checksums match
if ( (state->line[state->count-3]==state->checksumstr[0]) && (state->line[state->count-2]==state->checksumstr[1]) )
process_sentence(state);
else {
printk("NMEA checksum mismatch! %c%c != %s\n",state->line[state->count-3],state->line[state->count-2],state->checksumstr);
printk("%s\n",state->line);
}
state->state = StateWaitStart;
}
} else {
printk("NMEA sentence too large: %d\n", state->count);
state->line[state->count-1] = '\0';
printk("%s\n",state->line);
state->state = StateWaitStart;
}
break;
}
}
}

Updated gps_nmea_thread in board-kaiser-gps.c:

static int gps_nmea_thread (void *data)
{
struct file *filp;
mm_segment_t oldfs;
int count;
static char buf[128];
struct nmea_state nmea;

filp = filp_open("/dev/smd7", O_RDONLY, 0);
if (!filp || IS_ERR(filp)) {
printk("Unable to open NMEA device %d\n", (int) PTR_ERR(filp));
return -1;
}
if (!filp->f_op->read)
return -2;

nmea_init(&nmea, handle_fix_info, handle_pos_data, handle_sat_data,
handle_bearing_speed, handle_date);
while (!kthread_should_stop()) {
if (state->state == GPS_STATE_ON)
gps_tickle();
oldfs = get_fs();
set_fs(KERNEL_DS);
do {
count = filp->f_op->read(filp, buf, sizeof(buf), &filp->f_pos);
} while (!count);
set_fs(oldfs);
nmea_parse(&nmea, buf, count);
}
filp_close(filp, NULL);

return 0;
}

I currently have Wifi and background transfer enabled and I'm stressed it by switching between Google Maps, GPS Test and c:geo and changing the ringer volumen every now and then but it still works.

However I have a feeling that the NULL pointer panic will come back to haunt me.

Nonetheless I've attached NBH and zImage if anyone is brave enough to give it a try. (For Kaiser users!)
[Touch CDMA Android Development] kallt_kaffe:
The panics still occur. I'm trying to find out what's going on and UeventObserver keeps coming up in those panics. I've done some googling and I think that the UeventObserver is a part of Android (not the kernel) and it reads /proc/wakelocks.

Could it be something like if the UeventObserver reads the proc-filesystem at the same time as we read the /dev/smd7 (from within the kernel) something bad happens?
[Touch CDMA Android Development] cb2002:
Great work, I'd love to help you track this down. This GPS issues bug me a lot too. But I'm kinda stuck with setting up the environments on building NBHs.

I have compiled the kernel and got a zImage. I have android-sdk. I think the next step is building the RILs and compile tinboot for Kaiser but haven't figured out how to do that. I've looked on the forums but the information is all over various threads and posts and some of them are outdated too.

If you can point me in the right direction, that'd be great.
[Touch CDMA Android Development] kallt_kaffe:
Actually I've left NAND temporarily as I change kernel very frequently while doing this and it's just easier to replace the zImage on the memory card.

However, to create a NBH file you can follow this guide: http://xdaforums.com/showpost.php?p=5411636&postcount=2

Step 8 is wrong, only the last instance should be changed. Also the kernelparameters in tinboot.S are no up-to-date. Use a hexeditor on my NBH's or DZO's to see what needs to be changed.

As for getting the GPS to work I have a version now that works better. The freezes are happening less often, I can't seem to get rid of them but I've only hade them twice today and I've used the GPS a lot today and before I often got the freeze every 15-30 minutes or so. I'll tweak it a little more then I'll compile and attach a new version.
[Touch CDMA Android Development] kallt_kaffe:
Here's the version of the kernel that I am currently using: http://xdaforums.com/showthread.php?t=660158

It has a gps_nmea_thread that looks like this:

static int gps_nmea_thread (void *data)
{
struct file *filp;
mm_segment_t oldfs;
int count;
static char buf[8193];
struct nmea_state nmea;

filp = filp_open("/dev/smd7", O_RDONLY, 0);
if (!filp || IS_ERR(filp)) {
printk("Unable to open NMEA device %d\n", (int) PTR_ERR(filp));
return -1;
}
if (!filp->f_op->read)
return -2;

nmea_init(&nmea, handle_fix_info, handle_pos_data, handle_sat_data,
handle_bearing_speed, handle_date);
while (!kthread_should_stop()) {
if (state->state == GPS_STATE_ON)
gps_tickle();

msleep(500);	// Wait for some data to buffer up

oldfs = get_fs();	// Read data
set_fs(KERNEL_DS);
count = filp->f_op->read(filp, buf, sizeof(buf), &filp->f_pos);
set_fs(oldfs);
printk("NMEA read. Size %d\n", count);	// For debugging. Should be disabled once it's 100% stable
//	buf[count]='\0';
// printk("NMEA data: %s\n", buf);

if (count)	// Only parse if there is data
nmea_parse(&nmea, buf, count);
}
filp_close(filp, NULL);
return 0;
}
[Touch CDMA Android Development] cb2002:
Looking good :) Testing out the your new kernel. So far so good in regard to GPS. No lock up yet for using it twice about 15 minutes each time. Will continue testing and let you know.
[Touch CDMA Android Development] kallt_kaffe:
jnadke: A question...

I've matched a few numbers from the SUPL GPS registery values and this RPC command (that is used in GPS_Tickle and GPS_Enable):

msg.msg[0] = cpu_to_be32(0xa);
msg.msg[1] = cpu_to_be32(0x011843e0);
msg.msg[2] = cpu_to_be32(0x7);
msg.msg[3] = cpu_to_be32(0x1);
msg.msg[4] = cpu_to_be32(0x1);
msg.msg[5] = cpu_to_be32(0x1);
msg.msg[6] = cpu_to_be32(0x2);
msg.msg[7] = cpu_to_be32(0x0);
msg.msg[8] = cpu_to_be32(0x3b9ac9ff);
msg.msg[9] = cpu_to_be32(0x1);
msg.msg[10] = cpu_to_be32(0x0);
msg.msg[11] = cpu_to_be32(0x0);
msg.msg[12] = cpu_to_be32(0x0);
msg.msg[13] = cpu_to_be32(0x132f);
msg.msg[14] = cpu_to_be32(0x0);
msg.msg[15] = cpu_to_be32(0x0);
msg.msg[16] = cpu_to_be32(0x1);
msg.msg[17] = cpu_to_be32(0x32);
msg.msg[18] = cpu_to_be32(0x2);
msg.msg[19] = cpu_to_be32(0xda3);
rc = msm_rpc_call(RPC_GPS_PROG, 0xa, &msg, (20*4)+sizeof(struct rpc_request_hdr), 15*HZ);

My guess is that msg.msg[6] may be the "GPS Mode". Are these RPC commands documented somewhere?
[Touch CDMA Android Development] jnadke:
No, they're not documented.

You could probably ask the guy who wrote the file, his name is at the top of it.....

I'm pretty sure nobody understands them. I think they just recorded using HaReT what Windows Mobile was sending over that channel while GPS was 1) being started up and 2) when it lost reception.

The data you see is the hard-coded data being played back.

You can't really assume msg[6] is GPS Mode. We actually set that in the RIL (there's a RIL command for it -- search there). If there's an additional GPS mode, it could very easily be hidden as higher 4-bits of one of the 32-bit values that is set.

The only way to know is re-record using HaReT, and I haven't the slightest clue what the procedure is (I could probably figure it out, but it's not on my priority list). You'd basically have to direct it to record all AMSS I/O directed at 0x31000004 (kaiser may be different?).
[Touch CDMA Android Development] cb2002:
Got a lock up today using your NBH, just arriving near the destination. Here is the last_kmsg:

[ 3969.572390] date=27042010

[ 3969.572438] fix=-1068985344

[ 3969.572473] speed=622 bearing=916

[ 3969.884970] ds2746: 3689mV -709mA charge: 72/100 (3135 units)

[ 3969.884993] aux0: 253 (1402) aux1: 9 (40)

[ 3969.992293] NMEA read. Size 356

[ 3970.662308] NMEA read. Size 127

[ 3971.042257] NMEA read. Size 229

[ 3971.042370] time=211330 hlat=0 llat=-901877080 hlng=-3 llng=1045516473

[ 3971.042452] date=27042010

[ 3971.042499] fix=-1068985344

[ 3971.042534] speed=630 bearing=898

[ 3971.532284] NMEA read. Size 357

[ 3972.322321] NMEA read. Size 357

[ 3972.962719] NMEA read. Size 357

[ 3973.662428] NMEA read. Size 196

[ 3973.662633] time=211334 hlat=0 llat=-901875730 hlng=-3 llng=1045591827

[ 3974.092273] NMEA read. Size 160

[ 3974.092416] date=27042010

[ 3974.092466] fix=-1068985344

[ 3974.092505] speed=626 bearing=881

[ 3974.452405] NMEA read. Size 364

[ 3975.122420] NMEA read. Size 364

[ 3975.832440] NMEA read. Size 365

[ 3976.492351] NMEA read. Size 135

[ 3976.872339] NMEA read. Size 230

[ 3976.872459] time=211338 hlat=0 llat=-901874731 hlng=-3 llng=1045669208

[ 3976.872542] date=27042010

[ 3976.872589] fix=-1068986368

[ 3976.872624] speed=653 bearing=894

[ 3977.262256] ds2746: 3725mV -566mA charge: 72/100 (3132 units)

[ 3977.262279] aux0: 253 (1402) aux1: 10 (40)

[ 3977.372393] NMEA read. Size 366

[ 3977.384313] init: sys_prop: mis-match msg size recieved: -1 expected: 128

[ 3978.102321] NMEA read. Size 366

[ 3978.842358] NMEA read. Size 366

[ 3979.542338] NMEA read. Size 135

[ 3979.902263] NMEA read. Size 232

[ 3979.902383] time=211342 hlat=0 llat=-901875386 hlng=-3 llng=1045749917

[ 3979.902462] date=27042010

[ 3979.902507] fix=-1073704960

[ 3979.902542] speed=685 bearing=911

[ 3980.362275] NMEA read. Size 363

[ 3981.122329] NMEA read. Size 363

[ 3981.274299] init: sys_prop: mis-match msg size recieved: -1 expected: 128

[ 3981.902345] NMEA read. Size 360

[ 3982.642396] NMEA read. Size 276
[Touch CDMA Android Development] kallt_kaffe:
Excuse my ignorance... RIL? Radio Interface Layer? Where do I look for more information?

You would need to compare what is sent with GPS Mode 2 and GPS Mode 1 and try to see if anything is done differently. I think what we have right now in Android, at least on the Kaiser, is what would be GPS mode 2. The problem is when you move slowly it stops updating the postition. It's good for car navigation as it won't "jump around" when parked but for geocaching it is worthless to have it work like that.
[Touch CDMA Android Development] jnadke:
Line 352: (not sure what the value is)

http://androidhtc.git.sourceforge.n...42a17565be4c1169fce9745b8eb3de18;hb=HEAD#l352

Line 406: (This is the GPS mode you are talking about)

http://androidhtc.git.sourceforge.n...42a17565be4c1169fce9745b8eb3de18;hb=HEAD#l406
[Touch CDMA Android Development] kallt_kaffe:
Thanks. I'll try it out.
[Touch CDMA Android Development] dzo:
Actually I think GPSONE=4 just queries the value of the mode, use GPSONE=2 to set mode 2. I wrote an app to change the gps settings here:

xdaforums.com/showpost.php?p=6097236&postcount=30

This probably won't work on kaiser and be careful with it, you can change all sorts of things!
[Touch CDMA Android Development] jnadke:
Actually I thought the values were only 0, 1, 2, and 4? (3 is actually skipped). Probably a bit-wise value.

http://xdaforums.com/showpost.php?p=5803051&postcount=72

The Windows Mobile registry settings are:

0 Standalone

1 MS Based

2 MS Assisted

4 MS Assisted/Hybrid
[Touch CDMA Android Development] Jiggity Janx:
Service Programming

Funny that is mentioned as I just finished testing all GPS Mode values from 0-3. Didn't know that 3 was skipped. What is awesome about the service programming app was that it let me change my IP address to get assisted GPS without doing all the qpst from windows. It wasn't updating the IP as I changed it previously, so I left it alone. Came back to it recently and glad I did. Found that if you change the IP field value to the vzw 216... IP in hex and soft reset the value will stay! From there I tested mutiple values but thus far found Mode = 2 (Mode = 0 worked slightly, 1 and 3 not at all), Capabilities = 255, Port = 8889, IP = D8C68B5C, PDE services = 1, Transport = 0, and Mobile vs PDE = 1 to give me 8+ sats with sometimes all 8 locking. Got 16 sats with approx. 4 locking in my house last night.

As usual, great job DZO! :D
[Touch CDMA Android Development] jnadke:
If you read my post there is no mode 3.

There is a mode 4 (or should be). Mode 4 is network-assisted GPS.

As you can see in the code, it's already being set to the quickest position mode available (mode 4).
[Touch CDMA Android Development] Jiggity Janx:
If you read my post... you can see that the second sentence says that I didn't know there was no mode 3 when testing this BEFORE you chimed in (I was involved in the original diagnostic discussion/testing).

and..

As you can see in my post... the main thing I was bringing out was that the service programming app can be used to replace the painful agps process that the "code" apparantly cannot completely correct.

Thank you again DZO for once again making some people's lives easier.
[Touch CDMA Android Development] kallt_kaffe:
I think I may have isolated the part of the Kaiser GPS code that is causing the freezes. I need a little more time for testing to be sure but the version I'm running now is the best GPS experience I've had on my Kaiser by far.

No freezes and GPS position updates every second.

I propably post a zImage and an NBH later today if it still runs fine.
[Touch CDMA Android Development] kallt_kaffe:
Well, what the heck... I'll put up the version I'm currently running for those who want to try it out.

As usual use a hex-editor to change NBH to suit your Kaiser and Android version. I'm HARET booting at the moment so I haven't tried the NBH.

You will NOT get any satellite bars in GPS software that displays them like "GPS Test" because the code that processes those NMEA sentences has been disabled as I suspect they are troublemaker. I will debug and fix it later but you won't need them to try the new GPS code. It will just look strange to have a fix and see no satellites but it works fine.

EDIT: 3 and a half hours after writing the above it still works excellent. Been using Google Maps, GPS Test and c:geo. Zero issues, zero freezes. Working very well. :) As long as you do not mind losing the satellite bars this version will very likely perform as well as the final version. I will of course bring the satellite bars back once I fixed the broken code.

EDIT2: Still not a single freeze after over 6 hours.
[Touch CDMA Android Development] jfg69:
This is based on 2010-4-26?

Thanks for all the work you guys are putting into this! Gonna give it a try on my Tilt (KAIS100 version.)