Adventures with ODROID XU4 and RetroPie

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

TillmanZ

@zerojay Hi there!

I was wondering if you also encountered the lvl0 failed to get mixer ALSA issue after you have installed Retropie on your XU4 with kernel 4.14.
It is not really a critical issue for me as sound works in the snap videos and also in all the emulators but it sure looks not so very polished seeing this error appear in ES when switching the systems.

Any idea how to fix this?

Best,

Tillman

zerojay

I switched over to the premade image based on kernel 3. Sorry.

zerojay

Updated the method of getting full screen on advmame to allow it to be automatic and a bit more... proper.

yaazzz

Does anyone has been able to get scummvm working on xu4. Emulator install should be in "opt" section according to scumm.sh file but it is not.

zerojay

@yaazzz It's likely masked out with a !mali flag. You can remove it and you should then see it show up in RetroPie-Setup. Try installing it and let us know if it works.

yaazzz

@zerojay said in Adventures with ODROID XU4 and RetroPie:

@yaazzz It's likely masked out with a !mali flag. You can remove it and you should then see it show up in RetroPie-Setup. Try installing it and let us know if it works.

Thank you : that's was the trick. Everything went well : compilation and game launch. I only need To understand how To use the Ds3 with scumm now.

BuZz

@yaazzz if it works fine, I can enable scummvm for mali targets. Thanks.

yaazzz

Good morning. I tried to compile Dolphin but it seems I brake the system as I got the following messages :
lvl0: Error creating SDL window!
Could not initialize EGL
lvl0: Renerer failed to initialize!
lvl0: Windows failed to initialize!

Before touching anything I would like to get your feedback on what is the best solution to recover.

zerojay

You upgraded your version of SDL2 to whatever is latest in Ubuntu and therefore broke emulationstation, most likely. You'll have to run the installation again to get the original SDL2 installed.

I'm not sure why you are compiling Dolphin as I really don't see it being something usable on an ODroid XU4.

yaazzz

@zerojay said in Adventures with ODROID XU4 and RetroPie:

You upgraded your version of SDL2 to whatever is latest in Ubuntu and therefore broke emulationstation, most likely. You'll have to run the installation again to get the original SDL2 installed.

I'm not sure why you are compiling Dolphin as I really don't see it being something usable on an ODroid XU4.

Hi, thank you for this feedback. You are Right I don't know why sometimes I am so stupid :) So I tried what you suggest without success. By the way as I didn't reboot after the scumm install please let me check again if it is not the origin of the brake.

For people having a cloushell please disconnect the disk and cloudshell for the first boot, make :
apt-get update
apt-get upgrade
apt-get dist-upgrade
apt-get install linux-image-xu3
poweroff

Then reconnect USB and connector to the cloudshell.

yaazzz

I confirm it is working without the !mali flag. Enjoy!

Elwro

Hi,

I have problems with RetroPie on XU4 too.

For example, on Ubuntu 18.04, I can't build RetroArch :

LD retroarch

obj-unix/release/gfx/video_driver.o : Dans la fonction « video_context_driver_find_prev_driver » :

video_driver.c:(.text+0x54f4) : référence indéfinie vers « gfx_ctx_mali_fbdev »

obj-unix/release/gfx/video_driver.o : Dans la fonction « video_context_driver_find_next_driver » :

video_driver.c:(.text+0x55ec) : référence indéfinie vers « gfx_ctx_mali_fbdev »

obj-unix/release/gfx/video_driver.o : Dans la fonction « video_context_driver_init_first » :

video_driver.c:(.text+0x573c) : référence indéfinie vers « gfx_ctx_mali_fbdev »

obj-unix/release/gfx/video_driver.o:(.data.rel.ro+0x10) : référence indéfinie vers « gfx_ctx_mali_fbdev »

collect2: error: ld returned 1 exit status

Makefile:187: recipe for target 'retroarch' failed

make: *** [retroarch] Error 1

~/RetroPie-Setup

Could not successfully build retroarch - RetroArch - frontend to the libretro emulator cores - required by all lr-* emulators (/home/odroid/RetroPie-Setup/tmp/build/retroarch/retroarch not found).

Elwro

lr-mupen64plus :

/usr/bin/arm-linux-gnueabihf-ld : ne peut trouver -lGLESv2

collect2: error: ld returned 1 exit status

Makefile:304: recipe for target 'mupen64plus_libretro.so' failed

make: *** [mupen64plus_libretro.so] Error 1

Removing additional swap

~/RetroPie-Setup

Could not successfully build lr-mupen64plus - N64 emu - Mupen64Plus + GLideN64 for libretro (/home/odroid/RetroPie-Setup/tmp/build/lr-mupen64plus/mupen64plus_libretro.so not found).