Hello,
First of all, I am not attempting to compete with the other awesome images for the G Tablet available. I am doing this process to learn, and maybe contribute to the community.
I have grabbed the AOSP directly from Google's repo tree, and compiled it in two different ways: Generic build, modifying BoardConfig.mk and other files as necessary. I have also used the Device/Vendor files from the Cyanogen Beta 4 harmony repo tree, and compiled a harmony target with AOSP.
When I compiled the generic build (or the the targeted build), I made sure all proprietary files from the tablet had been extracted and replaced in my system.img. (I got this list from the extract-files.sh script in Cyanogen harmony repo).
I have found that using the stock boot.img from the original nvflash files will boot nearly any system.img (from my update.zip in clockwork). I used this original boot.img, combined with my system.img from the AOSP build (with the proprietary files in place), and made an updater-script which installed things. I found that the system.img was properly extracted to /system.
The problem that occurs -- when booting, the Viewsonic bootup screen will load the GTablet screen, but it will eventually loop back to the Viewsonic screen and report "deleting msc" prior to returning to Recovery Mode on it's own.
I have enabled ADB persistence in the boot ramdisk, and it works fine as long as it's not my system.img. When I use the AOSP system.img, adb devices shows the device, but adb shell/logcat fail until the device power cycles.
Does anyone know what I might be missing?
Also want to add:
I have tried the stock boot.img, which lacks a 'cmdline' parameter, and I have tried using the cmdline parameters from the Cyan Harmony boot.img specifications. I am not sure if this might have something to do with the issue or not.
kornyone said:
Hello,
First of all, I am not attempting to compete with the other awesome images for the G Tablet available. I am doing this process to learn, and maybe contribute to the community.
I have grabbed the AOSP directly from Google's repo tree, and compiled it in two different ways: Generic build, modifying BoardConfig.mk and other files as necessary. I have also used the Device/Vendor files from the Cyanogen Beta 4 harmony repo tree, and compiled a harmony target with AOSP.
When I compiled the generic build (or the the targeted build), I made sure all proprietary files from the tablet had been extracted and replaced in my system.img. (I got this list from the extract-files.sh script in Cyanogen harmony repo).
I have found that using the stock boot.img from the original nvflash files will boot nearly any system.img (from my update.zip in clockwork). I used this original boot.img, combined with my system.img from the AOSP build (with the proprietary files in place), and made an updater-script which installed things. I found that the system.img was properly extracted to /system.
The problem that occurs -- when booting, the Viewsonic bootup screen will load the GTablet screen, but it will eventually loop back to the Viewsonic screen and report "deleting msc" prior to returning to Recovery Mode on it's own.
I have enabled ADB persistence in the boot ramdisk, and it works fine as long as it's not my system.img. When I use the AOSP system.img, adb devices shows the device, but adb shell/logcat fail until the device power cycles.
Does anyone know what I might be missing?
Click to expand...
Click to collapse
Did you ever get your AOSP build to boot?
tjohnsonjr said:
Did you ever get your AOSP build to boot?
Click to expand...
Click to collapse
I did. It's in the Dev section now
Alright guys. I'm trying to get a custom CM7 kernel running on my Incredible. As background, I am well versed in kernel compilation in general and on embedded devices. I followed the directions on the cyanogen wiki (Building_Kernel_from_source), but skipped the section about compiling CM7 itself, since I'm only interested in the kernel. I pulled the kernel from CM's git repo, and it was checked out to the latest version (2.6.37), which is also what my phone was running. I grabbed the 'prebuilt' ARM cross compiling toolchain. I used the kernel config from my phone (/proc/config.gz). Looking through the options with menuconfig, it seemed that the options were correct. I pulled the boot.img from the latest CM7 install zip, (7.0.3), split out the ramdisk.img with split_bootimg.pl, merged my compiled zImage with the ramdisk.img using mkbootimg, copied the resulting img file to my sdcard, ran adb shell from recovery, zero'd out mtd2 (boot), and flashed my custom boot.img using flash_image.
Whew!
I have tried countless times, and every time I try to boot my device with the new kernel, my phone doesn't get past the "htc Incredible" boot screen. It just hangs there. I am completely at a loss as to where to go from here. Any suggestions would be EXTREMELY appreciated.
Thanks for reading.
I just remembered, I ended up using a different tool to split the ramdisk, since the wiki link to split_bootimg.pl was broken. I just now found split_bootimg.pl using google, extracted the custom boot.img I've been trying to throw at my phone, and the kernel section of it was recognized by 'file' utility as data. I'm going to try doing the ramdisk split using split_bootimg.pl tomorrow and see what the resulting boot.img looks like then. I'll report back my results.
Turns out that when you split the boot.img that comes with cyanogen, the kernel in there is also recognized as data. I am no closer to solving this mystery
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.