Stage1: Difference between revisions

(2 intermediate revisions by the same user not shown)

Line 13:

## As a fallback, the console will try to boot from NVRAM. (On retail consoles, this always fails as NVRAM does not contain any bootcode.)

## If one boot method fails, the bootroms will continue trying with the next one.

# 0x200 bytes at offset 0x200 from the boot medium are read. This contains the [[Stage2|stage2 header]].

# 0x200 bytes at offset 0x200 from the boot medium are read. This contains the [[Stage2|stage2 header]]. (For gamecart boots, the offset is 0 instead.)

# The RSA signature of the stage2 header is verified, and the first two SHA1 hashes (of the rest of the stage2 header, and the hash of the RSA message itself) are verified.

# On failure, goto 10.

# On success, the ARM9 instructs the ARM7 to load and decrypt the stage2 ARM7 binary from the boot medium. DMA is used from the boot medium to the AES hardware, but the ~~outupt~~ of the AES accelerator is simply read by software.

# On success, the ARM9 instructs the ARM7 to load and decrypt the stage2 ARM7 binary from the boot medium. DMA is used from the boot medium to the AES hardware, but the output of the AES accelerator is simply read by software.

## Depending on the option bits in the stage2 header, this payload may be compressed.

## Uncompressed payloads are loaded into NWRAM on the ARM7 side, and then mapped to the ARM9 using the MBK registers.

Line 28:

## Prepare keys for the next bootstage (some in the AES hardware, others copied to WRAM or ITCM)

## The ARM7 will lock out both boot ROMs from the system memory bus using the SCFG registers. The ARM9 waits for this lockout to happen.

## Both cores, now synchronized using the lockout, will now jump to [[stage2]] code. (Current stage2 binaries will immediately re-synchronize the cores, however.

## Both cores, now synchronized using the lockout, will now jump to [[stage2]] code. (Current stage2 binaries will immediately re-synchronize the cores, however.)

Error codes are supposed to be interpreted as a 32-bit unsigned little-endian integer, the least significant byte describing the status of the ~~NVRAM~~ boot attempt, the next of the ~~NAND~~ boot attempt, and the third one describes the game cartridge boot attempt. The most significant byte is always 0.

Error codes are supposed to be interpreted as a 32-bit unsigned little-endian integer, the least significant byte describing the status of the NAND boot attempt, the next of the NVRAM boot attempt, and the third one describes the game cartridge boot attempt. The most significant byte is always 0.

The individual bytes carry the following meaning:

Line 36:

* FE: stage2 header verification failed.

* FD: stage2 ARM7 binary verification failed.

* FC: ~~stage3~~ ARM9 binary verification failed.

* FC: stage2 ARM9 binary verification failed.

The boot ROM does not use any other error codes.

Line 44:

! Error Code !! Description

|-

| 0000FE00 || Error communicating with NAND chip (it's missing, CLK is shorted, etc.), or the most significant bit of the byte at 0x2ff of [NVRAM] has been cleared.

| 00FxFExx || Failed to run ntrboot exploit.

|-

| 0000FE00 || Error communicating with NAND chip (it's missing, CLK is shorted, etc.), or the most significant bit of the byte at 0x2ff of [[NVRAM]] has been cleared. (If you have a modchip installed, it could also mean the modchip exploit failed.)

|-

| 0000FEFC || Integrity error in ARM9 info block of Stage 2 (address at 0x220)

Line 50:

Line 52:

| 0000FEFD || Integrity error in ARM7 info block of Stage 2 (address at 0x230)

|-

| 0000FEFE || Integrity error in the stage2 header (or error in [[NVRAM]] ~~contents~~).

| 0000FEFE || Integrity error in the stage2 header (or error in [[NVRAM]] header: first 40 bytes must have a specific value).

|}

@@ Line 13: / Line 13: @@
 ## As a fallback, the console will try to boot from NVRAM. (On retail consoles, this always fails as NVRAM does not contain any bootcode.)
 ## If one boot method fails, the bootroms will continue trying with the next one.
-# 0x200 bytes at offset 0x200 from the boot medium are read. This contains the [[Stage2|stage2 header]].
+# 0x200 bytes at offset 0x200 from the boot medium are read. This contains the [[Stage2|stage2 header]]. (For gamecart boots, the offset is 0 instead.)
 # The RSA signature of the stage2 header is verified, and the first two SHA1 hashes (of the rest of the stage2 header, and the hash of the RSA message itself) are verified.
 # On failure, goto 10.
-# On success, the ARM9 instructs the ARM7 to load and decrypt the stage2 ARM7 binary from the boot medium. DMA is used from the boot medium to the AES hardware, but the outupt of the AES accelerator is simply read by software.
+# On success, the ARM9 instructs the ARM7 to load and decrypt the stage2 ARM7 binary from the boot medium. DMA is used from the boot medium to the AES hardware, but the output of the AES accelerator is simply read by software.
 ## Depending on the option bits in the stage2 header, this payload may be compressed.
 ## Uncompressed payloads are loaded into NWRAM on the ARM7 side, and then mapped to the ARM9 using the MBK registers.
@@ Line 28: / Line 28: @@
 ## Prepare keys for the next bootstage (some in the AES hardware, others copied to WRAM or ITCM)
 ## The ARM7 will lock out both boot ROMs from the system memory bus using the SCFG registers. The ARM9 waits for this lockout to happen.
-## Both cores, now synchronized using the lockout, will now jump to [[stage2]] code. (Current stage2 binaries will immediately re-synchronize the cores, however.
+## Both cores, now synchronized using the lockout, will now jump to [[stage2]] code. (Current stage2 binaries will immediately re-synchronize the cores, however.)
-Error codes are supposed to be interpreted as a 32-bit unsigned little-endian integer, the least significant byte describing the status of the NVRAM boot attempt, the next of the NAND boot attempt, and the third one describes the game cartridge boot attempt. The most significant byte is always 0.
+Error codes are supposed to be interpreted as a 32-bit unsigned little-endian integer, the least significant byte describing the status of the NAND boot attempt, the next of the NVRAM boot attempt, and the third one describes the game cartridge boot attempt. The most significant byte is always 0.
 The individual bytes carry the following meaning:
@@ Line 36: / Line 36: @@
 * FE: stage2 header verification failed.
 * FD: stage2 ARM7 binary verification failed.
-* FC: stage3 ARM9 binary verification failed.
+* FC: stage2 ARM9 binary verification failed.
 The boot ROM does not use any other error codes.
@@ Line 44: / Line 44: @@
 ! Error Code  !!  Description
 |-
-| 0000FE00 || Error communicating with NAND chip (it's missing, CLK is shorted, etc.), or the most significant bit of the byte at 0x2ff of [NVRAM] has been cleared.
+| 00FxFExx || Failed to run ntrboot exploit.
+|-
+| 0000FE00 || Error communicating with NAND chip (it's missing, CLK is shorted, etc.), or the most significant bit of the byte at 0x2ff of [[NVRAM]] has been cleared. (If you have a modchip installed, it could also mean the modchip exploit failed.)
 |-
 | 0000FEFC || Integrity error in ARM9 info block of Stage 2 (address at 0x220)
@@ Line 50: / Line 52: @@
 | 0000FEFD || Integrity error in ARM7 info block of Stage 2 (address at 0x230)
 |-
-| 0000FEFE || Integrity error in the stage2 header (or error in [[NVRAM]] contents).
+| 0000FEFE || Integrity error in the stage2 header (or error in [[NVRAM]] header: first 40 bytes must have a specific value).
 |}