Skip to content

How to Package a ROM for FFFE's Alternate Boot

eldarerathis edited this page Apr 12, 2012 · 5 revisions


Since FIREFIREFIRE Extended sets up a second set of ROM partitions, ROMs can only be installed and booted as an "alternate" if they are packaged in a specific way. This re-packaging is fairly straightforward, and requires simply that the init.omap4430.rc (which is packed into the boot image) and updater-script files be modified to point to the proper partitions.


The init.omap4430.rc file contains various commands that the Kindle Fire will execute during the boot process. It is packed in the boot image's ramdisk, and can also be found at /<pathToAndroidSource>/device/amazon/otter/root/init.omap4430.rc for AOSP builds (for CM7 builds it will typically be "blaze" instead of "otter"). One of the important functions of this file is mounting the partitions that the system needs to boot and run. In order to boot from a set of alternate partitions, you'll need to look for the following section of the file:

on fs
    mount ext4 /dev/block/platform/mmci-omap-hs.1/by-name/system /system wait ro
    mount ext4 /dev/block/platform/mmci-omap-hs.1/by-name/userdata /data wait noatime nosuid nodev errors=continue
    mount ext4 /dev/block/platform/mmci-omap-hs.1/by-name/cache /cache wait noatime nosuid nodev errors=continue
    mount ext4 /dev/block/platform/mmci-omap-hs.1/by-name/splash /dropbox wait noatime nosuid nodev errors=continue

...and change the mount points like so:

on fs
    mount ext4 /dev/block/mmcblk0p14 /system wait ro
    mount ext4 /dev/block/mmcblk0p16 /data wait noatime nosuid nodev errors=continue
    mount ext4 /dev/block/mmcblk0p15 /cache wait noatime nosuid nodev errors=continue
    mount ext4 /dev/block/platform/mmci-omap-hs.1/by-name/splash /dropbox wait noatime nosuid nodev errors=continue

This will make the init file mount the proper secondary partitions for system, data, and cache instead of the normal ones.

If you are building a ROM from source, you can change this section by modifying the init.omap4430.rc file before you build, which may be easier in many cases. However, if you are using a ROM that is prebuild (such as an OTA update or similar) then you will need to extract the boot image, modify the init file, and then repack it with the new changes. I currently recommend using dsixda's ROM kitchen for this, as it will greatly simplify the process. If you find yourself needing to do this manually, I recommend reading through the instructions on the Android-DLS wiki page (note that the scripts they provide are broken links, you'll need to try to find them elsewhere).


The udpater-script file is essentially a small script program that is run by the Android recovery system when installing a zip file (i.e. a ROM). It has functions for modifying the file system, extracting directorys, and many other things. There are two functions of particular importance when re-packaging a ROM for the alternate partition set:

  1. The format() function
  2. The mount() function

Other functions like extract_package() and unmount() do not take a partition as a parameter, and therefore do not need to be modified (they use a mount point as a parameter). Since the use of these functions can vary between ROM packages, it isn't really possible to provide a strict set of lines that must be changed. However, the following rules should suffice for just about any purpose:

  1. Anywhere that format() is used on the system, data, or cache partitions you must change the partition parameter to point to the alternate one. This means that, for instance, format("EXT4", "/dev/block/platform/mmci-omap-hs.1/by-name/cache"); would become format("EXT4", "/dev/block/mmcblk0p15"); Remember that system=14, cache=15, and data=16.
  2. Anywhere that mount() is used to access the system, data, or cache partitions must be changed to point to the alternate ones. Again, this would mean that something like mount("EXT4", "/dev/block/platform/mmci-omap-hs.1/by-name/cache", "/cache"); would become mount("EXT4", "/dev/block/mmcblk0p15", "/cache");

In addition, there will be a function in the script that attempts to write the boot image to the device. This can vary depending on the ROM (and author), but it is typically either done using write_raw_image() or package_extract_file(). In either case, the function must be changed to point to /dev/block/mmcblk0p13, which is the boot2 partition.

The updater-script file lives in the META-INF folder of a ROM package, and can easily be extracted from the zip, modified, and then added back to the archive. You shouldn't need any special tools other than an archiver that understands zip files (basically all of them) and a text editor.

Something went wrong with that request. Please try again.