Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

[Dev] *obsolete* Xperia S Boot Manager v0.1 (devs only for now)

OP letama

4th September 2012, 10:52 AM   |  #1  
OP Recognized Contributor
Thanks Meter: 2,315
 
1,679 posts
Join Date:Joined: Feb 2008
Donate to Me
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:
  1. I trimmed down a stock kernel to remove some fat and add a driver to set a specific memory location.
  2. I embed a small assembly loader with this kernel and its cpio plus the other 2.
  3. 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.
  4. 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.

2012-09-06, more details 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.


syntax:

kf [1|2] kernel_zimage_file cpio_file

Source code at: https://gitorious.org/sony-tools/dual_loader_kf

2) Loader source code uploaded to: https://gitorious.org/sony-tools/sony-tools, in dual directory.

2012-09-04:

If you have a 6.1.A.2.45 stock firmware, you can try the setup displayed in the video:
  1. Download package here (mirror) and extract it on your PC.
  2. Copy the 3 ext4 files at the root of the phone internal storage.
  3. Reboot in fastboot mode
  4. Flash dual.elf in fastboot mode with "fastboot flash boot dual.elf".
  5. 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.

Don't hesitate to give feedback here!

LeTama
Attached Files
File Type: zip kf_v0.1.zip - [Click for QR Code] (37.8 KB, 193 views)
Last edited by letama; 10th September 2012 at 09:56 PM.
The Following 30 Users Say Thank You to letama For This Useful Post: [ View ]
4th September 2012, 11:02 AM   |  #2  
Senior Member
Thanks Meter: 64
 
197 posts
Join Date:Joined: Dec 2011
More
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
4th September 2012, 11:40 AM   |  #3  
Senior Member
Flag Aachen
Thanks Meter: 309
 
294 posts
Join Date:Joined: Aug 2011
Donate to Me
More
Thats Realschule great when You allow i will try to implement twrp 2 at an later Version just as an Experiment

Sent from my LT26i using xda premium
4th September 2012, 02:41 PM   |  #4  
YousifNael's Avatar
Senior Member
Thanks Meter: 73
 
313 posts
Join Date:Joined: Jul 2012
More
This is awesome
Great job
Take as much as u want , this is so promicing
4th September 2012, 03:33 PM   |  #5  
ok so my two cents : -

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
Code:
 rm -f -r /sys
rm -f -r tmp 
rm -f -r etc
tar -xf ./stock_ramdisk.gz
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
4th September 2012, 04:33 PM   |  #6  
OP Recognized Contributor
Thanks Meter: 2,315
 
1,679 posts
Join Date:Joined: Feb 2008
Donate to Me
Thanks for your reply championswimmer.

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.
4th September 2012, 06:31 PM   |  #7  
Senior Member
Flag Rome
Thanks Meter: 434
 
426 posts
Join Date:Joined: Apr 2012
Donate to Me
More
Noob question , so it's a kernel that hot boot another ?
4th September 2012, 08:33 PM   |  #8  
OP Recognized Contributor
Thanks Meter: 2,315
 
1,679 posts
Join Date:Joined: Feb 2008
Donate to Me
Quote:
Originally Posted by Forzaferrarileo

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.
4th September 2012, 08:53 PM   |  #9  
OP Recognized Contributor
Thanks Meter: 2,315
 
1,679 posts
Join Date:Joined: Feb 2008
Donate to Me
I added my current setup if anyone want to test it, see bottom of first post.
4th September 2012, 09:18 PM   |  #10  
Quote:
Originally Posted by letama

Thanks for your reply championswimmer.

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

Sent from my LT26i using xda app-developers app

Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes