1 1
jernej

H3 kernel repo

Recommended Posts

Would be anyone interested helping me collecting or making kernel fixes for H3? I already collect some fixes here:

https://github.com/jernejsk/linux

 

Question remains what to do with out of tree drivers like mali and wireless. I will probably add those which can be found in most SBCs. Igor, what is the plan with mali driver? Would be r4p0 acceptable? Userspace libraries can be found here.

Share this post


Link to post
Share on other sites

Zero feedback so far isn't that much so at least a minor comment: I really like the idea and by looking through the commits I feel you're doing it absolutely right and I also think we all (read as: not just Armbian and your OpenELEC fork but all the others trying to use legacy kernel with H3) will switch rather sooner than later to this fork/branch.

 

But at least I lost somehow interest in legacy kernel in the meantime since for my use cases only THS stuff in mainline kernel is missing (Ethernet works already okish and if performance with GbE further improves even better).

Share this post


Link to post
Share on other sites

I don't see any downsides for having a maintained repository for H3 legacy kernel.

 

I can help with testing built-in wireless or anything device specific on different Orange H3 boards if it is needed.

 

Igor, what is the plan with mali driver? Would be r4p0 acceptable? Userspace libraries can be found here.

Desktop part of Armbian is not actively maintained right now, so I guess anything that works is acceptable.

Share this post


Link to post
Share on other sites

Thanks for at least some encouragement :) While you (tkaiser) are absolutely focused on headless systems, others might be on desktop/graphics. So at least for them this will be interesting for a while. I will join you with maintaining desktop version shortly. If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on and I can help you with squashing some bugs in the meantime. Currently I'm a bit short on time, but I will contribute for sure.

Share this post


Link to post
Share on other sites

If I want to make Kodi working with libvdpau-sunxi, Armbian is much nicer platform to develop on

I am sure a lot of people are waiting for this :) and will be grateful. Armbian is great platform, but with H3 specifically, there are a lot of issues with multimedia part and this should be the main target of this boards. That's why i currently using my router A20 board for multimedia, as it have less issues, which is weird. For example - mpv player works very well and as part of smplayer, even better, but subtitles support through pixman (because of missing g2d) have some annoying overlapping issue, while in your OpenElec they are fine. I don't know how you do it there. And system sounds, like in browsers, have some major bug.

Unfortunately i can be of no help in this collecting job, but i just want to say - thank you and take a part in encouragement thing :).

Share this post


Link to post
Share on other sites

RagnerBG: the pixman issue should be worked around with the last commit in my dev tree. There is/was some minor issue, that should be easy to fix. I still have to look into it.... Kodi does the gui with gles afaik. Not with cpu via pixman.

 

jernej: do you stay in contact with mosterta regarding libvdpau-sunxi and kodi? Maybe we should all come together in #cedrus some time ...

What is the license / eula of the linked mali libs? I did not follow the link so far ...

 

Regards

rellla

Share this post


Link to post
Share on other sites
(edited)

rellla,

I think you are right about subtitle rendering. pixman issue should not affect Kodi.

 

I'm not yet in the contact with mosterta, but I guess it would be beneficial. There are some parts in the code, which seems to render image once through vdpau and once through gles... But this is off topic here. H3 kernel has some issues with sound, which should be resolved first, I guess.

 

The problem with userspace mali r4p0 blobs is that they don't have clear usage license. Whitewind has them on github without any info where they came from. I and some others suspect that Steven/Xunlong provided them on forum or through e-mail, but that has to be confirmed.

 

@Igor, can you ask Steven about those mali drivers? Forum thread is extremely long...

Edited by jernej

Share this post


Link to post
Share on other sites

I will port it, no problem. Currently it doesn't apply cleanly due to a newer driver used, but there isn't much to fix. Just out of curiosity - wouldn't be better to use libvdpau-sunxi presentation framework for rendering? Mali was not designed for rendering/scaling/compositing video, especially for 4K, while Display Engine 2.0 (H3 video driver) used in libvdpau-sunxi is designed exactly for that.

Share this post


Link to post
Share on other sites

wouldn't be better to use libvdpau-sunxi presentation framework for rendering? Mali was not designed for rendering/scaling/compositing video, especially for 4K, while Display Engine 2.0 (H3 video driver) used in libvdpau-sunxi is designed exactly for that.

Yes. Mali is just the 3D engine. But afaik you can at least display the frame with an EGL window (native or X based).

For rendering it should be possible to use the vdpau presentation queue API or use the display ioctls directly in the app...

Depends... In case of Kodi, i'm a friend of adapting libvdpau-sunxi  to imitate the nvidia/gl interoperation as near as possible to the spec. Just using neither nvidia nor gl but sunxi and gles ;) It is and will always be a hack, because vdpau is not intended to work on ARM at all.

But If we can achieve this, the adaptions within e.g. kodi should be not that big. I have some minor success with nv_gles_interop and VDR (www.tvdr.de) already. But now we really get offtopic :P

 

Regards rellla

Share this post


Link to post
Share on other sites

@jernej

So what's the current state of your kernel repository? Are there things left to do or we can use this as default in Armbian?

 

I'm using it for OpenELEC with it, but currently I don't have much time to invest into it. After two weeks or so I will be back in H3 development. A lot of patches can be dropped if switch is made, but currently the main issue would be need to use r4p0 mali driver in userspace, olders would not work. I also heard that Maxime Ripard has r6p0 driver, which is not yet public. Maybe we could wait for it as it may fix Chrome HW rendering (not really sure about that, but I heard that at least r4p1 is needed for that, maybe tkaiser knows more).

Share this post


Link to post
Share on other sites

This is the kernel part, which is publically available. Problem is the userspace binary library. You need one with a proper license to legally use it....

rellla

Share this post


Link to post
Share on other sites

Is this the r6p0 driver? Mali

 

Yes, but only kernel part, which was opensourced long time ago. You also need matching userspace component, libMali.so at same version to make things work. Actually, you can look at kernel space driver just as a helper and userspace library as brains.

 

IIRC ARM page has 64 bit libMali.so r6p0, but not 32 bit.

Share this post


Link to post
Share on other sites

Question remains what to do with out of tree drivers like mali and wireless. I will probably add those which can be found in most SBCs. Igor, what is the plan with mali driver? Would be r4p0 acceptable? Userspace libraries can be found here.

Another question remains - is this r4p0 libMali.so redistributable? If not, how hard it would be to revert this kernel to older Mali driver?

Share this post


Link to post
Share on other sites

Another question remains - is this r4p0 libMali.so redistributable? If not, how hard it would be to revert this kernel to older Mali driver?

 

Well, I really don't know, because thread on OrangePi forum is too long to check. But if you go in this direction, I would worry more for GPL violations in kernel code. As it currently stand, H3 BSP kernel code is not really redistributable, because it contains at least three binary blobs which are statically linked with kernel. One situation is solvable (AR100 FW), but other two are not if you don't want to loose functionality (HDCP code and libisp, which is responsible for camera). OK, HDCP can be removed without much worries. There might also be other blobs. There is certainly one more for ethernet, but it seems to be redundant as code is available. Another issue are files without clear license. Some are missing terms completely and others have only copyrights asserted.

 

This means that you probably can't make completely legal image with H3 BSP kernel.

 

Another thing about mali - if I understand everything correctly, ARM had weird coditions for libMali redistributions until recently and r6p0 will be one of the first releases which can be redistributed without issues. Check this: https://lists.x.org/archives/xorg-devel/2016-June/050294.html

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
1 1