hmmmmm kind of like your post was right?
And your post also.
On a good note while i was digging around last night through the source code I did notice something really nice about the SGSIII that should make you all very happy. As the guys at epic have noted, the kexec flag is marked, meaning that kexec can crash the existing kernel with one of its own. Now what does that mean you may ask. I'm glad you asked.
For those of you that do not know there are 5 primary partitions that are contained on most phones and android devices:
- X-Loader
This partition is usually the partition with the most basic hardware inits such as base gpio (buttons) and power toggles
- bootloader
This is the partition that contains what most of us as dev's hate the most, the dreaded boot signature, and boot instructions. When a bootloader is locked down it can be because of either a hardware lock, see OMAP4 processors Sec_On Pin, or a software lock, HTC's S-Off. When a bootloader is said to be locked, it can have two reasons for this, a signed header or an encryption algorithm on the entire partition.
- recovery
This partition is the one every one loves to see Clockwork Mod on. When not signed the partition can be flashed and used. ONE THING TO NOTE HERE IS THAT WHEN YOU USE
THIS THREAD, YOU ARE SHOWING THAT THIS IS NOT SIGNED, Or the signature is not checked!!! This is intersting because it its self may show a security hole. The recovery might be what checks the CWM recovery flash images signature.
- boot
Perhaps one of the most interesting partitions on android devices. The boot partitions contains the binary for the kernel, and the inframs for the initilization of the os. This partition in this case has said to be signed, with a signature check in the bootloader that checks the validity of a boot partition, meaning there is no changing this.
- system
Contains most of the information on the OS. At this point all the framework and android settings get loaded. This partition is not signed, meaning we can modify to our will
- userdata
Contains the userdata, such as games and such
Now one thing to note is that there are two initialzation points, the first of which occurs in the boot parition and the second of which is in the system's /etc/init files. One thing that i would be interested in seeing is if you were to use this place to load in a new partition or an SD OS. for example:
system1 partition init:
Code:
kexec -l /sdcard/kernel --reuse-cmdline --ramdisk=/sdcard/ramdisk
system2 partition can then have an init that mounts a block partition from the sdcard onto the system partition.
Code:
mount /dev/block/mmc1... /system
Now what does it all mean? This current method means that we can reload a compleatly new os onto a devices kernel and all. AKA Jelly Bean.
For those dev which hope to find a way to make it work i point you to the following posts:
2nd-init can be used for a second init after the first one to allow for kexec to be run (might not need this)
kexec for ARM I might have to modify some kernel memory allocation issues but it should work none the less with the flag.
