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

Search This thread

CMTeamEpic

Retired Recognized Developer
Jun 21, 2012
32
1,004
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!
 

ruvort

Senior Member
Aug 4, 2010
1,543
405
Awesome! Thank you so much for your guys efforts

Sent from my HTC Rezound via Tapatalk
j8t1uvaAWRgTE.png

MyColorScreen
 
  • Like
Reactions: TheMorlince

mkasick

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

Schaweet

Senior Member
Aug 2, 2010
700
173
Wow! Thanks for taking the time to do this even though you guys aren't vzw owners. Great example of how great this community is.

Sent from my DROIDX using xda app-developers app
 

densetsu86

Senior Member
Aug 19, 2011
165
18
Just a question does the kexec allow the sgsiii to use both cores. I have heard that kexec on both the droid razr and droid 3 doesn't allow for dual core yet. Any such issues with sgsiii or is it too soon to tell?


Sent from my DROID X2 using xda app-developers app
 

ErylFlynn

Senior Member
Dec 6, 2007
97
6
Say we needed to return to stock, can we just use Odin, flash back the ROM or would their be a bit more to it?

And THANKS! You are just missing the raised finger picture to Verizon over this.
 

skennelly

Senior Member
Dec 18, 2010
222
39
Quad Cities
Just a question does the kexec allow the sgsiii to use both cores. I have heard that kexec on both the droid razr and droid 3 doesn't allow for dual core yet. Any such issues with sgsiii or is it too soon to tell?


Sent from my DROID X2 using xda app-developers app

I know this was an issue back in April(?) I haven't read anywhere that this has changed and I am curious to know this as well.
 

TheClap

Senior Member
Jun 17, 2012
102
10
I know this was an issue back in April(?) I haven't read anywhere that this has changed and I am curious to know this as well.

According to Noobnl in the IRC channel, the dual core thing isnt an issue since its a hard reboot so it reloads the bootloader; "this is a more advanced form kexec."
 

tpike

Senior Member
Glad to see some love from familiar faces. This is one if those times when i nuts being on sprint. From the galaxy tab, to the og epic, to the touch, sprint has allowed great things to happen on their devices. Now in big red, it's great to see we can use/reuse stuff across networks.

Big thanks!

Sent from my DROID RAZR using Xparent ICS Tapatalk 2
 

mkasick

Retired Recognized Developer
Aug 10, 2009
470
830
Just a question does the kexec allow the sgsiii to use both cores.
In short, yes.

Longer answer:

Traditionally kexec works by having one instance of the kernel boot a second instance directly, that is, by avoiding the bootloader. For this to work, every kernel driver has to shutdown in such a way that the same driver (in the kexec'd kernel) can revive and restart the hardware it controls.

The problem is that some, maybe many, drivers aren't actually capable of doing that. For the most part, it's a feature only needed by kexec, so unless the device manufactuer is specifically targetting kexec support, usually one or more drivers will put some part of the hardware in a confused state. That's the main source of compatibility bugs with kexec.

Now, what we do in the kexec hardboot approach is use the Linux kexec infrastructure to load and stage a new kernel in memory. Then we perform a hardware-level reboot, reinvoke the bootloader, and then at the very beginning of the recovery kernel code, we check to see if there's a kexec'd kernel out there in memory and if so, jump to that instead.

The advantage with this technique is that once the kexec'd kernel is booted, the environment is the exact same as if it was a kernel flashed to the device--there shouldn't be any hardware compatibility issues.

As it turns out, the one compatibility thing we have seen, which is unusual reboot behavior, isn't actually an artifact of kexec. The same thing would happen if you flashed a "boot kernel" to the recovery partition and booted it directly.

---------- Post added at 09:30 AM ---------- Previous post was at 09:28 AM ----------

Say we needed to return to stock, can we just use Odin, flash back the ROM or would their be a bit more to it?
This is a temporary mechanism. To return back to the stock kernel, simply reboot the device.

To remove the custom recovery and fully flash back to stock, yes, you would use Odin.
 

nosympathy

Senior Member
Dec 19, 2010
2,769
1,257
Cincinnati
So when you say you just reboot to get back to the stock kernel, is it a certain way of rebooting?

As in, if you were running soap and a kexec aosp kernel and rebooted and it forced you to the stock Samsung kernel, the phone wouldn't boot right?

Sent from my ADR6425LVW using xda app-developers app
 

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.