• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

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

Search This thread

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
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
 

Attachments

  • demo_kernel.tar
    5.5 MB · Views: 286
  • patch_decomp_cachebufram.sh.txt
    996 bytes · Views: 337
  • kexec_patches.tar
    416.3 KB · Views: 624
  • boot_zImage.zip
    259.7 KB · Views: 323
  • boot_zImage_recovery.zip
    259.8 KB · Views: 323
Last edited:

squshy 7

Senior Member
Dec 6, 2010
1,414
450
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
 

ugothakd

Senior Member
Jun 12, 2011
1,486
407
O 'Fallon, MO
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

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

stilesja

Senior Member
Feb 22, 2011
403
97
Knoxville
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

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
 
Last edited:

ac16313

Senior Member
Mar 15, 2011
2,844
397
Phoenix, Arizona
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
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
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.

All I have to say is hope you stick with the epic your amazing
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?
 
Last edited:

ugothakd

Senior Member
Jun 12, 2011
1,486
407
O 'Fallon, MO
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?

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.
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!
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.
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
So to patch any kernel u just point the script to the zImage?
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.
 

ugothakd

Senior Member
Jun 12, 2011
1,486
407
O 'Fallon, MO
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.

I see...so its a no-go for gb. Or at least quick gingerbread.

sent from my epic 4g. with the key skips.
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
I see...so its a no-go for gb. Or at least quick gingerbread.
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.
 

DRockstar

Retired Recognized Developer
Sep 30, 2010
309
561
Pasadena, CA
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
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
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.
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 ....
 

DRockstar

Retired Recognized Developer
Sep 30, 2010
309
561
Pasadena, CA
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
 
