I posted this in another old thread, but thought it would be easier to start my own instead. I'm having the same issue with my new (new to me) PS2 Tool. Upon startup, the mrp driver loads fine, and the TOOL LED in front lights up green properly as well. The issue is that any of the ds* commands in /usr/local/sce/bin I try all fail, stating that they cannot connect. Example screen shots are below. All DIP switch settings are correct on the rear for my NTSC TOOL, and I also verified the switches in front (CD/DVD is set, as well as TOOL). n addition, during shut-down, the mrp driver unloads properly, and I can see that everything powers down correctly. In order for powerctrl to shutdown the PS2 side correctly after, say, issuing a 'shutdown -h now' from the Linux side, doesn't this signify that the physically, everything should be ok inside my TOOL (serial connection good; SBC seated properly in PCI slot)? I'm not getting any video output form the PS2 multi-AV out (composite cables or component). The strange thing is that the online store I bought it from showed me a picture (verified with the MAC address of my TOOL) of the TOOL screen working, so this is strange to me.. My TOOL is in very good shape physically/aesthetically, and traveled a relatively short distance to me (from Seattle, WA to San Francisco, CA). One thing that I did find during the boot-up sequence under 'Starting dsnet' is that sam.o (/usr/local/sce/driver/2.0.36/sam.o) cannot be found. Is anyone familiar with this driver? I'll try to upload screenshots later since I'm currently having some image upload issues with the forum.
From my memory, all DECI2 programs will give that "no connectr" error if they can connect to the DSNETM server (which is the TOOL), but do not get a response from the IOP through DECI2 when the CONNECT command is sent. This could possibly be because the IOP/EE has gotten stuck, due to a hardware fault. You mentioned that you do not see the network information screen. Do you see this screen after the TOOL boots up, if you do not log in? Officially, the developers were never able to log into the TOOL and did everything remotely. If you reset (either by pressing the blue reset button or through DSIDB/DSEDB/DSRESET) the PS2 side of the TOOL, the program that displays the network information at boot will be cleared from RAM. The SAM driver fails to load on my DTL-T10000H unit that I have. I think that it's for some other peripheral that our units do not have. The most important one is the MRP interface, which is the interface to the PS2 side from the PC side. As for power management, it is controlled from the PC side for at least TOOL mode.
Thanks for your response. Even if I don't login to Linux on the PC-side, I still don't get the TOOL network screen. I'm not sure if this makes a difference, but earlier today, I setup my TOOL to use my DHCP server, which works well. I'll need to eventually open up my TOOL, but what specific interface is used for communication between the Linux running PC x86 SBC and the PS2 motherboard? Is it through the backplane (SBC PCI backplane connection & PS2 TOOL Motherboard backplane connection), the serial link, or both? I seem to be having a similar issue to superspeed, when he had his TOOL: http://www.assemblergames.com/forums/showthread.php?39047-Connecting-ps2-Tool-to-tv. He never did figure out what the issue was.
Also, my understanding from another forum post in a thread (which I cannot find at the moment) is that the 'devtool-opening' bash script that executes gstitle.elf (responsible for the TOOL network screen) is called within the boot-up process (init.d I believe, since we're talking about Linux). If this is the case, I can understand not seeing the PS2 TOOL network screen on boot-up being a manifestation of devtool-opening not executing correctly due to my dsnetm connection issues. For example, when I execute ./devtool-opening from my bash command prompt, I get a "No such PID" error.
Like I mentioned above, something is causing the PS2 side to get stuck. Since it isn't working, the opening screen cannot be displayed. :/ Is the CD/DVD drive's blue LED lit? They wrote that the PS2 side is dead, if that LED isn't lit. The SBC is a PCI card that is connected to the rest of the system, and also has a serial line connected. I have no idea which part is actually responsible for communication, but it could be several interfaces (e.g. there's the mrp0c interface that is used by the IOP ktty interface, which appears to be a COMs port... so maybe that's the serial line?). Someone else with actual experience with the hardware will have to answer this question. How about setting it to WS mode before powering up? Just in case it had a bad flash? You could try to get some information by doing this: 1. Start dsmcons. 2. Enter "record dsnetm.log", followed by "show log" at the prompt. 3. Press CTRL + ']' to quit the prompt. 4. View dsnetm.log with "cat dsnetm.log | less". A healthy TOOL would show connection attempts (and responses!), to and from the I (IOP) and E (EE) nodes: This was recorded from my host PC.
I'll have to try using dsmcons later tonight (have been busy), but yes, my CD/DVD drive's blue LED is indeed lit. In addition, if I look behind my PS2 TOOL while it's on, I can see that the Optical Audio jack is indeed lit red, and there are some red LEDs that I can see lit near the PCMCIA slot.
