PS2 Known PlayStation 2 Kernel Patch Locations

Discussion in 'PS2 Homebrew' started by sp193, Jun 28, 2017.

  1. 769
    1,383
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    769
    Likes Received:
    1,383
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    As of the SDK v3.0.3 (June 2005):
    Code:
    0x80030000-0x80032114 patch0100/kpatch (osdsys patch for v1.00J)
    0x80030000-0x80032294 patch0101/kpatch (osdsys patch for v1.01J)
    0x80074000-0x800747A8 libosd
    0x80075000-0x80075330 tlbfunc
    0x80076000-0x80076740 alarm
    0x00082000-0x00082028 eenull (alarm.o)
    
    About kpatch:
    The kpatch programs are from the osdsys.elf and osd110.elf files that are installed by the HDD Utility Disc, when run on a SCPH-10000, SCPH-15000 or SCPH-18000. Three files are installed as part of the system driver update, which are osdsys.elf, osd110.elf and osd130.elf.
    The SCPH-18000 uses osd130.elf, which is identical to osd110.elf. However, having ROM v1.20J, the kernel patches are not applied.

    The first PlayStation 2 model (SCPH-10000, v1.00J) will boot osdsys.elf, which will install a custom EELOAD module to 0x80030000. This will monitor for the booting of rom0:OSDSYS and patches it to boot osd110.elf and replaces the Japanese DVD Player is not set up error message (even though the exact same string appears to be already present in my console). rom0:EELOAD of ROM v1.00J has debugging messages and may cause the console to hang if the target boot program could not be loaded.
    Unlike osd110.elf, osdsys.elf contains only a patch (no boot screen).

    The next revision (SCPH-10000, v1.01J) will boot osd110.elf, which will also install a custom EELOAD module to 0x80030000. osd110.elf and osd130.elf contain the opening boot animation. osd110.elf only patches ROM v1.01J.
    Both versions have an older OSDSYS program that has a rather different design from the newer versions (from ROM v1.10 and later). These old OSDSYS programs are incapable of passing arguments to system updates, hence the patches.

    About libosd:
    The libosd update is applied by osd110.elf and osd130.elf. However, only osd110.elf will apply it because osd130 is booted by the SCPH-18000, which does not need it. It is also carried by, but only partially applied by all late games. I believe this is to prevent the user from being unable to change the settings in the browser, which can only happen with a newer browser version once the patch has been fully applied.

    libosd replaces the ExecPS2, SetOsdConfigParam and GetOsdConfigParam syscalls with newer versions. It also adds implementations for SetOsdConfigParam2 and GetOsdConfigParam2.

    In the SCPH-10000 and SCPH-15000, the ExecPS2 syscall only executed the specified program, without any form of cleaning up. So problems could develop if the previous software did not cleanly deinitialize. SCEI didn't finalize the specifications for the browser parameters until later on, so the SetOsdConfigParam and GetOsdConfigParam syscalls originally had a slightly different internal data structure that could only deal with 2 languages (instead of the 8 standard languages). Neither was there support for timezone settings.

    About tlbfunc:
    SCEI added TLB-management functions later on. Late games will apply this patch, but it will always get overwritten by the next software that boots. There is no mechanism for indicating whether it was installed or not.

    About alarm:
    SCEI appears to have replaced the SetAlarm and ReleaseAlarm syscalls somewhere between release v2.0 and v2.2.4.
    I believe that this may be a follow-up of a (then) new restriction by the EE kernel's design: if an interrupt is asserted before a DI instruction can be executed by the EE, then the EE's EIE status bit may be set at 0 by the interrupt handler... leaving thread-switching disabled.

    0x00082000 is also used by EELOAD. But that is not a problem because the small eenull module that is copied by the patch in alarm.o is run only after the software is booted. This is not actually a full EENULL module (which also contains the idle thread), but only contains the small stub for the Alarm implementation.
    Unlike the one in rom0:EENULL, this one invokes syscall #8 instead of syscall #5. Syscall #8 is usually undefined, but is defined by the alarm function update.​
     
  2. 769
    1,383
    222
    sp193

    sp193 Developer

    Joined:
    Oct 13, 2014
    Messages:
    769
    Likes Received:
    1,383
    Trophy Points:
    222
    Location:
    Singapore
    Home Page:
    Threads update
    This isn't installed as a patch within the kernel, but is actually present in the program itself. However, I feel it deserves a mention because it does address a few bugs in the EE kernel.

    The EE kernel's iWakeupThread, iSuspendThread and iRotateThread syscalls do not function completely perfectly:
    • iWakeupThread is unable to wake up a thread, if the running thread is the thread to be woken up (can happen if iWakeupThread is invoked from an interrupt handler).
    • iSuspendThread does not choose a new thread to run. So if the running thread is suspended, then the EE will get deadlocked because nothing will be running.
    • iRotateThreadReadyQueue does not choose a new thread to run. So if the running thread enters READY state, the EE will get deadlocked because nothing will be running.
    An indirect consequence of the broken iWakeupThread syscall could be felt when a SIFRPC server is set up on the EE with the older revisions of the homebrew PS2SDK (as well as the old SCE SDKs). While the server usually worked, it would occasionally stop responding because iWakeupThread couldn't wake up the server thread.

    There were a few versions of the iWakeupThread patch by SCEI. There is an earlier version of the patch that can be found in the browsers of most consoles (other than the SCPH-10000 and SCPH-15000), which SCEI attempted to work around the broken iWakeupThread syscall by first suspending the running thread before waking it up, before finally resuming it... but it doesn't work because iResumeThread won't resume the running thread! o_O

    The current (working) solution is to have a dedicated thread that invokes WakeupThread, SuspendThread and/or RotateThreadReadyQueue, on behalf of the code running from the interrupt context.

    It is also worth noting that the TOOL's late kernel does not have a problem with iResumeThread. This is unlike the iWakeupThread syscall, which has a development runtime check for the unsupported THS_RUN state. Hence this difference in behaviour of iResumeThread may be a technical oversight by SCEI.
    Hence the behaviour of any software that uses the real iResumeThread syscall may behave differently when it is used on the TOOL and a CEX set.

    The interesting thing about the designs of all patches mentioned so far, is that older software that do use the old syscalls can continue using the old (unpatched) syscalls. Their behaviour will not change because the old syscalls continue to be left in an unpatched state.
     

Share This Page