Thank you for taking the time and explaining the current and previous
state. It is highly appreciated.
Post by Trevor WoernerPost by Mirza KrakAs 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 :).
Post by Trevor WoernerPost by Mirza KrakAnd 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.
Post by Trevor WoernerPost by Mirza KrakBut 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.)
Post by Mirza Krak- 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.
Post by Mirza Krak- 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.
Post by Trevor WoernerPost by Mirza Krak- 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.
Post by Trevor WoernerPost by Mirza Krak- 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.
Post by Trevor WoernerIt's on my TODO list to send them some patches for things like that :-)
Post by Mirza KrakWhat 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 actually recently was in the situation on choosing of one of
meta-rockchip layers and I ended up with the Rockchip one, mostly
since it had Tinkerboard support and 4.4 vendor kernel. It built for
me at least :).
I am not totally against using repo and manifest to help users setup a
simple "demo" (and it is quite common to use this). As the BSP layer
does not really provide you with anything cool beside booting to a
console, if one is to provide a demo layer (which is quite common to
demo X11, Walyand, and Qt as examples) making it easier to get started
with development. But the BSP layer should of course work standalone.
Post by Trevor WoernerI'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).
This is certainly a interesting change but IMO not required to have
multiple u-boots, Linux kernels etc. The Freescale layer is by far
more complex (due to the number of boards/SOCs supported) and makes
sense there, most other BSP layers maybe do not that kind of
complexity and not the same need I guess.
Post by Trevor WoernerI 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.
It is quite obvious to me that any attempted efforts should be
directed to the community layers as this was once the base of the
Rockchip layers.
I do have some time and ambition to spend I will list some ideas here
so that they can be shot down before I start working on them (some
things might not align with your goals of the layer):
- Synchronize the Rockchip and community layers. There are some
goodies in the Rockchip layers that would be nice to pull in.
Especially the vendor 4.4 kernel with GPU support and accompanied
binary blobs (that should work with Qt, Wayland, X11), I have tested
X11 my self. Running mainline is nice but without the GPU support your
are really not utilized the true power of the SoC`s. And IMO this
should be the default kernel as it provides the most functionality.
- Bring in various boards from Rockchip to community layer. I know
your wrote that you do not like to bring in boards that can not test,
but you will never have all the boards :). When bringing in the
various boards we should also try and get people interested in
maintaining them, that could be one condition on bring in boards that
you do not have.
- Bring in more vendor kernels (tinkerboard, phycore, firefly?) who
all have their own forks. Again mainline is nice but does not provide
the same functionality as the vendor kernels.
- Consolidate machine configurations. I started working on something
targeting the Rockchip layer here [2]
- Add proper extlinux support [1], instead of hardcoding it in the gpt
image classes.
- Move away from custom image classes to WIC, I am running this in a
custom layer and it works just fine.
- There seems to be a lot of "stale/dead" code in the community
rockchip layer. Old kernels and "petitboot" that might not be used
today? This is basically a clean-up task.
- I kinda like the meta-rockchip-extra layer to provide more "capable"
demo images for testing purpose.
Also the ambition would be to try and get Rockchip involved again in
the community layer instead of forking or at least push changes to
community layer if they want to keep the fork.
There is probably more but I will stop here for now :).
Post by Trevor WoernerNever a dull moment :-D
We would not be doing this otherwise :).
[1]. https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/uboot-extlinux-config.bbclass
[2]. https://github.com/mirzak/meta-rockchip/commits/consolidate-machines
--
Best Regards
Mirza
--