So, my name is Mitri, I'm working for Linaro.
Today I'm going to talk a little bit about the Linux Yopto, a fairly unused Linux kernel
or Linux BSP for Yopto.
About me, I've been working on both Open Embedded and Linux Kernel and contributing them since
2007.
Maybe some of you guys remember Open Zaurus, I've been using Open Zaurus but not contributing
to it and started when it became on-stream.
So, Linux came about 2000 commits and in our part of the Qualcomm ecosystem, we are working
on the Qualcomm devices and I'm maintaining the Metaclick-com, the upstream and the open
source BSP for the Qualcomm devices.
And this talk is based on our experience with supporting or providing the canals.
Should I move somewhere?
With providing the canals for the Metaclick-com.
So typical Open Embedded board support package, of course it contains Linux kernel.
First come a recipe, custom.
Initially the BSP will find their own recipe, their own way to do things.
They have the source you write points into the Git tree.
Yeah, sure.
Sometimes this Git tree tracks the whole development history with all the tries, with all the attempts.
Or sometimes it is just written for each major release or sometimes it's a mixture of both.
So yeah, Roberto, the fix of the fix.
It is not an imaginary thing, it is what I saw in one of the BSPs.
Do you know how to track if the patch has been ever sent to upstream?
What's the status of that patch?
No.
Which version is it?
Well, if you're lucky, it is a long term support kernel, which you can up to the latest
LTS release.
I tell you, if you're lucky.
And security updates, if you're extremely lucky.
How to configure?
Yeah, there will be usually a different config file either in the layer itself or in the
same Git tree.
So any idea how to upgrade it?
Yeah, or how to enable the net filter or an other obscure option that the BSP vendor did
not enable for you.
Trouble some.
And yeah, everybody does it this way.
I think so.
Well, I thought so.
We tried to change this way for us.
Linux Yachto.
I knew about it for ages because it was the kernel that was used by OECore, by the core
layer for the OpenEmbedded for Yachto.
It was used for the QEMO machines.
It has been used for some of the default BSPs.
But why should I pay attention to it?
I have my own kernel.
Well, not quite.
We found that it follows stable releases.
It also follows the latest Linux release.
It tracks the release canals.
It has a very powerful kernel configuration tool based on the fragments, based on the
internal scripting language.
And it is endorsed by the Yachto project and the OpenEmbedded layer program.
And that's actually what made us to look into it.
We thought about making Metacore actually certified for Yachto project compatible layer
program.
And it is one of the recommendations.
Sounds perfect.
Well, all the stuff, all the DevConfig, all the points from the previous slides have been
pointed.
Yeah.
The problem was that nobody uses it.
We are trying to do it.
So some literally small how-to.
Yeah.
This reminds me of one of the talks of reading the Emacs config.
But I will be reading the Metacore configuration files.
First of all, the recipe itself is in OECore.
We do not have to provide any additional details.
We do not provide the Git repo.
We do not provide anything.
The default is same.
We just say, yeah, let's use the defaults.
Let's enable it for our machine.
Q-com.
R&D is our OpenEmbedded machine.
We will be using our paths and the bonus stuff.
There will be a lot of the files described in the configuration.
There will be a lot of the files in the SC format and the CFG format that should describe
different options for different machines.
We just need to enable a single root file.
The kernel.yokto class will get all the files that are beneath that.
So we do not have to list anything else in the source URI.
If you need, you can add more of the configuration options.
You can enable other features just by adding another append in your distro or in your enablement
layer.
That is it.
You do not have to patch anything.
You do not have to patch the DevConfig in either of the layers.
You do not have to create something that tracks, oh, that was the DevConfig from that layer.
The options changed.
It also tracks stable, as I said.
So we do not have to upgrade the versions.
We do not have to upgrade anything when there is a new release from this stable team.
Oh, sorry, one button.
Patches.
Of course, the BSP layer has tons of patches, hundreds of patches.
We have to list all of them.
They come in a series.
This is just a few lines.
In our layer, there are currently 78.
We are trying to limit them to some same amount.
And a bonus feature, bonus point.
Because this is a recite from OECore, we have to track upstream status.
So for each of the patches, there will be upstream status trailer that talks, yes, this
patch has been submitted.
Oh, sorry.
We did not submit this patch yet.
History is no longer written in some obscure git tree.
There is all the history of the patches comes from the layer BSP.
As the user, you can take a look at any pointers and find, okay, yeah, these patches have been
enabled for this and that platform.
And they have been changed this and that way.
Oh, and when we're basing from 6.5 to 6.6, oh, they did this and that mistake, and I
know how to fix it.
So the whole history, the whole development is visible to the, well, is visible to the
developers, is visible to the users of our layer.
Config fragments.
As I said, there is a powerful system of the config fragments.
They have the SSE files that describe, okay, how it all beams together.
And of course, the CFG files, the parts of the actual configuration.
And SSE, they provide a street-like structure.
They can include other SSE files or they can include config files.
So there is a huge set of default features that you can enable.
You just pull files from the default set that has been written for you by Richard, by Bruce
Asheville.
Several downsides.
There is no control over the exact kernel version.
This is all done by Bruce Asheville, by the maintainer of Linux Yachto.
And when he upgrades to the next version, yeah, when is his decision.
Before this new year, he decided to let everybody stay calm.
And so he delays upgrading to 6.6 LTS for several weeks.
And unless you know what's happening, this can cause some confusion.
So we had to ask Bruce what's happening.
Sometimes Linux Yachto gets delayed.
Sometimes there are additional patches.
Well, in fact, as it is a BSP for several devices, it has additional patches.
And you have to understand how that corresponds to your device, how this conflicts with your
patches.
And the most important thing.
So previously, you can easily have a set of developers working on just Git tree for your
kernel.
They do their job.
They do it all right.
They just tell you, OK, this is the Git commit that you should be pulling into your BSP layer.
Yeah, OK.
Now it is also responsibility of the maintainer of the corresponding layer to actually see
what's going on, to work in close collaboration with the kernel developers.
In our case, I'm working also as a reviewer for the patches being submitted by our developers
and by Qualcomm developers enabling the particular features because sometimes they are not.
So you can no longer just depend on being, oh, I'm Yachto developer.
I'm open and better developer.
You have to be kernel developer too.
And the last but not least, so what if we have several hundred of BSP patches?
How do you track them?
How do you actually manage them so that it does not become the mess?
So we solved that by splitting them into the series.
And so we actually are working with, as I said, with Qualcomm people just, OK, you cannot
say that, yeah, these hundred patches are for to enable this platform.
You have to say, yeah, this is a feature, this is a 10 patches enabling this feature.
These are 15 patches enabling another feature.
And so splitting and tracking different patch sets separately.
So rolling see, of course, there is the Linux Yachto itself repository, which has all the
branches, all the patches, all the history from prehistoric times till the recent 6.6.
Yachto can all cache.
That is what I told you when I said that you are pulling the config fragments from the
upstream.
This is the repository with all the configuration fragments, with all the configuration scripts
that your layer will pull, that will combine into the final kernel configuration.
Yeah.
Our unproud Metacucom, the upstream Qualcomm layer.
If you are working on the, for some reason, Qualcomm robotics or on Qualcomm robotics
platform, or if you are thinking about using the Yachto for your phone for some reason,
and it works, please take a look.
This is the area that you might be interested.
And yeah, of course, yeah, linear services.
We are linear development services, and we now have an account on Mastodon.
So please join the followers, and of course we are hiring.
So that's it.
Ah!
Yeah.
Questions?
Questions.
Questions.
Hello.
How does the feature set from your kernel compares to some internal developer, the standard kernel
Qualcomm provides?
So I'm not working with Qualcomm, but I see often the big differences between the vendor
kernel with thousands of patches compared to what is upstream.
Yeah.
So as I said, we are working for the Qualcomm upstream, or working on Qualcomm upstream
enablement.
So we are tracking what is going upstream, and we are developing, and we are sending patches
upstream.
So yes, right now there is a talk, or they just have been talked about different Qualcomm
kernels in another building.
You might be interested in statistics.
In our case, as I said, currently for this metric, we call for enabling platforms that
have not been fully integrated upstream.
We have about 80 patches.
Ah!
Oh!
Yeah, it works.
So, internal deep tree, before we switch to Linux Yachter, contained from 150 to 200 patches.
And so one of the reasons for switchover, and one of the points was that we were able
to clean up that stuff.
We were able to drop several, okay, I think it was about 20 patches.
Just touching bit of config in a different way.
So everything now goes to the Yachter.
We were able to drop several obscure patches that had been lingering for years.
And to move those patches actually into upstream, send them to upstream, rebook them and drop
them finally.
So I don't know if that answers your question.
This doesn't work for the downstream development.
Well, you are window with thousands of patches.