@sp193 I will address my question to you as you seem to be the main ps2 guy every where I look. Just wondering if you know of anyway to patch an ELF to boot from mc0/mc1 instead of cdfs/cdrom0 ?
Hi, Welcome to AG! Your question is quite broad, so I can only just give you some general information: it depends on why the ELF will not boot from the device. Is there a particular piece of software in question? IMO most ELFs will not have problems booting from most devices. Some software (mainly from me) will totally not work when made to boot from some unsupported device, as files will need to be accessed. The running software will have full control over the PlayStation 2, and is also responsible for loading the driver modules for all devices that it will support. Some software that assume that it boots from the CD/DVD drive (i.e. SnesStation and HDLoader) might not actually have problems booting from other devices, but they were just made to wait for the CD/DVD drive to be ready. On the SCPH-50000 and later, not having a disc inserted would result in such software seemingly getting stuck. This may not necessarily have been a deliberate anti-piracy thing, but might be even a design oversight (due to not knowing how to correctly deal with having no disc inserted).
Thanks for your reply It's an official $ony compiled ELF from a demo cd, when I look at it through a hex editor I can see it's loading modules from cdrom0: Basically what I'm trying to do is strip the demo of games and just use the multiloader elf to play a video on boot up. It works but currently only in the form of a burnt DVD and ESR doesn't work for my purposes so I have a modbo chipped console. Trying to make it a software option rather than requiring hardware. I have tried hex editing but I'm not having much luck getting it to boot in extracted form from mc0
Since it's an official program, there may be some issues: Officially, we cannot load unsigned code from user-writable devices like the memory card. As such, IRX modules (and even the ELF itself) cannot be loaded. Hence if the game attempts to load an IRX from memory card, it will fail to. Homebrew software are free from all restrictions because of homebrew patches on the IOP kernel. The software may support the memory card. But the IOP kernel does not, by default. Hence it cannot possibly load IRX modules from the memory card, until MCMAN is first loaded. Official software will always reboot the IOP with an IOPRP image. The IOP kernel supports the memory card as a device... but it cannot be used as an image source because it is prohibited. Hence, you need to write and inject code: For (1), the sbv_patch_disable_prefix_check() patch can be used to relax the restrictions on module loading, after the IOP reset. You need to write some code that will run this patch after the SIF has been reinitialized, after the IOP reboot. OR - you replace the module-loading code, embed all modules and load them from EE RAM instead. For (2), it is a chicken-and-egg problem, so you need to rewrite the module-loading code after the IOP reset, to load at least SIO2MAN and MCMAN from EE RAM instead. These modules must be hence embedded. (Thankfully, there is probably no need to apply sbv_patch_enable_lmb() because most games should have been made with a SDK that supports LoadModuleBuffer()) There is no direct solution for (3), except for replacing the call to sceSifRebootIop with a call to a function like SifIopRebootBuffer that customizes the IOP reboot process, so that the IOPRP image can be accessible. The IOPRP image must be hence embedded and stored in EE RAM. You need to be sure that the program does not use libcdvd APIs to locate (i.e. sceCdLayerSearchFile) and access files. If it does, then you need to replace more code. You will likely need to edit all paths because the cdrom0 device requires the filename to always have the version suffix (";1"), but this is not required on every other device. BTW, the memory card is very slow. Not sure if it is good enough for video playback.
