Project: Retail DeBugging (RDB) startup card

EDIT 2016/06/19: v0.9.2 released - http://assemblergames.com/l/threads...ing-rdb-startup-card.50322/page-2#post-887673
EDIT 2014/03/28: The Open Beta Test is here: http://www.assemblergames.com/forum...)-startup-card&p=738943&viewfull=1#post738943

What is the Retail DeBugging (RDB) startup card? It is a piece of software that provides some debugging facilities for retail PlayStation 2 consoles.

The RDB startup card is a clone of the Sony TDB startup card, which functions similarly. Except that it was meant to provide debugging functionality for supported TEST/debugstation PlayStation 2 consoles.

Like the TDB startup card, RDB provides IOP DECI2 modules, to complete the IOP side of the DECI2 system.

All PlayStation 2 consoles, regardless of whether they are retail, TOOL or TEST/debugstation units, have the EE DECI2 manager present in their EE kernels. However, only TOOLs will come with a fully functional debugging environment by default, as they are the only ones that have the IOP DECI2 modules present in their boot ROMs and will load them during every IOP reboot.

This project differs from Kermit in terms of the target and supported interfaces. Kermit appears to be more for debugging retail games and does not support the Ethernet port, while RDB is meant for debugging homebrew software and supports only the Ethernet port (Like the TDB startup card). It also shares most of the same limitations that the Sony TDB startup card has, which also makes Kermit more suitable for debugging complicated pieces of software that cannot be rebuilt from their sources.

As I haven't received a final confirmation from the developer who provided the non-Sony IOP DECI2 modules, I cannot make a release yet. But I'll like to share on the existence of this project and its eventual release (regardless of whether it ends up being entirely independent of Sony modules or not).

More information like how it works will most likely be provided later on, in another post.

Comparision between the structure of the DECI2 implementations of RDB, the TDB startup card and the TOOL: http://assemblergames.com/l/threads/project-retail-debugging-rdb-startup-card.50322/#post-735365

Thank you all!

 

Great work, will definitely try it out when you're able to release it.

 

DECI2 operational structure

As mentioned in the first post, I wrote that I would talk a little about how the system works.

According to SilverBull, he wrote in the Kermit README file that DECI2 on a real TOOL works like this:


Honestly speaking, I'm still unsure of how the AIF, PIF and MRP are related. The IOP driver that connects the IOP to the "outside world" describes itself as the "PIF driver", so the PIF might be just one interface in the AIF. On the other hand, the MRP is the device that the PS2 Linux has, which DSNETM interfaces with in order to communicate with the PS2.

Kermit's network topology appears to be quite a lot more complicated. But it is not reliant on the IOP at all, making it ideal for debugging stuff like games and programs that cannot have the IOP reset omitted:


Kermit does not involve a compatible version of DSNETM, but has its own system for simulating the presence of one.

As for the Sony TDB startup card (which RDB copies):


Since there isn't a PIF/AIF interface in consumer and debugstation units, a virtual interface that runs over TCP/IP called the "TIF" is added.

The reason why TDB and RDB do not support IOP resets is because the consumer and debugstation units do not have the DECI2 modules listed in their ROM IOPBTCONF file, which causes the IOP to be devoid of DECI2 modules after every single regular IOP reset.

As for the "client(s)" part, it's because the various tools such as dsedb (EE debugger), dsidb (IOP debugger), dsicons (IOP console) and dsecons (EE console) can connect to the PS2 via the DS Network Manager (DSNETM), using TCP/IP.

 

Can't the R5900 kernel be hacked to load the DECI2 IRX files after an IOP reset?

 

It is not a problem with the EE kernel, but with the ROM that both the IOP and EE share . One cannot simply add files to it, or we wouldn't need FMCB, DVD player and system driver updates, and the Sony TDB startup card.

Since the entire target reset process (as issued by either dsidb or dsedb) is done by the IOP, the only way to include additional modules is to store them on external media.

