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.
Posts by jernej
-
-
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.
-
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.
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.
How well do those Allwinner devices handle fractional frame rates? Are there any issues?
Wasn't that general issue with Kodi?
-
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).
-
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.
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
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.
-
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.
-
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.
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.
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.
-
Do you have any ETA when deinterlacing will be implemented?
No, because driver is not implemented and DRMPRIME Kodi render doesn't support deinterlacing yet. I would say not so soon.
-
riku lumpi another LE developer helped fix IR keymap persistence over reboots. It turns out that 4.20 kernel changed udev behaviour a bit. Now IR configuration should work just as described in LE tutorial.
Lirc driver is included, yes.
AA666 I can include first patch (do you plan to send it to Linux?) but I don't like to merge second one. Reason is that Pine64 doesn't have IR soldered. This is job for DT overlay, which can be done with dtoverlay and configfs functionality included in kernel, but I can't give you any tutorial at this time.
roel I uploaded libretech_h3 image.
-
I just uploaded new update with following improvements:
- included repository with PVR and other plugins
- H265 decoding improvements
- IR fixups (persistence over reboots, Kodi detection)
- Beelink X2 permanent MAC address
- included USB DVB drivers
-
just one short question, what was now the problem? how did you fix it?
I noticed that eventlircd doesn't start due to missing uinput device. I enabled it in kernel config.
my test procedure:
1. Set up my mobile phone to act as a Xbox remote.
2. execute following command through ssh:
Codeir-keytable -c -w /usr/lib/udev/rc_keymaps/xbox_3603. tested buttons up, down, etc. in Kodi
Above worked on internal IR.
-
same message in log, no luck with irw and Kodi GUI
Test this: libreelec-h3.arm-9.1-devel-20181227000522-86dd2d6.tar I found the issue and it works for me now. I guess I'll post new updates tomorrow due to many issues solved.
-
riku Don't worry, I'm just glad that we pinpointed the issue (hardware). Is your secondary H3 board also OrangePi PC? As I wrote before, I have plenty of different H3 boards (but no OPi PC) and CEC doesn't work on all of them (tested on same TV and kernel). I suspect that HW designers didn't test that and it may or may not work.
-
Dont ruin your christmas over the IR issue, for the moment a mouse on a too short wire has to solve the immediate need for control
Don't worry, if I don't feel like solving problems I won't. But currently I want to tackle them
Please try this update: libreelec-h3.arm-9.1-devel-20181226213819-4693356.tarI enabled LIRC interface in kernel. Maybe this will solve it.
-
i have noticed however this odd error on startup "bad crc while load from fat" it anyways work the /storage without any problems from fat... ??!?! look picture
That's normal. That just means that U-Boot will use default settings which is exactly what is wanted. If you would save U-Boot environment, this message wouldn't appear. Granted, it's more scary than it should be. It should be something like "Using default envitonment"...
Can you test with another H3 board?
lumpi I tried another thing for IP address changes. Please update with this: libreelec-h3.arm-9.1-devel-20181226203321-a85ff24-beelink_x2.tar
I'll check IR settings again, maybe I missed something.
-
Orange pi pc
There is a lot of information search in google orange pi pc s/pdif output
Sorry to disappoint you, but unless you edit DTB file yourself that won't be supported. DT overlays aren't supported currently, but maybe something can be done with configfs on linux if you want to play with it. DTB files are overwritten during LE update.
