Boot Process: Difference between revisions

From Xenon Wiki
Jump to navigation Jump to search
imported>TEIR1plus2
(Created page with "This article describes the boot sequence of the PowerPC G5 starting a Xenon kernel and OS. == Overview == The PowerPC G5 has a ROM containing the openfirmware (OF) bios, as w...")
Line 1: Line 1:
This page details the boot process used in the Xbox 360. The process is slightly different between Devkit/Retail and certain boxes which have a secondary CB loader (trinity/some jaspers)
This article describes the boot sequence of the PowerPC G5 starting a Xenon kernel and OS.
== Overview ==


=Retail=
The PowerPC G5 has a ROM containing the openfirmware (OF) bios, as well as a NVRAM containing variables used by the openfirmware to find bootable partitions or bootloaders like yaBoot or BootX(MacOSX). Its the task of openfirmware (OF) to find and start the os.
In Summary:
* Slim: 1BL -> CB_A -> CB_B -> CD -> CF -> CD -> HV -> Kernel -> Dashboard
* Phat (older): 1BL -> CB -> CD -> CF -> CD -> HV -> Kernel -> Dashboard
* Phat (newer): 1BL -> CB_A -> CB_B -> CD -> CF -> CD -> HV -> Kernel -> Dashboard
==1BL (Inside CPU)==
Loads and decrypts CB(_A) into ram, it computes a RotSumSha1 of CB(_A) and uses it to verify its RSA signature. If the signature is valid, 1BL jumps to CB(_A).


You can find reversed pseudocode of the 1bl here: [[1bl Code]]
The basics are:
* After CPU reset vector and cpu initialization the boot ROM stored in NVRAM provides power on self test (POST - diagnostics), and initializes enough of the system to load Open Firmware. When enough initialization has occurred to execute Open Firmware, the boot chime is played and Open Firmware is loaded.
* OpenFirmware (Init) will then probe the system's I/O buses to determine the device configuration and build a device tree.. the system will then examine the values of its enviroment variables. If the auto-boot? variable is flagged as true, the system will then read the value... and attempt to boot from that device. If additional information is required the boot-file variable is read. If the auto-boot? variable is flagged as false, the system will halt the boot process and drop to the Open Firmware user interface.
* Default Boot Device on Apple systems is "hd:,\\:tbxi". ("tbxi", tells the system to look for files of type tbxi. )
* the tbxi (bootfile) is started and from here on we follow the "Xenon" bootpath instead of the MacOSX.


==CB==
=== Xenon boot from OF ===  
'''SLIMS ONLY''': CB_A loads and decrypts CB_B into ram, it computes a RotSumSha1 of CB_B and checks it against the known hash. If it matches CB_A jumps to CB_B.
In case of the Xenon Alpha, we found that a special Partition called [[XeBoot]] is at the beginning of the harddrive. This contains either or what we asume 2 files, a bootx file (like MacOSX, containing a configuration script) and a xboxroma.bin file, wich is a (stripped ?) ELF file like the MacOSx kernel. This "rom" file will start looking for the Xenon OS kernel on various devices and start it.
[[citation needed]]
Known location the xboxroma.bin is looking:
* \Device\Cdrom0\*
* \Device\Harddisk0\Partition1\xboxroma.bin
* \Device\Harddisk0\Partition1\xboxrom_update.bin
* \Device\Harddisk0\Partition3\ROM\0000\xboxroma_1mb.bin
(NT/WINworld notation) [[citation needed]](is this realy the rom, or kernel that does check if its running the latest kernel?)


CB(_B) starts up a virtual machine, which does:
When the latest kernel is found and started it will locate its Dashboard or XShell files and optionaly if found, start the XBDM.dll (named XBDM.XEX)
<pre>
- initializes the PCI Bridge
- disables the GPU PCIE JTAG test port
- initializes the serial port
- talks to the SMC to clear the "handshake" bit
- initializes memory
- generates RROD if memory init fails
</pre>
CB(_B) loads and decrypts CD into ram, it computes a RotSumSha1 of CD and checks it against the known hash. If it matches CB(_B) jumps to CD.


Methods to dump the CB bootloaders and examples of them reversed can be found here: [[CB Code]]
== Extra information ==
* OF will automatically convert "hd" into the appropriate device path, as hd is simply an alias. The notation "\\" tells the system to start searching for "blessed" folders (directories) starting on the first HFS or HFS+ partition found on the system.


