Initializing the PlayStation 2 from cold boot

As promised, I would do a write-up to share about how the PS2 is to be initialized, from within an memory-card update program.

However, I am still reverse-engineering and updating my code from FMCB, so that they'll be more usable for external projects... so I don't really have any code to show at the moment I am writing this. Over time, I will make new posts to elaborate on things that I don't elabore here.
I have decided to consoliate the OSD init stuff into a new library, named libosdinit. It may make things easier for new software to work with the OSD configuration.

Although we have various samples floating around the Internet in the form of the FreeVast and FMCB v1.7 source code, I found that FMCB v1.8 did not quite have an accurate method of initializing the PS2.

I won't get into the basics of initializing SIFRPC/SIFCMD services, as those are the basics required for each project.

Things that need to be done:

• Initialize SIFCMD/SIFRPC.
• Reboot the IOP.
  • While homebrew software generally use the ROM modules and things may work without this step, it does not result in uniform behaviour across all console models. Depending on the ROM version, most PlayStation 2 consoles have the modules listed in rom0:/EELOADCNF/IOPBTCONF loaded, when the update is loaded by EELOAD.
  • Not rebooting the IOP may offer non-uniform behaviour across all consoles, as modules like NCDVDMAN are crippled.
    
  • Hence it is better to reboot the IOP with no argument (empty string), to load the default IOP kernel modules instead.
• Initialize SIFRPC again after the IOP reboot completes.
• Initialize system paths with osdInitSystemPaths(), if it is desired to retrieve the system directory names from libosdinit.
  
• Perform boot certification to unlock the CD/DVD drive. Boot certification is done with the content of rom0:ROMVER.
  • This may be to validate the binding between the MECHACON and the boot ROM.
  • Do not check for the result of this operation because early PlayStation 2 models do not support boot certification (only B-chassis and later support it).
  • I think this may not work on the DTL-H301xx consoles because they seem to have ROM v1.50, but boot certification within OSDSYS of these sets is hardcoded to boot certify with 1,10 as the version number... but we cannot quite cover all cases without additional bloat (and very few people use those sets).
  • ROMVER strings have this format: VVVVRTYYYYMMDD (i.e. 0160HC20020426 for v1.60, Asia, CEX, 2002/04/26).

Code:

int fd;
char romver[16], RomName[4];
 if((fd = open("rom0:ROMVER", O_RDONLY)) >= 0)
{
       read(fd, romver, sizeof(romver));
       close(fd);
       // E.g. 0160HC = 1,60,'H','C'
       RomName[0]=(romver[0]-'0')*10 + (romver[1]-'0');
       RomName[1]=(romver[2]-'0')*10 + (romver[3]-'0');
       RomName[2]=romver[4];
       RomName[3]=romver[5];

       sceCdBootCertify(RomName);
}

• This is optional because we are not Sony, but you can disable DVD Video playback here:

Code:

   do{
       sceCdForbidDVDP(&result);
   }while(result&8);

• While not done in the ROM OSD, the HDD Browser update applies the full OSD kernel patch (for SCPH-10000 & SCPH-15000) here.
  • This updates the SetOsdConfigParam, GetOsdConfigParam, SetOsdConfigParam2 and GetOsdConfigParam2 syscalls, as well as ExecPS2.
  • By updating the OSD syscalls, the kernel is also marked as fully patched.
  • This is probably only done by the HDD Browser itself (rather than the system driver update) because only a new browser can use the updated syscalls correctly. Updating the syscalls would prevent the old browser in ROM from changing the language setting (hence blocking the user), if the HDD browser update cannot be booted.
    
  • We can do this with:

Code:

InitOsd();

• Load the OSD configuration from the EEPROM, parse it and set the settings into the EE kernel with SetOsdConfigParam and SetOsdConfigParam2.
  • SetOsdConfigParam2 is not supported by the unpatched SCPH-10000 and SCPH-15000 kernel. Invoking this will cause an exception.
  • I plan to move the code for loading the configuration from the EEPROM and parsing it into a new library (libosdinit), as how Sony probably had... but that is still a work in progress. I will elaborate on this part at a later date.
    
  • How it is currently done in FMCB:

Code:

   int result;
   ConfigParam config;
   Config2Param config2;

   <Load and parse configuration here. config.version is set to 2, as FMCB implements the configuration mechanism from a late ROM>

   SetOsdConfigParam(&config);
   GetOsdConfigParam(&config);
   //Unpatched Protokernels cannot retain values set in the version field, and don't support SetOsdConfigParam2().
   if(config.version) SetOsdConfigParam2(&config2, 4, 0);

• Before the video mode is initalized with the graphics library, the GCONT (RGB/YPbPr) setting must be set:

Code:

   SetGsVParam(config.videoOutput?1:0);

Other tips:

• Do not use the board-specific IRX modules. While some old homebrew software do that, it is bad practice because this will make your software not compatible with some (usually rarer) PlayStation 2 consoles like the early models, the PSX, and perhaps the system 246.
  • All T* modules. T-modules like TSIO2MAN are used by TESTMODE.
  • All X* modules. X-modules like XSIO2MAN are used by the new OSDSYS program.
  • All P* modules. P-modules like PCDVDMAN are used by the PSX's OSDSYS program.
  • All IOPRP images like EELOADCNF and OSDCNF. There is generally no need to reboot the IOP with any of these. To reboot the IOP with the default IOP kernel modules, specify an empty string.
    
  • While the modules in rom0 are generally present, they aren't actually documented to be available. Even if they are present on all CEX consoles (i.e. rom0:MCMAN), this may cause problems on non-standard consoles like the TOOL (rom0:MCMAN is bounded to the SDK version!).
• After a cold boot, the controller ports seem to not be immediately powered-up on the DECKARD slim consoles (SCPH-75000 and later). Even if a controller is actutally connected, it appears to software as being disconnected.
  • This was probably not a problem for Sony because they did not need to implement any sort of trigger/override button (i.e. hold R1 to boot LaunchELF).
  • If necessary, wait until either a pad is detected or a timeout expires.
• As of the Dragon-series MECHACON (SCPH-50000 and later), issuing any blocking command will cause a lockup if the drive is not ready (i.e. no disc inserted), as the MECHACON no longer replies until the drive is ready.
  • OSDSYS seems to avoid this by checking on the disc type first, with sceCdDiskType(). Further actions are only taken if a valid disc is recognized.
  • When sceCdInit() is called, use the non-blocking mode to initialize the drive.
  • sceCdDiskReady, sceCdSync and sceCdTrayReq cannot be used when no disc is inserted.
• While the browser does have options (i.e. disc speed, texture) for the PlayStation driver, these settings are always erased with every IOP reboot, when EECONF is loaded. Not being able to load them is not an issue with your code!
  • EECONF opens that configuration block of the MECHACON EEPROM and zero-fills it.
  • EECONF is responsible for initializing various peripherals. It also initializes the MAC address, SPEED capabilties and manipulates the ROM version data, by collaborating with the DECKARD emulator (SCPH-75000 and later).
  • Part of EECONF's actions were previously implemented as part of FMCB v1.8's init.irx module, which is unnecessary.

 

I am wondering if we can extract the retail bios (like SCPH-10000) and boot it on DTL-T10K? I think that will be useful for Memory card and may be music player etc...

 

Even if it works, it will result in the loss of all TOOL functions that are provided by the ROM. The CEX ROM has no DECI2 modules, so you will become unable to debug anything. It was also hardcoded to support 32MB, so your 128MB RDRAM and 8MB of EDO RAM will be downgraded.

The browser is just a program, which can be substituted by another program. So perhaps replacing the ROM is overkill

 

Hi sp193,
Thanks for your info. I mean booting the browser but not replacing the rom entirely. Can it be done? Thanks!

 

BTW I still didn't understand which is the best practice for choosing between what to load: rom0:something or something.irx. what is advantages and disadvantages of these 2 methods. Correct me if I am wrong:
- if we use *.irx files, things became universal: so we are sure that irx file behavior will be the same in any machine starting from early japanese units and ending with PS3 in PS2 emulation mode.
- if we use *.irx we need more space for keeping these irx files (sometimes critical for memory cards) and we also need to more RAM for them (is it critical for IOP?? or I confused things)
- modules from rom0 (or rom1 in rare cases) are optimized for machine that are bundled with, so it is possible that universal irx files contains errors or performance issues (for example freesd.irx which cannot replace rom0:libsd)
- As I understand in homebrew ps2sdk we are trying to add more functionality from different versions. So in the bright future freesio2.irx can be used as replacement for

