Posts by jernej

Quote from starsail0r

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.

Quote from dan1234

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.

Quote from dan1234

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.

Quote from dan1234

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.

Quote from lumpi

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.

jack82

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.

dan1234

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.

Quote from lumpi

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.

Quote from lumpi

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.

Quote from smp

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.

Quote from awiniar

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?

Quote from smp

Some hardware is not capable of smooth playback of video with fractional frame rate like 23.976Hz. For example, all pre-Haswell Intel GPUs play 23.976Hz video at 24.000Hz and you get a repeated frame every 40 seconds. AMLogic also had this issue (but AFAIK it was fixed with some kernel patches).

I was wondering if Allwinner hardware is capable of properly displaying 23.976 fps video.

I guess monitor has to support it, fractional frame rate has to be whitelisted and resolution switching at start of playback has to be enabled to actually see if this is the issue or not?

Do you know what is actually the reason why some hardware supports it or not? I imagine it has to do which pixel clocks are supported. If that is the case then there is a good chance it will work. I specially took care that as much pixel clocks are supported as possible with Allwinner DW HDMI driver.

Sorry that I can't be more helpful. Currently I don't have appropriate monitor at hand to test it.

Quote from awiniar

I have a question about Bananapi M2P. This is Allwinner H3. Can I compile LibreELEC for this board?

Can you test this image? libreelec-h3.arm-9.1-devel-20181229171500-417520b-bananapi_m2p.img.gz

If it works, I'll add it to list of supported boards.

Quote from roel

First thing I noticed is that I couldn't configure my remote. Didn't check further what could be the problem as I didn't have a lot of time. I will come back about this later.

IR should work well with very latest update. I'm not sure when I created tritium image, before or after update. Just make sure that you follow LibreELEC Infrared Remote tutorial.

Quote from BleedingYou

This is the error. It's pointing to a non-existing path. I cannot install anything from the Libreelec repository.

I see that you didn't update to latest version. If you would, addons would be taken from amlgx.libreelec.tv Check first post for updates.

Quote from lumpi

Has anyone tried what happens with the H2+? I just figured out there are still some "H3" TV boxes around which used to have an H2+ in the past so better ask first not order first

I didn't try it yet with LibreELEC, but I couldn't find any downside of H2+ compared to H3 in the past. I guess it have lower performance, but don't take my word for it. BTW, I don't want to support any board/TV box which is not in Linux kernel and only TV box supported is Beelink X2. If you would like something else, please send patches to Linux first. As I said before, I don't want to carry patches forever.

Quote from smp

How well do those Allwinner devices handle fractional frame rates? Are there any issues?

Wasn't that general issue with Kodi?

Quote from lumpi

How is it possible you have HDMI audi on H* when sunxi mainlining matrix states a plain bold "NO"? is it out of tree?

Yes, it's out of tree. But there is an effort to mainline it.

No, not really. When I was using BSP kernel I let kernel to upload some firmware blob from Allwinner, which provided suspend functionality and wakeup support through IR.

Yeah, I follow crust development and I intend to use it here for suspend if it will play along nicely (no major changes to linux or U-Boot necessary).

Quote from lumpi

Bootlin and Sunxi usually mention A33 as very well supported and it has a PMIC

Sure, but you'll have to build your own LibreELEC for it. IIRC it doesn't support HDMI audio ATM.

Quote from lumpi

You mention Ampak, on the product page its mentioned Realtek RTL8189ETV, usually a bit of a diva I guess.

I didn't say that this board has it

Quote from lumpi

WRT ESD, I used to be brainwashed about ESD during my apprenticeship in a big electronics company, so I prefer having ESD protecton on rather than taking out my ESD slippers, ESD coat, wristband, waste bags, floor.... you name it

At previous company, we have to devise > 20kV ESD protection because client didn't want to spent few cents for few additional elements. I'm not so paranoid, I have just ESD slippers even though I handle expensive electronic boards.

BleedingYou Can you upload kodi log somewhere? Addon installed fine for me, but I can't test it thoroughly. Did you configure it?

jack82 I installed enigma addon and it blocked Kodi for few seconds but it continued ok. Please upload crashlog.

In general, repository is borrowed from another project (amlogic), which is not ideal. Once allwinner project is merged in master, proper repository will be established. Until then, repository may not work sometimes. Nothing that I can do about that.

Quote from lumpi

what board would you recommend? A64 or H3? are orange Pis to recommend or is the missing HDMI ESD protection a show stopper for a TV Box? unfortunately the beelink X2 is no more available. maybe friendlyelec or ALL-H3-CC (Tritium)?

Just checked the Olinuxino A64, but there all the Ports are on different edges of the board, so no luck putting it in a non customised case. PINE A64+ 1GB looks better in that HDMI, Power and LAN are on one side.

Maybe a Nintendo classic mini with an A33?

A33 is not supported by LibreELEC, so I wouldn't recommend it. Currently, A64 doesn't work as nicely as H3, but it isn't far behind (just some network annoyance, 4K rendering bug and missing analog audio support, which will be added soon). Currently I'm testing on OrangePi Plus 2E, which has ESD protection on HDMI port, contrary to OrangePi PC, and it works nice. Currently there is no support for on board wifi, but AMPAK based wifi chips will be supported in the future. Lack of ESD protection doesn't really matter if you will hide board somewhere and nobody will come near it. However, if it will be often near someone, like when cleaning dust around TV, I recommend having ESD protection. This can be checked on board schematic.

Hard to recommend any board in particular, except that you should take a board with at least 1 GiB of RAM. OrangePi Plus2E is very good board, but maybe a bit expensive for what you want.

Quote from AA666

I would like to apply it to mainline, but it will be long process with some probability of success

It's pretty simple - 2 patches. First should update device tree documentation with new compatible (A64 specific one followed by A13 one) and your patch, updated with double compatible. Both patches should of course have proper title and body and accompanied with cover letter. Third patch can be added with "DO NOT MERGE" tag, where you add IR to pine64, to show how you tested that it works.

This could be great for first time Linux contributor, if you want to go through process yourself. If you don't want, then I can do it instead. Anyway, I don't want carrying patches for too long, especially if they can be easily upstreamed.

Quote from AA666

Actually Pine board has soldered IR header, where you can just insert IR diode. I did it some time ago and IR start to work with original BSP without any further manipulations. At the moment I can't see any drawbacks if we leave IR enabled, but IR diode will not be inserted.

True, but you can say that for other peripherals too (like pine64 wifi) and suddenly there can be a lot of patches which can't be merged into Linux. Linux has a policy, which can be worded like: "If it is not soldered, then it shouldn't be enabled and empty headers don't count.". If you would submit such patch to Linux, it would be rejected with explanation it should be done with DT overlays.

Because I don't want carrying patches forever, I have to go with Linux policy. DT overlays should be already working, but I'll try to find an easy way for handling them. Ideally, it should be as easy as Raspberry Pi DT overlays.

Quote from jack82

H265 10 bit problem

It's not supported by hardware. I'll change it to be decoded in software but it will be probably too slow to be useful.