[yocto] [meta-rockchip] The various rockchip layers

[Trevor Woerner]

On Sat, Oct 7, 2017 at 7:03 PM, Mirza Krak <mirza.krak at 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