This issue is still under construction.
This is draft from my memory, I need to do fact cheking.
I will try to reconstruct MultiROM, so, we can implement it easier.
MultiROM is dualboot script that runs after kernel and before init scripts.
It lets users pick different ROM (that are installed by TWRP fork).
It is using modified kexec-tools for running kernel of different ROM and also kexec-hardboot patch.
Before running another kernel, it mounts paths to proper locations, for that different ROM,
from internal storage or USB flash (which seams like a better solution for us, right now, since we are using custom file storage)
Here, you can find list of modified kernels, to work with it.
Just for the record, EFIDroid is a similar project.
Some quick notes about EFIDroid:
There are lots of technical information here: https://forum.xda-developers.com/showthread.php?t=1266827 I've summarized it so that it is easier to follow for someone who wants to implement support for pmOS.
As I understand it, in order to support MultiROM we need to achieve the following points:
Once patched, enable the following options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
CONFIG_GROUPER_HARDBOOT_RECOVERY=n
Steps to boot to another kernel:
kexec --load-hardboot. It loads the zImage from disk, constructs parameters (e.g. cmdline) and stages it in memory.Example:
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
kexec -e. It writes special info to memory (to area which is not overwritten on reboot) and reboots the deviceNow the phone will reboot, the device will show the logo, and eventually Linux will boot the kexec'd staged kernel.
The hardboot patch is required because many built-in drivers do not support proper unloading, reloading, and reinitializing the associated hardware without a hardware-reboot. So the hardware is often left in an unexpected or unknown state on unload, and thus the kexec'd kernel hangs on boot. Hardboot fixes this issue by writing some info to memory, forcing a reboot and then reading that information from memory.
Once it is working, these two patches improve the usability:
decomp_cachebufram patch. It decreases the loading of a stock or non-keced-modified kernel from 35 seconds to 8.patch_decomp_cachebufram.sh script will binary patch the decompressor code for any Epic kernel (what is it for?)The author talks about the Epic kernel which is unknown to me.
@PabloCastellano The latest versions of MultiROM no longer needs the compatibility patches for the kernel being kexec'd; you only need the full-patched kernel. (see the commit message)
Dual boot patcher seems a good alternate option for this purpose as this does not require any major kernel modification as far as I know. The main benefits of using this are following -
Source and XDA thread
@PabloCastellano Just want to correct you quickly
It uses the Android build system (source)
EFIDroid does NOT use the Android build system, it uses similar syntax and targets and uses the repo tool from Google but the rest are his own Python scripts etc.
But Multirom does use the Android tree for building 馃槈
For the record: Safestrap (Droid 4 et al.) is a similar boot manager project..
@NotKit got safestrap working for the Droid 4 as initfs hook.
Safestrap is more about working around a bootloader you can't control than anything.
Then EFIDroid certainly looks the neater thingy imo, but it won't be available on all devices.
And similarly phones may have all the weirdest combinations of /boot restrictions, from those with a partition too little to accommodate two kernels, to those unable to load kernels outside of it (at least in normal conditions without kexec).
So imo, to avoid this kind of discussion x1000 there should be a list of "practices preferences", from those requiring the less burden/effort/changes/hassle/time-to-boot, to maybe having a third kernel to manage boot selection, to overcomplicated (yet, necessary) ones like hooking into safestrap or kexecboot.
Yeah the extra kernel approach with kexecboot for an universal bootloader that works from any other bootloader is also an interesting approach. That way we could provide a boot menu and offer choice between multiple kernels for all devices.
Most helpful comment
Just for the record, EFIDroid is a similar project.
Some quick notes about EFIDroid: