Whats the difference between performance.elf and compatibility.elf?

[notimp]

I just rewrote your port a little so it works on the RG40XXV in Anbernics Stock OS (see: https://old.reddit.com/r/rg40xx/comments/1g77jvq/how_to_make_ship_of_harkinian_12_work_on_the/ ) and was wondering how the compatibility.elf is different from the performance.elf I'm currently using. Could you give me any pointers?

Also - any new information on the Jabu Belly, second door crash, that apparently occurs, if you use an otr file generated on Windows? On Anbernics Stock OS the otr generation doesnt work, so any additional information would be helpful. (Would a linux generated otr file work, or does it have to be specifically generated on one of those rockchip/H700 devices?)

[JeodC]

I just rewrote your port a little so it works on the RG40XXV in Anbernics Stock OS (see: https://old.reddit.com/r/rg40xx/comments/1g77jvq/how_to_make_ship_of_harkinian_12_work_on_the/ ) and was wondering how the compatibility.elf is different from the performance.elf I'm currently using. Could you give me any pointers?

Also - any new information on the Jabu Belly, second door crash, that apparently occurs, if you use an otr file generated on Windows? On Anbernics Stock OS the otr generation doesnt work, so any additional information would be helpful. (Would a linux generated otr file work, or does it have to be specifically generated on one of those rockchip/H700 devices?)

Hi there! The file compatibility.elf is just soh built in debian bullseye chroot, and performance.elf is soh built in debian bookworm chroot. The difference is GLIBC support. ArkOS cfw and TrimUI require compatibility.elf to run since they use a lower GLIBC version, and as a consequence their soh experience is quite slow compared to performance.elf.

The Jabu Jabu's Belly crash was an issue of using a 8.0.5 Windows-generated otr file with a bleeding-edge version of soh. It should be fixed now since the current soh version is the release 8.0.6 tag, but HarborMasters recommended I always generate the otr file on-device to ensure port integrity.

If you upload some logs I might be able to tell you why it can't generate on stock, but no guarantees. This port relies on using the PortMaster Patcher GUI to process output while the otr gets generated.

Out of curiosity, what additional libs did you need?

[notimp]

Thank you, I thought so (version differences more likely than os build differences).

That the build on stock device fails might be realated to no /utils/patcher.txt being in any of the locations the script looks in - or not. :)

Thank you also for the information, that there is no downside to using performance.elf

The additional libraries I added were:

libatomic.so.1
libopenal.so.1 (that one is usually required)
libssl.so.1.1

Also as a word of warning, I didnt test your port without those libs, as everything worked after the first set of changes I usually do to a script to make it run under Stock OS, so the edits to the .sh file and adding those libraries to a games lib folder (creating it prior if it doesnt exist)

in addition to also adding

libcrypto.so.1.1
libzip.so.4

Is the first thing I try to get any game running, so far I had success on eight of them, without having used any deduction, why. ;) It could just as well be that the stock os is just missing the libopenal.so.1 library (which it is missing for sure), which I know from logs, that two of the games I got running (undertale, and AM2R required).

Thank you, and I'm closing this ticket now. :)

[notimp]

Closing the ticket now.

[JeodC]

Thank you, I thought so (version differences more likely than os build differences).

That the build on stock device fails might be realated to no /utils/patcher.txt being in any of the locations the script looks in - or not. :)

Thank you also for the information, that there is no downside to using performance.elf

The additional libraries I added were:

libatomic.so.1
libopenal.so.1 (that one is usually required)
libssl.so.1.1

Also as a word of warning, I didnt test your port without those libs, as everything worked after the first set of changes I usually do to a script to make it run under Stock OS, so the edits to the .sh file and adding those libraries to a games lib folder (creating it prior if it doesnt exist)

in addition to also adding

libcrypto.so.1.1
libzip.so.4

Is the first thing I try to get any game running, so far I had success on eight of them, without having used any deduction, why. ;) It could just as well be that the stock os is just missing the libopenal.so.1 library (which it is missing for sure), which I know from logs, that two of the games I got running (undertale, and AM2R required).

Thank you, and I'm closing this ticket now. :)

So for the most part you add those libraries because you suspect they are needed for stockos? You would be better off comparing the libs stockos has to a cfw like muos, in that case. Any libs missing from a port's libs folder are common enough to be handled by the firmware. I think under no circumstances do you want to be telling users "just download these libs", especially if they're not necessary, and especially after the xz backdoor incident.

The /utils/patcher.txt is indeed a file and runtime provided by PortMaster. The patcher gui is made in love2d, which uses lua. Not every firmware has a virtual terminal to output information, so the patcher gui is a universal solution to the dilemma.

[notimp]

Additional info (Essentially, the .otr and maybe also .o2r files need to be created with your port on device, or else the game crashes in Jabus Belly, second door):

