can you pass the command used to build it?
PROJECT=Allwinner ARCH=arm DEVICE=H6 UBOOT_SYSTEM=orangepi_3 make image
I fixed ethernet reboot issue. Bluetooth actually works, if you manage to change MAC address. I have to figure out how to do this best.
This branch will be PRed once I figure out why PineH64 is broken with OPi3 patches.
natumbri please test this image first: libreelec-h3.arm-9.1-devel-20190605004918-cdc4ec0-nanopi_m1.img.gz
If it is good, I'll ask to include this board in nightlies.
just wondering if you've been able to add the nano pi M1 build, at this stage?
It's in master, so now I have to ask to add it to nightly builds.
I also test different video resolutions and looks like only 1080p is affected with no HDMI sound.
If you switch back, does it work or not? It may be only notification issue.
Does this mean, HDMI passthrough is working if the issues are fixed?
No, passthrough is separate effort. Currently you might get lucky to get it work, but I wouldn't count on that.
Anyway, can anyone tells me what is so special on passtrough? Does it really matter if audio is decoded on SBC or AVR side? After all, in both cases audio is digitally transferred, so no loss of precision occurs.
I have been on holiday and will be back later this week to work on the Tanix TX6 H6 box.
Good. I hope you rested for DRAM driver work, which can be frustrating at times.
Hello.
As an addition to my issue with Audio not working on HDMI OPPC+: As I read all posts on this forum I notice solution to change resolution 1080p to 1080i.
Strange! But when I changed from 1080p to 1080i audio start working on HDMI and looks like HDMI Pass Trough is working also.
HDMI Audio related stuff in kernel will get rewrited in order to be acceptable for inclusion in mainline kernel. Hopefully rewrite will fix such issues and not introduce new ones. We'll see.
Can you test if changing in any other resolution also solves the problem?
I prepared initial OrangePi 3 support. Initial image can be found here:
libreelec-h6.arm-9.1-devel-20190603225103-f3b379f-orangepi_3.img.gz
Sources can be found here:
GitHub - jernejsk/LibreELEC.tv at aw_linux_patches
Known issues (apart from those in OP):
- ethernet doesn't work after reboot (physical power disconnection is needed, probably PMU related)
- bluetooth doesn't work (probably wrong firmware)
* The Orange PI PC device tree operating points table has only three states, and the fastest is 1.0 Ghz. As far as I remember, the SoC was supposed to run up to 1.5Ghz @ 1.3volts
Yeah, that's mainline issue due to missing temperature monitor driver. 1.5Ghz @ 1.3volts is actually already a overclocking, more like 1.3 GHz would be maximum. Anyway, you don't need any of that extra speed if you watch videos which are HW decoded.
* There is no cpufreq driver built in the kernel. Is it expected?
I have to check that.
* About CEC, there is a Kodi thread that apparently is using a lot of cpu time related to CEC. Doing a strace over it seems to continously scan the /sys directory in search for something and never stops. Maybe there's something missing to let it find the proper CEC device to listen to
Can you check if this is related to tinkerboard: disable 5s polling for CEC adapters by viulian · Pull Request #3506 · LibreELEC/LibreELEC.tv · GitHub ?
I have somewhere an inet97f2 tablet based on A10 with some old fedora on it, should i have a look for it?
You can, but in this case kernel config needs to be tweaked, to enable A10 drivers. You can try it based on my A20 branch here: GitHub - jernejsk/LibreELEC.tv at a20 (check last 3 commits)
However, I think it would be best to fix A20 support first.
I know it's pretty OT but such tablets would also be a target for a completely free mainlined android,
that's still not possible, but should be close. I think lima drivers needs to be improved? I don't really know.
You nicely summed up all known issues. BT2020 will be hard to implement - display and VPU drivers are missing BT2020 support for now. Currently all 10-bit HEVC videos are decoded as 8-bit.
Regarding audio, this is outside my expertise, but I'll take a look into it once.
I'll try to dig one out. It may have been a 10bit HVEC
That's possible to decode only on H6 and even then only with my WIP patches. What about videos not filling screen? Sample for that would be appreciated too.
"Green screens" on some HVEC videos
can you provide sample video?
Here is test image for PineH64 with working 10-bit H265 (HEVC) decoding and HDR output:
Build from:
GitHub - jernejsk/LibreELEC.tv at hdr
I suggest you put it on separate SD card because it will took some time before all needed patches land in LE master. I wonder how well it works for you.
Any chance of adding a build for the NanoPi M1?
Yes, but note that only version with 1 GiB of RAM will be supported. If you have 512 MiB version you can still use same image, but I don't accept bug reports which occurs due to memory consumption. Which version do you have?
I'm only surpised that H5 is missing here. Is there any reason for it?
Yes, it is. It has different GPU than any other SoC. Even drivers from other companies which use same GPU are not compatible with it. Workaround exist, but adds additional processing for every image rendered, which is far from ideal. This platform waits on Lima to become good enough to be used instead of binary drivers.
Two additional problems were observed - HDMI CEC is not working at all and image is unstable (freezes), maybe because of GPU driver hack or maybe RAM driver issues or maybe something else entirely.
I have also one old image LibreELEC-A64.arm-9.0-devel-20181220210336-147ea78-pine64_plus and this one works fine
This works because it is correct image for your board - note the "plus" in it's name. For some reason nightly image for Pine64 Plus isn't copied to download server (similarly as OrangePi Plus2E).
Due to a lot of problems with nightly builds, I'll probably build images now and then and linked it in OP.
2. The second one was converted from MPEG4 to HEVC1 with default parameters. After trying to play it, the sound starts to play and the system immediately reboots.
Kwiboo solved mystery with your video sample. It won't crash with very latest Kodi, but unfortunately, LE build system uses a bit old version. Not sure when will it be updated. However, it still won't be correctly decoded (blank screen). Your video uses RGB color space in GBR format (just color order is changed), which is not supported by Kodi's DRMPRIME renderer nor with HW video output. To properly display it, additional work on Kodi and maybe also on display driver is needed.
It's strange that default conversion used RGB color space. YUV is much much more common.
