[Odroid-C2] RetroPlayer Problem

qazy · January 19, 2025 at 2:46 PM

Hi

Have the same problem. Can not start "native" games 2048 or MrBoom. Also can not run games on emulator of "game and walk". In the same time I can run snes and sega genesis games.

Any clue how to fix it?

My running log https://paste.kodi.tv/idehexugub

**Da Flex** · January 19, 2025 at 3:37 PM

Please provide a full debug log.

How to post a log (wiki)

1. Enable debugging in Settings>System Settings>Logging
2. Restart Kodi
3. Replicate the problem
4. Generate a log URL (do not post/upload logs to the forum)

use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link

qazy · January 19, 2025 at 9:56 PM

Thanks for reply.

Did not get the difference so here they are.
kodi.log https://paste.libreelec.tv/eternal-hookworm.log
kodi_crash.log https://paste.libreelec.tv/refined-shrimp.log

I ran 2048 ant than something from Nintendo game & watch collection

**Da Flex** · January 20, 2025 at 2:01 AM

At devs: Is that normal for Odroid-C2?

Code

Feb 27 20:26:05.988127 LibreELEC kernel: [Firmware Bug]: Kernel image misaligned at boot, please fix your bootloader!

To me it looks like a general buffer issue on Odroid-C2:

Code

2025-01-20 00:35:29.969 T:974     error <general>: CEGLImage::CreateImage - failed to import buffer into EGL image: 0x3003
...
Jan 20 00:35:41.085671 LibreELEC kodi.sh[974]: linear imported buffer stride is smaller than minimal: 1504 (BO) < 1536 (min)

**chewitt** · January 20, 2025 at 7:02 AM

Quote from Da Flex

At devs: Is that normal for Odroid-C2?

Yup, 100% of AMLGX installs show it and it's completely harmless.

Quote from Da Flex

To me it looks like a general buffer issue on Odroid-C2:

Nope, there is no such thing as a "general buffer issue" and we're grabbing at straws with that comment.

qazy Please update to the latest LE13 nightly. I haven't touched the LE12 codebase in a while and any investigating and fixing needs to focus on the current codebase I'm poking. I have a hunch the error messages are generated by mesa, but it's probably reporting an issue with the underlying Linux DRM layer (where things like stride and buffers are handled). It may be something related to 'canvas' setup.

qazy · January 20, 2025 at 4:13 PM

The latest and greatest LE 13
system log https://paste.libreelec.tv/model-moray.log

crash log https://paste.libreelec.tv/lucky-buffalo.log

**Da Flex** · January 20, 2025 at 4:33 PM

EGL has issues while writing onto canvas (system log):

Code

2025-01-20 15:55:15.543 T:808     debug <general>: EGL Debugging:
                                                   Error: EGL_BAD_ALLOC
                                                   Command: eglCreateImageKHR
                                                   Type: EGL_DEBUG_MSG_CRITICAL_KHR
                                                   Message: createImageFromDmaBufs failed
2025-01-20 15:55:15.543 T:808     debug <general>: CEGLImage::CreateImage - attributes:
                                                   EGL_WIDTH: 376
                                                   EGL_HEIGHT: 464
                                                   EGL_LINUX_DRM_FOURCC_EXT: AR24
                                                   EGL_DMA_BUF_PLANE0_FD_EXT: 53
                                                   EGL_DMA_BUF_PLANE0_OFFSET_EXT: 0
                                                   EGL_DMA_BUF_PLANE0_PITCH_EXT: 1504
                                                   
2025-01-20 15:55:15.543 T:808     error <general>: CEGLImage::CreateImage - failed to import buffer into EGL image: 0x3003

Display More

I think the cause is a GPU driver issue (missing mali regulator, crash log):

Code

Jan 07 20:45:57.901461 LibreELEC kernel: lima d00c0000.gpu: gp - mali450 version major 0 minor 0
Jan 07 20:45:57.921082 LibreELEC kernel: lima d00c0000.gpu: pp0 - mali450 version major 0 minor 0
Jan 07 20:45:57.923010 LibreELEC kernel: lima d00c0000.gpu: pp1 - mali450 version major 0 minor 0
Jan 07 20:45:57.923667 LibreELEC kernel: lima d00c0000.gpu: pp2 - mali450 version major 0 minor 0
Jan 07 20:45:57.924346 LibreELEC kernel: lima d00c0000.gpu: l2_cache0 8K, 4-way, 64byte cache line, 128bit external bus
Jan 07 20:45:57.925304 LibreELEC kernel: lima d00c0000.gpu: l2_cache1 64K, 4-way, 64byte cache line, 128bit external bus
Jan 07 20:45:57.925997 LibreELEC kernel: lima d00c0000.gpu: bus rate = 166666667
Jan 07 20:45:57.926602 LibreELEC kernel: lima d00c0000.gpu: mod rate = 24000000
Jan 07 20:45:57.927225 LibreELEC kernel: lima d00c0000.gpu: error -ENODEV: _opp_set_regulators: no regulator (mali) found

