Database Info

Need help to recompe kernel for the Nordic HTC Magic to support netfilter/iptables

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

[Q] Compiling CM7 kernel on Incredible

Alright guys. I'm trying to get a custom CM7 kernel running on my Incredible. As background, I am well versed in kernel compilation in general and on embedded devices. I followed the directions on the cyanogen wiki (Building_Kernel_from_source), but skipped the section about compiling CM7 itself, since I'm only interested in the kernel. I pulled the kernel from CM's git repo, and it was checked out to the latest version (2.6.37), which is also what my phone was running. I grabbed the 'prebuilt' ARM cross compiling toolchain. I used the kernel config from my phone (/proc/config.gz). Looking through the options with menuconfig, it seemed that the options were correct. I pulled the boot.img from the latest CM7 install zip, (7.0.3), split out the ramdisk.img with split_bootimg.pl, merged my compiled zImage with the ramdisk.img using mkbootimg, copied the resulting img file to my sdcard, ran adb shell from recovery, zero'd out mtd2 (boot), and flashed my custom boot.img using flash_image.
Whew!
I have tried countless times, and every time I try to boot my device with the new kernel, my phone doesn't get past the "htc Incredible" boot screen. It just hangs there. I am completely at a loss as to where to go from here. Any suggestions would be EXTREMELY appreciated.
Thanks for reading.

I just remembered, I ended up using a different tool to split the ramdisk, since the wiki link to split_bootimg.pl was broken. I just now found split_bootimg.pl using google, extracted the custom boot.img I've been trying to throw at my phone, and the kernel section of it was recognized by 'file' utility as data. I'm going to try doing the ramdisk split using split_bootimg.pl tomorrow and see what the resulting boot.img looks like then. I'll report back my results.

Turns out that when you split the boot.img that comes with cyanogen, the kernel in there is also recognized as data. I am no closer to solving this mystery

[Q] GT-I9000M kernel compiling

I've got this side project going where I've decided to try to modify the stock kernel for my GT-I9000M.
I'm a Gentoo linux user and have cross-compiled kernels for embedded systems with or without initramfs and modules successfully many times. Rather than just grab and flash the latest mod from the net I want to understand exactly how to create my own.
I already have access via a chroot to a working Gentoo install, however that runs in a sandbox inside android userland, which can be irritating to say the least. I'm already able to create binaries for armv7a on the phone itself, which is a time and power-consuming novelty.
I setup a development environment on my main computer and made sure I could create working binaries for the armv7a.
I backed up all the bml partitions on my phone.
Next, I made sure I could access Download Mode and experimented with Heimdall until I was satisfied I was able to recover from any bad kernel flashes.
I altered the first boot logo in param.lfs with dd, but that's a whole other story.
Next, I downloaded Samsung's source for Froyo and followed the instructions to create a zImage.
aries_eur_defconfig selects the FM radio module and the Samsung TV out driver which are broken. No problem, I figured I could check that out later so I disabled those options for now. it compiles! great! But it didn't boot. I turned to the internet for ways to solve the problem.
There was a lot of conflicting information. I ended up trying a lot of different approaches, modules, firmware, version info, kernel command lines, fbcon... well I messed around.
Some time later, I find myself happily booting with my own kernel. The bootloader displayed my custom logo in param.lfs, but fbcon didn't work and I got a stock samsung gt-i9000 logo before android booted up! The phone worked, wifi worked, bluetooth worked, it was awesome (for 2.6.32.9 that is )!
So, great! Except I got overconfident and cocky. I made a slew of changes trying to get fbcon to work and to top off the evening I overwrote my working zImage with a broken kernel (without a backup of my working custom zImage or .config). I still have backups otherwise of course and haven't lost the functionality of my phone in any way, but now I'm just irritated.
Anybody else working on compiling from source on the GT-I9000M?

I pressed ahead and tried to recreate the conditions that got me a working kernel and as of yet I've been unsuccessful Luckily I've got a kmsg from the kernel when it booted. I can see the kernel command line on the custom kernel that booted was simply "console=ttySAC2,115200" although I do recall trying different values for init= ... The default init in the sources is /linuxrc which doesn't exist in initramfs.
There are also settings for the kernel command line and version information in arch/arm/mach-s5pv210/include/mach/param.h
Is there a known good method to compile from Samsung's sources?

