Root [DEV] Continuing Triumph ICS Development

[tickerguy]

T-Mobile is working very well.... and is cheap ;-)

Incidentally on the GPS the "gotcha" is that there's an LNA you need to poke to turn on or it won't work (and off when you're done.) It will appear to come up but never see any satellites. Let me know if you need to know where that is; it took me a good while to find it, and the driver has to be in the kernel for it too. It's an ioctl call and thus has to be made from the C/C++ code; you can't make ioctl calls directly from Java.

 

[mantera]

T-Mobile is working very well.... and is cheap ;-)

Incidentally on the GPS the "gotcha" is that there's an LNA you need to poke to turn on or it won't work (and off when you're done.) It will appear to come up but never see any satellites. Let me know if you need to know where that is; it took me a good while to find it, and the driver has to be in the kernel for it too. It's an ioctl call and thus has to be made from the C/C++ code; you can't make ioctl calls directly from Java.

If you got time to give a little more detail, it would be great and certainly make it easier so we have a place to start.

Also, if you could elaborate on what you mean by "and the driver has to be in the kernel for it too". It would help to see if that's in the 3.0 kernel already.

 

[PerkinsII]

Can anybody help with this error??

Spoiler

 

[konspiracy]

Can anybody help with this error??

Spoiler

I believe it because you have to objects saying they want to make the same item. You have to tell one of them not too make that file.

 

[PerkinsII]

I believe it because you have to objects saying they want to make the same item. You have to tell one of them not too make that file.

How would I code that?? In this commit tickerguy says you have to turn the others off, but I don't know which ones. https://github.com/tickerguy/qcom_gps/commit/881c0f1c8223e66b77327cbf24c321e7a7492b36

 

[konspiracy]

How would I code that?? In this commit tickerguy says you have to turn the others off, but I don't know which ones. https://github.com/tickerguy/qcom_gps/commit/881c0f1c8223e66b77327cbf24c321e7a7492b36

search under hardware folder for loc_api and edit the android.mk

 

[PerkinsII]

search under hardware folder for loc_api and edit the android.mk

Sorry for being such a noob, but what do I edit. I am pretty new to linux so you will have to explain in more depth.

 

[progmanos]

I was able to fix the ril_class problem by creating a special case for our device. So, now I am able to get the PRL, MIN, and phone number to load in the system. I am currently debugging data. I will update my repo when I am done.

 

[mantera]

Nice!

 

[Raptor5150]

I was able to fix the ril_class problem by creating a special case for our device. So, now I am able to get the PRL, MIN, and phone number to load in the system. I am currently debugging data. I will update my repo when I am done.

so this means data should be working?

 

[hotalings]

so this means data should be working?

He's debugging data, he gets the phone to reads the info, but still needs to get data functional, seems really close though

 

[Whyzor]

I was able to fix the ril_class problem by creating a special case for our device. So, now I am able to get the PRL, MIN, and phone number to load in the system. I am currently debugging data. I will update my repo when I am done.

I thought this info was already working since phone calls was working before? Or was it using "free" VM airtime because it couldn't find specific subscriber info?

Also not sure if you're running with the APN script enabled already or not, but it's another component TG coded up for CM7:

https://github.com/Whyzor/android_d...mmit/4bbe5d877aecf338b9b0ee7175695c1b03f07349

 

[yumbrad]

Thanks TG! I had ported all of your changes, and ... I seem to have all of these as I double check. Maybe you have an idea why the radio is still not coming up - unfortunately, the closed RIL/baseband is returning an error when I finally get to issuing a "SETUP_DATA_CALL" request. I haven't gone byte-by-byte to examine what I send down, but that's what I was considering next - putting a hexdump in the lowest layer right when it gets sent down to the RIL in both a working CM7 and my CM9 - because the higher level "<" and ">" (in/out RIL request) messages seem to be the same at this point. In other words, I've got it behaving just like your CM7 code, but the RIL returns an error to SETUP_DATA_CALL. I even checked the various libril and rild binaries - the rild in my working gingerbread MIUI was a bit bigger, and I tried that, but same behavior.

Any ideas? Am I going to have to bite the bullet and go byte-by-byte?

Ok, here's the deal.

To get the RIL to come up you need to deal with the following problems:

...

 

[mantera]

I thought this info was already working since phone calls was working before? Or was it using "free" VM airtime because it couldn't find specific subscriber info?

Also not sure if you're running with the APN script enabled already or not, but it's another component TG coded up for CM7:

https://github.com/Whyzor/android_d...mmit/4bbe5d877aecf338b9b0ee7175695c1b03f07349

Yeah, I just haven't pulled these commits yet since I wasn't sure if they were actually needed and was waiting on confirmation from yumbrad or progmanos who were working on the ril data stuff. If yumbrad or progmanos, thinks that they are definitely needed for the stuff they're working on, then I can certainly push them late tonight.

 

[mantera]

Thanks TG! I had ported all of your changes, and ... I seem to have all of these as I double check. Maybe you have an idea why the radio is still not coming up - unfortunately, the closed RIL/baseband is returning an error when I finally get to issuing a "SETUP_DATA_CALL" request. I haven't gone byte-by-byte to examine what I send down, but that's what I was considering next - putting a hexdump in the lowest layer right when it gets sent down to the RIL in both a working CM7 and my CM9 - because the higher level "<" and ">" (in/out RIL request) messages seem to be the same at this point. In other words, I've got it behaving just like your CM7 code, but the RIL returns an error to SETUP_DATA_CALL. I even checked the various libril and rild binaries - the rild in my working gingerbread MIUI was a bit bigger, and I tried that, but same behavior.

Any ideas? Am I going to have to bite the bullet and go byte-by-byte?

I seem to recall that TG saying back in the cm7 days that he had to do something similar to trace through the stacks to see wth was going on.

But it could just be my imagination.

 

[mantera]

Here's the current status of the deving as far as I can tell from what's being posted:

- yumbrad and progmanos are working on getting ril data working.
- PerkinsII is working on gps.
- I am looking into the camera and 3.0 kernel (whether either pans out... can't promise anything)

So everyone, just to do a little planning ahead. When yumbrad and/or progmanos gets data working, I think we have enough to release an alpha 1 version.

If no one objects, I'll throw that up there for everyone when that happens.

Let me know what you all think.

Thanks.

 

[konspiracy]

Whats up with wifi?
That would be great while we are working on data....

 

[mantera]

Whats up with wifi?
That would be great while we are working on data....

I have not had time to look into that at all yet. I don't know if anyone else has started. However, I do know that edowar doesn't have that working in his release either.

 

[konspiracy]

Here's the current status of the deving as far as I can tell from what's being posted:

- yumbrad and progmanos are working on getting ril data working.
- PerkinsII is working on gps.
- I am looking into the camera and 3.0 kernel (whether either pans out... can't promise anything)

So everyone, just to do a little planning ahead. When yumbrad and/or progmanos gets data working, I think we have enough to release an alpha 1 version.

If no one objects, I'll throw that up there for everyone when that happens.

Let me know what you all think.

Thanks.

I think since data isnt working if we could get wifi in the alpha 1 then that would make a smoother experience. More user friendly and such.

I mean we dont have a way to get data to the device besides usb.

 

[mantera]

I think since data isnt working if we could get wifi in the alpha 1 then that would make a smoother experience. More user friendly and such.

I mean we dont have a way to get data to the device besides usb.

Right, that's why I said "When yumbrad and/or progmanos gets data working" ...

 

[Raptor5150]

I think since data isnt working if we could get wifi in the alpha 1 then that would make a smoother experience. More user friendly and such.

I mean we dont have a way to get data to the device besides usb.

yes please!

 

[konspiracy]

Right, that's why I said "When yumbrad and/or progmanos gets data working" ...

Alright ya srry I see what your saying.
Ya I see no problem as long as we have data.

I mean I have noticed that if I leave the phone alone it will automatically reboot about every hour or so.
But I do think that it has something to do with the radio being in its current condition.
Also after I make a call the screen doesnt like to light up again and it takes awhile to turn back on.

 

[progmanos]

I thought this info was already working since phone calls was working before? Or was it using "free" VM airtime because it couldn't find specific subscriber info?

Also not sure if you're running with the APN script enabled already or not, but it's another component TG coded up for CM7:

https://github.com/Whyzor/android_d...mmit/4bbe5d877aecf338b9b0ee7175695c1b03f07349

I'm not sure how it was working before, but the PRL, MIN, and phone number were not loaded.

Yes, I am running with the APN script.

 

[Whyzor]

I'm not sure how it was working before, but the PRL, MIN, and phone number were not loaded.

Yes, I am running with the APN script.

Interesting. I remember receiving a phone call in ICS and it went pretty smoothly. so maybe CM9's framework needs less patching than CM7 did. So once the RIL data is working, it may be worthwhile to trim down on the framework patches (so future CM9 updates don't break things), I'm guessing there are some redudant CDMA fixes in ICS now.

 

[Whyzor]

BTW, not sure if this will help us, but since TG's fixes piggyback off of SamsungRIL, here's a recent ICS update for another Sprint device, maybe it'll reveal clues for us.

https://github.com/CyanogenMod/andr...mmit/45a18c1f0645e036fcb00623c1be01b2f13228b9