Set the machine field in /proc/cpuinfo to the PlayStation 2 model

[frno7]

The machine field in /proc/cpuinfo is currently set to unknown:

# head -n2 /proc/cpuinfo 
system type		: Sony PlayStation 2
machine			: Unknown

Set the machine field to the PlayStation 2 model, such as SCPH-50004 or SCPH-77004.

Retrieving the model seems to require some level of IOP support, see #11.

Use the sysfs pseudo file system to display further hardware revision information?

[sp193]

I wouldn't say that it is surely dependent on the IOP, but you need some form of access to the CD/DVD subsystem. It can also be accessed directly from the EE, although it might be good to keep things standardized.

In normal PS2 software, the model name is normally obtained via libcdvd's sceCdReadModelName() function. If the first 4 characters of ROMVER is "0100J", then the HDD Browser will default to "SCPH-10000". If "0101J", then it will read the model name from offset 0x8C808 of OSDSYS, although I haven't found a PS2 with ROM 1.01J that doesn't report itself as "SCPH-10000".

[frno7]

It can also be accessed directly from the EE,

That is very interesting! Would you be able to elaborate on how that could be done from the EE? I would like to implement it. Also, eventually I would like to map all address spaces, as in #13.

although it might be good to keep things standardized.

What kind of standardisation? I have, for example, removed the BIOS code used by the 2.6 PS2 Linux kernel to instead have the kernel interact directly with the SIF hardware for IOP RPCs. In my opinion, we need not be bound by official abstractions. We can invent better ones. 😄

[sp193]

You would need to issue the appropriate S-commands, by writing to the hardware. You would need to dig for the command and some code from CDVDMAN. I believe I also have some code from my OSD initialization sample because the default CDVDMAN module from the boot ROM does not support this function, but I used CDVDMAN to issue the S-command.

I know you could write your own system, but this is not an open platform and it is largely proprietary. If you deviate, you will have to support everything on your own, including figuring out why the hardware misbehaves (which is hard). While writing my own copies of some of the Sony modules, I used to think I could just change the code. But sometimes that caused more harm because the original code was sometimes designed to cater for hardware characteristics, be it bugs or some design requirement. By at least using their IOP modules to begin with, it becomes easier to compare results. You will also be able to offload processing of the hardware to the IOP and to reduce duplicated code with the PS2SDK, if you manage to use the standard modules.

The official way of using the hardware is to go through the IOP. Only PS2Linux has driver code on the EE, with interrupts and DMA routed over the SIF.

Over the years, we have also established that somehow, accessing some IOP peripherals only works well from the IOP. I do not have an explanation for this, unfortunately.

[frno7]

You would need to issue the appropriate S-commands, by writing to the hardware. You would need to dig for the command and some code from CDVDMAN. I believe I also have some code from my OSD initialization sample because the default CDVDMAN module from the boot ROM does not support this function, but I used CDVDMAN to issue the S-command.

Thanks! I need to learn what S-commands are to proceed with this, obviously.

By at least using their IOP modules to begin with, it becomes easier to compare results. You will also be able to offload processing of the hardware to the IOP and to reduce duplicated code with the PS2SDK, if you manage to use the standard modules.

I agree, using standard modules is the best starting point. Also, we need to figure out what kind of thing the IOP is to the Linux kernel, see #11.

Only PS2Linux has driver code on the EE, with interrupts and DMA routed over the SIF.

Linux USB device drivers cannot in general run on the IOP. They are far too complex and demand too much memory. That said, the Linux USB OHCI driver can hopefully be much more efficient, making use of DMA as suggested in #17. The same reasoning applies for Linux kernel file systems for #18 and #23 and possibly #21.

PlayStation 2 specific devices such as #22 can be implemented differently, I think.

[Ravenslofty]

@PSI-Rockin wrote an incomplete list of CDVD commands in https://psi-rockin.github.io/ps2tek/#cdvd - it could be a useful reference.

[sp193]

I don't mean that the Linux modules should run on the IOP. Not only would that be complicated, it could be slow. I meant to say that you could use some of the existing PS2 IOP libraries (IRX modules), much like how the Sony SBIOS works. Rather than re-implementing everything on the EE.

[frno7]

The system command reading the machine name is now implemented in commit e16b1ae and is used to set the /proc/cpuinfo machine field in commit a84cf79:

# head -n2 /proc/cpuinfo
system type		: Sony PlayStation 2
machine			: SCPH-50004

Reading the machine names for SCPH-10000 and SCPH-15000 are not yet implemented.

[frno7]

SCPH-10000 and SCPH-15000 are now recognised in commit cda11cb, although I'm unable to verify those machines myself.

@sp193, I have defined the system command for reading the ROMVER file in commit ab958ab but there is a one structure member that remains unknown to me:

struct rom_ver {
	int number;
	char region;
	char unknown;	/* FIXME: What is this? */
	struct {
		int year;
		int month;
		int day;
	} date;
};

I read a C for the unknown field, as in 0170EC20030227. Do you have any idea what it represents?

[sp193]

We have no official information on this, but to me it indicates the ROM type.

For the common PlayStation 2, it is a C for CEX.
On DebugStation consoles, this is a D for DEX.
On the PlayStation 2 TOOL and Arcade Computers, this is a T for TOOL.

Arcade Computers like System 246 seem
to have ROMs based on the TOOL version, for some reason.