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. :smile:

[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 e16b1aea01ced7e8465554086f192c495e28162e and is used to set the /proc/cpuinfo machine field in commit a84cf79ab71c1fd569568f085ff4a689a0407638:

# 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 cda11cba11a495df159b3488a2b42a5a9bc8082b, although I'm unable to verify those machines myself.

@sp193, I have defined the system command for reading the ROMVER file in commit ab958aba02788ec9b8e00cd3a83935c5f5a4705a 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.

[frno7]

Many thanks, @sp193! I will document this in the source code. I assume that C stands for consumer and D for developer, but what does the EX part in CEX and DEX stand for? Is TOOL an abbreviation for anything?

I have patches to use the R5900 and by extension the main processor of the PlayStation 2 with QEMU. Perhaps I could allocate another letter such as E for emulated or V for a virtual ROM in such cases. It would be used for testing the Linux kernel.

[sp193]

It is a boot ROM, so you cannot replace it. Even in an emulator, is there a reason to make a totally original ROM, as opposed to making one that is compatible with the CEX ROM?

It could be that this lettering was for Sony to determine the contents of the ROM for tagging purposes, as a DEX ROM needed to support any possible game region and also differ in MagicGate capabilities, while the TOOL ROM had DECI2 support, support for its hardware and no MagicGate file support.

I have no idea what the EX in CEX meant. Neither do I know what SCPH or DTL means.

[frno7]

Are there free ROM implementations available?

The ROMVER region and type fields are now nicely resolved with names in the kernel log:

# dmesg | grep -E rom.:
rom0: Found 98 files in 3900816 bytes
rom1: Found 29 files in 407408 bytes
rom0: Version 0170 Europe CEX 2003-02-27

The fields are also available via sysfs:

# ls /sys/rom/rom0/version
date    number  region  type
# cat /sys/rom/rom0/version/*
2003-02-27
0170
Europe
CEX

One can also inspect the raw ROMVER file, using /dev/mem:

# grep -l ROMVER /sys/rom/rom0/file/*/name
/sys/rom/rom0/file/3/name
# cd /sys/rom/rom0/file/3
# ls
data     extinfo  name     size
# dd if=/dev/mem bs=$(cat size) iflag=skip_bytes
	skip=$(( $(cat data) )) count=1 status=none
0170EC20030227

Or inspect any of the other files in ROM0 and ROM1:

# cat /sys/rom/rom0/file/*/name | sort | column
-		FILEIO		LOGO		ROMVER		TSIO2MAN
-		FNTIMAGE	MCMAN		SBIN		TZLIST
-		FONTM		MCSERV		SECRMAN		UDNL
-		HDDLOAD		MODLOAD		SIFCMD		VBLANK
-		HEAPLIB		OSDCNF		SIFINIT		VERSTR
-		ICOIMAGE	OSDSND		SIFMAN		XCDVDFSV
-		IGREETING	OSDSYS		SIO2MAN		XCDVDMAN
ADDDRV		INTRMANI	OSDVER		SNDIMAGE	XFILEIO
ATAD		INTRMANP	PADMAN		SSBUSC		XFLASH
CDVDFSV		IOMAN		PS1DRV		STDIO		XFROMMAN
CDVDMAN		IOPBOOT		PS1ID		SYSCLIB		XLOADFILE
CLEARSPU	IOPBTCON2	PS1VER		SYSMEM		XMCMAN
DMACMAN		IOPBTCONF	PS2LOGO		TBIN		XMCSERV
EECONF		KERNEL		RDRAM		TESTMODE	XMTAPMAN
EELOAD		KROM		REBOOT		TESTSPU		XPADMAN
EELOADCNF	KROMG		RESET		TEXIMAGE	XRMMAN2
EENULL		LIBFI		RMRESET		THREADMAN	XSIFCMD
EESYNC		LIBSD		ROMDIR		TIMEMANI	XSIO2MAN
EXCEPMAN	LOADCORE	ROMDRV		TIMEMANP
EXTINFO		LOADFILE	ROMGSCRT	TPADMAN
# cat /sys/rom/rom1/file/*/name | sort | column
CDVDFSV		EROMDRV		LOADFILE	ROMDIR		STDIO
CDVDMAN		EXTINFO		MODLOAD		ROMDRV		SYSCLIB
DVDCNF		FILEIO		PADMAN		SDRDRV		THREADMAN
DVDID		IOMAN		RESET		SIFCMD		TIMEMANI
DVDVER		LIBSD		RMMAN		SIFMAN		UDNL
EESYNC		LOADCORE	RMMAN2		SIO2MAN

[Ravenslofty]

I tried my best to write a clean-room BIOS for the EE - biostation - but integration with the IOP proved very painful, especiallywhen there is still so much we don't know about the internals of the system.

There's also FPS2BIOS, but that's possibly not safe to touch because it's of unclear license.

On Sun, 26 May 2019, 15:29 frno7, [email protected] wrote:

Are there free ROM implementations available?

The ROMVER region and type fields are now nicely resolved with names in the kernel log:

dmesg | grep -E rom.:

rom0: Found 98 files in 3900816 bytes rom1: Found 29 files in 407408 bytes rom0: Version 0170 Europe CEX 2003-02-27

The fields are also available via sysfs https://en.wikipedia.org/wiki/Sysfs:

ls /sys/rom/rom0/version

date number region type

cat /sys/rom/rom0/version/*

2003-02-27 0170 Europe CEX

One can also inspect the raw ROMVER file, using /dev/mem http://man7.org/linux/man-pages/man4/kmem.4.html:

grep -l ROMVER /sys/rom/rom0/file/*/name

/sys/rom/rom0/file/3/name

cd /sys/rom/rom0/file/3

ls

data extinfo name size

dd if=/dev/mem bs=$(cat size) iflag=skip_bytes

skip=$(( $(cat data) )) count=1 status=none 0170EC20030227

Or inspect any of the other files in ROM0 and ROM1:

cat /sys/rom/rom0/file/*/name | sort | column

• FILEIO		LOGO		ROMVER		TSIO2MAN
  

• FNTIMAGE	MCMAN		SBIN		TZLIST
  

• FONTM		MCSERV		SECRMAN		UDNL
  

• HDDLOAD		MODLOAD		SIFCMD		VBLANK
  

• HEAPLIB		OSDCNF		SIFINIT		VERSTR
  

• ICOIMAGE	OSDSND		SIFMAN		XCDVDFSV
  

• IGREETING	OSDSYS		SIO2MAN		XCDVDMAN
  

ADDDRV INTRMANI OSDVER SNDIMAGE XFILEIO ATAD INTRMANP PADMAN SSBUSC XFLASH CDVDFSV IOMAN PS1DRV STDIO XFROMMAN CDVDMAN IOPBOOT PS1ID SYSCLIB XLOADFILE CLEARSPU IOPBTCON2 PS1VER SYSMEM XMCMAN DMACMAN IOPBTCONF PS2LOGO TBIN XMCSERV EECONF KERNEL RDRAM TESTMODE XMTAPMAN EELOAD KROM REBOOT TESTSPU XPADMAN EELOADCNF KROMG RESET TEXIMAGE XRMMAN2 EENULL LIBFI RMRESET THREADMAN XSIFCMD EESYNC LIBSD ROMDIR TIMEMANI XSIO2MAN EXCEPMAN LOADCORE ROMDRV TIMEMANP EXTINFO LOADFILE ROMGSCRT TPADMAN

cat /sys/rom/rom1/file/*/name | sort | column

CDVDFSV EROMDRV LOADFILE ROMDIR STDIO CDVDMAN EXTINFO MODLOAD ROMDRV SYSCLIB DVDCNF FILEIO PADMAN SDRDRV THREADMAN DVDID IOMAN RESET SIFCMD TIMEMANI DVDVER LIBSD RMMAN SIFMAN UDNL EESYNC LOADCORE RMMAN2 SIO2MAN

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/frno7/linux/issues/12?email_source=notifications&email_token=AALPDW3KI7QOWTU7HPE3UDDPXKNDVA5CNFSM4G7BDMQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWIG6WI#issuecomment-496004953, or mute the thread https://github.com/notifications/unsubscribe-auth/AALPDW2GYYOOCLXLLE4LCJTPXKNDVANCNFSM4G7BDMQA .

[mirh]

CEX/DEX is also there in ps3 scene where they supposedly mean retail and debug. Not sure if there's anything behind (though those terms are inside a disassembly maybe?)

SCPH is likely Sony Computer PlayStation Hardware

And DTL.. =debug tool?

[Ravenslofty]

Worth mentioning that I would be willing to continue with biostation if people care enough; it seems like a useful thing, but I have difficulties with motivating myself to do something if I'm the only person who will ever use it.

[mirh]

Very simple reminder that it's just 2 decades pcsx2 has been waiting for not needing bios dumping to work.

[frno7]

@ZirconiumX, did you figure out the format of the EXTINFO ROM file? It looks like file metadata, and I would be happy to decode it. Here, for example, looking at the EXTINFO entry for the ROMDIR file:

# cd /sys/rom/rom0/file
# cat 1/name
ROMDIR
# dd if=/dev/mem bs=$(cat 1/extinfo/size) iflag=skip_bytes
	skip=$(( $(cat 1/extinfo/data) )) count=1 status=none | xxd
00000000: 0000 4c03 3230 3033 3032 3237 2d31 3933  ..L.20030227-193
00000010: 3035 302c 524f 4d63 6f6e 662c 5053 3230  050,ROMconf,PS20
00000020: 3137 3045 4332 3030 3330 3232 372e 6269  170EC20030227.bi
00000030: 6e2c 6861 6e61 4072 6f6d 2d73 6572 7665  n,hana@rom-serve
00000040: 722f 7e2f 672f 6170 702f 726f 6d00 0000  r/~/g/app/rom...

And the SBIN file:

# cat 4/name
SBIN
# dd if=/dev/mem bs=$(cat 4/extinfo/size) iflag=skip_bytes
	skip=$(( $(cat 4/extinfo/data) )) count=1 status=none | xxd
00000000: 0000 0401 0304 0220 0100 0002            ....... ....

@sp193 and @ZirconiumX, regarding QEMU: It currently does Linux user mode emulation for the R5900. This is the most convenient way to compile for the PlayStation 2, because the compiler and all other software run as native R5900 programs, avoiding all problems with cross-compilation.

I'm considering implementing QEMU system mode emulation specifically to test the R5900 Linux kernel. I imagine that the only device in such a configuration would be a serial port, perhaps also USB or ATA, so QEMU would not have an IOP, a Graphics Synthesizer, or anything like that. Like @mirh just noted, there are other emulators that have those devices, but I suspect they are not (yet?) good enough for running a Linux kernel.

@ZirconiumX, in some sense the Linux kernel is a ROM replacement, because it handles everything for the EE without running any ROM code at all. In fact, it completely discards and reclaims the SBIOS. :smile: The SIF, for example, is implemented in drivers/ps2/sif.c and is complete enough to run simple IOP services such as heap allocation that is needed for the Linux USB OHCI device driver. I'm hoping to discard and reclaim the memory for most if not all IOP modules as well, since I think Linux eventually will have better variants of them anyway.

[sp193]

This is a Linux project, so the IOP isn't important here I guess. But the PlayStation 2 IOP will always run Sony's proprietary IOP kernel, regardless of whether Linux advertises that or not. It may replace the EE kernel, but it cannot run the whole PS2 without the IOP.

The EXTINFO structure is known. I also wrote my own tool for building images, called ROMIMG. PCSX2 also has its own code for working on the ROM format, which I also took some information from.

[Ravenslofty]

GXemul can emulate a PS2 running Linux to some extent, but it doesn't have USB support which the official kernel requires, so it just hung.

As for the ROM, I'd imagine you'd want to boot Linux first? Sure, you can overwrite the ROM-in-RAM, but you need to get there first.

[frno7]

GXemul can emulate a PS2 running Linux to some extent, but it doesn't have USB support which the official kernel requires, so it just hung.

Oh, nice! USB is optional with the 5.x Linux kernels I'm working on so that shouldn't be problem then.

As for the ROM, I'd imagine you'd want to boot Linux first? Sure, you can overwrite the ROM-in-RAM, but you need to get there first.

Of course. Everything up to actually starting Linux is running a combination of ROM code and other software, such as Free MC boot, and so on.

[frno7]

This is a Linux project, so the IOP isn't important here I guess.

Well, the IOP as a piece of hardware is as important as ever, also for Linux, but if memory can be reclaimed by discarding unused modules then that is an improvement. More space for useful things. After all, the Linux project is about using the hardware, and not Sony's ROM software. :grin:

But the PlayStation 2 IOP will always run Sony's proprietary IOP kernel, regardless of whether Linux advertises that or not.

I suppose the IOP kernel could be replaced, if one wants to. Why not?

The EXTINFO structure is known. I also wrote my own tool for building images, called ROMIMG. PCSX2 also has its own code for working on the ROM format, which I also took some information from.

Thanks, @sp193! I found ROMIMG and will have look at the EXTINFO format.

[frno7]

@sp193, ROMIMG was indeed helpful and EXTINFO is now decoded in commit 81dd020b2aff3a151ccec53936dc2db58f23e93b and shown in sysfs with commit fc83e56e55d2a8f4194708445979813b679323aa. Would you know what the 0x7f type means? It is EXTINFO_FIELD_TYPE_NULL in your code. Few ROM files use it. Why would they have this property?

@mirh, is the PS3 scene active with OtherOS? I have a few PS3 machines with it installed, and would be happy to work on that too.

[mirh]

Uh, well.. Put aside Geoff, the only person doing something "active" with linux that I know is @rxrbln You may want to check this guide then.. It may not sport mainline, but at least way noober people than you got it working.

On the other hand, the big news on the global scene is the recent invention of HFW/HEN which finally opened >3.56 minfw to the world (in addition to providing yet again a software entry point to all fat and slims owners of course). Though (at least for the moment?) you can't get OtherOS++ without CFW.

While we are at it, I'd also like to remember of PSXLinux and vita-whatever.

[sp193]

0x7F seemed to be for the "-" entries, which exists to align the adjacent file at a specific address.

[uyjulian]

- files are padding files.
I have a WIP reimplementation of the modules included in the PS2 ROM located here: https://github.com/uyjulian/ps2iop Currently, stubs are pushed to the repository.
It is possible to reload the software currently running in the IOP with other versions using UDNL. When it is reset, it is running the modules from the boot ROM. A reset -> UDNL chain is possible, which allow you to make sure that the specific version of modules are loaded.
It may also be possible to run bare-metal ELFs on the IOP (like the romflash tool on PS2 TOOL models).
The IOPRP.img file used with UDNL for loading updated IOP modules has the same filesystem format as the PS2 ROM.

[frno7]

The following files in a SCPH-50004 have the 0x7f property:

ROM	file index	name	address	type
rom0	0	RESET	0x1fc00000	0x7f
rom0	32	RDRAM	0x1fc41000	0x7f
rom0	43	IOPBOOT	0x1fc4a000	0x7f
rom0	46	TBIN	0x1fc4b800	0x7f
rom0	52	KROMG	0x1fc64000	0x7f
rom0	54	KROM	0x1fc66000	0x7f
rom0	56	VERSTR	0x1fc7ff30	0x7f
rom0	58	ROMGSCRT	0x1fc80000	0x7f
rom1	0	RESET	0x1e000000	0x7f

The alignment seems to be to a page size, typically around 4096 bytes or so, with the curios exceptions of TBIN and VERSTR. Except for the RESET files at index 0, all the files above are preceded with these - padding files:

ROM	file index	name	size
rom0	31	-	16
rom0	42	-	208
rom0	45	-	1200
rom0	51	-	2960
rom0	53	-	832
rom0	55	-	192
rom0	57	-	112

Still, the question somewhat remains as to why the 0x7f is marked in the files following the padding files and what purpose that mark could serve there. Maybe it is some kind of annotation designed for a ROM file layout tool. Perhaps we will never know.

Anyway, the original issue can now be considered fully resolved. Many thanks for all the help! :smile:

@mirh, do you know if any CFW could be configured to default cold boots into OtherOS? As far as I understand it, CFWs such as Rebug only boots into GameOS, which means one always has to click through various menus every time OtherOS is booted. I'm running Gentoo on both the PS2 and the PS3, actually. :grin:

Thanks for your link, @uyjulian! Looks like it is worth studying your implementation.

[mirh]

I am under the vague impression that yes, you can (and indeed René videos don't ever seem to show gameos)

[sp193]

Most of those files have to exist at fixed addresses. I know that RESET must absolutely be at the start of the file, as it contains the bootstrap code that must reside at the standard MIPS reset vector.

Newer PS2s also have DECKARD, which is likely also flagged as such a file.

RDRAM is jumped to, so it must also reside at a known address. Some of the other files like are used by PS mode. It is possible that the PS ROM also expects them at fixed addresses.

ROMGSCRT is used by PS2Linux. From its code, you can tell how it was meant to be resolved.

Kernels like TBIN, KERNEL and IOTBOOT seem to not actually need to be located at fixed places because they are actually scanned for, by RESET.

rom1 belongs to the DVD ROM. Even if that is not the BOOT ROM, it also contains RESET, although that has no code in it.

[frno7]

@sp193, I have just created a new iopmod repository that is specifically made for IOP modules. The ABI is compatible with Sony and PS2SDK modules, but the source code is organised differently. Modern GCC and binutils are used. I intend to write all IOP modules for Linux there, but in principle any kind of IOP module could be compiled with it.

[frno7]

@sp193, interestingly, some European PAL machines report J in their ROMVER files, for example 0220JC20050620 for SCPH-75004 and 0220JC20060210 for SCPH-77004. These are not Japanese machines. All other European PAL machines I have seen report E:

• SCPH-30004
• SCPH-30004 R
• SCPH-39004
• SCPH-50004
• SCPH-70004

The Japanese SCPH-37000 L reports J. All run the Linux 5.1 kernel successfully, as I am preparing #1.

I guess some other method is needed to determine the region of the machine.