Kexec, and a Proof-of-Concept Source-Built Kernel (Bootloader Workaround)

Search This thread

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
So when you say you just reboot to get back to the stock kernel, is it a certain way of rebooting?
Say you have a ROM installed that's compatible with the stock kernel, but you also want to run a custom kernel. You can kexec the custom kernel from CWM. And, if you want to "switch back" to the stock kernel, just reboot.

But if you have a source-built ROM (CM, AOKP, etc.) installed to the /system partition then the stock kernel will be incompatible. You'll always have to kexec the source-built kernel.

That's a point of frustration for sure. If there's no other bootloader workaround found, we've discussed the idea of hijacking part of the boot process to detect if the stock kernel is being used to boot a source-built ROM, and if so, redirect it to boot recovery and automatically kexec a source-built kernel. Of course, the details on that still need to be figured out.

Anyways, what we're planning to do on the Sprint SGS3 is make the first CM releases actually (kexec) bootable from the SD card, so they won't be written to the /system partition at all. This lets both stock ROM and CM co-exist until the bugs can be worked out, and CM is worthy of being run full time.

I'd recommend that initial CM ports for the Verizon SGS3 use the same approach, at least in the beginnig.
 

chadamir

Senior Member
Dec 15, 2010
148
32
So, as it stands, merely rebooting the phone, for whatever reason and in any way, will revert back to the stock kernel? In order to back youll have to go into cwm and load the custom kernel?
 

Metfanant

Senior Member
Jan 10, 2011
721
198
what are the potentiall performance/battery drain related issues involved in using such a method??...coming from a DX and our "2nd Init" solutions to running ROMS like CM speed and smoothness are always important, and our 2nd Init ROMS had that, but im only willing to put up with extra battery drain issues to a certain extent...somewhat defeats the purpose...
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
So, as it stands, merely rebooting the phone, for whatever reason and in any way, will revert back to the stock kernel?
Actually, right now, rebooting the phone will reboot to recovery automatically. If you reboot from there, it "reverts" back to the stock kernel.

In order to back youll have to go into cwm and load the custom kernel?
Yes, for now.

what are the potentiall performance/battery drain related issues involved in using such a method??
None. Once the kernel is running, its indistingushable from the way it would run if it were flashed to the device (and the bootloader unlocked), aside from the aforementioned unusual reboot behavior.
 

Loglud

Senior Member
Jul 29, 2011
235
449
Google Pixel 7 Pro
Just to confirm, the kexec hardboot approach used here is a bit different from the typical kexec. The main difference is that we actually perform a hardware reboot, reinvoking the bootloader just prior to booting the kexec'd kernel.

The advantage to this approach is that it maintains a high-degree of compatibility and minimizes buggy behavior. The disadvantage is that it requires that the bootloader is capable of booting custom recoveries, which the present Verizon SGS3 bootloader is capable of doing.

Thus, it's very important that folks do not apply any over-the-air (OTA) update, until it is confirmed that custom recovery booting remains intact.

If it eventually arises that booting from a stock kernel/recovery is necessary, then it's likely a bunch of kernel bugs will have to be fixed, and it might still have compatibility issues observed in previous kexec attempts. It's linked in the blog post, but there's a bit more of a technical description of the hardboot approach in this old thread.

Thanks to invisiblek and captjtkirk for testing.

I worked alot with helping this be built on the Nook Tablet (though we found a secChain hole), and it can be done with an alternative bootloader such as fattire's cyanoboot that can replace the boot loader. To avoid any conflicts with future ota's i would not rely on this KExec method. Kexec is a flag in the kernel. It would take 2 seconds for them to patch this which throws everything out the window. I would focus your time at looking at Aboot, and seeing if their is a way to overload the header to allow for a nonsecure boot. I have referanced this in another post but heres a good link:

I merged the latest B&N 1.4.2 code into my 2nduboot git repository on github: https://github.com/bauwks/Nook-Tablet

It still compiles and works on my 16GB NT and others have have successfully booted the 8GB NT model.

The instructions for building are the same as before:
cd distro/u-boot
PATH=/usr/local/arm-2010q1/bin:$PATH
make nt2ndboot_sd_config
make
./tools/build_nt_2ndboot_img.py -o test.img u-boot.bin
cp test.img /media/boot/flashing_boot.img

For those of you that wish to try it without messy compilers, this zip file (http://dl.dropbox.com/u/40331061/bauwks-boot-1.4.2.zip) contains:
  • MLO from 1.4.2
  • u-boot.bin from 1.4.2
  • flashing_boot.img <- the 2nd uboot

Unzip it to the root directory on an SD card, drop in a boot.img you want to test and go. If you see the box then it's booting off the SD card and should then load your boot.img.


How ever I do have to say this is a major step in the boot unlock and other things. Congradulations to you all.
 

mikereidis

Inactive Recognized Developer
Jan 28, 2011
7,823
4,146
Ottawa/Gatineau, Canada
Team Epic announces a proof-of-concept source-built kernel for the Verizon SGS3, complete with kexec hardboot support.

Great ! :)

A bunch of us want to see if FM can work and we need kernels/modules with this in the config:

CONFIG_RADIO_ADAPTERS=y
CONFIG_RADIO_IRIS=y
CONFIG_RADIO_IRIS_TRANSPORT=m

Would you be able to build with this in the config ?

I don't want to "spam"/duplicate post in kernel threads (more than necessary), so I'll point you here for some further details: http://xdaforums.com/showpost.php?p=28515392&postcount=592

Thanks !
 
Last edited:

platinumyahoo

Member
May 15, 2009
49
15
I was worried my coming soon SGS3 would not be rootable and romable because of the locked bootloader. thanks for restoring hope!
 

minmongoblin

Senior Member
Jun 15, 2010
274
35
Actually, right now, rebooting the phone will reboot to recovery automatically. If you reboot from there, it "reverts" back to the stock kernel.

So if it were to accidentally reboot itself like sometimes smartphones are prone to do, or if the battery dies and we reboot after charging, we won't be thrown into the stock bootloader because it'll auto-start into CWM?

That's great news, I was skeptical until reading this. Thanks guys!
 

rothnic

Senior Member
Aug 18, 2010
811
278
Just to confirm, the kexec hardboot approach used here is a bit different from the typical kexec. The main difference is that we actually perform a hardware reboot, reinvoking the bootloader just prior to booting the kexec'd kernel.

The advantage to this approach is that it maintains a high-degree of compatibility and minimizes buggy behavior. The disadvantage is that it requires that the bootloader is capable of booting custom recoveries, which the present Verizon SGS3 bootloader is capable of doing.

Thus, it's very important that folks do not apply any over-the-air (OTA) update, until it is confirmed that custom recovery booting remains intact.

If it eventually arises that booting from a stock kernel/recovery is necessary, then it's likely a bunch of kernel bugs will have to be fixed, and it might still have compatibility issues observed in previous kexec attempts. It's linked in the blog post, but there's a bit more of a technical description of the hardboot approach in this old thread.

Thanks to invisiblek and captjtkirk for testing.

Can we take the kernel from your recovery and use it in any other recovery without any other modifications to the recovery? I couldn't get yours to mount the internal storage.
 

rothnic

Senior Member
Aug 18, 2010
811
278
If you're just transplating the zImage component, it should work.

At some point I(or someone) probably needs to apply the patches you implemented for kexec to the Verizon kernel. I understand the config is different, but I wonder if the source is as well. I would be a little suprised if they are identical.
 

rothnic

Senior Member
Aug 18, 2010
811
278
  • Like
Reactions: alquimista

antp121

Senior Member
Jan 15, 2011
6,056
2,061
New Jersey
  • Like
Reactions: ftmaniac948

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830

Top Liked Posts

  • There are no posts matching your filters.
  • 71
    Team Epic announces a proof-of-concept source-built kernel for the Verizon SGS3, complete with kexec hardboot support. This kernel serves two purposes:

    1. To be included in custom recovery images, as it proves the capability of booting-via-kexec custom kernels from recovery.

    2. To serve as a proof-of-concept boot kernel, to demonstrate that custom kernels are capable of running on the Verizon SGS3 in its present form.

    Please see our blog post, Kexec, and a Proof-of-Concept Source-Built Kernel for the Verizon SGS3, for full details and source links.

    CyanogenMod's Team Epic specializes in Sprint's flagship Android phones on Sprint.
    If you appreciate our work, please consider supporting us with a tiny contribution. Thanks!
    16
    Just to confirm, the kexec hardboot approach used here is a bit different from the typical kexec. The main difference is that we actually perform a hardware reboot, reinvoking the bootloader just prior to booting the kexec'd kernel.

    The advantage to this approach is that it maintains a high-degree of compatibility and minimizes buggy behavior. The disadvantage is that it requires that the bootloader is capable of booting custom recoveries, which the present Verizon SGS3 bootloader is capable of doing.

    Thus, it's very important that folks do not apply any over-the-air (OTA) update, until it is confirmed that custom recovery booting remains intact.

    If it eventually arises that booting from a stock kernel/recovery is necessary, then it's likely a bunch of kernel bugs will have to be fixed, and it might still have compatibility issues observed in previous kexec attempts. It's linked in the blog post, but there's a bit more of a technical description of the hardboot approach in this old thread.

    Thanks to invisiblek and captjtkirk for testing.
    10
    So when you say you just reboot to get back to the stock kernel, is it a certain way of rebooting?
    Say you have a ROM installed that's compatible with the stock kernel, but you also want to run a custom kernel. You can kexec the custom kernel from CWM. And, if you want to "switch back" to the stock kernel, just reboot.

    But if you have a source-built ROM (CM, AOKP, etc.) installed to the /system partition then the stock kernel will be incompatible. You'll always have to kexec the source-built kernel.

    That's a point of frustration for sure. If there's no other bootloader workaround found, we've discussed the idea of hijacking part of the boot process to detect if the stock kernel is being used to boot a source-built ROM, and if so, redirect it to boot recovery and automatically kexec a source-built kernel. Of course, the details on that still need to be figured out.

    Anyways, what we're planning to do on the Sprint SGS3 is make the first CM releases actually (kexec) bootable from the SD card, so they won't be written to the /system partition at all. This lets both stock ROM and CM co-exist until the bugs can be worked out, and CM is worthy of being run full time.

    I'd recommend that initial CM ports for the Verizon SGS3 use the same approach, at least in the beginnig.
    9
    wanted to revisit this thread to say thank you to those behind the work that gave us kexec ability, now that the phone is unlocked we can look back on this fondly
    3
    So, as it stands, merely rebooting the phone, for whatever reason and in any way, will revert back to the stock kernel?
    Actually, right now, rebooting the phone will reboot to recovery automatically. If you reboot from there, it "reverts" back to the stock kernel.

    In order to back youll have to go into cwm and load the custom kernel?
    Yes, for now.

    what are the potentiall performance/battery drain related issues involved in using such a method??
    None. Once the kernel is running, its indistingushable from the way it would run if it were flashed to the device (and the bootloader unlocked), aside from the aforementioned unusual reboot behavior.