Tool drives

If I remember correctly from some older thread unclejun mentioned illigal media, i think using another type/brand or color of writable media did the trick but i dont remember the details.

 

Okay, well I hadn't read your reply and went ahead and tested the software theory out and it isn't at fault. By placing the HDD from the unit that previously gave the "illegal media" error into the housing of the working unit, I managed to get software to run on DVD drive 1 & 2. Thus, it must come down to some hardware nonsense.

So, what you are saying is the UJ had this issue and managed to bypass it? Excellent, so it's potentially NOT a motherboard problem! I thought that perhaps in the older unit I had damaged something inserting a laser other than that originally equipped within the DVD drive.

I'll PM him! Thanks!

 

There we go! Two working units again. I had the older unit working with the other laser, but I must have grabbed one of the few blue discs I own.

So, that's 2 fully functional PS2 Tools. Why does the older T10k only want to read blue discs and copies? It's not controlled by the software on the HDD and certainly, unlike on a retail, has nothing to do with the laser fitted to it. As it reacts the same way no matter which DVD drive I install.

One of the earliest signs of laser failure is that your retail unit only reads CD or Blue discs and fails on DVDrom etc, so my immediate thought was "this isn't shafted from the off!" - apparently not!

WOOHOO!

 

So...have you got the older one to read DVD roms or will it only read CD media?

 

Thanks for the replies!

Checked. The laser seems to be fine. Why don't I get any error messages... hmm...

I am sorry to hear that port187. Let's hope it's a software issue and fixable. I took the TOOL apart today and cleaned all parts. Everything looked good and properly connected. It it still working too I will now continue troubleshooting software, since I am pretty confident the hardware is good.

I noticed that error message in a photo in one of the posts here

I am starting to believe that I may have a Flash ROM issue, and my need to reflash it. Would anyone help me by running /usr/local/sce/bin/dsidb and tell me their Flash ROM version?

I.e. the line starting with FlashROM. It may look something like this:
"FlashROM boot <20010219-213228,ROMconf,t10000-relXX.bin:11824>"

 

Currently only reading CD type blue PS2 discs. However, it is NOT, repeat NOT a laser fault as I have swapped the drives between both units and each laser is doing exactly the same thing, whether the older KHS400 or the new 400H. Both read perfectly well in machine #2 - pretty much any media I try. Both only read CDr media in machine #1.

 

ConsoleFun, the rom version checking is a good idea, I will post mine when I have re-cheked my (4) drives...
But the problem might be the cd/dvd controller:
http://www.assemblergames.com/forums/showpost.php?p=215245&postcount=115

 

I remember reading that and thinking "Oh no!" however I was hoping I was immune from it lol - the fact it reads the blue style disc is something. If it is how the unit is designed then I am happy. It doesn't look like it's a fault of any kind and I have tested all the main components by swapping between machines.

 

This is what I get:

CPUID=15, ROMGEN=2000-0117, CACH_CONFIG=1edd8, 8MB, IOP mode, ROM boot
<20000117-073038,ROMconf,:11792>
SW=b7:^^^^___^:b0, RESET parameter EE=00000000_00000000, IOP=00000000_00000000

 

I get exactly that too... Think we are in the same boat. Is this what you get too UJ? Parris?

Reading every piece of info I can find on the IOP and ROM/FlashROM right now. Running strings on binaries and what not, hehehe Would be nice to understand exactly how the TOOL works, like:
Is the only purpose of the WS/TOOL switch to select FlashROM area?
Do we actually use the FlashROM now, or is there a default ROM that we use?

I believe the i/o processor (IOP..) is the part of the PS2 that handles both the ROM/FlashROM and the CD/DVD drive. I am hoping that experimenting with /usr/local/sce/bin/dsi* utils might give some more clues as to how this works and what that is going on

 

I've not checked and just taken it all down and packaged it up as I'm going to trade / sell the newly repaired unit - sorry!

I don't feel the need for two almost identical units - had one of them been a T15k I'd probably be keeping it. However, I am sure UJ will report back.

I'm definately keeping the newer unit and I have fitted a new 3rd party laser to it so all going well, it will last a few more years!

Keen to see what you come up with though.

 

