• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root [DEV] Continuing Triumph ICS Development

Ok, here's the deal.

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

1. The Qualcomm code likes to CLAIM it has a RUIM in it that is not ready. A RUIM is a SIM for CDMA phones, basically. The problem is that there is no socket for that in the phone at all -- in other words, it doesn't exist. This will cause the phone to be torn down and reset when it comes up the stack. Needless to say that's bad.

To fix this you have to change the base code. In CM7 I patched RIL.java around line 2020 with the radio state (look in ril.h for the defines) for State 2, and if the class is Triumph I change the state to RadioState.NV_READY instead of RadioState.SIM_NOT_READY.

This same code is in the ICS build and must be fixed.

2. In the routine processUnsolicited there are a number of upcalls that have to be there. It appears that ICS picked up all but one. Add that one (VOICE_RADIO_TECH_CHANGED)

3. RILConstants appears to be fixed, so you should be ok there.

4. cdma/CdmaServiceStateTracker.java has a BUNCH of changes that have to be pulled over. You're going to have to go through this code in the ICS tree as it looks materially different. One place I know you have to fix is in EVENT_POLL_STATE_CDMA_SUBSCRIPTION -- you need to add the code from my CM7 build that checks for a Triumph and if so DOES NOT attempt to pull the PRL from the upcall packet -- it's missing on the Triumph and if you reference that 5th element in the array the code will fault and blow up. What I did here temporarily was to stuff a "fake" PRL in the data table.

5. Same file, look at CASE_SIM_LOCKED_OR_ABSENT. This is one of those async upcalls that on the Triumph CANNOT be allowed to fall through to the next state (it does in the base code.) If it does, you're dead as the code then turns the radio off! This is generated from the RUIM message; see what I did in the CM7 build to fix this (basically ignore it if it's a Triumph)

6. The poll for the ACTUAL PRL is in the default case in this same statement. Again, see my CM7 code, same file, and look at the other PRL related changes to that same file (they're not in the ICS version at all.)

That should get the RIL to come up. You NEED all of the radio parameters (including the PRL, MEID and such) to load before Android will allow a data connection to start. Thus, all this has to be fixed for data to work.

Once you have that you get to have fun with MMS, which will also require patching......

There's probably more I'm missing but this should get you either working or damn close.
 
Upvote 0
Ok, here's the deal.

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

1. The Qualcomm code likes to CLAIM it has a RUIM in it that is not ready. A RUIM is a SIM for CDMA phones, basically. The problem is that there is no socket for that in the phone at all -- in other words, it doesn't exist. This will cause the phone to be torn down and reset when it comes up the stack. Needless to say that's bad.

To fix this you have to change the base code. In CM7 I patched RIL.java around line 2020 with the radio state (look in ril.h for the defines) for State 2, and if the class is Triumph I change the state to RadioState.NV_READY instead of RadioState.SIM_NOT_READY.

This same code is in the ICS build and must be fixed.

2. In the routine processUnsolicited there are a number of upcalls that have to be there. It appears that ICS picked up all but one. Add that one (VOICE_RADIO_TECH_CHANGED)

3. RILConstants appears to be fixed, so you should be ok there.

4. cdma/CdmaServiceStateTracker.java has a BUNCH of changes that have to be pulled over. You're going to have to go through this code in the ICS tree as it looks materially different. One place I know you have to fix is in EVENT_POLL_STATE_CDMA_SUBSCRIPTION -- you need to add the code from my CM7 build that checks for a Triumph and if so DOES NOT attempt to pull the PRL from the upcall packet -- it's missing on the Triumph and if you reference that 5th element in the array the code will fault and blow up. What I did here temporarily was to stuff a "fake" PRL in the data table.

5. Same file, look at CASE_SIM_LOCKED_OR_ABSENT. This is one of those async upcalls that on the Triumph CANNOT be allowed to fall through to the next state (it does in the base code.) If it does, you're dead as the code then turns the radio off! This is generated from the RUIM message; see what I did in the CM7 build to fix this (basically ignore it if it's a Triumph)

