Skip to main content

Booting Andriod with u-boot

Booting Andriod with u-boot

u-boot is an open source bootloader that you will find in lots of embedded devices, including Android, and that’s what we are going to talk about today - boot up Android with u-boot.

Andriod Boot Image

Andriod boot image usually contains the kernel image and rootfs, and sometime dtb, you can either conconact the dtb to the kernel image or put it into the 2ndloader section. We’ll explain in more detail later.
|             | Description
| --------    | ------------------------------------------------|
| Header      | kernel cmdline, base/offset for kernel/ramdisk  |
| kernel      | kernel, may include dtb                         |
| ramdisk     | roofs                                           |
| 2ndloader   | 2nd bootloader                                  |
The following command (simplified for sake for simplicty) is what is used to create an Android boot image, using make bootimage.
mkbootimg --kernel zImage --ramdisk ramdisk.img.gz --cmdline 'xxxx' -o --boot.img
We’ll ignore the details regarding how the rootfs (ramdisk.img.gz) is created, which is indeed very intresting.

bootm overview

Bootm is an u-boot command that is used to booting a system from the memory, as the suffix mindicated. The full form of this command takes three parameters:
# bootm kernel ramfs dtb. 
The first parameter is the kernel address, the second one is the ram rootfs and the last one is the dtb. Only the first parameters is mandatory, and we call it boot image address generally without limiting it being kernel only.
u-boot support several boot image formats, such as uImage, which is u-boot defined image format. It is also called legacy image format but worth noting that uImage is not limited to be boot image. Instead, it is a generic container image format that can be recognized by u-boot. For example, you can package a raw ramdisk into the uImage format as well.
The other boot image format supported is Android bootimage format as we discussed above. Since Android bootimage contains the rootfs so there is no need to specify the second parameters but instead the uboot will extract the ramdisk out of the boot image and set up it correctly. For the dtb, there are approaches of concatenating it to the kernel but it requires the kernel’s awareness and ability to pull out of dtb. But not all the kernels are able to do that. For example, it is supported by aarch32 but not aarch64.
Nowadays, people are encouraged to use dtb and pass that explicitly to the kernel when booting. It is a good practice to have a dedicated partition for the dtb, so that it can be upgraded independently. But to retrieve the dtb (so as to pass to the bootm), it depends on the partition scheme you are using. Ideally, what we need is find_partition_by_name function (we have it in part.c::part_get_info_by_name). It is a breeze if gpt is used but in the case of mbrand/orerb there will be some hair scratch. As a comprise or solution, I proposed to use the underused section of Android boot image to hold the dtb, so that the Andriod boot image become a self-contained and self-sufficient boot image. And that is the way we use it for Poplar 96board.

bootm implementation

Down to essence, here are steps that are performed in the bootm.
  1. Find the kernel/os
  2. Find rootfs and dtb
  3. Relocate/decompress the kernel, if needed
  4. Relocate the rootfs if needed
  5. setup fdt or atag
  6. jump to the kernel
In the bootm implementations, those steps are called state and the entry function is do_bootm_states. You active specific step by passing corresponding enum values. say for bootm command, it is simply calling
 return do_bootm_states(
        &images, 1);
We’ll go over those states and see what will be done in each steps:
It will set up the lmb. Isn’t particular interesting.
  1. BOOTM_STATE_FINDOS -> bootm_find_os -> boot_get_kernel
boot_get_kernel will set up images.os.image_start and images.os.image_len, which are the kernel location in the ram and its length.
Some other important fields and concept: os.load, ep, os.start
images.os.load = android_image_get_kload(os_hdr);
images.ep = images.os.load;
images.os.load is used as the relocation destination when it is of different value with os.image_start. And kernel relocation usually happens. Relocations happen in the BOOTM_STATE_LOADOS stage we’ll see later.
images.ep is an alias for os.load. They should be of same value and is used to as the kernel entry point after the relocation is done.
  kernel_entry = (void (*)(void *fdt_addr, void *res0, void *res1,
        void *res2))images->ep;
images.os.start, for Android, it is the start of whole boot image (not the kernel inside of the boot image as os.image_start pointed to)
There are other fields not related to the addresses but more for information so that can be handled differently if required.
images.os.type = IH_TYPE_KERNEL;
images.os.comp = IH_COMP_NONE;
images.os.os = IH_OS_LINUX;
  1. BOOTM_STATE_FINDOTHER -> bootm_find_others -> bootm_find_images
Find ramdisk memory address, setting up images.rd_start and images.rd_end.
Find dtb memory address, setting up images.ft_addr and images.ft_len
copy the image, decompress if needed, from ram address (image.os.image_start) to its load address (image.load) and reserve that area from lmb.
iflag = bootm_disable_interrupts();
        ret = bootm_load_os(images, &load_end, 0);
        if (ret == 0)
            lmb_reserve(&images->lmb, images->os.load,
                    (load_end - images->os.load));
Will this update the image.ep as well? NO. ep is fixed when os.load is fixed.
setup the ramdisk relocation address, i.e images.initrd_start and images.initrd_end.
initrd_start is the final ramdisk load address (as os.load is for the kernel). If initrd_start is different from rd_start, ramdisk relocation will happen. The source ramdisk address is determined in the bootmcommand line (directly or indirectly) and setup in the BOOTM_STATE_FINDOTHER stage mentioned above; the destination ramdisk address can be controlled by several factors, including compile options (CONFIG_SYS_BOOT_RAMDISK_HIGH), environment variables (initrd_high) and some field in the boot image, such as the ramdisk load address in the Android bootimage. And I wholehearted agree with you it is a huge headache for a beginner (like me) to sort this out.
 * boot_ramdisk_high() takes a relocation hint from "initrd_high" environment
 * variable and if requested ramdisk data is moved to a specified location.
int boot_ramdisk_high(struct lmb *lmb, ulong rd_data, ulong rd_len,
      ulong *initrd_start,  // those are out
      ulong *initrd_end)    // out
Setup the kernel parameters using either atag or fdt, and the later take precedence over the former one. When fdt is used, it will fix up the kernel command line, ramdisk address if it is used, by amending the dtb.
int fdt_initrd(void *fdt, ulong initrd_start, ulong initrd_end) {
  err = fdt_setprop_uxx(fdt, nodeoffset, "linux,initrd-start",
            (uint64_t)initrd_start, is_u64);
Linux go!

Popular posts from this blog

Android Camera2 API Explained

Compared with the old camera API, the Camera2 API introduced in the L is a lot more complex: more than ten classes are involved, calls (almost always) are asynchronized, plus lots of capture controls and meta data that you feel confused about.

No worries. Let me help you out. Whenever facing a complex system need a little bit effort to understand, I usually turns to the UML class diagram to capture the big picture.

So, here is the class diagram for Camera2 API.

You are encouraged to read this Android document first and then come back to this article, with your questions. I'll expand what is said there, and list the typical steps of using camera2 API. 

1. Start from CameraManager. We use it to iterate all the cameras that are available in the system, each with a designated cameraId. Using the cameraId, we can get the properties of the specified camera device. Those properties are represented by class CameraCharacteristics. Things like "is it front or back camera", "outpu…

Java Collections Framework Cheat Sheet

Java Collections Framework (JCF) implements the Abstract Data Type  for Java platform. Every serious Java programmer should familiar himself on this topic and be able to choose the right class for specific need.  A thorough introduction to JCF is not the target of this small article and to achieve that goal you can start with this excellent tutorial . 

Instead, I'd like to
1) Provide an overview of JCF's classes ,   2) Provide a cheat sheet you can post in your cubicel for daily reference, 3) Underline the relationship between JCF's implementation and the data structure and algorithm you learned in your undergraduate course

With these goals in mind, I came up following diagram - Java Collection Cheat Sheet. You can click it to zoom in. There is no necessity for more explanation once your familiar with UML class diagram and have a basic understanding of common data structures.

Android Security: An Overview Of Application Sandbox

The Problem: Define a policy to control how various clients can access different resources. A solution: Each resource has an owner and belongs to a group.Each client has an owner but can belongs to multiple groups.Each resource has a mode stating the access permissions allowed for its owner, group members and others, respectively. In the context of operating system, or Linux specifically, the resources can be files, sockets, etc; the clients are actually processes; and we have three access permissions:read, write and execute.