Last edited:

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?
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.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 30
    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
    7
    CM7 dualboot update:

    I've been dualbooting CM7 for a while, and Rodderik has gotten it to work on his own as well. While we are slowly getting all the pieces in place to make this relatively easy, it's not yet in a user-friendly package. That said, folks are interested in this and I figure it's worth sharing what I have working now for the brave and capable to take a look at. But do note, this is not final form.

    Requirements:

    First, you need a micro-SD card reader and access to a Linux machine to partition and format a micro-SD card.

    Second, you need a kexec-capable recovery. At present I'm using the stock recovery included in my EI22 keyfix kernel (flashed to bml8), but you'll probably prefer to use DRockstar's test build of CWM5. Note that he hasn't posted that build here yet, but it's mentioned in the topic of the #epic IRC channel and folks have tested it some, and kexec is confirmed to work on it.

    Third, you'll need these files:

    Directions:

    Partition the micro-SD card using a card reader in a Linux machine. I use fdisk, but parted should work as well. You'll want to create exactly four "primary" (not logical/extended) partitions. The first will be vfat (FAT32) formatted and contain the usual /sdcard, while the 2nd-4th will be ext4 formatted for /system, /data, and /cache. The sizes of the partitions aren't particularly important, but in absence of any better ideas, I stay close to the size of the NAND partitions (/system: 260 MB, /data: 501 MB, /cache: 169 MB). As an example, here's the fdisk output for the partitioning of a 2 GB card (well, first 2 GB of an 8 GB card, I have other stuff after):
    Code:
    Disk /dev/sdb: 8017 MB, 8017412096 bytes
    247 heads, 62 sectors/track, 1022 cylinders
    Units = cylinders of 15314 * 512 = 7840768 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disk identifier: 0xe77dc28a
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/sdb1               1         137     1047985    c  W95 FAT32 (LBA)
    /dev/sdb2             138         173      275652   83  Linux
    /dev/sdb3             174         240      513019   83  Linux
    /dev/sdb4             241         263      176111   83  Linux

    After the card is partitioned, it needs to be formatted, which can be done with the commands below. Make sure to replace /dev/sdb with the appropriate block device lest one blow away part of their RAID-0 setup or something:
    Code:
    mkfs.vfat /dev/sdb1
    mkfs.ext4 /dev/sdb2
    mkfs.ext4 /dev/sdb3
    mkfs.ext4 /dev/sdb4

    Once formatted we have to populate the first partition of the micro-SD card with the files necessary to bootstrap CM7. We don't have to worry about the other partitions, those are handled on the phone. The command-line steps for this are:
    Code:
    mount /dev/sdb1 /mnt
    cp boot_zImage.zip boot_zImage_recovery.zip /mnt
    unzip -d /mnt kernel-cm-7.1.0-Epic-KANG-1022-sdrom.zip
    cp update-cm-7.1.0-Epic-KANG-1022-signed.zip /mnt
    umount /mnt
    That is, copy boot_zImage.zip, boot_zImage_recovery.zip, and update-cm-7.1.0-Epic-KANG-1022-signed.zip all to the root of the micro-SD card, and extract zImage from kernel-cm-7.1.0-Epic-KANG-1022-sdrom.zip and place it there as well.

    Shutdown the phone if it isn't already and place the micro-SD card in it. Now, three-finger boot (vol-down, camera, power) into recovery, select "apply update from sdcard" (the specific command varies on the recovery used), then select "boot_zImage_recovery.zip". This will kexec /sdcard/zImage (the CM7 kernel) and boot its recovery. And yes, it's very important that the rest of the installation is preformed under CM7 recovery.

    After selecting "boot_zImage_recovery.zip" you'll be abruptly greeted by the SAMSUNG logo and it should soon boot the cyan-colored CM7 CWM (v5.0.2.6). Here, select "install zip from sdcard", "chooze zip from sdcard", "update-cm-7.1.0-Epic-KANG-1022-signed.zip", "Yes - Install ...". This will flash CM7 onto the second partition of the micro-SD card, and should take a minute or so to complete. One finished, select "Go Back" (which will pause for a few seconds, don't worry), and "reboot system now".

    This will reboot the phone and automatically boot into bml8 (three-finger) recovery--that is, you don't have to hold the three buttons this time. Select "apply update from sdcard", then "boot_zImage.zip". This should force another reboot, SAMSUNG, and in a few moments show the CM7 boot animation. If so, congrats! If not, you'll probably have to battery pull.

    CM7 should work mostly as advertised with two exceptions (that I'm aware of). First, a reboot from CM will always dump you back into bm8 recovery, regardless of the "kind" of reboot, and second, a power off actually does the same thing. That is, the phone powers off as expected, but when powered on again, bml8 recovery is automatically booted.

    This behavior turns out to actually be somewhat convenient as you can select which ROM you want to boot from recovery this way. That is, to boot your regular ROM, select "reboot system now" from recovery. And to boot CM7, select "apply update from sdcard", then "boot_zImage.zip".

    I should also note that normal reboot behavior is restored during execution of the regular ROM so this isn't a permanent change, but rather the behavior only when operating in CM7. Also, to be honest, I'm not sure what happens when one charges with power off from CM7 (i.e., lpm mode). It should work, but I can't say exactly what will boot after--it should be sane though.

    Kernel details:

    The "sdrom" kernel is the CM7 1022 kernel with a repackaged initramfs, wrapped with a patched decompressor to make it kexec compatible. Here, the initramfs changes are the most significant part.

    The changes to the initramfs contain two patches, a fake param.ko, and a bunch of removed storage models. The first patch replaces rfs/NAND support for ext4/SD in the init scripts. The second patch removes NAND (fsr, stl, j4fs) support entirely. In conjuction with the fake param.ko allows the kernel to function without any potential possibility for disturbing the NAND partitions, so the regular ROM is always kept safe. This also means /mnt/.lfs (stl6) is left untouched, which is responsible for the odd reboot behavior.

    Removing NAND support isn't strictly required in SD kernels, it's something I did for testing purposes to avoid any accidents. That said, one beneficial side effect of removing NAND support is that it allows us to flash the CM7 update.zip unmodified. At present, the kernel update step (bmlwrite) fails silently without flashing anything, which is what we want here.

    As I mentioned above, all this is stuff I'm using to test CM7 dualbooting, but it's not the final intended form. Of pieces missing, it would be nice to have a script that partitions (if we decide to go with partitions) and formats a micro-SD card in the phone, so there's no external hardware requirements. It would also be ideal to use an unmodified CM7 kernel, which is doable through kexec initramfs overlays once the decompressor patches are included. With kernel NAND (bml or even mtd) support, additional work will be needed to ensure that CM7 update.zips don't perform the kernel flash step, if it's preferable to maintain the ability of flashing unmodified update.zips.
    4
    With those recovery scripts, doesn't Clockwork Mod have to have kexec set up?
    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.
    3
    I think what you described is how to make a kexec'able cwm kernel.
    Yes. I thought that's what you were asking, hopefully it's still useful info.

    I was asking doesn't cwm have to have kexec?
    Yes, if you're trying to kexec from CWM, which would be nice.

    If you have a kexec-patched kernel in bml7 with an intact recovery, even if it's not CWM, you can use that recovery to kexec stuff. The GB keyfix kernel I posted is of this type. You'll have to "reboot recovery" to get into it, three-finger won't work.

    Actually as a stop gap, you can have an update.zip that calls "reboot recovery", that you apply in CWM (bml8), that reboots into bml7 recovery, from which one can kexec. Attached is an update.zip that should do that.
    2
    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.

    All I have to say is hope you stick with the epic your amazing
    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?