Difference between revisions of "Boot Sequence"

From Vita Development Wiki
Jump to navigation Jump to search
(12 intermediate revisions by 3 users not shown)
Line 4: Line 4:
  
 
=== Boot ROM ===
 
=== Boot ROM ===
−
It is likely that the F00D processor (MeP Core) is the actual secure boot device rather than the ARM CPU. The F00D processor likely is Toshiba MEP based and is the first secure device ("first loader") to start on the Vita. Once it starts it likely maps the eMMC and directly reads in the second_loader.enp or second_loader.enp_ from the eMMC. This is in the native load format of the F00D bootrom. There are likely 2 layers of encryption. First it decrypts the per-console layer that was added during the install. After that it will decrypt the factory-encrypted layer then begin execution.
+
It is likely that the F00D processor (MeP Core) is the actual secure boot device rather than the ARM CPU. The F00D processor is Toshiba MEP based and is the first secure device ("first loader") to start on the Vita. Once it starts it likely maps the eMMC and directly reads in the second_loader.enp or second_loader.enp_ from the eMMC [[#Boot Partition|slb2]] partition. This is in the native load format of the F00D bootrom. There are likely 2 layers of encryption. First it decrypts the per-console layer that was added during the install. After that it will decrypt the factory-encrypted layer then begin execution.
  
−
The second_loader is primarily responsible for preparing the ARM processor. It initializes DRAM and decrypts slb2 kernel_boot_loader.self 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). The kernel_boot_loader.self contains both the secure world bootloader and kernel, as well as the non-secure boot loader. At this point the kprx_auth_sm.self and prog_rvk.srvk are both loaded into DRAM.
+
The second_loader is primarily responsible for preparing the ARM processor. It initializes DRAM and decrypts slb2 kernel_boot_loader.self 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 world kernel bootloader and secure kernel, as well as the non-secure kernel boot loader. At this point the slb2 kprx_auth_sm.self and prog_rvk.srvk are both loaded into DRAM.
  
 
Finally, the second_loader resets itself with a pointer to the secure_kernel.enp or enp_. F00D processor then restarts and loads the secure_kernel.enp in and again decrypts the per-console layer that was added by the install, and the factory layer. At this point the F00D processor secure kernel is prepared and it resets the ARM CPU at 0x00000000 (F00D scratch buffer). This triggers the ARM secure boot process to begin.
 
Finally, the second_loader resets itself with a pointer to the secure_kernel.enp or enp_. F00D processor then restarts and loads the secure_kernel.enp in and again decrypts the per-console layer that was added by the install, and the factory layer. At this point the F00D processor secure kernel is prepared and it resets the ARM CPU at 0x00000000 (F00D scratch buffer). This triggers the ARM secure boot process to begin.
  
 
=== Secure Kernel ===
 
=== Secure Kernel ===
−
The bootloader decompresses the [[ARZL]] secure kernel, loads it and sets up the VBAR and MVBAR. It then decompresses the [[ARZL]] non-secure bootloader and sets NS in SCR and jumps into non-secure bootloader. See [[Secure Bootloader]] for more information.
+
The bootloader decompresses the [[ARZL]] secure kernel, loads it and sets up the VBAR and MVBAR. It then decompresses the [[ARZL]] non-secure kernel bootloader and sets NS in SCR and jumps into non-secure kernel bootloader. See [[Secure Bootloader]] for more information.
  
 
=== SceKblForKernel ===
 
=== SceKblForKernel ===
−
The non-secure bootloader contains an embedded and likely stripped version of [[SceSysmem]], [[SceKernelModulemgr]], [[SceSblSmschedProxy]], and some core drivers. The non-secure bootloader sets up the eMMC device (again) and loads <code>os0:psp2bootconfig.skprx</code>.
+
The non-secure kernel bootloader contains an embedded and likely stripped version of [[SceSysmem]], [[SceKernelModulemgr]], [[SceSblSmschedProxy]], and some other core drivers. The NS KBL sets up the eMMC device (again) and starts <code>os0:psp2bootconfig.skprx</code>.
  
 
=== ScePsp2BootConfig ===
 
=== ScePsp2BootConfig ===
−
This kernel module does not export any libraries. 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 SceKblForKernel. Once the core initialization is done, the next module to run is SceSysStateMgr.
+
 
 +
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.
 +
 
 +
==== 0.931 special case ====
 +
 
 +
On 0.931, NSKBL embeds the kernel modules list instead of using ScePsp2BootConfig. Here is the list:
 +
 
 +
<source>
 +
sysmem.skprx
 +
 
 +
excpmgr.skprx
 +
 
 +
intrmgr.skprx
 +
 
 +
systimer.skprx
 +
acmgr.skprx
 +
threadmgr.skprx
 +
dmacmgr.skprx
 +
 
 +
ssproxy.skprx
 +
 
 +
smsc_proxy.skprx
 +
 
 +
authmgr.skprx
 +
 
 +
iofilemgr.skprx
 +
modulemgr.skprx
 +
processmgr.skprx
 +
 
 +
backtrace.skprx
 +
sdbgsdio.skprx
 +
deci4p_sdfmgr.skprx
 +
deci4p_sttyp.skprx
 +
deci4p_sdbgp.skprx
 +
deci4p_sdrfp.skprx
 +
stdio.skprx
 +
lowio.skprx
 +
clockgen.skprx
 +
sdif.skprx
 +
sdstor.skprx
 +
 
 +
fatsd.skprx
 +
exfatfs.skprx
 +
 
 +
pamgr.skprx
 +
sysstatemgr.skprx
 +
</source>
  
 
=== SceSysStateMgr ===
 
=== SceSysStateMgr ===
−
This kernel module also does not export any libraries. Its init function first loads all the [[SceKernelBootimage|bootfs]] modules. Then it decrypts <code>os0:psp2config_vita.skprx</code> or <code>os0:psp2config_dolce.skprx</code> and parses the [[Boot Sequence#System Configuration Script|System Configuration Script]] to load the remaining modules and finally either [[SceSafemode]] or [[SceShell]] or [[ScePsp2Swu]] or [[ScePsp2Diag]].
+
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 <code>os0:psp2config.skprx</code> or <code>os0:psp2config_vita.skprx</code> or <code>os0:psp2config_dolce.skprx</code> and parses the [[Boot Sequence#System Configuration Script|System Configuration Script]] to load the remaining modules and finally either [[SceSafemode]] or [[SceShell]] or [[ScePsp2Swu]] or [[ScePsp2Diag]].
  
 
== Boot Partition ==
 
== Boot Partition ==
Line 31: Line 77:
 
|-
 
|-
 
| kernel_boot_loader.self
 
| kernel_boot_loader.self
−
| 1.05
+
| 0.931
−
| This could be the non-secure bootloader SceKblForKernel
+
| Secure KBL and ARZL compressed NS KBL
 
|-
 
|-
 
| kprx_auth_sm.self
 
| kprx_auth_sm.self
−
| 1.05
+
| 0.931
−
| Used by [[F00D Processor]] to decrypt SELFs
+
| Used with [[F00D Processor]] to decrypt SELFs
 
|-
 
|-
 
| prog_rvk.srvk
 
| prog_rvk.srvk
−
| 1.05
+
| 0.931
−
| [[SCE]] encrypted revocation data of some sort
+
| [[SCE]] encrypted SELF revocation list
 
|-
 
|-
 
| second_loader.enp
 
| second_loader.enp
−
| 1.05
+
| 0.931
−
| Possibly the secure bootloader
+
| Secure bootloader
 
|-
 
|-
 
| second_loader.enp_
 
| second_loader.enp_
−
| 1.69
+
| 0.931
 
| Related to second_loader.enp in some way, likely for encryption
 
| Related to second_loader.enp in some way, likely for encryption
 
|-
 
|-
 
| secure_kernel.enp
 
| secure_kernel.enp
−
| 1.05
+
| 0.931
−
| Possibly the secure kernel [[ARZL]] compressed and loaded into memory by ROM
+
| Secure kernel loader
 
|-
 
|-
 
| secure_kernel.enp_
 
| secure_kernel.enp_
−
| 1.05
+
| 0.931
 
| Related to secure_kernel.enp in some way, likely for encryption
 
| Related to secure_kernel.enp in some way, likely for encryption
 +
|-
 +
| secure_kernel.xxx
 +
| 0.931
 +
| Prototype secure kernel loader encrypted differently than secure_kernel.enc
 
|}
 
|}
  
Line 62: Line 112:
 
<code>os0:psp2config.skprx</code> once decrypted is a UTF-8 text file that is parsed by SceSysStateMgr. It is a very simple script format.
 
<code>os0:psp2config.skprx</code> once decrypted is a UTF-8 text file that is parsed by SceSysStateMgr. It is a very simple script format.
  
−
If "manufacturing mode" is enabled, then it is possible to load <code>psp2config.skprx</code> from <code>sd0:</code> (not present in any production device or devkits) or <code>ux0:</code>. However, the files must still be signed and encrypted SELFs. In "manufacturing mode" with the default boot config, if <code>sd0:psp2diag.self</code> or <code>ux0:psp2diag.self</code> exists (and are valid signed & encrypted SELFs), then it will be launched. If "development mode" is enabled (note that this does not necessarily mean PDEL or devkit), then <code>psp2config.skprx</code> can be a plaintext file instead.
+
If "Producting Mode" (MANUFACTURING_MODE) is enabled, then it is possible to load <code>psp2config.skprx</code> from <code>sd0:</code> (SD adapter in GameCard slot) or <code>ux0:</code>. However, the files must still be signed and encrypted SELFs. In "Producting Mode" if <code>sd0:psp2diag.self</code> or <code>ux0:psp2diag.self</code> exists (and is a valid signed & encrypted SELF), then it will be launched. If "Development Mode" (DEVELOPMENT_MODE) is enabled (note that this does not necessarily mean PDEL or devkit), then <code>psp2config.skprx</code> can be a plaintext file instead.
  
 
=== Comments ===
 
=== Comments ===
Line 75: Line 125:
 
#
 
#
 
</pre>
 
</pre>
 +
 
=== Conditionals ===
 
=== Conditionals ===
 +
 
Conditionals start with <code>if</code> and end with <code>endif</code>. There are certain conditional constants defined in SceSysStateMgr. A table of known conditionals is below.
 
Conditionals start with <code>if</code> and end with <code>endif</code>. There are certain conditional constants defined in SceSysStateMgr. A table of known conditionals is below.
 
{| class="wikitable"
 
{| class="wikitable"
−
|-
 
 
! Name
 
! Name
 
! Description
 
! Description
Line 92: Line 143:
 
|-
 
|-
 
| USB_ENUM_WAKEUP
 
| USB_ENUM_WAKEUP
−
| Unknown. Could be [[CMA]] connection while device is turned off.
+
| Unknown. Could be [[CMA]] connection while device is turned off or IDU mode USB boot.
 
|-
 
|-
 
| KERMIT_REV_ES1_X
 
| KERMIT_REV_ES1_X
−
| Unknown. Hardware revision related.
+
| Unknown. GPU hardware revision related.
 
|-
 
|-
 
| KERMIT_REV_ES2_X
 
| KERMIT_REV_ES2_X
−
| Unknown. Hardware revision related.
+
| Unknown. GPU hardware revision related.
 
|-
 
|-
 
| KERMIT_REV_ES3_X
 
| KERMIT_REV_ES3_X
−
| Unknown. Hardware revision related.
+
| Unknown. GPU hardware revision related.
 
|-
 
|-
 
| KERMIT_REV_ES4_X
 
| KERMIT_REV_ES4_X
−
| Unknown. Hardware revision related.
+
| Unknown. GPU hardware revision related.
 +
|-
 +
| KERMIT15_REV_ES1_X
 +
| Unknown.
 +
|-
 +
| KERMIT10_REV_ES4_X
 +
| Unknown.
 
|-
 
|-
 
| UD0_EXIST
 
| UD0_EXIST
Line 110: Line 167:
 
|-
 
|-
 
| DEMO_MODE
 
| DEMO_MODE
−
| Is the Vita a [[Flags|IDU flagged]]?
+
| Is the Vita a [[Flags|IDU/ShowMode flagged]]?
 
|-
 
|-
 
| SAFE_MODE
 
| SAFE_MODE
−
| A flag from in sysroot buffer indicates device should enter safe mode.
+
| A flag in sysroot buffer indicates device should enter safe mode.
 
|-
 
|-
 
| DEVELOPMENT_MODE
 
| DEVELOPMENT_MODE
−
| [[SceSblACMgr]] is called to check if device is a development device.
+
| [[SceSblACMgr]] is called to check if device is a development device and is in DevMode.
 
|}
 
|}
  
Line 136: Line 193:
 
load os0:kd/ngs.skprx
 
load os0:kd/ngs.skprx
 
</pre>
 
</pre>
 +
 
=== Spawn ===
 
=== Spawn ===
 
<code>spawn path</code> will spawn an app and continue processing the script in the background.
 
<code>spawn path</code> will spawn an app and continue processing the script in the background.
Line 141: Line 199:
 
<code>spawnwait path</code> will spawn an app and wait for it to exit before continuing processing the script.
 
<code>spawnwait path</code> will spawn an app and wait for it to exit before continuing processing the script.
  
−
<code>appspawn path param</code> is used to spawn <code>vs0:vsh/shell/shell.self</code>. Specify a paramater to pass.
+
<code>appspawn path param</code> is used to spawn the app self located at <code>path</code> with the parameter <code>param</code>.
  
  
Line 151: Line 209:
 
|-
 
|-
 
| SHELL_BUDGET_ID
 
| SHELL_BUDGET_ID
−
| Unknown.
+
| Unknown. Example modules: <code>vs0:vsh/shell/shell.self</code> and <code>vs0:vsh/shell/shell_mini.self</code>
 +
|-
 +
| GAME_BUDGET_ID
 +
| Unknown. Example module: <code>vs0:vsh/shell/shell_gamebudget.self</code>
 
|}
 
|}
  
Line 173: Line 234:
 
include ur0:temp/bcfg2.txt
 
include ur0:temp/bcfg2.txt
 
</pre>
 
</pre>
 +
 
=== End ===
 
=== End ===
 
<code>end</code> will end script processing
 
<code>end</code> will end script processing
Line 178: Line 240:
 
=== Ignore Error ===
 
=== Ignore Error ===
 
Any line that starts with <code>- </code> will not fail the boot sequence if the line fails. For example, you can specify an optional module to load such that boot continues if the module does not exist or errors on load.
 
Any line that starts with <code>- </code> will not fail the boot sequence if the line fails. For example, you can specify an optional module to load such that boot continues if the module does not exist or errors on load.
 +
 +
=== All codes (from 0.990) ===
 +
load, unload, loadonly, start, stop, unloadonly, spawn, spawnwait, wait, kill, loadconfig, ifmodel, ifnmodel, setenv, setmodfile, repeat, endrepeat, appspawn, tload
 +
 +
+ include, if, endif, end
  
 
== Boot Debug Checkpoint Codes ==
 
== Boot Debug Checkpoint Codes ==
Line 190: Line 257:
  
 
{| class="wikitable"
 
{| class="wikitable"
−
|-
 
 
! Code
 
! Code
 
! Location
 
! Location
Line 338: Line 404:
 
== Suspend and Resume ==
 
== 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 loader. After secure kernel loads, instead of decompressing and jumping to the non-secure kernel loader, it restores the saved context and returns to the kernel resume code.
+
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 [[Suspend]].
 
See [[Suspend]].
 +
  
 
[[Category:Startup]]
 
[[Category:Startup]]
 
[[Category:Loaders]]
 
[[Category:Loaders]]
 
[[Category:Kernel]]
 
[[Category:Kernel]]

Revision as of 22:38, 4 March 2019

The Vita main application processor is a Cortex A9 MPcore. It implements ARM TrustZone for execution in both a non-secure world and a sandboxed Secure World.

Boot Process

Boot ROM

It is likely that the F00D processor (MeP Core) is the actual secure boot device rather than the ARM CPU. The F00D processor is Toshiba MEP based and is the first secure device ("first loader") to start on the Vita. Once it starts it likely maps the eMMC and directly reads in the second_loader.enp or second_loader.enp_ from the eMMC slb2 partition. This is in the native load format of the F00D bootrom. There are likely 2 layers of encryption. First it decrypts the per-console layer that was added during the install. After that it will decrypt the factory-encrypted layer then begin execution.

The second_loader is primarily responsible for preparing the ARM processor. It initializes DRAM and decrypts slb2 kernel_boot_loader.self 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 world kernel bootloader and secure kernel, as well as the non-secure kernel boot loader. At this point the slb2 kprx_auth_sm.self and prog_rvk.srvk are both loaded into DRAM.

Finally, the second_loader resets itself with a pointer to the secure_kernel.enp or enp_. F00D processor then restarts and loads the secure_kernel.enp in and again decrypts the per-console layer that was added by the install, and the factory layer. At this point the F00D processor secure kernel is prepared and it resets the ARM CPU at 0x00000000 (F00D scratch buffer). This triggers the ARM secure boot process to begin.

Secure Kernel

The bootloader decompresses the ARZL secure kernel, loads it and sets up the VBAR and MVBAR. It then decompresses the ARZL non-secure kernel bootloader and sets NS in SCR and jumps into non-secure kernel bootloader. See Secure Bootloader for more information.

SceKblForKernel

The non-secure kernel bootloader contains an embedded and likely stripped version of SceSysmem, SceKernelModulemgr, SceSblSmschedProxy, and some other core drivers. The NS KBL sets up the eMMC device (again) and starts os0:psp2bootconfig.skprx.

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.

0.931 special case

On 0.931, NSKBL embeds the kernel modules list instead of using ScePsp2BootConfig. Here is the list: 

sysmem.skprx

excpmgr.skprx

intrmgr.skprx

systimer.skprx
acmgr.skprx
threadmgr.skprx
dmacmgr.skprx

ssproxy.skprx

smsc_proxy.skprx

authmgr.skprx

iofilemgr.skprx
modulemgr.skprx
processmgr.skprx

backtrace.skprx
sdbgsdio.skprx
deci4p_sdfmgr.skprx
deci4p_sttyp.skprx
deci4p_sdbgp.skprx
deci4p_sdrfp.skprx
stdio.skprx
lowio.skprx
clockgen.skprx
sdif.skprx
sdstor.skprx

fatsd.skprx
exfatfs.skprx

pamgr.skprx
sysstatemgr.skprx

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 os0:psp2config.skprx or os0:psp2config_vita.skprx or os0:psp2config_dolce.skprx and parses the System Configuration Script to load the remaining modules and finally either SceSafemode or SceShell or ScePsp2Swu or ScePsp2Diag.

Boot Partition

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

Name Earliest Known Version Comments
kernel_boot_loader.self 0.931 Secure KBL and ARZL compressed NS KBL
kprx_auth_sm.self 0.931 Used with F00D Processor to decrypt SELFs
prog_rvk.srvk 0.931 SCE encrypted SELF revocation list
second_loader.enp 0.931 Secure bootloader
second_loader.enp_ 0.931 Related to second_loader.enp in some way, likely for encryption
secure_kernel.enp 0.931 Secure kernel loader
secure_kernel.enp_ 0.931 Related to secure_kernel.enp in some way, likely for encryption
secure_kernel.xxx 0.931 Prototype secure kernel loader encrypted differently than secure_kernel.enc

System Configuration Script

os0:psp2config.skprx once decrypted is a UTF-8 text file that is parsed by SceSysStateMgr. It is a very simple script format.

If "Producting Mode" (MANUFACTURING_MODE) is enabled, then it is possible to load psp2config.skprx from sd0: (SD adapter in GameCard slot) or ux0:. However, the files must still be signed and encrypted SELFs. In "Producting Mode" if sd0:psp2diag.self or ux0:psp2diag.self exists (and is a valid signed & encrypted SELF), then it will be launched. If "Development Mode" (DEVELOPMENT_MODE) is enabled (note that this does not necessarily mean PDEL or devkit), then psp2config.skprx can be a plaintext file instead.

Comments

Comments start out with #, as an example, here's the header of 1.69 psp2config.skprx 

#
# PSP2 System Configuration for Release
#
# [NOTICE]
# 
# This configuration is only for kernel_boot_loader_release.self.
#

Conditionals

Conditionals start with if and end with endif. There are certain conditional constants defined in SceSysStateMgr. A table of known conditionals is below.

Name Description
MANUFACTURING_MODE Unknown. Depends on some condition set on boot by some bootloader
EXTERNAL_BOOT_MODE Unknown. Depends on some condition set on boot by some bootloader
UPDATE_MODE Set by Syscon when an update is about to be performed.
USB_ENUM_WAKEUP Unknown. Could be CMA connection while device is turned off or IDU mode USB boot.
KERMIT_REV_ES1_X Unknown. GPU hardware revision related.
KERMIT_REV_ES2_X Unknown. GPU hardware revision related.
KERMIT_REV_ES3_X Unknown. GPU hardware revision related.
KERMIT_REV_ES4_X Unknown. GPU hardware revision related.
KERMIT15_REV_ES1_X Unknown.
KERMIT10_REV_ES4_X Unknown.
UD0_EXIST Does the ud0: Partition exist?
DEMO_MODE Is the Vita a IDU/ShowMode flagged?
SAFE_MODE A flag in sysroot buffer indicates device should enter safe mode.
DEVELOPMENT_MODE SceSblACMgr is called to check if device is a development device and is in DevMode.

Example: 

if SAFE_MODE
spawn	os0:ue/safemode.self
end
endif

Load

load path will load the kernel module at path.

tload path possibly stands for "test load." Possibly used in development units to load to module to dedicated devkit RAM.

Example: 

load	os0:kd/ngs.skprx

Spawn

spawn path will spawn an app and continue processing the script in the background.

spawnwait path will spawn an app and wait for it to exit before continuing processing the script.

appspawn path param is used to spawn the app self located at path with the parameter param.


Known param constants:

Name Description
SHELL_BUDGET_ID Unknown. Example modules: vs0:vsh/shell/shell.self and vs0:vsh/shell/shell_mini.self
GAME_BUDGET_ID Unknown. Example module: vs0:vsh/shell/shell_gamebudget.self

Example: 

if UPDATE_MODE
if UD0_EXIST
spawn ud0:PSP2UPDATE/psp2swu.self
else
spawn ur0:PSP2UPDATE/psp2swu.self
endif
end
endif

Include

include path will include and process a config script located at path.

Example: 

include	ur0:temp/bcfg2.txt

End

end will end script processing

Ignore Error

Any line that starts with - will not fail the boot sequence if the line fails. For example, you can specify an optional module to load such that boot continues if the module does not exist or errors on load.

All codes (from 0.990)

load, unload, loadonly, start, stop, unloadonly, spawn, spawnwait, wait, kill, loadconfig, ifmodel, ifnmodel, setenv, setmodfile, repeat, endrepeat, appspawn, tload

+ include, if, endif, end

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.

GPIO

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

Known Codes

Code Location Description
72 ? ?
84 ? ?
85 ? ?
86 ? ?
96 ? ?
129 Secure Kernel Loader Core 0 (secure world) pre-init complete
130 Secure Kernel Loader Secure world interrupts registered (?)
131 Secure Kernel Loader Serial console ready, boot message printed
132 Secure Kernel Loader Some device init
133 Secure Kernel Loader Some co-processor init. Starting point for other cores.
134 Secure Kernel Loader MMU enabled, VBAR/MVBAR set up
135 Secure Kernel Loader Nothing since 134
136 Secure Kernel Loader Boot setup complete, secure kernel loading begin
137 Secure Kernel Loader Secure kernel loaded. About to load NS KBL at 0x51000000
138 Secure Kernel Loader Secure kernel loaded. About to resume context at 0x1F000000. Or undefined instruction exception.
139 Secure Kernel Loader SVC exception (should not happen, error)
140 Secure Kernel Loader Prefetch abort exception
141 Secure Kernel Loader Data abort exception
142 Secure Kernel Loader IRQ exception (should not happen, error)
143 Secure Kernel Loader FIQ exception (should not happen, error)
161 NS Kernel Loader Core 0 (non-secure world) pre-init complete
162 NS Kernel Loader Some interrupts registered (?)
163 NS Kernel Loader Serial console ready, boot message printed (if enabled)
164 NS Kernel Loader Some buffer is initialized to device addresses
165 NS Kernel Loader Some co-processor init. Starting point for other cores.
166 NS Kernel Loader MMU enabled, VBAR set up
167 NS Kernel Loader Nothing since 166
168 NS Kernel Loader Boot setup complete, NS kernel loading begin
169 NS Kernel Loader Kernel pre-init (setup stacks, interrupts, etc) done. Right before first external loading.
170 NS Kernel Loader Undefined instruction exception
171 NS Kernel Loader SVC exception (should not happen, error)
172 NS Kernel Loader Prefetch abort exception
173 NS Kernel Loader Data abort exception
174 NS Kernel Loader IRQ exception (should not happen, error)
175 NS Kernel Loader FIQ exception (should not happen, error)

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 Suspend.

Retrieved from "http://wiki.henkaku.xyz/vita/index.php?title=Boot_Sequence&oldid=11208"