I unpacked a known good zImage, played with it's initramfs, repacked it and it boots just fine.
I've tried again with a fresh copy of the gt-i9000 froyo-samsung branch:
- unpack initramfs from a known good 2.6.32.9 kernel
- make clean
- make aries_eur_defconfig
- make menuconfig, add initramfs, remove Samsung TV driver and FM radio module
- make
the resulting vmlinux is: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, not stripped (I know, it's zImage not vmlinux but I'm just doing sanity checks)
I have a custom logo in param.lfs which always displays on boot. A second logo is compiled into the kernel, and I do see a change in the logo when my kernel boots (it shows GT-I9000 instead of GT-I9000M after the first logo). This leads me to believe that the kernel is booting... but the phone powers off after booting.
I've tried the recommended changes to default.prop to use adb to obtain the kmsg of the new kernel. This has not worked however, which could mean that the kernel doesn't get as far as initramfs.
the kernel command line from the kmsg I have from the one time that a custom kernel of mine booted is simply: "console=ttySAC2,115200 loglevel=4" . There's no mention of init, which I think should be init=/init although aries_eur_defconfig seems to think that init=/linuxrc is appropriate (linuxrc doesn't exist?) Regardless, it doesn't seem to matter what I specify for init.
Which leaves proprietary Samsung kernel modules. If they can't load, this could explain everything I'm experiencing. It isn't clear what specific version the proprietary modules are expecting.

Maybe this will help somebody else. I've got it working now.
Attached is my working config.

[HowTo] Compile the Kernel Source Code for the HTC One XL

