First read the LE11 release notes so you understand the limitations of AMLGX on an S905X3 board. Then (as per the notes) read the Amlogic boot instructions in the wiki: https://wiki.libreelec.tv/hardware/amlogic - there is no specific device-tree for that box but pick another SM1
Android box and it will probably work (they are all fairly similar).
gonp that kind of confirms the issue is noise on the UART pins. Have you tried resoldering the UART pins?
LE10 uses wpa_supplicant. LE11 uses iwd. I'm not sure knowing that helps, but it probably explains the difference.
Make a backup .. then update to 11.0 via the settings add-on. This avoids the need for clean-install and restore. If (and only if) something goes wrong you have the backup to restore back to 10.0.
P200 is for internal PHY boards with 10/100 Ethernet. P201 is for external PHY boards with Gbit Ethernet (like your box). Cold boot the box with Ethernet connected, then SSH in and run "pastekodi" and share the URL generated so I can see the boot log. This will show if any WiFi drivers and firmware are being loaded (or not).
You should read the LE11 release notes. These clearly state the AMLGX image is not perfect; although it works well with most normal media and codecs but some users have odd content and it might not suit them. They also tell you there is no support for internal DVB cards. I'd need to see debug logs to make any further comment on playback issues. Run "pastekodi" after clean boot and enabling debug logging and demonstrating problems.
All files under /storage/.kodi should be owned by root and except for specific files under /storage/.kodi/addons nothing should be executable; so a simple find/exec command setting 644 permissions but excluding the addons path should work. As a general rule permissions are not something that should end up being changed though, so I wouldn't waste time creating script tools. And that's probably why I've never seen them being created.
0.000000] Linux version 4.19.62-sunxi ([email protected]) (gcc version 7.4.1 20181213 [linaro-7.4-2019.02 revision 56ec6f6b99cc167ff0c2f8e1a2eed33b1edc85d4] (Linaro GCC 7.4-2019.02)) #5.92 SMP Wed Jul 31 22:07:23 CEST 2019I think you've pasted the wrong log .. becuase all I can see are Armbian boot logs (Armbian issues are theirs to solve).
Put https://chewitt.libreelec.tv/testing/LibreE….arm-11.0.0.tar in /storage/.update and the WiFi might work. The RTL vendor driver is not in the upstream LE image and I have no plan to add it.
Well it seems my artifacts were an artifact. Cannot reproduce them anymore. I restored the backup I made of Nexus so it is just as I left it last time. But now, no artifacts anywhere, not even the files I tried last time.
Maybe chatGPT-4 can solve the HEVC seeking problem
Then again, it might soon rewrite the entire video driver.
I'm confident there are memory useage/buffering issues in the current HEVC codec, and ultimately there are closed-source firmware blobs involved that can layer their own issues too.
ChatGP is quite interesting but linux media drivers are rather complicated. As Douglas Adams fans will appreciate; the challenge is about asking the right question 
Why does Kodi "Leia" have no problems with HEVC seeking ? What is different to Nexus ?
LE11 uses the upstream Linux kernel that has no code in-common with the LE9 and older vendor kernel. As written in release-notes; AMLGX is not perfect and will not be for all users. I'd love to see improvements to HEVC seek, but I don't write driver code, and there's been a multi-year gap in anyone taking an interest. I'm currently attempting to get the (abandoned but cleaned-up a little) HEVC driver merged upstream in the hope putting the code somewhere public attracts some community contribution.
There's no such thing as "too powerful"
Either the configuration expects files to be in a standard location and you've put them somewhere else, or you configure the location in the add-on (which I don't use or have any experience with) but some kind of unhandled issue with paths or formatting or permissions prevents the files from being read. As generic advice; don't use paths with spaces, ensure the text files have unix line endings (not Windows) and ensure the certs have 600 perms not 644/755/777.
S905L is an S905X without VP9 support, 10/100 Ethernet, no BT, and faked 2GHz CPU (all GXL boards are 1.5GHz). There is no direct support in the upstream kernel but differences from S905X are minor so creating a custom device-tree shouldn't be hard; I started to look at changes for the Venz V10 - though that user disappeared so progress stalled. NB: The current hardware decode drivers assume all GXL boards support VP9 so attempting VP9 media playback will result in blank screens in Kodi.
P201 is a GXBB (S905) device-tree; hence it will not boot a GXL (S905X) derived device. SSV6200 is a newer variant of the SSV6051 chip and also not supported. The SSV vendor drivers are horrific quality (achieving new depths of bad) and do not compile against an upstream kernel, only the vendor kernels. No support means no support.
If you can provide me with the Android dtb file and dmesg boot log, and a working remote control config, I can look at adding support.
The second partition on the SD card is designed to self-resize on first-boot so there is no need to "fix" this non-problem. Just create an SD from the box image and set the dtb name in uEnv.ini .. and that's all to do. As per the Amlogic page in the wiki; do not rename dtb files to dtb.img; do not change the location of files.
When DRM Prime is enabled I can't skip the video for more than 10sec without the picture freezing. Sometimes pressing the ESC button brings back the menu but it also happens that I have to reboot. When DRM prime is disabled skipping is no problem but the video is kinda choppy - not really smooth.
I assume the codec used is HEVC and thus the clearly written statements about the imperfect state of HEVC seeking that are in release notes are accurate. If the codec is H264 seeking works well (at least in my own testing). One of the upstream kernel static analysis tools recently flagged a memory leak in the HEVC codec and a fix for this will be in LE 11.0.1. That might help prevent resource starvation in some scenarios (stop/escape back to the GUI is more likely to work) but HEVC seeking itself needs development effort, and there are currently no volunteers for the task so you shouldn't expect progress anytime soon. If you disable DRMPRIME content is software decoded, but most 1080p HEVC is a little beyond the CPU capabilities of an S905 board. The Pi Foundation devs are currently working on some changes that might result in a more efficient software decode path that might improve that, but fixing the hardware decoder (needing volunteers) would be preferred.