One solution (which I am exploring) is to store the additional files and extended IOPBTCONF file in an updater module (which will load the modules into the IOP during an IOP reset), which is stored on a memory card. This makes the setup reliant on the memory card, however.

 

RDB v0.9.x Open Beta Test (OBT)

I think that I've made sufficient progress and there are few to no problems left. I lack time and resources to perform more tests, and I think that I would like to showcase what I have done.

As of right now, the only supported host operating system is Linux... as the dsnet programs that I have were built for it. There may be a public release of Windows versions (either running under Cygwin or native ports), but this cannot be promised.

There are a couple versions of RDB in this package, as I am still unsure of whether the Sony-licensed developers could run programs consecutively without a hard reset. It does not seem like the EE kernel (including the one in TOOLs) has a mechanism for clearing the software SIF registers during a target reset, which means that next software running on the TOOL may not be able to communicate properly with the IOP over the SIF.

I took a too long to write out the README file, so it may be filled with overly complicated facts and the information there may be not too well organized. I'll slowly rewrite it for the stable release of RDB.

The DECI2 modules and PC-side dsnet programs were generously provided by SilverBull. These copies are, however, "SP193" versions because I was the one who completed and compiled them. If SilverBull ever makes a release containing these programs in future projects, they may be different.

I intend to release the source code of RDB for everybody to study, in the future. Although I might only release the parts that were written by me, as SilverBull has expressed his wishes to tidy up his code before making any public releases.

The dsnet programs are Sony copyright-free clones of the original Sony dsnet programs.

As for documentation on the usage of the dsnet tools, please refer to the dsnet documentation from the official PS2SDK, as is currently not freely available.

Downloads/links
RDB: http://www.mediafire.com/download/usv2wzu2dyjhwpp/[140328]RDB-bin.7z
dsnet tool set: http://www.mediafire.com/download/oio3fbf81osi526/[140328]dsnet-bin.7z
Tentative documentation: http://www.assemblergames.com/forum...)-startup-card&p=740665&viewfull=1#post740665

 

Any chance you could make a video on getting it to work? Sure would help me out a ton and probably others as well.

 

Good to see some great programs for debugging being made for retail PS2s, I'll have to try it out sometime on my Japan PS2.

 

Some documentation

The current release of RDB has a messed up README file. Since its documentation covers many topics, I'll write the documentation here, adjust it based on feedback from the community, and use the adjusted version to write up a better README file.

I can see that there are a few topics that must be covered:

1. What is RDB.
2. What is DECI2.
3. What is DSNET.
4. How to set up and use RDB.
5. Limitations and known issues.

My free time is very limited, so there will be no instructional video. I'm aware that the current documentation is still quite vague, but it's difficult to adequately document a system this big, within a short time.

***

What is the Retail DeBugging (RDB) startup card? It is a clone of the Sony TDB startup card, which gives certain TEST/debugstation consoles (which support Magicgate) some DECI2 debugging functionality.

DECI2 is a low-level protocol that Sony uses for the PlayStation 2's system debuggers. Both the EE (E) and IOP (I) are nodes, and each one has a DECI2 manager for communicating with each other. There is also the host node (H), which is the development PC. The host node is connected directly to the IOP, which is the middleman between the EE and host nodes.

Traditionally, development and debugging of games and software was entirely done on PlayStation 2 TOOL consoles, which are basically each a PlayStation 2 console and PC in one unit.
Both entities are linked together through something known as the "PIF".

Retail consoles are essentially similar to debugstation consoles, except that their CD/DVD drive MECHAnics CONtroller (MECHACON) chips don't accept master discs, but support Magicgate and DVD video discs fully. Since these consoles lack the TOOL unit's PIF, Sony substitutes it with a virtual interface that is known as the "TIF", which sends data over the network.

Unfortunately, like the debugstation, the retail set has a boot ROM that contains an IOPBTCONF file (a list of modules to be loaded during every IOP reboot) that doesn't list the DECI2 modules.
As a result, it is not possible to reboot the IOP normally without cutting off DECI2 support.

