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
Well, as an introduction to topic, you could read the following entry:
http://forum.xda-developers.com/showthread.php?t=1296186
So far, when using "-static" directive for compiler, the applications could be compiled without doing of these steps, so why do I try this? Well, a statically linked executable is embedding all the required libraries to itself, so it's generally too huge. Also, if you compile all the applications statically, you probably link the same library (like C library, for instance) twice or more for every application you compile. This is definitely unnecessary.
It's why, for a few days now, I'm trying to compile the whole GlibC suite for Android (ARM devices, to be precise). The motive behind it is simple: since all Linux applications rely on full-fledged C library (rather than trimmed version like Bionic), if I compile it for this device, I can run every application; given that its compiled for the device.
Since it's Linux kernel underneath, we don't have to worry about changing whole system from Android to native Linux (hopefully )
So far what I did was following (I'm going to write the steps more systematically once I've time, so don't worry if those steps are too vague for you ):
1- Make a toolchain for ARMv7 architecture (which Desire CPU rely on). You can use crosstool-ng etc. or (if you're masochistic enough ) try to make your own.
2- Compile GlibC with this new toolchain of yours, store the compiled libraries in a folder where you can easily access (I keep mine at Desktop/glibc-arm for instance)
3- Edit Ramdisk of the Kernel. To do this, first you must extract the boot.img; then extract the ramdisk, edit init.rc to accordingly, so the libraries can be searched in a folder other than /system/lib (say, /data/lib). You can tweak PATH env-variable while you're at it as well . This is necessary because /system partition isn't big enough to carry all GlibC lib in it, so we can copy the library to some other folder (like /data/lib) and then make the system search for libraries there as well. The point is, since I'm using Data2ext; my data is large enough for this. I'd recommend the same to you if you're willing to go on this road.
After the editing of init.rc, reconstruct ramdisk; make a boot.img with it and flash it to the device.
4- Copy the libraries to the folder of you picked.
5- Compile some test apps (like Hello world etc ) with your cross compiler and place them to your device as well.
6- Test if they're running.
What I've found so far, the cross compiled executable (like simple Hello world), when dynamically linked, gives "no such file or directory" error when tried to be run at the device (WTF, right ). However, when when I do run it with the cross-compiled ld-linux.so (the linker of C library) it runs perfectly. So what I should do to overcome this is, somehow inform the system that this ld-linux.so binary should be used.
I'll keep you updated as I try new things
Till next time, happy Android'ing
ADDENDUM 1:
EUREKA! Found the solution! It's as simple as symbolically linking the library folder of your GlibC as /lib to root file system. You can edit ramdisk accordingly to do this process automatically.
Another thing I'm going to try is finding a way to change the path of the dynamic-linker option of my cross compiler accordingly. Apparently, the cause of the problem was the compiler, telling the application to look for the dynamical linker at /lib/ld-linux.so.3; while it was at /data/lib (in my case). I can put ld-linux.so.3 to /system/lib and change compiler accordingly; but I don't know which way would be the best for flexibility: symbolic linking of /lib to library dir; or putting dynamic linker to /system/lib (the dynamic linker can look for libraries at the "custom" libdir already, since $LD_LIBRARY_PATH is already showing it).
Will try some tweaks now. If I can make it all work, I'll see if I can make a flashable zip or something (also will write whole process step by step
-------------------------------------
ADDENDUM 2!!
Well, I kept you waiting a lot, but wow, was this process head spinning. This was the first time I actually wrote a recovery script; first time I had to use AWK, SED or regex; and first time I wrote such a long scripts Well, whatever, we're done for now..
There are two zip files attached to the end of this thread: One is an installer and other is uninstaller. Just flash the recovery zip and reboot the phone. Your native C or C++ applications should run flawlessly (only added support for this two language for now) if all other dependencies are also met
Happy Android'ing guys; and well, I'd appreciate if you'd buy me a beer for that (or just click thanks, or just say thanks.. If you did all of those, you're my hero )
Here is the hero of the post :
Glibc for Android v0.9.5
Uninstaller for GlibC
NOTE: Uninstallers erase only files, not directories. Ergo, you might need to erase them yourself (had to do it for not to erase your own binaries and such).
HERE'S HOW YOU'RE GOING TO MAKE TOOLCHAIN YOURSELF (making a toolchain):
http://forum.xda-developers.com/showpost.php?p=18356849&postcount=5
CHANGELOG
Code:
Version 0.9.5:
* Ramdisk-boot image editing tools are included in the package, for some systems might not have it.
-------------------
Version 0.9.4:
* A bugfix for a script syntax error which causes GlibC to pass the installation checks but make binaries give "not found" error.
* A bugfix for Bash, not working well, so causing system to freeze at boot.
-------------------
Version 0.9.3:
* A major bugfix for the bug that was causing bootloops.
* A bugfix for scripting errors inside the recovery zip, causing half-installation
-------------------
Version 0.9.2:
* A small patch added that will allow GlibC to be installed with Apt-get without problems.
* Made compatible with the Sibere's new Data2SD solutions
-------------------
Version 0.9:
* Moved configuration files from /data/etc to /system/etc
-------------------
Version 0.8.1:
* Removed a symlink which may cause some Android apps use wrong version of library.
-------------------
Version 0.8:
* Complete recompilation.
-------------------
Version 0.7:
* Fixed a bug which causes Sibere's Data2sd unrecognized if Droidzone's flasher is not used
* Fixed a bug with the installation of locales.
* Included a basic busybox binary and flash_image to make library installation successfull in all recovery systems - was causing problems in some systems
-------------------
Version 0.6:
* Standart C++, MPRF, GMG and MPC libraries are added to the package
* Library profiling support is added
* All libraries are recompiled with PIC (position independent code) for better portability.
-------------------
Version 0.5:
* LibGD included in package - it's a picture manipulation library
* GlibC Version 2.14 - I'm sure even your Ubuntu-Debian machines have older versions now :)
* Locale support added. Your C/C++ programs can use it freely.
-------------------
Version 0.4:
* /tmp support added, necessary configurations are done
* Package manager support is implemented, allows users to install to both MTD and SD-ext in coexistent way (no more had to choose!).
* Developed a flexible structure, thus allowing libraries to be installed with a helper application (it's going to be shipped later)
-------------------
Version 0.3:
* Stripped libraries and binaries for make them smaller
-------------------
Version 0.2:
* Installs to the MTD Partition instead of sd-ext. Needed for inital-time programs to run correctly.
-------------------
Version 0.1:
* Initial version
-----------------------------------------------------
Thank you very much for donations of:
Mr. Brochard and Mr. Huemer
I really appreciate it.
Eureka! Found an overcome!
Well, forgot to say this: if you want the compiled applications to be installed to some place if possible, create a "defaultinstall" file under sd-card root and write "EXT" (for sd-card) or "MTD" (for internal MTD storage) to the file (note that all uppercase).
Install manager first checks this file and if not found, uses default setting found in package (which I wrote /sd-ext generally for not-so-essential stuff ). You can use this functionality to override this setting.
Note that, some libraries and stuff cannot be installed to a different location - package manager handles this and acts accordingly; so don't worry about it
PS: The stuff I keep calling Package Manager is actually just bunch of scripts, so it's not like I wrote a whole suit
Sounds Interesting
Some compiled applications!
Well, if we're not going to use it, then why did we compiled it, right?
NOTE: The following packages don't have any specific order of installation: you can install them at any order you wish. The only exception is APT - it should be installed after DPKG, or otherwise your system will think you didn't install it
For those who hates command-line interfaces: DesirAPT (the APT front-end for Android) is here DesirAPT v1.0.0
For those who would like to run Enlightenment WM in Desire - this is the mediator application for Android: LinuxInAndroid APK
Note that it requires APT and it's dependencies, along with super user privilages.
---------------------
PACKAGE: NCurses Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: It's a shell extension library which is used to format shell (or terminal output) like colorful texts, and such. Default shell might not use it (but it's definitely something necessary for new applications like nano, like "new" bash etc.)
HOW BIG IS IT: Approx. 3.4 Mb.
WHERE TO DOWNLOAD: NCurses Lib. 5.5.9
UNINSTALL?: Available at NCurses Uninstaller
CHANGELOG:
Code:
v 0.4.1 :
* Made Compatible with Sibere's new Data2SD solutions.
------------------------
v 0.4 :
* Complete recompilation with UTF-8 and wide-char support
------------------------
v 0.3 :
* Fixed the Sibere data2sd un-recognization bug
* Added flasher files into the binary for support of all recovery systems.
------------------------
v 0.2 :
* Adding package manager support
------------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Bash
DEPENDENCIES: GlibC Library, NCurses Library, Readline Library
WHAT DOES IT DO: It's the main command interpreter for a linux system (also Android). Normally, Android is also shipped with it, but it's a very lightweight and trimmed version (also annoying - it doesn't support tab completion!). This is 4.2 version (latest now).
HOW BIG IS IT: Approx. 3.8 Mb.
WHERE TO DOWNLOAD: Bash 4.2
UNINSTALL?: Available at Bash Uninstaller/reverter
EXAMPLE OF A COOLNESS: You can change your shell label (the one shows before $ or # sign) by assigning PS1 environment variable. For instance, this : PS1="[\w]\$ " (with quotes) will show your current working directory at every prompt
(More at: http://www.lifeaftercoffee.com/2006/10/31/customize-your-bash-prompt/ )
NOTES: The bash will run the commands that you write initially on /etc/profile automatically. You can define your PS1 values, environment variables (be careful to add "export" before them) there for whole system )
Code:
v 0.7.2 :
* Made Compatible with Sibere's new Data2SD solutions.
------------------------
v 0.7.1 :
* Included automatic bash_completion file (stolen from Ubuntu :D) into package - now even apt-get packages are auto completed!
-------------------------
v 0.7 :
* Recompiled with LibReadline for history and auto-completion abilities.
------------------------
v 0.6 :
* Added Locale support
------------------------
v 0.5 :
* Complete recompilation with new schematics
* HOME directory set to /data/home by default
------------------------
v 0.4 :
* Fixed the Sibere data2sd unregnization bug
* Added flasher files into the binary for support of all recovery systems.
------------------------
v 0.3 :
* Added package management support
---------------------
v 0.2.2:
* Added ENV variable, thus support for /etc/profile shell starter file. You can define new environment variables there which is valid for all system (you don't need to change ramdisk each time now!)
--------------------
v 0.2 :
* "Jobs" support fixed
---------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Busybox Binary
NOTE: Busybox with GlibC dependency is no longer supported, because package update mechanisms require some command interpreter independent of the updated package. In order to support GlibC Update, Busybox binary will no longer be updated with GlibC support. I recommend you to revert back to static, or Bionic-linked Busybox with the link below.
UNINSTALL: Available at Busybox old version reverter
---------------------
PACKAGE: Zlib Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: It's compression library that is used with various applications like Git, Apt, DPKG etc.. It's recommended to keep it there
HOW BIG IS IT: Approx. 350 Kb.
WHERE TO DOWNLOAD: ZLib 1.2.5
UNINSTALL?: Available at ZLib Uninstaller
CHANGELOG:
Code:
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Fixed a bug causing system library to clash with the installed one
* Fixed a bug causing Segmentation Faults in some cases
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: ReadLine Library
DEPENDENCIES: GlibC Library, NCurses Lib.
WHAT DOES IT DO: Readline is a command line and history manager library that's used in some command line tools like socat. I personally don't know what else uses it
HOW BIG IS IT: Approx. 1.4 Mb.
WHERE TO DOWNLOAD: Readline 6.2 - v0.1
UNINSTALL?: Available at Readline Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: OpenSSL Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: OpenSSL Library is Secure Socket Library that is used in various secure applications and web browsers.
HOW BIG IS IT: Approx. 5.9 Mb.
WHERE TO DOWNLOAD: OpenSSL 1.0.0e
UNINSTALL?: Available at OpenSSL Uninstaller
CHANGELOG:
Code:
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Fixed a bug causing system library to clash with the installed one
* Fixed a bug causing OpenSSL to do Segmentation Fault and crash
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: APT - Advanced Package Tool
DEPENDENCIES: GlibC Library, Curl Library, Zlib library
WHAT DOES IT DO: APT is a front-end for DPKG which installs, removes, updates etc. packages easily. APT also supports dependency tracking, and automatically removal of unneeded packages.
HOW BIG IS IT: Approx. 1.8 Mb.
WHERE TO DOWNLOAD: apt 0.8.10.3
UNINSTALL?: Available at apt Uninstaller
CHANGELOG:
Code:
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Apt now assumes required packages are pre-installed; thus doesn't re-download them unnecessarily ..
* Changed repo host - configuration in sources.list is changed.
--------------------
v 0.1.1 :
* Configuration files are added. Apt-is ready to use out-of-the-box now..
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Cryptography Package
DEPENDENCIES: GlibC Library , Zlib Library, PTH Library, Readline library
WHAT DOES IT DO: This package contains some cyrptographic libraries necessary for various applications. If you're to use APT, it's recommended to install this package, for since it also carries GPG package inside. Package includes
GnuPG (2.0.18), LibGPG-error (1.9), LibGcrypt 1.5.0, LibKSBA (1.2.0), LibAssuan (2.0.2)
HOW BIG IS IT: Approx. 8.2 Mb.
WHERE TO DOWNLOAD: crpyto package
UNINSTALL?: Available at crpyto Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: cUrl
DEPENDENCIES: GlibC Library, OpenSSL Library, Zlib library
WHAT DOES IT DO: cUrl is a secure web client that supports HTTPS protocol. Package includes also libcurl which provides secure web connection API
HOW BIG IS IT: Approx. 916 Kb.
WHERE TO DOWNLOAD: cUrl 7.23.1
UNINSTALL?: Available at cUrl Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Re-Initial Release
---------------------
PACKAGE: Dpkg - Debian Package Manager
DEPENDENCIES: GlibC Library, Zlib library, Tar binary, Linux Utils
WHAT DOES IT DO: Dpkg is the main package for Debian package managing structure. DPKG is the responsible application for installing, removing and updating packages. Using with Apt (or other front-end) DPKG allows users to install new packages easily.
HOW BIG IS IT: Approx. 7.5 Mb.
WHERE TO DOWNLOAD: dpkg 1.16.1.2
UNINSTALL?: Available at dpkg Uninstaller
CHANGELOG:
Code:
v 0.4 :
* Fixed a bug which was causing GlibC not to upgrade from APT.
--------------------
v 0.3 :
* Links renewed
--------------------
v 0.2.1 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.2 :
* Fixed a bug that causes some big archives not to install
* DPKG now informs system that GlibC, OpenSSL, Ncurses libraries are already installed (necessary for DPKG anyway)
---------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: PTH - Portable Threads Library
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: PTH is a POSIX compliant thread library that is used in some linux applications.
HOW BIG IS IT: Approx. 251 Kb.
WHERE TO DOWNLOAD: pth 2.70
UNINSTALL?: Available at pth Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Tar Archiver
DEPENDENCIES: GlibC Library
WHAT DOES IT DO: TAR is and old and multi-purpose compression format used in various places. This tar suite is designed to be 100% compatible with the PC one (busybox one is not so good at this).
HOW BIG IS IT: Approx. 3.7 Mb (1 MB in System partition).
WHERE TO DOWNLOAD: Tar 1.23
UNINSTALL?: Available at Tar Reverter
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
---------------------
PACKAGE: Linux Utilities
DEPENDENCIES: GlibC Library, Ncurses Library
WHAT DOES IT DO: This package includes low-level linux tools that is necessary for a system to run in well manner. Busybox do provide many of those, but they are quite crippled versions - so high level applications may crash using busybox ones (like DPKG).
HOW BIG IS IT: Approx. 5.6 Mb
WHERE TO DOWNLOAD: Linux Utils 2.20
UNINSTALL?: Available at Uninstaller
CHANGELOG:
Code:
v 0.1.2 :
* Made Compatible with Sibere's new Data2SD solutions.
--------------------
v 0.1 :
* Initial Release
Where the hell is the other packages?
Since we know have an APT repository for our distributions, in order to follow all the packages from one source, they won't be published in zip form anymore. In order to obtain them, or update them if you have older versions, you can use apt :
Code:
apt-get install <packagename>
The packages distributed can be list with the following command:
Code:
apt-cache dumpavail | grep Package:
OR, you can use DesirAPT to do these works.
See you around!
NOTE
Before you start anything, don't forget to install build-essentials package. Under ubuntu, the command necessary for it is: sudo apt-get install build-essential - I don't know about other distros..
-------------------------
Well, as promised, now we should write the steps; right?... Now, before we begin, I should really warn that the process is really head spinning if you're to do all by yourself; so take heed to the warnings I give you (I learned the hard way)
Well, first thing is first, we need a Cross Compiler Toolchain, properly built that allows us to build applications, libraries etc. There is one toolchain that's already given to you with Android Native Development Kit (called NDK) but that one is quite restricted because it's built with support for Bionic (trimmed C library that is presented in Android), not Glibc or uGlibC. If you want to develop more native-like applications (especially linux programs) you need GlibC or uGlibC. You can try to build these libraries with that toolchain too, but don't do that, because it's going to fail as well. The reason is that some sort of Chicken-Egg problem is eminent in GlibC-GCC compilation
Let's put the steps to be followed first to build a nice toolchain. I assume you're using Linux - because the tools are developed for this platform only. If you're going to use them in Windows, you need Cygwin or such tools but I can't supply help about that, for since I didn't use them before at all. Google is your friend about this
(Note, the packages I wrote at this list are available at GNU's website www.gnu.org freely, open source)
1- We're going to build "binutils" first. This package includes some important stuff like assembler, linker, archiver (for libraries) etc..
2- We're going to build GCC's prerequisites. These are GMP, MPRF and MPC packages.
3- We're going to build a "bootstap" gcc (God, I hate that name. I like to call it "naked gcc" more ). This GCC just converts source codes to pure assemblies: thus cannot generate linkages or such. We're going to use it to build "actual" tools we're going to use.
4- We're going to extract Kernel source/headers - use Desire Kernel's here. There is some copying, and such to be done tho.
5- We're going to make GlibC headers installed, which will allow us to build more "complex" gcc, which can link applications with those libraries when the library binaries are given (so such thing is there yet, but we fool it )
6- We're going to build a very limited GlibC which will give us support for building more "complex" gcc.
7- We're going to build GCC again. This is called "Pass 1 GCC" or "GCC Stage 1". This GCC can link applications to libraries, with the information in Kernel headers and library headers (it's why we give it the headers, so it can create applications suitable with the Kernel architecture).
8- We're to build actual GlibC now. This glibC will be used for our compiled applications, statically or dynamically. You can, at the end of this step, copy the files to your devices and they would work, but picking files here is harder, so I'd recommend you to leave this alone for now
9- We're going to build "Pass 2 GCC" or "GCC Step 2" This is a full fledged GCC that can do anything we want
Complex isn't it? This is precisely why I recommend you to use Crostool-NG. The other tools (like Buildtools or Crosstool) (sadly) don't create GlibC based toolchains, or use old versions of them, so using this one is recommended. This package automatically will download, setup and link your all toolchain without you worrying about something (believe me, this is what you need. I gave 8 days without this to create a working GCC and Crosstool-NG made another one to me in 50 minutes. )
Well, however, Crosstool-NG won't create "nice" applications (they'll run allright, but they won't be optimized) without some settings done, so, let's go there. First, we need to install Crosstool-NG itself. To do that; go to http://crosstool-ng.org/ website, download and extract it to some place. Even though the steps are written in Crosstool website, you don't need all commands there (like setting PATH is unnecessary). The commands you should use is, after CD'ing to the Crosstool dir;
./configure --prefix="</some/place>"
make
make install
cd "</some/place/bin>"
./ct-ng menuconfig
I used prefix as /home/ahmet/crosstool for instance. Note that this is not going to be where your toolchain is, this is where your "toolchain creator" is .
---- NECESSARY KERNEL HEADER CHANGES ----
OK now, before we start compiling; we need to make some folder moving, copying etc. in Kernel directory. This is needed, because tree structure changed a tad in 2.6 kernels and unless you compiled this kernel before, some directories won't be in their correct place for our cross compiler. Switch to the directory which you extracted the kernel image. Now, from now on, I'm going to assume you're an Qualcomm/MSM board (like Desire, Nexus One etc.) user; but if you're not, change my descriptions accordingly:
1- Go to <kernel dir>/arch/arm/include folder. Copy "asm" directory and paste it into <kernel dir>/include directory.
2- Go to <kernel dir>/arch/arm/mach-msm/include folder. Copy "mach" directory and paste it to <kernel dir>/include/asm directory. It's going to complain that there is another mach folder there and will ask if you want to merge/overwrite. Say yes to all questions.
Now our kernel headers folder is showing a Desire device. Note that if you're not a Desire user, you should use your cpu folder instead of ARM and your board manufacturer in mach-xxxxx instead of mach-msm.
Note this kernel directory, we're going to use it to configure crosstool..
--- CONFIGURING CROSSTOOL ---
After issuing the commands, the crosstool-ng will give you a configuration menu. Most of the setting here are unchanged, but the ones you should change are given below.
1- Paths and misc options
a) Try features marked as EXPERIMENTAL (this is needed to build a toolchain with the latest GlibC support) -> Enabled
b) Local Tarballs directory -> The folder address that you want downloaded stuff to be kept. You might use them again (like for compiling GlibC again for device, you will use them
c) Save New Tarballs -> Enabled ( so that new downloaded files aren't erased )
d) Working Directory and Prefix directory -> Normally you don't have to change them, but you can if you want to install your toolchain to some other location. CT_TARGET signifies your target name (like arm-msm-linux-gnueabi - arm is cpu model, msm is vendor (can be anything), linux is showing the binaries are for linux system (you can use android, but then you'll get not GlibC but Bionic) and gnueabi shows you're going to use open-source EABI structure for your executables. The other option is ELF but EABI is more flexible (because also supports ELF).
e) Strip all toolchain executables -> do it if you don't want to debug GCC itself. this makes toolchain smaller of size, and a tad faster.
The other options can stay the way they are, or you can change them accordingly here. You can get help with ? key, and if you don't understand anything, just leave them default - there are very complex things there that you don't need to know if you're not planning to be a expert on subject
2- Target options
a) Target Architecture -> arm should be selected, cos Desire uses ARM. If you plan to make toolchain for, say, powerpc, pick that.
b) Endianness -> Should be little. ARM processors in Desire uses little endian system.
c) Architecture level -> "armv7-a" this is should be written. Desire uses ARMv7 based instructions and if you leave here empty, the applications will be built with armv5 support - they're still going to run but not use advanced v7 features.
d) Use Specific FPU -> "neon" . Desire uses NEON structure for floating point arithmetic, and if you leave here empty, the applications will not use Desire's FPU abilities (everything will be software based, which is slower)
e) Default instruction set mode -> arm . You can use thumb here for allegedly faster code but not every build system supports it. Leave it ARM.
f) Use EABI -> enabled. EABI is necessary for most flexible desing of binaries.
The other settings be as they were.
3- Toolchain options
a) Tuple's vendor string -> You can leave here empty if you don't want to; it's not necessary to use a string here. I used "msm" but you can write anything. This string here is used in toolchain name as arm-xxxxx-linux-gnueabi, so make it short, I recommend
b) Tuple's alias -> make it something short like "arm-linux" This alias string is used to make calls to your toolchain easier. Instead of writing arm-msm-linux-gnueabi-gcc everytime, you can use arm-linux-gcc to compile your applications. Can write anything here (like toolchain if you want to use toolchain-gcc to compile your applications)
The other settings can stay as they are, for since default values are the best in our case. You can tweak them only if you know Desire cpu like the back of your hand
4- Operating system
a) Target OS -> Use "linux" if you want the applications to run in Android and Linux; use "bare metal" if you're to compile low level applications which won't use linux headers. Default is linux.
b) Get Kernel headers from -> say "pre installed" because otherwise it's going to download standard Linux headers from internet. We needed some changes, so this option is compulsory to be "pre installed"
c) Path to custom headers directory/tarball -> Path to your kernel source folder - which you made changes above. WARNING: I say specifically extracted, because standart tarball won't work for us. We're going to make some changes in kernel directories, which is non-standart (Instructions were above).
d) This is a tarball -> No . We're going to use extracted folder.
e) Build shared libraries -> say "yes"; because we want dynamic linkage, not static one
f) Check kernel headers -> say "no" otherwise some unnecessary check causes compilation to stop.
5- Binary utilities
a) Binutils version - pick the latest one, 2.20.1a. If you use older versions with newer GCC/GlibC, it's not going to succeed.
Leave others as they are, they are not big deal..
6- C Compiler
a) GCC Version -> pick 4.6.1 for since it's the latest and most bug free. Just stay away from 4.5
b) Pick the languages you want support for. I've read online that Java is a tad troublesome in Android platform, for since Java in Android uses Dalvik, not Sun systems. You can try it at your second toolchain if you want Definitely pick C++ tho
c) Link libstdc++ statically -> say yes; it really saves you from big configure scripts later - apparently needed to avoid PPL problems as well
d) Compile lidmudflap/libgomp/libssp -> say no. These libraries are not the most suitable libraries for ARM platform (at least at cross-compiler level. You can compile them later, if you want, with your cross-toolchain.)
You can leave others as default
7- C library
a) C library -> gLibC (recommended). You can use other libraries which are eGlibC (embedded Glibc, like Bionic) and uGlibC (micro-glibc) too, but GlibC is the most spanning solution above those. The libraries are bigger, but they support more.
b) glibC version -> Use 2.13 (experimental) it compiles just fine, and you get a new version of GlibC. Not the newest, but that's ok
c) Threading implementation -> nptl (recommended) . You can use linuxthreads too, but nptl is more advanced ( like giving support to Thread-Local-Storage and such)
d) Force Unwind Support -> Enabled . If you don't use this option, for since we're making this toolchain from scratch, it's going to give you error during compiling that it couldn't find necessary headers (we're building them now, dumbass!)
Leave others default if you don't know what they're about
8- Companion Libraries
Well, go and pick the latest versions, even though when it says "Experimental", otherwise your GCC compilation will give you error about these libraries being old.
After setting these settings, press ESC key twice till it goes way back and ask if you want to save configuration; say yes.
--- STARTING COMPILATION ---
Now to start compilation write
./ct-ng build.
This is going to take approx. 45 minutes, so go watch some episodes of Big Bang Theory or something. Normally, there should be no errors but if there is; most probably either you made a wrong configuration, or didn't set your kernel folders well. Try again with other settings, google your problem etc..
After this process, you're going to have a cross-compiler at your use at /home/<username>/x-tool/arm-<vendor>-linux-gnueabi/bin folder. Note that Crosstool-NG automatically makes this folder read only to make you prevent screwing your toolchain You must edit your path variable to show "/home/<username>/x-tool/arm-<vendor>-linux-gnueabi/bin" folder as well for less headaches during compiling later
Whilst compiling other application, most used configure options you're going to use is "--host=arm-<vendor>-linux-gnueabi" and "--prefix=/some/folder/you/want/this/application/copied". After compilation, you can send binaries to your phone from prefix folder.
More options about GCC and Configure is available at GCC and Autoconf man pages; check them as well
Happy cross-compiling people
Woah, amazing work, congrats!
Sent from my HTC Desire using XDA App
Interesting..It answers some of my unanswered queries regarding cross compiling.. Thanks...Please keep documenting your progress.
THIS POST IS ONLY FOR THE BRAVE MAN
These are packages which are compiled; but not installed and/or tested by myself. Please test them and inform me if they work (PM me if they work or not; it's better that way ).
--------------
NO PACKAGES HERE! Frankly, I did test virtually all of them. They might not work as expected maybe, but at least they don't impede functions of device
Developer Log
Now while preparing a suitable (and as flexible as it can) recovery zip; I realized that instead of editing ramdisk, I can also use init.d script to link /lib to /data/lib. This also allows some flexibility to user (i.e. move library folder around -if needed- and edit init.d script accordingly and still have a running system).
What baffles me most is PATH env-variable. Apparently, if I set it at init.d level, it's not exported quite well - apparently, there is a user mode switch between init.d script run and ramdisk loading process (because PATH variables at Ramdisk are exported to all applications, whilst init.d ones are not) and the only way to set PATH variable for all processes is editing Ramdisk (AFAIK)...
And another point: what if kernel doesn't support init.d? (Go to hell if you're reading this post with a kernel which doesn't ) Ramdisk solution is quite general (i.e. works for everyone) but it's a little harder to edit with scripts and not as flexible as init.d method. I think it's safe to assume that there is init.d support at this level
Maybe I can create two versions (init.d one and ramdisk one) of recovery zip's.. Keep in touch guys..
theGanymedes said:
Now while preparing a suitable (and as flexible as it can) recovery zip; I realized that instead of editing ramdisk, I can also use init.d script to link /lib to /data/lib. This also allows some flexibility to user (i.e. move library folder around -if needed- and edit init.d script accordingly and still have a running system).
What baffles me most is PATH env-variable. Apparently, if I set it at init.d level, it's not exported quite well - apparently, there is a user mode switch between init.d script run and ramdisk loading process (because PATH variables at Ramdisk are exported to all applications, whilst init.d ones are not) and the only way to set PATH variable for all processes is editing Ramdisk (AFAIK)...
And another point: what if kernel doesn't support init.d? (Go to hell if you're reading this post with a kernel which doesn't ) Ramdisk solution is quite general (i.e. works for everyone) but it's a little harder to edit with scripts and not as flexible as init.d method. I think it's safe to assume that there is init.d support at this level
Maybe I can create two versions (init.d one and ramdisk one) of recovery zip's.. Keep in touch guys..
Click to expand...
Click to collapse
Well, what's the difference between init.d and ramdisk, when init.d support means running busybox runparts from ramdisk?
Droidzone said:
Well, what's the difference between init.d and ramdisk, when init.d support means running busybox runparts from ramdisk?
Click to expand...
Click to collapse
Well the difference is caused by Unix variable propagation.
Normally, when ramdisk is loaded and init.d scripts are starting to run (with run-parts binary) the exported variables are valid only for the scripts that run-parts do run. Since Linux only allows child processes to inherit variables from host, when runparts finishes job; defined variables within the scripts vanish.
When you add variables to Ramdisk (init.rc) directly, since variables become declared from init directly (and since init runs all the processes on boot) the variables automatically become available for all processes.
That's the difference I meant
Got it..So the variables from init.rc persist till shutdown..
Droidzone said:
Got it..So the variables from init.rc persist till shutdown..
Click to expand...
Click to collapse
Precisely. It's why the variables (even those which defined by export keyword) are vanished when the system booted up (unless defined in ramdisk)
Well, I've gotta learn RegEx one day anyways
Recovery zip is done! Now, I should test it on my device first
I'm also going to make a uninstaller script I think. It's really messy to clean this up otherwise
Android binaries and dependencies
I've examined the dependencies of all the binaries in /system/bin and /system/xbin in Android system. Too sad that the list contains some non-standart libraries (that's not that bad, sure you can find their sources).
Also, another problem is that you need to compile the binaries themselves from the source code as well (with the GlibC libraries) - which is near to the compiling the whole ROM itself - I'm not even sure if we can find source code (will check the Android source code itself when I've time)
The dependencies in my system, for instance, are as follows:
So that's a no-go for people with closed source system...
@theGanymedes, do you know if the system can mount ext4 at init.rc level (on early init) without using busybox?
Well, it can, but the kernel needs ext4 modules (or direct support). I checked the native mount source, it actually does nothing much more than simply calling kernel's ioctl or mount system call..
I think a simple tweak at ramdisk is all you need for that (and a supporting kernel, of course )
Weird thing about previous issue is, I have the source codes of most utilities, I can compile them too, but I don't have proper makefiles and I'm too lazy to write them myself - that's a lot of trial and error.
Well, apparently, we're not going to be able to switch from Bionic to Glibc completely. I think I can make them coexist tho.
theGanymedes said:
Well, it can, but the kernel needs ext4 modules (or direct support). I checked the native mount source, it actually does nothing much more than simply calling kernel's ioctl or mount system call..
I think a simple tweak at ramdisk is all you need for that (and a supporting kernel, of course )
Click to expand...
Click to collapse
Yup, my compiled kernel has direct support.
This is how mtd is mounted..
mount yaffs2 [email protected] /data nosuid nodev
And this is how I mount ext4 from init.d:
/system/xbin/busybox mount -t ext4 -o barrier=0,noatime,nodiratime,nosuid,nodev,nobh,nouser_xattr,noauto_da_alloc,commit=50 /dev/block/mmcblk0p2 /data
I need to change it to init.rc (init) language...
theGanymedes said:
Weird thing about previous issue is, I have the source codes of most utilities, I can compile them too, but I don't have proper makefiles and I'm too lazy to write them myself - that's a lot of trial and error.
Well, apparently, we're not going to be able to switch from Bionic to Glibc completely. I think I can make them coexist tho.
Click to expand...
Click to collapse
Earlier this month, I was trying to compile dosfstools for Android. But got stuck at static cross compile with ndk gcc
Droidzone said:
Earlier this month, I was trying to compile dosfstools for Android. But got stuck at static cross compile with ndk gcc
Click to expand...
Click to collapse
So, I'm not barking for the hollow tree here.. That's a relief. Seeing that this post is not that active, I was starting to think I'm working in vain..
Well, now, apparently init version of mount is quite restricted about options. The ones it supports are given in mount.c as:
Code:
"async", "atime", "bind", "dev", "diratime", "dirsync", "exec", "move", "recurse", "remount", "ro", "rw", "suid", "sync", "verbose"
I'm checking the mount.c source as we speak. I'm going to inform you if I can find something.
EDIT: BTW, also "no"+options are recognized (like noatime)
ADDENDUM:
The internal mount is exactly the same as the mount we use at busybox. So, most probably, it's the same was in init script.
Try this line
Code:
mount ext4 /dev/block/mmcblk0p2 /data noatime,nodiratime,nosuid,nodev,nobh
Notice that I erased some flags. You might also try to add them, but check if this line works first.
Hei there.
The idea of this thread is to develop a better kernel for the I9001 in the community. I have compiled my own one for using it in the cwm recovery mod. I've only changed the following so far:
Patched pm2.c file in the samsung kernel sources, see here for the patch:
https://github.com/PabloPL/android_...mmit/46e96915a7e0459dc6b3aec04aa47329371fff44
through menuconfig I've changed the default cpu governor from performance to ondemand.
What we should implement first is init.d support.
I've uploaded my boot.img file for further use here:
http://www.mediafire.com/?6p91s5knka0e0py
It also contains the CWM Recovery
This is great idea bro. Its great to have you here.
Thanks again!!!
Sent from my GT-I9001 using Tapatalk
I would love to see a overclock able kernel! Great idea!
Joost
Sent from my GT-I9001 using XDA App
overclocking module
Hi guys,
coolbho3000 posted source of an overclocking module for HTC Vision. As far I know, it can be used with the SetCPU App together.
http://forum.xda-developers.com/showthread.php?t=813681
Since S+ has a similar Qualcomm chip, it should work as well.
I compiled the overclocking module with the S+ Kernel and packed it into the zImage. The device doesn't boot. Maybe it would be better to follow what coolbho3000 says and adapt the settings
ädu
PS: it needs definitively some adaptions.
Shouldn't we create our own github/bitbucket repositories for kernel and CWM? I'm trying to get my feet wet in generic Android kernel development now, it would be cool to have repository to sync with.
YardE said:
Shouldn't we create our own github/bitbucket repositories for kernel and CWM? I'm trying to get my feet wet in generic Android kernel development now, it would be cool to have repository to sync with.
Click to expand...
Click to collapse
yep of course. I've already opened an account on github. But right now I ain't got time to read the instructions on how to upload repos because I'm busy with applying some changes to FeaMod Recovery and testing them.
I would be happy if a lot of kernel developers would join us!
Edit: The sources for FeaMod recovery 1.1 are on github:
https://github.com/manveru0/FeaMod-Recovery--based-on-CWM-Recovery-
Samsung kernel sources with patched pm2.c:
https://github.com/manveru0/kernel_I9001_samsung
Later I'll try to add "run-parts /system/etc/init.d/" to init.rc, but I'm highly confused from examining ramdisk, because I couldn't find any bash-scripts interpreter (possibly embedded into init executable?) and don't have enough time to continue examining init.rc now. I think, we can add busybox to system image and call it from there. Also, please, modify these lines in default.prop in your future builds:
Code:
ro.secure=0
ro.debuggable=1
As far as I understood, these allow us to use "adb root".
Also, thanks for your awesome work!
YardE said:
Later I'll try to add "run-parts /system/etc/init.d/" to init.rc, but I'm highly confused from examining ramdisk, because I couldn't find any bash-scripts interpreter (possibly embedded into init executable?) and don't have enough time to continue examining init.rc now. I think, we can add busybox to system image and call it from there. Also, please, modify these lines in default.prop in your future builds:
Code:
ro.secure=0
ro.debuggable=1
As far as I understood, these allow us to use "adb root".
Also, thanks for your awesome work!
Click to expand...
Click to collapse
sounds good. I haven't seen a script interpreter either and I'm not quite sure if there is one included in the init. I think it's better we include busybox. Take a look at this thread by the way:
http://forum.xda-developers.com/showthread.php?t=1152740
I'll try to do that testwise.
Here's the adress for my uploaded boot.img-ramdisk without the samsung pictures (we can easily add them again when building a new boot.img):
https://github.com/manveru0/bootimage_ramdisk_I9001
I've already included the changes in default.prop
EDIT: some useful links
http://www.kandroid.org/online-pdk/guide/bring_up.html
http://www.androidenea.com/2009/08/init-process-and-initrc.html
After some init.rd learning I've inserted a service here which should get the job's done, but I have no idea how to test it. Anyway, here is the diff from the normal one:
Code:
[[email protected] boot]$ diff -u3 init.rc ../boot_mod/init.rc
--- init.rc 2011-11-05 22:35:33.194680288 +0400
+++ ../boot_mod/init.rc 2011-11-05 22:24:40.000000000 +0400
@@ -566,7 +566,7 @@
# ihryu 2010.07.19
setprop ro.rfkilldisabled 0
- class_start default
+ #class_start default
# +++++++++++++++++++++++++++++++++++++++++++
# for silent reset
@@ -714,6 +714,10 @@
onrestart restart netd
onrestart restart sensor-daemon
+service initd /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
+ oneshot
+
service media /system/bin/mediaserver
user media
group system audio camera graphics inet net_bt net_bt_admin net_raw radio qcom_oncrpc
[[email protected] boot]$
Have also commented "class_start default" which runs twice for some reason. To have this working in theory, you should have busybox installed in /system/xbin with run-parts support. For me, it boots at least ^_^
P.S. It also works if I call command line from adb. Also, adb root works after changing default.prop, good.
P.P.S. You can also remove "charging.rle" from repo, as it is image, too, but why not just keep all the files in repo? git is loyal to binary files as long as you don't try to create a patch. ~_^ Also, you can use .gitignore to exclude some files from git's view at all.
Found excellent reference on init.rd:
http://www.kandroid.org/online-pdk/guide/bring_up.html
Fixed previous post (removed "disabled"), so it should really work now. Going to test it, but not really sure if my test are correct (I'll try to write something to sdcard, but is it mounted r/w at the moment of script running?)
Test failed, thinking of some other, more accurate tests now.
Tried to create file in /cache, and it worked! Here is boot.img with working init.rd and adb root. Flash it via dd (dd if=boot.img of=/dev/block/mmcblk0p8). You should have busybox installed into /system/xbin for this to work.
YardE said:
Found excellent reference on init.rd:
http://www.kandroid.org/online-pdk/guide/bring_up.html
Fixed previous post (removed "disabled"), so it should really work now. Going to test it, but not really sure if my test are correct (I'll try to write something to sdcard, but is it mounted r/w at the moment of script running?)
Test failed, thinking of some other, more accurate tests now.
Click to expand...
Click to collapse
thx for your commit, I'm testing it as well with the adrenaline shot. If init.d support works you should see the changed values.
I do have a working busybox in /system/xbin with run-parts support, so that shouldn't be the issue as my tests didn't work so far.
Okay, gonna delete disable as well.
concerning the images i wasn't so sure about law problems since they include original samsung stuff.
update:
success You did it! Init support works. Though I have to retest it since I've also added user root to the init.rc. Honestly I'm not quite sure if that entry is needed
"user root" is not needed since user is root by default, already tested without it (edited my posts above).
YardE said:
"user root" is not needed since user is root by default, already tested without it (edited my posts above).
Click to expand...
Click to collapse
okay then, i will change the init.rc file and commit it to github. I will name you in the comment to the change. Which name should I use? Is that okay for you?
Oh, you can use either "abbradar" or "YardE", I don't mind. ^_^ Thank you for credits and again for your work. Gonna experiment a bit with CWM now since init.d is working.
YardE said:
Oh, you can use either "abbradar" or "YardE", I don't mind. ^_^ Thank you for credits and again for your work. Gonna experiment a bit with CWM now since init.d is working.
Click to expand...
Click to collapse
I have to thank you for your work as well, mate It's cool working as a team since we are better, faster and should see more bugs than working alone
Edit:
Hmm, we should include busybox in the boot ramdisk, since not every user has busybox installed.
P.S: funny thing is, I've installed adrenaline shotv13 but only part of it works. For example the sdcard tweak works, the sysctl tweaks don't.
P.P.S: i've installed bash on my device, it's much more easier with it to navigate in the adb shell
manveru0 said:
Hmm, we should include busybox in the boot ramdisk, since not every user has busybox installed.
Click to expand...
Click to collapse
What is the max size limit in our device for ramdisk? Also, should we really do so? It will be hard to update in comparison and maybe will be stripped due to size limit, and users basically'll have two versions of busybox - our embedded into boot.img and their own - in /system. (I'm looking on CM and other init.d implementations as an example) But on the other hand, it is really nearly critical level app (although sh is not in boot.img, for example)
P.S: funny thing is, I've installed adrenaline shotv13 but only part of it works. For example the sdcard tweak works, the sysctl tweaks don
Click to expand...
Click to collapse
They also trying to write some values into non-existent /sys nodes, looks like they are meant for other kernel scheduler, like BFQ (should we also try it?)
---------- Post added at 01:25 AM ---------- Previous post was at 01:25 AM ----------
P.P.S: i've installed bash on my device, it's much more easier with it to navigate in the adb shell
Click to expand...
Click to collapse
Good advice, thank you ^_^.
YardE said:
What is the max size limit in our device for ramdisk? Also, should we really do so? It will be hard to update in comparison and maybe will be stripped due to size limit, and users basically'll have two versions of busybox - our embedded into boot.img and their own - in /system. (I'm looking on CM and other init.d implementations as an example) But on the other hand, it is really nearly critical level app (although sh is not in boot.img, for example)
They also trying to write some values into non-existent /sys nodes, looks like they are meant for other kernel scheduler, like BFQ (should we also try it?)
---------- Post added at 01:25 AM ---------- Previous post was at 01:25 AM ----------
Good advice, thank you ^_^.
Click to expand...
Click to collapse
the maximum size of both recovery and boot.img is 7864320 Bytes. Riversource once found that out. It's also in the BoardConfig.mk So we would have enough space for including busybox. But you're right, it would only lead to 2 busyboxes on the device which is not the best idea.
CM uses the BFQ scheduler as far as I know so yeah, we should give it a try
AFAIK, BFS patch nearly fully removes original kernel schedulers, so some work of comparing with original Linux kernel will be needed to do. Although, it may not be true for Android kernel sources or my experience may be wrong, so we should just try it as is before continuing.
Sent from my GT-I9001 using XDA App
YardE said:
AFAIK, BFS patch nearly fully removes original kernel schedulers, so some work of comparing with original Linux kernel will be needed to do. Although, it may not be true for Android kernel sources or my experience may be wrong, so we should just try it as is before continuing.
Sent from my GT-I9001 using XDA App
Click to expand...
Click to collapse
yep, I've looked at the changes the patches make and they remove alot of the CFQ related functions. Fortunately the makefile is patched as well so no work here.
I've have downloaded the patches for kernel 2.6.35 here:
http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php
I applied them to my sources, compiled em and flashed my FeaMod pack with the new kernel and your changes to the boot ramdisk.
So far everything is working on my device I'm gonna upload the patches to github.
Edit: Had to change the .config as well since bfq is not the default I/O scheduler. It is now, I've also activated the hierarchical scheduler support.
Concerning ramdisk git repo: maybe we should move all the code into some folder, for example, "ramdisk", and move README out from there to avoid it being placed into final image? Also, we should point which files are missing from ramdisk in README.