==CD==
* All versions of MacOS have a folder known as System Folder that is "blessed", and contains a MacOS Boot ROM file which is of type tbxi. The Boot ROM file is simply a stripped ELF executable image wrapped with a forth boot script.  
Loads and decrypts CE into ram, computes a RotSumSha1 of CE. If it matches the known hash, it decompresses the LZX compressed base kernel.<br/>
It then checks for patch slots. If it finds one, it will load and decrypt the corresponding CF bootloader for that patch. It then computes a RotSumSha1 of CF and uses it to verify the CF loaders signature. If the signature is valid, CD stays in memory but jumps to CF.


There can be up to 2 CF/CG pairs for patching the kernel.
* A "blessed" folder is simply one with a special attribute (or flag) set on it. The system will search all HFS partitions for a bblessed folder and a file of type tbxi within it, if none are located, the boot will fail. The system will always select the first one found, unless the boot-device is modified to a specific partition id.


==CF==
"tbxi", tells the system to look for files of type tbxi.
Loads CG into memory by reading the CG data in the NAND header and then reads the rest of the CG data from the CG blocks specified in CF header. It then decrypts the CG in memory using the key generated from decrypting CF. To verify it, it computes a RotSumSha1 and checks it against the known hash. If it matches, it uses LZX delta decompress to apply the patch to the base kernel in memory. Once its done, it jumps back to CD and once CD has finished up, it jumps to the reset vector in the [[Hypervisor]].


=Devkit=
== Openfirmware ==
In Summary:
To get into openfirmware, press Command (⌘) + Option (⌥) + O + F [[citation needed]]
* Phat: 1BL -> SB -> SC -> SD -> HV -> Kernel -> Dashboard


The devkit bootloaders are nearly identical to their retail counterparts; however instead of hardcoded hash checks, devkits verify bootloaders SD and SE by signature checks.
=== commands in openfirmware ===
The following commands work in the openfirmware used in the Apple G5 version known to boot Xbox software
[[citation needed]] (Please check commands on real Mac and add missing helpfull commands)
{| class="wikitable"
|-
! Command !! Explaination
|-
| Boot [option] || boot the device stored in nvram variable boot or boot the given option [[citation needed]]
|-
| ls || list the current device list (handy to find if a device is found by OF and its partitions are listed) [[citation needed]]
|-
| devalias || list all current known aliasses for devices [[citation needed]]
|}


The SC bootloader is the hardware initialization virtual machine run by SB.
=== Reverting OF into MacOSX bootable state ===
try booting macos from OF by typing:
<pre>mac-boot</pre>[[citation needed]]
If this fails, try checking if the bootdevice is actualy set by typing:
<pre>nvram boot-device</pre>[[citation needed]]


Because devkits do not update over the air, they use a pre-patched SE (HV + kernel) bootloader) without delta patching CF/CG pairs.


=Kernel=
Asuming the Harddisk containing MacOSX is reinserted and NVram or Openfirmware is not able to boot macosx, try:
<pre>setenv auto-boot true</pre>[[citation needed]]


Once control is handed off to the kernel, as denoted by the [[POST]] output, the kernel does the following (on development systems):


