Project: Retail DeBugging (RDB) startup card

Changelog for RDB v0.9.2:

• Updated the OSD setting initialization code.
• Added code that copies the OSD settings to the scratchpad, so that the TDB startup card kernel can retrieve them.
• Changed the initialization system for the stock kernel. The stock kernel will now be loaded from rom0 and patched.
• The stock kernel will now break upon initialization and on Exit(), like the TDB startup card's kernel.
• Fixed the mlist command for DSIDB; DECI2LOAD's support for the module LIST command under the DBGP protocol was broken.
• Added support for the use of an external IOPRP image, making it possible to use different IOP kernel modules.
• Refactored code for better reusability across the various variants of RDB.

To slimline the development process of RDB, I have decided that I am going to discontinue the development and support of the RDB-UIF, RDB-UIF-RB and RDB (system driver update) variants.
I discovered that the UIF versions don't seem to work on my SCPH-39006 and I couldn't figure out why. The only advantage that the UIF versions have, is that DSIDB can actually be used to debug IOP modules.
RDB-UIF-RB would have been more useful to debug retail software, but the goal of RDB was always more for aiding the development of homebrew software.

The system driver version of RDB would be very much like the TDB Startup Card, but installing FMCB and using it to auto-boot RDB would do the same thing. The startup card version of RDB used to have additional initialization code, but that has been merged into the normal RDB version. It is still possible to re-create a system driver update version by MagicGate-signing the RDB ELF.

The update to the OSD setting initialization is related to the recent update to FMCB: I've discovered that a version number (historically known as "region" within the homebrew PS2SDK) of 2 signifies that the Osd2 data will have the user's true language selection. Previously, the version number was set to either 1 or 2, depending on whether the console was a NTSC-U/NTSC-J or PAL/NTSC-C.

Downloads/links:
RDB v0.9.2: http://www.mediafire.com/?qp832rpsctcre8z
DSNET tool set (2014/03/28): http://www.mediafire.com/?oio3fbf81osi526

 

Changelog for RDB v0.9.3:

• Console initialization process moved earlier, to avoid interfacing with FILEIO.
• IOP reboot added, to ensure that the modules present at the console initialization process remain consistent across all console models.

The IOP may crash if RDB was supplied an IOPRP image newer than v2.0, due to FILEIO being of the newer design. To prevent this, the console initialization process is moved earlier and an IOP reboot is added.
The memory card is now the only supported boot device for RDB, from now on.

Downloads/links:
RDB v0.9.3: http://www.mediafire.com/?8l7umb7bwh2vt65
DSNET tool set (2014/03/28): http://www.mediafire.com/?oio3fbf81osi526

 

Nice! thank you!!

 

RDB v0.9.4 released!

Changelog for v0.9.4:

• SIF_SYSREG_RPCINIT will now be set for the stock kernel, to prevent the EE SIFRPC implementation from waiting on the IOP to initialize (when it already is).
• Added patch code to disable the reset of the GS (blanking of screen) when the stock kernel is used.

With this, I guess that using RDB with the stock EE kernel should be more usable.

The patch to disable the GS reset is in three parts:

1. Disable the call to SetGsCrt within Initialize (the function that prints "Initialize Start").
2. Disable the write to the RESET bit (0x200) of the GS CSR within InitializeEEGS (the first function called after "Initialize GS" is printed).
3. Later kernels (from ROM v1.70 and later) have additional initialization code, which also includes a write to SMODE1 (that sets the PRST bit). This exists within a new function that is called after the write to the GS CSR's RESET bit.

Downloads/links
RDB v0.9.4: http://www.mediafire.com/?1ok9919if0r9k3j
DSNET tool set (2014/03/28): http://www.mediafire.com/?oio3fbf81osi526

 

Thank you for the update. What version of linux do you recommend for running this? I have an older laptop that I want to run this on.

 

I think the tools should work on any modern version of Linux because I compiled the tools with Debian 6/7 (in 2014). I don't remember if it will work on x86 though, as my PC was a running a 64-bit installation.

But if you use the SONY tools, I don't know what is really suitable; so far they do work on Debian 7, but I have come across one person who had problems running dsedb on a late version of Linux (not Debian, but something else).

That being said, you probably need to try it yourself. Sorry.

 

They're 32-bit ELFs, dynamically linked. Should work fine on most common PC-based distros (unless you're running some funky alternative libc or a pure 64-bit system).

 

What do you mean by a pure 64-bit system?

I don't use a special version of libc, so that shouldn't be a problem.

 

> What do you mean by a pure 64-bit system?
One that doesn't have 32-bit libraries, for example Gentoo's "amd64-nomultilib". On such a system, the kernel might also be compiled without support for 32-bit syscalls, so you couldn't even "cheat" any more by setting up a 32-bit chroot...

> I don't use a special version of libc, so that shouldn't be a problem.
What I meant was, "if the end user has some wierd libc", like musl or uclibc. Most distros these days come with glibc -> not a problem; and users of one of those alternate libcs usually know what they're doing.

For the next release: if you want the absolute max in compatibility without releasing the source, compile static executables, that way all you need is a kernel with 32-bit syscalls - no more dependencies on any libs whatsoever.

 

Sorry if this seems pretty obvious, but are you telling me that my dsnet tools are indeed 32-bit tools? And that they will run fine on most PC-based distros (under the conditions that you specified)? And it's because you actually examined them?

If so, thanks. Really!

