It depends on HW, specs don't tell enough details. Anyway, most H6 TV boxes are similar and based on ethernet speed, Tanix TX6 image will most likely work for you, except maybe TV remote. Customizing remote requires custom build (to be able to wake up), but it's not that hard.
EDIT: Try first with SD card. If it works, you can overwrite internal emmc with LE.
There are two different wifi chips on that board. One is supported and another is not. Please provide output of dmesg. It should be possible to tell which wifi you have.
H616 is not supported yet by LibreELEC. H6 is best supported SoC, but random TV boxes are not, although one of the existing images may work with them.
I'm glad you managed to make it work. DT can be tricky at times, as you very obviously experienced.
Those parameters are not relevant for LE. Armbian has some custom extensions ported over from RPi kernel. One of these allows to have parameters for overlays.
No, there is no DT bug. It's customary to have two pin groups, one for communication pins (MISO, MOSI, SCK) and another for CS pin. CS pin can be basically any GPIO pin, not only that from SPI controller. You should actually use PineH64 DT as an example - along with SPI pin group you should also specify additional pin group for CS pin in your overlay.
Note, we don't accept Linux patches unless they are either reviewed on some Linux ML and are on it's way to be merged or, in rare cases, work in progress patches maintained by LE developers themselves (even such patches get merged in Linux eventually).
opi-tools is not LE provided addon, right? Anyway, what part of these addons you need? rpi-tools contain RPi.GPIO, gpiozero, colorzero and lan951x-led-ctl package, which are all RPi specific.
Well, in the post RE: How to enable spidev interface on SoC Allwinner? you give a screenshot with a lot of errors printed. Does that still happens?
Anyway, probably there is common issue in LE10, which prevents SPI to work on both kernels. I currently have no idea what could be wrong.
I obviously missed the fact that HW SPI driver wasn't even enabled on 64-bit kernel. I opened two PRs: https://github.com/LibreELEC/LibreELEC.tv/pull/6655 and https://github.com/LibreELEC/LibreELEC.tv/pull/6656
I have no idea why it doesn't work on LE10 H3 image. Can you confirm that you actually get other issues like those described before?
There are also LE10 nightly images nowadays: https://test.libreelec.tv/10.0/Allwinner/ Please test if it works for you. If it doesn't, some PR probably caused an issue.
Do you have serial adapter? If so, please check if U-Boot complains anything about overlays. Another useful thing would be to upload /sys/firmware/fdt somewhere. It is basically dtb file used by the kernel. Decompiling it should show if overlay was applied or not.
I suppose i2c0 overlay works correctly? Everything looks good, but I'm no expert in overlays, especially with old syntax. Armbian applies much more kernel patches than LE, so that's one possible answer. Another would be kernel config, but that we hopefully fixed adequately.
Oh, there is another possible issue. Can you tell me how do you apply overlays?
Kernel configuration is already updated for LE10 and LE11 (merged few minutes ago). Either wait for tomorrow LE11 nightly image or build LE10 image for yourself.
How do I understand that? This means that for H3 there is no chance for it to work in LibreELEC (in Armbian it works!).
Yes, with current image there is no chance to work. Kernel config file needs to be updated and image rebuild.
I just noticed that CONFIG_SPI_SPIDEV is not even enabled for 32-bit AW SoCs, but it is for 64-bit. So it should work on H6, but not on H3. Not sure what problem you see with compatibles - all 5.10 versions I checked have same compatible array.
Armbian has a patch that adds "spidev" compatible to the spidev driver. LibreELEC does not, because such patch has no chance of being included in mainline kernel. However, you can still achieve same effect by using one of the compatible strings listed in spidev.c (https://git.kernel.org/pub/scm/linux/…=v5.10.124#n669).
Edit: It seems that "spidev" compatible is invention by RPi kernel. Please don't rely on it.
- in other words: can I decide from two given hashes which is the elder and which the newer one ?
Based solely on hashes, no. You would need to check git repo which is newer. Hash is just some hex number, calculated from data. In fact, from security perspective, you should not be able to infer any useful information from hashes alone.
EDIT: To be clear, hashes are taken from git commits, we don't have any control over them.
There is not such thing as generic boot image. While file system and kernel are same for all H3 based boards, bootloader (U-Boot) is customized for each board separately and this fails in your case.
