PlayStation 2 TOOL unit ROM layout

I do not believe anyone has created a thread to talk about the ROM layout of the TOOL. More things are still being understood at the moment, so I have decided to create a thread to allow public discussion of this topic.

Introduction
PlayStation 2 ROM chips and their contents

• Boot ROM
  • Already present since the PlayStation.
    
  • Internally known as DEV2 to the SSBUS.
  • Hardwired to exist at 0xBFC00000 (no way to remap it via SSBUS).
    
  • This is a 32Mbit ROM on the CEX/DEX, but appears to be smaller on some prototypes (given the device names found within the romflash tool).
  • The TOOL's WS/TOOL mode switch appears to rotate the mappings of the two ROMs. In TOOL mode, the TOOL mode ROM resides at 0xBFC00000, while the WS mode ROM resides at 0xBFE00000. And vice-versa.
  • While DEV2 has no address register for SSBUS, it has an access control register.
• DVD ROM
  • Internally known as DEV1 to the SSBUS.
  • Typically mapped with SSBUS to reside at 0xBE000000.
    
  • Contains the DVD Player for most CEX models.
  • Not present on DEX and the A-chassis CEX.
  • Access to this ROM's contents is provided via the ADDDRV module in the CEX/DEX ROM.
  • In A-chassis CEX modules, their old ROMDRV modules have support for the DEV1. However, this device is not known to exist on such a console.
  • The early TOOL ROMs (including rom0:OLDROM) have a similarly-designed ROMDRV module as the A-chassis CEX.

PlayStation 2 mainboard models appear to have been designed to allow either a single chip (BOOT+DVD ROM Combo) or a 2-chip layout.

How DECI2 Determines the ROM Regions
The IOP DECI2 manager accesses the SSBUS configuration registers for DEV1 and DEV2 to determine the location and regions mapped to DEV1 and DEV2 respectively, before allowing the DMA controller to transfer large amounts of data quickly from them.

DEV1 on the TOOL
Here's the interesting part: the TOOL may have a DEV1 device. However, it (at least on my unit) does not appear to contain anything very interesting.

I booted up my DTL-T10000H J (release v3.00). From dsidb, the memory and configuration registers for DEV1 have the following power-on defaults:

Code:

dsidb R> iw 0xBF801400
 0xbf801400: 0x1fa00000
dsidb R> iw 0xBF80100C
 0xbf80100c: 0x00153f44
dsidb R>

0xBF801400 shows that DEV1 used to be mapped to 0xBFA00000.
0xBF80100C contains the access control parameters. As of now, there is no public documentation on the bit field definitions, but I can remark that this default value sets up a 16-bit access mode, with 2MB address space.

Accessing the memory at 0xBFA00000 with the DECI2 db command shows 0xFF for all bytes, so perhaps there is no content on that flash device for my unit.

SSBUS DEV1 Configuration/Delay Register Values

Other than determining the size of the memory region that DEV1 is mapped to, this register also determines various parameters used by the bus to access the device (i.e. DMA width, 8/16-bit access modes, cycles for reading/writing). While the official name of the register is "delay", it does more than configuring the number of access cycles.

For reference, there are a few values used for the SSBUS delay register of DEV1. ROMDRV of v1.0x:

1. 0x00183F4F
2. Upon failure, tries 0x00182D4F.
3. Upon failure (which always happens because these consoles have no DEV1 installed): reset both delay and address registers back to their original values.

ADDDRV (from my SCPH-39006, v1.60H):

1. 0x0018344F
2. Upon failure, reset both delay and address registers back to their original values.

ADDROM2 (SCPH-50009, v1.90C):

1. 0x00183444
2. Upon failure, reset both delay and address registers back to their original values.

SSBUS DEV2 Configuration/Delay Register Values
While the Boot ROM (DEV2) has no address control register, it still has a delay register that DECI2 uses to determine the size of the memory region that the boot ROM is mapped to. This register also determines various parameters used by the bus to access the device (i.e. DMA width, 8/16-bit access modes, cycles for reading/writing). While the official name of the register is "delay", it does more than configuring the number of access cycles.

On my DTL-T10000H J, a 32Mbit address space is mapped in 8-bit I/O mode:

Code:

dsidb R> iw 0xBF801010
 0xbf801010: 0x0016244f

Probing DEV1 on the TOOL
Issuing some commands to the flash chip seems to indicate that there is a device connected (but is blank).

This issues the manufacturer ID command, after setting up the SSBUS access for DEV1 to be 8-bit and to exist at 0xBE000000.

Code:

