Refusing to start on Raspbian Buster / RetroPie 4.6.1

[john-parton]

I have a Pi Zero W, with RetroPie 4.6.1 on Raspbian Buster.

I have the BIOS setup correctly, and have tried multiple games. Everything worked fine in RetroPie 4.5 on Raspbian Stretch. (There were slowdowns and other issues, but it at least started.) I'm sure there's some debug output somewhere, but it just crashes and bumps me back to EmulationStation.

I tried uninstalling the core and reinstalling it. I also tried uninstalling the core and building from source.

I couldn't find any relevant issues here or on notaz/gpsp.

Let me know if you need anything from me.

I'm not sure this is a dupe? https://github.com/libretro/gpsp/issues/70

[TechieAndroid]

I closed my issue since I hadn't had a chance to add as many details as you have about the problem.

As mentioned here -> https://retropie.org.uk/forum/topic/25111/lr-gpsp-giving-illegal-instruction-on-raspberry-pi-models-0w-3b-and-4/19

From what I've tested, it's not the emulator version that's the problem, but the compiler used to produce the binary - the one distributed with Raspbian Buster.

However I still had problems compiling a binary for my Pi 0 W on Arch Linux, perhaps my compiler flags were incorrect though. Here's what I was using make TARGET=PI1 I based that off the little information provided by the readme on this repo and the makefile itself. However, when I replaced the core I compiled with the one on my Pi it still didn't work.

This is from the makefile:

# Raspberry Pi 1 else ifeq ($(platform), rpi1) TARGET := $(TARGET_NAME)_libretro.so fpic := -fPIC SHARED := -shared -Wl,--version-script=link.T -Wl,--no-undefined CFLAGS += -DARM11 -DARM_ARCH CFLAGS += -marm -mfpu=vfp -mfloat-abi=hard -march=armv6j CFLAGS += -fomit-frame-pointer -ffast-math CFLAGS += -DARM_MEMORY_DYNAREC CXXFLAGS = $(CFLAGS) -fno-rtti -fno-exceptions -std=gnu++11 CPU_ARCH := arm HAVE_DYNAREC = 1

It would seem this is configured correctly since it has -march=armv6j which matches, and CPU_ARCH := arm which would be 32-bit because if I'm not mistaken, only arm64 is 64-bit.

The error the core's been giving me is "illegal instruction" which makes me think it's not compiling for the right architecture. The Pi 0 W has a ARMv6 32-bit instruction set, which is the same as the Pi 1 which is why I choose the make TARGET=PI1 command.

I hope this extra information can help us narrow down where the problem lies.

[john-parton]

Here are the flags from the libretro port of genesis-plus-gx. (Which I believe works correctly.)

PLATFORM_DEFINES += -DARM11 -marm -march=armv6j -mfpu=vfp -mfloat-abi=hard

https://github.com/libretro/Genesis-Plus-GX/blob/50551066f71f8a5ea782ea3747891fd6d24ebe67/Makefile.libretro#L91

Looks the same to my eyes.

It's my understanding that the RPi Zero and RPi 1 use the same instruction set.

[john-parton]

What should the value of the $(platform) variable be on the raspberry pi?

On my machine, it's "unix", I think. So the conditional for the raspberry pi specific compile args isn't true.

EDIT

Yeah, I just cloned down master and added

$(error PLATFORM is $(platform)) to line 74 (before all the conditionals for platform specific flags.)

Makefile:74: *** PLATFORM is unix. Stop.

EDIT 2

When you run make on master, the first thing it spits out is:

cc -I. -DGIT_VERSION=\"" 514cb1e"\"  -DHAVE_STRINGS_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBRETRO__ -DINLINE=inline -Wall   -DNDEBUG=1 -fPIC -Werror=implicit-function-declaration -DFRONTEND_SUPPORTS_RGB565 -O3 -DNDEBUG -c  -o main.o main.c

I copied the flags from raspberry pi block, and overwrite the unix block, and did a make clean/make and the first thing it outputs is:

cc -I. -DGIT_VERSION=\"" 514cb1e"\" -DARM11 -DARM_ARCH -marm -mfpu=vfp -mfloat-abi=hard -march=armv6j -fomit-frame-pointer -ffast-math -DARM_MEMORY_DYNAREC -DHAVE_STRINGS_H -DHAVE_STDINT_H -DHAVE_INTTYPES_H -D__LIBRETRO__ -DINLINE=inline -Wall -DHAVE_DYNAREC -DARM_ARCH   -DNDEBUG=1 -fPIC -Werror=implicit-function-declaration -DFRONTEND_SUPPORTS_RGB565 -O3 -DNDEBUG -c  -o main.o main.c

Which definitely looks more correct.

[juchong]

Hi folks, it looks like pulling the gpsp_libretro.so module from a RetroPie 4.5 image temporarily worked around the issue. Here's the the file for anyone that doesn't want to hunt for it: gpsp_libretro_4p5.zip

[john-parton]

@juchong That's not really a fix, though, right?

master is still not compiling properly.

[juchong]

@john-parton Correct. The file I posted will merely work around the issue. I've ammended my post to reflect that.

[dawenl]

Ran into the same issue. Some google search led me here. The 4.5 image helped, thanks! @juchong

Unfortunately, one important fix in #59 which solved the save type problem is apparently not in 4.5. So no golden sun :(

[lhimo]

Does it work on a Pi0W as well? I can't get it to launch.

[metchebe]

I also get the "illegal instruction" error on my Raspberry Pi 3 (using platform=rpi3) when building with Raspbian's default gcc (8.3.0). Thanks to the tip mentioned previously, I did manage to build a working core with gcc-6 (6.5.0) available in Raspbian Buster using export CC=/usr/bin/gcc-6 before compiling.

[Cr33dC0d3r]

So i stumbled across this issue - since im fairly new to all this, the following might be a dumb question but: How to install / replace the gpsp_libretro.so module from a RetroPie 4.5?

Is this a simple file replace somewhere in the deeps of retropie folderstructure, or do i have do execute some commands in the retropie console (via ssh) ?

Hope someone can help me with this, even though it's just a workaround. Thanks :)

[TechieAndroid]

So i stumbled across this issue - since im fairly new to all this, the following might be a dumb question but: How to install / replace the gpsp_libretro.so module from a RetroPie 4.5?

Is this a simple file replace somewhere in the deeps of retropie folderstructure, or do i have do execute some commands in the retropie console (via ssh) ?

Hope someone can help me with this, even though it's just a workaround. Thanks :)

It's in /opt/retropie/libretrocores/lr-gpsp

What I personally did was scp gpsp_libretro.so pi@192.168.x.x:/home/pi/ then ssh pi@192.168.x.x sudo cp ~/libretro_gpsp.so /opt/retropie/libretrocores/lr-gpsp/

[john-parton]

Just a quick update.

This appears to be an issue with Lakka as well, so it's definitely not isolated to RetroPie.

Related issue: https://github.com/libretro/Lakka-LibreELEC/issues/884

[john-parton]

It appears Lakka fixed this issue with the following commit:

https://github.com/libretro/Lakka-LibreELEC/commit/62ba4499c0b1e2d6fb0ad98aa8a54f78a87605c1

[metchebe]

@john-parton Does the Lakka fix have the dynamic recompiler enabled?

As I mentioned before using platform=rpi3 (which implies HAVE_DYNAREC = 1) works for me, but using gcc-6.

[john-parton]

@metchebe I don't think dynarec is enabled.

I was just making sure to forward on the relevant changes.

EDIT

Obviously it would be nice if it built on newer versions of GCC, but it's good know I can probably get it to build on 6.

[fearedbliss]

This also is affecting me on my GPI Case (RPI0W). When I installed the standalone gpsp from the retropie_setup.sh, that one works perfectly fine. I also checked the versions of the one pulled in from the repos with the script and the one that comes with the image I'm running the latest retropie-buster-4.6-rpi1_zero.img.gz image on the website with the hash 98b4205ad0248d378c6776e20c54e487, and both gpsp's are at the same version: 0.91.

EDIT: I can also confirm that the 4.5 gpsp works (I know there is one above but I downloaded/flashed/extract the one from the 4.5.1 image to confirm from a clean install/extraction).

[davidgfnet]

There have been a ton of fixes in gpsp and even new features in the last 3 months. Can you guys please confirm this is still an issue? You can use a Lakka nightly, since it should contain a fairly recent version of gpsp with said fixes/features. There were some big issues in the arm dynarec due to some well hidden bugs, but perhaps that fixed it :) Let me know and I will jump on it since I have an RPi0. Incidentally I've been using it to benchmark the dynarec and seemed to be working ok with all ROMs I tested it.

[metchebe]

@davidgfnet I build locally on Raspberry Pi OS on a Pi3 and have not had issues for a while now (since the arm dynarec fix, in fact). The last time I updated gpsp was fd20793.

I use RPi OS 64 bit (beta) now and have been unable to build it for aarch64 so I have not tried the latest commits (any tips appreciated).

[davidgfnet]

aarch64 does not have dynarec, should build normally like x64 (portable C code).

[metchebe]

@davidgfnet Yes, indeed. It turns out I was running out of memory building the aarch64 version. Building with -O2 instead of -O3 works.

[cmitu]

Can you guys please confirm this is still an issue? You can use a Lakka nightly, since it should contain a fairly recent version of gpsp with said fixes/features.

I've tested this recently and it looks fixed. FWIW, RetroPie implemented a workaround at the time by using an older GCC version, in order to allow Pi 0/1 installs to continue using gpsp (standalone and libretro core).

[john-parton]

This appears fixed as far as I can tell.