<ol>
* Initialize memory manager
* Initialize stack(s)
* Initialize object system (?)
* Initialize phase 1 thread (?)
* Phase 1 initialization and processors initialization
* Initialize keyvault
* Initialize HAL [https://en.wikipedia.org/wiki/HAL_(software)] phase 1
* Initialize SFC driver (?)
* Initialize security (?)
* INIT_KEY_EX_VAULT
* Initialize settings (?)
* Initialize power mode
* Initialize video driver
* Initialize audio driver
* Initialize boot animation
** Loads bootanim.xex
* Initialize SATA driver
* Initialize [[Shadowboot]] (not on retail systems)
* INIT_DUMP_SYSTEM (?) (not on retail systems)
* INIT_SYSTEM_ROOT (?)
* Initialize other drivers
* Initialize [[STFS]] driver
* Initialize XAM
</ol>


==Core OS Executables==
== Resourses ==
* [https://openfirmware.info/Welcome_to_OpenBIOS] Opensource website used by the openfirmware on the apple G5
* [https://books.google.nl/books?id=K8vUkpOXhN4C&pg=PA344&lpg=PA344&dq=macosx+bootdevice+OF&source=bl&ots=OMkhRYYw-C&sig=cATnoVTg7ShRia8tvxZr4y_cy6o&hl=nl&sa=X&ved=2ahUKEwi24oel7rLcAhUJM-wKHe9EBKQQ6AEwDnoECAQQAQ#v=onepage&q=macosx%20bootdevice%20OF&f=false] Mac OS X Internals: A Systems Approach (paperback)
* [http://mac.linux.be/content/guide-open-firmware-apple-bios-0] Guide to openfirmware on the Apple


After its initialization sequence, the kernel loads the following executables (in order)


<ul>
[[Category:Xbox 360 System Software]]
* xam.xex
* xbdm.xex
* xstudio.xex
* ximecore.xex
* Xam.Community.xex (from disk)
* huduiskin.xex
* xshell.xex (devkits) / dash.xex (retail)
</ul>
 
It then unloads the following:
 
<ul>
*huduiskin.xex
* bootanim.xex
</ul>
 
By this time the console will have booted into the dashboard
 
 
[[Category:Xbox360 System Software]]

Revision as of 19:37, 9 December 2018

This article describes the boot sequence of the PowerPC G5 starting a Xenon kernel and OS.

Overview

The PowerPC G5 has a ROM containing the openfirmware (OF) bios, as well as a NVRAM containing variables used by the openfirmware to find bootable partitions or bootloaders like yaBoot or BootX(MacOSX). Its the task of openfirmware (OF) to find and start the os.

The basics are:

  • After CPU reset vector and cpu initialization the boot ROM stored in NVRAM provides power on self test (POST - diagnostics), and initializes enough of the system to load Open Firmware. When enough initialization has occurred to execute Open Firmware, the boot chime is played and Open Firmware is loaded.
  • OpenFirmware (Init) will then probe the system's I/O buses to determine the device configuration and build a device tree.. the system will then examine the values of its enviroment variables. If the auto-boot? variable is flagged as true, the system will then read the value... and attempt to boot from that device. If additional information is required the boot-file variable is read. If the auto-boot? variable is flagged as false, the system will halt the boot process and drop to the Open Firmware user interface.
  • Default Boot Device on Apple systems is "hd:,\\:tbxi". ("tbxi", tells the system to look for files of type tbxi. )
  • the tbxi (bootfile) is started and from here on we follow the "Xenon" bootpath instead of the MacOSX.

Xenon boot from OF

In case of the Xenon Alpha, we found that a special Partition called XeBoot is at the beginning of the harddrive. This contains either or what we asume 2 files, a bootx file (like MacOSX, containing a configuration script) and a xboxroma.bin file, wich is a (stripped ?) ELF file like the MacOSx kernel. This "rom" file will start looking for the Xenon OS kernel on various devices and start it. citation needed Known location the xboxroma.bin is looking:

  • \Device\Cdrom0\*
  • \Device\Harddisk0\Partition1\xboxroma.bin
  • \Device\Harddisk0\Partition1\xboxrom_update.bin
  • \Device\Harddisk0\Partition3\ROM\0000\xboxroma_1mb.bin

(NT/WINworld notation) citation needed(is this realy the rom, or kernel that does check if its running the latest kernel?)

When the latest kernel is found and started it will locate its Dashboard or XShell files and optionaly if found, start the XBDM.dll (named XBDM.XEX)

Extra information

  • OF will automatically convert "hd" into the appropriate device path, as hd is simply an alias. The notation "\\" tells the system to start searching for "blessed" folders (directories) starting on the first HFS or HFS+ partition found on the system.
  • All versions of MacOS have a folder known as System Folder that is "blessed", and contains a MacOS Boot ROM file which is of type tbxi. The Boot ROM file is simply a stripped ELF executable image wrapped with a forth boot script.
  • A "blessed" folder is simply one with a special attribute (or flag) set on it. The system will search all HFS partitions for a bblessed folder and a file of type tbxi within it, if none are located, the boot will fail. The system will always select the first one found, unless the boot-device is modified to a specific partition id.


"tbxi", tells the system to look for files of type tbxi.

Openfirmware

To get into openfirmware, press Command (⌘) + Option (⌥) + O + F citation needed

commands in openfirmware

The following commands work in the openfirmware used in the Apple G5 version known to boot Xbox software 

citation needed (Please check commands on real Mac and add missing helpfull commands)
Command Explaination
Boot [option] boot the device stored in nvram variable boot or boot the given option citation needed
ls list the current device list (handy to find if a device is found by OF and its partitions are listed) citation needed
devalias list all current known aliasses for devices citation needed

Reverting OF into MacOSX bootable state

try booting macos from OF by typing: 

mac-boot

citation needed

If this fails, try checking if the bootdevice is actualy set by typing: 

nvram boot-device

citation needed


Asuming the Harddisk containing MacOSX is reinserted and NVram or Openfirmware is not able to boot macosx, try: 

setenv auto-boot true

citation needed


Resourses

  • [1] Opensource website used by the openfirmware on the apple G5
  • [2] Mac OS X Internals: A Systems Approach (paperback)
  • [3] Guide to openfirmware on the Apple
Retrieved from "https://www.xenonwiki.com/index.php?title=Boot_Process&oldid=274"