CODEWITHSUNDEEP
androidcbootloader
yew
yew

Reputation: 55

Android boot image format

On Android systems the kernel, the ramdisk, and some metadata are stored in a binary disk image that's handled by the bootloader. Images are built with the mkbootimg utility.

Examining the mkbootimg source, I see that the image format has a header defined as

struct boot_img_hdr {
        unsigned char magic[BOOT_MAGIC_SIZE];

        unsigned kernel_size;  /* size in bytes */
        unsigned kernel_addr;  /* physical load addr */

        unsigned ramdisk_size; /* size in bytes */
        unsigned ramdisk_addr; /* physical load addr */

        unsigned second_size;  /* size in bytes */
        unsigned second_addr;  /* physical load addr */

        unsigned tags_addr;    /* physical addr for kernel tags */
        unsigned page_size;    /* flash page size we assume */
        unsigned unused[2];    /* future expansion: should be 0 */

        unsigned char name[BOOT_NAME_SIZE]; /* asciiz product name */

        unsigned char cmdline[BOOT_ARGS_SIZE];

        unsigned id[8]; /* timestamp / checksum / sha1 / etc */
};

without any further qualifications. An instance of this struct is written at the start of the image file with write.

Doesn't this embed the endianness and alignment typical of the host system (x86, I believe) in the boot image? Even if the bootloader itself never treats the header as a struct, it seems that running mkbootimg on a system with different endianness/alignment (vis Android ARM) would now be problematic.

Am I overestimating how common differences in struct layout are?

Upvotes: 3

Views: 7721

Answers (1)

TheCodeArtist
TheCodeArtist

Reputation: 22517

No. You are right.

mkbootimg cross-compiled for ARM will run into issues as described in this question.

Upvotes: 2

Related Questions