your switching to libmali and gbm and included h6
just building and will try
There is no HW acceleration and audio of any kind for H6, booting is unstable and HDMI might blink occasionally, so very early stages
a PC2 and zero 2+ are standby
For some reason, there is an issue with mali for at least 1080p resolution on H5. I tried hard to find an issue, but I had no luck. As soon as it is fixed, support should be on H3 level.
hostkit how did you managed to crash Kodi? Was it by using some addon? Currently addons are very unstable.
They will be rebuild for next update and that should eliminate most (all?) addon related crashes.
wifi and temp won't be addressed in near future.
Is there anything speaking against getting a nanopi a64 as a libreelec "player"?
It's powered through microUSB, which is not recommended by me and some others, like Armbian team.
Anyway, board is not yet supported by LE build system, but I think that is easily fixed by one line entry.
I suggest you start from GitHub - jernejsk/LibreELEC.tv: Just enough OS for KODI
1. Add A20 specific subfolder here: https://github.com/jernejsk/libreelec.tv/tree/hw_dec_ffmpeg/projects/allwinner/devices Check H3 subfolder what it has to contain. You can just copy H3 folder as a starting point and check every file what needs to be changed. You have to definitely remove all Linux patches and add A20 specific ones. You have to add patches from Paul Kocialkowski where he added support for YUV (kernel/git/next/linux-next.git - The linux-next integration testing tree - everything from 2018-11-27 and newer) and support for DRM format modifiers (patches are somewhere on some mailing list, probably dri-devel). Remove all U-Boot patches.
2. Enable A20 specific drivers in kernel config: linux.arm.conf
3. Add boards to U-Boot helper script: LibreELEC.tv/uboot_helper at hw_dec_ffmpeg · jernejsk/LibreELEC.tv · GitHub
4. Extend FFmpeg support for using modifiers in V4L2 request codec. But if you come to this point, ping me and me and others could assist you.
After that, there are various small tasks, but most important one - hw video playback, will be already done.
In general, make bootable image first (points 1 - 3). However, to do that, you don't need any Linux patches, so that should be really easy.
What about bluetooth? I see it's disabled?
OrangePi One doesn't have bluetoth on board. Are you using a dongle?
What was the problem exactly?
I just rebuild addon using allwinner project. Currently repository is actually shared with amlogic devices. I though it would work for all addons, but obviously works only for some.
I'll rebuild all addons and soon upload another update which switches repository to those rebuild addons.
BleedingYou can you test this variant: pvr.dvbviewer-3.7.8.2.zip ?
thanks for images, but there is no possible to add wifi driver for Pi Lite?
It is but not something worth doing. Realtek drivers are pain to maintain and with different wifi manager in LE10 it won't work anyway. Besides, Lite has only 512 MiB of RAM, which means it won't be maintained for very long. At least not actively.
Do you have plan to add script?
At some point. I want to fix some decoding issues first.
New updates are uploaded for H3 and A64:
- rebased on latest LibreELEC master (notably Kodi 18 RC4)
- A64 analog audio is now supported
- HDMI CEC fixes added (not necessarily stable)
- new A64 board is added - OrangePi Win
- support for AP6212 WIFI (OrangePi Win, BananaPi M2+)
- USB is now disabled in U-Boot, which is a workaround for times when connected USB device prevents booting.
NOTE: U-Boot is not updated with image updates linked in first post. U-Boot is board specific, which means that update file would have to be board specific too to also update U-Boot and that is just not feasible with so many supported boards. But you can pull sources and build your own board specific update or even clean image.
what is the situation of i2s
It works, otherwise HDMI audio wouldn't work.
However, if you mean external I2S codec, that doesn't work out of the box. One of the rules of mainline Linux is that don't enable peripherals which are not used by the bare board. This would mean that I2S is not enabled by default on expansion connectors.
In future, there will be support for overlays as it is done in RaspberryPi case. Currently, you have to edit DT yourself, either by decompiling, editing and compiling existing DTB or creating a kernel patch and building image on your own. Possibly you would also need to enable codec driver in kernel.
On my Orange Pi PC (with LibreELEC 9.0) I can't configure the IR remote!
You are probably using old image where IR was not yet fixed. First post has a link to updates which you have to apply.
I don't have a device /dev/lirc......
And the modules sunxi_ir_rx and gpio_sunxi are not loaded:
/dev/lirc is not preferred way. sunxi_ir_rx and gpio_sunxi are from old, 3.4 kernel, mainline uses different drivers. Besides, IR driver is built-in and is not a module in LibreELEC images.
How can I enable onboard IR device?
First, update image to latest as I mentioned before and then search for official LibreELEC Infrared Remote wiki page where everything is explained.
While looking for hints I found a DT overlay I hoped I could steal from - sunxi-DT-overlays/gpio-button.dts at master · armbian/sunxi-DT-overlays · GitHub it even maps the button to KEY_POWER, but not sure how to bend it to fit (PL3) and if overlays work in LE.
Then I hoped to find more hints in this nanopi DTS - linux/sun8i-h3-nanopi.dtsi at 6f0d349d922ba44e4348a17a78ea51b7135965b1 · torvalds/linux · GitHub
Now I had two examples, which looked very dissimilar to me :-S
NanoPi DT is the correct example for your case. Note that overlay syntax is a bit special so don't look at it if you are new to this. Some remarks:
1. Port L and H are special, since they reside on different GPIO peripheral than other ports with lower character. In DT, this special GPIO peripheral is named r_pio.
2. "<&r_pio 0 3 GPIO_ACTIVE_LOW>" means PL3 pin (port 0 on r_pio is PL)
3. "r_" prefix means secure in AW documentation. Sometimes they use "s_" prefix with same meaning.
4. just copy over that NanoPi example, it uses same pin for same purpose. You should just change name where appropriate.
1. CEC is supposed to turn off TV when Kodi is turned off
2. Addons are not my responsibility. There is newer version of Enigma2 (pvr.vuplus) addon in source form. You can compile it yourself if you think it will help.
3. I'll disable USB in U-Boot. That should also speed up boot.
4. H265 decoding is not perfect, that's known. 10 bit is NOT supported at all by hardware. Nothing I can't do about it.
5. Is this passthrough by any chance? It's not currently supported.
It's not meant to be everyday driver. Old OpenELEC is currently better, but hopefully not for long. As I said 1000 times before, 10 bit can't be supported except by software decoding.
I don't know if wake-on-lan is actually supported in the driver or not. Anyway, once OrangePi PC or any other supported board for that matter is turned off, there is no way to turn it on except to do a power cycle. Power button is connected to ordinary GPIO pin on SoC, which just give a signal that it was pressed. If CPU is powered down, nobody will process this signal.
This could be solved only with monitor firmware on auxiliary AR100 core, which is exactly what is done by Allwinner provided solution. However, that firmware is unusable with mainline kernel. There is an effort to create suitable replacement which works with mainline (crust-firmware), but it's not ready yet and currently supports only 64-bit SoCs.
There might be a way to have similar capability with current software. If power button is defined as a wake up source in DT, suspend could be used instead of shutdown. But this needs some work.
I was playing with the power button (again on beelink x2), which according to armbian fex should be PL03, so gpio355 in sysfs.
Yes, that's correct.
Is there missing something from the DTS?
Sure. DTS is filled by enthusiasts when they miss some functionality otherwise supported by board. In this case, nobody missed power button.
awiniar That's pretty detailed Thanks for testing.
I believe this has something to do with the clock generator logic.
In other words, pixel clock support. So IMO it should work, but don't take my word until it gets tested.
I found one problem with wifi. In lib/firmware/brcm symbolic link brcmfcmac-sdio.txt shows to wrong file. Before change link to brcmfcmac-sdio.AP6212.txt wifi works perfect.
Yeah, wifi is not priority ATM. Do you see any issues with items listed as supported in first post? Can I mark BananaPi M2P as supported?
