EE exception occurs no matter what executable I use

[ijacquez]

I had v1.2 pre-built and it worked fine. I decided to build ps2link myself, and for every executable I try to upload, I get CPU exceptions (seems to vary from executable to executable).

The "cause" is 70008010.

1. I run PS2LINK.ELF from mc1
2. I've tried executables that worked with v1.2
3. I've built vanilla (no Makefile options changed)
4. I've built with the following:

diff --git a/Makefile b/Makefile
index 4be0a4e..b22bd93 100644
--- a/Makefile
+++ b/Makefile
@@ -1,23 +1,23 @@
 # Compilation variables

 # Set this to 1 to enable debug mode
-DEBUG = 0
+DEBUG = 1

 # Set this to 1 to build a highloading version, 0 for normal low version
 LOADHIGH = 0

 # Set this to 1 to build ps2link with all the needed IRX builtins
-BUILTIN_IRXS = 1
+BUILTIN_IRXS = 0

 # Set this to 1 to enable caching of config files
-CACHED_CFG = 1
+CACHED_CFG = 0

 # Set this to 1 to enable zero-copy on fileio writes.
 ZEROCOPY = 0

 # Set this to 1 to power off the ps2 when the reset button is tapped
 # otherwise it will try and reset ps2link
-PWOFFONRESET = 1
+PWOFFONRESET = 0

 # Set this to 1 to hook the kernel CreateThread/DeleteThread calls.
 # Note that this will cause problems when loading PS2LINK.ELF from PS2LINK...

Any suggestions? Anything I could try?

[ijacquez]

Setting LOADHIGH seems to have fixed the issue. Is there a reason why this needs to be set?

[sp193]

How are you booting ps2link? ps2link likely cannot boot another version of ps2link because that will overwrite ps2link before the loading can complete.

[ijacquez]

I'm booting it via uLaunchELF. I also have it set to autostart via FMCB.

Is that why other executables weren't working? I didn't see any option to set the start address.

[sp193]

I am a little unsure of what you did.

Were you able to boot the copy of ps2link that you compiled, and hence the executables that failed, were software that you attempted to boot from ps2link? Or was it ps2link itself that would not boot up properly?

If it is the former, then can you specify what software you tried to boot from ps2link?

[ijacquez]

Yes, I was able to boot the compiled ps2link.elf. The problem lies in the software I was trying to boot.

[sp193]

Can you try to edit ee/Rules.make to use -lkernel-nopatch instead of -lkernel?

I thought I already reworked ps2link to not execute its applications this way, but it still seems to boot things by starting threads. This could cause problems with the kernel patches we now have.

[ijacquez]

This requires rebuilding PS2SDK? I'll give it a shot.

Edit: To be clear, this is with LOADHIGH = 0?

[sp193]

I mean, edit the ee/Rules.make file of ps2link. Sorry for the confusion.

I think the LOADHIGH option should not matter. If the kernel patches were indeed related, then perhaps the LOADHIGH option was just causing the problem to be avoided.

[ijacquez]

I'll try what you suggested with LOADHIGH = 0 since it works when set to 1.

[ijacquez]

I get the same error with this being the only change.

diff --git a/ee/Rules.make b/ee/Rules.make
index 37d3dc9..df46af0 100644
--- a/ee/Rules.make
+++ b/ee/Rules.make
@@ -17,7 +17,7 @@ EE_ASFLAGS := -G0 $(EE_ASFLAGS)
 # Link with following libraries.  This is a special case, and instead of
 # allowing the user to override the library order, we always make sure
 # libkernel is the last library to be linked.
-EE_LIBS += -lc -lkernel
+EE_LIBS += -lc -lkernel-nopatch

Edit: Here is what I see.

Edit: I only ran one executable then exited. And here, I ran directly from my USB stick.

[sp193]

I see, thanks for the screenshot.

I think there is a problem with the addresses that were selected for the normal version. By setting _stack to 0x00100000 and _stack_size to 0x8000, the stack's top is at 0x00108000, which either allows ps2link to get partially overwritten once that ELF get loaded or it will corrupt the loaded ELF...

You can try changing ps2link/ee/Makefile as shown (on top of getting it to use -lkernel-nopatch), to correct this problem:

# Normal low loading version
...
STACKADDR = 0xf8000

[ijacquez]

Glad that helped. I can't test until next week, but is this a regression, excluding the kernel patches?

I can verify next week. If all is well, would this be merged in?

[sp193]

If it is an actual problem, it'll be a 15-year old bug.

Please test it when you can. Then it'll be merged in.

[sp193]

Related commit: b99f07a

[ijacquez]

Thanks, I'll test this out. I will be able to test in 1-2 days.

[ijacquez]

All is well! Thanks for fixing this.