TOOL Software/Hardware Update & Rebuild Project

So after reaching a point with my system that I'm pleased with for initial "stock maintenance" in terms of establishing a target box, getting the SDK tools, CodeWarrior, and ProDG to communicate effectively, I've moved on to a set of goals I've established for my project to make maintaining and using TOOLs more manageable:

1) Archival of DD (or other raw-file) hard drive dumps from the primary 2 drives:

1a) Secondary Disks (attached to the PS2) are ideal candidates for factory reinstalls. This is a high priority, and should be done before ever attempting to boot off this drive so as to get a proper image as shipped. If the drive has been booted off of, and only used lightly, it's still of use, but can not be used as a reference image for a factory install.

1b) Primary Disks (attached to the SBC) are useful for exporting core updates from, as only the RPMs for DSNet seem to be floating around.​

2) In harvesting images from 3 TOOLs thus far, I have found that very basic installs of Red Hat Linux 5.2 and 6.2 are used, with the exception of the addition of < 10 specialized RPMs from Sony to support the board drivers, debugger interface, web frontend, and other unknown items. This stage involves:

2a) Creating an inventory of installed RPMs found on images.

2b) Reconstructing any non-redhat RPMs for reinstallation.​

3) TOOL hardware components frequently need repair and/or upgraded:

3a) Fans (Loud and bearings are going)

3b) Hard drives (Speed/size is generally unimportant, reliability and noise is. Flash storage, SSD, etc may be valid options)

3c) Power supply (Power consumption, even when idle seems to hover around 170 Watts, can this be made more economical with a replacement power supply made in the last 10 years?)

3d) SBC and CPU (while the 233/566 examples exist as stock Sony options, with the rebuilding of the packages, can a more modern SBC be used on a more modern install of Linux? At least this would revitalize systems that had dead boards, or allow further usage of the existing system as more than just an intermediary between development desktop and TOOL)

3e) Case parts and general ports, switches, cables.​

All things aside, while I am far from an expert on the TOOL, I feel like I have a relatively solid working knowledge of the way the PC half functions (pretty straightforward in the world of embedded systems, or for that matter, even normal computers), and at least, my intention to collect this knowledge into a usable document may be of use to others.

Thoughts? If there's no real arguments in the upcoming day, I'll start using this as a worklog and/or a place for updates...

 

Fans:

1) Top Case Fan
40x20mm 12V 2-wire 4-pin MATE-N-LOK
Sanyo Denki 109p0412h626

2) PS2 Fans (2)
50x10mm 12V 2-wire locking 2-pin
Nidec D05X-12TS3 01

3a) SBC Fan (233MHz)
50x10mm 5V 2-wire 2-pin
Y.S.Tech FD0550107B2N

3b) SBC Fan (566MHz)
50x10mm 5V 3-wire 3-pin
Original model TBD
​

Power Supply:

300W ATX
Nipron PCSA-300P-X2S1
​

Hard Drives: (bytes indicate size of total partitions)

233 MHz
SBC Drive (defor, daytonausa, ?, Midway Games)
IBM DTLA-305030
5831594x512 bytes
Red Hat Linux 5.2
Wed Feb 21 12:44:58 2001

PS2 Drive (factory)
IBM DTLA-305030
5831594x512 bytes
Red Hat Linux 5.2
Thu Feb 22 07:12:01 2001

SBC Drive (Mugi, ?, Parris, ?)
Seagate ST340810A
5831594x512 bytes
Red Hat Linux 5.2
Wed Mar 26 00:51:06 2003

PS2 Drive (factory)
Seagate ST340810A
5831594x512 bytes
Red Hat Linux 5.2
Mon Apr 22 10:46:08 2002

566MHz
PS2 Drive (Mugi, ?, Parris, ?)
Seagate ST340810A
5847659x512 bytes
Red Hat Linux 6.2
Fri 28 Mar 2003 02:52:19
​

 

A few notes for replacing the power supply:

1) The external bracket that wraps around the right and bottom of the psu is unnecessary, and prevents the use of some (perfectly legitimate, but larger) ATX power supplies. It can be romoved with little to no impact on the mounting, although one should find alternate routes for the system cables.

2) 24-pin atx connectors WILL fit without running into anything on the PCI backplane, BUT (at least in the case of the 233MHz board) puts minimal pressure on the right SIMM slot.

3) To power a TOOL, a minimum of the 20(24)-pin ATX connector is needed, as well as 5 mate-n-lok plugs (upper case fan, 3 drives, and sbc auxiliary power) should be accessable. Splitters are acceptable, and can help reduce cable bunching between the PSU and the DVD-ROM drive. I highly recommend either investing in a modular PSU, or preferably, desolder unused cabling from the rails inside the power supply.

4) MOST stock power supplies WILL fit, although one consideration must be given, if you wish to put the back plastic back on the case:

NOTE the orientation of the power switch and jack. MANY ATX power supplies have these reversed, and the back panel will NOT fit without cutting (not really preferable if you wish to retain the system's value and look)

 

Some notes on replacing the SBC boot device with flash memory:

1) I recommend using a standard 40-pin IDE to CF adapter.
While industrial flash module will work fine, they are harder to use outside the system (important for maintenance and upgrades). SSD drives are a good option, but given the low amount of drive access, their speed is higher than needed, and cost is highly inflated as well.
If you choose an IDE-socket mounted CF adapter, and you do not intend to use an emulator card or the secondary drive attached to the PS2 board, the entirety of the lower corner of the case's mounting hardware may be removed, freeing up valuable airflow and cable routing space.
Dual-slot adapters are acceptable as the SBC WILL recognize both master and slave drives. This could be of use for testing multiple OS configurations by changing BIOS boot order.

2) Neither SBC offers power on pin 20, so you will need an adapter that provides power to the CF card by external means, generally mate-n-lok or floppy power conector. You can reroute one of the normal HD power leads for this purpose.

3) All images discovered thus far use slightly less than 3GB of a drive, as thus, a 4GB CF card will be FAR more than sufficient, but larger cards CAN be used instead, especially if a custom install is of interest.

4) Due to the age of the Red Hat builds on the TOOL, a CF card imaged directly off a system WILL NOT BOOT DIRECTLY.
This problem is tied to the age of the LILO boot loader used on these installs.
Either LILO can be upgraded to a version supporting the "lba32" flag in lilo.conf, OR one may use GRUB as their bootloader instead (recommended).

 

Compiling a list of RPM's from user's systems and elsewhere:

Code:

[FONT="Courier New"]
[B]buildhost	package[/B]
caster.msacaster.msa.co.jp	apache-ps-1.0-2
gazelle197.msa.co.jp	apache-ps-1.0-2
caster.msacaster.msa.co.jp      dhcpcd-0.70PS-4
sirius                          dsnet-0.1.65-1
                                dsnet-1.16.0-1
kuma-t10k                       dsnet-1.2.0-1
kuma-t10k                       dsnet-1.2.0-4
localhost                       dsnet-1.23.1-1
isdiag2.sm.sony.co.jp           gstool-1.2-1
kuma-linux.rd.scei.sony.co.jp   gstool-3.1.0-1
caster.msacaster.msa.co.jp      initscripts-3.78PS-5
gazelle222.msa.co.jp            initscripts-5.00-2
gazelle222.msa.co.jp            kernel-2.2.14-5.0
gazelle222.msa.co.jp            kudzu-0.36-2
isdiag0.sm.sony.co.jp           powctrld-ps2dev-1.2-3
oji7f-dh2-234.sm.sony.co.jp     powctrld-ps2dev-1.2-4
isdiag0.sm.sony.co.jp           powctrl-ps2dev-1.2-3
cdem.snsys.com                  ps2dvdem-1.0.0-1
isdiag2.sm.sony.co.jp           ps2tooldiag-2.0-17
isdiag2.sm.sony.co.jp           ps2tooldiag-2.0-20
localhost.localdomain           ps2tooldiag-2.1-4
kuma-t10k                       ps2tooldiag-2.1-5
isdiag2.sm.sony.co.jp           ps2tooldsetup-2.0-17
isdiag2.sm.sony.co.jp           ps2tooldsetup-2.0-20
localhost.localdomain           ps2tooldsetup-2.1-4
kuma-t10k                       ps2tooldsetup-2.1-5
kuma-linux.rd.scei.sony.co.jp   ps2toolmodem-2.2-1
caster.msacaster.msa.co.jp      PStoolInit-1.0-6
gazelle222.msa.co.jp            PStoolInit-1.0-8
juventus.sm.sony.co.jp          PStoolSetup-1.2-1
oji7f-dh2-235.sm.sony.co.jp     PStoolSetup-1.3-1
kuma-linux.rd.scei.sony.co.jp   PStoolSetup-1.4-1
[/FONT]