As far as the docs tell, the t10k should be booted on WS mode only if the flashing fails while in Tool mode.
The problem might be the version of the IOP, and you can't do anything about it...
The date of the rom could be an indication of how old is the unit (unless the company wich runned it downgrade the rom to a previous version), for example on my 1st unit, the Romgen code is 2002-0722 and it's using the t10000-rel255.bin


I want to try something later, running the ps1drv with a ps1 disc in the tray...

 

No problem Parris UJ comes to the rescue!!! This is kind of fun too, as we're forced to learn at lot about the whole system. I like that.

Just ran a bit of diag. The diag scripts require a 8 digit MPU board ID. I just used 02603667, which isn't actually the ID for the board in my unit, but is a semi-random working number . Here are the results from the MPU test. Think MPU means "Multiprocessor Unit" and that the MPU board is the big PCB with the EE, GS and three smaller daughter boards. It's a quite big test. Here goes:

Code:

[root@devtool /root]# cd /usr/local/sony/diag/MPU4DIAG
[root@devtool MPU4DIAG]# ./diagmain.sh 02603667 > ~/diagout.txt &
[1] 2817
[root@devtool MPU4DIAG]# cd
[root@devtool /root]# tail -f diagout.txt
@@ START MPU DIAG 1.8-2 20070819 22:28:15 @@
@@ CHECKING SBC @@
02603667: SBCnet: == NG 20070819 22:28:15 ==
@@ CHECKING BP2 @@
02603667: bpregcheck: == OK 20070819 22:28:15 == REMOTE
02603667: DAEMON: == OK 20070819 22:28:15 == REMOTE
@@ CHECKING IOP @@
02603667: ioprun: == OK 20070819 22:28:17 ==
02603667: ioprun2: == OK 20070819 22:28:20 ==
02603667: iopmpubid: == OK 20070819 22:28:23 ==
02603667: iopdswchk: == OK 20070819 22:28:25 ==
02603667: iopcpu: == OK 20070819 22:28:31 ==
02603667: iopmemsize: == OK 20070819 22:28:34 ==
02603667: iopmem0: == OK 20070819 22:28:39 ==
02603667: iopmem: == OK 20070819 22:28:56 ==
02603667: guidchk: == OK 20070819 22:28:59 ==
@@ CHECKING EE @@
02603667: eerun: == OK 20070819 22:29:08 ==
@@ current ROM rev=PS20100TD2000017 @@
@@ require ROM rev=PS20100TD2000017 @@
02603667: chkromrev: == OK 20070819 22:29:51 ==
== current BoardID=MPU4-01-12, EE=2.6-2.9, GS=ES4.91, IOP=ES3.1, SPU2=UNKNOWN, PCIC=UNKNOWN
== require BoardID=MPU4-01-12, EE=2.6-2.9, GS=ES4.91, IOP=ES3.1, SPU2=UNKNOWN, PCIC=UNKNOWN
02603667: chkrev: == OK 20070819 22:31:20 ==
02603667: eebp2reg: == OK 20070819 22:31:30 ==
02603667: eecpu: == OK 20070819 22:32:20 ==
02603667: eeclock: == OK 20070819 22:32:25 ==
02603667: eememsize: == OK 20070819 22:32:31 ==
02603667: eemem128: == OK 20070819 22:32:58 ==
02603667: eexmem128: == OK 20070819 22:33:28 ==
02603667: eemm: == OK 20070819 22:33:34 ==
02603667: eevu0: == OK 20070819 22:33:40 ==
02603667: eevu0m: == OK 20070819 22:33:46 ==
02603667: eegif: == OK 20070819 22:33:53 ==
02603667: thsample: == OK 20070819 22:33:59 ==
@@ CHECKING I/Os @@
02603667: ipu: == OK 20070819 22:34:25 ==
02603667: eefile: == OK 20070819 22:34:55 ==
02603667: eefile2: == OK 20070819 22:35:08 ==
02603667: eeusbreg: == OK 20070819 22:35:14 ==
02603667: iop1394reg: == OK 20070819 22:35:16 ==
02603667: iopmemcard: == NG 20070819 22:35:19 ==
02603667: eei2cven2: == OK 20070819 22:35:25 ==
02603667: eedifreg: == OK 20070819 22:35:31 ==
02603667: spu2sinwavea: == OK 20070819 22:35:48 ==
02603667: spu2sinwaved: == OK 20070819 22:36:04 ==
02603667: ramp: == OK 20070819 22:36:10 ==
02603667: ramppal: == OK 20070819 22:36:15 ==
02603667: rampvesa1: == OK 20070819 22:36:21 ==
02603667: rampvesa2: == OK 20070819 22:36:27 ==
@@ CHECKING GS @@
02603667: gstfr: == OK 20070819 22:36:48 ==
02603667: gsloadgpu4: == OK 20070819 22:37:26 ==
02603667: gsloadgpu4_cmp: == OK 20070819 22:37:27 ==
02603667: gsloadgpu5: == OK 20070819 22:37:49 ==
02603667: gsloadgpu5_cmp: == OK 20070819 22:37:50 ==
02603667: gsloadgpu6: == OK 20070819 22:38:13 ==
02603667: gsloadgpu6_cmp: == OK 20070819 22:38:14 ==
## SOME ERRORS DETECTD ##
## SKIP APPLICATION TEST ##
## ERROR TESTS in  SBCnet iopmemcard ##
## MPU DIAG NG ERR=2##