Hi guys!
Someone requested a tutorial on how to build the kernel source code, so I thought I might as well do it I'll give you a bit more information too.
Maybe this will kick start kernel development a little bit too. Who knows.
Anyway:
1. Set up your build environment as per this guide by AOSP here: http://source.android.com/source/initializing.html
This guide will be primarily aimed at Ubuntu, but it should be easy enough to do on other Linux PCs. Ubuntu is highly recommended. And don't ask about Windows.
2. Download the toolchains: http://code.google.com/p/rohan-kernel-evita/downloads/detail?name=toolchains.tar.gz&can=2
I've hosted both GCC 4.4 and GCC 4.6 (prebuilt) on my Google Code page. These are for Linux.
Download the toolchain package here: http://code.google.com/p/rohan-kernel-evita/downloads/detail?name=toolchains.tar.gz&can=2
Then un-tar the archive and extract it to your home folder so that the path to the toolchain directories are ~/toolchain/whatever-one-you-want
3. At this point you can decide which kernel source you want to download. There are really two sources.
The first choice is getting it from HTC Dev directly. This is good if you want to build your kernel for a Sense 4 ICS ROM. If you want to build for AOSP/JB, then scroll down below all the following HTC stuff.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To use HTC's source:
Go to HTCdev.com and make an account. Then download the source code for our device (I'd recommend the "One X" source under carrier "AT&T" version "2.20". Let the zip file download and extract it to your home folder (so the path is /home/user/evita-ics..../
To build HTC's source, run these commands:
Code:
cd ~/evita-ics-whatever_the_directory_is_named
export ARCH=arm
make elite_defconfig
Second command is saying what type of architecture we want (we are compiling for ARM processors, so we want ARM)
Third command is saying to make the default config for our device (whose hardware is codenamed "elite")
Then to build the actual kernel:
Code:
make -j# ARCH=arm CROSS_COMPILE=~/toolchain/arm-eabi-4.4.3/bin/arm-eabi-
In the command above, there is "-j#". Replace the "#" with the number of CPUs you have.
Ask me about it if you need help. That should be it! Let the build go and in a few minutes you should have a zImage file located at ~/evita-ics-..../arch/arm/boot. That is the actual kernel.
To test out the zImage (kernel), connect your device via fastboot mode and type:
Code:
fastboot boot /path/to/zImage
Combined with the ramdisk, thats what makes the boot.img file. Eventually if you want to distribute your kernel, you should use an installer that injects the zImage into the boot.img or combine the zImage with a ramdisk to make a boot.img. I can do a tutorial on that later on as well.
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To get the "other" source:
This source is based off of HTC's source and includes other devices as well in it (the One S and Evo 4G LTE). Its good if you want to build JB AOSP kernels.
To download this kernel source do this:
Code:
mkdir ~/kernel
cd ~/kernel
git clone https://github.com/CyanogenMod/android_kernel_htc_msm8960.git -b android-msm-evita-3.0
This version also includes a number of optimizations and odd bug fixes present in the HTC version.
To build this second source, run these commands:
Code:
cd ~/kernel/android_kernel_htc_msm8960
export ARCH=arm
make elite_defconfig
Second command is saying what type of architecture we want (we are compiling for ARM processors, so we want ARM)
Third command is saying to make the default config for our device (whose hardware is codenamed "elite")
Then to build the actual kernel:
Code:
make -j# ARCH=arm CROSS_COMPILE=~/toolchain/arm-linux-androideabi-4.6/bin/arm-eabi-
In the command above, there is "-j#". Replace the "#" with the number of CPUs you have.
Ask me about it if you need help. That should be it! Let the build go and in a few minutes you should have a zImage file located at ~/evita-ics-..../arch/arm/boot. That is the actual kernel.
To test out the zImage (kernel), connect your device via fastboot mode and type:
Code:
fastboot boot /path/to/zImage
Combined with the ramdisk, thats what makes the boot.img file. Eventually if you want to distribute your kernel, you should use an installer that injects the zImage into the boot.img or combine the zImage with a ramdisk to make a boot.img. I can do a tutorial on that later on as well.
-----------------------------------------------------------------------------
The second option is also a bit better as it uses the 4.6 toolchain instead of GCC 4.4. HTC's source doesn't work with GCC 4.6 so it can't be used without changes that the second source has.
If you have any questions, feel free to post here, message me on twitter (@rohanXm), chat me on IRC (#HTC-One-XL) or PM me!
If this helped you, please consider hitting the donation link under my username on the left. Donations are never required but always appreciated.

Instead of downloading cm10 the readme inclided with the HTC source has directions for getting a tool chain which will compile the source.
Sent from my HTC One X using Tapatalk 2

Perfect. Now I just have to read.
Sent from my HTC One XL bumping it

rohan32 said:
Code:
repo init -u git://github.com/CyanogenMod/android.git -b jb
Click to expand...
Click to collapse
FYI, It looks like the branch name has changed. When I changed "jb" to "jellybean" the repo init command worked.

Rohan. You are one bad MF'er
Sent from my twin turbo'ed OneXL rocking rezound beats

rohan32 said:
2. You can either try to find a standalone package of the precompiled toolchain, or you are going to need to download a ROMs source. I'd recommend downloading a ROMs source since I've never found a good toolchain that worked for me. If you find one that works, post below
For now we will download CM10 since that seems like the defacto standard.
Click to expand...
Click to collapse
I downloaded the 2.20.502.7 kernel source and when I extracted it there was a file named evita_readme.txt which gave another, possibly more "official", location for downloading a toolchain:
--Please follow below command to download the official android toolchain: (arm-eabi-4.4.3)
git clone https://android.googlesource.com/platform/prebuilt
Click to expand...
Click to collapse
I just performed a build with this toolchain but got this error when I attempted to load zImage via fastboot:
c:\>fastboot flash boot zImage
sending 'boot' (5140 KB)...
OKAY [ 1.044s]
writing 'boot'...
FAILED (remote: image error! (BootMagic check fail))
finished. total time: 1.077s
Click to expand...
Click to collapse
I'm not sure if this is caused by the toolchain or if I screwed something up. Have you ever seen this error before?
EDIT: Ok I see what I did incorrectly. The zImage needs to be "Combined with the ramdisk". You wouldn't know how to perform this operation... would you?

denversc said:
I downloaded the 2.20.502.7 kernel source and when I extracted it there was a file named evita_readme.txt which gave another, possibly more "official", location for downloading a toolchain:
I just performed a build with this toolchain but got this error when I attempted to load zImage via fastboot:
I'm not sure if this is caused by the toolchain or if I screwed something up. Have you ever seen this error before?
EDIT: Ok I see what I did incorrectly. The zImage needs to be "Combined with the ramdisk". You wouldn't know how to perform this operation... would you?
Click to expand...
Click to collapse
You are trying to flash a zImage
To my knowledge, only booting zImages work on this device. For the time being just boot the zImage (use fastboot boot zImage)
I will make a tutorial on how to combine the zImage created with a ramdisk to make a boot.img when I get the chance

denversc said:
FYI, It looks like the branch name has changed. When I changed "jb" to "jellybean" the repo init command worked.
Click to expand...
Click to collapse
Oops, my bad! That was a mistake. AOKP uses -jb and CM uses -jellybean so I got them switched fixed now

Out of any device I've seen more people actually interested in helping and learning to help then any other community. I've watched noobs become less noobish.. I've watched skizz learn how to make themes. Hell I've learned 10 fold what I knew before this phone myself.
That is beautiful, and now such an informed, helpful post such as this.
Have great Sunday you guys! I think I might give this a shot!
Sent from my One X

I'll streamline this process in a bit, so that you don't need to download CM10
Edit: cleaned up post, now I'm uploading just the toolchains. Its a tar.gz archive, around 150mb. Much better than downloading the entire CM10 source

rohan32 said:
You are trying to flash a zImage. To my knowledge, only booting zImages work on this device. For the time being just boot the zImage (use fastboot boot zImage)
Click to expand...
Click to collapse
Thanks for your response, rohan. You are absolutely right: I was incorrectly attempting to flash zImage straight to the boot partition, and the error produced by flashboot was justified. I have since successfully "tested out" my compiled zImage by flashing it via "fastboot boot zImage" and it worked like a charm! I ported the modifications from sbryan's Blackout BeastMode kernel and I am now able to OC to 2106 MHz and UC to 192 MHz. It's been running solid for the past few hours at least
Of course, the kernel reverts back to the one stored in the boot partition after a reboot, and I want my shiny new kernel to "stick". I've done a bit of research on this topic and found some information about combining my zImage with a ramdisk into a "real" boot.img but have not yet been successful in creating a boot.img which does not bootloop after flashing it.
For example, I found an article on xda called Basic Kernel Kitchen for Minor Kernel Tweaking which points to a "kitchen sink" tool for creating a boot.img from a zImage and a ramdisk. My problem is that I don't know where to get or how to make a ramdisk. So I tried using the ramdisk from the boot.img of the ROM that I am currently running (CleanROM 4.5 DE) but just got into a bootloop. I've since been doing some yard work today so haven't gotten back to investigating further.
I also found another program named abootimg which can also produce a boot.img from a zImage abd a ramdisk, but when I tried it an error message about my zImage being "too big" was produced.
If it's not obvious yet, I am kind of fumbling around in the dark as compiling and deploying custom kernels is completely new to me! But this post was the most valuable resource I've come across in getting to this point. Thanks so much for writing it! I eagerly await your next article about creating the boot.img
---------- Post added at 06:05 PM ---------- Previous post was at 05:50 PM ----------
rohan32 said:
cleaned up post
Click to expand...
Click to collapse
Thanks for cleaning up the post rohan. I have a few follow-up questions/comments:
missing toolchains link -- the post says "Download the toolchains:" but there is no link to download anything... did you forget to paste the link?
official toolchain -- That's great that you uploaded the toolschains to save tonnes of bandwidth. The CM10 source was taking a VERY long time for me to grab. However, I imagine some people (like me) would prefer to get the toolchain from an "official" source. In the "evita_readme.txt" file of the kernel sources downloaded from HTC dev it instructs one to use the official sources from "git clone https://android.googlesource.com/platform/prebuilt". This is the toolchain that I used and it successfully built the zImage.
ko files -- I noticed in the ZIP file for Blackout BeastMode, in additional to installing the zImage it also puts a bunch of "ko" (kernel modules I believe) into the /system partition (eg. qce40.ko). Should I also be deploying .ko files from my build to the device?
Thanks!

denversc said:
Thanks for your response, rohan. You are absolutely right: I was incorrectly attempting to flash zImage straight to the boot partition, and the error produced by flashboot was justified. I have since successfully "tested out" my compiled zImage by flashing it via "fastboot boot zImage" and it worked like a charm! I ported the modifications from sbryan's Blackout BeastMode kernel and I am now able to OC to 2106 MHz and UC to 192 MHz. It's been running solid for the past few hours at least
Of course, the kernel reverts back to the one stored in the boot partition after a reboot, and I want my shiny new kernel to "stick". I've done a bit of research on this topic and found some information about combining my zImage with a ramdisk into a "real" boot.img but have not yet been successful in creating a boot.img which does not bootloop after flashing it.
For example, I found an article on xda called Basic Kernel Kitchen for Minor Kernel Tweaking which points to a "kitchen sink" tool for creating a boot.img from a zImage and a ramdisk. My problem is that I don't know where to get or how to make a ramdisk. So I tried using the ramdisk from the boot.img of the ROM that I am currently running (CleanROM 4.5 DE) but just got into a bootloop. I've since been doing some yard work today so haven't gotten back to investigating further.
I also found another program named abootimg which can also produce a boot.img from a zImage abd a ramdisk, but when I tried it an error message about my zImage being "too big" was produced.
If it's not obvious yet, I am kind of fumbling around in the dark as compiling and deploying custom kernels is completely new to me! But this post was the most valuable resource I've come across in getting to this point. Thanks so much for writing it! I eagerly await your next article about creating the boot.img
---------- Post added at 06:05 PM ---------- Previous post was at 05:50 PM ----------
Thanks for cleaning up the post rohan. I have a few follow-up questions/comments:
missing toolchains link -- the post says "Download the toolchains:" but there is no link to download anything... did you forget to paste the link?
official toolchain -- That's great that you uploaded the toolschains to save tonnes of bandwidth. The CM10 source was taking a VERY long time for me to grab. However, I imagine some people (like me) would prefer to get the toolchain from an "official" source. In the "evita_readme.txt" file of the kernel sources downloaded from HTC dev it instructs one to use the official sources from "git clone https://android.googlesource.com/platform/prebuilt". This is the toolchain that I used and it successfully built the zImage.
ko files -- I noticed in the ZIP file for Blackout BeastMode, in additional to installing the zImage it also puts a bunch of "ko" (kernel modules I believe) into the /system partition (eg. qce40.ko). Should I also be deploying .ko files from my build to the device?
Thanks!
Click to expand...
Click to collapse
Hey!
Sorry, set it to upload then got distracted Link posted
The reason why your boot.imgs bootloop is because there is a special ramdisk address that needs to be set when combining the ramdisk with the zImage, and most kitchens don't support this. You also need to set the address after setting the base value.
I will post a guide on how to make it a real boot.img whenever I get the chance.

I'm telling you people, Rohan is a BOSS. Most helpful dev I know.
Sent from my HTC One XL using xda app-developers app

rohan32 said:
Hey!
Sorry, set it to upload then got distracted Link posted
The reason why your boot.imgs bootloop is because there is a special ramdisk address that needs to be set when combining the ramdisk with the zImage, and most kitchens don't support this. You also need to set the address after setting the base value.
I will post a guide on how to make it a real boot.img whenever I get the chance.
Click to expand...
Click to collapse
I have the zImage thanks to your tutorial, but I want to know how to create the kernel zip, whenever you have time will be amazing if you can post a guide, I'm really looking forward to that guide, because i haven't been able to locate a guide that works
Sent from my HTC One XL using xda premium

rohan32 said:
Hi guys!
Second command is saying what type of architecture we want (we are compiling for ARM processors, so we want ARM)
Third command is saying to make the default config for our device (whose hardware is codenamed "elite")
Then to build the actual kernel:
Code:
make -j# ARCH=arm CROSS_COMPILE=~/toolchain/arm-linux-androideabi-4.6/bin/arm-eabi-
Click to expand...
Click to collapse
This is the correct make for "other source" kernel.
Code:
make -j# ARCH=arm CROSS_COMPILE=~/toolchain/arm-linux-androideabi-4.6/bin/[COLOR="Red"]arm-linux-androideabi-[/COLOR]

Can you make a tutorial on how to insert governors into a kernel?

Compiling problem
Hey man,
Please help me I followed your article but when I try copile with:
make -j2 ARCH=arm CROSS_COMPILE=~/toolchain/arm-eabi-4.4.3/bin/arm-eabi
I got something like this:
/home/martin/toolchain/arm-eabi-4.4.3/bin/../lib/gcc/arm-eabi/4.4.3/../../../../arm-eabi/bin/as: error while loading shared libraries: libz.so.1: cannot open shared object file: No such file or directory
Thanks
UPDATE:
now its work
I went deeper and install lib32z1 with "sudo apt-get install lib32z1"... now its work

My device repositories are not available on github, But I got device tree and vendor blobs by making changes in similar device repo. That reference device's kernel's lineageos_defconfig is situated in htc msm8974 kernel repo. So how can I get lineageos_defconfig for my device, and which other my device related kernel files(.dtsi or any other) I have to push in htc msm8974 repo and get those files to make things ready for build?
Please help......

make kexec guestable kernels

hi all,
i'm going to support multiple android roms loading in my kernel_chooser + root_chooser project.
in few words it will be a powerful bootloader for android.
this is what it will be able to do ( many points are yet working ):
kernel loading thought kexec
boot from external devices
boot from subfolders
custom background
change android /sytem partition
change android /data partition
wipe android /cache partition
what i'm asking to you it's to make your android rom's kernel kexec-ready, applying them a kexec guest patch.
thus to make them ready to load for me.
if not i have to patch your kernel every time you modify it.
kernel_chooser and root_chooser are hosted here: https://github.com/tux-mind/tf201-dev
they are made for the asus transformer prime ( TF201 ), but they can run on any android device with your help.
i will add you to the github collaborators if you want to help.
now we are working on multiple android roms support.
thanks in advance for your time.
-- tux_mind

@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work

HTCDreamOn said:
@tux_mind sounds like an interesting idea. So this works for all device's kernels? Once I apply the patch to my kernel source, what happens after that? I'll make sure to follow your progress, good work
Click to expand...
Click to collapse
thanks
yes, this should work for all devices, except for a little tuning of the partition with the configuration data ( /data ).
i have to make it to self-detect the /data partition.
let's say for example that you want to use it on your HTC Vision.
i have to build an host kernel by the stock one applying the host kexec patch.
than i have to build an android boot image which contains kernel_chooser as initrd and the above kernel.
this android boot image will be written to your current one though fastboot.
after that kernel_chooser will be able to load any kernel patched with the guest patch.
obviously the loaded kernel must be made for that device
it can also load a custom initrd and use a custom kernel CMDLINE.
so, after i made a HTC Vision kernel_chooser, your rom it's ready to load if you applied the guest patch to you kernel.
i can't explain well how to make you rom "bootable" because we are developing this
but if your kernel is kexec-loadable it will be supported by kernel_chooser.
i will update you in the next days
bye!

Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4

@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?

dtrail1 said:
how different are the methods to use kexec?
Click to expand...
Click to collapse
kexec it's a syscall, so it's the same on every arm device.
HTCDreamOn said:
@tux_mind this'll sound really stupid but how do actually patch our kernels for this? Do I have to build kexec from here or something?
Click to expand...
Click to collapse
there is a good explaination here:
http://forum.xda-developers.com/showthread.php?t=2104706
look at the "Compatibility patch".
for my tf201 the guest patch is this: http://git.lilstevie.geek.nz/?p=ubu...ch;h=54c2e480682afb0629f3854dfea4154f528421e5
which is almost the same...
i hope that almost all kernels have the same host/guest patch, in order to save us a lot of work.
the patch isn't need for kexec, but for hardboot kexec, thus to physically shutdown and restart the device with your kernel, from 0.
the standard kexec it's a assembly jump to 0 ( jmp 0x0 ) with the new kernel loaded in the .text section.
but the standard method don't reinitialize the devices and many other things that could rest in a undefined state.
btw, i have almost done my work.....i'm fighting the android udev which is overwriting my symlinks..
see you!

i got it!
my initial target was to remove devices created by ueventd and replace them with symlink to loop devices.
but android respawn ueventd and replaces my symlinks...
i tried to start the android ueventd, leave it running, and replace the /sbin/ueventd with a infinite sleep static program
but android dont' start at all..i can't even access via adb.
so, the "final" solution is to edit the /fstab.$hardware, which should be in any andoird boot image ( right ? ).
please feel free to suggest any other way to hack the mount process.
you can find the sources here: https://github.com/tux-mind/tf201-dev/tree/master/android_chooser
the program read the paths from kernel cmdline.
the syntax is that:
Code:
newandroid=blkdev:initrd_path:fstab_path
where
blkdev is the linux name of the blockdevice containing the next args ( e.g. /dev/mmcblk0p8 )
initrd_path is the path on the previous blockdevice of the android initrd ( gzipped or not )
fstab_path is the path on the previous blockdevice of the fstab file
the fstab file have this syntax:
Code:
/android/mountpoint /path/to/image/file
where
/android/mountpoint is the android mountpoint to overwrite ( e.g. /system )
/path/to/image/file is the path to the filesystem image file ( on blkdev ) ( e.g. /boot/unrooted.img )
i don't make any documentation until i will be sure that there is no better way to do this.
thanks in advance for your testing
ah, some other useful info.
because we are in testing the program write a log file with some debug info in the root of your blkdev.
so you will find /android_chooser.log on your blkdev with these info in case of errors.
tux_mind

Please
dtrail1 said:
Really great idea! As it support other devices I can throw in my kernel which is a kexec one for the Motorola RAZR, because of our locked bootloader. The question is: how different are the methods to use kexec?
M.o.t.o.r.o.l.a.R.a.z.r - JBX-Kernel 0.5a - Tapatalk4
Click to expand...
Click to collapse
Dtrail could you explain me kexec and its components required for loading new kernel because my device(electrify 2) is similar to droid razr. Using bmm kexec is boot able because I had checked by flashing droid razr's kernel which gave a boot loop.
I would be pleased and thankful to you if you help me.