video=DSI-1:800x480@60,rotate=180^ I believe this needs to be appended to boot params in cmdline.txt so it impacts the kernel driver (the new way) not config.txt which controls pi firmware (the old way). Many pi firmware commands are deprecated with the move to the kernel DRM graphics pipeline.
I can't remember the last time that I booted a Cubox-i board (almost certainly not this year) .. so I doubt anything changed.
One of the Kodi mirror servers is borked. It's being worked on, but no ETA.
RPi4 will be a nice increase from the Slice CM1 (RPi1) or CM3 (RPi3) performance. It will be easier to do a clean install at the latest version and then selectively import bits of old config as needed. Kodi often benefits from the clean(er) start or spring-cleaning.
GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:F3;SD:800;USB:8;LOOP:1^ This is good, it means eMMC is fully erased (and the board is not bricked, it's simply missing software). You can now boot the board from an SD card .. as long as the SD card has a working u-boot in the correct places. The LE "hub" board image has everything needed although the catch22 will be that you're likely to hit the same problem with serial UART noise. Perhaps try writing the factory image backup written to SD and see if that's found (it might not be since it's an eMMC backup and S905 puts magic boot headers in different offsets for eMMC and SD) but even if it fails at booting into Android it might get you to a recovery console or perhaps the vendor u-boot console.
If the AMLGX image works for you, that's great. If it doesn't work for you, don't expect anything to change. I've done zero work on Amlogic hardware since April and have no plan to change that until someone shows up with new hardware decode drivers. Comparisons with CE are irrelevant due to 100% of the media driver code being different.
Uncompression can fail due to random Windows crappiness and lack of space on the /storage partition. Otherwise there is no need to unpack the file. Issues with copying files around are avoided by doing what I suggested: SSH into the box and wget (download) the file directly into the update folder. See https://wiki.libreelec.tv/support/update
Is this to be expected at this stage? Where can I find a "known bugs" list?
Maybe, it all depends on the media being played .. and in the release notes that I write and nobody reads.
You need to connect a USB > serial UART cable to the board. If you don't have one they are dirt cheap from Amazon.
https://wiki.odroid.com/odroid-c2/application_note/gpio/uart <= where to connect the cable board side. You also need a 'serial' app for your normal desktop/laptop computer OS .. there are lots of videos on YouTube for that.
The output will show whether the board boots at all, or boots and gets stuck somewhere.
It's not a Kodi debug log (or crash log) so it doesn't show anything interesting. Clean-boot with debug on and reproduce the issue.
What kind of USB devices? .. and what LE version?
Share the UART output from the failed boots.
In my case once the UART pins were resoldered I don't see noise and it boots without getting stuck (the other user forced a pin to 3.3v which had a positive effect). So I didn't need to short eMMC pins on the Hub (but have done that on Play2 and some other boxes before).
There are two more options I can think of:
a) https://github.com/superna9999/li…DMI-Boot-Dongle <= but this requires hardware you don't have (and a little $) and will take a while to arrive if in-stock or you have to order parts from China to self-build.
b) I forget the commands, but it's possible to enter the u-boot console, select the emmc device:partition and then erase a block range on the device to remove u-boot. Once that's done the boot-rom will fail to find u-boot on eMMC and boot the LE board image from an SD card (from where you can dd the factory image).
Moved to the RK section
The FLIRC case is a great case, and does look/feel fab.
Arghh.. I always forget that late model versions run newer silicon. My bad 
RPi0/1/2/3 are 32-bit SoCs so all past/present/future releases are 32-bit kernel and 32-bit userspace. RPi4/400 are 64-bit SoCs and <= LE 11.x are 64-bit kernel with 32-bit userspace. LE 12.x will use 64-bit kernel and 64-bit userspace. The same is true for other ARM SoC vendors where we have historically and/or still do support a mix of 32-bit and 64-bit SoC hardware. Generic LibreELEC releases have always been 64-bit (OpenELEC dropped i386 support @ after v5.0).
Over time the number of people confused/offended by our lack of publishing specific information on kernel vs. userspace arch is remarkably small, so I wouldn't over think the number of references that need to be made.
