So I'm a bit of a android build system newbie - I can get as far as getting the source properly downloaded, and even compiling. In looking at the source for CyangenMod I notice that when you run lunch after calling . Build/envsetup.sh it has several options. It seems that all the "supported" devices have build configuration selections that start with cyanogenmod_*. So far the ones for the mecha/thunderbolt are only listed under htc_mecha-eng and htc_mecha-userdebug. I'd like to help port over cyanogenmod to the thunderbolt if I can, and at the very least be a fly on the wall so to speak to learn a bit about the android build system in general. My native development background is C#, so java comes naturally to me however ubuntu is a whole new beast for me and I'm trying to learn as I go and find out as much as I can - unfortunately I haven't found much about the different settings from lunch and ultimately what they produce once you run the configuration and then 'make' the build. Thanks for any info!
check out this change from the cm gerrit. http://review.cyanogenmod.com/#change,4618
It includes the files you need to get the mecha to show up in the lunch menu as cyanogenmod_mecha.
edit - in case you dont know otherwise cm is still quite broken for the mecha at this point. Everyone is still waiting around for the ril commits to come in
Thanks for the reply, I've heard of the garret system in passing but haven't actually used it yet - and I know the RIL is MIA - really just curious in getting my feet wet with the source - I have my old incredible if I want a totally functioning device, the mecha is just a chance I guess to poke around on my own.
Alright side question - so far I've just been using repo sync to get the source down - seems this was checked into the gingerbread branch on github, why wouldn't specifying -g gingerbread on the repo init pull down this change? Is it not actually committed yet? Excuse the ignorance - I appreciate the help!
Hello everyone,
I am not new to the android scene, and am quite familliar with linux development in java and c. I found myself in the pleasant position of having a second Atrix 4g that I had previously unlocked and played with a bit and decided it was time to have a look at some of the android issues that have managed to sufficiently annoy me.
To this end I have pulled down the aosp of ICS as well as CM9 for comparison. I see that there are issues with the tegra2 binaries for ICS and was going to have a go at building a 2.6.39 kernel for ICS.
Can any of you point me to some info on integrating a new kernel into the android build? As I understand it, the currently available binary drivers are build against 2.6.36 for GB.
Is it only the opengl drivers that are an issue? Are there opensource drivers for the bt/wifi/cell? The cameras/touch sensors/gyros etc?
I have done some research and looked over Googles build info, but it only covers the reference gear. I have not yet found a good guide on integrating 3rd party drivers for other hardware..
Thanks for all your assistance. Once I learn the build system I'm sure I will be able to make some useful contributions.
Also, I may be able to offer some hosting assistance for some projects.
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.
I'm wondering if there is anyone out there that might be interested in building a "stock" ROM for the Nexus 5 that uses the BlueZ bluetooth stack instead of the default Bluedroid stack. It should be very simple, as the BlueZ for Android project has done most of the work, including building the kernel. It looks to be as simple as downloading the various source files and compiling. I was attempting to do it myself but I couldn't ever get Linux installed on my PC. Well, I got it installed but could never boot into it. I feel bad asking someone else to build it, but like I said, my PC setup seems to be Linux-averse and my understanding is that this is a simple build.
The impetus for this is that I recently upgraded my car stereo to a bluetooth-enabled unit but I can't transmit the track metadata. Even though the head unit supports AVRCP 1.3, and the Nexus 5 should also support AVRCP 1.3. I'm unlikely to get a firmware update from the stereo manufacturer. All my reading on the issue suggests that bad things happened for Android bluetooth when Google switched from the BlueZ to Bluedroid stack. I'm hoping that incorporating BlueZ in my phone might just increase compatibility between my phone and head unit.
The relevant links for making the build are here:
http://git.kernel.org/cgit/bluetooth/bluez.git/tree/android/README
https://code.google.com/p/aosp-bluez/
What is BlueZ?