Some machines lacks rom0:OSDCNF

[AKuHAK]

linux/drivers/ps2/sif.c

Line 49 in 1a3ad68

#define IOP_RESET_ARGS "rom0:UDNL rom0:OSDCNF"

Some PS2 machines lack OSDCNF in their ROM0. For better compatibility, it will better to avoid using this parameter for resetting IOP, or at least use this parameter only on machines that have this inside ROM0.
So it will lead to incompatibility with SCPH-10000, SCPH-15000, DTL-H10000, all ps2 TOOLs, Namco systems and ps2 emulators inside ps3 and ps4.
You can read more about restrictions here: https://assemblergames.com/threads/ps2-pops-stuff-popstarter.45347/page-39#post-771470

To my mind, it will be safe to use NULL for IOP resetting but I am not quite sure. It is better to ask @sp193 about this.

[AKuHAK]

I also find

linux/arch/mips/ps2/identify.c

Line 40 in 1a3ad68

int err = rom_read_file(rom0_dir, "OSDSYS",

PS2 TOOL doesn't have OSDSYS inside rom0 so this command will fail on it. I realized that it doesn't have OSDSYS only in WS moe which is abnormal and it is better to ignore it.

Inside ps2 part of ps3 and ps4 there is no ROMVER unfortunately. However, I am not quite sure that this will affect cause PS3 and PS4 use some kind of emulator (can be treated as not 'official') so this is not so important. But I own ps3 with built-in PS2 board inside (CECH-A) so I can make tests if you need it. Im sorry wrong information, ROMVER is presented inside all models.

[frno7]

Interesting, thanks! I tried to remove rom0:OSDCNF but then SIF RPC bind failed with error code -6. An investigation will be needed to figure out why that happens, and what a working alternative would look like. Perhaps some important IOP service is missing then. Same goes with the empty string for IOP_RESET_ARGS, which I suppose corresponds to NULL?

It would be great to have SCPH-10000, SCPH-15000, DTL-H10000, TOOL and Namco working properly with Linux as well, although I am unable to test those particular models myself, unfortunately.

[AKuHAK]

I can refer only to standard practice for resetting IOP:

    SifInitRpc(0);

#ifdef _DTL_T10000
    while (!SifIopReset("rom0:UDNL", 0))
        ;
#else
#ifdef __DECI2_DEBUG
    while (!SifIopRebootBuffer(&deci2_img, size_deci2_img))
        ;
#else
     //Final IOP reset, to fill the IOP with the default modules.
    while (!SifIopReset("", 0))
        ;
#endif
#endif

    dev9Initialized = 0;
    while (!SifIopSync())
        ;

    SifInitRpc(0);
    SifSetCmdBuffer(OplSifCmdbuffer, OPL_SIF_CMD_BUFF_SIZE);

Taken from OPL. You can safely ignore DTL and DECI2 exception but the rest should be correct.

So you should init SIF, then you should wait until SifIopReset is completed, then wait until SifIopSync is completed and only then init SIF again (!) and do the rest.

[AKuHAK]

Please check this thread for proper ps2 initialize.

[frno7]

Linux kernel SIF initialisation is currently documented as thirteen steps:

linux/drivers/ps2/sif.c

Lines 740 to 781 in c94ed72

	/**
	* sif_init - initialise the SIF with a reset
	*
	* The IOP follows a certain boot protocol, with the following steps:
	*
	* 1. The kernel allocates a DMA memory buffer that the IOP can use to send
	* commands. The kernel advertises this buffer by writing to the MAINADDR
	* register.
	*
	* 2. The kernel reads the provisional SUBADDR register to obtain the
	* corresponding command buffer for the IOP.
	*
	* 3. The kernel clears the %SIF_STATUS_BOOTEND flag in the SMFLAG register.
	*
	* 4. The kernel issues the %SIF_CMD_RESET_CMD command to the IOP.
	*
	* 5. The kernel indicates that the SIF and system commands are ready by
	* setting the %SIF_STATUS_SIFINIT and %SIF_STATUS_CMDINIT flags in the
	* SMFLAG register.
	*
	* 6. The kernel waits for the IOP to set the %SIF_STATUS_BOOTEND flag in
	* the SMFLAG register.
	*
	* 7. The kernel indicates that the boot is completed by writing updating
	* its MAINADDR and setting the %SIF_STATUS_CMDINIT and %SIF_STATUS_BOOTEND
	* flags in the MSFLAG register. The %SIF_UNKNF260 register is set to 0xff.
	*
	* 8. The kernel reads the final SUBADDR register to obtain the command
	* buffer for the IOP.
	*
	* 9. Register SIF commands to enable remote procedure calls (RPCs).
	*
	* 10. Reset the SIF0 (sub-to-main) DMA controller.
	*
	* 11. Service SIF0 RPCs via interrupts.
	*
	* 12. Enable the IOP to issue SIF commands.
	*
	* 13. Enable the IOP to issue SIF RPCs.
	*
	* Return: 0 on success, otherwise a negative error number
	*/

It seems OPL SifIopReset corresponds to step 4, and SifIopSync to step 6?

Steps 1 and 2 are repeated in 7 and 8, which I believe corresponds to the double SifInitRpc calls? A SIF command is used to reset the IOP, but actual remote procedure calls (RPCs) are not needed until step 9 and enabled in step 13.

I seems you are right that IOP module loading must be conditional on the machine model, which means that IOP_RESET_ARGS cannot be the same for all, although it works with all models that I have tested that are SCPH-30004, SCPH-30004 R, SCPH-37000 L, SCPH-39004, SCPH-50004, SCPH-70004, SCPH-75004 and SCPH-77004. Those are fairly common models, though.

[AKuHAK]

You are not using any part of our homebrew ps2sdk for unknown reason. I see your post that there is something strange after you boot kernel from uLaunchELF, this is because each ps2 app (firstly you are building ps2 app) should reset ps2 into proper state, but it seems that you are depending of what uLaunchELF does before and do not clear and set up everything. Also sometimes official Sony recomendations are not the best and it is better to use fixes from homebrew ps2sdk. But anyway if you are not using ps2sdk functions you should clone them and clone them as close as you can:
[SifInitRpc(0);](https://github.com/ps2dev/ps2sdk/blob/master/ee/kernel/src/sifrpc.c#L388-L426
SifIopReset())
It seems that your steps are very close to SifIopReset. But remember that you should repeat SifIopReset until it will return success.
SifIopSync
You should repeat this step again until you return success.

[sp193]

@AKuHAK I believe the PS2Linux folks have traditionally not used the homebrew PS2SDK as they have the RTE library. The Linux kernel also replaces the EE kernel.

The proper way to reboot the IOP without any IOPRP image, is to pass an empty string. I used to pass a NULL, until I realize that it was only possible with the homebrew SDK's SifIopReset() function.
Rebooting the IOP without any arguments specified, will cause the default IOP kernel modules to be loaded. This set of modules are the same across all PlayStation 2 consoles, regardless of model or type.

If you use OSDCNF, it will only work with consoles that have OSDCNF. If your software stops working after not using OSDCNF, then you shaped your work to be dependent on the board-specific modules (X-modules, OSDSND etc).
It's likely that you are expecting XMCMAN, XPADMAN etc to be loaded, which are usually automatically loaded with OSDCNF.

OPL's method of rebooting the IOP is more complicated because I also designed it to have a custom reboot procedure to load in DECI2 modules (which are missing from the CEX/DEX ROM) for debugging.

You really only need to initialize the SIF, issue the reset command, wait for completion, and then finally bring up the SIF interface.

Linux kernel SIF initialisation is currently documented as thirteen steps:

linux/drivers/ps2/sif.c

Lines 740 to 781 in c94ed72

	/**
	* sif_init - initialise the SIF with a reset
	*
	* The IOP follows a certain boot protocol, with the following steps:
	*
	* 1. The kernel allocates a DMA memory buffer that the IOP can use to send
	* commands. The kernel advertises this buffer by writing to the MAINADDR
	* register.
	*
	* 2. The kernel reads the provisional SUBADDR register to obtain the
	* corresponding command buffer for the IOP.
	*
	* 3. The kernel clears the %SIF_STATUS_BOOTEND flag in the SMFLAG register.
	*
	* 4. The kernel issues the %SIF_CMD_RESET_CMD command to the IOP.
	*
	* 5. The kernel indicates that the SIF and system commands are ready by
	* setting the %SIF_STATUS_SIFINIT and %SIF_STATUS_CMDINIT flags in the
	* SMFLAG register.
	*
	* 6. The kernel waits for the IOP to set the %SIF_STATUS_BOOTEND flag in
	* the SMFLAG register.
	*
	* 7. The kernel indicates that the boot is completed by writing updating
	* its MAINADDR and setting the %SIF_STATUS_CMDINIT and %SIF_STATUS_BOOTEND
	* flags in the MSFLAG register. The %SIF_UNKNF260 register is set to 0xff.
	*
	* 8. The kernel reads the final SUBADDR register to obtain the command
	* buffer for the IOP.
	*
	* 9. Register SIF commands to enable remote procedure calls (RPCs).
	*
	* 10. Reset the SIF0 (sub-to-main) DMA controller.
	*
	* 11. Service SIF0 RPCs via interrupts.
	*
	* 12. Enable the IOP to issue SIF commands.
	*
	* 13. Enable the IOP to issue SIF RPCs.
	*
	* Return: 0 on success, otherwise a negative error number
	*/

It seems OPL SifIopReset corresponds to step 4, and SifIopSync to step 6?

Steps 1 and 2 are repeated in 7 and 8, which I believe corresponds to the double SifInitRpc calls? A SIF command is used to reset the IOP, but actual remote procedure calls (RPCs) are not needed until step 9 and enabled in step 13.

(1) and (2) are done during initialization of SIFCMD.
(3) to (5) are done by SifIopReset(), while (6) is done by SifIopSync().
(7) is done by both the IOP and EE by reading each others SIF registers, although this description seems to be written from the IOP's perspective (hence MSFLAG, rather than SMFLAG).
(8) to (13) seem to be for initialization of the SIFCMD (and SIFRPC) implementation.

SifInitRpc() has to be called before the reboot. This will do a few things. It will internally call SifInitCmd(), to initialize SIF communications with the existing IOP kernel. It will also initialize the IOP side with the new SIFCMD receive buffer address. So if you don't do this, it could corrupt EE memory when you reset the IOP.
I know Sony documented calling SifInitCmd(), but we might be just using a really old SDK design (the default IOP modules were based on SDK release v1.3.4). Or the way we do things, is just different.

I seems you are right that IOP module loading must be conditional on the machine model, which means that IOP_RESET_ARGS cannot be the same for all, although it works with all models that I have tested that are SCPH-30004, SCPH-30004 R, SCPH-37000 L, SCPH-39004, SCPH-50004, SCPH-70004, SCPH-75004 and SCPH-77004. Those are fairly common models, though.

Although this is true, I think you should not be using board-specific modules. This has been a wrong practice that has been going on for too long.

I also find

linux/arch/mips/ps2/identify.c

Line 40 in 1a3ad68

int err = rom_read_file(rom0_dir, "OSDSYS",

PS2 TOOL doesn't have OSDSYS inside rom0 so this command will fail on it. I realized that it doesn't have OSDSYS only in WS moe which is abnormal and it is better to ignore it.

Inside ps2 part of ps3 and ps4 there is no ROMVER unfortunately. However, I am not quite sure that this will affect cause PS3 and PS4 use some kind of emulator (can be treated as not 'official') so this is not so important. But I own ps3 with built-in PS2 board inside (CECH-A) so I can make tests if you need it. Im sorry wrong information, ROMVER is presented inside all models.

The WS mode ROM version is 0100 - so it will be treated as a "SCPH-10000". Sony would print an "Unknown" if the model cannot be determined, which is something this code is doing differently.

The TOOL used to not have OSDSYS in its ROMs because it used to not boot discs directly. This function was added later on, for people to test their master discs without needing to write some code.

Who knows why Sony would want to try to read the model number from OSDSYS from a late SCPH-10000/SCPH-15000/DTL-H10000. At the end of the day, we haven't found one that doesn't isn't labelled as a "SCPH-10000" by OSDSYS. But this was how Sony did it for the v1.01 ROMs.

[frno7]

You are not using any part of our homebrew ps2sdk for unknown reason.

That is true, and as @sp193 notes, Linux replaces the EE kernel. Linux is an operating system, after all. One of the goals is to run entirely on the hardware. Another goal is to use fully modern and up-to-date versions of tools such as GCC, which is particularly important to compile modern Linux applications.

The older Linux 2.6 kernel relies on the BIOS for certain services, perhaps most notably handling of the SIF, but the latest Linux kernel discards the BIOS and handles the hardware directly instead. Linux has several advanced sub-systems, for example related to DMA, and hopefully these can be put into effective use with the capabilities of the PS2 hardware.

The great common goal for both the PS2SDK and Linux for the PS2 is, as I see it, to learn about, explore and have fun with the hardware. Having two, or more, independent implementations is a strength, I think, as projects can learn techniques from the others that do things differently. 😄

This Linux project does not attempt to mimic Sony application interfaces as much as the PS2SDK. However, when handling the IOP in particular, some level of SIF protocol compatibility is necessary since the IOP is operated from ROM routines.

Linux is concered with MIPS o32 and n32 ABI compatibility. The FPU, for example, is emulated in software for standard MIPS ELF executables due to FPU hardware anomalies, as described in #3.

I see your post that there is something strange after you boot kernel from uLaunchELF, this is because each ps2 app (firstly you are building ps2 app) should reset ps2 into proper state, but it seems that you are depending of what uLaunchELF does before and do not clear and set up everything.

Yes, as described in #7, the Linux kernel currently uses uLaunchELF as a boot loader. This works well, except for the CP0.Status anomaly. Perhaps a lower-level loader, as described in #4, could be used as a complement or a replacement in the future.

Also sometimes official Sony recomendations are not the best and it is better to use fixes from homebrew ps2sdk. But anyway if you are not using ps2sdk functions you should clone them and clone them as close as you can:

The Academic Free License version 2 licence used for the PS2SDK is considered to be incompatible with the GPL for Linux. This is unfortunate, and means that we cannot copy code between the projects unless it is dual-licenced with for example MIT or some of the other compatible ones.

But remember that you should repeat SifIopReset until it will return success.

This is very interesting. Why is repetition required? I have not observed that IOP reset is unreliable.

[sp193]

This Linux project does not attempt to mimic Sony application interfaces as much as the PS2SDK. However, when handling the IOP in particular, some level of SIF protocol compatibility is necessary since the IOP is operated from ROM routines.

All IOP kernel modules are replaceable through the IOP reboots (by supplying an IOPRP image to UDNL), but you'll be defining your own standard if you deviate from how Sony designed it.
The only time when the IOP runs directly from ROM, is during bootup when it accesses the reset vector and runs IOPBOOT. Or if it is in PlayStation mode.

But remember that you should repeat SifIopReset until it will return success.

This is very interesting. Why is repetition required? I have not observed that IOP reset is unreliable.

The IOP reboot involves sending a SIFCMD message. Within (sce)SifSendCmd() is a call to SifSetDma(), which can fail if the queue within the kernel is full. Although we all know that it's not supposed to be full at that point.

Perhaps, it's just a good practice to ensure that your code will never fail, by handling all return values. Whether to do this or not, is up to you.

[frno7]

All IOP kernel modules are replaceable through the IOP reboots (by supplying an IOPRP image to UDNL), but you'll be defining your own standard if you deviate from how Sony designed it.
The only time when the IOP runs directly from ROM, is during bootup when it accesses the reset vector and runs IOPBOOT. Or if it is in PlayStation mode.

Thanks, this is valuable information! Sony compatible IOP modules are sometimes of limited use, since Linux already has sub-systems for USB, file systems, networking, and various other devices and protocols.

It can make sense to write new IOP modules that work effectively with these Linux sub-systems, at suitable interface and protocol levels. The low-level SIF DMA command and RPC protocol can probably remain the same though, as I’m not aware of any particular reason to do that differently.

The iopmod project is a starting-point for IOP modules for Linux. An IRQ relay module is currently implemented, as it is needed by the current USB OHCI device driver.

Handling of the IOP is a bit loose at present, so things may change. 😄

The IOP reboot involves sending a SIFCMD message. Within (sce)SifSendCmd() is a call to SifSetDma(), which can fail if the queue within the kernel is full. Although we all know that it's not supposed to be full at that point.

Yes, it seems reasonable for the Linux kernel, when invoked by a boot loader, to expect that the IOP is idle and not in the middle of some transactions.

Perhaps, it's just a good practice to ensure that your code will never fail, by handling all return values. Whether to do this or not, is up to you.

All return codes that I’m aware of are checked by the Linux kernel. However, it doesn’t make multiple attempts at resetting the IOP. I will have to think about this.

[AKuHAK]

Interesting, thanks! I tried to remove rom0:OSDCNF but then SIF RPC bind failed with error code -6. An investigation will be needed to figure out why that happens, and what a working alternative would look like. Perhaps some important IOP service is missing then. Same goes with the empty string for IOP_RESET_ARGS, which I suppose corresponds to NULL?

If you use OSDCNF, it will only work with consoles that have OSDCNF. If your software stops working after not using OSDCNF, then you shaped your work to be dependent on the board-specific modules (X-modules, OSDSND etc).
It's likely that you are expecting XMCMAN, XPADMAN etc to be loaded, which are usually automatically loaded with OSDCNF.

But there is still a problem that you have an error when trying to remove OSDCNF, I personally don't think that this is because board-specific modules are loaded. To my mind its because IOP is not resetting with standards that cause problems with some arguments.

The great common goal for both the PS2SDK and Linux for the PS2 is, as I see it, to learn about, explore and have fun with the hardware. Having two, or more, independent implementations is a strength, I think, as projects can learn techniques from the others that do things differently.

One of the goals is to run entirely on the hardware.

Yes, as described in #7, the Linux kernel currently uses uLaunchELF as a boot loader. This works well, except for the CP0.Status anomaly. Perhaps a lower-level loader, as described in #4, could be used as a complement or a replacement in the future.

I understand your point of view, but to my mind, it is overkill and reinventing the wheel. You still are building a PS2 app (in the first place) and only secondly Linux system. You are trying to make as much as possible from the Linux side which can cause anomalies if you are trying to make all from scratch.
As about license - I don't mean to copy code from ps2sdk line-per-line - just investigate how exactly IOP should be reset in the proper way.

[sp193]

SIF RPC bind will fail if the IOP RPC server module does not exist - like if you are using libpad without loading the right PADMAN version.

[frno7]

If you use OSDCNF, it will only work with consoles that have OSDCNF. If your software stops working after not using OSDCNF, then you shaped your work to be dependent on the board-specific modules (X-modules, OSDSND etc). It's likely that you are expecting XMCMAN, XPADMAN etc to be loaded, which are usually automatically loaded with OSDCNF.

The IOP library dependencies are intrman, loadcore, sifcmd, sifman and thbase. In addition, the IOP heap memory RPC service is expected to be available (to allocate a USB OHCI buffer).

More specifically, the printk IOP module, that prints to the kernel log, has the following dependencies:

iopmod name		printk
import library	0x0102	intrman
import		23	intrman_in_irq QueryIntrContext
import library	0x0101	loadcore
import		 6	loadcore_register_library	
import		 7	loadcore_release_library	
import library	0x0101	sifcmd
import		12	sifcmd_send_cmd
import		13	sifcmd_send_cmd_irq isceSifSendCmd
import library	0x0101	sifman
import		 8	__sifman_dma_stat sceSifDmaStat

Note: When it says for example intrman_in_irq QueryIntrContext it means the two symbols are aliased, and refer to the same function, namely the one with id 23 for intrman in this case. Typically, a Linux module would refer to intrman_in_irq but a PS2SDK module would refer to QueryIntrContext. It’s just a matter of using a particular naming convention.

Similarly, the irqrelay module, that forwards IOP interrupts to the EE, has the following dependencies:

iopmod name		irqrelay
import library	0x0102	intrman
import		 4	intrman_request_irq RegisterIntrHandler
import		 5	intrman_release_irq ReleaseIntrHandler
import		 6	intrman_enable_irq EnableIntr
import		 7	intrman_disable_irq
import		17	intrman_cpu_suspend_irq CpuSuspendIntr
import		18	intrman_cpu_resume_irq CpuResumeIntr
import		23	intrman_in_irq QueryIntrContext
import library	0x0101	sifcmd
import		12	sifcmd_send_cmd
import		13	sifcmd_send_cmd_irq isceSifSendCmd
import		17	sifcmd_register_rpc sceSifRegisterRpc
import		19	sifcmd_set_rpc_queue
import		22	sifcmd_rpc_loop
import		24	sifcmd_remove_rpc sceSifRemoveRpc
import		25	sifcmd_remove_rpc_queue
import library	0x0101	thbase
import		 4	thbase_create
import		 5	thbase_delet
import		 6	thbase_star
import library	0x0101	sifman
import 		 8	__sifman_dma_stat sceSifDmaStat
import		24	sifman_set_sm_flag sceSifSetSMFlag
import		28	sifman_intr_main

So, some of these dependencies are not initialised by the IOP unless rom0:UDNL rom0:OSDCNF is given as a reset argument.

Looking at the contents of rom0:OSDCNF, I agree that it appears excessive with a lot of modules that are not needed:

RESEROMDIRHPEXTINFOXIOPBTCON?' D20030227-193049,osd.conf,osdconf.bin,hana@rom-server/~/g/app/rom' @800
SYSMEM
LOADCORE
EXCEPMAN
INTRMANP
INTRMANI
SSBUSC
DMACMAN
TIMEMANP
TIMEMANI
SYSCLIB
HEAPLIB
EECONF
THREADMAN
VBLANK
IOMAN
MODLOAD
ROMDRV
ADDDRV
STDIO
SIFMAN
IGREETING
XSIFCMD
REBOOT
XLOADFILE
XCDVDMAN
XCDVDFSV
SIFINIT
XFILEIO
SECRMAN
EESYNC
RMRESET
CLEARSPU
XSIO2MAN
XMTAPMAN
XMCMAN
XMCSERV
XPADMAN
XRMMAN2
OSDSND

You really only need to initialize the SIF, issue the reset command, wait for completion, and then finally bring up the SIF interface.

Yes, that sounds reasonable!

Although this is true, I think you should not be using board-specific modules. This has been a wrong practice that has been going on for too long.

What modules would you recommend to resolve the dependencies for printk and irqrelay above?

[sp193]

Among the imports you have listed, I cannot see any that are likely to be only available with the board-specific modules.

Previously, you wrote that it was a problem with binding with a SIF RPC. Have you determined that it was either of those two IOP modules that could not be loaded, due to a dependency problem? In other words, (Sif)LoadModule returned the exact error code which indicates that.
Which SIF RPC was it?