Merging init_boot.img into boot.img on Android 13+ native devices for use with "fastboot boot"

[surlyhacker]

Hi,
I see that the README contains a use case for "How to merge init_boot.img into boot.img".
I tried this, and it seemed to work, however when I send the resulting boot.img.signed to "fastboot boot" for an Android 13+ native device (a device that originally shipped with Android 13+, such as Pixel 8 and Pixel 7), the device seems to ignore the ramdisk inside of the image and use the ramdisk already stored onboard in the init_boot partition.

In other words, although I can merge init_boot.img into boot.img, this seems to do nothing because although the resulting image contains the ramdisk, the device will not use it. Could this be specific to the Pixel 8 (Android 14)? Or could it be that the implementation of "fastboot boot" is somehow designed to ignore the ramdisk sent within the boot image on this particular device?

Are there files within the build/unzip_boot/ folder that I can modify to try to get this to work?

Thanks

[cfig]

This may be specific to bootloader implementation.
For now there are several places to store ramdisk files:

1. boot.img
2. init_boot.img
3. vendor_boot.img

More to try:
You may try to edit init_boot.img, remove files inside it, and flash it back to device.
If bootloader doen't load ramdisk in boot.img, you may also try to merge init_boot into vendor_boot.img, to see if it can be loaded successfully.

Thanks ~

[surlyhacker]

Thanks for the suggestions. Just to clarify things, I am using "fastboot boot" and not "fastboot flash", because I do not want to modify any of the existing partitions. Also the images I am using are using boot header v4 format.

I tried further combining vendor_boot.img, vendor_kernel_boot.img, and init_boot.img into boot.img, but that poses a problem with the tool, because I think when it packs a v4 "boot.img", it does not allow some things in boot.json that are typically only in a vendor_boot.img, such as a dtb, bootconfig, ramdisk_table. (since the non-vendor boot header specification does not allow them either) The reason I wanted to try this is based on your suggestion and the idea that somehow not having a "complete" boot image makes my modified ramdisk be ignored.

And beyond that issue, the "ramdisk" json section for v4 boot.img doesn't allow "loadAddr", which is present in vendor_boot.img
Also, the "info" json section for v4 boot.img doesn't allow "tagsLoadAddr" or "kernelLoadAddr", which are also present in vendor_boot.img.

I guess I could maybe try a v2 boot.img, which supported dtb, tagsLoadAddr, kernelLoadAddr, and a loadAddr for ramdisk, but I don't know if this device will work with a v2 image because it launched with Android 13, and such devices supposedly only work with v3/v4. I also don't know if this tools supports v2 boot.img and all of those sections/properties. I will try it out.

Here is what my images contain:
boot.img: kernel
init_boot.img: ramdisk (generic) <-- this is what I am trying to modify and then boot without flashing
vendor_kernel_boot.img: ramdisk (has only kernel modules) using ramdisk_table, dtb
vendor_boot.img: ramdisk (the vendor ramdisk) using ramdisk_table, bootconfig

[surlyhacker]

I also tried combining vendor_kernel_boot.img, boot.img, and init_boot.img into vendor_boot.img
But I guess vendor_boot.img doesn't support a "kernel" section in the json, of course.

If I simply combine my modified ramdisk with the vendor_kernel_boot and vendor_boot ramdisks and pack them into a boot.img, this does boot successfully but just as before it totally ignores the contents of that ramdisk, it seems.

As you say, clearly something in the bootloader is not operating as expected, but I do not know what or how. And it is closed source, as far as I know. I've looked at it a bit with Ghidra for reverse engineering, specifically the "abl" section, which has an interesting string in it of "failed to read ramdisk from stored boot.img" that seems to imply that perhaps a "fastboot boot" image can indeed supply a ramdisk and it will be used in some scenarios.

I am going to try to build a debugging UART/serial/TTL USB cable to hopefully view the bootloader log or kernel logs to see more about what is happening:
https://github.com/Peter-Easton/android-debug-cable-howto

[cfig]

serial console log is a MUST when debugging boot images, otherwise the working scope has to be carefully confined in what the BL already supports.
Good luck ~