See here for charts: http://www.assemblergames.com/forum...)-startup-card&p=735365&viewfull=1#post735365

DSNET is a collection of development tools that run on the development PC. Some of the probably more important tools would be:

• DSNETM: DSNET Manager (all tools connect to this, which will connect to the PlayStation 2)
• DSEDB: EE debugger
• DSIDB: IOP debugger
• DSICONS: IOP console monitor
• DSECONS: EE console monitor

As of today, documentation for the DSNET tools and the debugger commands is still not publicly available. Please refer to the DECI2 documentation from the Sony PS2SDK.

Note: currently, the provided tools will only run on Linux as the originals were meant for Linux. There may or may not be a Windows bundle in the future, due to the difficulty of making such a port.

In this package, there are a few versions of RDB:

1. RDB - the normal standalone version that uses the original design which has the "TIF" interface.
2. RDB (System driver update) - the normal version, which is installed to the memory card. It is most similar to the Sony TDB startup card.
3. RDB-UIF - the standalone "UIF" version.
4. RDB-UIF-RB (System driver update) - the "UIF", ReBoot version. It's installed onto the memory card. This is the only version that supports the RESET command.

There isn't a system driver update version of RDB-UIF because RDB-UIF-RB is a modified version of RDB-UIF that has been designed to load itself from the memory card upon receiving a RESET command.

What is a system driver update?
A system driver update is a piece of software that gets installed onto your memory card, which most PlayStation 2 consoles will look for and boot at startup.

System driver update versions of RDB are installed this way, and hence get booted automatically whenever the console is started up. On the other hand, standalone versions can be started directly, from software like uLaunchELF and FMCB.

WARNING: System driver installations will overwrite FMCB installations, as well as other system drivers that were previously installed!
If your console is a SCPH-10000, SCPH-15000 or SCPH-18000 unit, this includes the system driver update that is required for HDD OSD (browser v2.00) support!

Why are there so many versions?
I'm still unsure of how the Sony-licensed developers developed software on the PlayStation 2 TOOL unit. I do not know whether they could simply reset the PlayStation 2 side of the TOOL remotely with the RESET command.

Originally, the UIF ReBoot version of RDB was supposed to be the sole version of RDB, which is why it has a higher version number of v0.9.1. However, I realized that the EE kernel might be left in a state that most PlayStation 2 software will not work within, if a running program is interrupted before another gets loaded. The RESET command does not fix this problem.
I found out later on that it's because target resets (caused by the RESET command) result in the IOP changing its state without the EE being aware of that. The software SIF registers within the EE kernel need to be cleared, but it does not seem like there was ever a way to do that.

So until the facts are known, there will be this number of versions.

Setting up RDB:

1. (For only the system driver version) Install RDB onto a genuine Sony memory card.
2. Configure your PC's IP address (Edit mc:/SYS-CONF/IPCONFIG.DAT).
3. Start RDB. For system driver versions, just reset your console. Otherwise, start RDB with something like uLaunchELF.
4. On the development PC, start dsnetm with the "-d" option.
5. Start debugging with dsedb etc.

Limitations, which the TDB startup card also has:

1. The IOP cannot be rebooted at all, so functions like SifIopReboot() and SifIopReset() must not be used (1).
2. LoadExecPS2() cannot be used, as it causes an IOP reset.
3. The Ethernet port cannot be used, as it is used by RDB itself. It is, however, still possible to use the HDD unit. POWEROFF.IRX and DEV9.IRX will be automatically loaded by RDB. (2)
4. As DEV9.IRX is loaded, an expansion bay unit cannot be reset by pressing the RESET button once. If the button is held down, the console will be switched off.
5. The RESET command is not supported, and hence clients like dsedb and dsidb must be startup with the "No reset" (-nr) option. (3)
6. IOP-side debugging cannot be performed due to limitations in RDB's design. dsidb can still be run, but the IOP will cease to respond if a BREAK is issued. (3)
7. When the IOP is heavily loaded, dsedb may not respond well. (3)

(1) However, with RDB-UIF-RB, it is possible if the IOP is reset with the "mcX:/RDB/rdb.irx" module (0x100 has to be specified as the IOP reset flags) instead of "rom0:UDNL". X = the memory card which RDB is on.
(2) RDB-UIF-RB loads a modified version of DEV9 that does not use POWEROFF.IRX, and so POWEROFF.IRX will not be loaded by this particular version.
(3) This does not apply to the UIF versions of RDB.

Limitations, which are unique to RDB:

1. If the stock EE kernel is used, thread information cannot be retrieved because these kernels don't support the "EE thread extension". See "Other features" to learn about replacing the EE kernel.
2. If the stock EE kernel is used, the EE debugger will start in a RUN state. Before invoking RUN, BREAK must be issued first (The prompt will then change from "dsedb R>" to "dsedb S>").
   This seems to apply to all older kernels that sport ESDBGP versions older than v3.20.
3. For only RDB-UIF-RB: the memory card which it is running from cannot be removed.

Differences in functionality from the TDB startup card:

1. IOP-side TTY output works. Homebrew software redirect EE-side printf() output to the IOP, so printf() from the EE will be sent to dsicons.

Other features:

1. EE kernel replacement:
   By default, RDB uses your retail console's stock EE kernel. However, this kernel lacks the "EE thread extension", which renders it unable to show information related to threading (e.g. thread and semaphore status).
   By placing a replacment EE kernel (e.g. the one from the TDB startup card or a TOOL) as KERNEL.bin in the same location as RDB, RDB will use the substitute EE kernel instead.
2. IP address configuration:
   RDB retrieves your network configuration from mc:/SYS-CONF/IPCONFIG.DAT, which has this format:
   IP address
   Subnet mask
   Gateway
   <optional: link speed and duplex mode: 10HDX, 10FDX, 100HDX,100FDX or AUTO. AUTO is the default if nothing is specified>

Included files/folders:

• RDB: Contains the installer for the normal, system driver update version of RDB.
• RDB-UIF-RB: Contains the installer for the UIF (ReBoot), system driver update version of RDB.
• bin/thmon.irx: A clone of the Sony "Simple thread monitor". Can be loaded and used with dsidb for viewing IOP-side thread information. It is interacted with over IOP tty9: (access with "dsicons 9").
• bin/RDB.elf: The normal, standalone version of RDB.
• bin/RDB-UIF.elf: The standalone "UIF" version.

Special thanks to:
SilverBull for the DECI2 modules, ideas and support
"Someone who wishes to remain anonymous"
... and other people who I might have (unintentionally) forgotten.

 

Hi!
I would like to make a try for RDB UIF with my SCPH-90006 HK BIOS v2.30 (modchipped with a Matrix Infinity v1.93 Clone) plus an EE-SIO Cable (provided by Gillbert) ;-)
Let's start with some basic questions (I am a newbie onto this area):
Does RDB enable EE-SIO output even from commercial games? I mean, if I start RDB with my original GT4 media disc inserted into console, I will start to see not only the KSIO (Kernel SIO) messages on my PC during IOP but also those SIO messages coming from game ELF (i.e. the sce functions)? Or RDB has features are useful only for PS2 consoles with PS2 iLink?
Please gimme some example which I could benefit for testing RDB with my SCPH-90006 - If any.
Please take in account that despite of I've noticed that there are RDB ETH features, I would like to use SIO at first, and iLink in second one. So ETH would be the last option).
Thanks for your time.

PS: Up to now both <<< RDB-UIF - the standalone "UIF" version >>> and <<< RDB-UIF-RB (System driver update) - the "UIF", ReBoot version >>> are giving me BSOD.

 

I realized that RDB has a problem actually; unlike a development EE kernel (e.g. from the TDB startup card or a TOOL), the kernel does not actually automatically break after initialization is done.
The stock EE kernel seems to be getting stuck on something actually, when it should have run the OSDSYS program. In the case of RDB, the instruction within the README file is to just enter the "break" command from dsedb in order to be able to run a program. But the kernel wasn't ever in a proper state for running a program on command.

***

No, it does not enable anything that wasn't already enabled in code. It's not meant for debugging retail games, but homebrew software during development. This is meant to be a clone of the SONY TDB Startup Card, which was meant to give Debugstation consoles lite DECI2 debugging support.

No retail software actually used the serial port of the EE. While it seems to be true that the EE kernel will also redirect output over ektty (EE Kernel TTY) to the serial port, there was never any hardware that is connected to this interface on any SONY PlayStation 2 unit.
All TTY channels (On the EE and IOP) go over DECI2, to the development machine via Ethernet.

When you debug homebrew software, you will get output from the EE and IOP as with a TOOL unit. But since our homebrew software generally just write to the IOP-side tty device, output from both the EE and IOP will only appear via i0tty (IOP TTY 0).

It does not support the i.Link interface. Only Ethernet is supported, as with the TDB startup card.
If you require support for the i.Link or serial port, please use Kermit. I have no intention of supporting these interfaces, as they require more work and experience that I do not have.

 

Hello, everybody! This is my first message; long time lurker, first time poster, glad to be here

I've set up a Red Hat machine and been trying to run an EE demo from the SDK, and I'm close to getting it to work, but the last step fails. Hope you guys could guess what's going wrong.

In first place, i launch the RDB elf from a pendrive using uLE. I've set the network parameters in the memory card. After that, the screen goes blank and the PS2 is accessible through network, so all right until here:

Then I launch dsnetm and it seems to work:

If you try to launch dsdeb normally, it would try to reset the console and, thence, it would crash, so it's necessary to instruct dsdeb to not reset the console and, as the readme states, issue a break command. Finally, i load the program:

Then it repeats the same "can't load module error" and does nothing more.

Please note that I have no previous experience with Sony platforms (I'm more inclined to GBA), so please forgive me if i've forgotten / omitted something.

Machines i've tried on:

• SCPH-50004 (FHDB) (The "standard" version is the only that works, the UIF one doesn't respond to pings)
  
• SCPH-90004 (Clone matrix modchip) (This one doesn't even initialize the network PHY when launching RDB)

If anyone can hint a solution, thank you.

 

Welcome aboard!

Did you put those modules in the right place, as required? If you have not, please do so and try again.

If you did:

Are you using the SONY PS2SDK, or are you using the homebrew PS2SDK?
This RDB project was meant as a clone of the SONY TDB startup card. As with the TDB startup card, it is supposed to be built for a specific SDK version. But since homebrew software can only work with the default IOP modules, RDB is made to work with the default IOP modules and hence you may have problems running SONY software with this.

The TDB startup card, for as far as I have seen so far, came in sets for only SDK v2.8.0 and v3.0.0 (hence not compatible with homebrew software).

The reason is because SONY designed the I/O Processor (IOP) allow the game/program to load newer modules. Over the course of the PS2's lifespan, SONY had changed their software specifications a few times. There was one major overhaul of them at some point (around v2.3), resulting in actual compatibility issues if some modules/libraries are mixed.

By design, each game/program is meant to work with the modules/libraries that they were compiled with, hence why these startup cards are supposed to be specifically built for the SDK being worked with.
On a real TOOL unit, the system ROM is always flashed to contain the new modules of the SDK that the developer is working with. However, a CEX (retail)/DEX (DebugStation) unit doesn't have a flash chip and so the startup card will reboot the IOP to have the required IOP modules loaded. Hence the design of the startup cards:
1. You cannot reboot the IOP.
2. You cannot use LoadExecPS2().

 

Thank you for your response @sp193, very explanatory and educational (also, btw, thanks for your hard technical work at OPL, I'm a happy user of it).

I'm using Sony's SDK, v3.0.3 (the version that I found in this forum).

I think this was, in fact, the case, since I have now succeeded at booting the demo via RDB! .

The problem was related to pad input; the program was trying to load two input-related IOP modules from the host (via sceSifLoadModule("host0:/usr/local/sce/iop/modules/sio2man.irx" and padman.irx). The files existed in the machine but, as you say, the IOP could not load them. I commented out all code related to input and, indeed, it worked:

​

After that, I would prefer the open source toolchain. Does anybody know any good documentation for it (and the old version of the modules it uses). I looked at psx-scene and only saw tutorials scattered around, not a cohesive "ps2 for newbies" (like the TONC for GBA) that lets you appreciate the big picture.

Anyway, this question is solved and, indeed, RDB worked on my retail fat machine. Thank you!

 

i remember Startup card for Preview plus and it use iLink to host


btw, it a nice project

 

Honestly, I am surprised that you were able to follow my explanations because I am quite bad at making complicated things easy to understand.

Congratulations!

It still doesn't mean that it is working right though. :/
If it cannot load the modules, then your program would have no support for the pads.

I do not remember what needs to be done to get the paths working properly. The paths are relative to the ds*db debugger or dsfilesv daemon that you run. If multiple instances of these programs are run, then it depends on whichever instance was started first. I do not remember what will happen if a fixed path is specified.

There aren't any guides, sorry. This is the reason why the PS2 world is quite devoid of nice homebrew software.
You'll be better off just following samples and using the documentation from the SONY PS2SDK. The homebrew functions are similar.

That would be because psx-scene wasn't every exactly about PS2 development. Development used to be discussed on the ps2dev.org website and forums, until they got closed.

AFAIK, nobody has the startup card for this, if it even exists.

 

Oh, that's a shame. The PS2 looks like a nice machine, though. For the time being I will be moving to another city, so this is left in my backburner. Thanks for the information.

 

Many thanks for your great work on all things PS2, sp193!
This RDB card worked perfectly on my consoles, enabling us to better investigate hardware behavior for implementation in PCSX2.
(Also *very useful* was the CDVD timing / flags test you created for OPL!)

I found that many sce samples would not work using the RDB-UIF-RB card.
They tend to hang in SIF related functions, even when not loading any modules from the boot rom or HOST.

I wonder what could be done to improve this.
Would it help (be possible) to replace the boot rom with a changed IOP configuration file and added modules?
Could a modchip be used to help a retail console regain the disabled features?

 

Thank you. Glad to hear that this tool has been useful to you.

I realized there there's a big problem with RDB. Unlike the SONY TDB startup card, this one does not replace the EE kernel with one that will break upon boot. You may have noticed that the OSDSYS doesn't boot, even when RDB is loaded. It's because something has gotten stuck on something (I presume, SIF initialization).

Probably, to patch the EE kernel to break upon boot.

It would be possible, if you mod/replace the boot ROM. But that would also likely make your retail PS2 a lot less compatible with games because it would have a lot less IOP RAM. A TOOL unit has 8MB, unlike the CEX and DEX units that only have 2MB.

But no, it wouldn't help. The problem is on the EE side, and has nothing much to do with the IOP side.

Yea, perhaps. But it would require modding, which this project doesn't require.

Anyway, during development, the IOP shouldn't be rebooted and usually isn't rebooted. So not being able to reboot the IOP here, isn't really much of a loss unless one developes a multi-ELF program (i.e. a optical device emulator, like OPL) that will surely require reboots.

On a TOOL unit, If the IOP is reboot, then all breakpoints (on both the EE and IOP) set will be erased. It doesn't have to be rebooted, as the ROM of a TOOL already has the modules that the game needs. The reboot, is to load the necessary modules into a CEX/DEX unit's IOP RAM.

 

Okay, got it.
I don't worry about this retail unit loosing the capability to run games.
It would be more useful if it supported more iop modules, possibly even patched ones, to make reversing hardware behavior easier.
But from what you're saying, this isn't required, so that's cool. Saves me some hairy reflow action