The ipu test displays a nice animation, spu2sinwav outputs audio, loadgpu displays 3D graphics etc. etc. Quite cool. At least some hardware is working

My unit did not pass the SBCnet and iopmemcard tests (result=NG). The iopmemcard test I don't worry about yet and will check later. I also run a DVD drive diag script, and that did not even start because of the SBCnet failing! ....

[EDIT - This is wrong: I blieve that the "SBC" board is the board with the flat flex connector for the CD/DVD drive, PCMCIA slot, etc....]
As UJ says below, SBC is short for Single Board Computer, and would be the PCI card then...

 

You can (and should) run all these tests from the web interface actually, SBC is short for Single Board Computer.
For SBCnet, your Tool must be connected to the network, the iopmemcard is pretty explicit...

 

Somehow I probably forgot I had put the TOOL in WS mode, this prevented discs to run.. now that I set it back to TOOL mode it runs the games fine again! I was worried there for a sec I busted the cable somehow when opening up/upgrading the unit ah well all well

 

LOL -God, I love it when these little errors creep in as it points out errors that others may encounter.

I would strongly advice anyone who has opened the unit and removed the PSU or cut the cable ties to replace it. I opened the older unit last night and discovered that the plastic connector for one of the cables was sitting actually directly on top of the GPU fan. Had I switched it on it probably would have fried the bloody thing as the fan would have been affected.

Just something to note - cable ties a MUST!

 

Now that I have the unit in TOOL mode it comes up with this:

CPUID=15, ROMGEN=2003-1031, CACH_CONFIG=1edd8, 8MB, IOP mode, ROM boot
<20031031-193432,ROMconf,t10000-rel300.bin:11856>
SW=b7:^^^^___^:b0, RESET parameter EE=00000000_00000000, IOP=00000000_00000000

 

I am glad to hear you got yours working again!! Turns out we're not in the same boat then....

Regardless if the switch is set to TOOL or WS, I get exactly this:
CPUID=15, ROMGEN=2000-0117, CACH_CONFIG=1edd8, 8MB, IOP mode, ROM boot
<20000117-073038,ROMconf,:11792>
SW=b7:^^^^___^:b0, RESET parameter EE=00000000_00000000, IOP=00000000_00000000

I suspected it might have something to do with the DIP switches, so I actually tested the switches with a multimeter yesterday, but I did not test the cable to the PCB. Guess I have to do that now...

Update: I checked the cable too. It is fine :-/

 

Thanks UJ! I just ran the full test from the web interface. Everything was OK, but that was because the "SBCnet" and "MEMORYCARD" test was commented out when I checked the "ViewCatalog" webpage. Maybe there is something special about those tests.

Another interesting thing... I was using the default IP address of "192.168.0.10". Guess what I found in the SBCnet bash script:

Code:

if [ X${IP} = X192.168.0.10 ]
then
        ERR=2
fi

No wonder the test failed. So, I changed the IP to 192.168.0.5, and the SBCnet test passed with "OK"....

Anyway - still the same problem with the flashrom and drive.... :-/

 

Thanks to UJ - the MASTER of the PS2 TOOL - I just booted my first game disc A longer post will follow....