5,597,647 Members 33,015 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
mkasick
Old
(Last edited by mkasick; 7th November 2011 at 03:15 AM.) Reason: Added statically-linked kexec.
#1  
Recognized Developer - OP
Thanks Meter 823
Posts: 470
Join Date: Aug 2009
Default [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
Attached Files
File Type: tar demo_kernel.tar - [Click for QR Code] (5.46 MB, 90 views)
File Type: txt patch_decomp_cachebufram.sh.txt - [Click for QR Code] (996 Bytes, 131 views)
File Type: tar kexec_patches.tar - [Click for QR Code] (416.3 KB, 221 views)
File Type: zip boot_zImage.zip - [Click for QR Code] (259.7 KB, 85 views)
File Type: zip boot_zImage_recovery.zip - [Click for QR Code] (259.8 KB, 79 views)
The Following 22 Users Say Thank You to mkasick For This Useful Post: [ Click to Expand ]
 
squshy 7
Old
#2  
Senior Member
Thanks Meter 449
Posts: 1,406
Join Date: Dec 2010
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
[21:22] <Shabbypenguin> but the nexus... well its gunna be better than sex
 
ugothakd
Old
#3  
Senior Member
Thanks Meter 404
Posts: 1,485
Join Date: Jun 2011
Location: O 'Fallon, MO
Quote:
Originally Posted by squshy 7 View Post
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
Old
(Last edited by stilesja; 18th September 2011 at 03:01 PM.)
#4  
stilesja's Avatar
Senior Member
Thanks Meter 97
Posts: 402
Join Date: Feb 2011
Location: Knoxville

 
DONATE TO ME
Quote:
Originally Posted by squshy 7 View Post
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
 
ac16313
Old
#5  
ac16313's Avatar
Senior Member
Thanks Meter 377
Posts: 2,745
Join Date: Mar 2011
Location: 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
 
formula84
Old
#6  
Senior Member
Thanks Meter 389
Posts: 2,173
Join Date: Aug 2007
Location: Philadelphia - HTC One (m7)
All I have to say is hope you stick with the epic your amazing

Sent from my SPH-D700 using Tapatalk
 
mkasick
Old
(Last edited by mkasick; 18th September 2011 at 08:19 PM.)
#7  
Recognized Developer - OP
Thanks Meter 823
Posts: 470
Join Date: Aug 2009
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.

Quote:
Originally Posted by formula84 View Post
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?
The Following 2 Users Say Thank You to mkasick For This Useful Post: [ Click to Expand ]
 
ugothakd
Old
#8  
Senior Member
Thanks Meter 404
Posts: 1,485
Join Date: Jun 2011
Location: O 'Fallon, MO
Quote:
Originally Posted by mkasick View Post
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.
 
thomasskull666
Old
#9  
thomasskull666's Avatar
Senior Member
Thanks Meter 415
Posts: 1,552
Join Date: Sep 2010
Location: St. Louis

 
DONATE TO ME
this is definitely very cool, thanks mkasick!

Sent from my SPH-D700 using XDA Premium App
*_Epic 4G_*
*_Sprint Galaxy Nexus_*
The Following User Says Thank You to thomasskull666 For This Useful Post: [ Click to Expand ]
 
Rodderik
Old
#10  
Rodderik's Avatar
Recognized Developer
Thanks Meter 1311
Posts: 1,300
Join Date: Sep 2010

 
DONATE TO ME
mkasick you never cease to amaze me...i'll definately play with this, this week if i have the time!
Devices: EVO 4G LTE (pre-ordered), Epic 4g, Sprint 7" Galaxy Tab, HP TouchPad (CM9), Nook Color (CM7), Transform, Intercept

Epic 4G Kernel: Genocide EC05 Kernel v2.0|1.4GhzOC|RomManager|CustomUV|DUALBOOT
Galaxy Tab: [SPRINT][CDMA]Samsung Galaxy Tab (SPH-P100) Mega Development Starter Thread

http://devphone.org

The Following User Says Thank You to Rodderik For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes