Develop Bugs

[DEV] Toolchains

This is the placeholder for the different toolchains used for compiling ARM targets (read - aosp, other projects/binaries)
I'll be updating this post tomorrow with download links.
First and most important will be the standard binutils/gcc combo.
Some time ago, I was really fed up with having to set up a 32bit chroot in order to compile aosp, which is why I decided to build my own native x86_64 toolchain.
Should you use it, you MUST have gmp and mpfr installed (libgmp, libmpfr).
I won't be bundling those for your distro.
I could make gmp-less and mpfr-less versions, but these enabled offer considerable a better code being built.
Packages:
[email protected]_4.4.4 - binutils 2.20.1, newlib 1.18.0, gcc 4.4.4
[email protected]_4.5.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.5.0
[email protected]_4.6.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.6.0 (I don't recommend using that one, since it's VERY experimental)
Notes:
If you want a stable, yet fast and bleeding edge system, use v4.4.4
You can use 4.5.0 to compile native apps, but compiling aosp with 4.5.0 fails on skia (you can always circumvent this by compiling skia first, changing to 4.4.4 and re-compiling aosp)
Once I get some time, I'll share uClibc toolchains/roots in order to get your busybox compile. ;]
>EDIT< linked 4.4.4 to download.

adwinp said:
This is the placeholder for the different toolchains used for compiling ARM targets (read - aosp, other projects/binaries)
I'll be updating this post tomorrow with download links.
First and most important will be the standard binutils/gcc combo.
Some time ago, I was really fed up with having to set up a 32bit chroot in order to compile aosp, which is why I decided to build my own native x86_64 toolchain.
Should you use it, you MUST have gmp and mpfr installed (libgmp, libmpfr).
I won't be bundling those for your distro.
Packages:
[email protected]_4.4.4 - binutils 2.20.1, newlib 1.18.0, gcc 4.4.4
[email protected]_4.5.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.5.0
[email protected]_4.6.0 - binutils 2.20.1, newlib 1.18.0, gcc 4.6.0 (I don't recommend using that one, since it's VERY experimental)
Notes:
If you want a stable, yet fast and bleeding edge system, use v4.4.4
You can use 4.5.0 to compile native apps, but compiling aosp with 4.5.0 fails on skia (you can always circumvent this by compiling skia first, changing to 4.4.4 and re-compiling aosp)
Once I get some time, I'll share uClibc toolchains/roots in order to get your busybox compile. ;]
Click to expand...
Click to collapse
some questions ...
toolchain that you used to compile "hikari aosp?
can cause problems, compiling skia with 4.4.4 and then switch to 4.5.0 to compile the rest?
Regards,
robin04

robin04 said:
some questions ...
toolchain that you used to compile "hikari aosp?
can cause problems, compiling skia with 4.4.4 and then switch to 4.5.0 to compile the rest?
Regards,
robin04
Click to expand...
Click to collapse
4.4.4 is completely stable.
IF you want to play with 4.5.0, you'll have to compile with 4.4.4 first, strip all other binaries, then compile with 4.5.0.
I'll upload in the evening.

Hmm, I compiled the official Android sources without problem on my x64 box... used the supplied 4.4.0 toolchain in the ndk though, is that cheating? .
Are there any portability issues when you build a Hero rom? I mean, do you have to copy some binary libs here and there that won't work if the rest of the ROM is compiled with 4.5.0? You said something like that once I think.
Or is this a non-issue because we got complete source now that we have a 2.6.29 kernel? I thought we still use some binary HTC files somehow (never cooked an android rom before, just compiled AOSP once and left it there).

@dipje:
Yes, not all binaries are "cross-toolchain" compatible, with different reasons behind this. Wouldn't want to enumerate all of them, lol.

/me looks at his Linux boxes all being busy with compiles.... man there goes my electricity bill again .
You can probably guess the next question adwinp: are there any real benefits to using another gcc toolchain?
Did I see it correctly that you are building with the newlib C library instead of the bison C library? Any real (proven) benefits of choosing that one, or just your preference ?
-------------------------------------
Sent from my AOSP Hero Androbin

I've had some rare cases of breakage, but newlib is a stable base (for arm targets), proven to work.
Anyhow, it's only a middleware in order to get a proper gcc working (which is what's of interest to us, along with binutils).
I'll have to sort my uClibc in order to upload a proper release. Dunno if I'll have the time till tomorrow though, since on Friday, in the evening, I'm going to the UK for ~10 days.

Links are down..

Are you sure you need these toolchains, most kernels are buildable with the one you get from Android NDK you can download from google's site

[REF] Source code: Unified git repo for GT-I9000 Gingerbread kernel source

Here we go
Common gingerbread-samsung git branch for all of us
This branch contains the fixed Gingerbread source (compiling and working) everyone of us may use as reference git repository.
Fixed in this source:
- all cleaned up gitignores
- missing FSR in Makefile
Take also a look at the updated README.txt that will explain you how to compile and get it working with modules
Also: makes sure you disable, in .config:
[*] Automatically append version information to the version string in menuconfig or CONFIG_LOCALVERSION_AUTO in .config
It will help each developer to exchange patches easily because of the common starting point.
bilboa1 said:
What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
I certainly support this idea.
Click to expand...
Click to collapse
How you can fork this repository:
- clone it via github directly
or, if you prefer keeping only this gingerbread branch directly, on your dev computer:
Code:
git clone git://github.com/project-voodoo/linux_gt-i9000.git -b gingerbread-samsung
cd linux_gt-i9000
git remote rm origin
git remote add origin git://your-new-remote-repository.git
git remote add common git://github.com/project-voodoo/linux_gt-i9000.git
This way, for people re-using Vodooo sound for example, it will be as easy as:
Code:
git fetch common
git merge gingerbread-voodoo-sound
If you have more idea of collaboration like that, express yourself
FAQ:
Q: Bleh! I hate this Kernel/ directory.
A: Yes, this was the case for the original commits but now it's a standard Linux repository with everything on its root.
But it didn't worked as expected, so I had to make the change, sorry for the inconvenience to the early adopters.
Q: What happens when Samsung update their source code tarballs
A: I'll update the common git repository accordingly (hopefully fast enough for you)
On your side, all you'll need to do will is.
Code:
git fetch common
− or git fetch git://github.com/project-voodoo/linux_gt-i9000.git
git merge gingerbread-samsung
Say good bye to messy tarballs!
PS: if you're looking to initramfs, take a shot at https://github.com/project-voodoo/samsung_initramfs − contribution welcome.

Good idea, I second that, it will be easier

wrong link
Github reads http://project-voodo.org/

