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

[PATCHES] Kexec syscall support, boots kernels from SD or USB (11/6/11, GB support)

11/6/11 Update: Added statically-linked kexec to kexec_patches.tar.gz and example update.zips. Now works in stock recovery and CM7 CWM (with a kexec-patched kernel).
10/19/11 Update: Added patches for the recently released GB sources to kexec_patches.tar.gz.
Attached is a set of patches (kexec_patches.tar.gz) against EC05, and the recently released GB sources, to implement kexec syscall support in the Epic's kernel. kexec enables the booting of kernels "directly" from the SD card or over USB without having to flash them to the device first. This allows us to easily use, test, and switch between many kernels, not just the one (two with recovery) there's room for on flash.
When used in conjuction with modified init.rc scripts, this allows entire ROMs (with their own kernels) to run from SD card. In short, this allows us to run custom-kernel ROMs (e.g,. CyanogenMod) alongside each other or a stock kernel without having to flash back and forth.
Also attached is a modified version of the kexec userspace tool (also in kexec_patches.tar.gz, along with source and patches) that facilitates the proces of loading and kexecing a kernel image. Finally, attached is a demo EC05 kernel with kexec enabled (demo_kernel.tar.gz; mostly stock: RFS support only, testkeys recovery w/adbd, but does inlcude the keyboard patches), example update.zips that kexec an SD-card kernel from recovery--either as a normal boot (boot_zImage.zip) or recovery boot (boot_zImage_recovery.zip), and a script (patch_decomp_cachebufram.sh) to binary patch unmodified kernels to kexec boot faster.
Note, this thread is primarilly intended for kernel developers. Kexec probably won't be of great utility to end users until commonly-used kernels are patched. Also, although stock kernels can be kexec'd, they need some init.rc modifications boot an entire ROM from SD card. Hopefully the fine folks here will come up with a user-friendly implementation of this work that's easy for everyone to use.
Instructions:
Flash a kexec-enabled kernel (e.g., the attached demo kernel) to either /dev/block/bml7 or /dev/block/bml8. For testing purposes, this kernel needs either "ro.secure=0" or "ro.debuggable=1" set in default.prop, and also needs recovery.rc/fota.rc modified to spawn the adbd service, so that an adb root shell is available while in recovery. Also copy the attached kexec tool to a convenient location on the device (e.g., /data/local/tmp/kexec).
Reboot into recovery. If the kexec kernel is installed to bml7, run "adb reboot recovery" while the phone is running. If installed to bml8, power down and boot into recovery by holding the volume-down, camera, and power buttons.
Make sure adb is running as root. If it's not, try running "adb root".
Find the kernel (zImage) you wish to boot. These can be extracted from a kernel update.zip or Odin .tar file, or use the demo kernel again.
Push the zImage into RAM (tmpfs) with:
Code:
adb push zImage /tmp
Now, open an adb root shell with "adb shell" and run the commands:
Code:
mount -ro remount /dev/block/stl6 /mnt/.lfs
mount -ro remount /dev/block/stl9 /system
mount -ro remount /dev/block/stl10 /data
mount -ro remount /dev/block/stl11 /cache
/data/local/tmp/kexec --load-hardboot --mem-min=0x50000000 --append="console=ttySAC2,115200 loglevel=4" /tmp/zImage
sync
/data/local/tmp/kexec -e
after which the phone will reboot, show the SAMSUNG logo, and eventually boot the kexec'd kernel. Do note that when booting unmodified kernels (see below), the SAMSUNG logo will persist for ~30 seconds longer than usual.
Also note that kexec performs an "abrupt" reboot, i.e., it doesn't shutdown the system normally. Hence it's important to kexec from recovery where few services are running. It's also prudent to remount file systems read-only and sync them to avoid any potential (although unlikely) of corruption.
In the future, kexec could be better integrated into the Android framework to allow for a clean shutdown. Otherwise, probably the best way to deploy kexec is through an update.zip file that boots a kernel from the SD card. See the attached example update.zips.
Technical details:
kexec is feature of Linux that allows it to directly execute (boot) a new kernel in place of itself, allowing Linux to effectively serve as its own bootloader.
The kexec procedure is two step. The first "kexec" command loads a zImage from disk, constructs parameters (e.g., the kernel command line), and stages it in memory, after which Linux continues to run as normal. The second "kexec" command tells Linux to execute (boot) the staged kernel.
In the standard implementation, Linux "soft boots" kexec'd kernels. That is, on "kexec -e" the running instance of Linux shuts-down all devices, drivers, and goes through the process of unloading itself as it does during a normal reboot. However, instead of invoking a hardware reboot, Linux, at the final stage of unloading itself, jumps to start executing the new kernel.
This soft boot process requires that Linux hardware drivers are fully capable of unloading, reloading, and reinitializing the associated hardware without hardware-reboot or bootloader assistance. Since, for many built-in drivers, this capability is only used by kexec, hardware is often left in an unexpected or unknown state on unload, and thus the kexec'd kernel hangs on boot. Unfortunately this is the case with the Epic kernel, and soft booting doesn't work.
To work around this, the attached patches implement a "hard boot" method for kexecing kernels. Here, we use kexec to stage a kernel in memory as usual. On "kexec -e", Linux shuts-down as before, and at the very end of the unloading process it does two things: (i) scribble some information on how to boot the kexec'd kernel to a "special place" in memory, and (ii) performs a hardware reboot, invoking the Epic bootloader as a normal reboot does.
On reboot, the bootloader loads the (previously-running) bml7 or bml8 kernel and starts executing it. Here, the hardboot patch modifies the Linux the zImage decompressor code to check the "special place" in memory to see if we're actually kexecing a different kernel. If so, it switches over to the other kernel, already staged elsewhere in memory.
Known Issues:
Kernel Command Line:
Kexec (via hardboot) can boot stock or non-kexec-modified custom kernels. However, unless the copy_atags patch is applied, they can only use the kernel command line provided by the bootloader, as opposed to the custom command line provided by kexec. Although this isn't a problem when kexecing from a bml7 boot kernel, kexecing from a bml8 kernel runs recovery (fota.rc) instead of a normal boot (init.rc).
With the copy_atags patch, the command line for the kexec'd kernel must be provided by with kexec's --append option. These are the command lines provided by the bootloader in normal boot and recovery scenarios, any of which may be used:
Code:
Normal boot (init.rc):
console=ttySAC2,115200 loglevel=4
"adb reboot recovery" (recovery.rc):
bootmode=2 console=ttySAC2,115200 loglevel=4
Three-finger recovery boot (fota.rc):
bootmode=3 console=ttySAC2,115200 loglevel=4
Slow Booting:
Kexec booting of a stock or non-kexec-modified custom kernel is known take significantly longer than a regular boot, sitting at the SAMSUNG logo for 35 seconds instead of 8. The decomp_cachebufram patch resolves this issue for modified kernels. In addition, the attached patch_decomp_cachebufram.sh script will binary patch the decompressor code for any (to my knowledge) Epic kernel.
Many more details on the patches themselves are in the accompanying READMEs.
Mirror links:
Kernel & kexec-tools patches: kexec_patches.tar.gz
Kexec EC05 demonstration kernel: demo_kernel.tar.gz
Recovery script to boot /sdcard/zImage (normal boot): boot_zImage.zip
Recovery script to boot /sdcard/zImage (recovery boot): boot_zImage_recovery.zip
Script to binary patch decompressor code: patch_decomp_cachebufram.sh

Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium

squshy 7 said:
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
Click to expand...
Click to collapse
His uses a modified init, which then choses to load which init.rc, the one names init.rc.sdcard or normal init.rc. This (kexec method) reminds me A LOT like how they ran linux/android on winmo devices...it shuts down android and then runs the kernel they want (if I read correctly).

squshy 7 said:
Is this different in function than rodderik's dual boot support?
I know his didn't include usb booting support, but sdcard booting appears to be the same...although this seems a little cleaner, possibly
Sent from my SPH-D700 using xda premium
Click to expand...
Click to collapse
Yes. The genocide implementation allows a ROM to boot from the sd card as long as the kernel on the main ROM supports the sd ROM. this means you cannot dual boot a gingerbread and a froyo ROM because the need different kernels .
With this patch that limitation is removed as the sd based ROM can use its own separate kernel. This you may run stock ec05 and keep cyanogen or a gingerbread on the sd card to test and play with.
Great work mkasick
Sent from my SPH-D700 using Tapatalk

I was never interested in the dual boot feature since that was ROM's only and itwas limited by kernel support.
But now this really interest me, can't wait till we see some developers take advantage of this.
Sent from my SPH-D700 using xda premium

All I have to say is hope you stick with the epic your amazing
Sent from my SPH-D700 using Tapatalk

Yes, this is complementary to Rodderik's dual boot. Kexec allows one to load a different kernel, but it still defaults to booting the ROM stored in flash. Which is great for kernel testing, but not of much use otherwise.
It's easy enough to modify a kernel to load a ROM only from SD, but then we'll start seeing a divide between "bml kernels" and "SD kernels", when really it'd be nice to have init scripts that support both. That's where Rodderik's work comes in.
Probably the best is to have a kernel command line parameter that specifies where the ROM is located, so it can be passed in. Something like "console=ttySAC2,115200 loglevel=4 systemfs=mmcblk0p2 datafs=mmcblk0p3 cachefs=mmcblk0p4". These would default to stl9, stl10, stl11 respectively if unspecified. The kernel command line is available to init through "/proc/cmdline", and it's easy enough to parse in a shell script.
But yes, keeping a working ROM on flash while testing/debugging CyanogenMod was my primary motivation, since I need a working phone "during the day" and can't touch CyanogenMod otherwise.
formula84 said:
All I have to say is hope you stick with the epic your amazing
Click to expand...
Click to collapse
Thanks!
I'm much of a year out on a full upgrade, and I'm not considering a new device sooner as long as my Epic still works.
Edit: An obvoius limitation is modem compatibility. I've avoided the GB leaks thus far, so I'm not sure what's the status with that. But if GB supports the EC05 modem, then you can dual boot EC05 and GB-whatever. Same if EC05 supports newer modems.
Speaking of which, anyone know what GB modem compatibilty is like?

mkasick said:
Yes, this is complementary to Rodderik's dual boot. Kexec allows one to load a different kernel, but it still defaults to booting the ROM stored in flash. Which is great for kernel testing, but not of much use otherwise.
It's easy enough to modify a kernel to load a ROM only from SD, but then we'll start seeing a divide between "bml kernels" and "SD kernels", when really it'd be nice to have init scripts that support both. That's where Rodderik's work comes in.
Probably the best is to have a kernel command line parameter that specifies where the ROM is located, so it can be passed in. Something like "console=ttySAC2,115200 loglevel=4 systemfs=mmcblk0p2 datafs=mmcblk0p3 cachefs=mmcblk0p4". These would default to stl9, stl10, stl11 respectively if unspecified. The kernel command line is available to init through "/proc/cmdline", and it's easy enough to parse in a shell script.
But yes, keeping a working ROM on flash while testing/debugging CyanogenMod was my primary motivation, since I need a working phone "during the day" and can't touch CyanogenMod otherwise.
Thanks!
I'm much of a year out on a full upgrade, and I'm not considering a new device sooner as long as my Epic still works.
Edit: An obvoius limitation is modem compatibility. I've avoided the GB leaks thus far, so I'm not sure what's the status with that. But if GB supports the EC05 modem, then you can dual boot EC05 and GB-whatever. Same if EC05 supports newer modems.
Speaking of which, anyone know what GB modem compatibilty is like?
Click to expand...
Click to collapse
As far as I know, and from experience, modems are a free for all except for bonsai. Ec05 modem works on gb, leaked modems work on ec05.

this is definitely very cool, thanks mkasick!
Sent from my SPH-D700 using XDA Premium App

mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!

Rodderik said:
mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!
Click to expand...
Click to collapse
Great!
If you run into something not particularly straight forward, or think there's something I can clarify, please ask. I've been playing around with this long enough that I fear I might've overlooked documenting a detail or two that would be helpful for others.

So to patch any kernel u just point the script to the zImage?
sent from my epic 4g. with the key skips.

ugothakd said:
So to patch any kernel u just point the script to the zImage?
Click to expand...
Click to collapse
The script only implements one patch, it allows any kernel to boot ~30 seconds faster when kexec'd.
But yes, "./patch_decomp_cachebufram.sh zImage" modifies that zImage to boot faster. It requires the xxd hexdump tool that's packaged with vim.
Kexec support itself, along with the slew of other source patches, has to be applied to a kernel source tree, from which a new kernel must be built to take advantage of them.

mkasick said:
The script only implements one patch, it allows any kernel to boot ~30 seconds faster when kexec'd.
But yes, "./patch_decomp_cachebufram.sh zImage" modifies that zImage to boot faster. It requires the xxd hexdump tool that's packaged with vim.
Kexec support itself, along with the slew of other source patches, has to be applied to a kernel source tree, from which a new kernel must be built to take advantage of them.
Click to expand...
Click to collapse
I see...so its a no-go for gb. Or at least quick gingerbread.
sent from my epic 4g. with the key skips.

ugothakd said:
I see...so its a no-go for gb. Or at least quick gingerbread.
Click to expand...
Click to collapse
You should be able to kexec a GB kernel, but you'd need an EC05-ish /system on flash to boot recovery. Unless GB recovery is compatible with Froyo kernels.
If you're going to boot a GB kernel, you'd probably want to repackage the initramfs with an init.rc that loads the rest of the GB ROM off SD. It's actually not a bad way to keep EC05 around for a stable, working phone, and to test GB leaks as they happen. Which, hopefully, shouldn't be much longer.

