{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Building Your ROM With The Linaro Toolchain
This guide will help you build your ROM with the Linaro toolchain, and any other 4.7, 4.8+ toolchains. Using one of these "updated" toolchains requires you to be able to search, read, and be able find information to be able to fix errors you may encounter varying from device to device, and depending on your Global optimization level. This guide is more for setting up your build and leaves you to play with the flags and optimizations. It takes a little work to get your environment set up but that's all the fun ..
1. Getting the toolchain
First you will need to get the toolchain. You can either pull it from a repo or download the zip straight from Linaro or Google. Keep in mind that the ROM is compiled with the arm-linux-androideabi and the kernel with arm-eabi. You can find all the release versions of Linaro's toolchains here along with nightly builds LINK, And Googles toolchains for Linux and Darwin here LINK. Focusing on building with Linux the path for them is "prebuilts/gcc/linux-x86/arm" with Linaro you can just extract the one folder into the directory but Google has them split up into arm-linux-androideabi-4.7, and arm-eabi-4.7.
2. Setting up your build repo
You will need to edit the build repo to point to the updated toolchains. From step one we either put the Linaro folder or Google's toolchains into the "prebuilts/gcc/linux-x86/arm" directory. Remember the names of the folder or toolchains as we will need them in these edits, Using the linaro folder name for both arm-linux-androideabi, and arm-eabi lines or just replacing them with the updated Google versions. You can follow this commit as a guide to setting up your Build repo Toolchain Edits
3. Dealing with build errors
From Linaro:
Getting rid of -fno-strict-aliasing enables rather efficient additional optimizations – but requires that the code being compiled follows some rules traditionally not enforced by compilers.
Given the traditional lack of enforcement, there’s lots of code out there (including, unfortunately, in the AOSP codebase) that violates those rules.
Fortunately, gcc can help us detect those violations: With -fstrict-aliasing -Werror=strict-aliasing, most aliasing violations can be turned into built time errors instead of random crashes at runtime. This allowed us to detect many aliasing violations in the code, and fix them (where doable with reasonable effort), or work around them by enabling -fno-strict-aliasing just for a particular subdirectory containing code not ready for dropping it.
There are many Projects in your source you will have to add patches to fix the violations or workarounds. I have 40+ patches to fix the numerous errors in my builds. Many can be found from Linaro's Gitweb LINK, and you can get some of them from CM Review LINK. This is the hard part and Google search can be your best friend :silly:.
4. Optimizations
Once you get your setup going successfully you can play around with some optimizations. You can find some information about flag optimizations from Linaro LINK and GNU LINK. an example can be like this for -O3 LINK, or more stable -O2 with some added flags that would be enabled by -O3 LINK. there's also options like Linaros string handling routines LINK.
MISC Links
DJLaMontagneIII Github
CM Review Linaro commits
Linaro Gitweb
Linaro Downloads
Google Source
SaberMod Github
trailblazerz Github
Please feel free to reference my Github for patches you may need and feel free to post any build errors you may be stuck on and need help because others my be in the same boat, but please use hide tags or pastebin for the terminal outputs:good:.
one
two
three!!!!
no, but is compiling a toolchain from source pretty effortless?
I need a darwin version.
airfluip1 said:
three!!!!
no, but is compiling a toolchain from source pretty effortless?
I need a darwin version.
Click to expand...
Click to collapse
You would have to use
https://android.googlesource.com/platform/prebuilts/gcc/darwin-x86/arm/arm-eabi-4.7/
https://android.googlesource.com/platform/prebuilts/gcc/darwin-x86/arm/arm-linux-androideabi-4.7/
Sent from my Nexus7 using Tapatalk HD
Hi @DJLamontagneIII Can I cherry-pick your commits for building kernel man? Cause the patches I applied to the kernel seems to screw my bootimage as my phone couldn't boot up (along with patches to the others were fine)
daothanhduy1996 said:
Hi @DJLamontagneIII Can I cherry-pick your commits for building kernel man? Cause the patches I applied to the kernel seems to screw my bootimage as my phone couldn't boot up (along with patches to the others were fine)
Click to expand...
Click to collapse
You can use what ever you need
All the very best for your own thread my friend.. As such you were doing this job for a long time till now.. Thanks for all the support !!!
Sent from my Find 5 using Tapatalk 2
Good write up DJ. Self help/teaching method Thanks for this
Hey @DJLamontagneIII. First of all, thanks for the very informational guide I was able to compile CM10.1 with Linaro for my phone (HTC Sensation) but it just hangs at the manufacturer splash for ~30 seconds then reboots into the recovery. I tried building with and without all the repos from your GitHub but it hasn't made a difference. I've also been building with the flags you're using but still no luck I've tried compiling with generic Linaro GCC 4.7 and 4.8 but the same thing happens with both. Any ideas for what I can do?
android1234567 said:
Hey @DJLamontagneIII. First of all, thanks for the very informational guide I was able to compile CM10.1 with Linaro for my phone (HTC Sensation) but it just hangs at the manufacturer splash for ~30 seconds then reboots into the recovery. I tried building with and without all the repos from your GitHub but it hasn't made a difference. I've also been building with the flags you're using but still no luck I've tried compiling with generic Linaro GCC 4.7 and 4.8 but the same thing happens with both. Any ideas for what I can do?
Click to expand...
Click to collapse
swap your boot.img out with one from a working cm-10.1 rom for your device and if it works, then it obviously indicates that it has something to do with the kernel and how it was compiled. If that's the case, I would take a look at what prebuilt you're pulling from for armeabi
IAmTheOneTheyCallNeo said:
swap your boot.img out with one from a working cm-10.1 rom for your device and if it works, then it obviously indicates that it has something to do with the kernel and how it was compiled. If that's the case, I would take a look at what prebuilt you're pulling from for armeabi
Click to expand...
Click to collapse
I've already tried that, still doesn't boot . I've been building the kernel with linaro for a while (I also have a custom toolchain path set in kernel.mk) and I was running it on my phone for weeks, so it's definitely not the kernel (or ramdisk).
Have you tried lowering the flags to -O2... -O3 could be causing issues
Sent from my SGH-T959V using Tapatalk 4 Beta
DJLamontagneIII said:
Have you tried lowering the flags to -O2... -O3 could be causing issues
Sent from my SGH-T959V using Tapatalk 4 Beta
Click to expand...
Click to collapse
I'm already using -O2 because I'm using the flags from your GitHub
android1234567 said:
I'm already using -O2 because I'm using the flags from your GitHub
Click to expand...
Click to collapse
The problem with my device in particular, was modifying the prebuilt line indicated in build/core/combo/select.mk
change that back to the default (which I believe was pointing to 4.6) and rebuild... You'll be surprised.
However don't feel discouraged about changing that line back to 4.6 as the envsetup.sh is where the magic really happens and decides which prebuilts to use.
My phone went from splash to darkness for 30 seconds, and then a reboot back into recovery.. If that sounds familiar, make that one change in your select.mk and give it a rebuild.
IAmTheOneTheyCallNeo said:
The problem with my device in particular, was modifying the prebuilt line indicated in build/core/combo/select.mk
change that back to the default (which I believe was pointing to 4.6) and rebuild... You'll be surprised.
However don't feel discouraged about changing that line back to 4.6 as the envsetup.sh is where the magic really happens and decides which prebuilts to use.
My phone went from splash to darkness for 30 seconds, and then a reboot back into recovery.. If that sounds familiar, make that one change in your select.mk and give it a rebuild.
Click to expand...
Click to collapse
That's what my phone is doing (splash to black screen to recovery) but it still doesn't boot after making the change. Just to make sure I did it right, do you have a commit I can see for the change you made in select.mk?
android1234567 said:
That's what my phone is doing (splash to black screen to recovery) but it still doesn't boot after making the change. Just to make sure I did it right, do you have a commit I can see for the change you made in select.mk?
Click to expand...
Click to collapse
I'm sorry buddy I told you the wrong file
It's in TARGET_linux-arm.mk
this is the original line:
TARGET_TOOLCHAIN_ROOT := prebuilts/gcc/$(HOST_PREBUILT_TAG)/arm/arm-linux-androideabi-4.6
as shown on the unmodified version here: https://github.com/CyanogenMod/android_build/blob/cm-10.1/core/combo/TARGET_linux-arm.mk#L46
Change that line in your modified build/core/combo/TARGET_linux-arm.mk to look identical to that, do a make clean, and rebuild with that change.
Actually, try doing it without a clean first and if it still doesn't boot, do a make clean and then try.
IAmTheOneTheyCallNeo said:
I'm sorry buddy I told you the wrong file
It's in TARGET_linux-arm.mk
this is the original line:
TARGET_TOOLCHAIN_ROOT := prebuilts/gcc/$(HOST_PREBUILT_TAG)/arm/arm-linux-androideabi-4.6
as shown on the unmodified version here: https://github.com/CyanogenMod/android_build/blob/cm-10.1/core/combo/TARGET_linux-arm.mk#L46
Change that line in your modified build/core/combo/TARGET_linux-arm.mk, do a make clean, and rebuild with that change.
Actually, try doing it without a clean first and if it still doesn't boot, do a make clean and then try.
Click to expand...
Click to collapse
But TARGET_linux-arm.mk is what controls which toolchain builds the whole thing... I know that envsetup doesn't set the toolchain; I experimented a lot and found that TARGET_linux-arm.mk is what controls the toolchain for the whole thing. It makes sense that it booted for you because I think you built the whole ROM with the 4.6 toolchain.
EDIT: It might not have booted for me because my build machine is apparently messed up
android1234567 said:
But TARGET_linux-arm.mk is what controls which toolchain builds the whole thing... I know that envsetup doesn't set the toolchain; I experimented a lot and found that TARGET_linux-arm.mk is what controls the toolchain for the whole thing. It makes sense that it booted for you because I think you built the whole ROM with the 4.6 toolchain.
EDIT: It might not have booted for me because my build machine is apparently messed up
Click to expand...
Click to collapse
https://code.google.com/p/android/issues/detail?id=3812
Have a read. envsetup.sh is what decides the toolchain. That particular target should be left alone. At least for my device.
target thumb C: libcrypto_static <= external/openssl/crypto/bio/bss_dgram.c
external/openssl/crypto/bio/bss_dgram.c: In function 'dgram_ctrl':
external/openssl/crypto/bio/bss_dgram.c:581:5: warning: pointer targets in passing argument 5 of 'getsockopt' differ in signedness [-Wpointer-sign]
In file included from prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/netdb.h:66:0,
from external/openssl/e_os.h:563,
from external/openssl/crypto/cryptlib.h:65,
from external/openssl/crypto/bio/bss_dgram.c:64:
prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/sys/socket.h:73:18: note: expected 'socklen_t *' but argument is of type 'unsigned int *'
external/openssl/crypto/bio/bss_dgram.c:597:5: warning: pointer targets in passing argument 5 of 'getsockopt' differ in signedness [-Wpointer-sign]
In file included from prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/netdb.h:66:0,
from external/openssl/e_os.h:563,
from external/openssl/crypto/cryptlib.h:65,
from external/openssl/crypto/bio/bss_dgram.c:64:
prebuilts/ndk/current/platforms/android-9/arch-arm/usr/include/sys/socket.h:73:18: note: expected 'socklen_t *' but argument is of type 'unsigned int *'
external/openssl/crypto/bio/bss_dgram.c:628:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
external/openssl/crypto/bio/bss_dgram.c:628:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
external/openssl/crypto/bio/bss_dgram.c:628:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
cc1: some warnings being treated as errors
make: *** [/home/gchild320/Source/out/target/product/i605/obj/STATIC_LIBRARIES/libcrypto_static_intermediates/crypto/bio/bss_dgram.o] Error 1
make: *** Waiting for unfinished jobs....
Anyone have any ideas on what is causing this?
Related
Hi all!
As many of you might already know we have gotten a HTC Magic here in Scandinavia without support for netfilter and iptables. I've been trying to recompile a new version of the kernel on my x86_64 Archlinux box while adding these lines to the .config which I exported from my rooted phone:
Code:
CONFIG_NETFILTER=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=Y
I am a n00b when it comes to compiling, booting and flashing Android stuff and not really a git wizard either. I've downloaded the source, cross-compiled it with my new .config and tried booting it with fastboot only to stare at the HTC logo for 15 minutes before giving up. I suspect that I have probably failed doing the right thing at more than one step in the process but have troubles finding a full guide for Android kernel hacking and loading on the web. I am not even sure if I really compiled the 2.6.27 version used in the daldroid build I have on the phone instead of the latest version in git.
I will provide the step-by-step details below.
1. Downloading and installing the CodeSourcery Cross-compiler from
HTML:
http://www.codesourcery.com/sgpp/lite/arm/portal/release858
2. Downloading setting up the android source code:
Code:
git clone git://android.git.kernel.org/kernel/msm.git
git checkout --track -b msm_htc origin/android-msm-2.6.27
git checkout -f
(here I noticed that the checkouts did not seem to download any extra code, is that expected?)
3. Setting up the cross compilation in the Makefile.
Code:
CROSS_COMPILE=../arm-2009q1/bin/arm-none-linux-gnueabi-
4. Using my .config when running make like this:
Code:
make zImage ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
(a few additional options not present in the .config-file need to be manually specified before the build starts)
5. Extracting the ramdisk from the nordic daldroid boot.img:
Code:
split_bootimg.pl boot.img
5. Trying the new kernel with the daldroid ramdisk:
Code:
fastboot boot arch/arm/boot/zImage ../../boot.img-ramdisk.daldroid.gz
creating boot image...
creating boot image - 1634304 bytes
downloading 'boot.img'... OKAY
booting... OKAY
6. Fail
I would really appreciate some help to get this going. How can I confirm that 2.6.27 was really used? What other gotchas I have forgotten about?
CONFIG_MACH_SAPPHIRE=y
ridli said:
CONFIG_MACH_SAPPHIRE=y
Click to expand...
Click to collapse
Hmm, unfortunately this option is already set to true.
Perhaps it is mainly a fastboot problem. I dunno.
maybe but why you dont try to make a boot.img and flash it?
did you set the system type to msm? it is important.
copy here your .config, maybe we can try to see if something is wrong or you can do this.
Code:
make ARCH=arm CROSS_COMPILE=../arm-2009q1/bin/arm-none-linux-gnueabi- msm_defconfig
for do a default msm .config.
For what I've seen, you're not making a kernel+ramdisk image, but loading them both splitted. Maybe you're missing the command line parametters?
Also, you can patch the kernel code to make it light up one of the leds so you can know if at least the kernel is actually booting or is getting stucked somewhere. To make this, you can patch, on board-sapphire.c, the init function:
Code:
static void __init sapphire_init(void)
{
int rc;
printk("sapphire_init() revision = 0x%X\n", system_rev);
/*
* Setup common MSM GPIOS
*/
config_gpios();
msm_hw_reset_hook = sapphire_reset;
msm_acpu_clock_init(&sapphire_clock_data);
/* adjust GPIOs based on bootloader request */
printk("sapphire_init: cpld_usb_hw2_sw = %d\n", cpld_usb_h2w_sw);
gpio_set_value(SAPPHIRE_GPIO_USB_H2W_SW, cpld_usb_h2w_sw);
[] INSERT HERE:
gpio_set_value(SAPPHIRE_CPLD_LED_BASE+XX, 1);
Where XX is the led number you want to enable.
Any progresses ?
shwan_3 said:
Any progresses ?
Click to expand...
Click to collapse
Not yet, but the posts above are encouraging. I'll post my .config below.
My .config
I stripped all the '#' commented lines from the file to have it go below the 1000 lines limit.
Code:
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_GENERIC_GPIO=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_MMU=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_SUPPORTS_AOUT=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_OPROFILE_ARMV6=y
CONFIG_OPROFILE_ARM11_CORE=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=17
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_PANIC_TIMEOUT=5
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_KALLSYMS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_COMPAT_BRK=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_ASHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
CONFIG_PROFILING=y
CONFIG_OPROFILE=y
CONFIG_HAVE_OPROFILE=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_KMOD=y
CONFIG_BLOCK=y
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_DEFAULT_AS=y
CONFIG_DEFAULT_IOSCHED="anticipatory"
CONFIG_CLASSIC_RCU=y
CONFIG_ARCH_MSM7XXX=y
CONFIG_ARCH_MSM7201A=y
CONFIG_MACH_TROUT=y
CONFIG_MACH_SAPPHIRE=y
CONFIG_HTC_BATTCHG=y
CONFIG_HTC_PWRSINK=y
CONFIG_MSM_AMSS_VERSION=6225
CONFIG_MSM_AMSS_VERSION_6225=y
CONFIG_MSM_AMSS_SUPPORT_256MB_EBI1=y
CONFIG_MSM_DEBUG_UART_NONE=y
CONFIG_MSM7XXX_USE_GP_TIMER=y
CONFIG_MSM7XXX_SLEEP_MODE_POWER_COLLAPSE_SUSPEND=y
CONFIG_MSM7XXX_SLEEP_MODE=0
CONFIG_MSM7XXX_IDLE_SLEEP_MODE_POWER_COLLAPSE=y
CONFIG_MSM7XXX_IDLE_SLEEP_MODE=1
CONFIG_MSM7XXX_IDLE_SLEEP_MIN_TIME=20000000
CONFIG_MSM7XXX_IDLE_SPIN_TIME=80000
CONFIG_MSM_IDLE_STATS=y
CONFIG_MSM_IDLE_STATS_FIRST_BUCKET=62500
CONFIG_MSM_IDLE_STATS_BUCKET_SHIFT=2
CONFIG_MSM_IDLE_STATS_BUCKET_COUNT=10
CONFIG_MSM_FIQ_SUPPORT=y
CONFIG_MSM_SERIAL_DEBUGGER=y
CONFIG_MSM_SMD=y
CONFIG_MSM_ONCRPCROUTER=y
CONFIG_MSM_RPCSERVERS=y
CONFIG_MSM_CPU_FREQ=y
CONFIG_MSM_CPU_FREQ_MSM7K=y
CONFIG_MSM_CPU_FREQ_SCALING_MAX=528000
CONFIG_MSM_CPU_FREQ_SCALING_MIN=384000
CONFIG_MSM_HW3D=y
CONFIG_MSM_ADSP=y
CONFIG_HTC_HEADSET=y
CONFIG_HTC_ACOUSTIC=y
CONFIG_WIFI_CONTROL_FUNC=y
CONFIG_WIFI_MEM_PREALLOC=y
CONFIG_CPU_32=y
CONFIG_CPU_V6=y
CONFIG_CPU_32v6=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_PABRT_NOIFAR=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_ARM_THUMB=y
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_PREEMPT=y
CONFIG_HZ=100
CONFIG_AEABI=y
CONFIG_ARCH_FLATMEM_HAS_HOLES=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_RESOURCES_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_ALIGNMENT_TRAP=y
CONFIG_ZBOOT_ROM_TEXT=0x0
CONFIG_ZBOOT_ROM_BSS=0x0
CONFIG_CMDLINE="mem=64M console=ttyMSM,115200n8"
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_DEFAULT_GOV_MSM7K=y
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_MSM7K=y
CONFIG_BINFMT_ELF=y
CONFIG_PM=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HAS_WAKELOCK=y
CONFIG_HAS_EARLYSUSPEND=y
CONFIG_WAKELOCK=y
CONFIG_WAKELOCK_STAT=y
CONFIG_USER_WAKELOCK=y
CONFIG_EARLYSUSPEND=y
CONFIG_FB_EARLYSUSPEND=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_ANDROID_PARANOID_NETWORK=y
CONFIG_BT=y
CONFIG_BT_L2CAP=y
CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_HIDP=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
CONFIG_BT_HCIUART_LL=y
CONFIG_FIB_RULES=y
CONFIG_RFKILL=y
CONFIG_RFKILL_LEDS=y
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_MTD=y
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CMDLINE_PARTS=y
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
CONFIG_MTD_MSM_NAND=y
CONFIG_BLK_DEV=y
CONFIG_MISC_DEVICES=y
CONFIG_ANDROID_PMEM=y
CONFIG_TIMED_OUTPUT=y
CONFIG_TIMED_GPIO=y
CONFIG_BINDER_IPC=y
CONFIG_KERNEL_DEBUGGER_CORE=y
CONFIG_LOW_MEMORY_KILLER=y
CONFIG_LOGGER=y
CONFIG_ANDROID_RAM_CONSOLE=y
CONFIG_ANDROID_RAM_CONSOLE_ENABLE_VERBOSE=y
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION=y
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_DATA_SIZE=128
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_ECC_SIZE=16
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_SYMBOL_SIZE=8
CONFIG_ANDROID_RAM_CONSOLE_ERROR_CORRECTION_POLYNOMIAL=0x11d
CONFIG_HAVE_IDE=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_DEBUG=y
CONFIG_DM_CRYPT=y
CONFIG_DM_UEVENT=y
CONFIG_NETDEVICES=y
CONFIG_DUMMY=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_SMC91X=y
CONFIG_NETDEV_1000=y
CONFIG_NETDEV_10000=y
CONFIG_PPP=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
CONFIG_SLHC=y
CONFIG_MSM_RMNET=y
CONFIG_INPUT=y
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_KEYRESET=y
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_ELAN_I2C_8232=y
CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_UINPUT=y
CONFIG_INPUT_GPIO=y
CONFIG_INPUT_KEYCHORD=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_MSM=y
CONFIG_SERIAL_MSM_CLOCK_CONTROL=y
CONFIG_SERIAL_MSM_RX_WAKEUP=y
CONFIG_SERIAL_MSM_HS=y
CONFIG_UNIX98_PTYS=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_MSM=y
CONFIG_SENSORS_AKM8976=y
CONFIG_SENSORS_PCA963X=y
CONFIG_SENSORS_MT9T013=y
CONFIG_SENSORS_MT9P012=y
CONFIG_POWER_SUPPLY=y
CONFIG_SSB_POSSIBLE=y
CONFIG_DAB=y
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_MSM=y
CONFIG_FB_MSM_LOGO=y
CONFIG_HID_SUPPORT=y
CONFIG_HID=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_FUNCTION=y
CONFIG_USB_FUNCTION_MSM_HSUSB=y
CONFIG_USB_FUNCTION_ADB=y
CONFIG_USB_FUNCTION_MASS_STORAGE=y
CONFIG_MMC=y
CONFIG_MMC_UNSAFE_RESUME=y
CONFIG_MMC_EMBEDDED_SDIO=y
CONFIG_MMC_PARANOID_SD_INIT=y
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_PARANOID_RESUME=y
CONFIG_MMC_MSM7XXX=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_CPLD=y
CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_SLEEP=y
CONFIG_SWITCH=y
CONFIG_SWITCH_GPIO=y
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
CONFIG_RTC_INTF_ALARM=y
CONFIG_RTC_DRV_MSM7XXX=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
CONFIG_FS_MBCACHE=y
CONFIG_FS_POSIX_ACL=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FAT_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_YAFFS_FS=y
CONFIG_YAFFS_YAFFS1=y
CONFIG_YAFFS_YAFFS2=y
CONFIG_YAFFS_AUTO_YAFFS2=y
CONFIG_YAFFS_SHORT_NAMES_IN_RAM=y
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
CONFIG_NLS_ISO8859_1=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_FS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DETECT_SOFTLOCKUP=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SPINLOCK_SLEEP=y
CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_VM=y
CONFIG_DEBUG_SG=y
CONFIG_FRAME_POINTER=y
CONFIG_HAVE_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_CBC=y
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_TWOFISH=y
CONFIG_CRYPTO_TWOFISH_COMMON=y
CONFIG_CRYPTO_HW=y
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
CONFIG_CRC32=y
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_REED_SOLOMON=y
CONFIG_REED_SOLOMON_ENC8=y
CONFIG_REED_SOLOMON_DEC8=y
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
biktor_gj said:
For what I've seen, you're not making a kernel+ramdisk image, but loading them both splitted. Maybe you're missing the command line parametters?
Where XX is the led number you want to enable.
Click to expand...
Click to collapse
Yeah, that could be a problem. I was under the impression that fastboot built the boot.img itself before transfering the kernel to the phone.
Interesting test with the leds. I'll check it out if I don't solve this.
I'm working on the exact same thing. can you contact me via im? pm for my screen names
I think that HTC patched some things in that are not available in the source tree... So I doubt that you'll be able to get a kernel running build from source. If you do happen to make it run let us know
Amon_RA said:
I think that HTC patched some things in that are not available in the source tree... So I doubt that you'll be able to get a kernel running build from source. If you do happen to make it run let us know
Click to expand...
Click to collapse
I would not be suprised at all if that was the case. However, since the Linux kernel is GPL, such patches, as I understand it, also need to be under the GPL and made available upon request. Is there a public HTC source tree anywhere?
And btw, how can I fix the "recompile" misspelling in the title of this thread? It is driving me insane
This might be a very stupid question, but here it goes:
Shouldn't it be possible to build all the extra netfilter/iptables support for the vanilla 2.6.27 kernel as modules and insmod them when running HTC's kernel? Or will that result in swift and horrible death?
i don't see why it wouldn't. we wouldn't need the source for htc's kernel then, right? just figure out how to build the modules? isn't that kind of how proprietary video drivers work for linux?
EDIT: Modules will work, that is certain. A little googling confirmed that's how wlan and such work (on Android)
EDIT 2: It seems like there is .config for the kernel on the phone that can be used with the standard 2.6.27 kernel source to build the android kernel.
EDIT 3: found the kernel here http://github.com/zhoukejun/android-2.6.27-yf255/tree/master
sammypwns said:
i don't see why it wouldn't. we wouldn't need the source for htc's kernel then, right? just figure out how to build the modules? isn't that kind of how proprietary video drivers work for linux?
EDIT: Modules will work, that is certain. A little googling confirmed that's how wlan and such work (on Android)
EDIT 2: It seems like there is .config for the kernel on the phone that can be used with the standard 2.6.27 kernel source to build the android kernel.
EDIT 3: found the kernel here http://github.com/zhoukejun/android-2.6.27-yf255/tree/master
Click to expand...
Click to collapse
I wonder if access to the kernel can help with the Bluetooth problems in the Hero ROM?
Bump!
Is there any news about iptables on PVT 32A based sapphire?
gboddina said:
Bump!
Is there any news about iptables on PVT 32A based sapphire?
Click to expand...
Click to collapse
Well. The kernels that we successfully have built by cross-compiling refuse to boot. Looking at the config.gz that the phone exports and trying
Code:
make oldconfig
we have learnt that HTC has a lot of parameters specified for code that appears not to be in the standard android 2.6.27 kernel source tree. We would be very very happy if someone around here could point us to the repository holding HTC specific patches and code for the Magic/Sapphire.
Based on http://www.mail-archive.com/[email protected]/msg00442.html , it seems we need to find the source of the android-msm-htc-2.6.27 kernel.
Which don't seems to be public.
gboddina said:
Based on http://www.mail-archive.com/[email protected]/msg00442.html , it seems we need to find the source of the android-msm-htc-2.6.27 kernel.
Which don't seems to be public.
Click to expand...
Click to collapse
But it has to be made public if requested. That is essence of the GPL.
i emailed them a while ago. i also talked to someone who has gotten his own kernels to boot but on the dream dev phone
This thread is intended only for developers.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
What is Acidify?
Acidify is a tool for building Android builds. It allows easy switching between build types and setting up everything that is needed to build Android.
That said, it is a tool designed for people that are already building Android but want to be able to switch between CM7, CM9, and AOKP easily. It's primarily a convenience tool for TeamAcid developers.
Can I use Acidify?
Of course you can use Acidify! Be aware that it grabs manifests from us (TeamAcid) so in its unmodified state you'll only be able to build Android the way we build Android. As of 0.2.4, however, there are configurable options that allow building for any device. Simply specify any local manifest URLs and the device name in the script.
What do I need to use Acidify?
Short Answer: A POSIX-compliant machine with bash which is capable of compiling Android.
Long Answer: Currently, you need a machine running version 10.10 of Ubuntu or higher to use every feature available in Acidify. Until people contribute code aimed at other distributions and versions, some features (such as grabbing needed packages) may be unavailable. The core features such as initializing the build environment, switching between build types, or building Android itself should theoretically work on any platform running bash and which has all the packages installed that are required to build Android.
How do I install Acidify?
Download a tarball of acidify or clone the repository. Put it somewhere safe and run
Code:
acidify setup
. That will install all the required packages for building Android (if you're on Ubuntu) and it will create a soft link to acidify in ~/bin so that you can access acidify from any directory (assuming ~/bin is in your PATH).
How do I use Acidify?
Run
Code:
acidify usage
for an explaination on how Acidify may be used.
Can I modify or redistribute Acidify?
Yes, you can! Acidify is licensed under the GNU General Public License version 3 (or greater). You can modify it and redistribute it under the terms of the license. See LICENSE for more information.
I found a bug with Acidify. Will you fix it?
For sure! Make an issue in the issue tracker to tell us about it.
I found a bug with Acidify and I fixed it. Do you want it?
We would love it! Submit a pull request.
I wanted X feature, so I implemented it. Do you want it?
Potentially. Submit a pull request and we can discuss it there.
Get it on Github!
Changelog
ABOUT TIME! I was waiting for this all day yesterday, it took you until today to post it, serioiusly, rabble rabble *gets smacked by m4xm4n* Okay okay I'll stop about the ETA's.
Nice work Max!
Oh boy!
This is gonna make my life better.
Sent from my SGH-T959V using xda premium
Well Max thanks dude this will help with some stuff
Sent from my SGH-T959V using xda app-developers app
I will never forget it．
Oh hey,
um,
If you try to switch between build types right now, it's going to mess a lot of stuff up. So don't do it until I push 0.2.0. hehe. whoops.
Changelog
Version 0.2.0 is up on the githubs.
schedtool will now be installed as a required package. (ubuntu only)
Fixed acidify init. Switch between build types cleanly and correctly.
Fixed acidify deploy. I had it deploying all builds as CM9 and not removing the correct builds. Blame it on late night programming.
Minor things you won't notice.
Version 0.2.1 is up on the githubs
Fixed a derp that made goo upload not work for CM7 and CM9
Version 0.2.2 is up on the githubs
Fix uploading to goo
Fix make clobber call in cleanenv()
Fix for acidify init in a clean directory
Add symlink to ~/bin/acidify (thanks fbis251)
Version 0.2.3 is up on the githubs
Add colorized output and timer (thanks fbis251)
Add error checking to checkenv() (thanks fbis251)
Version 0.2.4 is up on the githubs
Simplify configuration and increase acidify device agnosticism. You should be able to compile for any device now by configuring correctly for it. Simply change the local manifest variables and the device variable.
Version 0.2.5 is up on the githubs
Added temporary workaround for building AOKP (thanks fbis251!)
Version 0.2.6 is up on the githubs
Don't run timer on 'acidify version' or in the absence of a command.
Colorize error output
Version 0.2.7 is up on the githubs
Add automatic kernel building and cleaning to CM7.
Apply the AOKP build workaround only if the device is galaxys4gmtd.
Version 0.2.8 is up on the githubs
Make kernel cleaning device agnostic and clean before switching build types. Left over kernel build stuff from CM7 will break AOKP and CM9 builds.
Version 0.2.9 is up on the githubs
Install pngcrush as a required package in setup()
Fix Goo.im upload
curl isn't installed on ubuntu by default. Install the required packages before trying to grab repo using curl (thanks fbis251)
Update deploy() for AOKP milestone 6 (thanks fbis251)
Update deploy() to reuse code (thanks fbis251)
Update upload() (thanks fbis251)
Version 0.3.0 is up on the githubs
Added a check for lsb-release and made the error a little more readable (thanks xaocon)
Changed check for /etc/lsb-release to look for a readable regular file and changed the logic for defaulting the DISTRIB_ID value. (thanks xaocon)
Add Gummy support (thanks fbis251)
Version 0.3.1 is up on the githubs
Updated upload() to use rsync with resume support (thanks fbis251)
Add Linux Mint support to setup()
Version 0.3.2 is up on the githubs
Gummy: get-prebuilts added (thanks fbis251)
Version 0.3.3 is up on the githubs
Update constants and add ~/bin/acidify check (thanks fbis251)
Version 0.3.4 is up on the githubs
Add boot image flashing function
Version 0.4.0 is up on the githubs
Massive changes to how configuration works. Please update and read this.
For anyone wondering, the AOKP repo is set up and you can grab and compile Team Acid's version of AOKP using Acidify. .
There's still one minor hitch with bml_over_mtd but I'm assuming no one's really gonna go ahead and grab the source anyway. Boo!
Looks great! Certainly saves me a huge amount of time figuring out how to maintain and switch git/repo between CM9 and AOKP, as well as bugging you guys to find the right local manifests!
Forgive me, but where is the bug tracker?
$ acidify
$ acidify init cm9
Acidify version 0.2.1
Attempting to initialize environment to build type cm9
This WILL REMOVE ALL LOCAL CHANGES
/home/jeff/bin/acidify: line 126: [: !=: unary operator expected
if [ ${ANDROID_BUILD_TOP} != $resdir ] # Apparently fails with empty ${ANDROID_BUILD_TOP}
+ '[' '!=' /home/jeff/Documents/android-build/test ']'
../acidify/acidify: line 126: [: !=: unary operator expected
Looks like it needs a check for an empty string there
jeffsf said:
Looks great! Certainly saves me a huge amount of time figuring out how to maintain and switch git/repo between CM9 and AOKP, as well as bugging you guys to find the right local manifests!
Forgive me, but where is the bug tracker?
$ acidify
$ acidify init cm9
Acidify version 0.2.1
Attempting to initialize environment to build type cm9
This WILL REMOVE ALL LOCAL CHANGES
/home/jeff/bin/acidify: line 126: [: !=: unary operator expected
if [ ${ANDROID_BUILD_TOP} != $resdir ] # Apparently fails with empty ${ANDROID_BUILD_TOP}
+ '[' '!=' /home/jeff/Documents/android-build/test ']'
../acidify/acidify: line 126: [: !=: unary operator expected
Looks like it needs a check for an empty string there
Click to expand...
Click to collapse
You're using an old version. That error has been fixed.
FBis251 said:
For anyone wondering, the AOKP repo is set up and you can grab and compile Team Acid's version of AOKP using Acidify. .
There's still one minor hitch with bml_over_mtd but I'm assuming no one's really gonna go ahead and grab the source anyway. Boo!
Click to expand...
Click to collapse
I left my laptop syncing before I left the house
Sent from my SGH-T989 using xda app-developers app
Awesome. We'll finally have some more people messing with the AOKP source. I've been hoarding it all to myself, but if I had tried to share it without the local_manifest.xml it would've gotten messy quick. Good thing Max made this script .
Tell me when you try building, I wanna see if all the problems I had aren't there anymore.
EDIT
You should hop onto IRC for a bit.
I just pushed a few updates to Acidify which brings us to 0.2.9
It was updates to upload() and deploy() if you're using goo.im for uploads or pushing the builds to your sdcard via ADB. It'll be easier to add new devices. Once I get the repo issues sorted with AcidGummy I'll also add it to the list of available roms that you can download and build.
Acidify version 0.4.0
This is the last bash release. I will be rewriting acidify in Python after this.
This release introduces a global configuration file so script modifications are no
longer required or encouraged. Additionally, all config options can be overridden by
the environment. This makes way for acidifies use in automated build scripts and
when building for multiple devices. Further more, if a build environment is
configured, you can invoke acidify from anywhere.
See config.sample to create a config for yourself. Save it as ~/.acidify/config
e.g. for running with environmental variables:
DEVICE=vibrantmtd MANUFACTURER=samsung acidify config
will run acidify config for the device vibrantmtd instead of whatever the script's
defaults are, or the options set in the config file (if present).
Options priority ENV(highest), config file, script defaults (lowest)
m4xm4n said:
Acidify version 0.4.0
Click to expand...
Click to collapse
I am trying to run latest script, and no go. What am I doing wrong?
[email protected]:~/src/aokp$ acidify setup
....
....
Your machine is ready to setup the Android build environment
Please see http://source.android.com/source/initializing.html for
instructions on setting up ADB and the udev rules required.
Elapsed Time: 10 sec(s)
[email protected]:~/src/aokp$ acidify init aokp
Acidify version 0.4.1
Attempting to initialize environment to build type aokp
This WILL REMOVE ALL LOCAL CHANGES
/home/galets/bin/acidify: line 54: /.acidify/buildtype: No such file or directory
Error: Could not write to /.acidify/buildtype !
do I need some env variables configured?..
**EDIT:** My bad... I guess I was supposed to create ~/.acidify/config
It's not listed anywhere, but... First run setup.
git clone https://github.com/teamacid/acidify.git
cd acidify
mkdir ~/.acidify
cp config.sample ~/.acidify/config
./acidify setenv
./acidify setup
./acidify init <yourtype>
./acidify init <yourtype>
Click to expand...
Click to collapse
Need to run it twice... or mkdir .repo manually once. Either way. First time it creates the folder too late for it to succeed, so easiest thing to do is just run it twice. And we copy the config.sample, which will build for our phone but doesn't have a working directory set, and then force it to use the current directory as the build folder, so we keep everything nice and neat.
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Also, depending on how much you care about things, might want to sudo -s. Or not.
Theraze said:
It's not listed anywhere, but... First run setup.Need to run it twice... or mkdir .repo manually once. Either way. First time it creates the folder too late for it to succeed, so easiest thing to do is just run it twice. And we copy the config.sample, which will build for our phone but doesn't have a working directory set, and then force it to use the current directory as the build folder, so we keep everything nice and neat.
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Also, depending on how much you care about things, might want to sudo -s. Or not.
Click to expand...
Click to collapse
I am stuck at the acidify init successfully downloading all but 3 projects. When I try to re-run "acidify init" or "acifidy sync", I'm geting this:
Fetching projects: 99% (311/314) Username for 'https://github.com': Username for 'https://github.com': Username for 'https://github.com':
I can enter user name, but it won't accept my password
I will clean my work folder and try to re-fetch all...
Edit: I think following 3 commands will never complete:
galets 21984 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 21986 21984 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_libhardware
galets 21996 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 21997 21996 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_msm7k
galets 22024 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 22025 22024 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_qcom_media[/QUOTE]
I verified that my password is 8 characters (there's apparently a bug in git)
That's an issue with AOKP, not Acidify. You'll have to wait until they fix all the things they have tendency to break.
Sent from my super fancy SGH-T959V with Magic Debugging Powers
On AOKP build failures, you might want to follow [REF] Building AOKP -- Transient Issues -- 2012/09/18
Though until someone uploads the ics framework files, you're stuck. So... like I said...
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Click to expand...
Click to collapse
Watch that thread jeffsf pointed to and when FBis251 or someone actually uploads a working copy of the files, THEN you can build AOKP. Or you can build CM7 or CM9 right now.
I want to get Ezekeel's patches of BLN, live oc to build my first jellybean kernel.
I have currently applied _thalamus' work.
I tried this http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/
On https://github.com/Ezekeel/GLaDOS-nexus-s/tree/bln
But I get
git remote add remoterepo https://github.com/Ezekeel/GLaDOS-nexus-s.git -b bln
fatal: Not a git repository (or any of the parent directories): .git
[email protected]:~/patch/bln$ git remote add remoterepo https://github.com/Ezekeel/GLaDOS-nexus-s.git
fatal: Not a git repository (or any of the parent directories): .git
[email protected]:~/patch/bln$
Click to expand...
Click to collapse
Am I doing something wrong?
you have to git merge the branch of Ezekeel's repo that has the feature you want
git remote add remoterepo http://.....
git remote update
git checkout your working branch
git merge remoterepo/BLN (e. g.)
:highfive:
Hmm thanks. I am trying it out now.
I hope it's compatible with Jellybean.
I tried to update the kernel to 3.0.38 but it prompts me every time if I am sure. And sometimes I have errors patching.
djjonastybe,
Thanks for your "How to compile a kernel" tutorial in the developers section. Using that I was able to 'roll my own' kernel the way I wanted it (stock JB kernel merged to latest linux version + voodoo.)
Although I didn't use it, I experimented with Ezekeel's BLX. I was unable to 'git merge' it into the aforementioned kernel from the BLX branch. (Every file had a conflit, and although git has a steep learning curve I am guessing the reason is it was merged into ICS.) I was able to get it to work using 'git cherry-pick', and I am guessing BLD is the same.
Once I had compiled my kernel I used 'dsixda-Android-Kitchen' as a frontend to unpack boot.img. I replaced zImage and repacked boot.img.
I registered with this forum to ask a question, but through trial and error I found that that it was important to use the ramdisk associated with the target ROM, rather than the stock ramdisk. Many CWM updater-scripts do this 'on the fly'...
(I was surprised to see that several kernel installers also copy a few .ko modules into /system/modules. One was for BLN, but I did not research the reason for the others...)
...
I have been reading [and reading] and 'crackflashing' for around a year, but this is my first post. I would like to thank everyone who shared up-to and including the following: CM team, koush, ezeekel, thalamus, adamg, kibmcz, legolas93, Steven676, AOKP team and mathkid. (I couldn't think of everyone, but if you have contributed then thank you!.)
--== HurryNwait ==--
Nexus S + CM10 v1.10 + my custom kernel
[INTRO]
Well, hello there stranger.
This is a development only thread. If you are having a problem building, installing, using the kernel or it's source code, please turn to the Q&A Thread.
If you found a bug and have a log from dmesg or logcat, or have a patch, this is where to comment on development activities.
I'm trying to keep this a short OP, because you all know the problems we've had in the past with this kernel, so @jeffsf and myself are going through the stock drop and cleaning out any unused code so we can easily port forward and possibly figure out aries kernel issues.
Currently, as you can see in the OP title, this is for GingerBread. I know, nothing terribly new. But that tag will change. Right now, it's in the cleanup phase. This OP will probably change a lot to keep up to date with the development conversations that will follow in this thread.
I've already started a bunch of work, but I'm always open to help.
[GOALS]
Clean out any code that is different from v2.6.35.7 that has nothing to do with SGS4G.
Clean up code that is different (inline) to use "#if defined" so that this platform could be disabled, and another platform could be enabled cleanly with Kconfig. (think about multiple phones in one source tree...)
Once code is cleaned up (section mismatches removed, warnings caused by code we've added, etc..) and tested, porting to newer kernel versions like 3.0.x and 3.4.x becomes much easier.
If you plan on helping out, I have a few rules:
This is a long term project. I'm looking at 3.4.x and 3.10.x android kernels. You won't find fancy bells and whistles here. As this project progresses, releases will be cut. At release points, other developers are welcome to fork and add features. I will start different branches for 'porting' and for 'features' to keep track of the two activities so we can keep moving forward.
Every commit must be tested. Make sure it boots, and area's you've affected work properly. No new build warnings or section mismatches.
Try to keep your commits targeted... An example of a non targeted commit was the v2.6.35.7 merge I made. I also cleaned up a few things that should have been done in separate commits. Oh well. The rest of the commits I made were exactly what I mean.
make it awesome, I think this device can keep working for a while and be up to date!
Try to use ./scripts/checkpatch.pl to check the changes you made to a file. Fix the errors and warnings, only on code you have changed. If it is a lint error/warning in code that is upstream code, leave it alone. We are not maintaining the kernel, we are only maintaining the changes we are making to it.
Either use 'git format-patch' to send me patches or fork the repo, make changes to your local fork, and open a pull request.
[PROGRESS]
I've cleaned out a ton of other platform cruft that has nothing to do with SGS4G, as seen here.
I tried to merge 2.6.35.14, but tfsr broke. So moving to MTD.
It would be nice to not have to rebuild a ROM over and over. Anyone feel up for making a GB MTD rom?
[BUILDING]
I use linux to build. Other platforms: Your Mileage May Vary!
Code:
sudo mkdir -p /build/galaxys4gmtd /opt
sudo chown -R $(id -un):$(id -gn) /build /opt
curl -O ~/Downloads/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 http://sourceforge.net/projects/bhundven.u/files/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2/download
cd /opt
tar jxf ~/Downloads/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
cd /build/galaxys4gmtd
git clone https://github.com/bhundven/android_kernel_samsung_galaxys4gmtd
git clone https://github.com/bhundven/android_initramfs_samsung_galaxys4g
cd android_kernel_samsung_galaxys4gmtd
git checkout -b android-samsung-2.6.35-galaxys4g-scrub-deux origin/android-samsung-2.6.35-galaxys4g-scrub-deux
./build.sh
the file in 'out/galaxys4g/arch/arm/boot/zImage' is the kernel image you'd flash to the kernel partition.
[BRANCHES]
I have a few guidelines for branching and branch names.
Name them what they are. Long branch names allow everyone to read it and know what it is.
A few of them are upstream like 'linux-2.6.35.7' is a branch of the tag 'v2.6.35.7'.
Ones that are named too similarly, like the aosp and cyanogen(aries) 2.6.35 samsung kernels get the name prepended for clarity:
Code:
cm-aries_android-samsung-2.6.35
aosp_android-samsung-2.6.35-gingerbread
As for working branches, I name it:
android-samsung-<version>-<board>-<branch topic>
Where version would be the full minor version, like 2.6.35 or 3.0. Not the full version including the stable version number.
Board is the board name. 'galaxys4g' is what we've always used for BML kernels, and 'galaxys4gmtd' for MTD kernels.
This kernel will eventually be MTD, hence the repository name.
The branch topic is something you could describe in <= 3 words.
Current branch topics:
scrub: no numbers, so the original addition of the sgs4g code.
upgrade: merged in the linux-2.6.35.7 branch (technically, the v2.6.35.7 tag in this case)
scrub-deux: After merging v2.6.35.7, there are a few rather large commits with the initial source drop and file permission fixes that make it hard to diff through commits. This branch was branched from tag v2.6.35.7 and had the difference of 'linux-2.6.35.7..android-samsung-2.6.35-galaxys4g-upgrade' applied to HEAD. This allows us to start chopping up that one large patch into smaller commits that are more easily merged/rebased to other branches (for porting).
Future branches coming up will have to do with the results of cutting up the one patch. One for drivers (each driver), one for sound, one for architecture specific, etc.
Once things are broken down this way, a lot of code will have been cleaned up and as I said in the scrub-deux branch description, it will make merging, rebasing, and cherry-picking these changes for porting purpouses.
[RELEASES]
There are currently no planed releases.
Since it looks like I'll have to start moving to MTD sooner rather then later, I'm also looking at skipping ICS and JB, and going to KK.
As for testing the build, I'm using the Stock_KJ6_+_root-One-Click.jar
Let the rom settle after it boots up, and power it off. Heimdall flash the built zImage. TADA.
If you don't understand what I just said, don't forget to ask in the the Q&A Thread.
[SOURCE]
Source
Wiki
Issue Tracker
If you're interested in helping out, or just got here because you searched "flash kernel" or the like, I prefer heimdall to manage "raw" flashing. I find it to be very robust and also runs on Linux and Mac OS.
http://forum.xda-developers.com/showthread.php?t=755265
http://glassechidna.com.au/heimdall/
https://github.com/Benjamin-Dobell/Heimdall
This is not a one-click kind of thing (though you could use one of the one-click installers to get back to GB).
I'm a command-line guy for simple tasks, so I use (v1.3.x)
Code:
heimdall flash --kernel path/to/kernel/boot.img
Edit -- When I tried to flash on my Mac using v1.4.0 (ignoring @bhundven warnings in the next post), I found that I needed to match the returned PIT partition name to get it to work:
Code:
heimdall flash --KERNEL path/to/kernel/boot.img
Make sure for now that you only use the 1.3.1 version found here.
checkpatch.log
Attached to this post is the latest checkpatch.pl output of the files different from upstream.
Generated by:
Code:
for i in $(git diff --name-only linux-2.6.35.7..android-samsung-2.6.35-galaxys4g-upgrade); do
echo -e "\nRunning checkpatch.pl on: ${i}\n";
./scripts/checkpatch.pl -f ${i};
done 2>&1 | tee out/checkpatch.log
Those of you maintaining unofficial ROMs that need some device specific patches to the android platform that are not (yet) merged into the official sources often face the same problem: When syncing with upstream you either have to cherry-pick your patches again manually, or for those changes that are not committed there may be merge errors.
Additionally, when there are many patches in various repos it can get hard to keep track of them.
I faced the same situation while working on my phone, which needs changes not merges into any official sources except for NamelessROM. And those of you who know me, know that I like scripts doing the work for me.
So I decided to write a tiny script to do all that for me.
Sure, I could have written a script like
Code:
cd frameworks/base
git cherry-pick <blah>
git cherry-pick <blah2>
cd ../../system/core
git cherry-pick <blah3>
But I just don't like hardcoding, and maintaining the script would also be way, way harder.
So I came up with this solution:
Storing the fetch URLs as well as the commit IDs in arrays. Then I can call one after another fully automatic via for-loops.
One issue remained, though: if a cherry-pick fails the next commits would also fail. Which is why the repo gets automatically reset if a cherry-pick doesn't apply properly.
An example script can be found HERE or in the attachments.
Now, the most important part for you: How do you make the script compatible with your ROMs sources?
There are just a few values you have to take care of:
Code:
##### Definable values
remote_name="p880-dev_autofetch"
paths="frameworks/native frameworks/base frameworks/opt/telephony"
commit_id[frameworks_native]='8465cdba74a038bb29598cfb4f48754b83124f48 208b1fcc0df405dc15582798c4e5406ba16201a9 49beaf826eb1c4eae3fe3202ef682a5973213c2d c83b9661c0fca41a5f43473def58379c7d7ae7d7 0c880a230ef4331cc071d45b6b06a8b0572c5a8f'
commit_id[frameworks_base]='45b92f41db68285e87980fafaa263511a6568705'
commit_id[frameworks_opt_telephony]='e7490c2c565d388212d84f627fb59c2bcccf8d61'
repo_url[frameworks_native]='[email protected]:laufersteppenwolf/android_frameworks_native.git'
repo_url[frameworks_base]='[email protected]:laufersteppenwolf/android_frameworks_base-1.git'
repo_url[frameworks_opt_telephony]='[email protected]:laufersteppenwolf/android_frameworks_opt_telephony.git'
#####
remote_name specifies the name that should be used for fetching (doesn't really matter, it just helps keeping track of what this remote is)
paths specifies the paths to the repos the script is gonna cycle through.
commit_id[name] specifies the commit IDs of the repo "name". While "name" is the path to the repo, but with underscores instead of slashes. Example: if your path is "system/core", the name you have to specify would be "system_core".
repo_url[name] specifies the URL of the repo to fetch. The naming is the same as in commit_id with underscores.
That's it. You can specify as many repos as you need, the script will cycle one after the other.
For an example on how to update the script with more repos, you may want to take a look at THIS commit
Now, how to use the script?
It's as simple as it could be:
Set up the build environment (. build/envsetup.sh)
Execute the script from whereever you want (. cherry-pick.sh)
If you're running the script for the first time or the fetched repo needs an update, you have to add the --fetch argument to (re-)fetch the repo again. (. cherry-pick.sh --fetch)
If you happen to have questions or suggestions, please feel free to let me know!
Mine!
@laufersteppenwolf Nice bro!
Interesting idea.
Will test it soon.
Does it also work for revert commits ?
(They usually take me to nano and I have to ctrl+x to apply them)
Thank you
m0d said:
Interesting idea.
Will test it soon.
Does it also work for revert commits ?
(They usually take me to nano and I have to ctrl+x to apply them)
Thank you
Click to expand...
Click to collapse
Yeah, sure, with a few modifications the script should also be able to revert commits
EDIT: Feel free to test with THIS script after you specified your commits you want to revert. But please note that I did not yet test it.
laufersteppenwolf said:
Yeah, sure, with a few modifications the script should also be able to revert commits
EDIT: Feel free to test with THIS script after you specified your commits you want to revert. But please note that I did not yet test it.
Click to expand...
Click to collapse
I am trying to set up the script,
How must one go setting up repo url for:
https://android-review.googlesource.com/#/c/104728/
5a6037f1c8b5ff0cf263c9e63777444ba239a056
git fetch https://android.googlesource.com/platform/hardware/qcom/bt refs/changes/28/104728/1 && git cherry-pick FETCH_HEAD
I tried checking for the following,
commit_id[hardware_qcom_bt]='5a6037f1c8b5ff0cf263c9e63777444ba239a056'
repo_url[hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'
repo_url[hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'
commit_id[platform_hardware_qcom_bt]='5a6037f1c8b5ff0cf263c9e63777444ba239a056'
repo_url[platform_hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'They all gave me:
Code:
*************************************************************
* Entering hardware/qcom/bt
*************************************************************
*************************************************************
* All commits applied successfully!
*************************************************************
There seems to be an error as it always says - * All commits applied successfully!
But, when I check for the commit changes they are not present.
Also,
Is it possible to have a revert in the cherry-pick script? As in before a particular cherry-pick I need to revert a commit,
so I need to check if the commit is a cherry pick or a revert,
Where as now it is sort of hard-coded:
for commit in ${commit_id[${commit_path}]}; do
sleep 1
cherry-pick "$commit"
doneand
for commit in ${commit_id[${commit_path}]}; do
sleep 1
revert "$commit"
doneAn if else needs to be added somehow,
will try to test once I get the script to start working
Hi there!
I know this thread hasn't had activity for years but it is the only possible resource I find for minimally automating security patching our rom sources... I am new to building and have a couple of viable nougat builds almost ready for Xiaomi Mi Mix, and a third one with more problems. One of the last things I am working on is security patching my working directories and as I have no background in programming or linux or any technical stuff in general, I get quite lost about git cherry-picking, git fetching, patching, merging, etc.
From what I see here this script could make the whole thing easier but I do not know if it works. Anybody out there willing to give me a hand here?
Thanks in advance