[Android General] Tzul:
MediaTek boot process and partitions 101

Since [MENTION=7184758]charlestek[/MENTION] was asking about the purpose of all the partitions earlier, and since I've been planning to do this anyway... here comes a long post.

If you want to understand the purpose of some of the partitions, then you first need to know details about the boot sequence.

When the tablet is turned on, the CPU initializes itself and has to start executing code from somewhere. But at this time, pretty much all the hardware is uninitialized and not yet usable: no flash memory, not even the 2 GB of main memory (DRAM, dynamic random access memory). However, the CPU has a bit of integrated memory: SRAM (static random access memory, SRAM vs. DRAM see here). And the CPU has a "Boot ROM" (BROM, read-only memory).

It is this BROM that contains the first instructions for the CPU. They are fixed and unchangeable. The BROM code initializes the MediaTek chip's serial port (UART, universal asynchronous receiver/transmitter), and actually provides a read/write interface this way, which could be used to "unbrick" a dead tablet. However, the UART port isn't accessible from the outside, as far as I know, so you'd have to open the tablet, find the right contacts on its mainboard, and solder some wires to them, in order to connect that serial port to your PC - not really an option for most people.

Anyway, the BROM also initializes the internal flash memory chip(s), then loads the preloader from flash memory into the SRAM, and hands off execution to it.

The preloader continues initializing more hardware, like the DRAM (finally), the PMU (power management unit), and the USB port. While USB stands for "universal serial bus", its normal data transfer protocol is fairly complex, and not as easy to implement as the serial COM ports of yore it replaced. Since the on-chip SRAM is quite small (just a few dozen kilobytes, usually), the preloader must be small enough to fit inside, and therefore can't include a ton of features.

So, the preloader configures the USB port in a special way, as virtual COM port (VCOM), basically mimicking the BROM's UART port. And that's why you need that special preloader USB driver.

The preloader then listens on this VCOM port for about 2 seconds. If the SPFT connects during that time, they "shake hands", and the SPFT sends a "download agent" (DA) over. The preloader receives the DA, stores it in main memory (DRAM), and finally hands off execution to the DA. It is this DA then which performs the downloading (=flashing) and reading back, and afterwards turns off the tablet. The advantages of this approach are clear: the preloader doesn't have to include all this functionality (must stay small), and in case of bugs or updates concerning the download/readback procedures, nothing on the tablet needs to be changed, because the DA lives "outside" with the SPFT.

If the preloader doesn't get any response on the VCOM port within the short timeframe, it disables the port and continues with the normal boot process.

This involves checking the cryptographic signatures of several partitions, at least on "locked" (tamper-proof) systems.

If the signatures are valid (or the system is "unlocked", which ours is), the preloader loads the bootloader from flash memory into DRAM, and hands off execution to it.

The bootloader, LK = Little Kernel in our case, initializes yet more hardware, like the screen, and displays the boot logo ("Lenovo - powered by Android", this boot logo is not the same as the boot animation that follows later). It also analyzes the boot reason (power key pressed, USB connected, alarm clock went off, and a few more), and decides how to continue. It checks if certain hardware keys are pressed, and if power key + volume up key are pressed, it shows the tiny "Normal, Recovery, Fastboot" selection menu. Yes, the bootloader also implements Fastboot, which has nothing to do with the speed of booting, but is a USB protocol for flashing partitions, and sending a few other commands to the bootloader.

NB: preloader and LK are sometimes called first and second stage bootloaders.

Once the boot mode has been decided, the bootloader will either go into Fastboot mode, do some other boot stuff that isn't important here, or finally load and run the recovery, or the boot image. These two partitions, boot and recovery, share the same basic format. They start with a header containing information about memory addresses and sizes, followed by the Linux kernel, followed by the ramdisk. This ramdisk contains the initial Linux/Android filesystem, most importantly the init executable, its script file init.rc, and often more .rc scripts (referenced by init.rc).

In case of the recovery, init.rc contains relatively few commands. Its main purpose is to launch the recovery executable, normally /sbin/recovery, which is of course included in the recovery's ramdisk.

In case of the normal boot partition, init.rc does a lot more work, like mounting the /system and /data filesystems from their respective partitions, launching various background services, including the boot animation that is supposed to keep users entertained / at ease, while Android and everything that belongs to it is starting up.

