Android build boot. img

Source: Internet
Author: User

 

Taking tcc88xx as an example, when the top-level Source Code directory of Android is compiled using make, such a directory is generated:

Out/target/product/tcc8800. This directory contains the required boot. IMG and system. IMG, Boot. mg

It is packaged using the kernel and out/target/product/tcc8800/root directories (ramdisk in a broad sense), that is,

Boot. IMG is generated by kernel and ramdisk. IMG. This article mainly analyzes the generation of the root directory and ramdisk. IMG,

In the android compilation framework, many fixed and frequently used directory paths are defined as macro variables.

The Macro of out/target/product/tcc8800 is product_out.

The out/target/product/tcc8800/system macro is target_out.

The Macro of out/target/product/tcc8800/root is: target_root_out,

Out/target/product/tcc8800/root is copied from the system/CORE/rootdir directory,

Therefore, I have analyzed the Android. mk file in the system/CORE/rootdir directory. The specific situation is as follows:

Copy_from: = ETC/hosts. conf ETC/hosts

Copy_from + = ETC/vold. fstab

The above content adds the file to be copied to the copy_from variable for later processing.

Where can I copy it? Let's look at the definition of copy_to:

Copy_to: = $ (addprefix $ (target_out)/, $ (coby_from ))

This statement adds a target_out prefix (that is, system) to each string segment in copy_from.

The content is clear:

Copy_to: = out/target/product/tcc8800/system/etc/hosts. conf... and so on.

Then, add the path prefix to copy_from:

Copy_from: = $ (addprefix $ (local_path)/, $ (copy_from)

The reason why you want to add a prefix is the copy statement that you want to set now:

$ (Copy_to): $ (target_out)/%: $ (local_path)/% | $ (ACP)

$ (Stransform-prebuilt-to-target)

The above statement will allow android to automatically complete the copy operation before building the IMG, with the symbol % used for matching. This is why

Why do I add a prefix to copy_from.

Then, the script adds the copy_to variable to the all_prebuilt Global Macro:

All_prebuilt + = $ (copy_to)

Finally, we can see in build/CORE/makefile that the content of copy_to is extracted into another global macro, as shown below:

# Build/CORE/makefile

Internal_systemimage_files: = $ (filter $ (target_out)/%, $ (all_prebuilt )......

Because the above four lines are designed to generate system. IMG, we will not go into detail here.

It seems that part of system/CORE/rootdir is copied to out/target/product/tcc8800/system, not

Completely copied to the out/target/product/tcc8800/root directory.

We will continue to check the system/CORE/rootdir/Android. mk file. The remaining content in this file is closely related to root.

File: = $ (target_root_out)/init. RC

And then the classic copy settings:

$ (File): $ (local_path)/% | $ (ACP)

$ (Stransform-prebuilt-to-target)

The content of the subsequent script is written to generate boot. IMG.

All_prebuilt + = $ (file)

$ (Installed_ramdisk_target): $ (file)

It seems that the principle is the same as that of the above system copy. In build/CORE/makefile, It is extracted by internal_ramdisk_file,

Details: internal_ramdisk_files: = $ (filter $ (target_root_out)/%, $ (all_prebuilt )...

Then a key sentence broke the ramdisk. IMG generation:

Installed_ramdisk_target = $ (built_ramdisk_target)

$ (Installed_ramdisk_target): $ (mkbootfs $ (internal_ramdisk_files | $ (minigzip)

$ (Hide) $ (mkbootfs) $ (target_root_out) | $ (minigzip) >$ @

So many macros Let's list their values one by one:

Built_ramdisk_target = $ (product_out/ramdisk. IMG this is our goal

Installed_ramdisk_target = built_ramdisk_target is disguised.

Mkbootfs = mkbootfs is located in the out/host/linux-x86/bin directory mkbootfs, this thing also has a post.

Internal_ramdisk_files = all objects in target_root_out

It can be seen that the root directory is first packaged to generate ramdisk. IMG, and then merged into boot. IMG.

Ramdisk. IMG, one of the components of boot. IMG, has been analyzed above. Another important component of boot. IMG is the kernel,

The kernel mentioned here can only be understood as the kernel file located in out/target/product/tcc8800/. This article mainly analyzes the copy of the kernel

Process and how to package it into boot. IMG. After analysis, it is found that the kernel file located in out/target/product/tcc8800/is actually the kernel

The compiled image file is located in the kernel/ARCH/ARM/boot directory. The clue is this image file. A definition is found after searching:

Local_kernel: = kernel/ARCH/ARM/boot/Image

The definition is located in devices/telechips/tcc88xx-common/boardconfigcommon. mk, followed by Android. mk in the same directory

The following definition is provided:

Product_copy_files + = \

$ (Local_kernel): Kernel

It is intended to copy the image file and rename it as the kernel. Subsequent copy settings are completed in build/CORE/makefile and omitted here.

After the copy is complete, how does one package the Kernel File into boot. IMG? The following content also exists in build/CORE/makefile:

Internal_bootimage_args: =... -- kernel $ (installed_kernel_target)

The problem is to check the definition of installed_kernel_target. The macro is located in build/target/board/Android. mk:

Installed_kernel_target: = $ (product_out)/kernel

The content is obvious, so far, the kernel image is in place.

In addition, the definition of install_kernel_target is a little strange in build/target/board/Android. mk,

Build/target/board/Android. mk is extracted from Main. mk using subdir_makefiles and included in Main. mk.

 

 

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.