What supercurio means, is that he's offering to have a common GIT repository for the official Samsung kernel of the GT-I9000 (and similar phones).
The GIT tree would contain only Samsung drops and possible other upstream fixes/changes (the kernel being loosely based on the Nexus S kernel, there's at least Samsung and Google as different upstream), as well as bug fixes. No new features etc except maybe Voodoo.
The advantage of that is that the ones not using GIT yet could fork it and make their own kernel variation on a STABLE base. They could also issue pull requests for fixes they made, which would profit everyone. That's the open-source spirit and way of doing things efficiently by the way.
Note that the current GIT already contains fixes for compiling and using Samsung's GB sources with Samsung's firmwares (and binary modules).
Forking in git hub is VERY VERY easy btw.
I certainly support this idea.

Awesome! - I also support this idea

United Galaxy S Developers
Nice idea! Perfect spirit of open source

I hope good things come out og this.

Great move Supercurio - once again !

Simply awesome men

Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?

pikachu01 said:
Will the github include the multitouch fix(SGS only using two fingers rather than multiple fingers) that affects Google Maps rotation?
Click to expand...
Click to collapse
The gingerbread-samsung branch promoted here will only contain Samsung kernel sources and won't interfere with other developers modifications.
Only exception is if this source is broken and needs something to work, like nikademus's patch: https://github.com/project-voodoo/linux_gt-i9000/commit/6c8f989f58999770d23236bb172c3a4e1c80586b

It seems that JVK and JVB was pulled from Kies because of an update problem. Looks like we're going to have new ROMs to play with in a week or two (maybe less)
Edit: What about the SSL fix (http://forum.xda-developers.com/showthread.php?t=1040005)

Great, good idea. That's how community development should work!

zorxd said:
Great, good idea. That's how community development should work!
Click to expand...
Click to collapse
Agreed! Thanks for getting things started Supercurio! Now I have to start making a Vibrant branch.

Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...

ttabbal said:
Any chance this code will boot with preempt enabled? Does the MTD driver work with the OneNAND partitions like the NS code does? I'd kind of like to get away from FSR/RFS and such....
Still cloning...
Click to expand...
Click to collapse
The code has many similarities with Nexus S one (build from it IMO) and is preempt too

Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?

supercurio said:
The code has many similarities with Nexus S one (build from it IMO) and is preempt too
Click to expand...
Click to collapse
Excellent! I just did a defconfig to check it out and saw the preempt in there.. Nice to see Samsung fixing things up a little. Now I need to get a GB ROM to install so I can try to boot.
Thanks again. I'll send a pull request when I have a Vibrant branch ready. Going for minimal modifications, fix touch button mapping and such. People can add whatever they want after that. Now I need to learn the new code tree... wheee! Hopefully the basics are the same, getting the changes into an i9k froyo kernel is pretty easy.

zorxd said:
Just a note, I had to edit the Makefile to set the crosscompile variable to the right path
Question: is the generated zImage flashable through ODIN? Don't we need to add the initramfs?
Click to expand...
Click to collapse
You will need an initramfs... anyone have a default one we can start with for 2.3?
zImage will have to be in a TAR file to flash with Odin. Heimdall can flash a bare zImage, as can the SGS Kernel Flasher tool for Android.
Oh... think I saw a setting in "make menuconfig" for the cross-compiler prefix. Might be able to avoid Makefile mods....

Sorry for the newb question, but how do we generate the initramfs? I guess we could take the one from stock JVB. But how do we extract it and how do we combine our compiled kernel with it?
On a side note, I noticed that CFQ is the default scheduler. Isn't it better to use No-op for flash memory?

[Q] [REQ] How to cook a PA rom

I like the PA rom but i would want to have the Rom Control / Similar tweaks into PA.
Can someone help me with this.
Thanks

husytcs said:
I like the PA rom but i would want to have the Rom Control / Similar tweaks into PA.
Can someone help me with this.
Thanks
Click to expand...
Click to collapse
build from source. there's a thread about aosp building stickied in general. learn git and its various functions. you'll need linux or mac osx (only builds on master branch, afaik).
explore rom's source you wish to kang @github (or any other git repository). enjoy the beauty of open source. learn how to (at least) read, cherry-pick and merge code.
naturally, after you get your build running, you can't (or shouldn't) ask for help, you need to know how to debug, and how to get yourself out of trouble.
sent from my i9250

[KERNEL][SOURCE][android_kernel_lge_msm7x27-3.0.x (3.0.8)]

I waited to post this over here until it was debugged and all the hardware works.
Even though this forum's been kinda dead quiet for a while, xda gets searched and I want this source code out there.
Derived from androidarmv6 project and tweaked over to thunderc from the p500 developers' awesome work getting it running on the Optimus One.
source:
https://github.com/bigsupersquid/and...7x27-3.0.x.git
(branch squid, for lack of imagination.)
make thunderc-test_defconfig
you'll want to change or remove the toolchain path in the config. it is highly unlikely that your cross toolchain is in the same path as mine.
I set it in the config to avoid having to add "CROSS_COMPILE=/blah/blah/etc" to the make command every time I rebuild the kernel.
it is for jellybean and kitkat roms.
use on older android versions messes up various things. Especially USB.
it conflicts with /sbin/chargerlogo or /sbin/charger for offline charging and bootloops unless that file is removed.
Use the attached removecharger.zip in recovery with signature verification off for that if you don't want to edit the ramdisk yourself.
md5sum b1a9f21285e09e06dc94422a8578dc98
enjoy

@bigsupersquid Know if anyone's willing to have a stab at building Firefox OS, now with the 3.x kernel?
EDIT: Well apparently there's no full ArmV6 support in it so, I guess not...

Making a CAF based rom.

Alright so I've built and modified both LOS and RR a bit and it went pretty well. Tutorials o'plenty when it comes to building those roms.
However I now want to try and build a rom from scratch and I'd like to base it on CAF.
I've *I think* correctly synced up with the latest msm8996 tag, but I may have ****ed that up as well.
My problem is is that I literally can not find any resource for building with CAF sources, and I can't even find my local_manifests/roomservice, so I have no idea where to start.
If any of you have any resources or want to share a bit of your knowledge it would be greatly appreciated.
Thanks.

Anyone?

Hey, check out AOSP-CAF(https://github.com/AOSP-CAF). This is all you'll ever need and it's updated regularly. The dev has already added all the necessary stuff(HALS) and also has CM's build system so all you need to do is fork some device tree , sync it's dependencies and you should be good to go.

INT3NSE07 said:
Hey, check out AOSP-CAF(https://github.com/AOSP-CAF). This is all you'll ever need and it's updated regularly. The dev has already added all the necessary stuff(HALS) and also has CM's build system so all you need to do is fork some device tree , sync it's dependencies and you should be good to go.
Click to expand...
Click to collapse
Thanks! I've synced up with it and also synced with the OnePlusOSS device tree. The builds are failing however because the pull_library.sh script they give doesn't work anymore. Is there another device tree you would recommend? And how could I go about finding the dependencies?
Thanks for your help