Code:

rom0:SIO2MAN, rom0:XSIO2MAN, rom0:TSIO2MAN, rom0:PSIO2MAN

and so on.

In few words: if I am developer and want to create and then share my app - is it better to use homebrew irx files or rom0 content files?

 

Wow, that's pretty amazing information, thank you !

 

It's better to use homebrew irx files since they have bug fixes and additional features.
The IRX files in the ROM are very old versions, and they are used in all consoles (except, in most cases, the TOOL, which has a flashable ROM)
The IRX files will require storage space on a storage device, but the space required should be minimal if you compress them.
The IRX files, from either rom0 or storage device, will require no additional space than what the IRX file requires.
The base IRX files contained in rom0 (such as SYSCLIB, PADMAN, TIMEMAN, etc) are used in all consoles (except, in most cases, the TOOL, which has a flashable ROM). They are not optimized for each machine. Don't depend on the T*, P*, or X* modules existing, since they are not guaranteed to be there.
Homebrew IRX files often have bugfixes that the ROM or even new IOP updates (IOPRP) from Sony do not have.

It's better to use Homebrew IRX files.

IRX files in rom0 and the ones you provide are the same kind of IRX files.
Don't look at the file extension, look in the file header (first 4 bytes). If you see ELF header, look for .iopmod. If you see those two items, it is a IRX file.

 

@uyjulian already explained most things, so I will just add on.

Yes. This also includes any PS2 that is not common - can include the PSX and the system 246.

This really depends on how you store your modules, but usually does not involve additional IOP RAM. For official Sony software that came on discs, the IRX modules were stored on the discs. For our homebrew software and some Sony software (i.e. HDD Browser), modules are usually stored in the main ELF itself before they are loaded into the IOP... which means storage in EE RAM.

Loading the IRX from a file on external storage media is a chicken-or-egg problem, which is why we sometimes have few choices here. You can only use sceSifLoadModule to load a module from a device that the IOP kernel already knows of. For example, you can load a module from CD-ROM after a clean boot, but not from USB Mass Storage.

Please note that there is a device blacklist/whitelist for loading unencrypted modules (i.e. you cannot normally load IRX from memory card). But for our homebrew software, we have sbv_patch_disable_prefix_check() to disable this check within MODLOAD.

There are board-specific files as I mentioned, but they are usually concerned with hardware differences (initialization). PlayStation 2 models are generally designed to function exactly in the same way. The modules that homebrew software are generally concerned with are also generic (works on all PS2 models).

In fact, as @uyjulian mentioned... the stuff in ROM are generally very old and can be bugged (particularly the features that are not used by OSDSYS). So this is also one other reason to not use the ROM stuff. For example, the thfpool allocation function is bugged in ROM, and FILEIO's getstat, dread and remove RPC functions are faulty.

freesio2.irx is a drop-in replacement for XSIO2MAN. You can already use it in place of its X-module, as with the other "free" modules like freepad, mcman, mcserv, freemtap. The only thing you cannot do, is to mix and match them with the old modules (i.e. rom0:SIO2MAN).

In fact, as of the recent updates, freepad is now (hopefully) a 100% accurate replacement for PADMAN v3.6 (the final version of XPADMAN).

EDIT: oh yeah, there is one more thing to note: for some reason, Sony decided to add new exports in the middle of the export table for SIO2MAN, which prevents us from using freesio2 (XSIO2MAN) with newer SIO2 drivers (i.e. from games). This also includes mixing and matching SIO2 modules from rom1, as they were from a newer SDK version.

However, the rsio2man module (updated to fit rom1:SIO2MAN) that you can find from our SDK was updated to have the export table entries for the remocon (remote control), which brings the export table layout up to date with the newer SIO2MAN.
So you can say that: rom0:SIO2MAN < rom0:XSIO2MAN < rom1:SIO2MAN. The SIO2 modules (SIO2MAN and friends) are neither forward not backward-compatible, in terms of designs.

Please don't use the rom0 stuff because they were not documented to exist.

