SCMD list

[AKuHAK]

linux/arch/mips/include/asm/mach-ps2/scmd.h

Lines 22 to 34 in 7ef0b69

	/**
	* enum scmd_cmd - system commands
	* @scmd_cmd_read_rtc: read the real-time clock (RTC)
	* @scmd_cmd_write_rtc: set the real-time clock (RTC)
	* @scmd_cmd_power_off: power off the system
	* @scmd_cmd_read_machine_name: read machine name
	*/
	enum scmd_cmd {
	scmd_cmd_read_rtc = 8,
	scmd_cmd_write_rtc = 9,
	scmd_cmd_power_off = 15,
	scmd_cmd_read_machine_name = 23,
	};

Some notes about the SCMD list. Currently, this is a very undocumented feature, cause this list depends on the Mechacon firmware version and probably is generated by mechacon processor.

For example, scmd_cmd_read_machine_name actually reads machine model name from EEPROM (or NVRAM). EEPROM content can be rewritten, so this command can be inaccurate in some cases.

Below is the list of SCMD that I collected and that works in PS3 with backward compatibility PS2. In theory, this list should be universal for any mechacon.

scmd_cmd_read_rtc
scmd_cmd_power_off

It seems that these 2 is present on all machines.

scmd_cmd_read_machine_name
this one isnt present on very early units

scmd_cmd_write_rtc
this one also isn't present on some machines, for example in PS3/PS4 in PS2 mode

scmd_send_byte(0x12, NULL, 0, &ilinkID, sizeof(ilinkID));
_get_ilink_id - returns iLink.ID - this is a unique ID, for each PS2 it is different. Some online games used this ID for identifying consoles. This ID is calculated from information on the sticker, and stored in EEPROM, all functions for calculating still is unknown.

