Related
Has anyone been able to really utilize the tool chain that comes with the android source. I'm wanting to play with cross compiling for android some. I found a wrapper someone wrote in perl, but I've only had limited success using it. For more complex things that use build systems I've not been able to get anything to compile.
Would it just be easier to use another toolchain with something like uclibc?
What do JF and some others use to build stuff like busybox?
Hello,
Do you know that it is possible to enable JIT in Dalvik JVM?
http://groups.google.com/group/0xlab-devel/browse_thread/thread/1edef26f4e5b7427
According to the Dalvik developers it is possible to backport JIT to the Donut tree and gain ...1.74x in performance!!! It would be awesome if someone could spend some time and create a ROM with that patches applied.
Anyone?
Karol
I think you misread somewhere.
It is a *new feature* they are *adding in*. The current JIT in AOSP/master is in development (i.e. incomplete). You can play with it if you want, but you should consider this to be a future new feature that will be added to official builds.
Well, I though that this is xda developers forum, place where even experimental Android features are welcome (vide extra memory hack and others...
And while English is not my native language I doubt that I have misread it. The current master tree ALREADY contains JIT implementation PLUS there are patches which allow using it in the Donut tree. So even though it is experimental it is worth checking out because it apparently it can be compiled and tested...
I would do this by myself, but since a week or so I am unable to update my donut tree, I am getting "fatal: The remote end hung up unexpectedly" messages
The current master branch in AOSP is eclair. If you use repo to sync the AOSP source, then build, the branch it pulls out (according to the output from envsetup and the lunch menu I receive) is eclair (2.0). I doubt that the donut branch has the code for the Dalvik JIT.
It *may* be possible to backport it to donut (1.6), but why when 2.0 is running on the Dream except for some AV/codec issues without problem?
Let me quote developers behind JIT in Dalvik....
NOTE: the results were measured in Donut based environment. That is,
there are some changes for Eclair backport to Donut without replacing
the libcutils and bionic, which were modified a lot in Eclair.
If you would like to introduce Eclair's Dalvik VM in Donut based
products (especially for 3rd-party components compatibility), feel
free to apply the attached patches and rebuild Android.
Here are the instructions:
# cd android-donut
# mv dalvik dalvik-orig
# . build/envsetup.sh
# git clone git://android.git.kernel.org/platform/dalvik.git
# cd dalvik
# git apply dalvik-eclair-backport.patch
# mm
# cd ../frameworks/base
# git apply frameworks-base-eclair-backport.patch
# mm -B
# cd ../../
(Do copy out~system to your target.)
Click to expand...
Click to collapse
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...
karolbe said:
Let me quote developers behind JIT in Dalvik....
This is from the link I pasted in my first message...
And why? Well, because there will be no full Eclair build for G1 until HTC releases some closed source components which currently doesn't work with the Eclair kernel. So this is still worth trying out, I doubt that those components will be released in near future...
Click to expand...
Click to collapse
Ah, I stand corrected. It looks like it is indeed workable to get 1.6 with a JIT Dalvik. However, once HTC (or Qualcomm) releases the needed A/V drivers, 2.0 will be fully functional on the Dream. But, this might be nice in the interim.
Is that just the Eclair Dalvik version, or is it also the JIT-enabled Eclair Dalvik?
There /is/ a difference between the two.
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Yeah, I tried it out, and the phone seemed to be less responsive. When I tried to install an app the phone rebooted, and now it seems to be booting to a certain point and then shutting down again. Nice progress though.
cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Memory Hog.
That's what I was afraid off, that a JIT would hog memory. And if there's 1 thing that my G1 is really short of, it's memory. RAM for running applications. So no please no more memory hoggging on my G1! ;-)
I'm afraid that memory hogging is kind of unavoidable for a JIT.
Just my 2ct.
--Tim
Anyone tried this with the memhack and CompCache running?
EDIT: Running it myself now. Can't see any lagginess; everything seems to be running quite snappily. Going full-time with it now.
I haven't done any java stuff for a while, so I might be off. Anyways, since this is a vm library change, I assume it runs in mixed mode (dynamnically compiles the java byte code when needed), which may cause performance issues. Is there a way for us to pre-compile all the java code in the apps with jit? and have the apps run natively without the dalvik vm at all? This would be the most desirable. I think the biggest weakness in android is the dalvik vm. It is a huge memory hog. If we can use jit to compile the apps into native instructions then theoretically we shouldn't need the vm to run at all.
If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.
If this jit is run in mixed mode, if it is done correctly it should still help. You should see performance increases on the second time you run the app.
Click to expand...
Click to collapse
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.
A bit of ignorance is a compliment. Like I said I have not done any java work for a long time. What I don't understand about jit the way it is done, is why not go all the way and generate the native code similar to the odex files, and just by pass the vm all together. If they are going to the trouble of compiling byte code into native instructions anyway.. why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
IConrad01 said:
Umm... that's just not how JIT interpreters work.
Seriously -- JIT compilers don't change the core data of the application at all; they just translate bytecode into machinecode within the runtime environment in order to speed up the execution of frequently-encountered "strings" of code within the application as they are encountered.
Seriously: try this link [ http://psyco.sourceforge.net/doc.html#how-does-it-work ] to get a better understanding of why what you just suggested displays a bit of ignorance regarding the topic-at-hand.
Click to expand...
Click to collapse
why not just do it once and get it over with instead of compiling it over again and again... for short running tasks like most apps on android, it may very well be a perf hinderance.
Click to expand...
Click to collapse
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.
I'm trying the libdvm.so cyanogen posted on my 32A magic (288MB of RAM) and so far it's all working well, and it seems much faster
Using 4.2.5 on 32A Magic with 4.2.4 Radix Kernel with New JIT Based libjvm.so
Everything Works Well and Never had any Force Close but is that 4.2.4 Kernel from Radix actually uses JIT.
@cyanogen 32A have 288 MB ram i can test JIT based Dalvim if you want me to test it
Ok, I integrated this lib with Cyan 4.2.5. Running comp-cache and Ram hack, 16GB class 2 SD.
Initial impression (based on 20 minutes of playing);
No change in OS speed. No crashes yet. Apps (especially game emulators) have a noticeable increase in speed. I have no technical information to back up my claims, nor do I have the possibility of an ABX comparison. Sorry.
Thanks for the explanation, I buy #3 as far as security is concerned, we all know those virus taking advantage of overflow instructions in windows. But As for #2 I don't mean to have developers compile the byte compile to native, but have the vm on our phone compile it on first run and save the native instructions in file similar to how it generates the dex files on first run. This way it'll not have to recompile every time it runs. I just wish there is a way to avoid the dalvik-vm.
I irks me how much memory the dalvik-vm hogs up. A simple battery widget takes 12-16mb of memory.. It has a few pics and bytecode that simply goes to the system driver go get a number. I mean the whole ext3 filesystem driver uses less memory. Same with those widgets for task killing, they take up well over 10 mbs, which kind of defeats the whole purpose. I could write a simple tiny script that uses kill and do the same job without taking up 10m+ in the background.
We all here complain about our hardware, but I feel like these are more of software problems. anyways, that's just my rant... i hope the memory issues in vm gets better in later release.
IConrad01 said:
Well, I can think of a few reasons.
1) High-level programming languages are just plain easier to write for. Python, for example, uses an interpreter (VM) as well -- though you can compile it once and be done with it. High-level languages, as such, typically don't compile well because of the lack of "symmetry" that you get between higher-level languages and actual machine code. (Remember, my friend, the The Story of Mel )
2) JIT compilation in interpreters get you //near// compiled performance from non-compiled code. In other words; you write the program to the VM once. The VM then gets compiled one time for each platform, (Remember; despite being essentially the same hardware the Dream is somehow two different boards each of which would require a separate compile... :/) and this will only get worse over time. Now, the programmer doesn't have to specifically call up devices based on the platform but rather on the VM. He doesn't have to re-compile for each CPU/integrated-board circuit. You don't have to store, for example, one version of an app for Dreams/MT3G's, one for Heroes, one for Droids... and down the road, one for the MIPS chips, etc... Saves massively on storage considerations for centralized distribution repositories like the Market itself is.
3) VMs can be functionally isolated, preventing most forms of malicious program code escalation. Sandboxing programs is far easier when those programs are running in their own VMs. Each program/task is initiated within its own VM, which makes initialization and garbage-cleanup rather simple. For such an open-to-communications platform as a mobile phone, that can only be a good thing. Natively compiled code typically doesn't play so well with such sandboxing.
Those are just the thoughts off of the top of my head. I feel it important to note that IANAP.
Click to expand...
Click to collapse
cyanogen said:
I've had the JIT-enabled Dalvik running for a bit (on CM 4.2.5), but it's a memory hog and has a weird performance profile. It will shave 4 seconds off your "Benchmark PI" score, but interactivity of the device suffered. And it crashes sometimes.
If you want to try it (CM-4.2.5 only), here's a copy of the file:
http://n0rp.chemlab.org/android/testing/libdvm.so
Click to expand...
Click to collapse
Could anyone upload that again? The link is dead.
Hello everyone. I'm looking for a way to use gcc make natively on Android. I know would supposedly be slow and heat up my cpu, but I don't get enough time on my computer to develop via a cross compiler.
Something like this would be ideal:
http://forum.xda-developers.com/showthread.php?t=1645182
I'd post there asking about a download link but the forums won't let me until I've made ten posts.
If anyone has any ideas how to get this working I'd love to hear them!
I found a gcc binary here:
rwiki.sciviews.org/doku.php?id=getting-started:installation:android
I don't know what version it us but it seems to run. I think I will try compiling gcc from scratch.
Can bionic libc be replaced with the full version of libc? Or would that break things?
Next up I think I'll try to get bash on this phone.
I'll post an update when I have gcc fully working.
I've found an app that does most of what I needed, called Terminal IDE on the play store. I now have a mostly functional development environment on my phone.
Next up, some of the open source software I want to port uses autoreconf, which is part of automake. Unfortunately, automake needs access to /tmp/ during configure, which doesn't exist. I guess I'll just have to edit the configure file on my PC and point it to a path that's accessible.
Does anyone know of an automake binary for Android?
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline kernel with some patches from paulburton to make it actually work.
Icluded are (as of now) :
improved atmel mXT1386 touchscreen driver
tegra_v4l2 camera driver
ov5640 soc camera driver
prox_lds6202 proximity sensor driver
fm34-500 voice processor driver
asusec keyboard driver (for dock)
al3000a ambient light driver
The purpose of this is not to port things back from some linux 3.X kernel to our 2.X kernel, but to have a fully working 3.X source tree some day, from which we could port to further linux versions in the future. This can also be helpful if we want to port android 5.X in the future.
The github is at https://github.com/skirata/linux/tree/android-tegra-tf101-3.1 .
(It's my github, if someone wants to become a collaborator, please let me know, I'll add you to the collab list.
WE NEED EVERY DEVELOPER WE CAN GET.
I will spend some time on this, but I think I can hardly finish this project on my own.
Totally support this, looks promising!
Thanks for the initiative.
Are you and guever working on this together? I can test and maybe help make aokp or megatron versions.
Sent from my Transformer TF101 using Tapatalk 2
Of course I'm willing to work, you know I've helped all I could.
My kernel has much of the code updated to 3.1, so may be we can use much of it.
This can be done in two ways, by modifying the code in paul whatever it takes, or modify mine. I have nothing clear which will be easier, because over time I have made several test on my code and unfortunately, when the kernel does not boot can not be debugged, so you have to turn back.
Until wednesday I will not be able to devote almost no time, so I think the first thing would be to check the operation of the kernel of paul (if not already done) with a current rom.
It is possible that the graphics drivers (most are binary system level) may not work with that kernel.
Well, it is what I think, that first we must see is what should be changed in the kernel to function properly (or whether to change the rom).
Teamwork is how it's meant to be done.!
I will setup a working kernel konfig in the next days to push this a little forward.
at Guevor :
I'm adding you in as a collaborator so we can work together on this.
Let's improve paulburton's drivers and add new ones based on latest nvidia images.
The advantage of upstream-porting rather than downstream-porting is we can port future kernel versions more easily with own written drivers.
Also, android 5.X porting will be a lot easier, as I think it won't support 2.6.X kernels at that time. And even if it would, we can have a massive performance boost if using 3.1 mainline kernel with improvements all over the world.
Glad to count you in, guevor.
I owe you so much already.
EDIT : Just in case, be sure to use the 3.1 branch of the linux repository, as the master branch is forked from torvalds (linux 3.4.X) and will get some love when we get the 3.1 kernel to work as good as we are satisfied.
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
guevor said:
Well, the main problem I see, thinking about future versions (5.x) is that we do not have the source code for video drivers, only a small part that exists in the kernel. This added to the fact that nvidia does not provide (at least I do not know) the binary drivers for android (as they made for linux), I think that may be, we do not see tegra2 drivers for 5.x. That does not mean we can not do something, but will be less optimal and more complicated.
Hopefully I'm wrong and nvidia make things easy , but I think no manufacturer will use tegra2 for new products, and do not think they will update current products to that version ....
Click to expand...
Click to collapse
Have you tried contacting Nvidia about this?
For the record, I am not a Linux user, even with what Im going to say, keep that in mind... My history is firmly routed in WinBlows land!
This has me all sorts of excited, I remember saying it back in paul's thread before it fell off the face of the earth (read, first few pages of the forum).
As stated at the top, while NOT a Linux user, I was trying to build CM9 for one of my tablets, to do so, I had setup a Linux box (tried a few distro's), and kept having issues, so a friend of mine walked me through updating to a 3.4.x kernel (3.4.0.-5 iirc), and things definitely FELT smoother vs the 3.0 (on the distro I was using before he berated me for it and moved me to a different one) and then 3.2 kernel in use (ill note hardware issues where also at play with the actual issues, but the smooth feeling after updating was definitely something I noticed).
I have no benchmarks or performance statistics to back that up, but as I said in paul's thread, and have now experienced in a "full" Linux environment, the future with Kernel v3.1 and up has me VERY excited as to what can be done with the OG Transformer! (vs mass backports to 2.x)
On that note, Subscribed thread, and time to get an RMA for my Tablet... the top basil part is starting to come off the unit
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Orkeren said:
I haven't coded a lot with linux and android source, but I do have experience with coding and especially with reading through source code and finding syntax and other errors i.e. proofreading
So if you want me on the team I'm game!
Click to expand...
Click to collapse
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
ajohn117 said:
If my help is welcome i am willing to test your builds on my TF101G B90 with dock. So let me know if you have to do something.
Click to expand...
Click to collapse
Will do for sure, but it could take some time until we can push out the first build for testing.
rayman33 said:
Hello people,
after some conversation with early ICS-on the transformer developer paulburton, I have a git repository of a mostly working linux 3.1 mainline own.
Click to expand...
Click to collapse
With my git every things works but usb hotplug,cam,hdmi-audio. ( usb works fine when insert add boot ) , also i will stop dev for it as i'm selling my tab :crying: but would be nice if this got finished.
also major thanks to paul
Do you started the project?
I tried some things yesterday, but it did not boot. I will have a look into spark rom and try some other things, I think I have some ideas.
Btw, kernel compiles fine, zImage is there, perhaps some early device drivers have to be updated. I will look into the ramdisk I created and fix some things ...
Just to let you people know. Progress is being made.
First progress
I managed to make it boot on revolver 4.1.1 rom. I modified the video drivers to be compatible with the actual binary drivers.
The touch screen is not working, but I really have not looked at it, maybe even compile options I chose are not the most adequate, but just wanted to get it to boot with video graphics working.
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
rayman33 said:
We better get each other updated via pm in the future ..
What touchscreen driver did you define in the kernel config ?
The new mxt1386 or the old one from the 2.6.39.4 kernel?
Maybe we need to rewrite the mxt1386 drivers.
Click to expand...
Click to collapse
Well, I tested whether simply boot and graphics drivers failed as expected, and I've tried to change it and make it working. I think that is the basics (make it boot) to further adjust problems.
About the drivers, yes, I used mxt1386 but not detected coordinates, just click. I used a USB mouse to verify that the graphics drivers work.
I updated the repository with my changes.
Did you get a log cat already ?
It may reveal if the mxt1386 driver fails to load.
rayman33 said:
Every help is welcome !
Please tell me your github name and I will add you as a collaborator
Click to expand...
Click to collapse
easy as pie!
Code:
orkeren
The general idea is to free the kernel from needing the source for every build.
The kernel currently uses DTB, but even that is included in the kernel source.
make tegra11_android_defconfig -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
make tegra114-roth.dtb -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
make -j$CPU_JOB_NUM ARCH=arm CROSS_COMPILE=$TOOLCHAIN_PREFIX
This has not been verified without the source already downloaded, but the general idea is to move toward being able to produce kernel packages with just the kernel repository.
https://github.com/StarKissed/roth-kernel-starkissed
Had to fix some make issues running a mac, but I'm hoping to have a build out soon.
Many of the changes come from Tegra 3, due to the lack of Tegra 4 devices, and will have to be tuned. This may lead to some initial instability.
The source was temporarily made private until it is fit to compile. This was done to prevent erroneous reports that it's broken when the issues are known and just require the time to address them.
Are you going to compile custom kernels and release them to public?
Antara33 said:
Are you going to compile custom kernels and release them to public?
Click to expand...
Click to collapse
When I get time. Right now there is a little too much going on already.
The source and commands may work but with using a Mac, even a source build results in loops, so I have to resolve that before saying it does the same thing.
After an interesting conversation, the mpdecision idea is pointless. I bought into the belief that it might be interesting to test an alternative, but the shield thermal control has been extremely well-designed.
The primary focus will be simply unlocking additional kernel features, such as extended ntfs support and alternate tcp settings along with integrating and updating the kernel to current Linux revisions.
twistedumbrella said:
The source and commands may work but with using a Mac, even a source build results in loops, so I have to resolve that before saying it does the same thing.
After an interesting conversation, the mpdecision idea is pointless. I bought into the belief that it might be interesting to test an alternative, but the shield thermal control has been extremely well-designed.
The primary focus will be simply unlocking additional kernel features, such as extended ntfs support and alternate tcp settings along with integrating and updating the kernel to current Linux revisions.
Click to expand...
Click to collapse
Any word on what's the status here? Why does the kernel source require the full source anyways?
I'm just looking to be able to build the vanilla kernel with no hacks, I just want to compile extra modules for the kernel where I need them
vostok4 said:
Any word on what's the status here? Why does the kernel source require the full source anyways?
I'm just looking to be able to build the vanilla kernel with no hacks, I just want to compile extra modules for the kernel where I need them
Click to expand...
Click to collapse
I had a recent realization after working with the Note 4 that should allow me to build the stuff needed to compile kernels without the source. I just have to verify I can make it a distributable file and we should be good.