Unless there is really some reason... like for example: you write something like FMCB that is spec'ed to only work on CEX PS2 models. Then perhaps you can use the rom0 modules that were known to exist on all PS2 models (to also preserve compatibility), like SIO2MAN, MCMAN, MCSERV and PADMAN. However, these are very old, which also results in no support for the multitap and may not work on non-standard PS2 models (i.e. the TOOL).

 

OSD Initialization Libraries + Example

It took longer than expected because I discovered that my code was quite unfit for this role. And oh yeah, FMCB has some mistakes...

This package contains various files that are related to the initialization of the PlayStation 2 and the launching of the DVD Player.

As from the README:

Release Information
The basic functionality has been tested, with a SCPH-39006:

• Loading of OSD configuration.
• Loading of the classic ROM DVD Player.
• Booting of ROM DVD Player.
• Updating of play history.

Untested functionality:

• Loading of memory-card DVD player update.
• Support for Unified ROM DVD Player, for the SCPH-75000 and later.

Notice regarding unidentified functions/variables
There may be functions and variables around that have not been identified (i.e. within OSDInit.c). If you know of what they might be for, please feel free to let us know!

Downloads/Links
OSD Initialization Libraries + Example (2018/01/28): http://www.mediafire.com/file/q40h6jhk658ehco/[180128]osd.7z

 

oh nice, thank you

 

Changelog for release v0.91 (2018/01/28):

• Changed the roles of OSDInit.c and OSDConfig.c.
• Replaced all direct calls to the I/O library (i.e. fileio) with the _ps2sdk_* function wrappers.
  • To allow the I/O library to be freely changed. At least until there is a better solution on the PS2SDK side.
• dvdplayer: corrected inability to boot the classic DVD Player (incorrect path to EROMDRV).
• example: added more comments, added printing of configuration, added missing loading of memory card modules.
• OSDConfig: added OSDConfigGetPSConfig() and OSDConfigSetPSConfig(), added note regarding the official selection of languages for each OSD region.

Downloads/Links
OSD Initialization Libraries + Example (2018/01/28): http://www.mediafire.com/file/q40h6jhk658ehco/[180128]osd.7z

 

ROM v1.0x patch for OSDSYS

This package contains the source code for clones of the OSDSYS patches, meant for ROM v1.00 and v1.01.
As with the OSD update files, these files were meant to be encapsulated as KELFs. But I will not cover that here.

The first PlayStation 2 consoles (SCPH-10000 & SCPH-15000) had a considerably different boot ROM from the expansion-bay consoles.
Other than having the earliest-possible IOP and EE kernels, their OSDSYS programs were coded rather differently and had a design flaw that prevented arguments from being passed to memory-card updates.

These are the original update files and their descriptions:

Code:

Model                 ROM             Update File  Description
SCPH-10000            0100JC20000117  osdsys.elf   OSDSYS patch (patch0100).
SCPH-10000/SCPH-15000 0101JC20000217  osd110.elf   System Driver Update + OSDSYS patch (patch0101).
SCPH-18000            0120JC20001027  osd130.elf   System Driver Update + OSDSYS patch (patch0101). Exactly the same in content as osd110.elf.

The OSDSYS patch will copy a ROM image that contains a replacement EELOAD program, into kernel memory (0x80030000).
It will then patch the EE kernel to scan 0x80030000-0x80040000 for the EELOAD, instead of the boot ROM.

The System Driver Update attempts to boot the HDD-based update from the HDD unit.
While the SCPH-18000 contained a modern ROM that did not have the same deficiencies as its predecessors,
it is incapable of supporting the CXD9566R PCMCIA controller of the SCPH-18000. As a result, it needed extra help to boot updates from the HDD unit.

osd110.elf and osd130.elf are the system driver update main executables, which also contain a patch that is similar to the code within osdsys.elf, which install a replacement EELOAD program that will replace rom0:EELOAD.
This patch targets OSDSYS from ROM v1.01J, and does nothing for other ROM versions.
As a result, its patches are also different from the ones that osdsys.elf applies (see below).

This EELOAD replacement will wait for a request that boots rom0:OSDSYS, before loading rom0:OSDSYS and applying a few fixes to it:

