On Wed, 2024-02-21 at 10:57 +0000, Ross Burton wrote: > From: Ross Burton <ross.bur...@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. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#195968): https://lists.openembedded.org/g/openembedded-core/message/195968 Mute This Topic: https://lists.openembedded.org/mt/104486073/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
