• 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

when building im getting this error
host C: mkbootimg <= system/core/mkbootimg/mkbootimg.c
host C: libmincrypt <= system/core/libmincrypt/rsa.c
In file included from /usr/include/inttypes.h:26:0,
from system/core/include/mincrypt/rsa.h:31,
from system/core/libmincrypt/rsa.c:28:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directoryIn file included from /usr/include/stdio.h:28:0,
from system/core/mkbootimg/mkbootimg.c:18:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.

compilation terminated.
make: *** [out/host/linux-x86/obj/EXECUTABLES/mkbootimg_intermediates/mkbootimg.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [out/host/linux-x86/obj/STATIC_LIBRARIES/libmincrypt_intermediates/rsa.o] Error 1
 
Run In your working directory,
Code: 
make clean && make clobber 
repo sync -j4
. build/envsetup.sh
lunch
press choice 5
make bacon -j(how ever many number of cores you have)
Sometimes you can get caught syncing when they are updating stuff.
Hope this helps.
 
Man, our data seems good going down.

There are definitely some fragile maneuvers needed around SETUP_DATA_CALL due to incompatibility of the RIL parcel between versions - different handling is needed for RILv3, RILv4, etc.. Could I ask you guys to take your same build and throw in the hex dump of the RIL packets coming in? That would be around line 565 in RIL.java - dump "length" bytes of "buffer" (oh, and prepend with "IN:" or something)...

If you're interested, I'm looking at hardware/ril/libril/ril.cpp to try and trace further back where the error we're getting is coming from. My theory is that some system property or something is causing a version mismatch .. not sure though, since I think the type/serial/error fields are common to all versions, and we're getting an error return.
 
I'll get to this tonight. Just to confirm, this is what I'll insert:

String Incoming = byteArrayToHexString(buffer);
Log.v(LOG_TAG, "IN: " + Incoming);

into line 542 of the file:

https://github.com/Whyzor/android_f.../java/com/android/internal/telephony/RIL.java

So it'll look like:

Code: 
length = readRilMessage(is, buffer);

String Incoming = byteArrayToHexString(buffer);
Log.v(LOG_TAG, "IN: " + Incoming);

if (length < 0) {
    // End-of-stream reached
    break;
}
 
On second thought, this data probably wont help much... the parcel in question doesn't have any data, only the three ints
 
konspiracy said:
Run In your working directory,
Code: 
make clean && make clobber 
repo sync -j4
. build/envsetup.sh
lunch
press choice 5
make bacon -j(how ever many number of cores you have)
Sometimes you can get caught syncing when they are updating stuff.
Hope this helps.
Click to expand...
didnt seem to fix :/
 
joemossjr said:
didnt seem to fix :/
Click to expand...

Well, I can tell you that I deleted all of my local files and resynced everything from Github yesterday and was able to build successfully. So everything on the repo is definitely working.

It definitely looks like either you missed a step when you were setting up your environment or your repo sync did not finish successfully.

So I suggest that you go over the directions again and make sure you did not miss a step.
 
Been digging around... CM7 successfully brings up rmnet0, which is what SETUP_DATA_CALL should do. So I thought I'd look into any differences around rmnet0. It should be provided by the same kernel code, and we're running the same rild and proprietary qcom ril libraries. Thought it might then be permissions - those seem to be good on all the files I thought to check (in /sys and /proc/sys and /dev/oncrpc). How else could that code and those rmnet devices be affected? System properties is one way (I'd like to create a build that dumps whenever a property is requested, and hopefully by who - that possible?). Linkage to changed dynamic libraries is another - ugh is all I can say about that. Someone trying to bring up some mozilla OS on a galaxy S2 found that their rild was crashing during SETUP_DATA_CALL due to an atoi in their libc that barfed on a NULL pointer. But our rild isn't crashing (I checked). So investigating that might be a pain, since a crash isn't involved - subtle libc data return differences causing an error in the closed source library would be ugly. One of the android libraries would be more likely than libc, but still unlikely in my mind.

Finally, /sys configuration and module parameters. (Or, I *think* finally - any ideas for other sources of runtime differences?) All the relevant configuration in /proc/sys/net/ipv4/*/rmnet0 was identical. But I did finally find a difference in /sys/class/net/rmnet0 ... "address" and "broadcast" were filled out in my CM9 build, but blank for my working miui build. Flags was different (0x1 in MIUI, 0x1003 in CM9), as was type (530 in MIUI, 1 in CM9).

These differences may be red herrings, but I'm running out of ideas about how the runtime could change.

UPDATE: type corresponds to ip_arp.h types ... 1 is ethernet, 530 is "raw IP" .. Not sure if this could affect things yet, though.
 
We may be able to glean more information about what rild/librils are doing by injecting a lot of printks in the msm_rmnet driver. The reason the type is different is because the ril library isn't issuing an ioctl to set the device to raw ip mode in CM9, and it is in working builds (dmesg | grep rmnet). One more layer of the onion :) .. Now, why isn't it? No idea. It doesn't seem to ever call into the driver, so perhaps printks wouldn't help.
 
Just a suggestion but when it's released to the public I think all contributor's should be able to post donation links. Tickerguy didn't do this because he did it with isaac and they built separate roms. As the work isn't even ours (we pulled from isaac and he disappeared). I think it would be fair for anybody who fixed something to get credit and next to there name a donation link. I think this a great idea because everbody gets credit for helping and if users want to donate it doesn't all go to one person. This is just an idea to think about and it has no negative side for any of the devs so it's a win win situation :).
 
Ok, next idea - I did an "strace -f /system/bin/rild" and got a lot of useful information, especially considering I didn't disable the originally spawned rild (which init respawns if you kill it). So I have to go for a time, but if someone could do this on a CM7 and a CM9 build, it'd be very useful information: easy one - add "logwrapper" to the launch of rild so that it's stdout and stderr goes to logcat - then do a regular logcat to watch what rild says (I think logwrapper would redirect to the regular log, not -b radio).

Better one: compile and use rild.cpp from the sources, not the prebuilt one. It's a simple wrapper that should just link against the proprietary libril, so hopefully it'll work (though I seem to remember some commit that mentioned trying that). Change the #if 0 line to cause it to make it's own socket rather than get the one init creates. Comment out the running of rild in init.rc... Finally, adb shell in and run "strace -f /system/bin/rild > /sdcard/rild_strace" .. then toggle the radio and the output should be useful to compare between CM7 and CM9.

Actually, I don't know how deep the logcat buffer is, or if you can make it deeper, but an easier way to get the strace if it wouldn't overwhelm logcat would be to simply change the ril-daemon line in init.rc to "service ril-daemon /system/bin/logwrapper /system/xbin/strace -f /system/bin/rild" ... I guess just make sure the logcat is running and "waiting for device" as the device boots to avoid buffer wrapping. This is easier and allows us to not change the rild. If some folks could do this, that'd be great - I might be able to later but it may be a while. We should be able to see where the nonworking CM9 deviates in it's operation as it decides not to issue those ioctls (which will show up in strace).
 
Ummm... say what? :) give me exact code & where to insert & I'll rebuild a CM7 with the extra logging. Otherwise I'm not following your Einsteinian logic. ;)
 
Gent's I am finally back on the scene now that my power house arrived (Quad Core Xeon with 4GB of Ram). I am going to mostly be focused on the kernel since I have picked up a few o'reilly driver/kernel books in the past few days. It's good to see we are making progress!
 
Whyzor said:
Ummm... say what? :) give me exact code & where to insert & I'll rebuild a CM7 with the extra logging. Otherwise I'm not following your Einsteinian logic. ;)
Click to expand...

Lol, sorry.extra detail if you're curious. Just need to replace the ril-daemon line in init.rc in rootfs with the one above that has strace and logwrapper.
 
PerkinsII said:
Just a suggestion but when it's released to the public I think all contributor's should be able to post donation links. Tickerguy didn't do this because he did it with isaac and they built separate roms. As the work isn't even ours (we pulled from isaac and he disappeared). I think it would be fair for anybody who fixed something to get credit and next to there name a donation link. I think this a great idea because everbody gets credit for helping and if users want to donate it doesn't all go to one person. This is just an idea to think about and it has no negative side for any of the devs so it's a win win situation :).
Click to expand...

That shouldn't be a problem to dedicate a credits post like I have in post 3 of this thread.
 
g60madman said:
I was doing some reading last night and ran into some information. This looks to be the fix for our camera

https://docs.google.com/View?id=dht...Secondary_Camera_Support_181_9212664796505123

also it maybe possible to incorporate some of the code sections for wifi/3g
Click to expand...

Nothing there that really helps us for networking... Is this how TG got the camera working? Or did he use the new, native gingerbread support? It would make sense that VM would use Sprint's apis to get the FFC to work on froyo I guess.
 
g60madman said:
I was doing some reading last night and ran into some information. This looks to be the fix for our camera

https://docs.google.com/View?id=dht...Secondary_Camera_Support_181_9212664796505123

also it maybe possible to incorporate some of the code sections for wifi/3g
Click to expand...

Unfortunately, that's just the API that exposes certain functions contained in the compiled binaries so that apps can call them. It's not actually the source code to the actual compiled files that we need to make it easy in fixing the camera/wifi/3g, etc.
 
mantera said:
Unfortunately, that's just the API that exposes certain functions contained in the compiled binaries so that apps can call them. It's not actually the source code to the actual compiled files that we need to make it easy in fixing the camera/wifi/3g, etc.
Click to expand...

Fail :P
 
You must log in or register to reply here.
Back
Top Bottom