Raspberry Pi 4 support

[joolswills]

We are working on RPI4 and Raspbian Buster support. There's no ETA but RetroPie 4.5 will be released first as a final Stretch based image (although we may support it for longer than Raspbian do - we are not sure what their future support for Stretch is).

Please comment here or on the forum before submitting RPI4 PRs as you may be repeating work others have already done.

Thanks!

[joolswills]

I don't want this thread to become a support thread. Please use the forum for that. It wont work out of the box on buster yet.

[psyke83]

I notice that emulationstation via fkms sometimes crashes during idle (possibly due to controller idle disconnect). I vaguely recall this occurring on stretch when you upgraded to 2.0.9, so it may be the same issue cropping up again.

The buster raspbian source (2.0.9+dfsg1-1+rpt1) includes several patches that aren't present via upstream:

debian/patches/0001-ARM-Create-configure-option-enable-arm-simd-to-gover.patch
debian/patches/0002-ARM-SIMD-assembly-optimization-for-function-BlitRGBt.patch
debian/patches/0003-ARM-SIMD-assembly-optimization-for-function-BlitARGB.patch
debian/patches/0004-SDL_blit-use-a-named-enum-for-required-hardware-feat.patch
debian/patches/0005-ARM-SIMD-assembly-optimization-for-BGR-to-RGB-32bpp-.patch
debian/patches/0006-ARM-assembly-optimization-for-SDL_FillRect.patch
debian/patches/0007-ARM-SIMD-optimization-for-4-4-4-4-to-8-8-8-8-normal-.patch
debian/patches/0008-ARM-Create-configure-option-enable-arm-neon-to-gover.patch
debian/patches/0009-ARM-NEON-assembly-optimization-for-function-BlitRGBt.patch
debian/patches/0010-ARM-NEON-assembly-optimization-for-function-BlitARGB.patch
debian/patches/0011-ARM-NEON-assembly-optimization-for-SDL_FillRect.patch
debian/patches/fix-cross-building-907711.patch
debian/patches/no-libdir.patch

Although they seem to be mostly optimizations, perhaps it might be worthwhile to test with these changes included. I can investigate if you want (although, the emulationstation crashes are sporadic and hard to reproduce, unfortunately).

[psyke83]

Buster & preliminary fkms support for mupen64plus: master...psyke83:mupen64plus_buster

Will send the gcc build fix upstream and remove from patch later.

Status of fkms rpi3 build (should apply to rpi4): auto/gliden64 plugin is currently non-functional (segmentation fault), gles2n64 driver doesn't set the correct fullscreen resolution, and rice seems to be working fine (fullscreen is correct, but it's not doing any dispmanx scaling, so performance may be lower).

[cmitu]

I notice that emulationstation via fkms sometimes crashes during idle (possibly due to controller idle disconnect). I vaguely recall this occurring on stretch when you upgraded to 2.0.9, so it may be the same issue cropping up again.

Probably #552. There's a patch, from @nadenislamarre, but I haven't tested it. I had a bisect that yield a good commit (after 2.0.9), I'll see if that's enough on top of 2.0.9 to stop the crashes.

[psyke83]

@cmitu - great, thanks! I haven't yet tested the patch, but it helped give a clue towards making a reproducible test case. On my PS3 controller, the crash reproduces every time if the controller disconnects whilst an analog stick is not at the resting position. I'll try recompiling SDL2 with the patch and see if it fixes the issue.

[cmitu]

I'm using testhotplug.c from the test folder distributed with sdl2 to test for this:

SDL_VIDEO_DRIVER=opengles SDL_EVENT_LOGGING=1 LD_LIBRARY_PATH=build/.libs/ ~/testhotplug

Note that I had to disable the motion sensors, because the test only supports 1 joystick. I usually just press the joystick(s) and then disconnect the gamepad (I'm using an USB cable to make it easier).

[ghost]

I've only been able to get retropie running under full kms with a minimal desktop (lightdm+openbox) gui setting the gl and x11 flags during compile as all other options cause emulationstation either not to start or blackscreen altogether during boot and cause the pi to become unresponsive. What does work runs pretty slow and the pi has a very bad overheating issue which happens for an unknown reason during operation.

[psyke83]

lr-mupen64plus PR sent, as it seems to work without major issues: #2751

Upstream will need a PR to enable neon/armv8 optimizations for RPI4, but I can't verify those changes without the hardware, so that part can wait.

[ghost]

@psyke83 I have the RPI4 hardware and I'm testing @joolswills system flags PR. I'll get back to you on this.

[joolswills]

The system flags are a minor part vs the fkms changes really (from @psyke83).

[ghost]

Seems like either the compiler flags or header locations need changing as retroarch can't locate EGL/egl.h and emulationstation throws an EGL Error : Could not create the egl surface from SDL while trying to run in fkms.

[cmitu]

@raidensnake you need RetroArch compiled with kmsdrm and GLES2/3 support and ES will need to be switched to support OpenGL to make it ignore the GLES1 path.

[ghost]

I did compile it but as I said ES won't run unless it's under a window manager in FKMS cause of the EGL error. Even when I do get ES running under lightdm+openbox retroarch just crashes with no output.
I'm using this commit for the rpi4 configuration. 1d8f7c9

[cmitu]

@raidensnake as @joolswills said, it's more than that than needs to be changed and an X.org/desktop env will not be needed.

[ghost]

It does for now just to get ES running. Also I recompiled retroarch and got this error on /dev/shm/runcommand.log failed to add service - already in use? I'd thought I'd just mention this as well.

Also to reiterate here. I'm not asking for support here. I'm just pointing out issues I've ran into that may be useful for everyone else to know.

[joolswills]

@raidensnake at this stage I don't believe this is useful. We are still working on stuff. We already have some things working - but we don't need any testing yet, and this thread will get cluttered if more people start saying they can't build X, Y Z,

[ghost]

Thanks to @popcornmix there's a forum thread that explains the current problems with the pi 4 that may prove useful. https://www.raspberrypi.org/forums/viewtopic.php?f=68&t=243611

[ghost]

From what I've determined is this. The pi 4 can't use dispmanx due to the way the vc6 graphics api operates in fkms. It can only run GLES via x or wayland. The kmsdrm that @psyke83 mentioned is possible to get working if we had a lightweight alternative however unless wayland or x is used to handle the window management. The current build is non-functioning. The only suggestion I can think of for the pi 4 in the short term is disable dispmanx and at least use x11 with the kmsdrm.

[psyke83]

@raidensnake,

I'm not sure what you mean by disabling dispmanx; the vc4-kms-v3d overlay uses a dispmanx context to expose the open graphics driver through KMS. The "fake" part of the driver is what allows us to keep using legacy dispmanx software that only needs software rendering, as well as tvservice, omx accelerated codecs via omxplayer, etc. Disabling the fkms driver (by enabling dtoverlay=vc4-kms-v3d) will break those features, and I'm fairly sure that I've seen it mentioned that this overlay configuration isn't even possible on RPI4.

Yes, dispmanx + GLES is no longer a working combination, and that's why we're reconfiguring mesa software builds as generic GLES2 + KMS targets. We're working on it, but very few of us are set up with a Pi 4 yet, not to mention that we also need to prioritize fixing general issues caused by the buster upgrade, as well as the breakage caused from the latest firmware packages breaking composite for the 4.5 release, etc.

People are working on the issue, but patience is needed. You can see some of my open PRs that are refining fkms support for some packages already, but even this is of limited use, because I can only test against RPI3, and inevitably there will be need for resolving issues related to the new processor revision, etc.

[ghost]

I'm pleased to report I've managed to get retropie working in the pi 4 with almost full fps however there were several things I had to mess with just to get it functional.

1. The pi 4 needs to use some form of desktop and window manager as I said before. I'd recommend using lightdm+openbox in auto login mode for the bare minimum without having to install a full blown desktop.

2. The compiler needs to have x11 and not use dispmanx in the configuration for it to function alongside the kms and mesa flags during detection. I'm recommending the following platform config for the pi 4:
   function platform_rpi4() { __default_cflags="-O2 -march=armv8-a+crc -mtune=cortex-a72 -mfpu=neon-fp-armv8 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -DGL_GLEXT_PROTOTYPES" __default_asflags="" __default_makeflags="-j2" __platform_flags="arm armv8 neon x11 kms gles" }

3. For the pi 4 also the code used to detect apd point the Broadcom GLES2 libraries also needs to be disabled for the pi for and use the default mesa libraries instead. So this section of helper.sh that's being shown here:
   function patchVendorGraphics() { local filename="$1" compareVersions "$__os_debian_ver" lt 9 && return getDepends patchelf printMsgs "console" "Applying vendor graphics patch: $filename" patchelf --replace-needed libEGL.so libbrcmEGL.so \ --replace-needed libGLES_CM.so libbrcmGLESv2.so \ --replace-needed libGLESv1_CM.so libbrcmGLESv2.so \ --replace-needed libGLESv2.so libbrcmGLESv2.so \ --replace-needed libOpenVG.so libbrcmOpenVG.so \ --replace-needed libWFC.so libbrcmWFC.so "$filename" }
   and any other code that looks for any of the Broadcom headers and libraries need changing in order for it to compile properly.

4. Force Retroarch's config to use ALSA instead of Pulseaudio when running emulators as it can affect the fps greatly.

I'll be posting a proof of concept video on youtube demonstrating this. I hope it helps.

[kcgen]

@raidensnake:

The pi 4 needs to use some form of desktop and window manager as I said before.

RetroPie on the Pi4 needs a windows manager?

That would be the nastiest of software kludges; so severe that I would forgo upgrading until non-window-manager-wrapper solution was implemented. Sounds like @joolswills is on track in this regard.

[ghost]

@krcroft Yes however the good news is that the pi 4 hardly suffers in framerate from what I can see running it. Whenever I tried to run it without a window manager SDL would constantly throw errors saying about the EGL surface as I mentioned before.

[joolswills]

It wont require a window manager. @raidensnake - your post is not correct and I'm sorry, but you're not really helping on this thread - it's causing confusion. We already have stuff working. Would be better to use the forum to share ideas and tests.

[ghost]

@joolswills I don't see how that isn't the case since dispmanx never worked when I tried it. The raspberry pi forums even stated dispmanx doesn't work properly on the pi 4 due to the way it functions.

[cmitu]

@geekinchief when the new Pi4 compatible version will be out, it will be announced in the forums and on the RetroPie home page - you'll just have to be patient.

[jimmydakang]

Any chance I could get a tiny little hint about how to even get emulationstation to run on pi4 without X11?

i constantly get the error
lvl0: Error creating SDL window!
Could not create EGL window surface
lvl0: Renderer failed to initialize!
lvl0: Window failed to initialize!

All of the forums for rpi 4 seem to imply that X11 is necessary, so the only clues I have are comments from @joolswills.

I don't need much hand holding. Just a little boost would be nice and then I'll start a post on another forum to prevent this one from getting cluttered.

[lockers90]

Any chance I could get a tiny little hint about how to even get emulationstation to run on pi4 without X11?

i constantly get the error
lvl0: Error creating SDL window!
Could not create EGL window surface
lvl0: Renderer failed to initialize!
lvl0: Window failed to initialize!

All of the forums for rpi 4 seem to imply that X11 is necessary, so the only clues I have are comments from @joolswills.

I don't need much hand holding. Just a little boost would be nice and then I'll start a post on another forum to prevent this one from getting cluttered.

Easy enough for force RetroPie to thinking its on a rpi3.

Install Debian. Git clone retro pie. Before you run RetroPie_setup.sh add the following line to retropie_packages.sh using sudo nano command. “__platform=rpi3” without quotes. Add it just under the part that says “__version=xxx”

Some emulators don’t work.

Hope that helps

[ghost]

@lockers90 That doesn't work on the pi 4. You're better using the fkms_rpi4 branch and also applying @psyke83's SDL patch that's listed here. 7a538f8

[lockers90]

@raidensnake i did that first cloning the fkms branch, but couldn’t get it working properly. Tried with the 4.5.1 release and worked fine

[ghost]

@lockers90 you can apply @psyke83's sdl2.sh #2770 and it will work with the fkms_rpi4.

[CaelThunderwing]

just a heads up, from helping testing over w/ @magicseb (im not sure i can tag people not afilliated w/ a project) for LibreElec+RetroArch, while theres a working image uptill now it was verry unstable, if it helps any, Kernel 4.19.56 is the sweet spot we found to keep it from causing a Kernel Panic (Memory Deadlock) it's something after this kernel version thats causing it to occur after about 2 to 2 n ahalf hours of use.

if it doesn't outright cause a Kernel panic and drops to what launched RetroArch, restarting the Pi Will cause a different kernel panic to Occur, it happened on 1GB Models 2GB and 4GB models. I hope this helps some!

[wmparsons]

Not trying to rush the process, but if there's any need for testing on actual hardware I'm definitely willing to help. Not expecting anything stable, happy to just log issues as needed. I've got a 4gb board just sitting around, patiently waiting for a stable release.

[midwan]

Amiberry generally works with FKMS, and we've got both a Dispmanx and a vanilla SDL2 version available. I've ordered a RPI4 now that it's back in stock, so in a few days I'll be able to test and prepare a version especially for that.

[erwan]

is there a label or something to follow what the blockers are for Rpi4?

[xirsoi]

It's been a month, any news?

I too have an RPI4 and could help test if necessary.

[midwan]

BTW, Amiberry at least has an RPI4-specific target now and has been tested to work perfectly well. Both the current v2.25 and the upcoming dev beta (which contains a lot of bug fixes and improvements, but it's not ready for release quite yet).

[ersinakinci]

For anyone coming in from Google, I was able to use the fkms_rpi4 branch and run various emulators without any problem on my RPI4 without any patching. Just git clone https://github.com/RetroPie/RetroPie-Setup.git && cd RetroPie-Setup && git fetch && git checkout fkms_rpi4 && sudo ./retropie_setup.sh.

[morph166955]

I have loaded the fkms_rpi4 branch on my pi4 and have had good success. The one exception seems to be both of the dreamcast emulators. Neither will start with an error of "* failed to add service - already in use?" in /dev/shm/runcommand.log. Some googling seems to indicate it's because the default of "dtoverlay=vc4-fkms-v3d" is configured for the pi4. When I remove that configration, or try to enable default GL in raspi-config, emulationstation will not start at all.

[midwan]

@morph166955
If you disable/remove that line, you essentially disable the FKMS driver. It will revert back to Legacy, or at least that's what it would do under Stretch. ;-)

[cmitu]

There's no 'legacy' driver anymore on the Pi4, so disabling the FKMS or the KMS overlays would make all GL apps unusable.

[burt111]

I thought I was the only one running into the Dreamcast issue I’ve tried a lot of compiler flags to no avail and came to the same conclusion as @morph166955 took me a whole week of debugging and only reason I seen the service error is because I was running emulstionstation through ssh

[ilitirit-za]

I was able to build and run (from EmulationStation) @psyke83 's reicast_fkms build without getting the "failed to create service" error. The only thing I changed in raspi-config was enabling fkms. Unfortunately the performance is really terrible compared to Flycast + Lakka. I'm going to play around with the settings a bit.

[morph166955]

I did a rebuild today and now I'm in much worse shape. Almost all of my emulators are throwing that error. I'm going to check tomorrow but it seems to be all of the "lr-" emulators that are busted. The reicast emulator did work as suggested. N64 seems to work as well.

EDIT: I believe the problem is with RetroArch itself. I did some tests against a "known good" compile from last month. When I recompile just RetroArch all of the libretro emulators seem to fail. I can however compile/update individual emulators without any issues.

[darksaviorx]

@morph166955 Fine here with retroarch 1.7.9. I cloned cmitu's repo for retroarch and added the commit that fixed compiling on pi4 https://github.com/libretro/RetroArch/pull/9597/commits
I then cloned fkms_rpi4 and built my emulators with that. All of my lr emulators work, including flycast.

[Skreelink]

I have the same issue, only ppsspp and mupen64plus work (since they are not lr- emulators). I'm assuming it has to do with the video driver. At the bottom when trying to launch with verbose logging:

[INFO] [Audio]: Set audio input rate to: 47872.40 Hz.
[INFO] [Video]: Video @ fullscreen
[INFO] [Video]: Starting threaded video driver ...

• failed to add service - already in use?

This is the error I get... I've tried updating everything, removing, reinstalling, doing a basic install over a current install, building each emulator individually, building retroarch individually. All with the same result. Get the same error trying to launch the retroarch from the config menu as well, so I'm leaning toward a retroarch problem.

@darksaviorx You mentioned cloning cmitu's retroarch repo... cmitu has a fork of Retropie-Setup, but not Retroarch. I also tested building with cmitu's "fkms_rpi4_cmitu" branch of Retropie-Setup, same results. It also compiles 1.7.6, not 1.7.9. Trying to alter it to build 1.7.9 errors about the patches.

[joolswills]

This is not a support thread.

[morph166955]

Just to be clear, not looking for support. Posting experiences and documenting changes so that the devs are aware of issues experienced as they move forward.

[joolswills]

We are not at a stage where we need user testing yet - and the user above did look like they were after support. This topic has become pointless really - I'm just going to close it. Use the forum to discuss issues you have if you want to test the unfinished branch.

[khimaros]

FYI, you can lock an issue without closing it. This would allow the issue to still be used for status tracking while eliminating the support request noise.