Editing Talk:Boot Order

===SPI traces/testpoints===
Does anybody have a picture of the SPI trace locations or even testpoints for them?

===PS3 Bootsequence:===

Power on : syscon boots from it's internal (non-encrypted / dual banked) ROM *1 *2
     + syscon powers up and configures Cell
     + syscon pulls the reset of Cell high -> Cell INIT
Cell INIT: CELL boots from it's internal ROM *2
     + Initialises RAM
     + fetches bootldr off NAND/NOR flash
     + loads bootldr into Isolated SPU (SPE0)
     + bootldr decrypts lv0 which runs on PPU -> loaders INIT
loaders INIT: lv0 loads metldr (SPE2)
     + passes lv1ldr (which loads lv1) to metldr
     + passes lv2ldr (which loads lv2) to metldr
     + passes appldr (which loads vsh) to metldr
     + passes isoldr (which loads *.iso_spu_module) to metldr
     + passes rvkldr (which loads rvkprg / rvklist) to metldr

*1) Read/Writeable with undocumented / should also be read/writeable through serial port and possible to switch it to the backup bank1 with backup_mode pulled high
*2) CEX/Retail consoles go to standby with red light. SEX/SHOP/SECH will not standby, but instead boot through without waiting for powerbutton. Also check is done on all models if update is flagged to set it into firmware updating procedure
*3) Partialy Read/Writeable
about the disabled SPE: syscon reads it’s internal (non-encrypted) eeprom @ 0x48C30 which is value 0×06 on all CEX/Retail consoles and will set the cell config ring accordingly for 7 SPE’s. SPE0 and SPE2 are reserved for bootldr and metldr for isolation respectively. Setting the value to a nonworking state (e.g. 0×00, 0xFF, enabling a defective SPE or disabling a needed SPE for proper boot) might brick the console, locking you out from restoring the correct value to the syscon eeprom.

==asecure loader==
How do isolated loaders work? Asecure_loaders in specific (metldr)? Well, metldr is a raw binary, not an ELF, and here are the segments of it I have figured out at least:

<pre>
 Name                   Start    End
 .local_storage_cleanup 00000400 00000860
 .text                  00000860 0000CB70
 .rodata                0000CB70 0000FCD0
 .data                  0000FCD0 0003E400
 .ram                   0003E400 00040000
</pre>

The entrypoint of metldr is at 0×400, and in essence it just does the following:
<pre>
    ULONG *pStart = (ULONG*)&start;
    (pStart)();
</pre>

The start routine prepares the DMA buffer, and essentially is crt0.c, branches to main, then exits. The main routine prepares the global isolated loader constructor (yes, this is C++ code), then branches to loader_start, which sets up the mailbox for recieving mail, and then loads the actual isolated module, after this, it sends back the mail twice, once normally, second with an interrupt. The actual loader decryption subroutine (load_isolated_loader) sets the prepares the SELF for decryption, verifies the header, then gets the program information headers, then verifies each segment. The code for verifying the header essentially sets up a buffer and then calls verify_header. Then metldr loads its AES decryption key, IV, ECDSA public key and curve type then calls verify_header again. Verify_header sets up the buffer manager, and eventually calls verify_signature after running aes_ctr and aes_decrypt. Verify_signature loads the digest, and performs the SHA1 hash checks. Then we verify the signature by using ECDSA signature algorithms. Verify_self_segment loads the elf segment after several buffers are initialized, then the necessary program structures needed for loader initialization are created then control is passed to the cleanup subroutine. This routine essentially zeroes out every register except $r3 (yes, $SP, $LR, $r0-r2, $r4-r127), and branches to the address in $r3. Ta-da! We have successfully decrypted a binary.

Source: http://rmscrypt.wordpress.com/2011/05/08/long-hiatus/

== What type of encryption? ==

The Boot Order table lists whether the various loaders and levels are encrypted, but doesn't say what type of encryption. Is this generally AES256?