• 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

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 you should wait, really nothing is working. Once there is someway to get data on the phone besides usb (wifi &/or data) it would be usable as a daily for some people. I mean by waiting to get some type of connection to the internet on the phone more people will try for an extended period of time. Where as if you released it now it would be flashed then reflashed with froyo or cm7. Also, the more things that don't work the more questions you get for example: How come wifi doesn't work???, How come I can't connect to the internet???, How come most things don't work??, etc. But hey that's just my opinion maybe the rest of you think differently.

*Edit made the same mistake as konspiracy, I didn't read mantera's post all the way through. I still think we should wait longer, but getting some type of data should suffice for now.
 
Upvote 0
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 updated my ubuntu 10.10 workstation to the linux 3.0 kernel and there was a hell of a speed improvement! :D will that work the same way with the phones if you can get it in a working order? if so this device may put the galaxy nexus in its place lol :p
 
Upvote 0
i updated my ubuntu 10.10 workstation to the linux 3.0 kernel and there was a hell of a speed improvement! :D will that work the same way with the phones if you can get it in a working order? if so this device may put the galaxy nexus in its place lol :p

Look into the zen kernel
I just compiled one myself for 11.10
Its the one with the BFS scheduler and its already on kernel version 3.2....
I also bumped the tick rate to 10000 wich seems to help things be really really smooth.

I just need to recompile it with the modules I only need and take out all the other crap I dont use.
I mean when I self compiled a kernel for my laptop (crunchbang not ubuntu) it was still slow for building things (its a single core) but everything else was much much smoother.

I also noticed there is a zen kernel for android, but I think each phone provider builds kernels a little differently right?
 
Upvote 0
  • Like
Reactions: zajrik and Whyzor
Upvote 0
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.

Definitely - CM9/ICS incorporates quite a few (sometimes in a more general way) of the RIL fixes we needed.
 
Upvote 0
Wifi is looking like it may be a pain. Edowar is stuck and is hoping that we figure it out -> xda-developers - View Single Post - Alpha1 AOSP ICS Rom for Huawei x6 and other FB0 devices

It looks like there may have been some changes with WiFi on ICS. For example, a country code needs to be set in Secure System Settings. See [APK] WiFix - Fixes regional Wi-Fi problems in IceCream Sandwich - xda-developers But it is more than just that... I like challenges so I will try and look into it when I find time
 
Upvote 0
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 can think of three possibilities since the calls seem to be the same in TG's CM7 and ours:

1. There is some byte-level difference in the the RIL requests we send down before SETUP_DATA_CALL.
2. There is some important property difference that rild / the ril libraries (which are the same prebuilt ones) are picking up. I went through looking for ril/telephony related things that would matter in build.prop and I didn't think so, but something has to be causing rild to behave differently.
3. There is some *hidden* property that changed (i.e. a system property that wasn't set in CM7 or our CM9, but changed default values).

Unfortunately, these are now at the point where they are time consuming and painful to check out. I've got a day job and 4 kids :) .. If someone wants to check out #1, they need to capture a "adb logcat -b radio \*:v > logfile.cm7" from a working CM7 and then do it again with our current build with my or programos (assuming he's got the fixes ported as I have) changes. But first, in both, you'd need to go to RIL.java and add something to dump out exactly what we are sending down to the RIL. At the point where it sends it down - s.getOutputStream().write(data) - at around line 340 or so - add a hexdump of the data. Here's a function to convert the "byte[] data" to a string, then just Log.v(LOG_TAG, stringReturnedFromThatFunction);

Code:
public static String byteArrayToHexString(byte[] b) {
    StringBuffer sb = new StringBuffer(b.length * 2);
    for (int i = 0; i < b.length; i++) {
      int v = b[i] & 0xff;
      if (v < 16) {
        sb.append('0');
      }
      sb.append(Integer.toHexString(v));
    }
    return sb.toString().toUpperCase();
  }

Then capture logs from both, and go through those hexdumps byte-by-byte, comparing. We'd need to figure out whether any differences are important.

#2, we could make EVERY thing the same, even the things that don't seem to matter, as long as thing still works. #3, somebody needs to google default properties, and figure out what changed from CM7/gingerbread to CM9/ICS.
 
Upvote 0
  • Like
Reactions: lifeblows10
Upvote 0
Just a heads up, two recent commits to SamsungRIL went in CM9, should probably re-sync to upstream, maybe re-capture the hex-dump too in case anything changed.

https://github.com/CyanogenMod/andr...mmit/8a9f3161d983b131a857e58141c4e7ff69a94fea

https://github.com/CyanogenMod/andr...mmit/57dd8c88d0821fb2839a8c43d3c23a932d4e0496

Though related to our RIL in that we have to do a few of the same things and we can see how they do them, these commits won't affect our operation since we don't and can't run the SamsungRIL.. Unfortunately the underlying RIL implementation is different, and based on ppp (wow, back to BBS dialup days), so our problems with getting the right response back from the native RIL code probably won't be helped much by looking at their ril. The underlying radio technology is the same (CDMA), but the native code between java and the radio is very different. Definitely worth looking into any obvious CM7 -> CM9 differences though to see if we're missing something.
 
Upvote 0
Here's the hex data dump for CM7: https://gist.github.com/1715393 (changed MDN & MIN to protect my privacy :)) Did a couple of 3G data toggles & also airplane mode. To make sure it captured enough data.

logcat -d -b radio > ril_cm7.txt

& also toggled wifi on & off and a

logcat -d > cm7.txt

For anyone interested in comparing a working logcat of wifi in CM7.

I'm interested in hearing what you find, even if it's inconclusive it may provide clues for others.
 
Upvote 0
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

Having these settings enabled wasn't going to hurt anything so I re-enabled them and pushed them up so we're all on the same page.

I also cleaned up our config files a little bit.
 
  • Like
Reactions: bradhoschar
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