ELF Loader seems to be broken if SetMemoryMode is called by the same program

[israpps]

As some of you already know, i've been developing a basic bootloader for PSX and PS2

the PSX builds can't run ELF Files if the SetMemoryMode function is used to set the TLB to limit RAM to 32mb (PSX has 64mb)

this only happens if the executable is installed as a system update. when running this program via wLaunchELF or FreeMcBoot for PSX the issue is magically gone. maybe this function breaks something on newer toolchains.

I don't think it's my program's fault (everyone can be wrong lol)

I will appreciate any feedback...

and of course, I will tag those that might/will be interested on this

@sp193 @uyjulian @fjtrujy

[israpps]

aditional note: i've already tested ELF Loader with debug colors. seems like ELF Loader crashes before it can display one.

[fjtrujy]

You can put other colors here, just to assure that the code is being executed https://github.com/ps2dev/ps2sdk/blob/master/ee/elf-loader/src/elf.c#L53-L101 The loader as soon as it starts it shows the white color, so it means that loader probably is not even executed, that could happen if the memory is overridden....

Not sure if you are putting something else in that memory region https://github.com/ps2dev/ps2sdk/blob/master/ee/elf-loader/src/loader/linkfile#L5

I don't have PSX, so I can't help you debugging that.

Cheers.

[israpps]

You can put other colors here, just to assure that the code is being executed https://github.com/ps2dev/ps2sdk/blob/master/ee/elf-loader/src/elf.c#L53-L101 The loader as soon as it starts it shows the white color, so it means that loader probably is not even executed, that could happen if the memory is overridden....

Not sure if you are putting something else in that memory region https://github.com/ps2dev/ps2sdk/blob/master/ee/elf-loader/src/loader/linkfile#L5

I don't have PSX, so I can't help you debugging that.

Cheers.

I will try to replicate this on ps2dev:v1.0 on a few days... as FreeMcBoot 1.966 was release around that time too and it works well...

[israpps]

Not sure if you are putting something else in that memory region https://github.com/ps2dev/ps2sdk/blob/master/ee/elf-loader/src/loader/linkfile#L5

How can I check that? Is it still necesary to check it if just by commenting the mentioned function makes it work?

[fjtrujy]

Not sure if you are putting something else in that memory region https://github.com/ps2dev/ps2sdk/blob/master/ee/elf-loader/src/loader/linkfile#L5

How can I check that? Is it still necesary to check it if just by commenting the mentioned function makes it work?

No idea about that specific function… wait for the others to reply.

The best you can do for now, is to put others debug colors where I said….

[sp193]

Where is your stack located? If you use this syscall and then call ExecPS2()/LoadExecPS2() to go from 64MB to 32MB mode, you will get a crash if your stack is located at the end of memory because TLB gets remapped. This may happen if you left the stack undefined (defaults to the end of memory). It is dumb, but the kernel does not relocate the stack before remapping TLB. I believe I figured this out by getting the exception printed with PS2Link.

Sony documented that you can leave the stack undefined (-1) like that for development (which is supposed to also reserve some additional space for development), or you could define the size and position of both the heap and stack explicitly. If I remember right, the heap ends with the bottom of the stack with our crt0, so you need to plan your memory layout.

For FMCB, I recall that I once set the stack of the main body to the end of 32MB to solve this. I believe I eventually followed the Sony ELF loader design for this part, which is to put the stack at the end of the program, which means no heap. But this makes sense because you can keep everything belonging to the ELF loader below the officially-documented start of user memory (0x00010000), in order to safely execute a wipe of everything above this address.

[israpps]

Where is your stack located? If you use this syscall and then call ExecPS2()/LoadExecPS2() to go from 64MB to 32MB mode, you will get a crash if your stack is located at the end of memory because TLB gets remapped. This may happen if you left the stack undefined (defaults to the end of memory). It is dumb, but the kernel does not relocate the stack before remapping TLB. I believe I figured this out by getting the exception printed with PS2Link.

Sony documented that you can leave the stack undefined (-1) like that for development (which is supposed to also reserve some additional space for development), or you could define the size and position of both the heap and stack explicitly. If I remember right, the heap ends with the bottom of the stack with our crt0, so you need to plan your memory layout.

For FMCB, I recall that I once set the stack of the main body to the end of 32MB to solve this. I believe I eventually followed the Sony ELF loader design for this part, which is to put the stack at the end of the program, which means no heap. But this makes sense because you can keep everything belonging to the ELF loader below the officially-documented start of user memory (0x00010000), in order to safely execute a wipe of everything above this address.

Interesting 🤔

May I ask you if you could answer an email I sent you some time ago?

[sp193]

I hope you already got all the answers you needed, regarding this topic. For the understanding for other people on the Internet, would you mind copying your questions here if you still have further questions?

[israpps]

I hope you already got all the answers you needed, regarding this topic. For the understanding for other people on the Internet, would you mind copying your questions here if you still have further questions?

Without setting the memory to 32mb everything works like a charm

The only remaining question is:

What are the dangers/drawbacks/issues of not leaving it capped at 32?

[sp193]

It's just not going to be exactly as a retail PS2. Normally, there is no problem, but you might introduce incompatibilities in software with design issues/bugs, just by changing the environment.

Since Sony did it that way, I would do it that way too. They were the system designer and had some design considerations we might not know of. I wouldn't want to deal with the possibility of incompatibilities nor invest effort in debugging those.

Anyway, it's not like official software would normally try to gain more memory and to use it. By documentation, the memory layout was supposed to be fixed, once development is completed; the stack's address and size, and end of heap would be specified. But in the case of Homebrew software, we tend to just specify -1 for the stack location... which is normally what Sony recommends for development. With this, the stack is placed against the end of memory and the heap is placed against the end of the stack. And some additional space is reserved for debugging... or so the documentation goes.

[sp193]

If you asked me, it might benefit homebrew software and usage (e.g. if we want to do development), but not games. The extra 32MB was probably added to serve the DVR's software.

The OSD of the PSX (on the HDD) switches to 32MB mode, when switching the PSX to "Game Mode". So you could consider it as a feature for ensuring compatibility with PS2 game titles. This "Game Mode" also involves switches the CD/DVD drive to operate in the PS2 mode, which involves the PS2's 400C laser.