Android システムでは、カーネル、RAM ディスク、および一部のメタデータは、ブートローダーによって処理されるバイナリ ディスク イメージに格納されます。イメージはmkbootimg
ユーティリティで構築されます。
ソースを調べるmkbootimg
と、画像形式に次のように定義されたヘッダーがあることがわかります
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 */
};
それ以上の資格なしで。この構造体のインスタンスは、イメージ ファイルの先頭にwrite
.
これは、ホスト システム (x86 だと思います) に典型的なエンディアンとアライメントをブート イメージに埋め込んでいませんか? ブートローダー自体がヘッダーを構造体として扱わない場合でも、mkbootimg
(Android ARM に対して) エンディアン/アライメントが異なるシステムで実行すると問題が発生するようです。
構造体レイアウトの一般的な違いを過大評価していませんか?