Re: [yocto] [meta-rockchip] The various rockchip layers
2017-10-08 5:39 GMT+02:00 Trevor Woerner: > On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krak wrote: Thank you for taking the time and explaining the current and previous state. It is highly appreciated. >> 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 ;-) Yeah, noticed that one. Neat little layer that the meta-rockchip should try and consume :). > >> 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. Ok, that explains it a bit. > >> 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 :-) That is of course fully understandable. > >> - 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. Also understandable. > >> - 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 :-) This explains a lot thanks. > 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
Re: [yocto] [meta-rockchip] The various rockchip layers
On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krakwrote: > 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
Re: [yocto] [meta-rockchip] The various rockchip layers
On Sat, Oct 7, 2017 at 4:03 PM, Mirza Krakwrote: > Hi all. > > I recently started working with Rockchip SoC`s and I currently have a > Tinkerboard and a FireFly-RK3288 board. And as I recently enter the > Yocto Rockchip world I have some comments and questions on the current > setup/workflow which I found a bit confusing when starting out. > > 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]. > > 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. > > 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. > > 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? > > - The Rockchip maintained layers supports more "community" boards then > the community layers does. Bit odd? :) > > - The community layers are a bit outdated on older Yocto branches, > master branch seems active though. > > - Trevor and Romain (maintainers of the community layers) are listed > as maintainers of the Rockchip layers? [4] Its not a good situation, While it is good that both layers are maintained, it should be clear in its purpose. It could be that github layer supports products and might have binary stuff and may not work with latest upstreams and the community layer while supporting lesser number of boards is kept uptodate with respective upstreams. Ideally, it would be good if both layers were in sync. > > 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. > > [1]. https://github.com/rockchip-linux > [2]. http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/ > [3]. > http://freescale.github.io/doc/release-notes/2.2/#the-differences-between-project-name-and-freescale-release-name > [4]. > https://github.com/rockchip-linux/meta-rockchip/blob/master/README#L65-L66 > -- > Best Regards > Mirza > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-rockchip] The various rockchip layers
Hi all. I recently started working with Rockchip SoC`s and I currently have a Tinkerboard and a FireFly-RK3288 board. And as I recently enter the Yocto Rockchip world I have some comments and questions on the current setup/workflow which I found a bit confusing when starting out. 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]. 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. 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. 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? - The Rockchip maintained layers supports more "community" boards then the community layers does. Bit odd? :) - The community layers are a bit outdated on older Yocto branches, master branch seems active though. - Trevor and Romain (maintainers of the community layers) are listed as maintainers of the Rockchip layers? [4] 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. [1]. https://github.com/rockchip-linux [2]. http://git.yoctoproject.org/cgit/cgit.cgi/meta-rockchip/ [3]. http://freescale.github.io/doc/release-notes/2.2/#the-differences-between-project-name-and-freescale-release-name [4]. https://github.com/rockchip-linux/meta-rockchip/blob/master/README#L65-L66 -- Best Regards Mirza -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto