[Dev] *obsolete* Xperia S Boot Manager v0.1 (devs only for now)
Hello Guys,
Here is my last toy, it's a dual boot system for the xperia S:
It lets you start two different kernels with their associated cpio with a third kernel that handles the boot menu and embeds cwm. It works with any kernel, this is not kexec based. As a demo in the video, I have stock firmware on regular partitions on one and cm9 on the other one with loopbacks on internal storage. I'll experiment later on with partitioning to see if we could have two sets of native partitions to make it more comfortable.
As it it's, it's quite rough, but if anyone has interest in it I will release it as it is and try to improve usability.
This is for devs and advanced users only, you would have to fiddle a lot to get the second build to run, you need an arm toolchain to embed both kernels and you have to modify its cpio.
I'm working on tools to flash kernels directly on device, but they're not ready yet. And ideally, CWM would need to be extended to support two environments. Don't expect quick progress, I don't have much free time to work on this.
Here are some details on how it works:
I trimmed down a stock kernel to remove some fat and add a driver to set a specific memory location.
I embed a small assembly loader with this kernel and its cpio plus the other 2.
The tiny kernel is loaded first, it displays the menu and eventually starts cwm. The menu will set the memory location with the kernel choice, then reboot.
At next reboot, the assembly loader will detect the kernel choice and start the appropriate kernel.
So, in fact, you're booting two times, first the small loader, then the real boot.
It adds some boot time, but it's not dramatic. The advantage is that it's easy to build the loader, it's a simple init. Second advantage, the second kernel is running on a "fresh" start, no left-over in memory, no kexec patch to apply, it works with any kernel. Last, cwm can be embedded with the tiny kernel, so it's finally independent from the build kernel.
First a disclaimer: I'm not responsible if you fry your phone using this, it's very experimental and I'm not 100% sure running a build on loopback won't reduce internal flash lifetime. I don't expect problem, but proceed with caution!
* Updates *
2012-09-07: Trimmed kernel uploaded to gitorious here , branch bootloader_kernel, boot menu (FBMenu, thanks to openAOS for initial release!) source added here.
1) on-device kernel flasher attached (kf_v0.1.zip). It let you flash kernel 1 or kernel 2 directly from device (adb from recovery for instance). You must have previously flashed dual.elf in fastboot!
And again, all of this is highly experimental! Be careful.
If you have a 6.1.A.2.45 stock firmware, you can try the setup displayed in the video:
Download package here (mirror) and extract it on your PC.
Copy the 3 ext4 files at the root of the phone internal storage.
Reboot in fastboot mode
Flash dual.elf in fastboot mode with "fastboot flash boot dual.elf".
Reboot with "fastboot reboot"
You should now have the boot menu at each phone start. If you want to get rid of it, just reflash your original firmware kernel.
Note:
- I'm not sure cwm is working completely properly, I barely tested it.
- it may work with another stock firmware version, but the embedded stock kernel is 6.1.A.2.45 one, I'm not sure how it behaves on other builds.
wow, this is very very nice, now we can have the best of stock and cm9, thanks for all your hard work, im sure this is going to go far in the xperia s development community
1. we should NOT flash kernel every time we need to boot into other OS (too much flashing = bad blocks)
2. thus I suggest we need to maintain the same kernel tree for both stock and cm/aosp/aokp kernel. the zImage will be same, but ramdisk will be different ....
3. how will that help ? we will keep a minimalistic ramdisk (containing only bootmanager) on the original kernel.elf. the stock and aosp ramdisk can reside as stock_ramdisk.gz and aosp_ramdisk.gz either inside the ramdisk (if it has space) or inside /system/dual_boot/ and the required ramdisk will be inflated/deflated on the fly as per usage requires something like
for referrence see how CWM runs using chargemon script on locked bootloader
4. we will need our own custom CWM/whatever-recovery-we-want-to-use that shall allow us to flash system1 and system2, data1 and data2, like that....
5. for optimum results i want to suggest to use current system partition as system1 and current data partition as system2, both data partition can be kept as loop devices on the internal sdcard. that will be best for space as well as speed. using any other combination we will have to sacrifice either on speed or on space.
now these are my opinions, and I'll sit down an speak with OP after my exams are over on 17th Sept. I am very much interested on this idea, because it's a win-win situation. People get to use custom firmware alongside stock and devs get more users for their ROMs because there is no risk of non-working hardware as we always have stock on the other partition
I wasn't clear enough in my message I guess, so to clarify: I'm not flashing kernel each time I boot, the three kernels are flashed once and everything happens in memory. I'm using the whole 20 MB space to fit the three kernels, and my assembly loader jumps in memory to the desired kernel.
Your idea of having a single kernel for all is nice, but afaik, cm differs in kernel from stock, this is not a problem of ramdisk only.
Regarding partition scheme, well, I have no opinion yet, I'd prefer avoid loopbacks if I can repartition, but I'm not sure bootloader will let me do it. If repartition is possible, cwmod handling should be easy and only a matter of launching it while swapping on two recovery.fstab.
Noob question , so it's a kernel that hot boot another ?
Not really, the first kernel+cpio is here mostly to handle the boot menu. After selection is made, the phone reboots and a small assembly loader starts the final kernel.
I wasn't clear enough in my message I guess, so to clarify: I'm not flashing kernel each time I boot, the three kernels are flashed once and everything happens in memory. I'm using the whole 20 MB space to fit the three kernels, and my assembly loader jumps in memory to the desired kernel.
Your idea of having a single kernel for all is nice, but afaik, cm differs in kernel from stock, this is not a problem of ramdisk only.
Regarding partition scheme, well, I have no opinion yet, I'd prefer avoid loopbacks if I can repartition, but I'm not sure bootloader will let me do it. If repartition is possible, cwmod handling should be easy and only a matter of launching it while swapping on two recovery.fstab.
Got it
Makes more sense
Great job
About repartition... We do have a lot of space in system to partiton into system1 and system2 say....
But splitting data is not good idea
Some people keep.big.games on data which need lot of space
Lets see what happens
Will check your current scheme tomorrow
Really like your memory base shifting concept... Pretty neat
Instead of 3 we can still make do with 2 kernels and 3 ramdisk.
We can keep the first kernel for both stock rom as well as the for.bootmanager :P
XDA Developer TV Producer Kevin set up his phone to respond to … more
XDA Developers was founded by developers, for developers. It is now a valuable resource for people who want to make the most of their mobile devices, from customizing the look and feel to adding new functionality. Are you a developer?