wow mkasick, you never cease to amaze me bro...
I wish I wasn't working so many damned hours now, with your patches, I really want the dual boot now. Like you, the need for a working phone at all times is what keeps me from flashing more ROMs, including EpicCM and the gb leaks...
I hope Rodderik figures this out pretty quickly, as most of my dev time is spent on the IRC channels, and he's usually around to help and answer questions.
Once I can get my Clean Kernel working with this, I'll be stoked... I have had a tough time dealing with patches thus far, I usually git cherry-pick and/or manually edit, so I need to figure out how to use the patches correctly.
Anyways, gotta go to work now (I'm working 50+ hour weeks now, hence the time constraints), but hopefully I can get the time to get it into my kernel.
Thanks, mkasick!
Sent from my Samsung Epic4G

DRockstar said:
I have had a tough time dealing with patches thus far, I usually git cherry-pick and/or manually edit, so I need to figure out how to use the patches correctly.
Click to expand...
Click to collapse
What environment (OS, etc.) are you using? Is the "patch" utility working for you?
The patches are split up based on functionality. In each patch directory there's a "series" file that lists the order they should be applied. There's a program, quilt that can help manage them but it's not necessary. If you're running a bourne shell (e.g., bash) in the "Kernel" directory of the kernel sources, you should be able to apply the patches with:
Code:
while read i; do patch -p 1 < "/path/to/kexec_patches/kernel-EC05/$i"; done < "/path/to/kexec_patches/kernel-EC05/series"
Whether they'll apply cleanly or not is a different story, but that's the general idea.
And yeah, time ....

Thank you mkasick, that's a great explanation, I think I can handle that, much appreciated!
For the record, I compile by ssh into dev boxes donated for dev use. They all run linux in different distros. I find this most convenient since I can do most everything from the command line using your brilliant connectbot for epic
Sent from my Samsung Epic4G

With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?

ugothakd said:
With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?
Click to expand...
Click to collapse
You mean for boot_zImage_recovery.zip to work?
The CWM kernel doesn't need full kexec support in order to be booted via kexec. But it does need the copy_atags patch in order to respect the "bootmode=3" kernel argument.
Actually, you can take any existing Epic kernel and somewhat-easily fix it to be bootable via kexec. Steps are:
1. Extract EC05 kernel sources. Or use the GB sources, it doesn't matter, it doesn't even have to match the version of the kernel you're fixing.
2. Apply "decomp_cachebufram" and "decomp_copy_atags" patches.
3. Build a kernel. Config options don't matter much since this kernel is going to be thrown away.
4. Find the zImage for the kernel you want to fix. Run:
Code:
skip=`grep -Fabom 1 $'\x1f\x8b\x08' zImage | head -n 1 | cut -d : -f 1`
dd if=zImage bs=1 skip="$skip" | gunzip > Image
cp Image arch/arm/boot/Image
which extracts the decompressed kernel payload from the zImage, and replaces the "Image" that was previously built with the one you've extracted.
5. Run "make" in the kernel source directory again. You might have to append a "CROSS_COMPILE=" path to match the one used in a build script. The output should be:
Code:
CHK include/linux/version.h
make[1]: `include/asm-arm/mach-types.h' is up to date.
CHK include/linux/utsrelease.h
SYMLINK include/asm -> include/asm-arm
CALL scripts/checksyscalls.sh
CHK include/linux/compile.h
Kernel: arch/arm/boot/Image is ready
GZIP arch/arm/boot/compressed/piggy.gz
AS arch/arm/boot/compressed/piggy.o
LD arch/arm/boot/compressed/vmlinux
OBJCOPY arch/arm/boot/zImage
Kernel: arch/arm/boot/zImage is ready
Building modules, stage 2.
MODPOST 13 modules
which shows that the build process took the existing, extracted Image, compressed it, and attached a new kexec-compatible decompressor to it.
The resulting "arch/arm/boot/zImage" can be kexec'd, and command line arguments should be respected, e.g., if you want to boot into CWM recovery.

[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......

Kexec-hardboot patch

In this post, I would like to explain what kexec-hardboot patch is and also bring it to light a bit more since until now, it was only burried in MultiROM thread.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows me to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
Standard kexec call unfortunatelly does not work on Nexus 7. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a commong thing among Android devices, which is why kexec-hardboot was made.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Another difference is that both kernels must be patched. The "host" kernel requires a full patch, the one which is being kexecd' requires only two small compatibility patches.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Full kernel patch: https://gist.github.com/4558647, 4.1 kernel repo, cm 10.1 kernel repo
This is the full kernel patch. Kernels with this patch can be both "host" and "guest" kernels.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
CONFIG_GROUPER_HARDBOOT_RECOVERY=n
First three options must be enabled. Last one, GROUPER_HARDBOOT_RECOVERY, specifies if the kexec call should reboot to normal mode or to recovery. This can be useful if you don't have the kernel in boot partition but only as kernel in recovery partition. You usualy want to disable this option.​
Compatibility patch: https://gist.github.com/4458581
This patch only makes the kernel bootable via kexec, ie. it can't be the host kernel. This was made for Ubuntu kernel (and it was accepted), because I did not want to drag the whole patch in there. If your kernel is for Android ROMs, you should use the full patch.​
Userspace kexec binary: View attachment kexec-tools.zip
That ZIP file contains kexec source, patches and README. It is from the original patch from Mike Kasick. It also contains precompiled, statically linked kexec binary, so you probably just want to use that.​
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x85000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Currently used by:
MultiROM - I use it to boot different kernels (eg. Ubuntu).
MOSLO - Part of Plasma Active for Nexus 7, also usefull tool for every N7 developer - read more: http://ruedigergad.com/2012/12/09/nexus-7-easily-flashaccess-entire-userdata-partition/
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.

Hi Tasssadar,
im trying to get this to work on the HOX in order to have a shot at multiboot,
the patched applied with no problem... however on compiling i gett this error
"Adress for kexec hardboot page not defined"
ask this error naturely defined to kick in with every device beside N7 i that comment completely....
and that ended up giving me an error about KEXEC_HB_PAGE_ADDR not defined,
so i readded it, but i removed the "#if defined(CONFIG_MACH_GROUPER)"
now trying to compile it, its gets pretty close to the end... but failed with unexpected string error at line OUTPUT_ARCH(arm) in file linux/arch/arm/boot/compressed/vmlinux.lds
Code:
/*
* linux/arch/arm/boot/compressed/vmlinux.lds.in
*
* Copyright (C) 2000 Russell King
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
/DISCARD/ : {
*(.ARM.exidx*)
*(.ARM.extab*)
/*
* Discard any r/w data - this produces a link error if we have any,
* which is required for PIC decompression. Local data generates
* GOTOFF relocations, which prevents it being relocated independently
* of the text/got segments.
*/
*(.data)
}
. = 0;
_text = .;
.text : {
_start = .;
*(.start)
*(.text)
*(.text.*)
*(.fixup)
*(.gnu.warning)
*(.glue_7t)
*(.glue_7)
}
.rodata : {
*(.rodata)
*(.rodata.*)
}
.piggydata : {
*(.piggydata)
}
. = ALIGN(4);
_etext = .;
.got.plt : { *(.got.plt) }
_got_start = .;
.got : { *(.got) }
_got_end = .;
_edata = .;
. = ALIGN(8);
__bss_start = .;
.bss : { *(.bss) }
_end = .;
. = ALIGN(8); /* the stack must be 64-bit aligned */
.stack : { *(.stack) }
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
}
also, im booted into windows now... so i can't provide the exact error.

I'm afraid "comment everything which doesn't work" won't work here. The KEXEC_HB_PAGE_ADDR and END_MEM is device-specific, it will most likely be different for HTC One X. You can find out what address is it supposed to be by examining /proc/iomem on your device. For example, here's memory map from grouper:
Code:
...
80000000-be9fffff : System RAM
80008000-808faba7 : Kernel text
80940000-80b8228f : Kernel data
beb00000-bebfffff : ram_console
...
So, for grouper, END_MEM is 0xbe9fffff + 1 = 0xbea00000.
KEXEC_HB_PAGE_ADDR is located 1MB before console RAM, which is in this case also immediatelly after System RAM, so for grouper, it is also 0xbea00000.
but failed with unexpected string error at line OUTPUT_ARCH(arm) in file linux/arch/arm/boot/compressed/vmlinux.lds
Click to expand...
Click to collapse
That doesn't seem to be related to this patch. Are you using correct cross-compiler?

Tasssadar said:
I'm afraid "comment everything which doesn't work" won't work here. The KEXEC_HB_PAGE_ADDR and END_MEM is device-specific, it will most likely be different for HTC One X.
Click to expand...
Click to collapse
i figured
but im walking you through what i did.
You can find out what address is it supposed to be by examining /proc/iomem on your device. For example, here's memory map from grouper:
Code:
...
80000000-be9fffff : System RAM
80008000-808faba7 : Kernel text
80940000-80b8228f : Kernel data
beb00000-bebfffff : ram_console
...
So, for grouper, END_MEM is 0xbe9fffff + 1 = 0xbea00000.
KEXEC_HB_PAGE_ADDR is located 1MB before console RAM, which is in this case also immediatelly after System RAM, so for grouper, it is also 0xbea00000.
Click to expand...
Click to collapse
Code:
7d000000-7d003fff : tegra-udc.0
7d000000-7d003fff : tegra-otg
7d000000-7d003fff : tegra-udc
7d004000-7d007fff : tegra-ehci.1
80000000-beafffff : System RAM
80008000-8094000f : Kernel text
809a8000-810b940f : Kernel data
beb00000-bebfffff : ram_console
bec00000-beffffff : fbmem
bf000000-bf7fffff : fbmem
0xbeafffff + 1 = 0xbeb00000
grrr that would put me inside the ram_console...
aaaa would it wok if i used the address before??
7d00800
Edit:
or did your ram RAM end earlier because you set you END_MEM 0xbea00000
in that case, it works out just the same with the HOX
That doesn't seem to be related to this patch. Are you using correct cross-compiler?
Click to expand...
Click to collapse
i would have guessed so, but the kernel compiled and is working before the patch.
im using the one provided by google (Android NDK r9) while it contains booth gcc 4.6/4.8 im using 4.6 (arm-linux-androideabi-)

The patch will move ram_console 1MB further, see https://gist.github.com/Tasssadar/4558647#file-n7_hardboot-diff-L387 . You'll have to modify this part of the patch, it will be in different file for your device.

Tasssadar said:
The patch will move ram_console 1MB further, see https://gist.github.com/Tasssadar/4558647#file-n7_hardboot-diff-L387 . You'll have to modify this part of the patch, it will be in different file for your device.
Click to expand...
Click to collapse
HOX is also a Tegra 3 device... so im guessing i wont need to touch a thing?
also note... that iomem provided is from an unpatched kernel (as i cant compile a patched one)
also,
im currently on freenode #htc-one-x
if you dont mind joining.

I've been looking through the kexec-hardboot patch these last few days, trying to actually understand it instead of just blindly porting it and after several hours of messing with assembler with no means to debug it, I've managed to remove the need for guest kernel to be patched. This is not really useful for grouper, since thanks to multirom and accepting kernel devs, nearly every third-party kernel has the proper patches. But, if I'll port multirom to some other device (hello, flo), it will be very useful
To know more see the changes in this commit, but you'll probably need to understand how the patch does things: https://github.com/Tasssadar/androi...mmit/2ce4130061f72430a8ddfde25346c4e528c5c30b
@mkasick: Could you please look over this? I'm afraid there's some good reason why you didn't do this in the first place, like rewriting some part of memory which shouldn't be rewritten or something like that. Thank you.

Tasssadar said:
I've been looking through the kexec-hardboot patch these last few days, trying to actually understand it instead of just blindly porting it and after several hours of messing with assembler with no means to debug it, I've managed to remove the need for guest kernel to be patched. This is not really useful for grouper, since thanks to multirom and accepting kernel devs, nearly every third-party kernel has the proper patches. But, if I'll port multirom to some other device (hello, flo), it will be very useful
To know more see the changes in this commit, but you'll probably need to understand how the patch does things: https://github.com/Tasssadar/androi...mmit/2ce4130061f72430a8ddfde25346c4e528c5c30b
@mkasick: Could you please look over this? I'm afraid there's some good reason why you didn't do this in the first place, like rewriting some part of memory which shouldn't be rewritten or something like that. Thank you.
Click to expand...
Click to collapse
Perfect timing, just finished my last exam
Edit:
Also, this applies on top of the original patch right??
Edit2:
i can't seem to get it to kexec boot, but i didn't do much testing, maybe 2morrow night!
Edit3:
fixed, it was a problem with min-addr,
changed it to 0x82000000 and it worked

One more question...
TEGRA_PMC_BASE is also device specific, ain't it???
So, for a Qualcomm device, what should I be using? I am guessing it is MSM_RPM_BASE, which I got from here: http://forum.xda-developers.com/showpost.php?p=31127486&postcount=7

Yes, it is SoC-specific. This is using some special register to reset the chip, I'm not sure if that is available on msm chips - probably yes, but in some different form. Your best chance is to examine restart sequence in arch/arm/mach-msm/restart.c and port it to assembler.

Tasssadar said:
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0xA0000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Click to expand...
Click to collapse
The address of 0xA0000000 is not necessarily the best choice going forward. It originally made perfect sense, as it is well above everything else. But now that we can boot unpatched guest kernels, we can hit the interesting situation where the guest decompression may take a full minute. At least it's when I've seen on the Ouya game console that's running the next chip after Grouper.
When I realized what's going on, I changed to 0x8E000000, as it gets me just below the 256 MB limit of cache-enabled memory that's present on a typical guest at that early decompression stage. It's enough to hold a typical 8 MB boot image kernel/ramdisk. Now the guest kernel startup is fast in all cases.
Thank you Tasssadar for continuing your work in this area, especially with finding that way to allow unpatched guests.

Indeed, that's actually what I'm using in MultiROM for flo and mako (and grouper, but it is useless 'cause not all 3rd-party kernels have been updated), I just kinda "forgot" to update these threads.

Would it work on devices with locked bootloaders (Xperias). I mean :does the idea of this patch would also work on bootloader unlock allowed :no devices?
Sent from my LT22i using xda app-developers app

I am trying to build a kexec patched kernel integrated into a ROM. I make sure that the following code is there in the defconfig:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
The ROM works well, except that it does not boot my secondary ROMs - kexec hardboot patch missing. I have multi ROM and TWRP recovery installed
What am I missing?

Logs or it didn't happen.
Show me dmesg from normal boot into android, with MultiROM and your kernel installed.
Code:
adb shell
su
dmesg > /data/local/tmp/dmesg.txt
exit
exit
adb pull /data/local/tmp/dmesg.txt

Porting?
Tassadar which things do I need to boot kexec kernel on my device (Motorola Electrify 2) .

@Tasssadar, Sorry for picking up this kinda "old topic" but I'm sadly experiencing some problems while trying to port kexec-hardboot to the Sony Xperia Z2 (aka sirius). I applyed all needed commits (cherry-picked from a apparently working Z1 repo for stock kernel) to my CM based custom kernel (https://github.com/Myself5/android_kernel_sony_msm8974/tree/kexec-cm-12.0) and it does not boot at all. It's stuck on the Sony Logo, and it seems like I can't get any log either. I also tryed the stock cm kernel with the patch (https://github.com/Myself5/android_kernel_sony_msm8974-kexec) cause I tought it might be some incompatibility, but sadly it wasn't. Hope you have any ideas to solve my problems, cause I'm out of ideas ATM. I also checked the kexec commits for other devices (namely the One Plus One) and it seems like I got everything needed.
Thanks in Advance

Tasssadar said:
In this post, I would like to explain what kexec-hardboot patch is and also bring it to light a bit more since until now, it was only burried in MultiROM thread.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows me to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
Standard kexec call unfortunatelly does not work on Nexus 7. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a commong thing among Android devices, which is why kexec-hardboot was made.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Another difference is that both kernels must be patched. The "host" kernel requires a full patch, the one which is being kexecd' requires only two small compatibility patches.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Full kernel patch: https://gist.github.com/4558647, 4.1 kernel repo, cm 10.1 kernel repo
This is the full kernel patch. Kernels with this patch can be both "host" and "guest" kernels.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
CONFIG_GROUPER_HARDBOOT_RECOVERY=n
First three options must be enabled. Last one, GROUPER_HARDBOOT_RECOVERY, specifies if the kexec call should reboot to normal mode or to recovery. This can be useful if you don't have the kernel in boot partition but only as kernel in recovery partition. You usualy want to disable this option.​
Compatibility patch: https://gist.github.com/4458581
This patch only makes the kernel bootable via kexec, ie. it can't be the host kernel. This was made for Ubuntu kernel (and it was accepted), because I did not want to drag the whole patch in there. If your kernel is for Android ROMs, you should use the full patch.​
Userspace kexec binary: View attachment 1653562
That ZIP file contains kexec source, patches and README. It is from the original patch from Mike Kasick. It also contains precompiled, statically linked kexec binary, so you probably just want to use that.​
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x85000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Currently used by:
MultiROM - I use it to boot different kernels (eg. Ubuntu).
MOSLO - Part of Plasma Active for Nexus 7, also usefull tool for every N7 developer - read more: http://ruedigergad.com/2012/12/09/nexus-7-easily-flashaccess-entire-userdata-partition/
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.
Click to expand...
Click to collapse
I'm sorry for picking up this older topic as well, but I always played with the thought of merging kexec support into a kernel and I'm doing one right now.. But my secondary device is a LG G2 and since the era of Lollipop began, somehow MultiBoot just stopped working and nobody can figure out why. I think they even started to build some new concept now.. So before I spark a heated debated by Note 4 users I'd love to know if you have any idea if this patch is still applicable? Altough the only way to find out is to probably just try it lol.

Tasssadar said:
In this post, ....
Click to expand...
Click to collapse
Bro can you please mention on your wiki that kexec isnt supported for x64 devices? It will be great help and save developers hours! I was porting for oneplus 2 when a dev told me that kexec isnt there for x64. I was shocked
Is any alternative available for that? Please reply! Thanks.
All other devs, who cant make multirom to work (lollipop is the x64 era) stop working. Kexec isnt supported for x64. Find an alternative for it.

Can Anyone help me to port this? Here is my patched kernel (ignore arch/arm64) and this is /proc/iomem.
Code:
80000000-854fffff : System RAM
80008000-80fa43ef : Kernel code
81112000-817bf797 : Kernel data
8cb00000-9fefffff : System RAM
9ff00000-9ff3ffff : persistent_ram
9ff40000-9ff7ffff : persistent_ram
9ff80000-9fffffff : persistent_ram
a0000000-ffffefff : System RAM
For kexec_hb_page_addr the value i inseted is 85500000 coz as tasssadar said 884fffff + 1 = 85500000, but I don't know what value add for
Code:
#elif defined(CONFIG_ARCH_MSM8916)
/* Restart using the PMIC chip, see mach-msm/restart.c */
ldr r0, =MSM8916_HARDBOOT
mov r1, #0
str r1, [r0, #0]
loop: b loop
MSM8916_HARDBOOT, and if I compile the kernel it stucks on samsung logo.

[ROM+KERNEL]HUAWEI WATCH 2[LTE-Sawshark]+[BT-Sawfish]-[OWDE.180926.001.A1][22-Jan-20]

[HUAWEI WATCH 2 (LTE/4G-Sawshark) & (Bluetooth/BT-Sawfish)-OWDE.180926.001.A1]​INTERNATIONAL VERSION
Please read the instructions and notes before flashing anything. Don't ask me if you don't read the instructions.
Code:
###Disclaimer###
[COLOR="Red"][B]WARNING:
IMPROPER FLASHING MAY POTENTIALLY BRICK YOUR DEVICE. SO PLEASE PROCEED AT YOUR OWN RISK. ME OR ANY OTHER DEVELOPER MENTIONED IN THIS POST WILL ASSUME NO RESPONSIBILITY FOR THIS.[/B][/COLOR]
​
DONATE ME HERE
DONATE-ME
##############################
REQUIREMENT
##############################
- An Unlock bootloader
- Working adb/fastboot and driver - Download from Here
- A custom recovery (twrp) See my twrp thread for custom twrp recovery
TWRP-RECOVERY
##############################
HOW TO FLASH KERNEL/BOOT IMAGE
##############################
- Steps via adb/fastboot
- Unzip the folder and move the boot image into your adb/fastboot folder and apply the following commands
Code:
- adb devices
- adb reboot bootloader
- fastboot flash boot boot.img
- fastboot reboot
##############################
HOW TO FLASH THE ROM AND ROOT
##############################
1- Move the build/ROM and Busybox and Magisk to your watch
2- Make a backup - there's always 1% chance something goes wrong.
3- Full wipe is recommended....Wipe data/Factory reset
4- Flash the ROM, then flash Busybox and Magisk (Please flash in this order, ROM, then Busybox and Magisk)
5- Reboot and complete your initial setting
6- Open Magisk Manager and go to settings and set Automatic Response to Grant
7- Done. Don't forget to donate if you like my work, Thanks.
##############################
ROM AND KERNEL FEATURES [22-Jan-2020]
##############################
[Changelog]-Huawei Watch 2 LTE(Sawshark)+Huawei Watch 2 BT(Sawfish)-[22/Jan/2019]
- Based on latest kernel source (-Source 3.18.24) android-wear with latest security patch
- Linux version 3.18.24 (gcc version 4.9.3 20141215 (prerelease) (UBER-SaberMod-4.9.3_arm-graphite)) #1 SMP PREEMPT Wed Jan 22 9:45:39 CET 2020
- Forced-encryption disabled
- dm-verity removed/disabled
- Auto memory killer set to default
- Sepolicy is patched
- Fix the CPU idle latency unvote timeout. It should reduce the wasting power and CPU go to deep idle states immediately after a request
- Add and use a timer frequency of 100 Hz. It should improve power consumption.
- Add and update/Hide verifiedbootstate from /proc/cmdline in order to fix the failed SafetyNet CTS check(It can still fail through other means)-GOOGLE PAY SHOULD WORK. USE MAGISK TO HIDE ROOT. U may need Gpay enabler
- Remove verifiedbootstate flag from /proc/cmdline - Disable CRC check
- Scheduler optimize/support for heterogeneous multi-core
- Scheduler support for heterogeneous multi-processor systems
- Enable all core with scaling_available_frequencies (200000 400000 533333 800000 1094400 1267200 MHz)- scaling down the frequency of the CPUs to 200 MHz during idl mode and rise the freq. to 1.26Ghz during high pressure.
- Set swappiness to 60
- Change zswap max pool % to 20%. It will reduce CPU usage a lot
- Enable zram & zswap and add 256MB virtual memory default. It will speed up the device a lot
- Removed nolog usage, remove rtb logging from the kernel
- Remove selinux auditing from kernel for lower overhead
- Remove IPC logging from the kernel
- Disabled some kernel parameter to speed up the performance- at the cost of battery/ power consumption
- Remove some logging from several drivers
- Improve memory allocations -Should improve the device a lot
- Add some tweaks to improve the overall speed, apps startup are too faster
- Set zswap compressor to lz4 by default
- APM driver updated again to reduce battery usage during sleeping
- Several other patches to reduce battery usage
- Multi-core scheduler enable/optimized
- APM driver updated reduce battery usage during sleeping
- Fix the wake up time. The screen should wake up more quickly when pressing the button.
- Tweaked the scheduler to reduce/save power by scaling down the frequency of the CPUs or idling them,
- A lot subsystems converted to use power efficient workqueue
- The watch goes to sleep during no action in order to save battery
- Remove debug event logging-Kill the useless logging to reduce overhead
- Remove sync debug entirely to cut down CPU waste in the frame render hot path
- Remove 10 ms CPU idle latency unvote timeout- Doesn't force the CPU to stay out of deep idle states for far longer than necessary, which wastes power
- Disable audit support, usually comes with a measurably significant amount of overhead
- Remove audit dependency
NOTE: THERE IS NO NEED TO FLASH THE LATEST KERNEL IF YOU FLASH THE LATEST ROM.
##############################
DOWNLOAD
##############################
[Huawei Watch 2 4G/LTE]+[Huawei Watch BT][22-Jan]
[DECRYPTION KEY]
WO0FVexxQnrtcODYdmNvnQ
##############################
MAGISK/BUSYBOX/APP-KERNEL-CONTROL
##############################
DOWNLOAD LATEST MAGISK FROM HERE
DOWNLOAD LATEST BUSYBOX FROM HERE
KERNEL CONTROL APP WEAR OS
##############################
How to get the Gpay back...
##############################
1-https://pastebin.com/HKV7cj7H
2-https://forum.xda-developers.com/smartwatch/other-smartwatches/rom-kernel-t3821013/page172
3-https://www.youtube.com/watch?v=UKxGfNxRjo4&t=320s
4-https://forum.xda-developers.com/showpost.php?p=79637148&postcount=1720
##############################
HOW TO FLASH THE STOCK IMAGES-(BACK TO STOCK)
##############################
1- Download and unzip the system image below
2- Attach the watch charger to the watch and plug the USB cord (from the charger) into your computer
3- Use the following adb command to start the watch in fastboot mode: adb reboot bootloader
4- On your computer, navigate to the directory where you unzipped the system image in Step 1. At the top level of that directory, execute the flash-all script:
- On Linux or MacOS, type ./flash-all.sh
- On Windows, type flash-all.bat
5 -DONE. Don't forget to donate if you like my work, Thanks.
STOCK-IMAGES-HUAWEI-WATCH-2-LTE-LEO-DLXX-OWDE.180215.017-SAWSHARK-(13/Oct/2018)
STOCK-IMAGES-HUAWEI-WATCH-2-BT-LEO-BX9-OWDD.180215.018-SAWFISH-(22/7/2018)
##############################
Source/GitHub
##############################
-Source
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE
DONATE-HERE
Special thanks to:
If you can, donate and respect all the devs and enjoy
@Chainfire for great work in android
@Maxr1998 Big thanks for giving me knowledge and your great work for Asus Zenwatch_3 and your great github guide. Please thank and donate him for all his efforts
@topjohnwu for his great effort (Magisk)Thank you so much
@SuperR.R for the great kitchen
@Xmaster24 for system-less root-
@moneytoo for his great app. Please appreciate and donate him
Pay Enabler
@SuperThomasLab for great tools
Please always support devs and others (soon).​

ROM download asking for decryption key?Can fix the link?

Hello All,
Is it possible to install this latest ROM on model without LTE?
Thank you for reply :good:

arthos7 said:
ROM download asking for decryption key?Can fix the link?
Click to expand...
Click to collapse
Hoffmanns said:
Hello All,
Is it possible to install this latest ROM on model without LTE?
Thank you for reply :good:
Click to expand...
Click to collapse
Link are fixed now. It will properly not gonna work on non-lte. I can build a new for non-lte version if some one send me the latest system image and boot image. (I can extract from your watch via teamviewer, in case you can't) But you need to flash the latest firmware without root.
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE​

I will upload a complete latest stock images N7176C (lte) incase anyone wanna go back to latest stock again.
The only thing you have to do is boot into bootloader mod and then run the script by double click on it. After some reboots you will be back on latest stock.
I will combine both Linux and Windows together, use one you prefer.
IF YOU LIKE MY WORK AND WANT ME TO CONTINUE, THEN BUY ME A SHOT OF WHISKY
DONATE ME HERE​

Just received my Huawei SW 4G this weekend and after installing Huawei wear I got the alert message that the watch was rooted.
How can I confirm is it's rooted or not.
Thanks
Sent from my ONEPLUS A3003 using Tapatalk

Can anyone who's used this verify that it's notably faster or has improved battery life compared to stock? Or is the difference negligible?

How to build boot.img
Hi Janjan,
I am trying to build a custom kernel for my Huawei Watch 2 (non LTE) and I was wondering if you could share a little of your development work.
How do you actually put the boot image together? I am able to compile the kernel from android-msm-sawshark-3.18-nougat-mr1-wear-release,
which gives me a zImage. I also have the original images. So I tried to unmkbootimg the original boot image and replace the kernel. However, this doesn't seem to work. when I compare the sizes of the supposedly original zImage and the one created from the repository above, their size differs by roughly a factor of 100. So there must be something seriously wrong
What steps do you use to create the kernel and the boot image?
I also checked your github code and tried to use it but it seems to depend on other stuff that is not in your repos. Where did you find the code you have in your repos?
Best regards,
Mogli

janjan said:
I can build a new for non-lte version if some one send me the latest system image and boot image. (I can extract from your watch via teamviewer, in case you can't) But you need to flash the latest firmware without root.
Click to expand...
Click to collapse
Does that offer still stand? If yes I am willing to let my watch be used as a test subject.

mogli19 said:
Hi Janjan,
I am trying to build a custom kernel for my Huawei Watch 2 (non LTE) and I was wondering if you could share a little of your development work.
How do you actually put the boot image together? I am able to compile the kernel from android-msm-sawshark-3.18-nougat-mr1-wear-release,
which gives me a zImage. I also have the original images. So I tried to unmkbootimg the original boot image and replace the kernel. However, this doesn't seem to work. when I compare the sizes of the supposedly original zImage and the one created from the repository above, their size differs by roughly a factor of 100. So there must be something seriously wrong
What steps do you use to create the kernel and the boot image?
I also checked your github code and tried to use it but it seems to depend on other stuff that is not in your repos. Where did you find the code you have in your repos?
Best regards,
Mogli
Click to expand...
Click to collapse
Sure, tell me what you did and your steps for building zImage + modul. I am away from my office for a while.

janjan, have you had success with making a non-lte version?

cdkg said:
janjan, have you had success with making a non-lte version?
Click to expand...
Click to collapse
If you send me the latest boot.img, system.img and vendor.img then I will definitely make.

janjan said:
If you send me the latest boot.img, system.img and vendor.img then I will definitely make.
Click to expand...
Click to collapse
I have the boot.img and system.img. Is there a tutorial or any instructions you could give on how to get the vendor.img?

janjan said:
Sure, tell me what you did and your steps for building zImage + modul. I am away from my office for a while.
Click to expand...
Click to collapse
Hi Janjan,
(Apparently I am not allowed to post links yet, so I am trying my best to explain without them)
1. I got the source code for the Sawshark watch from github (mr1-wear-release). I guess there is no dedicated Seafish kernel source. Short question: There is a choice of 3 different kernel codes. Which one shall I take?
2. I tried to compile this source code without changes (to rule out errors before I make modifications). This works and I get as zImage. What do you mean by modul though? I thought zImage was the only product.
3. Using unmkbootimg, I un-packed an stock boot.img. The unmkbootimg tool says that the boot.img has been compiled with a non-standard mkbootimg program. However the offsets and other values (I am supposed to tune when I use mkbootimg) are contradicting. Eventually, the "non-custom" values recommended by unmkbootimg caused errors in mkbootimg and I ended up using the default values. This worked.
4. When I flash the resulting boot.img my watch gets stuck during boot with the Huawei logo on all the time.
To verify my tools, I tried step 3. in two more ways:
3.1. re-pack the un-packed boot.img, flash it (no errors and boot works)
3.2 pack a boot.img using a zImage obtained from a sawshark boot.img (instead of the seafish). This also worked and boot was successful
I have also looked at the boot.img and zImage files in a hex editor. I can locate the beginning of the kernel but not the end. Also if I did, I wouldn't know how to replace the kernel in hex mode But from what I have understood about mkbootimg, this script does not much more than concatenate zImage and ramdisk and add a header. Is this somewhat correct?
Eventually, I need to turn on some currently disabled kernel features (which is why I am doing all of this ). So I am still trying to figure out the right tools and components. And therefore the question: How do you usually build the kernel and how do you pack it into the boot.img. Do you modify the ramdisk when you replace the kernel?
Best,
Mogli

Instructions to modify ramdisk
Hi Janjan,
How do you disassemble and re-assemble the ramdisk?
Wanted to make a few modifications to the ramdisk.cpio.gz. Again, I wanted to try the tools first. So I unpacked and re-packaged the ramdisk without modifications. After flashing the regenerated boot image, my watch goes into recovery mode...
I found these instructions in a tutorial (again, I can't post links yet... sorry):
For disassembly:
Code:
$ mkdir ramdisk_dir
$ cd ramdisk_dir
$ gunzip -c ../ramdisk.cpio.gz | cpio -i
for re-assembly
Code:
$ find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Update to my previous post:
I found my mistake in building the kernel:
Instead of using
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androidkernel-
I was using
Code:
make ARCH=arm CROSS_COMPILE=arm-linux-androideabi-

mogli19 said:
Hi Janjan,
How do you disassemble and re-assemble the ramdisk?
Wanted to make a few modifications to the ramdisk.cpio.gz. Again, I wanted to try the tools first. So I unpacked and re-packaged the ramdisk without modifications. After flashing the regenerated boot image, my watch goes into recovery mode...
I found these instructions in a tutorial (again, I can't post links yet... sorry):
For disassembly:
for re-assembly
Update to my previous post:
I found my mistake in building the kernel:
Instead of using
I was using
Click to expand...
Click to collapse
It seems much better now. Are you in Windows or Linux? I will post my script and tools once I reach my PC. I am away from my PC right now. It means you destroy something during generating or packaging the boot image. Does you kernel /boot.img work without or before editing the ramdisk?
Update:- seems you are in Linux.

janjan said:
It seems much better now. Are you in Windows or Linux? I will post my script and tools once I reach my PC. I am away from my PC right now. It means you destroy something during generating or packaging the boot image. Does you kernel /boot.img work without or before editing the ramdisk?
Update:- seems you are in Linux.
Click to expand...
Click to collapse
Yes, I am on linux. I found a different approach that works for me now:
Code:
Extract the ramdisk.
$ mkdir ramdisk
$ cd ramdisk
$ gzip -dc ../ramdisk.cpio.gz | cpio -i
# Make any changes necessary (e.g., set ro.secure=0 in default.prop).
# Recreate the cpio archive using the mkbootfs binary produced from building the Android source code
$ cd ..
$ mkbootfs ./ramdisk | gzip > ramdisk-new.gz
You said you were able to turn on all the cores. Can this be done by modifying the ramdisk or how do you do this?

mogli19 said:
Yes, I am on linux. I found a different approach that works for me now:
You said you were able to turn on all the cores. Can this be done by modifying the ramdisk or how do you do this?
Click to expand...
Click to collapse
Did I said? But It can't be done by editing the ramdisk only. You need to add and edit alot (add driver edit cores etc) in kernel sources.

Okay, before anyone flames, I did look everywhere in this thread and cannot find it. Does anyone have the link to the flashing instructions for this rom?

janjan said:
Did I said? But It can't be done by editing the ramdisk only. You need to add and edit alot (add driver edit cores etc) in kernel sources.
Click to expand...
Click to collapse
Oh sorry, I thought I had read this on your feature list I actually looked at this and asked myself if there was a way to make the cpu settings permanent:
https://stackoverflow.com/questions/20221680/android-how-to-force-cpu-core-offlineshut-down-cores