[Exynos] LE 13.0-nightly for Odroid XU4 no longer boots

    it's the same parameters that work fine in 0725. I would like to increase systemd verbosity if that is possible. Parameter order should not matter in extlinux.conf. I do set up screen with the same baudrate of 115200, and that should be all if it works fine in 0725.

    Hi all,

    in logs it looks like no sound device is found by alsa ?

    TuxOhOlic you can eventually try this one. This build should be very close to what you tested since I pulled sources on 12.18. There are additional kernel supports I mentioned earlier to get 6.16 kernel booting. I suspect(hope) your log will go a little bit further.

    Download LibreELEC-Exynos.arm-13.0-devel-20251220102805-5cc8ee3-odroid-xu4.img.gz 128.97 Mo
    Download from download.gg, the number 1 in one-click online file hosting websites (Bandwidth 1 Gbit/s) :…
    download.gg

    I can eventually provide a build with 6.17.1 kernel, I just don't know what is the most relevant, if we should debug 6.17 builds first or consider the current linux kernel version.

    tetienne: attached is the log for Exynos.arm-13.0-devel-20251220102805-5cc8ee3-odroid-xu4. Your image does boot into a terminal, does hand out an ip and start ssh, but the display stays blank with no signal. I'm still missing debug switches for systemd. The logs do seem to swallow up a lot of content and then just open the ttySAC2 terminal. I have no clue what this is about, but I will test uart against Armbian or my own Debian images I use with the xu4.

    TuxOhOlic

    yes, I realised today that my 6.17 and 6.18 images are booting and you can ssh to it. No real need for systemd logs, the problem can be seen in logs that there is no drm, so no graphics.

    Divergence appear in logs at line 192 in your logs with dma-controller, there's one missing channel, which appears to be the GPU when you look in a working log (it's associated later line 303 of your working log).

    I made a few tests today, but I did not manage to solve that issue. In 6.17 kernels it seems that did something around the panfrost driver for mali GPUs, I suspect it's related to that.

    If the OS is running but no graphics (and thus no Kodi) I'll make an educated guess the problem is mesa related. See if reverting to the mesa version used with the last known working images restores things? If yes, you can manually bisect between known-good and known-bad mesa versions to find when the breaking version change occurs; then you can look at mesa changelogs/commits to see what commits might be involved.

    NB: I'm guessing mesa because the panfrost kernel driver has received little real-world change over time since it was added, but on the userspace side mesa has a high rate of change and mesa automated testing will be done against Bifrost hardware, and perhaps the second generation Midgard T860 used in some Chromebook devices; not the first generation Midgard T628 used with XU4 which has an inconvenient amount of silicon "errata" that often require complex or fugly workarounds.

    heitbaum the patch modif is basically there to maintain the same source code between <6.17 kernels and 6.17, in order to revert the behavior to a very old linux-5 kernel. So we were compiling the same code in 6.16 and 6.17.

    In the end I've deleted that patch to stick to linux upstream and my 6.17.1 build works. Let's see for 6.18...

    TuxOhOlic : in case you want to give a try to 6.17.1 build

    Download LibreELEC-Exynos.arm-13.0-devel-20251222113709-3336d28-odroid-xu4.img.gz 128.03 Mo
    Download from download.gg, the number 1 in one-click online file hosting websites (Bandwidth 1 Gbit/s) :…
    download.gg

    Edited once, last by tetienne (December 22, 2025 at 10:44 AM).

    well done, tetienne, they both run fine and load kodi alpha with network and sound. I'll test the images and my addons some more over the holidays. Here are the uart logs, who still look somewhat incomplete to me after "Run /init as init process". There should be more output. With debian images uart logs look normal, I tested this yesterday. I can't really tell why that is because the relevant boot parameters are similar. systemd-journald has other options in debian, that is one thing i noticed comparing with LE journald. If somebody knows how I can change this without modifying the SYSTEM squash file I'd like to know how this is done.

    The contents of /storage/.config/system.d are overlaid onto the virtual filesystem after SYSTEM is expanded on boot, so if you want to change config of an embedded .service file just clone the file to that location, make edits, and reboot. The same is true for other special folders under /storage/.config/ .. or you need to start building custom images with your preferred changes baked-in during compile via the buildsystem. The former is fine for quick tweaks and tests. The latter will be easier to sustain over a longer period.

    chewitt : This didn't work, what did work is add the missing symlink from /storage/.config/journald.conf.d > /etc/systemd/journald.conf.d/ to SYSTEM and repackage it.

    Now the uart logs look better with tetiennes last image (attached here). You also get better logs of the shutdown process. Why isn't "ForwardToConsole=yes" and "TTYPath=/dev/ttySAC2" an active default in journald.conf? It don't think it matters if journald writes there if now uart is attached and extlinux.conf always contains "systemd.debug_shell=ttySAC2 console=ttySAC2,115200n8" anyways.

    tetienne : the playback framerate does look somewhat reduced with 5e48165, can you confirm frame drops as well with 1080p50 content?

    The existing config worked fine at one point but systemd is a continually evolving beast so perhaps something was improved and now needs additional config juju for things to work as before. If something needs fixing .. send a PR with a decent explanation of what is being changed and why, and it will be tested (over a range of build targets) and if good, merged.