Bachiller

This is a collection of notes which should help anyone looking at the PS2 BIOS. The goal is to fully document the public interface so that a free (GPL) replacement BIOS can be developed for use in emulators such as PCSX2. Where source code examples are given, these refer to the fps2bios source code and not to any original Sony code. The information contained in here has been collected from anumber of sources but the main sources are the PCSX2 source code which documents the machine hardware and the open source ps2sdk found at ps2dev.org.

The PS2 BIOS is a collection of files packed into a single file. A file called ROMDIR contains the name and size of each file in the archive. The first file in the archive is called RESET and contains a minimal boot program. The ROMDIR structure isfound by looking for the character sequence RESET from the start of the BIOS

The boot process

The BIOS file is initialized to the memory address 0xBFC00000. The program counter is set to this address and execution started. This is true for both the EE and IOP and so the first few lines of code need to figure out which CPU is currently executing and branch to the relevant initialization code.This code is contained in kernel/start.c. The files kernel/eestart.c and kernel/iopstart.c contain the boot code for the EE and IOP respectively

The IOP boot process

The IOP boot code is stored in kernel/iopstart.c. This locates the file IOPLOAD in the BIOS image and loads it to the memory address 0x80000000. It then executes the code at 0x80001000. The directory kernel/iopload contains allof the IOP releated BIOS code. Note the linkfile in this directory – this is required to enforce the magic numbers described above. It makes sure that the iopirq.o object is linked at the address 0x80000000 and that iopload is linked starting at 0x80001000.

The boot code found at 0x80001000 is _start() located in iopload.c. This loads the SYSMEM file from the BIOS image and executes its definedentry point. The LOADCORE file is then loaded and its entry point executed. When the LOADCORE entry point returns, the IOP enters an endless loop waiting for an exception.

IRX linking

The LOADCORE module is responsible mainly for managing the dynamic link relationship between IRX modules. An IRX module is a dynamically linked module – it both exports and imports functions in addition tohaving an execution entry point. IRX dynamic linking is ordinal based rather than symbolic and, as the public interface is defined by the function export table, this makes figuring it out quite complex. Fortunately, some games have been distributed with debugging symbols and thus this allows us to associate symbolic names with the export ordinals.

The IRX export table is defined as follows:struct irx_export_table {
u32 magic;
struct irx_export_table *next;
u16 version;
u16 mode;
u8 name[8];
void *fptrs[0];
};

Where magic is 0x41c00000 and fptrs is a list of exported functions terminated by a NULL entry.

The IRX import table definition is very similar.

struct irx_import_table
{
u32 magic;
struct irx_import_table *next;
u16 version;
u16 mode;
char name[8];void *stubs[0];
}

The magic number for the import table is 0x41e00000 and in the same manner as the export table, the stubs list is NULL terminated. An IRX will contain an import table for each module (IRX) that it needs to link with.

To give a concrete example, an IRX that wants to import the GetLibraryEntryTable function from the LOADCORE module, could define the import table asfollows:

loadcore_stub:
.word 0x41e00000
.word 0
.word 0x00000101
.ascii "loadcore"
.align 2

.globl GetLibraryEntryTable # 0x03
GetLibraryEntryTable:
j $31
li $0, 3

.word 0
.word 0

The label GetLibraryEntryTable does not define the linkage itself – this is done by the number (or ordinal) 3. The li $0, 3 instruction defines that this entry should be linked to the...