You're referring to the user's system, aren't you?
My Debian installations did not come with multilib installed, although I installed it later on (for the sake of Skype). I just had this feeling that my binaries are 64-bit because someone once mentioned something about an architecture mismatch.... but I don't remember that clearly.

Thanks for clearing things up for me.

Despite using Linux for more than 10 years already, it has been giving me a lot of weird problems. >_>

I guess this means more reading. :/
Thanks again!

 

> are you telling me that my dsnet tools are indeed 32-bit tools
> You're referring to the user's system
Yes to both.

> I guess this means more reading
Not really, just doing "cc -static -o dsfoo dsfoo.c" should be enough. Try "file dsfoo" afterwards to see what you got.

 

Thanks. if I do recompile those tools, I will try that,
For now, there are the SONY tools that are 32-bit.

 

Changelog for v0.9.5:

• Re-added the SONY customization to DECI2DRS - which is to not wait for transfers to end or to inform the EE of SIF2 shutting down.
• Added a delay to TIFINET, to allow the DCMP reset command packet to be sent to the EE before the IOP is reboot. This allows the DECI2 reset command to work.
• Re-added RDB-UIF.
• Updated to use LWIP v2.0.0.
• Removed POWEROFF.IRX, as the modern DEV9 revisions are no longer dependent on it.

Also, I have cleaned up the source code and released the code that is mine.

I do not know why, but without a delay after the DCMP reset packet is sent to the EE, the system gets stuck somewhere. Indirectly, that was why the reset command never worked.

Finally, unlike what I wrote in the README file, it is currently not possible to use ATAD with RDB-UIF (should be fine with RDB). I guess that it's because the DEV9 interface's interrupts are being handled in a different way by DECI2DRU, that ATAD gets confused.

Downloads/Links
RDB v0.9.5: http://www.mediafire.com/file/79fy03rwwbh3ycd/[170610]RDB-095-bin.7z
RDB v0.9.5 (source code): https://www.mediafire.com/?vsgw3g91d7mk90z
DSNET tool set (2014/03/28): http://www.mediafire.com/file/oio3fbf81osi526/[140328]dsnet-bin.7z

 

Hi. In Windows Bash ive got this error:

Code:

-bash: ./dsidb: cannot execute binary file: Exec format error

Maybe it is possible to recompile it as static?

file dsidb shows me

Code:

ELF 32-bit LSB  executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=fc45dc8f3c6845cf6b5a5b8c1ed71eb091707182, not strippedr

I just found that there is no way to run 32-bit executables under Windows Bash. Maybe it is possible to provide 64-bit executables?

 

Thanks for sharing. I guess I can restructure the libraries to allow all the tools to become 64-bit.

BTW, as of now the debugger clients still have some problems. I haven't managed to fix them yet, so some features do not work. For example, the "dt" command can cause dsedb to crash.

 

sorry off topic .
any good way to copy real Start up card ? it band new , i want clone it by no use data
is it good run RipMCFile in T10K or use QATOOL copy to other card ?

 

You cannot just copy the contents because the boot file is signed for the card itself. If you copy the files, the files will not boot on a different card.

To complicate things, a file signed for a DEX will never boot on a CEX.

 

@sp193 thank info.
so keep it no touching is better

 

Hi @sp193.
After take a look on your document and the source code .

Spoiler: code

#define DBGP_GROUP_ENTIRE_SYSTEM 0
#define DBGP_CODE_CONT 0x00
#define DBGP_CODE_STEP 0x01
#define DBGP_CODE_NEXT 0x02
#define DBGP_CODE_OTHER 0xFF

#define DBGP_TYPE_GETCONF 0x00
#define DBGP_TYPE_GETCONFR 0x01
#define DBGP_TYPE_GETREG 0x04
#define DBGP_TYPE_GETREGR 0x05
#define DBGP_TYPE_PUTREG 0x06
#define DBGP_TYPE_PUTREGR 0x07
#define DBGP_TYPE_RDMEM 0x08
#define DBGP_TYPE_RDMEMR 0x09
#define DBGP_TYPE_WRMEM 0x0A
#define DBGP_TYPE_WRMEMR 0x0B
#define DBGP_TYPE_GETBRKPT 0x10
#define DBGP_TYPE_GETBRKPTR 0x11
#define DBGP_TYPE_PUTBRKPT 0x12
#define DBGP_TYPE_PUTBRKPTR 0x13
#define DBGP_TYPE_BREAK 0x14
#define DBGP_TYPE_BREAKR 0x15
#define DBGP_TYPE_CONTINUE 0x16
#define DBGP_TYPE_CONTINUER 0x17
#define DBGP_TYPE_RUN 0x18
#define DBGP_TYPE_RUNR 0x19
#define DBGP_TYPE_XGKTCTL 0x20
#define DBGP_TYPE_XGKTCTLR 0x21
#define DBGP_TYPE_XGKTDATAR 0x23
#define DBGP_TYPE_DBGCTL 0x24
#define DBGP_TYPE_DBGCTLR 0x25
#define DBGP_TYPE_RDIMG 0x28
#define DBGP_TYPE_RDIMGR 0x29
#define DBGP_TYPE_SETBPFUNC 0x2E
#define DBGP_TYPE_SETBPFUNCR 0x2F

Can I use IOP to take full control of EE CPU ?

 

In a way, yes. You can remotely control the debugger, with DECI2. On the T10000, DECI2 is used boot programs by loading the ELF with the WRMEM command and running the loaded image.