Fake RAM size isn't uncommon but it's rare to see 512MB configurations outside of industrial boards, even on older platforms like Meson8. I'd guess you still have the wrong boot ROM for the box and the RAM configuration in early boot code means it's only seeing 1 bank of RAM, and the second (missing) will add another 512MB to give a more normal 1GB.
Then again; this is an era where all kinds of shady manufacturing has been done. If it works and doesn't cause problems; don't fix it 
If you follow the [1] link in the wiki it links to the PR: https://github.com/xbmc/xbmc/pull/21973 .. which shows this is only on Windows.
Does anyone have a solution for this?
Update to (or reimage with) the current LE11 beta which is more than stable and has lots of fixes for RPi blank screen issues. Run "pastekodi" again if issues are not resolved.
video=HDMI-A-1:d
video=eDP-1:d^ Pick whichever connection you want to disable (HDMI or eDP) and add the relevant string to kernel boot params in /flash/syslinux.cfg to disable that output. This assumes you have an Intel or AMD GPU in the laptop. If it's nVidia; there is no GPU support in the Generic image now that we switched to GBM/V4L2 graphics and you will need to use the Generic-Legacy image that heitbaum mentioned.
If it starts with this, your Android is unfortunately only lying that you have 2GB of RAM, but in fact it only manages 1GB.
^ Android hacked to fake RAM size is not uncommon. We even see "Amlogic" boxes with Rockhip boards inside 
You run the command over SSH.
Connect the HTPC to the TV, capture the EDID and setup audio/video as you like. Reconnect HTPC to AVR and use.
As Dr. Spock once said.. "The needs of the many outweigh the needs of the few" and we (still) have no interest in adding IPSec client support for a tiny hanful of people to use. NB: If you have need for VPN to play media remotely WireGuard is a much better option than IPSec and you have either a NAS or general server device at home that can support WireGuard (or a container that supports it) with the router doing basic port-mapping to allow access.
If your distro runs Xorg as the windowing system HDR is not possible (and not likely to change). If it uses Wayland it's possible with the right kernel drivers and mesa for codec, colourspace and colorimetry support, and right now that's more complete with OpenGLES (which is not standard) not OpenGL (standard). And then you'll be challenged by Wayland lacking support for dynamic refresh-rate switching which is essential for a better playback experience. So it's possible, but a conventional desktop distro is probably missing essentials due to favouring stable code over latest code. And even if you pick a rolling and more bleeding edge distro you're probably swimming uphill with a few things to resolve. LE isn't constrained with 'Desktop' requirements so we have it a little easier, but even LE is cannot avoid the reality of Kodi only supporting rather basic HDR things on Linux today. There are PRs on GitHub for some (but not all) missing bits of the puzzle; there are still several unresolved "chicken vs egg" issues between kernel and userspace that need to be addressed. RedHat are sponsoring a Wayland meet-up next month which aims to get enough 'name' developers in the room to agree on a path forwards for the main problems. Hopefully that succeeds, as the discussion has been been rolling on for some time now. Once there is a clear statement of technical direction Kodi developers can plot a course on the missing pieces. Right now Kodi only really supports HDR on Android and Windows; because the underlying OS support HDR and thus we can leverage that. LE is next-best (or least worst) ignoring the existence of some ARM vendor kernels (built for Android) but LE is still dependent on a number of "Work in Progress" pieces that aren't upstream yet, and moving slowly.
About installing to the internal memory, I know it's discouraged from and deprecated, but would help me, at my risk; no queries in case of failure. Is the solution in finding and running the script?
The solution is you coding/implementing support for Amlogic's proprietary partition scheme in the upstream kernel. Until that exists there is no way for the kernel or disk tools used in a script to 'see' the Android /system or /data partitions to wipe and reuse them. Even if someone does port the horrid hack from Amlogic sources it will be refused upstream; because it really is a horrid hack.
This was triaged on GitHub and found to be a missing kernel config option. The change will be applied to the next Pi kernel bump we make; it won't be in LE 11.0.0 (which is already built) but should be in LE 11.0.1.
Run "pastekodi" a minute after boot with the driver connected and share the URL please.
I'm the main author of the HDR/4K content. I'll have a think about something for audio.
Please update to the current LE 11 beta; there are lots of fixes and enhancements for various RPi related screen issues. There will be no fixes for anything found under LE 10 now so best to start fom the current/active codebase.
If you locally mount remote drives the OS is frequently doing something in the background which generates activity and the drives will rarely spin down (and this is not controllable). If you use the SMB/NFS client built into Kodi you might run into client timeout issues (something that can be fine-tuned in advancedsettings.xml) but Kodi shouldn't be accessing the NAS unless scraping or playing and the drives should spin down more frequently. In short; from your description you're doing the former, so it's an expected behaviour.
If you installed add-on's with graphics dependencies under GBM and then swapped to X11 you will need to remove the add-ons, clear the add-on package cache, then reinstall the add-ons; else you will have add-ons with GLES dependencies on a GL platform. The same is true if you go in the other direction.
The main thing I was looking for was SDIO WiFi support (there are some fixes added since 10.95.1) and that looks good now.
I need to find the name of the manufacturer for Vorke to create a vendor binding, then I'll create a proper device-tree file for next test.
Ethernet looks to be working this time. It has 100Base-T speed, but that could be due to cables or switch ports? - WiFi shows more output this time, but still has errors so we might need to reduce the speed of the SDIO bus.
Please update to https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.0.tar and share "dmesg | paste" URL again.
Thanks for the Android dts. It confirms a couple of things that I'll need to prepare a proper dts file.
