Adventures with ODROID XU4 and RetroPie

zerojay

Hi, I just received an ODROID XU4 and have been working to get RetroPie running on it. The idea here behind this is to document things I run into and possible workarounds/fixes so that I don't flood the bug tracker with issues needlessly. This is a living document.

Used the latest XU4 Ubuntu image: https://wiki.odroid.com/odroid-xu4/os_images/linux/ubuntu_4.14/20171212

Followed the RetroPie wiki for basic installation: https://github.com/RetroPie/RetroPie-Setup/wiki/Odroid-XU4

Issues and workarounds

* advmame-0.94/advmame-1.4 cannot be built for Odroid XU4

So the issue here is that the script module for both advmame-0.94 and 1.4 both are set to not allow building on the Odroid XU4 with the "!mali" flag. This is likely because it seems to just not function when running any game, leaving the following behind in the runcommand.log:

The raw keyboard driver cannot be used with the SDL video driver.
Unable to start video emulation

Workaround/fix: Remove the !mali flag and build through RetroPie Setup. Once built, you will want to edit the /opt/retropie/configs/mame-advmame/advmame-0.94.rc and advmame-1.4.rc files with nano and make the following change:

device_keyboard auto -> device_keyboard sdl

Save the file and you should now be able to run advmame just fine on ODroid. You'll probably get the game running in the corner of the screen with no buttons working, just plug in a keyboard and setup everything from the Tab key menu and you should be good to go.

* advmame appears to only show in the top left corner at a tiny resolution.

When launching advmame, all games will show up only in a tiny resoultion in the top left corner. The Tab key menu is unreadable and even when you are able to make your way to the Video menu, none of the options appear to help much.

Workaround/fix: This is one of those cases where MAME just can't handle things automatically so let's fix it.

Edit the /opt/retropie/configs/mame-advmame/advmame-0.94.rc and advmame-1.4.rc files with nano and make the following changes:

device_video auto -> device_video sdl
device_video_output overlay -> device_video_output fullscreen
display_mode auto -> display_mode sdl_1920x1080
display_resize auto -> display_resize fractional

All your games should now display correctly in fullscreen.

* lr-ppssspp complains of missing header files when attempting to compile

Seems this package requires more dependencies declared. Run the following to install what you need:

apt-get install libavformat-dev libswscale-dev

* lr-ppsspp fails to build on sceMpeg.cpp

Log shows the following:

../Core/HLE/sceMpeg.cpp: In function ‘bool InitPmp(MpegContext*)’:
../Core/HLE/sceMpeg.cpp:771:21: error: ‘PIX_FMT_RGBA’ was not declared in this scope
pmp_want_pix_fmt = PIX_FMT_RGBA;
^
../Core/HLE/sceMpeg.cpp:774:45: error: ‘CODEC_ID_H264’ was not declared in this scope
AVCodec * pmp_Codec = avcodec_find_decoder(CODEC_ID_H264);

Workarounds/fixes: None yet, still investigating, likely related to https://github.com/hrydgard/ppsspp/issues/7955

* Reicast cannot be built for Odroid XU4

So the issue here is that the script module for reicast is set to not allow building on the Odroid XU4 with the "!mali" flag.

Workaround/fix: Remove the !mali flag and build through RetroPie Setup.

* lr-parallel-n64 fails compilation/linking.

Compilation crashes out at the following:

./libretro-common/audio/conversion/float_to_s16.o: In function convert_float_to_s16': float_to_s16.c:(.text+0x6c): undefined reference to convert_float_s16_asm'
./libretro-common/audio/conversion/s16_to_float.o: In function convert_s16_to_float': s16_to_float.c:(.text+0xbc): undefined reference to convert_s16_float_asm'
collect2: error: ld returned 1 exit status
Makefile:863: recipe for target 'parallel_n64_libretro.so' failed

This appears to be a bug having to do with the NEON flag being used. See https://github.com/libretro/parallel-n64/issues/487 for more details.

Workaround/fix: Compile without HAVE_NEON = 1 and -mfpu=neon flags (and also lose out on the better speeds likely provided by them). I haven't verified this myself yet.

* EmulationStation video previews play without audio.

