An excerpt from my old thread "PS2 Tool: Questions" on Assembler Games, with some updated information. Also thanks to wisi for some of this info.
I have a few questions about the PS2 Tool.
* What is MRP?
mrp.o appears to be a Linux kernel module. How does it communicate with the PS2 side? Does it communicate through the serial cable or through the PCI slot?
MRP = Linux kernel Module for the Request Processor (this is a guess)
It is the PC-side driver for the PIF (PC(SBC)/Processor InterFace), which is the big Xilinx FPGA on the backplane (together with the 4 FIFO chips on the bottom side of the backplane).
There are (similar) registers on PC (PCI) and PS2 side, through which communication is done. There two channels - one single byte "serial" port and another that can transfer packets (using DMA as well). DECI2 packets are sent over it.
In the same registers range there are also registers for controlling the power/reset of the PS2 and PC sides, LED control, power button reading, etc. the BID (Board ID) register is there as well. The register range starts at 0xBF803800.
A list of the register ranges under the EXTR (EXTRA) SSBUSC device channel and registers descriptions is attached. It was compiled with the help of SP193.
The PIF/MRP (FPGA) connects through buffers to the PS2 IOP SSBUS and through a PLX PCI9050 PCI<->other buses bridge to the SBC PCI bus.
* Is there any way to disable writing to the Flash ROM?
I do not know of such a way (unless you manually disconnect its write-enable line and set it to inactive state), but depending on the DIP switch on the back, only half of the Flash-ROM will be written on update (AFAIK). But disconnecting the /WE line will also prevent reading the Flash ID and other data, so this won't work correctly.
* How much of the TOOL's internals can you take out/disconnect before basic functionality (running programs on the EE and IOP) will stop working?
In theory the CDVD PCB and the AIF (+Dev9) PCB can be removed and it might even be possible to disconnect the Backplane from the MPU4 board, leaving you with a bare MPU board, that if you power somehow should run as a bare PS2 (with more RAM), but it will probably require emulating some of the signals that connect it with the backplane and will a different ROM image that does not try to initialize the missing components. But if you need it to run as a TOOL, then there is hardly anything that can be disconnected, leaving it still fully-functional (maybe the AIF board only and additional PCI boads?).
(After some time): I took out the following:
CDVD drive (and associated ribbon cable)
AIF HDD
SIO2 ports (controller and memory card)
Eject board (and associated cable)
LED board (and associated cables; showing the status of TOOL/WS and CDVD/EMULATOR modes, as well as one LED for 3 HDDs)
* Is it possible to use the other three PCI slots from the PC side or the PS2 side?
The PIF is a peripheral PCI slave device on the PCI bus, so AFAIK it cannot become a PCI master and communicate with other PCI devices.
It should be possible to use any of the PCI slots for mostly anything PCI slots can be used for, although there may be a requirement in which slot the SBC must be and also some of the PIF drivers (powercontrol) require the PIF to be connected to PCI slot 0 (if I remember correctly). (Otherwise up to four MRP devices are supported, but in this case the PIF is integrated on the backplane, and it needs to be on a PCI card for this.)
* Is there a way to switch to YCbCr mode?
EE argument bit 4 0x00000010 Component video output
0 RGB
1 Y/CrCb
* Is there a way to make the SBC go past the initialization screen faster?
I already disabled the built-in floppy controller, disabled boot seeking, disabled the extended memory checking, set the boot order to C only, and disabled the primary slave HDD.
I can't think of anything more than what you already did. You could try updating the BIOS, and look for a "fast-boot' option.
As for the Linux startup - you could probably edit the bootloader configuration, and the Linux startup scripts.
* Has anyone benchmarked the speed of the SBC PCI<->IOP yet?
I'm curious if this is faster than the speed of an HDD connected to the Network Adapter.
It should be very fast compared to PS2 Ethernet connection speed, but I think it is at least two to five times slower than the PS2 internal HDD. The maximum transfer rate on the IOP is ~120MB/s, and when transferring data between a peripheral device (SPEED chip - HDD) and the EE it is half that ~50MB/s. The SPEED chip SSBUSC channel is configured to the fastest SSBUSC settings (and so is the CDVD device if I remember correctly). But the EXTRA SSBUS channel uses lower speeds - at least twice lower, but I don't know for sure (because of the multiple buffers between the SSBUS and the PIF FPGA). Also the PCI interface limits the maximum speed somewhat.
So it is probably the second or third fastest peripheral device after the internal HDD.
* Are there any upgrades or replacements for the SBC?
I have read about this on the forums (but I don't remember the thread). On the PS2 TOOL, the SBC was meant only as a communication processor and no work was done directly on it. (almost quoting SP193)
Also given that Ethernet is used to connect it to the development PC(s), it probably didn't need to be particularly fast.
On the PA DTL-T15000 (AFAIK) there is a dedicated MCU connecting the main sampling FPGA to the PIF FPGA and/or PCI bridge, which probably enables faster transfers of sampled data to the network (but I don't know exactly how this system works).
* Misc information about my system
Since it was sold with broken plastic casing, I put it to the side, intending to fix it later.
I trashed most of the foam and copper tape.
I used a compressed gas duster to clean out most of the dust.
I replaced the HDD connected to the PC SBC with a CF card.
I might take out the TOOL/WS/CDVD/EMU switch board, since its primary function (ROM swap) can be replicated by DIP switch #1 (1-indexed, away from the PSU)
(At the end, I just left it in, since it's easier to switch it and the cable isn't that long)