1. Patch the memory card update dispatcher to pass arguments.
2. patch0100 only: Overwrite the Japanese message (DVDプレーヤーが起動できませんでした。), which says that that the DVD Player could not be started.
3. patch0100 only: Replaces update filenames and commands.

Once the OSDSYS-patching code within EELOAD is run, its effects are binding until the console is hard-reset or powered off.

Modifications for FMCB, which this package has:
FMCB sits in for the System Driver Update. To save space, I made osd110.elf similar to osdsys.elf; instead of being a full system driver update, it will patch OSDSYS to boot osd130.elf.
The osdsys.elf patch was also made to boot osd130.elf directly, hence allowing only one copy of the system driver update to exist.

Official path of execution:
ROM v1.00J: osdsys.elf -> osd110.elf -> HDD update
ROM v1.01J: osd110.elf -> HDD update
ROM v1.20J: osd130.elf -> HDD update

New (unofficial) path of execution:
ROM v1.00J: osdsys.elf -> osd130.elf -> HDD update
ROM v1.01J: osd110.elf -> osd130.elf -> HDD update
ROM v1.20J: osd130.elf -> HDD update

Notes for compilation:
These patches are split into two parts: The main program and an ROM image that contains EELOAD.
It is possible to build the patch without rebuilding EELOAD, by just entering "make".

The EELOAD module is a binary file, built to be loaded at 0x00082000. To build a ROM image, you need a tool (i.e. ROMIMG).
If you wish to rebuild EELOAD, you need to:

1. Build EELOAD, by entering "make" from within the EELOAD folder.
2. Convert it into a binary file. You can do that with ee-objdump.
3. Generate a new ROM image named 'EELOAD.img', that contains EELOAD.
4. Rebuild the patch.

Other trivia:

• Within the comments of the ROM images, the EELOAD images are known as "eeload.rom".
• Their original paths were as follows:
  • osdsys.elf: horikawa@phoenix/ee/src/kernel/patch0100/kpatch
  • osd110.elf: horikawa@phoenix/ee/src/kernel/patch0101/kpatch

Download Link
kpatch (2018/01/29): https://www.sendspace.com/file/urbyv9

 

MBR Program

This package contains the source code for the homebrew MBR program, which aims to function similarly to the Sony MBR program, which is used for booting HDDOSD installations.

It supports the same integrity checks as the Sony MBR program, and boots one of the following KELF targets:

• pfs0:/osd/osdmain.elf
• pfs0:/osd/hosdsys.elf
• pfs0:/osd100/hosdsys.elf

If the HDD has been deemed to have filesystem corruption, FSCK in one of these locations will be launched, in this order:

• pfs0:/fsck/fsck.elf
• pfs0:/fsck/fsck.elf
• pfs0:/fsck100/fsck.elf

Failing to do so, it'll fall back to the OSD.

Notes for programmers:
This MBR is split into two parts: The main program and an embedded EELOAD module, which is used to load the HDDOSD.

The embedded EELOAD module is hardcoded in the MBR program to expect the EELOAD module to run at 0x00084000.
Unlike rom0:EELOAD and various other EELOAD programs, the SDK used to build the MBR has the alarm functions patch (which resides at 0x00082000).

The MBR program itself must run from 0x00100000 when decrypted by rom0:HDDLOAD or by a Sony OSD update.

Both programs are headerless, binary blobs of code.

Download Link
MBR (2018/01/29): https://www.sendspace.com/file/5xxgin

Additional note: this MBR program is not a drop-in replacement for the PSBBN's MBR program. That one has more functionality.
The "MBR" is the first program that the ROM/System Driver Update will boot, when booting a HDD update.

As with any update file, the MBR program is meant to be stored within an appropriate KELF, but that will not be covered here.

 

How to use ee-objcopy to create obj files from binary files ?
I use this :

ee-objcopy.exe -I binary -O elf32-littlemips lng_Chinese.lng chinse_lng.o

but ee-ld get this warning :

