On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krak <mirza.k...@gmail.com> wrote: > As I started digging to check the current state of the different > layers it was quite clear to me that there where two different sets. > One is maintained by Rockchip [1] and the other one by the community > [2].
Don't forget https://github.com/jackmitch/meta-tinker ;-) > And it made sense to me initially. I do not know the full background > story with the Rockchip layers (would be nice if someone could tell it > :)) on what the intent was with "community" Rockchip layers. Romain started meta-rockchip initially, then I joined, then people from Rockchip joined later. > But as I looked in to it further it was quite clear to me that the > Rockchip maintained layers are more "up to date" then the community > ones. And then I started thinking on why are not these merged and we > could focus effort on maintaining one layer. The main goal Romain and I have is to have a meta-rockchip that helps users run upstream code on their rockchip devices. My guess is that the main goal of the Rockchip meta-rockchip is to demonstrate the performance of the rockchip SoC (usually via vendor kernels, vendor bootloaders, binary blobs, etc.) > There are a couple things that are interesting: > > - The Rockchip maintained layers state that they do accept > contributions trough pull-requests on github. So nothing stopping us > there? They are quite friendly, but they have their goals. > - The Rockchip maintained layers supports more "community" boards then > the community layers does. Bit odd? :) The rockchip people are paid to maintain meta-rockchip as part of their day-jobs, Romain and I aren't. I buy my own boards, I haven't received any hardware support, so my contributions tend to focus on boards I actually have. I would rather have support for boards I can actually test and therefore actually have rather than guessing whether stuff will work. Not to mention I have to find time to work on this after other "more important" things are done :-) > - The community layers are a bit outdated on older Yocto branches, > master branch seems active though. Mostly a time issue. I build master with firefly-rk3288 every night with all the latest master updates and try to fix any issues that come up. I don't have the resources, unfortunately, to keep my finger on various past releases. > - Trevor and Romain (maintainers of the community layers) are listed > as maintainers of the Rockchip layers? [4] Initially the Rockchip people would send pull requests for the one meta-rockchip layer. Many of those pull requests were to add recipes pointing to vendor kernels/bootloaders and binary blobs. Also they would send patches for boards that (at those times) weren't available or sometimes weren't even announced! We pushed back on some of the contributions, not just for philosophical reasons but sometimes for technical reasons as well. They weren't happy with our slow response times and push-back so they just forked and went on their own way. When they forked they forgot to change some of the boilerplate stuff that should have been changed (such as the maintainers). So yes, Romain and I are listed as the maintainers of the Rockchip meta-rockchip layer, but we're not :-) It's on my TODO list to send them some patches for things like that :-) > What I am really after is better understanding the workflow working > with Rockchip SOC`s and Yocto and that is why I am raising questions > to do so :). > > My plan was getting involved in one of the Rockchip layers as I have > some improvements and I have some ideas for further improvements. And > the goal with this email was to figure out where. Every once in a while I try to carve out some time to try the Rockchip meta-rockchip layer and see how things are going. Maybe it's just a coincidence, but often they don't build for me. Looking through their instructions they seem to want lots of control over a user's setup/configuration (i.e. by using repo to pull specific versions of a specific set of layers, then using their own setup tool). My goal is to have a layer that works any way the user wants to work (e.g. distroless with openembedded-core, or with poky, or with angstrom, etc...). When I use their instructions I do have more success (but not always), but I don't believe that's how BSP layers should work. I don't think it's a good situation when a user must use a specific distro, or specific layers at specific commit points, or a specific setup tool in order to build for a MACHINE successfully. I'm hoping that one day https://bugzilla.yoctoproject.org/show_bug.cgi?id=11881 will get accepted. If/When that happens then it will be theoretically possible to have both a set of upstream recipes and a set of vendor recipes within the same BSP layer. Maybe at that point the two (three?) layers can come together. Unfortunately there doesn't seem to be much interest in BSP layers outside of the BSP community. I'll probably just have to add the support to the layer itself in order to gain this functionality (as do the FSL layers, which is where this idea originates). I am hoping for a better situation in the future. I'm glad for any suggestions, patches, testing, etc. For example, the meta-rockchip I help maintain still uses a vendor u-boot although I've been told the upstream should work fine; I just haven't had the time to investigate. Also, I'd like to add a linux-stable recipe for 4.13 (similar to meta-odroid) but I can't seem to get the defconfig right. Also, I have a firefly-rk3399 and a tinker-rk3288, but haven't had the time to get anything into a state I can push publicly. Never a dull moment :-D -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
