[Odroid-C2] RetroPlayer Problem

    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

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

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

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

    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.

    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.