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

[Mikko Rapeli <mikko.rapeli@linaro.org>]

Hi,

On Wed, Feb 21, 2024 at 11:21:39AM +0000, Richard Purdie wrote:
> On Wed, 2024-02-21 at 10:57 +0000, Ross Burton wrote:
> > From: Ross Burton <ross.burton@arm.com>
> > 
> > This is a new 64-bit "generic" Arm machine, that expects the hardware to
> > be SystemReady IR compatible. This is slightly forward-leaning as there's
> > not a _lot_ of SystemReady hardware in the wild, but most modern boards
> > are and the number will only grow.� Also, this is the only way to have a
> > 'generic' machine as without standardised bootloaders and firmware it
> > would be impossible.
> > 
> > The base machine configuration isn't that exciting: it's a fully featured
> > machine that supports most things, booting via UEFI and an initramfs.
> > 
> > However, the kernel is more interesting.� This RFC uses the upstream defconfig
> > because unlike some other platforms, the arm64 defconfig is actively
> > maintained with the goal of being a 'boots on most hardware' configuration.
> > My argument is: why would we duplicate that effort?
> 
> Can you point at the policy/process which decides how a config option
> makes it in there?
> 
> > The "linux-yocto way" is configuration fragments and after a week of
> > hair-pulling I do actually have fragments that boot on a BeaglePlay, but
> > to say this was a tiresome and frustrating exercise would be understating it.
> > 
> > So, a request for comments: is it acceptable to use the upstream defconfig in
> > a reference BSP?� Personally I'm torn: the Yocto way is fragments not monolithic
> > configs, but repeating the effort to fragmentise the configuration and then
> > also have it sufficiently modular that it can be used in pieces - instead of
> > just being a large file split up into smaller files - is a lot of effort for
> > what might end up being minimal gain.� My fear is we end up with a fragmented
> > configuration that can't be easily modified without breaking some platforms,
> > and badly copies what the defconfig already does.
> 
> Let me play devils advocate.
> 
> I do understand it is a pain, equally, once you do have it working, it
> is something you rarely have to touch again for a given board.
> 
> In the context of linux-yocto, I suspect we'd end up with a few board
> specific lists of config options (fragments) that board *really* needs.
> genericarm64 would end up as the sum of all those configs, plus any
> other bits which you really want in a generic machine, presumably the
> genericx86 machines have an idea of that.
> 
> The advantage here is that you give the users three options:
> 
> a) the kitchen sink upstream "systemready" defconfig
> b) the genericarm64 machine defconfig which works most places and�
>    is�'guaranteed' on our target test platforms
> c) a machine targeted defconfig with only what a board needs
> 
> Developers/users end up in different places at different points in
> there lifecycles.�
> 
> For in depth development, you might like to be able to cut the kernel
> down so you'd not rebuilding tons of stuff you don't need/use/care
> about each time, nor transferring it to a device during updates.
> 
> For a specific product release, you again might want to trim it down to
> what it needs.
> 
> If you're shipping demo software, a full systemready image would be
> much more appropriate.
> 
> 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.

FWIW, we have been using upstream kernel.org aarch64 defconfig plus
few board specific fragments and few extra features for our testing needs.
I have been very happy that several major kernel version updates have already
been done this way and zero adaptations needed on our side for the
ARM SystemReady boards and firmware which we support. A simple CI run to show
passing test results was sufficient for a poky update with new kernel
major version.

The implementation here looks pretty much like ours. Looks good, thanks Ross!

More details of our setup:

https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/blob/main/meta-ledge-secure/recipes-kernel/linux/linux-ledge-common.inc?ref_type=heads
https://gitlab.com/Linaro/trustedsubstrate/meta-ledge-secure/-/tree/main/meta-ledge-secure/recipes-kernel/linux/ledgearm64-kmeta?ref_type=heads
https://trs.readthedocs.io/en/latest/

Cheers,

-Mikko