Re: [OE-core] [Openembedded-architecture] [RFC PATCH] Add genericarm64 MACHINE using upstream defconfig

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2024-02-21 at 08:15 -0800, Anton Antonov wrote:
> On Wed, Feb 21, 2024 at 03:21 AM, Richard Purdie wrote:
> > I think it comes down to whether the fragments are usable and
> > testable.
> > We have a list of targets we want this new machine to run on so
> > lets
> > start with those, define genericarm64 as that set of fragments
> > combined
> > plus the generic pieces linux-yocto adds, then go from there. If
> > you
> > add a new machine to the test matrix, we add a new fragment. If
> > someone
> > wants to add new config, they need to show a machine using it.
> 
> Although Ross mentioned that there are not a lot of SystemReady IR
> compatible hardware in the wild, we're already talking about tens of
> them in existence. With this approach the genericarm64 machine will
> be compatible with only some of them unless we test all of the
> certified platforms and update kernel fragments accordingly. 
> The whole idea of SystemReady+defconfig is that it would allow to
> avoid future maintenance of kernel fragments in Yocto for existing
> and new SR certified platforms. If a platform is SystemReady
> certified (i.e. required drivers are up-streamed and mainline
> defconfig is updated) then the genericarm64 Yocto image would "just
> work".  On the last Yocto summit Bruce mentioned a tool which can
> automate defconfig -> kernel fragments conversion. Using this tool as
> a part of kernel versions updates in Yocto might solve the problem
> for genericarm64. But, I don't know how up to date and robust the
> tools is.
>
> Some additional information explaining requirements for genericarm64 
> - currently for SystemReady IR certification it is required that at
> least two of the main Linux distros (Fedora, Debian, Ubuntu,
> OpenSuse) generic arm64 images are bootable and functional. We would
> like to expand this list with Yocto and Openwrt as well. There is
> also a PR into Openwrt which adds a generic armsr target with the
> same defconfig approach to build the kernel.

I think the problem here is going to be defining which kinds of
configuration should come from where.

Let me pick for example, ZFS as a random kernel config option. I could
pick a USB Alcatel Speedtouch modem instead, the point is something
which doesn't really have hardware implications (but could have distro
ones).

I have no idea whether the "systemready defconfig" enables zfs or or
not. From a Yocto Project perspective that option is very much a
"distro" piece of configuration and not related to the "machine" or
hardware.

By using fragments, we can clearly keep something like that separate
and off limits. I don't know what policy this defconfig has to have
things enabled or disabled but if the policy is "supports anything and
everything", zfs and likely a lot of other things are probably enabled
that we wouldn't usually want in Yocto Project builds.

This is where the full defconfig becomes tricky since you get the bits
needed for the Systemready spec, but you potentially get all kinds of
other pieces too. You end turning on everything just in case.

Is there some policy which says whether zfs should or should not be
enabled in that defconfig?

There has to be some set of config options that systemready requires
and some that it doesn't care about and the real issue here is wanting
to know which are which.

Cheers,

Richard