On 31.05.2019 08:47, Belisko Marek wrote: > Hi Maciej, > > On Wed, May 29, 2019 at 1:08 PM Maciej Pijanowski > <maciej.pijanow...@3mdeb.com> wrote: >> >> On 29.05.2019 09:39, Belisko Marek wrote: >>> Hi Dimitris, >>> >>> On Wed, May 29, 2019 at 9:03 AM Dimitris Tassopoulos <dimt...@gmail.com> >>> wrote: >>>> Hi Marek, >>>> >>>> that's correct. I have a branch though which I've started to experiment >>>> and add support for Mali. I didn't finished because I've tried to do this >>>> by myself from the scratch and soon I've hit a wall. Nevertheless, I've >>>> done the same for the rk3399 for nanopi-neo4 and during this process I've >>>> learned a lot on how to do it with some help from other people from the >>>> open source scene. The graphics stack was too complicated for me in the >>>> beginning. >>> You can maybe look to meta-sunxi there is sunxi-mali driver + >>> libraries which will add support for that. When I've set that package >>> to PREFERRED_PROVIDER_virtual/gles2 I get issues with compilation >>> gtk3+ and others. I've spend 2 hours looking and trying yesterday but >>> without any success. Also pls look at this communication: >>> https://github.com/linux-sunxi/meta-sunxi/issues/144 (looks like we >>> can use opensource drivers + libs later). Thanks. >> What are you trying to achieve? Which kernel version are you using? >> Isn't the mali recipe in meta-sunxi quite dated already? Can it work >> with mainline kernel correctly? >> >> I would suggest to try the recent blobs as described in this post: >> https://bootlin.com/blog/mali-opengl-support-on-allwinner-platforms-with-mainline-linux/ >> >> As I've written previously, I have been using the Wayland / Qt with >> good performance on H3 using the mainline kernel. Is it something you >> are looking for? >> You can take a look at my dirty branch - maybe this will be any help: >> https://github.com/3mdeb/meta-sunxi/tree/weston-with-kms/recipes-graphics/mali > I've took some patches and now core-image-sato can be build. I have > just one question for mali kernel module. Does it need some dts > changes or it will work out of the box (I didn't see any dts changes > in your branch thus I'm asking). > Thanks. Depending on the board. I think since then, most of the baords already have mali node in the devicetree. Especially all the H3 baords should have it. >> Unfortunately, I had stopped working on that and presently do not have much >> time to clean up / get back to it. I can provide some support and / or get >> back to it if it seems valuable and there is some interest. >>>> Therefore now that I feel much more confident with it I'm going to re-try >>>> and finish with my branch. Armbian does have support, so I'll try to stick >>>> to the Armbian backend for maintenance reasons. >>>> >>>> I hope that this will be rather easy, because the dri driver should >>>> already be there, so the only thing I believe is needed is the blobs and >>>> to create symlinks for the various so libs to that blob. >>>> >>>> Anyway, I'll try to do that also. In the meantime I will also wait a bit >>>> to see if that merge between those two layers is possible and doable, >>>> which will help to short the time and effort to do that. >>>> >>>> Regards, >>>> Dimitris >>> BR, >>> >>> marek >>>> Belisko Marek <marek.beli...@gmail.com> schrieb am Mi., 29. Mai 2019, >>>> 08:37: >>>>> Hi Dimitris, >>>>> >>>>> On Tue, May 28, 2019 at 1:07 PM Dimitris Tassopoulos <dimt...@gmail.com> >>>>> wrote: >>>>>> Hi Enrico, >>>>>> >>>>>> I'm totally positive to any possibility for such integration. >>>>>> Personally, that was the first thing I've tried to do before I start >>>>>> this layer, but I've failed as it got really complex and the overhead >>>>>> was too much after some point (at least for me). If you have look it's >>>>>> actually a mix of meta-sunxi and armbian, but I had to remove or change >>>>>> many stuff to fit the armbian in the layer. >>>>>> >>>>>> If you have time to have a look to my layer and you think that such kind >>>>>> of integration is possible and can be done in a more easy way, then from >>>>>> my side I'm all in. >>>>>> I believe that re-using the armbian patches is easier as it makes >>>>>> maintenance much easier, there are more supported SBCs and also there is >>>>>> much more testing involved in armbian and frequent updates fix those >>>>>> bugs. >>>>> I did check your layer and it seems that you're not using sunxi-mali >>>>> for opengl HW acceleration only mesa so SW rendering? Thanks. >>>>>> Please consider it and I can help as much as I can and my time allows >>>>>> for that integration. >>>>>> >>>>>> Regards, >>>>>> Dimitris >>>>>> >>>>>> >>>>> Marek >>>>>> On Tue, May 28, 2019 at 12:56 PM Enrico <ebut...@users.sourceforge.net> >>>>>> wrote: >>>>>>> On Tue, May 28, 2019 at 12:06 PM Dimitris Tassopoulos >>>>>>> <dimt...@gmail.com> wrote: >>>>>>>>> I was thinking about this also, too. The only reason is that in >>>>>>>>> meta-sunxi they do a great job and they keep their layer clean, which >>>>>>>>> is great I think. The other layers are just based on the armbian >>>>>>>>> distro, which is a lot different, but for me it was much easier to >>>>>>>>> integrate their patches, patching scripts and bootloader scripts to a >>>>>>>>> Yocto layer. That way the only thing I do is that from time to time I >>>>>>>>> just integrate their new patches and that's it. There's no >>>>>>>>> development in the layer is just re-use of the armbian work and a >>>>>>>>> wrapper around it. Therefore, it's hard, even no doable to put those >>>>>>>>> different architectures together. But definitely that decision also >>>>>>>>> bothered me a lot before I create the layer and I also don't like >>>>>>>>> time to be spend on the same thing from different people. >>>>>>>>> Nevertheless, from my point of view I couldn't find a way to put >>>>>>>>> those things together. I've tried but I couldn't do it. >>>>>>>>> >>>>>>>>> Therefore, it was easier for me to do it the way I've done it. And >>>>>>>>> after all, although it doesn't seem right, at the same time this is >>>>>>>>> the beauty of the open source. I think the layers are just >>>>>>>>> incompatible in the way that they are do things. Also it's not bad to >>>>>>>>> have alternatives. >>>>>>>>> >>>>>>>>> Sunxi is a great community and I believe many of the armbian patches >>>>>>>>> are coming from there. Others not. Of course, having them all >>>>>>>>> together would be nice. But I don't think that it's possible because >>>>>>>>> of the different approach. >>>>>>> It would be great to integrate all those different layers in >>>>>>> meta-sunxi,the main problem is that usually they come with their own >>>>>>> bootloader/kernel/etc.... so you have to *maintain* all these >>>>>>> different configurations. >>>>>>> Infact in the past i refused to do such things because i didn't have >>>>>>> the time to maintain all those different versions, it was just easier >>>>>>> to support what was already in mainline uboot/kernel. >>>>>>> >>>>>>> But of course if someone wants to do it then it's welcome, the worst >>>>>>> thing that can happen is that once an arch gets unmaintained it will >>>>>>> be removed. >>>>>>> >>>>>>> One thing that can be done anyway is to have those external layers >>>>>>> linked in the readme, so at least people will know they exist. >>>>>>> >>>>>>> Enrico >> -- >> Maciej Pijanowski >> Embedded Systems Engineer >> https://3mdeb.com | @3mdeb_com >> >> >> -- >> _______________________________________________ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > BR, > > marek
-- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com
signature.asc
Description: OpenPGP digital signature
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
