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

["Anton Antonov" <anton.antonov@arm.com>]

[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]

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.

Cheers,

Anton

[-- Attachment #2: Type: text/html, Size: 2020 bytes --]