Firefox OS/Performance/Modifying boot.img: Difference between revisions

Line 19: Line 19:
The boot 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#Extracting_and_modifying_an_existing_boot_image here] for splitting a boot.img are only mostly sufficient on a flame since the tool specified only detects the kernel and ramdisk. For more information on the structure of this partition see: https://github.com/xiaolu/mkbootimg_tools/blob/master/dtbtool.txt .
The boot 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#Extracting_and_modifying_an_existing_boot_image here] for splitting a boot.img are only mostly sufficient on a flame since the tool specified only detects the kernel and ramdisk. For more information on the structure of this partition see: https://github.com/xiaolu/mkbootimg_tools/blob/master/dtbtool.txt .


The device tree binary is the last section (after which is zero padding if the image was pulled from the device). A device tree is basically a data structure for describing the hardware of the device to the kernel, and It is generally compiled to a binary format more suitable machines to read than humans. It signals its beginning in the boot partition with the 4 byte magic <code>|QCDT|</code>. 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. A command such as this can be used to find the offset:  
The device tree binary is the last section (after which is zero padding if the image was pulled from the device). A device tree is basically a data structure for describing the hardware of the device to the kernel, and It is generally compiled to a binary format more suitable for machines to read than humans. It signals its beginning in the boot partition with the 4 byte magic <code>|QCDT|</code>. 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. A command such as this can be used to find the offset:  
<pre>
<pre>
strings -o boot.img | grep QCDT | awk '{print $1}'
strings -o boot.img | grep QCDT | awk '{print $1}'
Line 28: Line 28:
dd if=boot.img of=dtblob skip='$DT_OFFSET' bs=1
dd if=boot.img of=dtblob skip='$DT_OFFSET' bs=1
</pre>
</pre>
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).
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 <code>unmkbootimg</code> 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 files such as '''init''' and '''init.rc''' (and various other *.rc's) live.
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 files emitted from <code>unmkbootimg</code> somewhere safe. The porting guide explains how to unpack the ramdisk itself and repackage it. This is where files 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 <code>|--dt dtblobname|</code> if applicable. This utility can be built in the firefox os source tree by invoking <code>|./build.sh mkbootimg|</code> and the resulting binary is found at. <pre>$SRC_TOP/out/host/$HOST_NAME/bin</pre>
Assuming one has run the <code>unmkbootimg</code> utility, a command to reconstruct the partition using <code>mkbootimg</code> such that it retains the same settings and kernel parameters should have been displayed. That is exactly the command necessary, except with the addition of <code>|--dt dtblobname|</code> to the end of the command if applicable. The utility <code>mkbootimg</code> can be built in the FirefoxOS source tree by invoking <code>|./build.sh mkbootimg|</code> and the resulting binary is found at. <pre>$SRC_TOP/out/host/$HOST_NAME/bin</pre>. This tool should be used especially if the device tree is needed.




W.I.P
W.I.P
Confirmed users
125

edits