Adventures with ODROID XU4 and RetroPie

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

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