On Wed, Nov 05, 2025 at 09:27:07AM -0600, Ryan Eatmon wrote: > > > On 11/5/2025 9:19 AM, Tom Rini wrote: > > On Wed, Nov 05, 2025 at 09:13:15AM -0600, Ryan Eatmon wrote: > > > > > > > > > On 11/5/2025 8:42 AM, Tom Rini wrote: > > > > On Wed, Nov 05, 2025 at 03:53:16PM +0530, Neha Malcom Francis wrote: > > > > > > > > > Add support for fetching config fragments and defconfigs out-of-tree > > > > > using > > > > > CONFIG_FRAGMENT_PATH and CONFIG_DEFCONFIG_PATH respectively. > > > > > > > > > > Signed-off-by: Neha Malcom Francis <[email protected]> > > > > > --- > > > > > scripts/kconfig/Makefile | 10 +++++++++- > > > > > 1 file changed, 9 insertions(+), 1 deletion(-) > > > > > > > > Isn't this what scripts/kconfig/merge_config.sh is for? No, you can't > > > > just do "make foo_defconfig bar.config" directly, but your tooling that > > > > knows about outside fragments can merge foo_defconfig with > > > > /somewhere/bar.config directly. > > > > > > The problem is the Yocto recipes. There is a somewhat fixed manner in > > > which > > > the recipe is setup and optionally adding steps is way more invasive than > > > just adding an option to the make command. > > > > The merge_config.sh tool came from the OpenEmbedded community pushing > > things up to the kernel, so this sounds like a problem to resolve in the > > u-boot recipes/classes, and not something to change here. Feel free to > > loop me in on patches / discussions over on the appropriate list(s) > > there, thanks. > > There was a recent patch to the uboot classes in yocto that allow for > passing extra options to the make command line in for uboot. This is > intended not for "primary" platform configs, but for multiple alternate > testing configs that can be built at the same time as the primary. > Effectively, the code loops over the multiple configs in different build > directories and configures/compiles uboot multiple times and then names all > of the output files uniquely. > > That flow has been in Yocto for a very long time and is, again, somewhat > rigid in what it can allow for changing for each of the variant builds. It > was designed to build different defconfigs which is what we are trying to do > here. But since we do not want to store the defconfigs for all of these > variants in the uboot source itself, we need to be able to tell uboot that > the config is in a different location other than in the uboot source. Hence > the most straight forward solution was a variable on the make to allow for > specifying where to look for the out of tree defconfigs.
I think you need to fix this up in the OE side of things by taking the new defconfigs from where they live and copying them to configs/, assuming you're storing them somewhere as config files and not patches. If you want to support kbuilding finding a defconfig out of tree, get that in the kernel and then import those changes here. I do not want to diverge from upstream on this, sorry. -- Tom
signature.asc
Description: PGP signature
