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.
No. Most likely DRAM driver driver doesn't work. If you have serial to usb cable, you can try to find correct connector on board and connect it. That way you can see how far boot comes. If it's really DRAM driver, chances are basically non-existing to do anything. Unless, of course, if you know software reverse engineering techniques, but in such case you probably wouldn't ask these questions.
Disclaimer: We don't support random TV boxes based on Allwinner chips. That being said, it might work with existing image. So which image did you use? And by "installing" you really mean installing with install2emmc script or do you mean booting from SD card? You also didn't provide enough detailed photos - most interesting things are markings on various chips but we can't read them.
Nope. While basic Linux support is slowly materializing, two major blockers are still at the same spot - HDMI audio (no useful driver) and bug in display driver (big code change may be required to fix it).
oddebian thanks, but unfortunately everything checks up. I sporadically managed to reproduce the issue on my own builds, which is improvement. However, even with all minor differences ported from BSP driver, issue was still there. I'm not sure it's the driver issue anymore.
oddebian I have exactly the same board, with same markings on the board. So it must be something on SW side. I did few more tests with official LE 10.0.2 release and I managed to get corrupted deinterlacing only once. However, it stayed corrupted also over reboots until I plugged off power supply for few seconds and plugged it back on. After that, I couldn't reproduce it anymore. So it must be some issue which persists over boot. Maybe some clock setting. Can you provide output of cat /sys/kernel/debug/clk/clk_summary, executed during bad deinterlacing?
EDIT: I managed to reproduce it once on latest, self-build image. However, reboot restored deinterlacing.
As i had Orange Pi3 in mind which has a H6 CPU, for which you mentioned above it does HW.
Yes, of course. My brains don't work for some reason.
Pi3 doesn't decode HEVC in HW, it just have extremely optimized SW decoding, but only in LE9.2 and lower, not LE10. I'm not sure what is 10-bit HEVC performance.
oddebian Currently I can't think of any data that would help in narrowing down issue. Sadly only way to fix it, is to reliably reproduce it on my development system, but I don't have any success with that.
Oh i thought thats just the name of the decoder(DRM Prime) , and not realated to Amazon. Today i learned :).
Ah, sorry, brainfart on my side. DRM prime is really a decoding method, you're right 
Anyway, I'm pretty sure you tried to watch 10-bit HEVC and H5 doesn't have appropriate core neither to HW decode nor HW render it. H6 does, so it will be very low CPU utilization.
You can use mediainfo addon, which shows basic information about video file.
