• Hey, Guest!

    XenForo 2.2 is coming soon, it's bringing many new features such as a PWA app for OG etc. It also comes with the drawback of more costs to update themes/some addons. It'll also remove access to some older browsers which'll suck but these shouldn't be used as their security sucks.

    With the costs already looming we decided to improve OG's look with a new fancy theme that gives OG a more gamer feel. This has cost us only slightly more than it would have cost to renew the current theme and runs alot nicer.

    You can beta test it here: Linky. (Please note only dark is live, light will come once issues are ironed out.)

    If the current theme breaks on update we will end of life it, but we'll make something looking similar based on the default free theme so don't fret!

PS2 TOOL Version/Game Booting Questions

water111

Registered
Registered
Joined
Jun 2, 2019
Messages
8
Reaction score
3
Hi all,

I recently got a PS2 TOOL (T10000H), and had a few questions.

First of all, I noticed that the Linux SBC has 128 MB of RAM. This seems like more than it should be.
Second, I noticed that the root user's password has been changed from the default of "administ", and the user "z" with password "z" is missing.
However, there is a user ez, with password ez. I tried logging in as this, and got some weird prompt, and decided not to mess with it.
Any thoughts on why?

Another weird thing is it has the DVD emulator, but the kernel module for the DVD emulator doesn't work with the installed kernel. The MRP driver is for the correct kernel (and there's also a version for the old kernel that the DVD emulator is for).

The next thing I tried to do was run a game. I used "dsreset 100 2", but this immediately caused the PS2 side to stop running after reset. I used "dsedb" as a debugger and saw that very quickly the kernel would reach a break instruction. I read in some documentation that the feature of "dsreset" which enables you to boot a retail game was added after the TOOL was released. I wrote a program for the PS2 side which would dump the contents of the BIOS ROM, and I saw that the BIOS ROM was very old. For example, it used the IOP Runtime Kernel 0.9. I compared it to the BIOS ROM t10000-rel300.bin and saw it was missing the modules for booting from DVD drive.

To try to fix this, I flashed the ROM to t10000-rel300.bin from the SDK. After this, I could use "dsreset 100 2", and I hear the disk drive begin to spin up, and I see that the game's ELF file is loaded and starts executing. However, there is still a problem, and the game doesn't load. I think the problem is with the IOP. The TOOL's BIOS ROM has IOP kernel 2.2 on it, but the game tries to load IOP kernel 2.1. When the game calls sceSifRebootIop, the IOP reboots, but comes back running 2.2. The game then calls sceSifSyncIop which always returns a failure code, and the game is stuck in a loop. The IOP has definitely come back from the reboot - the game spams a printf("Syncing...\n") every time sceSifSyncIop fails, which makes it back to my development computer.

Is it possible that if the game I'm trying to run has an older version of the IOP kernel, it won't be replaced? Has anybody had an experience like this, or any suggestions? I am using an older game (Jak and Daxter), which is older than the SDK.
,
I've also verified I can read stuff from the disc by writing my own program which loads IOP modules that came with the SDK, loads a file with Sony SDK functions, and does a checksum on one of the files on the DVD.

Thanks!
 

uyjulian

AG Refugee
Refugee
Registered
Joined
May 30, 2019
Messages
69
Reaction score
30
Is the SBC running Red Hat Linux 5.2 or 6.2?

To use IOP functionality at release 1.3.4, set bit 8 of the IOP boot parameter.

Also, ensure that DIP switch #1 (1-indexed, away from the PSU) is off (switch is positioned towards the ports) and the "TOOL/WS" switch is positioned towards the "TOOL" position to ensure that you are using the correct ROM.
 
Last edited:

Borman

2020 Donator
2020 Donator
2019 Donator
VIP
Refugee
Registered
Community Contributor
Joined
Jul 31, 2018
Messages
94
Reaction score
190
Stop running things on the PC side (assuming you are). You can do updates with ProDG I believe.
 

water111

Registered
Registered
Joined
Jun 2, 2019
Messages
8
Reaction score
3
Thanks for the suggestions!

It is running 6.2, with kernel 2.2.14-5.0. I am running things on a remote computer, and not directly on the Linux SBC. I only needed to access the Linux SBC once to reset the network settings and clear the BIOS battery warning.

