Last time I've checked there was "only" kernel 4.14.y odroid-xu4:software:building_kernel [ODROID Wiki] but anyway more recent than the outdated AML stuff.
I have no experiences with the XU4 but found this https://lists.fedoraproject.org/archives/list/[email protected]/thread/ag2ybn6kpnmxxdvuuxbisb37724xvfwk/ so you probably can use fbset to apply some geometry settings.
Here's the 5.0 tree: GitHub - mihailescu2m/linux at odroidxu4-5.0.y
XU4 is on 5.0 already. Looks like fbset can do what I need. My cabinet screen has 1280x1024 resolution, you know if I can configure this resolution with 50/60Hz through the sys interface?
N2 seems to be stuck on 4.9 kernel with fbdev. I suppose XU4 might be a good choice, or simply take the step up to a NUC7PJYH or ITX solution. I want something faster than an RPi3 in my arcade cabinet.
Another thing with the ODROID's is refresh rate switching. I think it's set at boot time and there's no such thing as "tvservice". Perhaps it's possible to build with Xorg and use xrandr, but I'm not sure. Need PAL mode for C64/Amiga and a reboot is too clumsy.
Did you ever try TARGET_FPU=neon-fp-armv8 and vc4 driver? Wonder if aarch64 is possible at this point, anybody done some research?
Will be looking into RPi builds again while waiting for my arcade cabinet to be built and shipped. Or I might just get an ODROID H2.
5schatten, a though concerning Spectre & Meltdown vulnerabilities... It's a known fact that related patches for the vulnerabilities are slowing down an OS.
I know those patches are crucial for hosting companies for obvious reasons. As for LibreELEC we basically have just root user so I feel like it's useless to have them enabled.
You can disable them with kernel command line options: Linux kernel gets another option to disable Spectre mitigations | ZDNet
Never heard of issues with -O2 in general.
The Performance Between GCC Optimization Levels - Phoronix
-O2 is faster, there is IMO no valid reason to use -Os over it unless you are running out of space on /flash.
You need to look at TARGET_CFLAGS which includes GCC_OPTIM: LibreELEC.tv/optimize at a98586ba336e1d396e8f6c95bae42106ec9113ac · LibreELEC/LibreELEC.tv · GitHub
So the default is still -Os.
Of course, even RPi can run arcade games at full speed, this will only matter in cores like Citra, reicast, ppsspp and the likes.
Here's a recent compiler optimization benchmark: GCC 9 Compiler Tuning Benchmarks On Intel Skylake AVX-512 - Phoronix
They conclude with -O2 being the most effective option, although as you can see applications like C-Ray greatly benefit from more specific tuning. As far as I understand it, the AVX optimization of the compiler does not depend on the application itself utilizing AVX.
Would be interesting with some actual benchmarks of emulators, haven't bothered with it myself (is there a good way to do benchmarks with RetroArch?). I think there's definitely a benefit, but most likely nothing you'd be able to spot with your eyes. I really should just buy a new computer instead of obsessing over optimizations
I've commited the last of my local work today and uploaded a "final" LE8 version (albeit for avx2 only at this time). Changes include gcc 8.3.0, glibc 2.29, mesa 19.0, linux 5.0 and updated versions of most of the emulation stuff. Except for still being Kodi 17, it's pretty up to date I only use Kodi for LE settings and launching Emulationstation these days, I still might look at rebasing on LE9 but it looks like 5schatten is doing a good job on that. Probably time to have a look at the status of Recalbox as well, looks like they have done a great deal of work on integration and polish.
I agree, the Chinese chipsets can be quite quirky. It's nearly 2019, forget about Atom x5. Go for the NUC 
Still the big image size problem, but maybe you're right...
Linuxbrew vs guix? Guix is full ready to use for linux. Compiled packages already done.
Binaries are available for Linuxbrew as well, called "bottles".
Theoricaly, it is as simple as it seems. If you want to install guix on a distribution you need 1 compile it, 2 enable the deamon. And then you can install what you want in userspace with shared libraries instead of root system space overrides.
Practically, you're wrong. LibreELEC doesn't have fully fledged util-linux, but uses instead busybox. There's no bash. There's only a root user and not possible to add users. There's a read-only root system. I understand that you can install GUIX in a separate location, but I'm quite certain that you will run into issues with the mentioned limitations. The binaries themselves will run, but the daemon and scripts to start etc will fail. Come to think of it, Linuxbrew will probably have some issues as well.
I do agree though, LibreELEC desperately needs a proper package manager. Personally I have tons of tasks for my living room HTPC. Most of them unrelated to Kodi.
Flatpak/Snap might be better alternatives. Someone should look into packaging one as an addon (or simply integrated into LibreELEC). I might, but probably not in the near future.
I think adding a package manager would mean more work than you think. You can't just plug-in a package manager from a different distribution and use their package repo.
A more approachable way (perhaps) to extend LibreELEC would be to create add-ons for GCC and the rest of Linuxbrew's few dependencies, which would allow you to compile the many packages available for Homebrew.
Or just properly learn how Docker works, which doesn't really take that much time. Then you can containerize whatever distribution you like and install any package available.
Haven't bothered, there's been many benchmarks through the years. I believe the performance gain is up to 10% but will vary depending on the type of application. I just figure since I'm building everything I might as well build for my specific CPU.
I'm on 4.20 now haven't tested PCSX2 in a long while will see if I get the time over the weekend.
It's really just changing TARGET_CPU to "haswell", so that gcc gets passed -march=haswell.
I had those cherry picked before, but they were upstreamed with glibc 2.27.
No, I use mt-32 emulation for midi.
I do ship with NFS kernel server, check out the nfs-utils package.
ALSA should work in 100% of cases, which is why creating an asound.conf should be all that's needed. The latest generic build might have the bug mentioned by 5schatten though which leads to a corrupted retroarch.cfg. Not sure, but I'll do a rebuild soon and upload that. My latest avx2 build is updated though if you have a CPU not from the stone age.
You need asound.conf.
Tell me what to change in the python code to accept arguments and I'll modify it. As 5schatten points out, there's nothing stopping you from creating your own scripts to use with launchers etc as well.
Yes, I read about those plans but I don't think anyone has been willing to actually work on it. The internal scraper works good enough now, and it supports some systems that sselphs' doesn't. It doesn't support video previews though. RetroPie uses scripts to set it up indeed.