scmd_send_byte(0x1e, NULL, 0
purpose unknown, returns some static information

0x41, 0x84, 0x85
purpose unknown, returns NULL

There is also such SCMD 0x03 command family. SCMD 0x03 is an interesting command set, cause it always is called with a subcommand. Looks like this feature is not implemented currently, but SCMD subcommands offers some useful information. Code examples can be found here:
https://github.com/ps2homebrew/PS2Ident/blob/master/libcdvd_add.c

For example sceCdApplySCmd(0x03,0x00,...)
_get_MV
will return 4 bytes, 1 byte error code (which is BTW buggy on some DTL-H301** machines - it will incorrectly return 0x01, error state, while no actual error proceed), 2 or 3 bytes - Mechacon version. 2 bytes on pre-Deckard models, 3 bytes on Deckard. Also 1 byte (last) of these 3 - will be the console real region (I mean the most accurate). Very useful command, based on mechacon version we can know which SCMD commands are supported, and also the real region is read (not that one from ROMNAME, but flag from EEPROM). This command also seems supported in all machines starting from very early units.

sceCdApplySCmd(0x03,0x01,...)
_get_DSP
will return DSP chip revision. Can be 4 values: 0,1,2,3. starting from SCPH-3xxxx always return 3.

sceCdApplySCmd(0x03,0x30,...)
purpose unknown

also 2 SCMD command are force disabled in PS3 in PS2 mode. That probably means that they are used somewhere:
scmd_send_byte(0x0a,
sceCdApplySCmd(0x03,0x45,...)

[frno7]

Thanks for your findings, @AKuHAK. I’ll try to sort them. It seems we should distribute them to various preexisting issues rather than create new ones, as explained below.

For example, scmd_cmd_read_machine_name actually reads machine model name from EEPROM (or NVRAM). EEPROM content can be rewritten, so this command can be inaccurate in some cases. scmd_cmd_read_machine_name
this one isnt present on very early units

Isn’t this a partial duplicate of #12, and also already implemented here?

linux/arch/mips/ps2/identify.c

Lines 58 to 77 in 7ef0b69

	/*
	* ROM version 1.00 is always SCPH-10000. Later machines with
	* ROM version 1.0x have the machine name in the ROM0 file OSDSYS
	* at offset 0x8c808. These are late SCPH-10000 and all SCPH-15000.
	* Even later machines have a system command (SCMD) to read the
	* machine name.
	*/
	if (rom_version_number >= 0x110)
	err = set_machine_name_by_scmd(); /* ver >= 1.10 */
	else if (rom_version_number > 0x100)
	err = set_machine_name_by_osdsys(); /* 1.10 > ver > 1.00 */
	else if (rom_version_number == 0x100)
	mips_set_machine_name("SCPH-10000"); /* ver = 1.00 */
	else
	err = -ENODEV;
	if (err)
	pr_err("identify: Determining machine name for ROM %04x failed with %d\n",
	rom_version_number, err);

scmd_cmd_write_rtc this one also isn't present on some machines, for example in PS3/PS4 in PS2 mode

I think the main targets for PlayStation 2 Linux are real hardware and emulators that simplifies development, for example QEMU. I’m hoping to revisit PS3 Linux, but then the real thing, via Other OS. I’m happy to accept good quality patches though, if someone feels PS3 and PS4 are important for the PlayStation 2 Linux kernel.

scmd_send_byte(0x12, NULL, 0, &ilinkID, sizeof(ilinkID)); _get_ilink_id - returns iLink.ID - this is a unique ID, for each PS2 it is different. Some online games used this ID for identifying consoles. This ID is calculated from information on the sticker, and stored in EEPROM, all functions for calculating still is unknown.

Sounds useful for #24? Maybe it’s a MAC address?

There is also such SCMD 0x03 command family. SCMD 0x03 is an interesting command set, cause it always is called with a subcommand. Looks like this feature is not implemented currently, but SCMD subcommands offers some useful information. Code examples can be found here: https://github.com/ps2homebrew/PS2Ident/blob/master/libcdvd_add.c

I suppose these subcommands mainly goes to #23?

For example sceCdApplySCmd(0x03,0x00,...) _get_MV will return 4 bytes, 1 byte error code (which is BTW buggy on some DTL-H301** machines - it will incorrectly return 0x01, error state, while no actual error proceed), 2 or 3 bytes - Mechacon version. 2 bytes on pre-Deckard models, 3 bytes on Deckard. Also 1 byte (last) of these 3 - will be the console real region (I mean the most accurate). Very useful command, based on mechacon version we can know which SCMD commands are supported, and also the real region is read (not that one from ROMNAME, but flag from EEPROM). This command also seems supported in all machines starting from very early units.

Identifying the machine is best for #12, I think.

sceCdApplySCmd(0x03,0x01,...) _get_DSP will return DSP chip revision. Can be 4 values: 0,1,2,3. starting from SCPH-3xxxx always return 3.

Likewise, #12 seems best for this one.

[AKuHAK]

I think the main targets for PlayStation 2 Linux are real hardware and emulators that simplifies development, for example QEMU. I’m hoping to revisit PS3 Linux, but then the real thing, via Other OS. I’m happy to accept good quality patches though, if someone feels PS3 and PS4 are important for the PlayStation 2 Linux kernel.

I just posted here this list cause these particular SCMD commands are implemented even in partially emulated hardware. This means that these commands probably are present in every real hardware. Of course, the real SCMD list is much much larger. For example, on PSX DESR machines almost all 0x00 - 0xFF SCMD commands are supported and almost all SCMD 0x03 subcommands are supported (0x03, 0x00 - 0x03,0xFF). This is an enormous list but mostly all commands are for internal use (to lock DVR writing media, some DVRP processor interrupts, and so on). I don't mean that we should focus on compatibility with PS2Emu, just mention features that are implemented, so these features can be safely used.

Sounds useful for #24? Maybe it’s a MAC address?

Huh, yes Sony chooses bad naming for this ID. iLink.ID has no relation with iLink hardware. Each console (even slims) has its iLink.ID, it is calculated from Console Serial number, console model name, and console generation. This is not a MAC address cause FAT models don't have a built-in network adapter, so the MAC address wasn't present on it. This ID is used mostly for DNAS stuff, for some HDD stuff, for DRM, for online gaming, and for online services. MAC address wasn't that useful, cause you can just buy another network adapter and you will get a new MAC address, but for proper console recognition, this ID always is used. Official Sony services have special tool that can calculate this 8-byte iLink.ID from sticker photo and vice versa - can regenerate sticker photo from this 8-byte value.

[frno7]

I don't mean that we should focus on compatibility with PS2Emu, just mention features that are implemented, so these features can be safely used.

👍

Huh, yes Sony chooses bad naming for this ID. iLink.ID has no relation with iLink hardware. Each console (even slims) has its iLink.ID, it is calculated from Console Serial number, console model name, and console generation. This is not a MAC address cause FAT models don't have a built-in network adapter, so the MAC address wasn't present on it. This ID is used mostly for DNAS stuff, for some HDD stuff, for DRM, for online gaming, and for online services. MAC address wasn't that useful, cause you can just buy another network adapter and you will get a new MAC address, but for proper console recognition, this ID always is used.

#12 again, presumably. 😄

Official Sony services have special tool that can calculate this 8-byte iLink.ID from sticker photo and vice versa - can regenerate sticker photo from this 8-byte value.

Is its algorithm publicly known these days?

[AKuHAK]

I collected and reversed some info. But for proper algorithm we need to collect data from all ps2 different models. Part of ilinkid is so called Model ID, and this ID is unique for console revision. It seems that Sony just have big table with all possible Model IDs and corresponding console hardware. While I collected many Model ID (about 200 if I am correct) this list is still incomplete. For example pink scph-70001 has different ModelID than black one. I use Model ID for proper console recogntion, cause sometimes pirates alter Model Name in nvram (there is software that allows it on pre-Deckard units) and sell, for ecample, SCPH-30003 as SCPH-39004. This can be easily checked by reading ilink ID from eeprom, cause noone knows about that feayure in 2000s.