Booting Android from NOR Flash
QEMU doesn’t provide NOR flash emulation on the goldfish platform. To make things simple, we will use RAM to create a boot-up process that is similar to the boot process from NOR flash. This approach builds a binary image that includes U-Boot, the Linux kernel, and the RAMDISK image and passes this image to QEMU through the –kernel option.
Before we start, let’s look at how QEMU boots a Linux kernel. To boot up a Linux kernel, the bootloader prepares the following environment:
The processor is in SVC (Supervisor) mode and IRQ and FIQ are disabled.
MMU is disabled.
Register r0 is set to 0.
Register r1 contains the ARM Linux machine type.
Register r2 contains the address of the kernel parameter list.
After power-up, QEMU starts to run from address 0x00000000. Before it loads a kernel image, QEMU prepares the environment described previously; it then jumps to address 0x00010000. Figure 10.4 shows a memory dump before the point at which QEMU launches a kernel image. Notice the five lines of assembly code before control is transferred to the kernel image—these lines are hard-coded by QEMU when the system starts. The first line (0x00000000) sets register r0 to 0. The second line (0x00000004) and third line (0x00000008) set register r1 to 0x5a1, which is the machine type of the goldfish platform. The fourth line (0x0000000c) sets the value of register r2 to 0x100, which is the start address of the kernel parameter list. The fifth line (0x00000010) sets the register pc to 0x10000, so the execution jumps to address 0x10000. QEMU assumes the kernel image is loaded at address 0x10000.
Figure 10.4 Memory dump of mini-bootloader at reset
As outlined in Figure 10.5, we will create an image including U-Boot, the Linux kernel, and RAMDISK for testing. U-Boot is located at address 0x00010000, which is the address that QEMU will invoke. The Linux kernel is located at address 0x00210000, and the RAMDISK image is located at address 0x00410000. Both the kernel and RAMDISK images are placed at a distance of 2MB starting from address 0x00010000. After U-Boot is relocated, it will move itself to address 0x1ff59000 (this address may change for each build) and free about 2MB from the starting address 0x00010000. We can inform U-Boot about the kernel and RAMDISK image locations through the bootm command, given from the U-Boot command line. Alternatively, you can set the default bootm parameter in include/configs/goldfish.h. We can add the default bootm and kernel parameters in goldfish.h as follows:
#define CONFIG_BOOTARGS "qemu.gles=1 qemu=1 console=ttyS0 android.qemud=ttyS1 androidboot.console=ttyS2 android.checkjni=1 ndns=1" #define CONFIG_BOOTCOMMAND "bootm 0x210000 0x410000"
Figure 10.5 Memory relocation during boot-up
The U-Boot command bootm then copies the kernel image into 0x00010000 and the RAMDISK image into 0x00800000. At that point, U-Boot jumps to address 0x00010000 to start the Linux kernel.
Creating the RAMDISK Image
Besides U-Boot and the kernel image, we need a RAMDISK image to support the boot process. In Android, RAMDISK is used as the root file system. We can customize the boot process by changing the RAMDISK content. Let’s create a RAMDISK image so that we can build the flash image for testing. Given that we are using the Android emulator, we can take advantage of the RAMDISK image from the Android SDK as the base for our image. The RAMDISK image can be found in the system image folder in the Android SDK. For an example, the RAMDISK image for Android 4.0.3 (API 15) can be found at {Android SDK installation path}/system-images/android-15/armeabi-v7a/ramdisk.img.
If we want to modify this image, we can create a folder and extract the image to that folder using the following command:
$ mkdir initrd $ cd initrd $ gzip -dc < ../ramdisk.img | cpio --extract
Once we extract the RAMDISK image, we can see its content:
$ ls -F data/ dev/ init.goldfish.rc* proc/ sys/ ueventd.goldfish.rc default.prop init* init.rc* sbin/ system/ ueventd.rc
The RAMDISK includes the folders and startup scripts for the root file system. The actual system files are stored in system.img, and the user data files are stored in userdata.img. Both system.img and userdata.img are emulated as NAND flash. They are mounted as /system and /data folders, respectively, under the root file system.
We can inspect file systems after boot-up as follows:
shell@android:/ $ mount rootfs / rootfs ro 0 0 tmpfs /dev tmpfs rw,nosuid,mode=755 0 0 devpts /dev/pts devpts rw,mode=600 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 none /acct cgroup rw,cpuacct 0 0 tmpfs /mnt/secure tmpfs rw,mode=700 0 0 tmpfs /mnt/asec tmpfs rw,mode=755,gid=1000 0 0 tmpfs /mnt/obb tmpfs rw,mode=755,gid=1000 0 0 none /dev/cpuctl cgroup rw,cpu 0 0 /dev/block/mtdblock0 /system yaffs2 ro 0 0 /dev/block/mtdblock1 /data yaffs2 rw,nosuid,nodev 0 0 /dev/block/mtdblock2 /cache yaffs2 rw,nosuid,nodev 0 0 shell@android:/ $
Now we can change the files in this folder as desired. After we’ve made those changes, we can generate the new RAMDISK image using the following commands:
$ find . > ../initrd.list $ cpio -o -H newc -O ../ramdisk.img < ../initrd.list $ cd .. $ gzip ramdisk.img $ mv ramdisk.img.gz rootfs.img
Creating the Flash Image
Now that all of the image files (U-Boot, Linux kernel, and RAMDISK) are ready, we can start to create the flash image to boot the system.
U-Boot can boot a variety of file types (e.g., ELF, BIN), but these file types have to first be repackaged in the U-Boot image format (i.e., uImage). This format stores information about the operating system type, the load address, the entry point, basic integrity verification (via CRC), compression types, free description text, and so on.
To create a U-Boot image format, we need a utility called mkimage. If this tool is not installed in the host system, it can be installed in Ubuntu using the following command:
$ sudo apt-get install uboot-mkimage
With this utility, we can repackage the kernel image and RAMDISK image in the U-Boot format using the following commands:
$ mkimage -A arm -C none -O linux -T kernel -d zImage -a 0x00010000 -e 0x00010000 zImage.uimg $ gzip -c rootfs.img > rootfs.img.gz $ mkimage -A arm -C none -O linux -T ramdisk -d rootfs.img.gz -a 0x00800000 -e 0x00800000 rootfs.uimg
Once we have uImage files in hand, we can generate a flash image using the dd command as follows:
$ dd if=/dev/zero of= flash.bin bs=1 count=6M $ dd if=u-boot.bin of= flash.bin conv=notrunc bs=1 $ dd if= zImage.uimg of= flash.bin conv=notrunc bs=1 seek=2M $ dd if= rootfs.uimg of= flash.bin conv=notrunc bs=1 seek=4M
The file flash.bin includes all three images that we will use to boot up the system.
There are multiple steps to build the Linux kernel and generate all images. Please refer to Appendix A for the detailed procedures. All related Makefiles and scripts can be found in repository build in GitHub.
Booting Up the Flash Image
Finally, we are ready to boot the flash image that we built. Let’s run it in the Android emulator and stop in the U-Boot command-line interface first. In U-Boot, we set a 2-second delay before U-Boot starts autoboot. Before autoboot starts, any keystroke will take us to the U-Boot command prompt. We can use a U-Boot command to verify the kernel and RAMDISK image, thereby making sure they are correct:
$ emulator -verbose -show-kernel -netfast -avd hd2 -qemu -serial stdio -kernel flash.bin ... U-Boot 2013.01.-rc1-00003-g54217a1 (Feb 09 2014 - 23:28:59) U-Boot code: 00010000 -> 00029B0C BSS: -> 0002D36C IRQ Stack: 0badc0de FIQ Stack: 0badc0de monitor len: 0001D36C ramsize: 20000000 TLB table at: 1fff0000 Top of RAM usable for U-Boot at: 1fff0000 Reserving 116k for U-Boot at: 1ffd2000 Reserving 136k for malloc() at: 1ffb0000 Reserving 32 Bytes for Board Info at: 1ffaffe0 Reserving 120 Bytes for Global Data at: 1ffaff68 Reserving 8192 Bytes for IRQ stack at: 1ffadf68 New Stack Pointer is: 1ffadf58 RAM Configuration: Bank #0: 00000000 512 MiB relocation Offset is: 1ffc2000 goldfish_init(), gtty.base=ff012000 WARNING: Caches not enabled monitor flash len: 0001D0D4 Now running in RAM - U-Boot at: 1ffd2000 Using default environment Destroy Hash Table: 1ffeb724 table = 00000000 Create Hash Table: N=89 INSERT: table 1ffeb724, filled 1/89 rv 1ffb02a4 ==> name="bootargs" value="qemu. gles=1 qemu=1 console=ttyS0 android.qemud=ttyS1 androidboot.console=ttyS2 android.checkjni=1 ndns=1" INSERT: table 1ffeb724, filled 2/89 rv 1ffb0160 ==> name="bootcmd" value="bootm 0x210000 0x410000" INSERT: table 1ffeb724, filled 3/89 rv 1ffb02f8 ==> name="bootdelay" value="2" INSERT: table 1ffeb724, filled 4/89 rv 1ffb0178 ==> name="baudrate" value="38400" INSERT: table 1ffeb724, filled 5/89 rv 1ffb0154 ==> name="bootfile" value="/ tftpboot/uImage" INSERT: free(data = 1ffb0008) INSERT: done In: serial Out: serial Err: serial Net: SMC91111-0 Warning: SMC91111-0 using MAC address from net device ### main_loop entered: bootdelay=2 ### main_loop: bootcmd="bootm 0x210000 0x410000" Hit any key to stop autoboot: 0 Goldfish # iminfo 0x210000 ## Checking Image at 00210000 ... Legacy image found Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1722596 Bytes = 1.6 MiB Load Address: 00010000 Entry Point: 00010000 Verifying Checksum ... OK Goldfish # iminfo 0x410000 ## Checking Image at 00410000 ... Legacy image found Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 187687 Bytes = 183.3 KiB Load Address: 00800000 Entry Point: 00800000 Verifying Checksum ... OK Goldfish #
In the preceding code, notice that we use the iminfo command to check the image at 0x00210000 and 0x00410000. U-Boot recognizes the data at these addresses as the Linux kernel image and Linux RAMDISK image, respectively. Also notice the load address: U-Boot loads the kernel image to address 0x00010000 and the RAMDISK image to address 0x00800000.
We can boot the system using the bootm command as follows:
Goldfish # bootm 0x210000 0x410000 ## Current stack ends at 0x1ffadb10 * kernel: cmdline image address = 0x00210000 ## Booting kernel from Legacy Image at 00210000 ... Image Name: Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 1722596 Bytes = 1.6 MiB Load Address: 00010000 Entry Point: 00010000 kernel data at 0x00210040, len = 0x001a48e4 (1722596) * ramdisk: cmdline image address = 0x00410000 ## Loading init Ramdisk from Legacy Image at 00410000 ... Image Name: Image Type: ARM Linux RAMDisk Image (uncompressed) Data Size: 187687 Bytes = 183.3 KiB Load Address: 00800000 Entry Point: 00800000 ramdisk start = 0x00800000, ramdisk end = 0x0082dd27 Loading Kernel Image ... OK CACHE: Misaligned operation at range [00010000, 006a2390] OK kernel loaded at 0x00010000, end = 0x001b48e4 using: ATAGS ## Transferring control to Linux (at address 00010000)... Starting kernel ... Uncompressing Linux............................................................. ........................................... done, booting the kernel. goldfish_fb_get_pixel_format:167: display surface,pixel format: bits/pixel: 16 bytes/pixel: 2 depth: 16 red: bits=5 mask=0xf800 shift=11 max=0x1f green: bits=6 mask=0x7e0 shift=5 max=0x3f blue: bits=5 mask=0x1f shift=0 max=0x1f alpha: bits=0 mask=0x0 shift=0 max=0x0 Initializing cgroup subsys cpu Linux version 2.6.29-ge3d684d (sgye@sgye-Latitude-E6510) (gcc version 4.6.3 (Sourcery CodeBench Lite 2012.03-57) ) #1 Sun Feb 9 23:32:29 CST 2014 CPU: ARMv7 Processor [410fc080] revision 0 (ARMv7), cr=10c5387f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Goldfish Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: qemu.gles=1 qemu=1 console=ttyS0 android.qemud=ttyS1 androidboot.console=ttyS2 android.checkjni=1 ndns=1 Unknown boot option 'qemu.gles=1': ignoring Unknown boot option 'android.qemud=ttyS1': ignoring Unknown boot option 'androidboot.console=ttyS2': ignoring Unknown boot option 'android.checkjni=1': ignoring PID hash table entries: 2048 (order: 11, 8192 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) Memory: 512MB = 512MB total Memory: 515456KB available (2944K code, 707K data, 124K init) Calibrating delay loop... 370.27 BogoMIPS (lpj=1851392) Mount-cache hash table entries: 512 Initializing cgroup subsys debug Initializing cgroup subsys cpuacct Initializing cgroup subsys freezer CPU: Testing write buffer coherency: ok net_namespace: 936 bytes NET: Registered protocol family 16 bio: create slab <bio-0> at 0 NET: Registered protocol family 2 IP route cache hash table entries: 16384 (order: 4, 65536 bytes) TCP established hash table entries: 65536 (order: 7, 524288 bytes) TCP bind hash table entries: 65536 (order: 6, 262144 bytes) TCP: Hash tables configured (established 65536 bind 65536) TCP reno registered NET: Registered protocol family 1 checking if image is initramfs... it is Freeing initrd memory: 180K goldfish_new_pdev goldfish_interrupt_controller at ff000000 irq -1 goldfish_new_pdev goldfish_device_bus at ff001000 irq 1 goldfish_new_pdev goldfish_timer at ff003000 irq 3 goldfish_new_pdev goldfish_rtc at ff010000 irq 10 goldfish_new_pdev goldfish_tty at ff002000 irq 4 goldfish_new_pdev goldfish_tty at ff011000 irq 11 goldfish_new_pdev goldfish_tty at ff012000 irq 12 goldfish_new_pdev smc91x at ff013000 irq 13 goldfish_new_pdev goldfish_fb at ff014000 irq 14 goldfish_new_pdev goldfish_audio at ff004000 irq 15 goldfish_new_pdev goldfish_mmc at ff005000 irq 16 goldfish_new_pdev goldfish_memlog at ff006000 irq -1 goldfish_new_pdev goldfish-battery at ff015000 irq 17 goldfish_new_pdev goldfish_events at ff016000 irq 18 goldfish_new_pdev goldfish_nand at ff017000 irq -1 goldfish_new_pdev qemu_pipe at ff018000 irq 19 goldfish_new_pdev goldfish-switch at ff01a000 irq 20 goldfish_new_pdev goldfish-switch at ff01b000 irq 21 goldfish_pdev_worker registered goldfish_interrupt_controller goldfish_pdev_worker registered goldfish_device_bus goldfish_pdev_worker registered goldfish_timer goldfish_pdev_worker registered goldfish_rtc goldfish_pdev_worker registered goldfish_tty goldfish_pdev_worker registered goldfish_tty goldfish_pdev_worker registered goldfish_tty goldfish_pdev_worker registered smc91x goldfish_pdev_worker registered goldfish_fb goldfish_pdev_worker registered goldfish_audio goldfish_pdev_worker registered goldfish_mmc goldfish_pdev_worker registered goldfish_memlog goldfish_pdev_worker registered goldfish-battery goldfish_pdev_worker registered goldfish_events goldfish_pdev_worker registered goldfish_nand goldfish_pdev_worker registered qemu_pipe goldfish_pdev_worker registered goldfish-switch goldfish_pdev_worker registered goldfish-switch ashmem: initialized Installing knfsd (copyright (C) 1996 okir@monad.swb.de). fuse init (API version 7.11) yaffs Feb 9 2014 23:30:30 Installing. msgmni has been set to 1007 alg: No test for stdrng (krng) io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered allocating frame buffer 480 * 800, got ffa00000 console [ttyS0] enabled brd: module loaded loop: module loaded nbd: registered device at major 43 goldfish_audio_probe tun: Universal TUN/TAP device driver, 1.6 tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com> smc91x.c: v1.1, sep 22 2004 by Nicolas Pitre <nico@cam.org> eth0 (smc91x): not using net_device_ops yet eth0: SMC91C11xFD (rev 1) at e080c000 IRQ 13 [nowait] eth0: Ethernet addr: 52:54:00:12:34:56 goldfish nand dev0: size c5e0000, page 2048, extra 64, erase 131072 goldfish nand dev1: size c200000, page 2048, extra 64, erase 131072 goldfish nand dev2: size 4000000, page 2048, extra 64, erase 131072 mice: PS/2 mouse device common for all mice *** events probe *** events_probe() addr=0xe0814000 irq=18 events_probe() keymap=qwerty2 input: qwerty2 as /devices/virtual/input/input0 goldfish_rtc goldfish_rtc: rtc core: registered goldfish_rtc as rtc0 device-mapper: uevent: version 1.0.3 device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised: dm-devel@redhat.com logger: created 64K log 'log_main' logger: created 256K log 'log_events' logger: created 64K log 'log_radio' Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (8192 buckets, 32768 max) CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or sysctl net.netfilter.nf_conntrack_acct=1 to enable it. ctnetlink v0.93: registering with nfnetlink. NF_TPROXY: Transparent proxy support initialized, version 4.1.0 NF_TPROXY: Copyright (c) 2006-2007 BalaBit IT Ltd. xt_time: kernel timezone is -0000 ip_tables: (C) 2000-2006 Netfilter Core Team arp_tables: (C) 2002 David S. Miller TCP cubic registered NET: Registered protocol family 10 ip6_tables: (C) 2000-2006 Netfilter Core Team IPv6 over IPv4 tunneling driver NET: Registered protocol family 17 NET: Registered protocol family 15 RPC: Registered udp transport module. RPC: Registered tcp transport module. 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com> All bugs added by David S. Miller <davem@redhat.com> VFP support v0.3: implementor 41 architecture 3 part 30 variant c rev 0 goldfish_rtc goldfish_rtc: setting system clock to 2014-02-20 08:54:53 UTC (1392886493) Freeing init memory: 124K mmc0: new SD card at address e118 mmcblk0: mmc0:e118 SU02G 100 MiB mmcblk0: init: cannot open '/initlogo.rle' yaffs: dev is 32505856 name is "mtdblock0" yaffs: passed flags "" yaffs: Attempting MTD mount on 31.0, "mtdblock0" yaffs_read_super: isCheckpointed 0 save exit: isCheckpointed 1 yaffs: dev is 32505857 name is "mtdblock1" yaffs: passed flags "" yaffs: Attempting MTD mount on 31.1, "mtdblock1" yaffs_read_super: isCheckpointed 0 yaffs: dev is 32505858 name is "mtdblock2" yaffs: passed flags "" yaffs: Attempting MTD mount on 31.2, "mtdblock2" yaffs_read_super: isCheckpointed 0 init: untracked pid 39 exited eth0: link up shell@android:/ $ warning: 'zygote' uses 32-bit capabilities (legacy support in use)
Source-Level Debugging of the Flash Image
At this point, we can use a flash image that includes both U-Boot and the goldfish kernel to boot up the system. But can we do source-level debugging as well? If we are working on a real hardware board with JTAG debugger, it is quite difficult to do source-level debugging for both U-Boot and the kernel. However, no such problem arises in a virtual environment. With this approach, we can closely observe the transition from bootloader to Linux kernel using source-level debugging. This is a convenient way to debug the U-Boot boot-up process. We can track the interaction between U-Boot and Linux kernel by tracing the execution of the source code.
Let’s start the Android emulator with gdb support:
$ emulator -verbose -show-kernel -netfast -avd hd2 -shell -qemu -s -S -kernel flash.bin
We connect to the Android emulator using gdb:
$ ddd --debugger arm-none-eabi-gdb u-boot/u-boot
As shown in Figure 10.6, we load U-Boot in gdb with source-level debugging information.
Figure 10.6 Loading U-Boot to gdb
Now we can perform source-level debugging for U-Boot. Since U-Boot will reload itself, we must use the same technique that we applied in Chapter 9 to continue the source-level debugging after memory relocation occurs.
Each time we start U-Boot in gdb, we have to go through a series of steps. It is much easier (and faster) to put these steps into a gdb script, as shown in Example 10.1. This script can be found in the folder bin of the repository build.
Example 10.1 GDB Startup Script for U-Boot (u-boot.gdb)
# Debug u-boot b board_init_f c b relocate_code c p/x ((gd_t *)$r1)->relocaddr d symbol-file ./u-boot/u-boot add-symbol-file ./u-boot/u-boot 0x1ff59000 b board_init_r
We can load this script in the gdb console using the following command:
(gdb) target remote localhost:1234 (gdb) source bin/u-boot.gdb
After running this script, we can see that U-Boot has stopped at board_init_f() and the U-Boot symbol has been reloaded to the memory address after its relocation, as shown in Figure 10.7.
Figure 10.7 Reload the U-Boot symbol after relocation
Let’s continue running U-Boot to a point after memory relocation. In the script u-boot.gdb, the breakpoint is set to board_init_r(). After U-Boot stops at this breakpoint, we can load the goldfish kernel symbol. The multiple steps to load the goldfish kernel can also be put into a gdb script, as shown in Example 10.2. This script can also be found in the folder bin of the repository build.
Example 10.2 GDB Script for Debugging Goldfish Kernel (goldfish.gdb)
# Debug goldfish kernel d symbol-file ./goldfish/vmlinux add-symbol-file ./goldfish/vmlinux 0x00010000 b start_kernel
We can load the script goldfish.gdb to the gdb console as follows:
(gdb) source bin/goldfish.gdb add symbol table from file "/home/sgye/src/build/goldfish/vmlinux" at .text_addr = 0x10000 Breakpoint 4 at 0xc00086b4: file /home/sgye/src/goldfish/init/main.c, line 535. (2 locations) ... warning: (Internal error: pc 0x10088 in read in psymtab, but not in symtab.) (gdb) c warning: (Internal error: pc 0x10088 in read in psymtab, but not in symtab.) Breakpoint 4, start_kernel () at /home/sgye/src/goldfish/init/main.c:535 (gdb)
In the script goldfish.gdb, the kernel symbol is loaded from vmlinux at memory address 0x10000 and a breakpoint is set at start_kernel(). After loading the kernel symbol, we can continue running U-Boot. Now the system stops at the Linux kernel code, as shown in Figure 10.8.
Figure 10.8 The goldfish kernel at start_kernel()
As we can see in this session, we have much more control over the system in the virtual environment compared to what is possible in the real hardware. In turn, we can perform a deeper analysis of the code by tracing the execution path at the source level. We can work at the source level, starting from the first line of code and working all the way to the point at which the operating system fully boots up.