Workaround/fix: Follow these steps to install and configure pulseaudio: https://retropie.org.uk/forum/post/112887

zerojay

* Reicast fails building on newer Ubuntu kernels

This is being caused by the newer kernels changing their reported hardware for the ODroid XU4. Previous kernels would report them as ODROID-XU3 but the most recent kernels now return ODROID-XU4. The platform code in Reicast is still expecting to receive ODROID-XU3 and when it doesn't, it builds a generic arm build which fails.

Workaround/fix: A change is being submitted to the RetroPie reicast repo with the fix: https://github.com/RetroPie/reicast-emulator/pull/5

* Setting a default resolution for an emulator or core does not appear to work

Attempting to set the resolution for whichever emulator or game you are trying to run doesn't appear to function. This is easily noticable with RetroArch where you would clearly see the yellow warning text at the bottom of the screen would show up much larger with lower resolutions but it appears that the change doesn't happen.

Also, you can notice that when running any game through runcommand, with a resolution change or not, there is a quick flash of an error that shows that fbset is not installed.

Workaround/fix: None yet, however you can run apt-get install fbset to fix the fbset error. Just installing it isn't enough to fix the lack of resolution options, unfortunately.

BuZz

@zerojay resolution changing is RPI specific and uses tvservice which is a RPI tool. It shouldn't show up as an option on the XU4 (I can check that). Also fbset should not be used unless it exists. I can check that too.

LoloMc

Hi all,
I'm extremely interested by Reicast on XU4 but as Linux neewbie, I do not know where is the !mali flag to remove ?

Do you continue to work on the subject ?

pfox__

Hi @zerojay I've repro'd the same error when building ppsspp on my xu4.

Based on my read of RetroPie's fork of the ppsspp codebase, we would need to resynthesize PR#7959 from the hrydgard/ppsspp repo as a PR against RetroPie/ppsspp. Is that correct?

If so, I can put together that PR and submit it... but...

I'm curious of how to test it locally in the context of using the RetroPie-Setup.sh infrastructure.. should I just retarget the sub-module checkout to point at a local copy of a ppsspp fork and use that? Is there a flag in the script to have it not do the checkout portion? I can't find any docs on doing this kind of testing/iteration within RetroPie-Setup.

Thanks!

zerojay

@pfox__ said in Adventures with ODROID XU4 and RetroPie:

Hi @zerojay I've repro'd the same error when building ppsspp on my xu4.

Based on my read of RetroPie's fork of the ppsspp codebase, we would need to resynthesize PR#7959 from the hrydgard/ppsspp repo as a PR against RetroPie/ppsspp. Is that correct?

If so, I can put together that PR and submit it... but...

I'm curious of how to test it locally in the context of using the RetroPie-Setup.sh infrastructure.. should I just retarget the sub-module checkout to point at a local copy of a ppsspp fork and use that? Is there a flag in the script to have it not do the checkout portion? I can't find any docs on doing this kind of testing/iteration within RetroPie-Setup.

Thanks!

Just fork off RetroPie/ppsspp (on Github), make your changes to your fork and update the module to point to your fork, I would say. If you want, I can do that for you and you can submit a PR to me with your changes.

pfox__

@zerojay nm, I read through the codebase some more and it looks like the change in hrydgard's repo are a part of RetroPie's: https://github.com/RetroPie/ppsspp/commit/33c39636c8d3f9cef25fea87cc458e3b69a9110f#diff-7569aff64133d9c49602eec78c0dfd5b

I don't have access to my xu4 at this moment.. I wonder if the RetroPie-Setup script isn't pulling from the HEAD of RetroPie's fork? I will check the module as you say.

zerojay

Looks like it's pulling from the main original repo, actually.

https://github.com/hrydgard/ppsspp.git

pfox__

@zerojay Yes you beat me to it :)

pfox__

@zerojay But if that were the case then the output we see above makes no sense... I think it's pulling from libretro's fork? https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-ppsspp.sh#L29

That would appear to be the case (although I need my logs of my failed ppsspp build to verify, which I don't have access to atm).. here we see the old version of the code: https://github.com/libretro-mirrors/libretro-ppsspp/blob/master/Core/HLE/sceMpeg.cpp#L771

So I guess that is where we should target for the fix, then.

zerojay

Sorry, I should specify here. I was looking at the standalone version which appears to pull from main, not lr-ppsspp.

pfox__

@zerojay lol there's a PR for this very issue languishing in the PR queue on libretro's version. https://github.com/libretro-mirrors/libretro-ppsspp/pull/85

zerojay

Pretty sure they are using https://github.com/libretro/ppsspp/, not https://github.com/libretro-mirrors/ppsspp/ and it looks like that change is already there.

pfox__

@zerojay Do you have access to the full RetroPie-Setup log that you used when pasting your error from building lr-ppsspp in the OP of this thread? That should show you which repo it cloned from. I'm away from home right now, so I won't be able to verify this until later, but I think the build error is because retropie-setup is using the scriptmodules/libretrocores/lr-ppsspp.sh script to drive it's build, not the standalone at scriptmodules/emulators/ppsspp.sh.

Here are the relevant lines in the respective scripts mentioned above:

lr-ppsspp.sh: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/libretrocores/lr-ppsspp.sh#L29

        gitPullOrClone "$md_build" https://github.com/libretro/libretro-ppsspp.git

The above repo redirects to libretro-mirrors/libretro-ppsspp. This is the repo that DOES NOT have the 33c396 commit fix for the ffmpeg issue.

ppsspp.sh: https://github.com/RetroPie/RetroPie-Setup/blob/master/scriptmodules/emulators/ppsspp.sh#L26

    gitPullOrClone "$md_build/ppsspp" https://github.com/hrydgard/ppsspp.git

This repo does have the fix we've been discussing.

Please let me know if I'm missing something, here. As I said, if you have your full logs on hand, you can verify this for yourself. Otherwise I will follow up later today when I have a chance to check myself.

zerojay

Okay, for lr-ppsspp, the logic is that if the platform isn't rpi (as it isn't for us), then it would use https://github.com/libretro/libretro-ppsspp.git to build from, which as you pointed out is the mirror without the fix we need. I think I'll fork it, add the fix we need to it and attempt to build to see what comes out of it.

EDIT: It got past sceMpeg.cpp... fingers crossed.

Okay, it compiles and runs and runs quite well with no tweaking. Burnout Legends ran full speed with only the occasional slight blip however it does appear that actually playing MPEG videos is busted. So for the menu backgrounds of Burnout Legends which are all MPEG videos, they don't properly play and it appears there's output about an unsupported format (it's difficult to read as it's outputing the text to the screen which gets overwritten quickly. (Might be my fault as I had a local change for the lr-ppsspp script that might have caused it, giving it another shot.)

EDIT2: Appears my tweak didn't help or hurt anything. So the error being output is videoc_try_fmt:401 Unsupported format for destination. Looking into it.

Also, for awareness, this is building PPSSPP 1.0.1 which is quite old now. Going to try http://github.com/libretro/ppsspp.git now to see how that turns out.

zerojay

Latest lr-ppsspp (http://github.com/libretro/ppsspp.git) doesn't compile for me:

g++ -O2 -mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard -ftree-vectorize -funsafe-math-optimizations -DGL_GLEXT_PROTOTYPES -DGIT_VERSION="" dd73f91"" -std=c++11 -O2 -DNDEBUG -D__LIBRETRO__ -DINLINE="inline" -DPPSSPP -DUSE_FFMPEG -DBAKE_IN_GIT -DPROFILE_THIS_SCOPE(x) -DGLEW_STATIC -DGLEW_NO_GLU -DNO_VULKAN -I../ffmpeg/linux/armv7l/include -I. -I. -I.. -I../Common -I../libretro -I../ext/native -I../ext/zlib -I../ext/snappy -I../ffmpeg -I../ffmpeg/linux/armv7l/include -I../ext/cityhash -I../ext/armips -I../ext/native/ext/libzip -I../ext/native/ext -I../ext/native -I../ext/libkirk -I../ext/xbrz -I../ext/xxhash -I../ext/native/ext/rg_etc1 -I../ext/glew -DARM -fPIC -DARM -marm -mfpu=neon -D__NEON_OPT -D__arm__ -DARM_ASM -DGLES -DUSING_GLES2 -DDYNAREC -D_ARCH_32 -c -o../GPU/GPU.o ../GPU/GPU.cpp
In file included from ../ext/native/gfx/gl_common.h:25:0,
from ../GPU/GLES/DrawEngineGLES.h:30,
from ../GPU/GLES/GPU_GLES.h:25,
from ../GPU/GPU.cpp:29:
../ext/native/gfx/../gfx_es2/gl3stub.h:504:289: error: ‘void (* glCopyImageSubDataOES)(GLuint, GLenum, GLint, GLint, GLint, GLint, GLuint, GLenum, GLint, GLint, GLint, GLint, GLsizei, GLsizei, GLsizei)’ redeclared as different kind of symbol
ImageSubDataOES) (GLuint srcName, GLenum srcTarget, GLint srcLevel, GLint srcX, GLint srcY, GLint srcZ, GLuint dstName, GLenum dstTarget, GLint dstLevel, GLint dstX, GLint dstY, GLint dstZ, GLsizei width, GLsizei height, GLsizei depth);
^
In file included from ../ext/native/gfx/gl_common.h:8:0,
from ../GPU/GLES/DrawEngineGLES.h:30,
from ../GPU/GLES/GPU_GLES.h:25,
from ../GPU/GPU.cpp:29:
/usr/include/GLES2/gl2ext.h:278:29: note: previous declaration ‘void glCopyImageSubDataOES(GLuint, GLenum, GLint, GLint, GLint, GLint, GLuint, GLenum, GLint, GLint, GLint, GLint, GLsizei, GLsizei, GLsizei)’
GL_APICALL void GL_APIENTRY glCopyImageSubDataOES (GLuint srcName, GLenum srcTarget, GLint srcLevel, GLint srcX, GLint srcY, GLint srcZ, GLuint dstName, GLenum dstTarget, GLint dstLevel, GLint dstX, GLint dstY, GLint dstZ, GLsizei srcWi
^
Makefile:444: recipe for target '../GPU/GPU.o' failed

pfox__

I just tried to install the ppsspp script, via retropie_setup.sh, that sources itself from hrydgard/ppsspp and got the same build error as @zerojay shows above. That error message is referenced in a few psspp issues (https://github.com/hrydgard/ppsspp/issues/2936 & https://github.com/hrydgard/ppsspp/issues/9032 ).. Not sure what to make of it yet.

psyke83

@zerojay,

There's an ongoing effort to implement libretro support directly into the official ppsspp repository. I would suggest waiting for the PR to be accepted before wasting too much time on what will hopefully soon be an obsolete repository.

There have been problems with the vanilla ppsspp build related to GLES support for Pi recently, too. I sent some fixes that have been merged in the last week or so, but as of last night, the build had a new issue on Pi, where it's setting up a 960x544 window size instead of the actual fullscreen resolution.

zerojay

@zerojay said in Adventures with ODROID XU4 and RetroPie:

advmame appears to only show in the top left corner at a tiny resolution.

Added this section to the OP so that I don't lose it.

TillmanZ

Hi there!

Would any one of you have an idea why my lr-mame2010 on my XU4 based on the 4.14 kernel (minimal image from December 2017) would not load roms?
When I manually launch the core with retroarch in the command line then I can see mame-2010 always complaining that it does not find any of the files even though those files are definitely part of the rom's zip archive.
I double and triple checked if the roms are really 0.139 but they are and they work on a Rpi3 mame-2010 build.
File permissions on the arcade folder (that's where they are stored on my build) are set to rw-rw-r--.

What am I missing - why does mame-2010 not like my roms? :)

Best,

Tillman

P.S. I just built lr-mame2010 directly via the retropie-setup.sh script - allegedly without any issues.

*** UPDATE ***

I can confirm that the issue is definitely caused by the new build.
I have replaced the core with a known-to-be-working build from a couple of weeks ago and all roms work flawlessly.
Only the new build complains about the missing files (all of them) inside the zip.

So what might be causing this?

Best,

Tillman