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).

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.

@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).

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.

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