bertiera please install (or update to) https://chewitt.libreelec.tv/testing/LibreE…85.0-box.img.gz for testing. I've added a device tree specifically for the box (meson-gxl-s905l-venz-v10.dtb) which should get WiFI working at least.
Does the box have power LEDs or power buttons on the case?
Is there an IR remote for the box? If yes, what keymap is used?
Looks interesting and makes sense for industrial users. If it's an official RPi Foundation created module? we can probably get a sample sent to HiassofT who has my Slice3 box in his collection since last summer now. That said, there are now only ~45 Slice boxes showing in stats (down from ~100 pre-Covid) so it's probably not high on the to-do list.
RPi has no native IR capability so needs an additional device with independent power and IR receiver that can control the main power to the board, either by being inline to the normal power connector or through driving power input pins on the 40-pin connector. It is not possible to use a GPIO receiver because the GPIO pins on the 40-pin connector need power before they can receive anything.
Our normal response would be that the 2GB RPi4 is the minimum RPi4, but that's considering 4K support which you probably don't/won't need in a space constrained RV installation. It has newer/better/more-efficient design and considerably more CPU grunt which is always a good thing. It also allows you to run LE10/LE11 so is more future proof (we already dropped support for Pi0W) and you'll have native HEVC hardware decoding. As long as it's not a crazy price it would definitely be an improvement. Then again, so would an RPi3B+ which you might be able to pick up cheaper/easier somewhere. Not as future proof, slower, and similarly 1GB RAM constrained but still a worthy bump.
Some of their containers are deliberately missing from the 'repo' list but I'm not aware that's one of them. There's no harm in trying to use it .. if it doesn't work just rm the container.
I don't maintain Rockchip stuff, but I add boards and such to Amlogic frequently, so:
https://github.com/chewitt/linux/commits/amlogic-5.18.y <= my kernel sources
https://github.com/chewitt/u-boot/commits/amlogic-2022.01 <= my u-boot sources
https://github.com/chewitt/LibreELEC.tv/commits/amlogic <= my LE sources
There are lots of previous examples of devices being added in GitHub.
It will either fix the issue or it won't .. so easy to test and try
LE patches generally follow <package>-<number>-description.patch but it depends on who created them and where they are used, e.g. for Amlogic kernel stuff I'm generating patches using "git format-patch" so things are number sequenced; other maintainers bundle patches together into large sets (which I don't like, but each to their own). Regardless of the naming convention the build-system applies patches in alphanumeric sequence.
If you intention is to submit the patches to our git repo; be advised that we will not accept/merge them unless we can see the same patches on a kernel and/or u-boot mailing list with acks from maintainers, i.e. we will accept a backport of an upstream accepted patch, we will not accept an orphan patch that only exists in LE (else we will never get to drop the patch in a future kernel/u-boot bump).
a) Patch upstream kernel sources to include the dts and build the dtb
b) Patch upstream u-boot sources in include the dts with a u-boot config file
c) Generate patches for the kernel and u-boot changes; ensure those patches apply on-top of existing LE package patches
d) Add patches to the 'patches' folders of either the packages or under projects/Rockchip/devices/RK3399/patches/(linux|u-boot)
e) Modify scripts/uboot_helper to add a device using the kernel dtb and u-boot config file
f) Build the image
There aren't really instructions for this anywhere; GitHub commits serve as 'prior art' and there's a deliberate low-bar requirement for some initiative and general understanding of how distro image building and build-systems work.
There is no recovery script; it should prompt the box to re-read the u-boot scripts (s905_autoscript etc.) which will load the LE kernel file and dtb into memory and boot them. I'd need to see UART (serial console) output to understand where it goes wrong - it's always worked for me and others in the past. WeTek did ship UART cables with the box but I'd expect most folks to have chucked it out by now? - The wetek-play2 image boots the device from SD card using upstream u-boot; but only if the eMMC has been erased (removing vendor u-boot) first, and the best way to do that is booting the device from the box image (catch 22).
Hard to say without seeing a proper debug log file, but the reason why we have written "DO NOT UPDATE, CLEAN INSTALL" all over the LE10 release notes is that add-ons cause issues due to the Python 2 to 3 changes. If you're comfortable at the command-line I'd stop Kodi and rename /storage/.kodi to /storage/.kodi-old and then restart Kodi. You now have clean instance and can clean install add-ons so they work and stop/move-stuff/restart bits of Kodi content to manually restore the essentials like thumbs, sources, databases, add-on settings, etc.
You'd have to track Kodi development to spot the schema changes that result in DB 'version' bumps. If you're using MariaDB the DB versions are now different for K19 and K20 but that only results in you having two active DB versions. You will have to scrap content twice (once for each version) and might end up with occasional differences in content due to changes in scrapers outputting different results, but overall things coexist (in ignorance of each other) and the only thing that doesn't work is tracking of watched/play status. I run in the same way due to ongoing testing and do an occasional "marking things watched" run on the K20 database (as K19 is still the family daily-driver where the changes accumulate). However my kids mostly watch the same stuff over and over so I don't make too much effort to keep things in sync as they'll quickly catch up once K20 becomes the main DB.
bertiera please run "dmesg | paste" from the box and share the URL generated.
The latest iterations of RPi4 board need newer firmware than we ship(ped) some time ago in the LE 9.2.8 image. You either need to run LE10 or venture into experiments with the newer boot files copied to the LE 9.2 image (Start.elf and one other, I forget the name).
Unless you have a really good reason to need LE 9.2, the LE10 codebase is some way ahead and should be used.
Nothing has ever beaten the 85ºC that one of my mk1 AppleTV boxes once reached 
OSMC spent quite a bit of time fixing issues with 3D support in the Amlogic 3.14 vendor kernel but it was never quite as polished as the legacy Raspberry Pi codebase. I've no idea what state it's in with anyone else's patches and code, but I'd suggest you keep an RPi3 around for that duty when you need it.
Enable Advanced or Expert mode.
Forcing the SSH daemon to start requires "ssh" in boot params not "SSH" .. the other one that's useful is "textmode" which will boot direct to a text console on-screen instead of Kodi allowing you to poke around in networking, dmesg, etc.