anyone know how to make the code tag work, or otherwise add tab stops?

 

SBC replacement update:
ordered in a few items- notably, an Advantech PCI-6881FG board.
This SBC supports Gigabit ethernet, USB, compact flash, and Pentium M processors.

preliminary results:
Off a stock 233 image:
CF does not boot directly, even with GRUB setup properly (error about inaccessible boot device)
Ethernet is unrecognized, but a driver should be able to fix this.
I have not connected the serial port as the SBC makes use of small-pitch connectors, and I'll need to throw together an adapter.
PCI drivers are recognized, and system communicates with the PS2 board in order to issue resets with no problems!

In the end, my conclusion is that, as long as the board will boot, has at minimum a free serial port, and ethernet drivers exist that will work with a 2.0/2.2 kernel, pretty much and PCI based SBC should be adequate if one would like to boost the usefulness of the PC side of things. Obviously I have more testing and setup to do to fully integrate this board, but in the meantime, it definitely means that we are not locked to the Socket7/370 boards initially shipping with the TOOL.

 

Very useful. Now, Pentium-M is a 32-bit CPU. I wonder if SBCs with 64-bit CPU's work (Core2Duo; latest Celeron line, Pentium Dual Core; Pentium-D, etc..) will work. I'll probably try this myself. Also, I'm not sure what the need/utility of the serial port is. Can you explain further?

