Firefox OS/Performance/Modifying boot.img: Difference between revisions
| Line 20: | Line 20: | ||
===Splitting the boot.img=== | ===Splitting the boot.img=== | ||
This partition contains 2-3 distinct entities. The kernel, the ramdisk, and (optionally, based on how the kernel was configured) the device tree binary. The instructions outlined [https://developer.mozilla.org/en-US/Firefox_OS/Porting#Rebuild_boot.img here] for splitting a boot.img are only mostly sufficient on a flame. The tool specified only detects the kernel and ramdisk. For more information on the structure of this partition go here: https://github.com/xiaolu/mkbootimg_tools/blob/master/dtbtool.txt . | |||
This partition contains 2-3 distinct entities. The kernel, the ramdisk, and (optionally, based on how the kernel was configured) the device tree binary. The instructions outlined [https://developer.mozilla.org/en-US/Firefox_OS/Porting#Rebuild_boot.img here] for splitting a boot.img are only mostly sufficient on a flame. The tool specified only detects the kernel and ramdisk. | |||
The device tree binary is the last section (after which is zero padding), and it begins with the 4 byte magic |QCDT|. To extract this blob I simply used dd on the partition image skipping to whatever offset the magic was found at, and then trimming the trailing zeros similarly. This is not the most elegant of procedures, however I have not as of yet found a better way. (The correct solution I suppose would be extending the unmkbootimg utility appropriately). | The device tree binary is the last section (after which is zero padding), and it begins with the 4 byte magic |QCDT|. To extract this blob I simply used dd on the partition image skipping to whatever offset the magic was found at, and then trimming the trailing zeros similarly. This is not the most elegant of procedures, however I have not as of yet found a better way. (The correct solution I suppose would be extending the unmkbootimg utility appropriately). | ||
Revision as of 11:34, 24 June 2014
Modifying boot.img
This page is meant to illustrate the general steps necessary to make changes to the ramdisk in the boot partition of the device. This may be desired for a number of reasons such as making changes to the init rc scripts or the init program itself, without changing the kernel.
Ideally, the build system would build the kernel and ramdisk, and then create a boot.img which one could then flash. In this case, it's simply a matter of making whatever changes are necessary (and of course init would be automatically included as well). On the flame however, it was not quite so easy.
Obtaining a boot.img
The way this was originally accomplished was to find the boot partition on the file system and run |adb pull|. So for the flame this was
adb pull /dev/block/platform/msm_sdcc.1/by-name/boot .
Where the file specified is a friendly symlink to /dev/block/mmcblk0p7. For certain other devices the partitions lived under |/dev/mtd/| and the mappings could be found by executing |cat /proc/mtd| on the device.
Alternatively
If you already have an image from the OEM or elsewhere ready to flash, you don't need to take the image from the device.
Splitting the boot.img
This partition contains 2-3 distinct entities. The kernel, the ramdisk, and (optionally, based on how the kernel was configured) the device tree binary. The instructions outlined here for splitting a boot.img are only mostly sufficient on a flame. The tool specified only detects the kernel and ramdisk. For more information on the structure of this partition go here: https://github.com/xiaolu/mkbootimg_tools/blob/master/dtbtool.txt .
The device tree binary is the last section (after which is zero padding), and it begins with the 4 byte magic |QCDT|. To extract this blob I simply used dd on the partition image skipping to whatever offset the magic was found at, and then trimming the trailing zeros similarly. This is not the most elegant of procedures, however I have not as of yet found a better way. (The correct solution I suppose would be extending the unmkbootimg utility appropriately).
If you are going through this procedure it is unlikely that you want to change the kernel, and especially unlikely to want to change the device tree blob, so it would be wise to keep those somewhere safe. The porting guide explains how to unpack the ramdisk and repackage it. This is where thing such as init and init.rc (and various other *.rc's) live.
Assuming one has run the unmkbootimg utility, a command to reconstruct the partition using mkbootimg such that it retains the same settings and kernel parameters should have been output. That is exactly the command necessary, except with the addition of |--dt dtblobname| if applicable. This utility can be built in the firefox os source tree by invoking |./build.sh mkbootimg| and the resulting binary is found at.
$SRC_TOP/out/host/$HOST_NAME/bin
W.I.P