Checked this, and no good...

I've created my oot.otr using soh windows version 8.0.6, and just reached Jabus Belly and the game crashed on the second door.

Workaround. Find an sdcard, flash MuOS: https://dl.muos.dev/RELEASE/2410.1/

Put the soh and soh2 port files from github in the ports folder, put the rom files in the respective soh and soh2 folders, launch the two ports, and on the first launch viable .otr and .o2r files should be created.

Its verified by someone on discord, that that firmware works, but not by me. :) Need to get an sdcard first, then I'll test this.

Then I did this myself, this is my write down:

I just did this on the RG40XXV and have no crashes now. Flashed the firmware on a new sd. Booted with it. Set location and date/time, waited for MuOS to finish booting (boot process took 13 minutes, so beware). Logged into my wifi. Started Portmaster. Let it update to the most recent version. Downloaded soh and soh2 (just to see where the files would be placed). Shut down the device took out the sdcard, and renamed the soh and soh2 folders in ports to unusedsoh, and unusedsoh2, then copyied over both of those folders from the JeodC github packages. (Roms (GC versions) were already put in there by me previously.), then went to Roms/Ports and replaced the Ship of Harkinian.sh and the Ship of Harkinian 2.sh files in there with the .sh files sporting the same name from the JeodC github.

Put the sdcard back into the RG40XXV. Booted up and started both ports (one after the other). On first start, they both generated the game asset files (.otr and .o2r) and then booted into the game. I exited, shut down the device, and copied the roms over to my StockOS sdcard(s).

Switched the cards, booted back into stockos, started soh and the crash in jabus belly (second door) was gone.

[notimp]

So for the most part you add those libraries because you suspect they are needed for stockos? You would be better off comparing the libs stockos has to a cfw like muos, in that case. Any libs missing from a port's libs folder are common enough to be handled by the firmware. I think under no circumstances do you want to be telling users "just download these libs", especially if they're not necessary, and especially after the xz backdoor incident.

Yes, security was not my main concern.

I did check the libraries using virustotal.com (no positive, and no heuristic hit), but that was about it.

Those five libraries are the essential ones to get AM2R running, which was the first thing I did with ports on stockos. In my tutorials I mention, that the libraries from portmaster packages should be left in place, and not overwritten (even delete newer/older versions contained in the .zip package if a library with a different version number is already part of the game.) Libraries are kept on the fat32 partition of the sdcard (not sure if that matters).

So I did the basics, but I didnt vet them (reverse engineer them).

From download counts, sub 10 people have downloaded them so far (1 hit on every filehost is from myself), so -- its not a huge botnet yet.. ;)

[notimp]

Did some more due diligence.

libzip.so.4 in my package is the same as in the original portmaster .zip (sha256) of AM2R.

libssl.so.1.1 differs (sha256) but uses the same function names as the libssl.so in the original portmaster .zip

libcrypto.so.1.1 differs (sha256) and uses almost the same function names as the libcrypto.so.1.1 in the original portmaster .zip (only 3 differ, and they are functions that are imported, not exported.

libssl.so.1.1 references libatomic.so.1 as a shared library, which is probably why its also in the package. According to a quick online search, it is normal that libssl.so.1.1 links libatomic.so.1

libatomic.so.1 is only 30 KB in size.

libopenal.so.1 is the main library most ports complained in logs was missing.

While this doesnt mean anything on its own - if malicious, the malicious code would likely have been obfuscated. Or be inside libopenal.so.1 which, while 756KB in size, also does the heavy lifting of getting the graphics routines to work. :)

[JeodC]

Did some more due diligence.

libzip.so.4 in my package is the same as in the original portmaster .zip (sha256) of AM2R.

libssl.so.1.1 differs (sha256) but uses the same function names as the libssl.so in the original portmaster .zip

libcrypto.so.1.1 differs (sha256) and uses almost the same function names as the libcrypto.so.1.1 in the original portmaster .zip (only 3 differ, and they are functions that are imported, not exported.

libssl.so.1.1 references libatomic.so.1 as a shared library, which is probably why its also in the package. According to a quick online search, it is normal that libssl.so.1.1 links libatomic.so.1

libatomic.so.1 is only 30 KB in size.

libopenal.so.1 is the main library most ports complained in logs was missing.

While this doesnt mean anything on its own - if malicious, the malicious code would likely have been obfuscated. Or be inside libopenal.so.1 which, while 756KB in size, also does the heavy lifting of getting the graphics routines to work. :)

I wasn't questioning your libs per se, but the method in which you advertised them. There is a large difference in "download this libs.zip" and "you need these libs, here is a convenient download for them" which gives others the option to find their own rusted versions.

[notimp]

I'll rephrase it in the postings. Thanks.