Help with running elf on PS2 TOOL

[ThePinkBunny]

There are a few elf files I would like to run on my tool.
When I extracted the bios on my previous tool, I put the system.cnf, dummy, and boot.elf on a mastered disc, and everything booted fine.

Now i am tring to run uLaunch4.42(on my current tool) but I get errors when it starts the elf.

Input ELF format filename = cdrom0:\BOOT.ELF;1
0 01c921a0 0006e01d .......
Loaded, cdrom0:\BOOT.ELF;1
start address 0x1d00008
gp address 00000000
loadmodule: fname rom0:SIO2MAN args 0 arg
loadmodule: id 31, ret 0
loadmodule: fname rom0:PADMAN args 0 arg
loadmodule: id 34, ret 0
Unknown device ''
*** Unexpected reply - type=BREAKR code=ff result=EXCEPTION
*** Target program stopped. Check the location by dr command.

# EEKERNEL[IntcHandler] : Interrupt handlers must call ExitHandler().

And the screen shows a messed up looking (and frozen) uLaunch sceen.

I have tried different versions but same result always.
I even tried "pload BOOT.ELF" (witch loaded) but after "run" it gives same thing.
The only difference from my old tool is the firmware, 3.0 now 2.7 then. although I did have to update to 3.0 to run FFX Inter. but i did not run elf's after that, so i don't know if that's why i cant now.

Thanx in advanced for any help :)

[SilverBull]

I got the same error when trying to run uLE quite some time ago. Unfortunately, there is no easy fix for this; I ended up patching the uLE binary (as it was quicker than setting up a VM for compiling the program from source), then inserted some files from a retail PS2 BIOS via the debugger connection. Give me a few hours so I can dig for my old files...

The reason the crash occurs is that the homebrew file system library uLE is linked to is incompatible with newer releases of the PS2 SDK. Sony has changed the EE<->IOP interface of this library in some of the later BIOS versions, so data sent by the older client-side code cannot be interpreted correctly by the IOP. Depending on the call, the IOP may either catch the error (that's why you get the "Unknown device" error) or crash entirely. As the errors are not correctly propagated back to the EE, it will also start the act strange. If you attach the debugger, you will see why the EE hangs; in my case, it was a "Reserved Instruction" exception, ultimately caused by an invalid memory reference.

[ThePinkBunny]

I got the same error when trying to run uLE quite some time ago. Unfortunately, there is no easy fix for this; I ended up patching the uLE binary (as it was quicker than setting up a VM for compiling the program from source), then inserted some files from a retail PS2 BIOS via the debugger connection. Give me a few hours so I can dig for my old files...

The reason the crash occurs is that the homebrew file system library uLE is linked to is incompatible with newer releases of the PS2 SDK. Sony has changed the EE<->IOP interface of this library in some of the later BIOS versions, so data sent by the older client-side code cannot be interpreted correctly by the IOP. Depending on the call, the IOP may either catch the error (that's why you get the "Unknown device" error) or crash entirely. As the errors are not correctly propagated back to the EE, it will also start the act strange. If you attach the debugger, you will see why the EE hangs; in my case, it was a "Reserved Instruction" exception, ultimately caused by an invalid memory reference.

Thank you very much for you quick reply.
and once I have this patched uLE, does that cover me for launching homebrew though uLE?, or will I get the same error if the elf to be launched is also linked to an incompatible library?

You also speak of a debugger, Is this an extra piece of hardware? It seems you fixed your problem using it. so it seems useful.

Thank you again.

[SilverBull]

and once I have this patched uLE, does that cover me for launching homebrew though uLE?, or will I get the same error if the elf to be launched is also linked to an incompatible library?

It depends, but you'll basically run into the same problem for each homebrew.
Homebrew libraries expect the IOP BIOS to be compatible to the original SCPH-10000. In retail and TEST machines, this can be achieved by issuing an IOP reset to any of the included kernels (null, EELOADCNF, OSDCNF), as they all contain appropriate modules (later modules add calls, but the basic 10k functions are usually still present). However, the TOOL flashrom contains an IOP BIOS as used by games of that specific SDK release, which might use completely different interfaces.

To get homebrew running on the TOOL, you need to boot a corresponding IOP BIOS first, as there are no homebrew libraries corresponding to the newer BIOSes as used by games. However, each program on a PS2 is free to reboot the IOP anytime it wants to any BIOS it likes. Therefore, even if you manage to get the program starting under the correct BIOS, it might still choose to issue a reboot call (to the wrong BIOS) afterwards...

There is no general solution, besides recompiling the program to detect whether it is running on a TOOL and use a different BIOS path if necessary. In addition, on a TOOL, it also needs to load any non-default modules from an alternative path, as the ones present in ROM are incompatible as well.

Homebrew can be patched to work on a TOOL, but it is a pain to do so, and the program needs a special startup sequence afterwards (it only works on a TOOL, only if certain additional files are present, and generally cannot be started from cdrom at all):

• Patch all IOP reboot calls to refer to an external BIOS ("host0:IOPRP")
• Load additional modules from external storage instead of ROM0, but make sure they match the external BIOS ("rom0:SIO2MAN" => "host0:SIO2MAN")

You also speak of a debugger, Is this an extra piece of hardware? It seems you fixed your problem using it. so it seems useful.

DSEDB/DSIDB, as included in the official SDK.

Wait, don't you have a development PC with the Sony PS2 SDK installed? To get my modified uLE running, besides other things, you need to compile a certain program from source using the official SDK. I haven't ported the code to the homebrew version yet, and due to copyright issues I cannot distribute the compiled binary (which links to Sony libraries). :shrug:

[ThePinkBunny]

Very Informative, and I thought that's what you meant, after i replied, lol, Iv just been up all day/night tiring to figure the problem out myself, so I saw what you said wrong. ( I saw it as if you had some sort of additional debugger hardware, something like the performance analyser)

anyway. Do you still have the patched version of uLE? And if/when you find it, do you mind sharing?

And, The patching process does not seem "too" difficult ( may need some sleep :P ).
When ever I get enough grasp on Programing for the EE and start literly homebrewing, Would not I be able to account for the Tools libraries vs retail. sence my end(ish) goal does not include running my homebrew on retail systems. My resoning for that brings me to another question,

I have not see anywhere, something saying this. "the PS2 TOOL has 128MB RAM accessible to the EE"
BUT when using the debugger it says 128MB, AND there is a flag for limiting to 32MB.
So question.. Can I develop homebrew that would use more than 32MB ram, if ran on the tool only.

[SilverBull]

Okay, I found the files. Just tested it on my TOOL, and the modified uLE v4.39 works fine. To repeat what I did back then, you'll need the following:

• The modified ULE v4.39 binary: http://www.megaupload.com/?d=53A6AL4C, Password is "ASSEMblergames.com"
• My romfs.exe from the Kermit Beta v0.4.0004: http://www.megaupload.com/?d=BIX9J7I4, Password is "ASSEMblergames.com" as well
• Dump of ROM0 of a retail PS2 BIOS
• Development PC connected to your TOOL that has DSEDB and the full Sony PS2 SDK v3.0 installed.
• Source code of the uplaunch utility (expect a PM soon ;-))
• Hex editor of your choice

Creating/extracting the BIOS:
On a Windows system having the .NET 2.0 SP1 runtime installed, put romfs.exe and your retail BIOS dump (named "rom0") into a folder, then execute the following commands:

• romfs mk-ioprp rom0 IOPRP.IMG
• romfs x rom0 . -f "^SIO2MAN$" "^PADMAN$" "^MCMAN$" "^MCSERV$"

This will create a file named IOPRP.IMG that'll function as your IOP BIOS later on, as well as extract the 4 mentioned files from rom0. Copy IOPRP.IMG, SIO2MAN, PADMAN, MCMAN and MCSERV into your home directory on the Linux development PC/VM.

Preparing the launcher
On the development PC, extract the uplaunch package into a new folder and run MAKE. If your SDK is set up correctly, you'll get an uplaunch.elf.
Then, use your favourite hex editor to perform the pattern replacement mentioned in the comment in uplaunch.c (turns off version checking for the LOADFILE client library). Without this patch, uplaunch.elf won't be able to do anything useful. Place the modified uplaunch.elf into your home directory.

Launching uLE
Navigate to your home directory and start DSEDB (you may want to have DSIDB running in a separate terminal, but you don't need to). In DSEDB, enter the following commands:

• reset f0000 100
• run uplaunch.elf host0:ULE439-TOOL.ELF

If everything goes well, you should see some messages from uplaunch first, then uLE should be running.

Good luck!

When ever I get enough grasp on Programing for the EE and start literly homebrewing, Would not I be able to account for the Tools libraries vs retail. sence my end(ish) goal does not include running my homebrew on retail systems.

Sorry, but I don't think I understood your question. Both retails as well as TOOLs can run code compiled with both SDKs (homebrew as well as official), but each has it upsides and downsides.

Homebrew libraries can work on a system running a default IOP kernel (e.g., a retail or TEST, or a TOOL after a retail kernel has been started via uplaunch), whereas libraries from the official SDK require the correct kernel delivered with that SDK. That is, you need to either run them on a TOOL having the correct version installed in flash, or issue an IOP reset specifying the SDK's IOPRPxxx first. As there is no legal way for a non-licensee to distribute that file (or, for that matter, even an ELF compiled with the official SDK), you won't also be able to share your work with others. And in case you run into problems, you might also have a hard time finding anyone who'd be willing and able to help; the people responsible for the open-source/homebrew SDK generally don't answer questions related to the official one.

I have not see anywhere, something saying this. "the PS2 TOOL has 128MB RAM accessible to the EE"
BUT when using the debugger it says 128MB, AND there is a flag for limiting to 32MB.
So question.. Can I develop homebrew that would use more than 32MB ram, if ran on the tool only.

The TOOL has four times the memory a retail unit has, for both EE and IOP programs. That is, the EE has 128MB and the IOP has 8MB. You can restrict memory by specifying appropriate flags for the RESET command, but by default, all memory (minus some KB needed by the kernel) is available to the application.

[ThePinkBunny]

**names first child SilverBull** lol j/k
but really thanx. Iv downloaded everything and I'll get back to you after sleep.
Iv had problems in the past compiling elf's but ill tell you if any arise.

[ThePinkBunny]

Ok i was right my ee-gcc never seems to want to work.

ee-gcc -c -xassembler-with-cpp -Wa,-al -o crt0.o /usr/local/sce/ee/lib/crt0.s > crt0.lst
as: unrecognized option '-mdebug'

[SilverBull]

Ok i was right my ee-gcc never seems to want to work.

ee-gcc -c -xassembler-with-cpp -Wa,-al -o crt0.o /usr/local/sce/ee/lib/crt0.s > crt0.lst
as: unrecognized option '-mdebug'

That's strange. Which compiler(s) and assembler(s) are installed on that PC? The Sony-supplied ones should not generate that error, so I assume something got mixed up.

Did you by any chance install the open source SDK under the same user account than the official one? If so, you need to separate the two; I suggest to create a new user account, then make sure the PATH environment variables of both users only refer to those directories they are supposed to.

Can you please post the output of the following commands?

• set|grep PATH
• which ee-gcc
• which ee-ld
• which ee-as

[ThePinkBunny]

PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/Bunny/bin:/usr/local/sce/ee/gcc/bin:/usr/local/sce/iop/gcc/bin:/usr/local/sce/bin

/usr/local/sce/ee/gcc/bin/ee-gcc
/usr/local/sce/ee/gcc/bin/ee-ld
/usr/local/sce/ee/gcc/bin/ee-as

[SilverBull]

/usr/local/sce/ee/gcc/bin/ee-gcc
/usr/local/sce/ee/gcc/bin/ee-ld
/usr/local/sce/ee/gcc/bin/ee-as

These look fine.

PATH=/usr/lib/qt-3.3/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/lib/ccache:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/Bunny/bin:/usr/local/sce/ee/gcc/bin:/usr/local/sce/iop/gcc/bin:/usr/local/sce/bin

I see some differences from my machine, but nothing I'd consider important. Here's my path:

PATH=/usr/local/bin:/bin:/usr/bin:/home/tooldev/bin:/usr/local/sce/bin:/usr/local/sce/ee/gcc/bin:/usr/local/sce/iop/bin

I have neither kerberos nor qt installed nor do I have sbin in the path; however, that shouldn't cause your problems. I think your ee-gcc invokes the wrong as(sembler), but unfortunately I don't know enough about the inner workings of gcc to diagnose this correctly; I can only guess... :shrug:

Can you please verify that the directory /usr/local/sce/ee/gcc/ee/bin includes the following files: ar, as, ld, nm, ranlib, strip. Each of them should be either a soft or hard link to the similarly-named files, but having the ee- prefix, in /usr/local/sce/ee/gcc/bin. For example, /usr/local/sce/ee/gcc/ee/bin/as should be the same file as /usr/local/sce/ee/gcc/bin/ee-as. You can use something like this to compare them:

cd /usr/local/sce/ee/gcc/ee/bin
for n in `ls`;do diff -s $n ../../bin/ee-$n; done

If they are identical, the "for" loop should output one line saying so for each of the six files. If there are any differences, I suggest you backup the .../ee/gcc/ee/bin folder, then remove the files and create appropriate symbolic links by hand. I think I had to do so for my SDK installation, as they were not created automatically during installation.

In case this still does not help, please run the failing ee-gcc command manually with "-###" added directly after "ee-gcc", and paste its output. Here's mine:

$ ee-gcc -### -c -xassembler-with-cpp -Wa,-al -o crt0 /usr/local/sce/ee/lib/crt0.s > crt0.lst
Reading specs from /usr/local/sce/ee/gcc/lib/gcc-lib/ee/3.2-ee-030926/specs
Configured with: /proj/ee-toolchain/ee-gcc-3.2-final-rc2/release-src/ee-gcc/configure --prefix=/usr/local/sce/ee/gcc --target=ee --enable-c-cpplib --without-sim --disable-sim --enable-c-mbchar --enable-threads
Thread model: eekernel
gcc version 3.2-ee-030926
"/usr/local/sce/ee/gcc/lib/gcc-lib/ee/3.2-ee-030926/cpp0" "-lang-asm" "-D__GNUC__=3" "-D__GNUC_MINOR__=2" "-D__GNUC_PATCHLEVEL__=0" "-Dmips" "-DMIPSEL" "-DR5900" "-D_mips" "-D_MIPSEL" "-D_R5900" "-D__ee__" "-D__mips__" "-D__MIPSEL__" "-D__R5900__" "-D__mips__" "-D_MIPSEL" "-D_R5900" "-D__ee__" "-D__mips" "-D__MIPSEL" "-D__R5900" "-D__mips" "-D__NO_INLINE__" "-D__STDC_HOSTED__=1" "-D__LANGUAGE_ASSEMBLY" "-D_LANGUAGE_ASSEMBLY" "-DLANGUAGE_ASSEMBLY" "-D__SIZE_TYPE__= unsigned int" "-D__PTRDIFF_TYPE__= int" "-D__mips_fpr=32" "-D__LONG_MAX__=9223372036854775807L" "-U__mips" "-D__mips=3" "-D__mips64" "-D__mips_eabi" "-D__mips_single_float" "/usr/local/sce/ee/lib/crt0.s" "-o" "/tmp/cclOcCWW.s"
"/usr/local/sce/ee/gcc/lib/gcc-lib/ee/3.2-ee-030926/../../../../ee/bin/as" "-mdebug" "-al" "-o" "crt0" "/tmp/cclOcCWW.s"

Please note that it invokes /usr/local/sce/ee/gcc/ee/bin/as in the last line, but this is ee-as, not the system-provided as. I think that on your machine, this call invokes either the system-provided as or a completely different one.

If all else fails, could you try to reinstall the SDK from scratch?

[ThePinkBunny]

cd /usr/local/sce/ee/gcc/ee/bin
for n in `ls`;do diff -s $n ../../bin/ee-$n; done

I must have had a similar problem, be cause they were all not linked. after creating the symbolic links, the uplaunch compiled, yay :D.

ok continuing on, will report back

[ThePinkBunny]

:Rock:It Works:Rock:
loaded uLE, did complain about missing .cnf's, but it works!

Thank you :pray:

EDIT: If i try to run other elf's i get.

kupdate: pannic ! file 'rom0:EELOADCNF' can't open

[SilverBull]

:Rock:It Works:Rock:
loaded uLE, did complain about missing .cnf's, but it works!

Thank you :pray:

:clap: You're welcome.

EDIT: If i try to run other elf's i get.

kupdate: pannic ! file 'rom0:EELOADCNF' can't open

The TOOL does not contain an EELOADCNF kernel, so this message is (somewhat) expected :033:.

To fix this, patch the string "rom0:EELOADCNF" in the ELF to something like "host0:EELOADCNF" (make sure to terminate it with a NULL byte and don't overwrite any data that follows!). You can use romfs to construct the file:

romfs mk-tool-eeloadcnf retail.rom0 EELOADCNF t10k.rom0

retail.rom0 should be the exact same rom0 image you used to create IOPRP.IMG. t10k.rom0 should be the flashrom image that is installed on your TOOL (e.g., t10000-rel300.bin for SDK 3.00). Please note that this command writes a new EELOADCNF, so don't run it if the current directory already includes the file (or put the output file into a different directory).

If your homebrewn ELF loads other files from rom0, you can simply extract the files from the retail BIOS, place them in your home directory, then patch the filenames in the ELF to refer to host0:<FILE>. For example, if a homebrewn ELF uses gsKit's built-in text output routines, you need to do so for rom0:FONTM, as it is also not present on TOOL ROMs.

[ThePinkBunny]

I was able to extract the EELOADCNF, and I did have an ELF that needed FONTM and extracted that to. But when you say change the rom0 string to host0, were/how would this be done. I assumed hex edit, but no rom0 was found, only EELOADCNF same for FONTM.

also, is there a way to put EELOADCNF and FONTM in the rom0 of the tool. (I would assume patching the tool.rom0 and re-flashing.)

The ELF that needed the FONTM was kloader2.3

[SilverBull]

I was able to extract the EELOADCNF, and I did have an ELF that needed FONTM and extracted that to. But when you say change the rom0 string to host0, were/how would this be done. I assumed hex edit, but no rom0 was found, only EELOADCNF same for FONTM.

Depends on the ELF and how it constructs the path to the file. This is hardcoded most of the time, so the strings should be visible in the hex editor; if you have the source code, you can also search for calls to routines like SifLoadModule and SifResetIop (there are variations of the name, like SifIopReset, SifIopReboot and so on) to see where they get their arguments from.

If the ELF is packed, you most likely won't find any readable strings. In this case, try running it through ps2-unpacker first; the unpacked ELF should contain them in readable format.

By the way: did you "extract" EELOADCNF from the retail rom0 just as you extracted FONTM ("romfs x"), or did you use romfs to mix a retail and TOOL rom0 to create the file? Sorry for nitpicking, but it is important that you use mk-tool-eeloadcnf here; using a retail EELOADCNF will at least turn off debugger support, if the IOP survives the reboot at all. :gravedigging:

also, is there a way to put EELOADCNF and FONTM in the rom0 of the tool. (I would assume patching the tool.rom0 and re-flashing.)

This should be possible, as the format of the PS2 ROM file system has been reversed completely. I once thought about doing something similar (maybe even getting PS1 games working via a similar method), but I didn't pull it off.
The main reason is that reflashing the ROM requires a working DECI2 connection to the target, so the image needs to be correct at least to the point where the IOP is up and responding to debugger commands. There is almost no room for mistakes here; a single error in the image can render the entire PS2-side inoperable. If this happens, you would need to use WS mode to start the alternate BIOS, then flash the "other" (shadow) side of the chip. The procedure is outlined in the SDK ("Restoring the Flash ROM" in setup_*.pdf), but to be honest, I really wouldn't want to try it.

The ELF that needed the FONTM was kloader2.3

That's for executing Linux, right? Sorry, but I have never tried the program, not even on a retail machine.

[ThePinkBunny]

I used the mk-eeloadcnf for the EELOADCNF but, extract for the FONTM

[dtl-t10k]

Does anyone here have the source to the uplaunch utility they can PM me? Thanks alot!

[SilverBull]

Does anyone here have the source to the uplaunch utility they can PM me? Thanks alot!

Here you go: http://www.megaupload.com/?d=4ZWIWK2M
Password is "ASSEMblergames.com"

The archive contains the ELF with source, as well as the ROMFS utility from the Kermit distribution archive from May 2010. I finally reversed the DECI2 libraries for the EE-side console, thus allowing uplaunch to be compiled with the open-source PS2SDK (without any loss of functionality, even if its just debug output). The included ELF does not contain any Sony libraries, so I see no reason to further restrict distribution. Mentioning the sceTty* functions does not count, I have re-implemented them and just happen to like the official names... :lol:

The source is included for reference purposes only; the archive does not include the reversed DECI2 and console libraries, so you won't be able to compile the program yourself. I'm not planning to release these libraries any time soon.

Changes from the previous ("hack") version are minor: migrated to the open-source PS2SDK, re-implemented EEDECI2 libraries, changed some debug strings, and moved the code to the loader range (0x84000) instead of 0x100000 where applications might reside. So unless you are experiencing problems with the old version, there is no need to upgrade.

Have fun, and good luck :-).

[dtl-t10k]

You are a good man. Thanks so much. :)