I have checked the DIP switches in the back, mine are down, up, down, down, up, down, up, up.
Both switches in the front are in the UP position, and the red TOOL Led on the inside (below the hard drives) is lit up.

I have figured out what is happening. It is very weird, and specific to the game Jak and Daxter. All other games I have are working fine. I thought I would post what I discovered, and two ways to work around it, if anybody else has this problem.

Basically, Jak has code like this, and it gets stuck in the loop with "Syncing..."

Code:
    printf("Rebooting IOP...\n");
    while (!sceSifRebootIop("cdrom0:\\DRIVERS\\IOPRP221.IMG;1")) {
      printf("Failed, retrying...\n");
    }
    while (!sceSifSyncIop()) {
      printf("Syncing...\n");
    }
The data to be sent to the IOP for the sceSifRebootIop call never makes it to the IOP. This somehow caused by the printf of "Syncing..." in a loop. So the IOP never is rebooted, and the Syncing never completes.

I managed to get the game to work in two different ways.

The first is to wait for the EE to get exactly here, and do a "break"
Code:
dsedb R> reset 2 100

EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01
  CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M

# Restart Without Memory Clear.
# Initialize GS ...NTSC mode
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize Scratch Pad ...
# TLB spad=0 kernel=1:12 default=13:36 extended=37:47
# Restart Without Memory Clear Done.
# ExecutePs2GameDisk
# TLB spad=0 kernel=1:12 default=13:36 extended=37:47
# Restart.   
# Initialize GS ...NTSC mode
# Initialize INTC ...
# Initialize TIMER ...
# Initialize DMAC ...
# Initialize VU1 ...
# Initialize VIF1 ...
# Initialize GIF ...
# Initialize VU0 ...
# Initialize VIF0 ...
# Initialize IPU ...
# Initialize FPU ...
# Initialize User Memory ...
# Initialize Scratch Pad ...
# TLB spad=0 kernel=1:12 default=13:36 extended=37:47
# Restart Done.
*** Resetted  
              
EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01
  CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M

dsedb R> break
I see from the IOP side that the main game ELF has loaded, and the game is waiting on the CD drive to initialize, before it reaches the IOP reboot code. At this point, I patch out the call to printf with

Code:
dsedb S> as 0x103424 nop
After doing this, I then see that the game is able to successfully load its IOP kernel onto the IOP. Previously, I did not see the "use alternate ROM image", and the IOP kernel ver. 2.1 is never loaded.

Here is what the IOP does when it successfully loads the IOP kernel with this approach:
Code:
Get Reboot Request From EE
*** Resetted
        
Update rebooting.. reset parameter for IOP=00000000_00000100
cdvdman Init
  use alternate ROM image
*** Resetted
        
Update reboot complete
cdvdman Init
        
IOP Realtime Kernel Ver. 2.1
    Copyright 1999-2001 (C) Sony Computer Entertainment Inc.
        
IOP DECI2 manager Version 0.9.1
    Copyright 1999 (C) Sony Computer Entertainment Inc.
        
DECI2 manager start.
But this is very challenging to get the timing right for. You need to enter the break command after your see the final "Resetted" message from the EE, because this is when the game's ELF will be loaded. But you also need to do this _before_ the Syncing... loop. All breakpoints are cleared at the "Resetted" message, so you can't set a breakpoint at the beginning of the program

I found another method that makes the timing much less tight.

The solution with this is to do a "reset 0 100" on the IOP side, then do a "mstart rom0:UDNL". This loads the IOP with an ancient kernel in test mode. Then I can copy the game's ELF file onto my computer, and load it with "pload". Then, when it is run, in between the reboot and sync calls, the DECI2 Manager is not connected, so the printfs are never sent anywhere, and the IOP can reboot as normal.

Code:
Rebooting IOP...
*** Resetted
;; in here, it is calling printf("Syncing...\n"), but DECI is not connected, so no issue.
*** No Connect
*** Resetted
        
EE DECI2 Manager version 0.06 Oct 31 2003 19:02:01
  CPUID=2e14, BoardID=4126, ROMGEN=2003-1031, 128M
Here is a video which shows the second method (with some additional patching to enable a debug mode that only works on a TOOL):
(it may still be processing)
 
Top