dsidb R> ow 0xBF801400 0x1E000000
dsidb R> ow 0xBF80100C 0x152F4F
dsidb R> ob 0xBE000AAA 0xAA
dsidb R> ob 0xBE000555 0x55
dsidb R> ob 0xBE000AAA 0x90
dsidb R> db 0xBE000000   
 0xbe000000: 04 04 49 49 00 00 00 00  04 04 49 49 00 00 00 00  ..II......II....

Dumping the ROM

Dumping the ROM(s) can be done with the bsave command. While the EE is given access to the IOP's SSBUS peripherals, I recommend that dumping be done via dsidb because the IOP has direct access to the SSBUS.

Code:

dsidb R> bsave filename start count

Example (dumping the boot ROM):

Code:

dsidb R> bsave dev2.bin 0xBFC00000 0x00200000

Example (dumping the DVD ROM):

Code:

dsidb R> bsave dev1.bin 0xBFA00000 0x00200000

As the default configuration for DEV1 has a size of 0x15, 2^0x15 = 2MB. So for this example, this command just dumps 2MB (0x00200000 bytes).

If, for whatever reason, there is a need to relocate DEV1 in memory (i.e. because the DEV1 device is actually bigger than 2MB and is hence impossible to map at 0xBFA00000):

Code:

dsidb R> ow 0xBF801400 0x1E000000
dsidb R> ow 0xBF80100C 0x183F4F
dsidb R> bsave dev1.bin 0xBE000000 0x00400000

This maps DEV1 to a 4MB region at 0xBE000000.

Credits
Special thanks to @Shuji and @wisi for bringing up this topic and for sharing their knowledge.

 

Content of DEV1
I wrote above that my DEV1 device does not contain anything very interesting. However, it does contain something other than just 0xFFs. At offset 0x001F0000 (hence 0xBFBF0000 in memory):

Code:

73 45 61 43 92 D4 EC 86
07 46 00 08 D6 7F 00 30
61 00 00 00 14 00 00 00 08 00 00 00 15 00 00 00 07 00 00 00 20 00 00 00
FF FF FF FF
02 00 1A 00

The 2nd set of 8 bytes specifically, looks like a GUID for i.Link comms.

For comparison, here are the IDs of my SCPH-15000:

Code:

Console ID:    0x02 0xd2 0x11 0x01 0x1d 0x76 0x31 0x00
i.Link ID:       0x07 0x03 0x00 0x1a 0xdd 0x68 0x2e 0x10

Sony OUI: 0x080046 -> 46 00 08

Code that I put into i.Link man (copied from ILINK.IRX), which replaces the MODELID part of the i.Link ID with the SCE OUI, to form the IEEE1394 GUID:

Code:

      *guid=(ilink_id&0xFFFFFFFF00000000) | ((*(u8*)&ilink_id)|0x08004600);

In early consoles, the first byte of the i.Link ID is always 0x07.

However, the serial number of my console (700186) does not seem to match the serial number part of the console ID (bytes 5, 6 and 7)... if the first 8 bytes is a console ID. But I have doubts it is one, as its known fields do not seem to fit the usual patterns.
In the i.Link ID, bytes 5, 6 and 7 also contain the serial number, but it is obfuscated in some way.

The 02 00 1A 00 may be the model ID of the DTL-T10000 TOOL (known to be 0x001A0002). In comparison, the DTL-H10000 has 0x001A0001 and SCPH-10000 has 0x001A0000.
This relationship was extracted from the Sony ILINK.IRX module.

Usually, the MODELID and MODELNAME fields are obtained from the MECHACON's EEPROM. In early PlayStation 2 models (all A-chassis CEX+DEX), MODELNAME is hardcoded into the software (i.e. the Sony browser) and is entirely absent from the MECHACON EEPROM. Neither does their ILINK.IRX module seem to utilize this data within DEV1, so it is pretty weird that Sony would include this data in yet another place...

After this part, there are some 0xFF bytes until offset 0x1F0080:

Code:

4D 50 55 34 3D 31 32 2D 31 39 39 39 30 39 30 33 2D 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 4D 49 46 3D 30 34 2D 33 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 49 46 3D 31 31 2D 30 39 30 2D 31 2E 33 2E 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 56 49 46 3D 31 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 42 50 32 3D 31 31 2D 31 30 2D 31 30 2D 31 30 2D 31 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 53 42 43 3D 31 30 2D 31 39 39 39 30 38 30 34 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 4D 4F 44 45 4C 4E 41 4D 45 3D 44 54 4C 2D 54 31 30 30 30 30 00....

After this block are all 00s.

It looks like text! And indeed, Shuji did find some text there:

• MPU4=12-19990903-10
• MIF=04-30
• DIF=11-090-1.3.0
• VIF=11
• BP2=11-10-10-10-10
• SBC=10-19990804
• MODELNAME=DTL-T10000

Although @Shuji's TOOL is likely much older than mine, these lines appear to be exactly the same. So perhaps these strings are common to all TOOLs. I have not determined if the IDs from earlier are the same or not, however.

 

nice info , thank share

 

Dumping IOP RAM on the TOOL
This is not really related to the ROM anymore, but I feel that this deserves a mention - why we cannot dump all 8MB of the TOOL's (and PSX's) 8MB of IOP EDO RAM. It will also give an example for how the DECI2 manager determines the sizes of the memory regions (and their locations) that the two ROMs are mapped to.

Through experimentation, one may observe that dsidb appears to have difficulty dumping memory around the last 256 bytes of IOP RAM, with the dd and/or bsave commands. To make matters stranger, that region can be viewed with most other commands (i.e. db, dh, dw, iw). bsave may even work, depending on the address and size specified!

This weird behaviour can be explained by understanding how the IOP DECI2 manager copies data.

While commands like db, dh, dw, dd, dq must be issued with addresses that are appropriately aligned, bsave has no such requirement. bsave will internally determine the necessary steps to save the requested range as efficiently as possible, which may involve making multiple transactions of varying alignment sizes:

• If the specified address is not aligned to the size of the CPU's largest register mode, read in byte mode until the current address is aligned.
• Make the maximum possible number of reads, with the CPU's largest register mode.
• Read the remaining number of bytes, in byte mode.

1, 2 and 4-byte accesses are done with the IOP itself, in software. On the other hand, 8-byte block accesses are done with the DMA controller instead. This applies to both the bsave and the dd commands.

Before the transfer is carried out, the address range is verified against a whitelist of regions:

• Length and address must be aligned to 8-byte boundaries.
• Convert virtual segments (KSEG etc) into physical addresses. e.g. 0xB0000000 -> 0x10000000
  
• If the address is in main memory:
  • Start: Hardcoded to assume 0x00000000
  • Size: QueryMemSize(). QueryMemSize() returns 0x007FFF00 on the TOOL! This is why we are unable to bsave/dd the last 256 bytes.
• If the address is in Boot ROM:
  • Start: Hardcoded to assume 0x1FC00000
  • Size: (1 << ((*(volatile u16*)0xBF801012) & 0x1F)). This accesses the DEV2 delay register for the ROM size.
• If the address is in DVD ROM:
  • Start: *(volatile u32*)0xBF801400. This is the DEV1 address register.
  • Size: (1 << ((*(volatile u16*)0xBF80100E) & 0x1F)). This accesses the DEV1 delay register for the ROM size.
• Anything else will be deemed as a "bus error".

While the DECI2 manager accesses the SSBUS registers directly, it can be treated as a kernel module (may/may not be board-specific). And so it may be better for external software to use the SSBUSC Service's (rom0:SSBUSC) functions instead, to reduce coupling with the board's design.

QueryMemSize()

QueryMemSize() returns a value of 8MB-256 bytes (0x007FFF00) on the TOOL, as well as any console (i.e. the PSX) with 8MB of IOP memory installed.

This is due to SYSMEM limiting memory in software.

Credits
Special thanks to @SilverBull for the DECI2 research material.

 

Here is data from @Armorant tool:
MPU4=12-19990903-10
MIF=11-20
DIF=11-090-1.3.0
VIF=11
BP2=11-10-10-10-10
SBC=10-19990804
MODELNAME=DTL-T10000
Almost the same

 

is it work dump IOP after break the memory area ?

When the EE program stops, use the hardware break feature on dsidb
to set a breakpoint if access is attempted in the 2M - 4M area.

(Example: from dsidb)
dsidb R> hbp dauk:00200000,50200000
dsidb R> hbp pcuk:00200000,50200000

Then set up breakpoints as described above to catch accesses in the 4M - 8M area.

(Example: from dsidb)
dsidb R> hbp dauk:00400000,50400000
dsidb R> hbp pcuk:00400000,50400000

 

I tested and any region (and size) of memory can be correctly read through dsidb, except for the space between 0x007FFF00 - 0x007FFFFF. If you make small reads (<16 bytes), then you can list all bytes there. If you try to make 16-byte and larger reads, then a "Bus Error" message is displayed in dsidb.

Thank you for the tip.

 

In my first post, I wrote an example for dumping the boot ROM (DEV2) with a 2MB range, but the boot ROM might be up to 4MB. Although that is on CEX consoles, please check that your dumps are complete.
The size of the flash image may be from 512KB to 4MB in size. 512KB because the Sony flash tool mentions some 512KB devices, while the CEX has 4MB. The location of the ROM in memory can also allow up to a 4MB ROM (0xBFC00000-0xBFFFFFFF is 4MB).