By the way, the init executable is also responsible for Android's property system. It parses the default.prop file from the ramdisk, and /system/build.prop, and also "persistent" properties from /data/property/. But properties are a topic in and of themselves...

So, let's look at a list of all partitions of this tablet. Unless a filesystem (e.g. ext4) is mentioned, all partitions are "raw" (binary blobs with mostly unknown formats).

preloader: Explained above. It's perhaps the most crucial of all partitions. Don't flash if you don't have to, because if the preloader gets damaged, your device is "bricked", and the SPFT won't work anymore. Unless the device has a special recovery mode in the Boot ROM that allows the SPFT to restore a missing/broken preloader (this tablet apparently has this feature).

pgpt: primary GUID partition table

proinfo: product info; empty on my phone, contains my unique serial number on my tablet; probably the vendor's choice whether this gets used or not

nvram: the non-volatile random access memory; holds unique configuration info such as the WiFi and Bluetooth MAC addresses, IMEI (for devices with SIM card), and some other stuff related to audio, camera, GPS. This data gets "unpacked" to /data/nvram/ (or on newer devices to a dedicated "nvdata" partition) by an init.rc service (nvram daemon), if not present there already. This service also stores a little activity log inside the nvram partition!

protect1: alternate name "protect_f"; ext4 filesystem, usually empty. No idea what it's for.

protect2: alternate name "protect_s"; same as protect1 ...

kb: "keyblock", no idea, appears to be empty

dkb: same as kb

seccfg: appears to be related to security/signature checks performed by preloader and bootloader. Empty on this tablet.

lk: "Little Kernel", the bootloader, explained above. Alternate name "uboot", because previously, a bootloader called Das U-Boot was used. But all MediaTek devices I've seen in the past few years use LK, even if the partition name wasn't updated accordingly.

boot: Android boot image: Linux kernel + Android ramdisk

recovery: Recovery boot image: Linux kernel + recovery ramdisk

secro: appears to be related to security/signature checks performed by preloader and bootloader. Not empty.

para: alternate name "misc"; space for miscellaneous parameters. The bootloader stores some variables here (e.g. whether "off-mode charging" is enabled or disabled), and maybe messages to the recovery or Android. Some logging info could also be stored here.

logo: the boot logo, and other graphics the bootloader might need (like battery charging graphics, if the device can do "off-mode charging").

expdb: no idea, mostly empty, contains some log fragments?

tee1: Trusted Execution Environment, something to do with ARM's TrustZone, apparently involved in "full disk encryption", more on that in a second.

tee2: same as tee1, gotta have two for redundancy, I guess.

metadata: The crypto metadata, used for Android's "full disk encryption". This feature actually "only" encrypts the /data partition (userdata). In some older devices, the crypto metadata used to be stored in a "footer" at the end of the encrypted data partition, but newer devices store it in this dedicated partition, which is probably safer and more convenient. So, if you use Android's "full disk encryption" feature (Android system settings, security), then you should not mindlessly backup and restore this metadata partition, or you might literally trash the key to all your data. Otherwise, this partition is probably unused and empty.

system: the main Android system files, ext4 filesystem, gets mounted to /system

cache: the Android cache partition, ext4 filesystem, gets mounted to /cache, used for some temporary files, and also by the recovery for its log file

userdata: the main data partition, ext4 filesystem, gets mounted to /data, used for user-installed apps, and all app settings. Also contains /sdcard, which is not the actual MicroSD card, but the "internal storage", where media files and other app data files can be placed. In the past, /sdcard used to be its own partition with FAT32 filesystem, but here it is emulated and actually a link to /data/media/0. This so-called "data media" layout has the advantage that the available space is shared dynamically: don't have many picture and music files in /sdcard? More space for apps in /data! Don't have many apps installed? More space for music, pictures, videos! The disadvantage is that /sdcard can't be mounted in USB mass storage mode anymore, because Windows PCs don't understand the ext4 filesystem.

flashinfo: alternate name "bmtpool", I think. Might have contained the flash block mapping table in the past, used for wear leveling and to keep track of bad blocks. But nowadays, eMMC flash has a built-in controller for that, so that can't be the purpose anymore. The SPFT stores some info here, but I don't know details.

sgpt: secondary GUID partition table; gotta have two for redundancy, I guess.

If anybody has more insight to offer where mine was lacking, please contribute. :)