Also, about the HDDs: I don't have my TOOL yet, but doesn't the TOOL support 3 HDDs with the stock 815VE and 586HVE SBCs (I'm guessing 3 IDE connectors)? If so, at least with either stock SBC, couldn't a 3rd HDD be installed in a TOOL with, say, the latest release of OpenSUSE? This would allow for switching between OpenSUSE and the TOOL's RedHat Linux by simply changing the boot order of the HDDs in the SBC's BIOS, I believe.

For both stock internal HDDs, what's installed on the second, non-primary HDD?

Keep up the good work

 

32-bit and 64-bit CPUs will both run fine in 32-bit mode (not itaniums, they're completely different altogether). 64-bit CPUs will only run in 64-bit mode if they have a 64-bit kernel and code running on them, else they won't run in it at all, but you'd need supporting hardware like an updated bios for the motherboard, etc.

 

Yep, this is what I assumed, for x86-64/x64 at least. Other ISAs like Power/PowerPC works a little differently with regards to 32 vs. 64 bit code execution.

Any, what types of spec are there regarding the PS2 TOOL's motherboard (is this the so called 'backplane' everyone refers to?)? Are there certain PCI specs an x86/x64 SBC must meet in order to be used within a PS2 TOOL? This would help me determine what to look for in an SBC regarding specs when I want to upgrade it.

 

The motherboard is NOT the backplane- the backplane (is more of a pci riser intended for sbc use (you'll encounter the design in other sbc industrial systems) but it is extremely unique as it has custom connectors along the back edge that the massive ps2 motherboard slots into.

this is the ps2 mainboard:
http://www.flickr.com/photos/defor/4106021707/in/set-72157622485345810/

this is the backplane:
http://www.flickr.com/photos/defor/4106699562/in/set-72157622485345810/

Well, stock, I'm hearing that sbc's THAT new may have issues with booting redhat in the first place- I've been doing all my packing development with clones of the hdds in vmware on a C2D system and havent seen any issues, but - hard to say.

Also, watch out for clearance issues- I picked up a nice Pentium M board but the back of it has a CF slot that hits some of the PS2 components and is a shorting/case stress hazard.

a STOCK tool has 2 drives, a tool with emu board has 3-
the 2 main drives- one is connected to the sbc, the other to the ps2- others here have accessed this internal drive iirc via a modified ps2 linux kernel, and could be potentially accessed by games during development as the DEV9 hardware had not been finalized by the tool's original shipping date it seems.
you could realistically install as many drives as you want in a tool by way of using the 2 ata buses on the sbc, and then add more via a pci ata/scsi card.
I'd once again highly recommend in a setup with an interest in dual-booting, that one use CF cards on ide adapters connected to the sbc- they're small, and you can usually get mounts that fit in the PCI slots.

So far from the pile of images that have been sent to me for analysis- the ps2 drive contains an exact copy of the sbc drive, but in a virgin state because nothing has ever written to it.

The rationale behind WHY this has data on it is most likely due to a mass-install of a bunch of drives for the tool manufacturing process, and rather than have linux-preinstalled sbc disks and BLANK ps2 disks, they just installed on them all and grabbed from the pile when building the system.

Another theory was that this was to simplify the troubleshooting process if a TOOL was returned with a dead drive- the drives could be swapped and one that was tailored for that system would be ready to go. (In one of the newsgroup entries I seem to remember this mentioned by someone who was self-servicing a unit (odd since i thought sony gave maintenance as part of the TOS)...

The good side about this is that it makes an excellent recovery disk if you want to get back to square one.

I have a large amount of tutorials written up in draft format documenting proper disk imaging procedure on mac/win/linux - drop me a pm if you get a tool and i can help you get a good, indexed, backup made before you start messing with the system.

 

why need upgrade host card?
for custom Linux?

 

Just commenting about the "DEV9" name.

It's called that way because it's connected to IOP IRQ9.

In a expansion bay console DEV9 is the SSBUS interface chip (CXA9611 or equivalent) and in a PCMCIA console it will be CXD9566.

So it was not "DEV9" specs that were not ready but perhaps the SSBUS specification that were not ready ?


P.S.:
IOP interrupts exposed on the circuit board:

IRQ4 goes for the SPU2, IRQ5 is for DVD drive hardware (DSP) and IRQ8 seems to be disconnected.

 

that could be (damn you and your in-depth development awesomeness )

 

Very cool stuff.

defor,
I am seriously considering trying something like what you are doing. Upgrading to a current (or at least MORE current) Linux distro. Thanks for doing all this work and keeping it all public so others can benefit. I will try to get you DD images of my drives when I have the time to *safely* take apart my T10kH. This is getting more interesting all the time... : )

Regards,

npt

:thumbsup:

p.s. I am also very soon coming into a T15k, if I can find something that will explain how to get it apart and back together, I will try and send those DD images as well.

 

Has anyone now been able to try a later model PCI SBC in their TOOL? Potentially something with a Pentium M, Atom, or even a Core Solo?

 

i ran a pentium m based board in mine for a little, but the key issue is space.. I had to make some custom shims to keep the cpu card bent out of the way as the CF slot on it ran into part of the ps2 boards iirc.

on the other hand- why?
all compilation and use of the TOOL should be done on the host pc, not the target board of the tool....

anyway- I've got most of the rpm's for about 6 or 7 systems that people sent me rebuilt and tested working a few months ago- I hope to have a reinstall solution ready by end of summer so i can mark another incomplete project off my list.
also, still would love to hear from people who are willing to share their drive DD images and/or contribute to an online repo for netinstalling tools with wiped drives.

 

Looking forward to this!

 

Is there any update on this project?
Really looking forward to it

 

Heh- not for ages, but i had backburnered it- give me a little bit, I've gotten a few precursors sorted out...