I've been trying since last week to reboot my odroid but it always just shuts down, tho I should mention that the LE logo does appear and looks like its trying to start when it shuts off. No matter what method I use whether it's from SSH (reboot or kodi-send --action="restart") or the gui it's always the same. And to turn my device back on i have to unplug and replug it, sometimes several times which is starting to worry me.
When the board boots (u-boot first, then kernel, then userspace) the kernel init script loads the LE boot splash. When Kodi starts, it renders to a full screen 'Window' and this overwrites/obscures the splash. If you manually stop Kodi the Window goes away to reveal the underlying layer with the splash again. If a shutdown is slow enough you'll see the same; Kodi stops and the splash is revealed again. If the screen then goes black, e.g. TV loses the HDMI signal and then you see the splash again; it suggests the board has rebooted. If you don't see the black loss of signal and the LE splash remains on-screen it suggests the board is never shutting down. If you only see the black/lost-signal it suggests the board shuts down and either never reboots; or it reboots and hangs before the kernel init runs.
I haven't boot tested a C2 for a while, but it was working fine last time I did, and nothing has really changed. For kicks you can try this on a clean SD card: https://chewitt.libreelec.tv/testing/LibreE…droid-c2.img.gz (removing all add-ons and such from scope is never a bad thing). If you see the same and have an old shitty SD card (no fancy fast speeds) lying around that's also worth testing to rule out issues with voltage changes not happening (not resetting the card to a state where it can be seen on boot). Testing a clean card also proves it's not just an old/bad/dying card (they don't last forever) - the same applies to emmc modules.
The best way to really understand what's happening is connecting a UART cable as this will clearly show the early stages of boot (u-boot and kernel) and where things get stuck or not.
And (as has already been said) whatever the issue is, it is guaranteed to have nothing to do with CONFIG_MESON_DRM in the kernel.