new way of writing defconfigs for freescale's powerpc platforms

[Richard Schmitt]

> -----Original Message-----
> From: Bob Cochran [mailto:ppc at mindchasers.com]
> Sent: Thursday, April 16, 2015 8:21 AM
> To: Wood Scott-B07421; Pan Lijun-B44306
> Cc: linuxppc-dev at ozlabs.org; Schmitt Richard-B43082
> Subject: Re: new way of writing defconfigs for freescale's powerpc platforms
> 
> On 04/16/2015 12:44 AM, Bob Cochran wrote:
> > On 04/09/2015 06:31 PM, Scott Wood wrote:
> >> On Thu, 2015-04-09 at 16:52 -0500, Pan Lijun-B44306 wrote:
> >>> Hi Maintainers,
> >>>
> >>> We have a proposal for writing the defconfigs for freescale's
> >>> powperpc platforms in a new way.
> >>> Can you take a look and provide some feedback?
> >>>
> >>> You know currently we have mpc85xx_defconfig, corenet32_defconfig,
> >>> bsc913x_defconfig, *fman*_defconfig, etc.
> >>> We are going to extract some common parts from the existing
> >>> defconfigs, and name it, say, fsl_basic_defconfig.
> >>> Then, we could create some defconfigs targeting specific features or
> >>> specific platforms.
> >>> Say, features specific: kvm_defconfig, fman_defconfig, etc.
> >>> Platforms specific: p1_defconfig, p2_defcongfig, p4_defconfig,
> >>> t1_defconfig, t2_defconfig, t2_defconfig, b4_defconfig, etc When we
> >>> want to make a kernel image for p1 platform, Using the following
> >>> steps:
> >>>
> >>> make ./scripts/kconfig/merge_config.sh
> >>> arch/powerpc/configs/fsl_basic_config p1_defconfig make
> >>>
> >>> What do you think of this new approach?
> >>> Will you accept this approach?
> >>
> >> I'm OK with a merge_config approach.
> >>
> >> I'm not OK with having separate builds for p1/p2/p4/t1/t2/b4.
> >>
> >> -Scott
> >
> >
> > As you probably know, Freescale makes use of the Yocto Project build
> > system for its SDK and submits patches to the SDK at a public
> > meta-fsl-ppc repo at
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-fsl-ppc/
> >
> > I have seen some kernel related patches in the past come across the
> > Yocto Project site that made use of the Yocto Project kernel tools,
> > which includes a process for maintaining kernel configuration fragments.
> 
> 
> Here is a link to a patch from a Freescale developer introducing Yocto kernel
> tool support (description files & configuration fragments) to the meta-fsl-ppc
> repo (FSL QorIQ SDK on Yocto).
> 
> https://lists.yoctoproject.org/pipermail/meta-freescale/2014-
> October/010890.html
> 
> 
Yes, we do also intend to support this in Yocto and that the fragments will be applied during the build process as part of Yocto recipes and Kernel Features.   The first step in doing this is creating the fragments and providing a means to create the platform defconfigs without Yocto.  
> 
> >   It sounds like the requirements you have could be met with Yocto's
> > existing process.
> >
> > I was hoping to see Freescale continue to move in the direction of
> > using the Yocto kernel tools rather than roll its own solution.

There are a number of activities we are doing that will bring us more in the direction of the Yocto kernel tools.  But again, Yocto is one way, not the only way.  So we intend to support a Makefile approach to building configs (similar to Intel) as well as a Yocto approach to building configs.
> >
> > The Yocto kernel tools make use of description files (*.scc) and
> > configuration fragments (*.cfg).
> >
> > Here is a link to the latest stable Yocto kernel development manual:
> > http://www.yoctoproject.org/docs/1.7.1/kernel-dev/kernel-dev.html
> >
> > Bob
> >
> >
Rich

> >
> >
> >
> >>
> >>
> >> _______________________________________________
> >> Linuxppc-dev mailing list
> >> Linuxppc-dev at lists.ozlabs.org
> >> https://lists.ozlabs.org/listinfo/linuxppc-dev
> >>
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev at lists.ozlabs.org
> > https://lists.ozlabs.org/listinfo/linuxppc-dev