PS2 Julian's various PS2 projects (Worklog)

So, here is a roundup of what I've been working on so far...

* romdrv implementation in ps2sdk
* fsck/fssk/hdck/hdsk in ps2sdk
* cdvdman/cdvdfsv modules implementation in ps2sdk
* sysmem/loadcore/modload/loadfile implementation in ps2sdk
* dsnet related programs (5 years and ongoing...)
* arcade modules implementation in ps2sdk
* DVR PFS/APA more complete implementation based on DVRP RE
* IRX generation using external tools (more easily upgrade binutils version)
* PSF2 player related stuff (Don't really have a goal here, just playing with taping together stuff)
* OSDSYS resource loading/decoding

How much can I finish during the winter break? I think the first 2 will be mostly straightforward.
 
I'm almost finished labeling and typing LOADFILE.

While in the process of doing that, I potentially found out the reason why stuff gets corrupted if you do AllocSysMemory in the IOMAN open() function while in the process of loading an ELF.

The size/offset when reading into the temporary buffer is incorrect. The size of the buffer never gets set correctly, so it uses a fallback code path, which has the subtraction operands set backwards. Thus, it writes into the data right before the buffers allocated by LOADFILE.
 
The following RE is close to being finished:
* FILEIO from SDK 1.3.4
* IOMAN from SDK 1.3.4
* DMACMAN from SDK 1.3.4 (thinking of porting symbols to the module from SDK 3.1.0, since it's not that much additional stuff)
* SSBUSC from SDK 1.3.4 (thinking of porting symbols to the module from SDK 3.1.0, since it's not that much additional stuff)
* STDIO from SDK 1.3.4 (thinking of porting symbols to the module from SDK 3.1.0, since it's not that much additional stuff)
* LOADFILE from SDK 1.3.4

The following needs a bit more time in the bakery:
* CDVDMAN from DESR/SDK 3.0.0 (need associated RPC names from the .rel file)
* CDVDFSV from DESR/SDK 3.0.0 (need associated RPC names from the .rel file)
* SYSMEM from SDK 1.3.4 (pointer offsets need to be cleaned up)
* LOADCORE from SDK 1.3.4 (pointer offsets need to be cleaned up)
* MODLOAD from SDK 1.3.4 (pointer offsets need to be cleaned up)
 
A little tidbit.

PSBBN uses an executable daemon to handle pfs access and new kernel installation (not a kernel module).

Those executables are pfsd and ps2kinst, respectively.

Both executables have symbols.

Now, here's the interesting part... they left .mdebug debug info section in ps2kinst.
 
I need a MIPS based machine that can run Linux, upstream Linux, so that I can test my PSF2 player on MIPS hardware (with a debugger!!!) instead of just running in QEMU.
Something that is less complicated than PS2 Linux and is well supported, so I can at least save some time on setup the environment.

SGI machines are too expensive.
OpenDingux handhelds like RG350 are also expensive and not well supported.

How about routers...?
Netgear WNDR4500 is a MIPS based router (only v1 and v2, not v3 which is ARM based), and is supported by DD-WRT. It also has USB ports.
I can remote into it and run programs.

Now, how cheap are they used on eBay...? Around 20 USD.
 
Last edited:
I've been finishing up the FILEIO RE.

One thing to note is newer versions of FILEIO have a 64 byte unaligned double buffer for reading instead of a 16 byte unaligned double buffer.

Unfortunately, since size of the structure is not specified in the transfer, I can't detect which buffer size to use by detecting the size.

So instead, this is my attempted workaround:

1. If size to transfer of either buffer is over 16 bytes, it's using the 64 byte structure version, so stop here.
2. Before starting transfer, flip all the bits of the unaligned double buffer, then copy it to somewhere else.
3. After transfer, if the last 96 bytes of the double buffer is unchanged, it's using the 16 byte structure version, so stop here.
4. It's using the 64 byte structure version, so stop here.

What does Play! emulator do in its HLE emulation of FILEIO?

Well, since it has knowledge of both EE and IOP RAM, it can just write directly to it. No need to go through SIF or handle misalignment.
 
Last edited:
FILEIO, STDIO, ROMDRV (and associated modules), and file system check modules patches have been sent.

What's next?

* IRX generation using external tools (more easily upgrade binutils version)
* IOMAN from SDK 1.3.4 (need to figure out how to make iomanX able to grab the file and device handles due to offsets changing)
* DMACMAN from SDK 1.3.4 (thinking of porting symbols to the module from SDK 3.1.0, since it's not that much additional stuff)
* SSBUSC from SDK 1.3.4 (thinking of porting symbols to the module from SDK 3.1.0, since it's not that much additional stuff)
* LOADFILE from SDK 1.3.4 (waiting on header changes)
* CDVDMAN from DESR/SDK 3.0.0 (need associated RPC names from the .rel file)
* CDVDFSV from DESR/SDK 3.0.0 (need associated RPC names from the .rel file)
* SYSMEM from SDK 1.3.4 (pointer offsets need to be cleaned up)
* LOADCORE from SDK 1.3.4 (pointer offsets need to be cleaned up)
* MODLOAD from SDK 1.3.4 (pointer offsets need to be cleaned up)
* dsnet related programs (5 years and ongoing...)
* arcade modules implementation in ps2sdk
* DVR PFS/APA more complete implementation based on DVRP RE
* PSF2 player related stuff
* OSDSYS resource loading/decoding
 
For module unload support in loadcore/modload, modules itself need to also be updated to support unload.

The problem is the return value of 2 in _start has differing behaviors between older and newer versions of modload.

I don't feel like copy and pasting the modload version check in every module just to check for this behavior.

I'm planning on implementing this change in stages:
1. Implement SDK 1.3.4 version of loadcore/modload
2. Implement module unload functionality in modules (without changing return value of _start)
3. Implement module unload function in modload
4. Change return value of relevant modules with module unload functionality to 2
 
cURL and wolfSSL did another release, so I went ahead and sent a PR to ps2sdk-ports to enable the HTTPS feature.

Now, for some other libraries:

liblzma: build with -DTUKLIB_CPUCORES_FOUND=ON -DTUKLIB_PHYSMEM_FOUND=ON -DHAVE_GETOPT_LONG=OFF -DBUILD_TESTING=OFF
lz4: build with -DLZ4_POSITION_INDEPENDENT_LIB=OFF -DLZ4_BUILD_CLI=OFF -DLZ4_BUILD_LEGACY_LZ4C=OFF
libzip: build with -DBUILD_TOOLS=OFF -DBUILD_REGRESS=OFF

zstd: issue, need to disable PIC, ICE in lib/dictBuilder/cover.c
brotli: issue, need to disable PIC and building tools

The first three will come later.
 
I'd like to make a cross toolchain with the compiler from PS2 Linux automatically using Github Actions eventually.
There are lots of source code, binaries, and instructions available, but either they are incomplete (missing environment etc.), not automated, or out of date.
This will probably require heavy patching to make it work with the latest compilers available.

For reference, here is how to setup a cross toolchain:
https://sourceforge.net/projects/ke...ate Files/mozilla-ps2/moz_cross.html/download

And here is how to setup a old version of rpm for PS2 linux usage:
http://www.tonns.org/ps2linux/#prep

Eventually, this will turn into a project to reproduce the open source portions of PS2 Linux in an automated and reproducible way, but these are the first steps.
 
wolfSSL should be actually working with cURL now, but with a performance issue. It takes longer than it should to perform a request. I'll probably leave debugging that issue for later.

---

loadcore module has been RE'd and patches have been sent.
 
LKL seems to be an interesting library. It's basically Linux, but as a library. https://github.com/lkl/linux

That means you can use its filesystem code without needing to have the other e.g. threads, networking, processes etc. related code.
And that means you don't have do the entire Linux setup like reformat your HDD to e.g. ext4, or rewrite your code from iomanX to POSIX, etc.

Which also means: ext4 and gsKit at the same time???

That means it becomes easier to integrate e.g. ext4, ntfs support.

However, it appears that it hasn't been upstreamed yet.

This may also possibly become a replacement for stuff in ps2sdk like the iso9660, vfat, FatFs, lwip code.

This looks very promising, and I'll keep watch on it. Maybe I can have my cake and eat it too...
 
Adding c-ares to ps2sdk-ports would require a lot of patching and stubs.

The configure arguments:
-DCARES_STATIC=ON -DCARES_SHARED=OFF -DCARES_INSTALL=ON -DCARES_STATIC_PIC=OFF -DCARES_BUILD_TESTS=OFF -DHAVE_LIBSOCKET=ON -DCARES_USE_LIBRESOLV=ON
 
I'd like to see if I can relocate IOP modules to something like 0x2800000.

The problem is that modules e.g. LOADCORE, MODLOAD, UDNL access in absolute memory low addresses like 0x280 for storing stuff like the IOP boot parameter, or the exception handler. Modules are stored at 0x0, then rebased to a higher address.

However, disassemblers don't perform the rebase automatically, so if it sees a low memory address access, it assumes that it is part of the module code, when it actually be a low address not part of the module code.
 
"objcopy --change-addresses" doesn't give me what I need.
For relocating the IOP module to an arbitrary address, what I'll probably end up doing is porting the relocation related code out of LOADCORE/UDNL to POSIX and then just make it relocate to an arbitrary address. After that is done, just wrap the result in a static ET_EXEC ELF file similar to how ps2-unpacker does it.
 
STABS debug info parser and inserter now has improved local variable type inserter for i386 and mips. In most cases it should work correctly.
Things left to do:
* Type interdependency issues
* Block scope handling

---

I think I can just add module unloading support to MODLOAD and LOADFILE. SYSMEM and LOADCORE don't need to be touched right now.
Basically, the following need to be changed:
* If return value of start function has the 2 bit set, set a flag that indicates that module is unloadable.
* When unloading module, call start function with negative argc.
The following may be missing in the initial implementation (but planned to be added later):
* If module to be unloaded has clients, do not unload and return an error.
 
Sent patches for implementing MODLOAD and REBOOT.

These are currently at SDK 1.3.4 featureset, so no module unload just yet.
As mentioned before, I plan to add module unload code to the modules that can support it.
 
You must log in or register to reply here.

Similar threads

Back
Top