D:\project\ps2net\MinGcc\MinGW\msys\1.0\lib\ps2dev\ee\bin\..\lib\gcc-lib\ee\3.2.2\..\..\..\..\ee\bin\ld.exe: warning: unknown architecture of input file `chinese_lng.o' is incompatible with mips:5
900 output

 

Try adding --binary-architecture=ee?

 

I test these:

--binary-architecture=ee
--binary-architecture=mips
--binary-architecture=mips:5900

All of them cause some warning or error information .


Does EELoad always at 0x82000 , will never be overwrited by game ?

 

I thought you meant ee-objcopy. I also thought you were really converting a binary executable into an ELF...

If you want to embed a file into a program, you should use bin2c instead.

EELOAD from ROM loads at 0x00082000. It is meant to use the space between 0x00082000 - 0x000FFFFF. Sony does not seem to use new SDKs for old software, like the browser.
Later on, they added a runtime patch for the alarm function, which is copied to 0x00082000 during runtime. This patch replaces part of the EENULL module that handles the user-mode dispatcher for the alarm function.

This is probably why the EELOAD module of newer browsers always load at 0x00084000 instead, since they are made with newer SDKs; in the case of the HDD browser, its EELOAD module should not overwrite the alarm patch.

Games are meant to use 0x00100000 - 0x01FFFFFF. Those that somehow use an address below 0x00100000 might have been made to break cheating devices or HDLoader, since only Sony officially knows what uses the memory below 0x00100000...

 

OPL use bin2s to change irx to assembler code , then object code .
I want to use single step to replace these two steps .

I take a look on your code.

Spoiler: idle thread

Code:

.globl IdleThread
.ent IdleThread
IdleThread:
   nop
   nop
   nop
   nop
   nop
   nop
   b IdleThread
   nop
.end IdleThread
.p2align 4

I think I get IOP side only IGR solution. When IGR is detected ( via hookSio2man) .
Overwrite ee idle thread .

 

That would be bin2o, but I remember that there is something wrong with it... but I just do not remember what.
I doubt ee-objcopy can be a solution on its own because it will likely not create symbols for you. There would be no way to know the location of the object nor its size.

Then you must have a way to fix it again, after that...
Anyway, you still need code on the EE to reset the EE and to load the next ELF. If you have code on the EE, there are various ways to signal it.

BTW if you want to discuss OPL-related stuff, please create a new thread.
I do not know why, but now they prohibit us from editing a post after a fixed period of time. So if my threads get longer, it gets harder for people to find updated information.

 

v0.9.2 Beta Release Notes

• Fixed selection of DVD Player (should now correctly choose the DVD player).
• Added new code for demonstrating how Sony boots PlayStation and PlayStation 2 game discs.
• Added code for retrieving the PlayStation 2 model name.
• Added code for retrieving the PlayStation driver version.
• Added code for retrieving the DVD Player version.

The disc-booting code (PlayStation, PlayStation 2 and DVD Video disc) will automatically update the play history for you. So the information about updating the play history is FYI.

The PlayStation-driver initialization code shows how the version number is obtained from late PlayStation 2 models. Interestingly, they made it similar to DVD players, whereby each MagicGate region has its own ID/Version file... but there is only one PS1DRV program (unlike the DVD Player). How strange...

Limitations of this release:

• The PS2GetBootFile() function within ps2.c will likely not support the Chinese console (SCPH-50009) properly because of the missing libcdvd function.
• The DVD Player-loading code does not seem to work if the console has no ROM. It may be a bug in the original code.
• The code for reading the model name does not work on the A-chassis PlayStation 2 models. (I forgot to mention this in the README).
  • So this probably means that only the HDD Browser was specifically built to support all PS2 models.

***
Regarding how PS2 discs are booted: the browser does not need SYSTEM.CNF.
It has been this way since the SCPH-10000, but we (in the homebrew world) just parse SYSTEM.CNF.
So the information (specifically, the disc ID) within SYSTEM.CNF is to verify against the DRM information obtained.

The method for obtaining the boot filename seems to differ for Chinese consoles as well, which may explain why @SONIC3D observed that Chinese discs will not boot on foreign consoles.

The code for booting PlayStation discs passes additional information to PS1DRV, but PS1DRV does not actually use the "BOOT" and "VER" information provided by the browser (even in the earliest-known version of PS1DRV). I think it might have been leftover code from the development days of the PlayStation 2, but Sony kept this code there.

I plan to revise this version again in a few days' time, but the APIs probably won't change.

Downloads/Links
OSD Initialization sample package v0.9.2: http://www.mediafire.com/file/mton6k0yi5kaq7k/[180203]osd.7z