Boot Sequence

Syscon
Syscon powers up and sets up DRAM, sets up boot context buffer, turns on the KERMIT SOC which eventually starts the Boot code on the CMeP Processor.

First Loader
The PS Vita main application processor is an ARM Cortex A9 MPcore. It implements ARM TrustZone for execution in both a non-secure world and a sandboxed Secure World. However it is not the first processor to run on boot.

The cmep processor is the actual secure boot device rather than the ARM processor. The cmep processor's boot ROM, nicknamed First Loader, is the first known code running on PS Vita start. Once it starts, it likely maps the eMMC and directly reads in the second_loader.enp from the eMMC (SLB2 partition) or SD Card (if SD BOOT challenge passes). This is in the native load format of the boot ROM. There are two layers of encryption. First it decrypts the per-console SLSK personalization layer that was added during the System Software installation. After that, it decrypts the factory-encrypted SLSK layer then begins execution.

Second Loader
The Second Loader is primarily responsible for preparing the ARM processor. It initializes DRAM and decrypts kernel_boot_loader.self from eMMC SLB2 partition into DRAM. It also writes the ARM exception vector and some boot context information to the 32kB scratch buffer (mirror mapped to 0x00000000 on ARM). kernel_boot_loader.self contains both the secure kernel bootloader and TrustZone, as well as the non-secure kernel bootloader. At this point the kprx_auth_sm.self and prog_rvk.srvk read from the eMMC SLB2 partition are both loaded into DRAM. Finally, the Second Loader resets itself with a pointer to the secure_kernel.enp binary.

Secure Kernel
the cmep processor then restarts and loads the secure_kernel.enp in and again decrypts the per-console layer that was added during the System Software installation, and the factory layer. At this point the cmep processor is prepared and Secure Kernel tells Syscon to reset the ARM CPU at 0x00000000 (cmep scratch buffer). This triggers the ARM secure boot process.

Secure Kernel Bootloader
The secure kernel bootloader decompresses the ARZL compressed TrustZone kernel, loads it and sets up the VBAR and MVBAR. It then decompresses the ARZL non-secure kernel bootloader, sets NS in SCR and jumps into non-secure kernel bootloader with svc mode. See Kernel Boot Loader for more information.

Non-secure Kernel Bootloader
The non-secure kernel bootloader contains an embedded and likely stripped version of SceSysmem, SceKernelModulemgr, SceSblSmschedProxy, and some other core drivers. The NSKBL sets up the eMMC device (again) and starts.

ScePsp2BootConfig
This kernel module does not export any library. It only has a module init function that has a hard coded list of core kernel modules (ex: sysmem.skprx) which are loaded with calls back into NSKBL through SceKblForKernel imports. Once the core initialization is done, the next module to run is SceSysStateMgr.

FW 0.931.010 special case
On System Software version 0.931.010 (and probably earlier versions), NSKBL embeds the kernel modules list in data segment instead of using the ScePsp2BootConfig kernel module. Here is the list:

SceSysStateMgr
This kernel module also does not export any library. Its init function first maps all the SceKernelBootimage embedded modules and redirects them to os0:kd/. Then it decrypts  or   or   and parses the System Configuration Script to load the remaining modules and finally either SceSafemode or SceShell or ScePsp2Swu or ScePsp2Diag.

Also refer to the SceSysStateMgr page for System Configuration Script.

Boot Partition
The boot partition is SLB2 formatted. It contains entries these files:

Boot Debug Checkpoint Codes
During the boot sequence, the various bootloaders will update a GPIO register specifying the progress into boot. This can be used to debug where in the boot process something fails.

Second Loader checkpoint codes start at 0x40 (e.g. GPO value  corresponds to SBL code  ).

GPIO
The GPIO registers are registered at  (turn off bits) and   (turn on bits). On PDEL units, this maps to the LED lights.

Known Codes
The Event column indicates what happens/is about to happen when a code is shown on the GPO LED. If boot of the unit doesn't succeed, the Halting event column indicates what caused the boot process to fail based on the last value of the GPO LED.

Suspend and Resume
Upon suspension, context is written to memory and a syscon command is issued to save the context pointer as well as other information (for example, if it should restart into update mode). When resuming, the boot process is the same as cold boot up until the secure kernel bootloader. After secure kernel loads, instead of decompressing and jumping to the non-secure kernel bootloader, it restores the saved context and returns to the kernel resume code.

See also Suspend.