6. The poll for the ACTUAL PRL is in the default case in this same statement. Again, see my CM7 code, same file, and look at the other PRL related changes to that same file (they're not in the ICS version at all.)

That should get the RIL to come up. You NEED all of the radio parameters (including the PRL, MEID and such) to load before Android will allow a data connection to start. Thus, all this has to be fixed for data to work.

Once you have that you get to have fun with MMS, which will also require patching......

There's probably more I'm missing but this should get you either working or damn close.

Off topic kinda, but would this work to get data working on the Andro-ID rom also?
 
Upvote 0
Mantera I also noticed that in your repo we pull gallery 1 and 2??? https://github.com/mantera/android/blob/ics/default.xml Maybe that's is why the new gallery doesn't work???

yeah, I wasn't sure what the difference was between the 2 and haven't really spent any time looking into it. I suppose we don't need 2 galleries. I'll dump the 1 from the manifest.

Has anybody tried the ics music app instead of the gingerbread one we have now https://github.com/CyanogenMod/android_packages_apps_Music/tree/ics

How would I pull that to try it (Please keep in mind I am a github noob)

We should already be pulling the ics branch since it's the default branch on that repo.
 
Upvote 0
yeah, I wasn't sure what the difference was between the 2 and haven't really spent any time looking into it. I suppose we don't need 2 galleries. I'll dump the 1 from the manifest.



We should already be pulling the ics branch since it's the default branch on that repo.

Seen the same gallery error on touchpad with cm9 it has two gallerys as well .
 
Upvote 0
Ok, here's the deal.

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

1. The Qualcomm code likes to CLAIM it has a RUIM in it that is not ready. A RUIM is a SIM for CDMA phones, basically. The problem is that there is no socket for that in the phone at all -- in other words, it doesn't exist. This will cause the phone to be torn down and reset when it comes up the stack. Needless to say that's bad.

To fix this you have to change the base code. In CM7 I patched RIL.java around line 2020 with the radio state (look in ril.h for the defines) for State 2, and if the class is Triumph I change the state to RadioState.NV_READY instead of RadioState.SIM_NOT_READY.

This same code is in the ICS build and must be fixed.

2. In the routine processUnsolicited there are a number of upcalls that have to be there. It appears that ICS picked up all but one. Add that one (VOICE_RADIO_TECH_CHANGED)

3. RILConstants appears to be fixed, so you should be ok there.

4. cdma/CdmaServiceStateTracker.java has a BUNCH of changes that have to be pulled over. You're going to have to go through this code in the ICS tree as it looks materially different. One place I know you have to fix is in EVENT_POLL_STATE_CDMA_SUBSCRIPTION -- you need to add the code from my CM7 build that checks for a Triumph and if so DOES NOT attempt to pull the PRL from the upcall packet -- it's missing on the Triumph and if you reference that 5th element in the array the code will fault and blow up. What I did here temporarily was to stuff a "fake" PRL in the data table.

5. Same file, look at CASE_SIM_LOCKED_OR_ABSENT. This is one of those async upcalls that on the Triumph CANNOT be allowed to fall through to the next state (it does in the base code.) If it does, you're dead as the code then turns the radio off! This is generated from the RUIM message; see what I did in the CM7 build to fix this (basically ignore it if it's a Triumph)

6. The poll for the ACTUAL PRL is in the default case in this same statement. Again, see my CM7 code, same file, and look at the other PRL related changes to that same file (they're not in the ICS version at all.)

That should get the RIL to come up. You NEED all of the radio parameters (including the PRL, MEID and such) to load before Android will allow a data connection to start. Thus, all this has to be fixed for data to work.

Once you have that you get to have fun with MMS, which will also require patching......

There's probably more I'm missing but this should get you either working or damn close.

Thanks TG.. everyone here i'm sure thanks you for the help.. How's T-Mobile been treating you?
 
Upvote 0
Upvote 0
Could we use this commit for gps https://github.com/edowar/android_hardware_msm7k/commit/1a60593adc1ddd56ad22fc637bc7af911092e969??? I am pretty sure in our boardconfig.mk (whichever file it is there are a couple) links to the same gps.

Also here is a qualcomm camera repo for ics https://github.com/freexperia/android_hardware_qcom_camerahal

I would say try it and find out...

As for the camera, I've been working on that off and on; there's more to it than just that. But try and see if it works for you. Perhaps I'm doing something wrong.
 
Upvote 0
Ok, here's the deal.

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

1. The Qualcomm code likes to CLAIM it has a RUIM in it that is not ready. A RUIM is a SIM for CDMA phones, basically. The problem is that there is no socket for that in the phone at all -- in other words, it doesn't exist. This will cause the phone to be torn down and reset when it comes up the stack. Needless to say that's bad.

To fix this you have to change the base code. In CM7 I patched RIL.java around line 2020 with the radio state (look in ril.h for the defines) for State 2, and if the class is Triumph I change the state to RadioState.NV_READY instead of RadioState.SIM_NOT_READY.

This same code is in the ICS build and must be fixed.

2. In the routine processUnsolicited there are a number of upcalls that have to be there. It appears that ICS picked up all but one. Add that one (VOICE_RADIO_TECH_CHANGED)

3. RILConstants appears to be fixed, so you should be ok there.

4. cdma/CdmaServiceStateTracker.java has a BUNCH of changes that have to be pulled over. You're going to have to go through this code in the ICS tree as it looks materially different. One place I know you have to fix is in EVENT_POLL_STATE_CDMA_SUBSCRIPTION -- you need to add the code from my CM7 build that checks for a Triumph and if so DOES NOT attempt to pull the PRL from the upcall packet -- it's missing on the Triumph and if you reference that 5th element in the array the code will fault and blow up. What I did here temporarily was to stuff a "fake" PRL in the data table.

5. Same file, look at CASE_SIM_LOCKED_OR_ABSENT. This is one of those async upcalls that on the Triumph CANNOT be allowed to fall through to the next state (it does in the base code.) If it does, you're dead as the code then turns the radio off! This is generated from the RUIM message; see what I did in the CM7 build to fix this (basically ignore it if it's a Triumph)

6. The poll for the ACTUAL PRL is in the default case in this same statement. Again, see my CM7 code, same file, and look at the other PRL related changes to that same file (they're not in the ICS version at all.)

That should get the RIL to come up. You NEED all of the radio parameters (including the PRL, MEID and such) to load before Android will allow a data connection to start. Thus, all this has to be fixed for data to work.

Once you have that you get to have fun with MMS, which will also require patching......

There's probably more I'm missing but this should get you either working or damn close.

Hmmm... OT... in MIUI, I had everything working but the radio. With this info, maybe I can get that working finally...
 
Upvote 0
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones