Fuchsia Bootup - abhishekkumardwivedi/Fuchs1a-doc GitHub Wiki

Zircon bootup

Zircon receives command-line arguments from bootloader for how the system should be booted up. This option could be enabled or disabled at the command line by setting option=false.

Commands received from bootloader are a mix of options for kernel as well as userspace bootup. Commands which are intended to the kernel is processed at the kernel space itself and the remaining command is transferred to userspace bootup for user boot and device manager i.e. devmgr receives these options.

devmgr reads configuration form /boot/config/devmgr which could be overridded by kernel.

Userspace bootup

After the kernel is booted up, userspace bootup doesn't start immediately but via userboot. Userboot is a program embedded along with the kernel image, but it is not part of the kernel. Address of userboot is known to the kernel by the offset as part of kernel image. Userboot runs in userspace and talks to kernel by system calls. The job of userboot is to parse rootfs meta information, to decompress rootfs image. This is primary rootfs, a ramdisk image. Once primary rootfs is decompressed it contains all the needed executables, libs and data for userspace to run.

After Kernel is booted up and user space is kickstarted by userboot, further jump to userspace is done with bootsvc as being the first program to come up. So, in the view of userspace, bootsvc is the first user space program (it doesn't know about userboot). Bootsvc then brings up many system core services:

  1. Filesystem service with bootfs which is /boot partition
  2. Loader service started from bootfs

And after these services, it next executable is started based on provided in kernel command line file. Kernel command-line file is placed at the root of the file system with name cmdline i.e. /cmdline.

A typical cmdline file looks like:
bootserver zircon.bin bootfs.bin -- gfxconsole.font=18x32 gfxconsole.early=false

Here, since bootsvc.next is not provided default will be /bin/devmgr. We will see bootsvc.next in later sections. This is handle as:

if (bootsvc_next == nullptr) { bootsvc_next = "bin/component_manager," "fuchsia-boot:///#meta/root.cm," "--use-builtin-process-launcher"; }

In typical there will be partitions like:
/boot
/svc

bootsvc jobs

  1. Sets up bootfs service
  2. Process ZBI boot image
  3. Load boot arguments from /config/devmgr into VMO
  4. Take root resource
  5. Setup svcfs service
  6. Consume certain VMO types from the startup handle table
  7. Creating the loader service
  8. Launch next process from bootsvc.next

bootsvc.next sequence:

After bootsvc has done its job, next services is started by bootsvc.next. This is executed as part of thread as next process execution may request to loader service running in async loop. bootsvc.next program is provided by kernel command line, which actually comes from /bootcmd. If this option is not provided in bootcmd file then default is handled by bootsvc as:
This is handle as:
if (bootsvc_next == nullptr) { bootsvc_next = "bin/component_manager," "fuchsia-boot:///#meta/root.cm," "--use-builtin-process-launcher"; }

It is worth to check std::thread API to understand how this next process thread is started:
std::thread(LaunchNextProcess, bootfs_svc, svcfs_svc, loader_svc, std::cref(log)).detach(); Which is a last job in the bootsvc loop to run. Bootsvc.next uses fuchsia.io.Node service channel.

Program Loader

TODO

Other system core services

devmgr

TODO

netsvc

TODO

svchost

TODO

miscsvc

TODO

pwrbtn-monitor

TODO

virtcon

TODO