[Tool] Xperia S Boot Manager v0.8, a real dual boot system
Here is a new version of my boot manager.
If you didn't see first release, its purpose is to allow dual boot a firmware with two different kernels with a third one that manages boot selection:
Here is a demo of the previous version, it behaves almost the same:
Since first release, I added cwmod and twrp support for both build:
First build is run from native partition, and second build is installled on internal storage via loopbacks. Since first release, I added automatic loobpack creation:
CWM will take care of formatting them.
FIRST A BIG WARNING: all you'll see here is highly experimental, I'm not responsible for any damage or problem it could cause. I don't have any idea if running a build on loops is wearing off flash memory, it could damage your device.
I don't think it dramatically change anything compared to standard wear on native partitions, but who knows... And something else could go wrong.
Currently, if you don't want to loose your current data, you have to be on a rom that has already be repackaged. By default, bootmanager installs Sony 6.1.A.2.55 kernel, so if you're using this firmware, no need to reflash it. For all the other roms, you will have to reflash the repackaged zip in the list below after installation. Don't wipe data/factory reset and you should be good to go. In both case, backup your stuff with Titanium Backup or something else!
Note: you won't be able to restore your previous cwm backups!
Most of the time, no. Some may work unmodified, like google apps that mounts system without using explicit partition. But most of the zips found here mounts directly native partitions so they won't work for build installed on loops. Last, all the kernel zips have to be modified. Flashing any unrepackaged kernel zip will replace boot manager completely and will kill it.
- Can I restore my previous CWM backups after installing bootmanager ?
Yes and no. Yes if you want to go back to where you were before installing bootmanager. No if you want to keep boot manager: restoring the backup will erase it.
- Moved apps (to storage/sdcard) will disappear when booting from one build to another. I presume it happens because both builds are sharing storage and it messes up ext2sd scheme. As a workaround, move apps back to internal. This is not a boot manager issue per se, but it's more related to the way builds are repackaged, it probably requires different location for ext2sd. I'll take a look someday.
- Recoveries backups will backup/restore all kernels at once instead of of doing each one separately.
2013/02/21: version 0.8
- Offline charging embedded in TWRP, bootmanager is no longer using native build to provide it.
- 1 GB system loop size added
Note: Offline charging can't be added to CWM so CWM is not recommended anymore, TWRP is safer for power management.
2013/01/28: version 0.7
- New settings menu, single boot/dual boot, boot manager protection enable/disable, alternate enable/disable
- Default is now single boot: in this mode, boot manager is only using one kernel and is only providing separate recovery for it.
- TWRP upgraded to v 126.96.36.199
- Only released with aosp build
2012/11/20: version 0.6
- Default recovery is now twrp
- Default kernel is now from 6.1.A.2.55 firmware
- TWRP updated to fix keyboard in backups
- Boot menu now remember which kernel was launched and defaults to it at next boot.
- Bootmanager protection: flashing a kernel that hasn't been repacked should fail. Temporary protection removal here if you want to get rid of bootmanager with a normal firmware.
- Native partition protection: flashing from loop recoveries should not be able to mount native partitions
- Kernel flasher bug fix: layout should now be calculated properly and big kernels shouldn't trash bootmanager anymore
- Notification led color changes depending on which recovery is launched
- ram_console is now properly handled by boot manager kernel. From now on, you should go to a recovery to get the last_kmsg for a crashing kernel.
- Boot manager can be flashed from recoveries.
2012/10/20: version 0.5
- flashable recoveries (cwm and twrp)!
- new kernel layout to give more space to loop kernel
- boot menu delay countdown fix
- offline charging forwarded to native build
- pre-installed kernel is now 6.1.A.2.50 one.
- added recoveries for alternate (re-partitioned devices only)
2012/10/06: version 0.4
- initramfs location moved to 0x41500000 for aokp and cm10 compatibility
- debug traces left in cwm removed
- new kernel extraction command (ke)
2012/10/02: version 0.3
- cwm recovery bugfix to get proper Aroma colors.
- stock / custom name changed to native / loopback in menus.
- added menu for cache loopback to adjust cache size.
2012/09/10: version 0.2
- CWMod recoveries are now working for stock (native) and custom (loopbacks).
- Loopbacks files are created if they are missing with multiple sizes.
Elf kernel splitter sksplit here. I use it mostly to extract kernel and cpio in repackaging firmware.
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.
# mount mmc partitions
# mount /system, set up links to the modem, and remount r/o
mount ext4 /dev/block/mmcblk0p12 /system wait rw barrier=1
mkdir /system/etc/firmware/misc 0771 system system
mount ext4 /dev/block/mmcblk0p12 /system wait ro barrier=1
setprop ro.crypto.tmpfs_options size=128m,mode=0771,uid=1000,gid=1000
mount ext4 /dev/block/mmcblk0p14 /data wait noatime nosuid nodev data=ordered noauto_da_alloc
mount ext4 /dev/block/mmcblk0p13 /cache wait noatime nosuid nodev data=ordered noauto_da_alloc
# losetup on storage
mount vfat /dev/block/mmcblk0p15 /sd wait rw
# ro directly as misc is created by install script
mount ext4 loop@/sd/custom_system.ext4 /system wait ro barrier=1
setprop ro.crypto.tmpfs_options size=128m,mode=0771,uid=1000,gid=1000
mount ext4 loop@/sd/custom_data.ext4 /data wait noatime nosuid nodev data=ordered noauto_da_alloc
mount ext4 loop@/sd/custom_cache.ext4 /cache wait noatime nosuid nodev data=ordered noauto_da_alloc
Repack Sample, 6.1.A.2.45 firmware on stock/native:
7z x ../downloads/LT26i_6.1.A.2.45_GENERIC_NL.7z
7z x "LT26i_6.1.A.2.45_GENERIC NL.ftf"
rm "LT26i_6.1.A.2.45_GENERIC NL.ftf"
sin2raw kernel.sin kernel.elf
mv sec0-0x40208000.bin zip_out/zImage
mv sec1-0x41300000.bin zip_out/initramfs.cpio.gz
sin2raw system.sin system.ext4
mount -o loop -t ext4 system.ext4 system
... optionally add root, busybox:
cp -r /home/tama/supersu/system/* .
chmod 6755 su
cp /home/tama/cm9/out/target/product/gen9/system/xbin/busybox .
cp /home/tama/relink-busybox.sh .
chmod 755 relink-busybox.sh
tar -cvzf zip_out/system.tgz system
... get script from cm9, ..
cp -a ../../fxp137_cm9_ziploop/META-INF .
This one is special and deserve specific instructions.
First, it's not functional, and will never be.
I just wanted to have a look at current status of AOSP experiment for Xperia S, it required much more fiddling than reasonable and ended into a monster.
Again, I take no responsability if you flash this. It doesn't work properly, it's not tested, it can be bad for your phone .
Second, if you want to install this, read carefully instructions, it's not packaged like a normal loop rom.
[B]Last: special thanks to FXP team, it wouldn't have been this far with the work they did on CM10. I took few binaries from FXP release and few patches from Cyanogen repo, no way to make it run without the work they did.
Now, that the warning are there, here is the status:
What's not working:
3) And much more
1) You need around 2G free space on storage
2) It will replace your loop kernel but keeps the loopback files untouched
3) If you want to save your current kernel, you can do this from loopback recovery with adb:
I started this to check status of Google/Sony AOSP experiment. I wanted to see how far they went and how it behaves.
2) Why not making it functional ?
As it is, it's not worth it. To have the running state I have, I had to patch google aosp source, patch kernel, fiddle with FXP binaries, etc... This build is a Frankenstein monster and it would take quite a big amount of work to end up with something that takes many things from CM and doesn't work as good as CM.
We'll see if Sony goes further in releasing proprietaries and source code, but without that, AOSP will end up in CM without CM bonus
Those of us who use Linux on a day to day basis don’t think twice about sinking … 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?