Seems like chewitt is already familiar with that issue:

Re: Missing mali regulator in Amlogic dts - Robin Murphy

Maybe this is helpful:

Mali driver fails to initialize · Issue #39 · rockchip-linux/kernel

Often the mali driver stack fails to initialize: $ glmark2-es2 ERROR: The DDK is not compatible with any of the Mali GPUs on the system. The DDK was built for…

github.com

**garbear** · January 20, 2025 at 5:43 PM

We can narrow it down to a DMA issue. In my RetroPlayer test builds I use this hack to force GBM: https://github.com/garbear/xbmc/c…69a58f7f7f8713e

DMA was giving some users black screens due to strided textures I think (here's the original report: https://forum.kodi.tv/showthread.php?tid=373658 )

Can someone do an ODROID-C2 build with that patch?

EDIT: I'll upload one myself

**chewitt** · January 20, 2025 at 5:45 PM

Quote from Da Flex

I think the cause is a GPU driver issue (missing mali regulator, crash log):

That's a wrong guess (and if you don't know the answer, don't guess). Amlogic hardware has no Mali regulators so the frequency scaling code in the Mali probe/initialisation code correctly cannot find them and throws an error, which is harmless. Tweaking the kernel code to stop bogus user reports of GPU bugs is something I'd like to solve, but it's harder than it looks.

I've asked Q's to garbear who maintains Kodi retroplayer.

**garbear** · January 20, 2025 at 6:50 PM

Can you give this image a try? It's based on latest LE 13 master plus the patch I posted.

https://github.com/kodi-game/LibreELEC.tv/releases/download/libreelec-13.0-20250120/LibreELEC-AMLGX.aarch64-13.0-devel-20250120100528-cbe5bdc-odroid-c2.img.gz

qazy · January 20, 2025 at 7:49 PM

garbear
Same black screen
system log https://paste.libreelec.tv/arriving-jaybird.log

crash log https://paste.libreelec.tv/closing-wallaby.log

**Da Flex** · January 20, 2025 at 8:43 PM

Quote from chewitt

That's a wrong guess (and if you don't know the answer, don't guess).

Hard to resist when logs are filled with so much fake news.

**chewitt** · January 21, 2025 at 3:28 AM

Quote from qazy

Same black screen
system log https://paste.libreelec.tv/arriving-jaybird.log

Odd. This time there's no crashes or complaints about stride size and buffers. The logs look clean.

**Da Flex** · January 21, 2025 at 6:37 AM

It switches to a specific frame buffer:

Code

Jan 07 20:45:54.287681 LibreELEC kernel: meson-drm d0100000.vpu: Queued 1 outputs on vpu
Jan 07 20:45:54.287811 LibreELEC kernel: stackdepot: allocating hash table of 131072 entries via kvcalloc
Jan 07 20:45:54.288333 LibreELEC kernel: meson-drm d0100000.vpu: CVBS Output connector not available
Jan 07 20:45:54.289012 LibreELEC kernel: meson-dw-hdmi c883a000.hdmi-tx: Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)
Jan 07 20:45:54.289641 LibreELEC kernel: meson-dw-hdmi c883a000.hdmi-tx: registered DesignWare HDMI I2C bus driver
Jan 07 20:45:54.290201 LibreELEC kernel: meson-drm d0100000.vpu: bound c883a000.hdmi-tx (ops meson_dw_hdmi_ops)
Jan 07 20:45:54.290312 LibreELEC kernel: [drm] Initialized meson 1.0.0 for d0100000.vpu on minor 0
Jan 07 20:45:54.290363 LibreELEC kernel: Console: switching to colour frame buffer device 240x67
Jan 07 20:45:54.290917 LibreELEC kernel: meson-drm d0100000.vpu: [drm] fb0: mesondrmfb frame buffer device

Any chance to test / debug the function of "switching to colour frame buffer device 240x67"? Maybe that's the moment when the screen goes black.

**chewitt** · January 21, 2025 at 8:52 AM

Code

Jan 07 20:45:54.278148 LibreELEC kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034]
...
Jan 07 20:45:54.290312 LibreELEC kernel: [drm] Initialized meson 1.0.0 for d0100000.vpu on minor 0
Jan 07 20:45:54.290363 LibreELEC kernel: Console: switching to colour frame buffer device 240x67
Jan 07 20:45:54.290917 LibreELEC kernel: meson-drm d0100000.vpu: [drm] fb0: mesondrmfb frame buffer device

Nope, that's the moment 0.12 seconds after kernel boot when the simplefb device used during early stage boot is unloaded and the kernel switches to the meson (Amlogic) fb device provided by the VPU on the SoC which is now ready for use.

There is nothing helpful in the logs at this point and garbear understands what the overall issue is about. You can stop guessing.