Re: BSP for taskit stamp9g20

[Bruce Ashfield <bruce.ashfield@windriver.com>]

On 12-06-29 09:34 AM, Markus Hubig wrote:
> Hello @all,
>
> now I have a working BSP-Layer, but for now its only a plain copy
> (created with yocto-bsp)
> of arm-versatile-926ejs. And the only thing it does so far, is
> creating a .config-Kernel
> configuration file (which is fine by now). To adapt this to my needs
> it seems I have to edit the
> stamp9g20.cfg and the stamp9g20-non_hardware.cfg files. Am I right?
>
> Since I can create a valid kernel configuration by simply:
>
> $ make ARCH=arm stamp9g20_defconfig
>
> I'm using this file as a reverence, but now I'm having a hard time
> figuring out what part of
> this config file I have to put inside my BSP cfg files and what to use
> from the kernel
> meta/cfg/kernel-cache/features stuff via a include statement ...
>
> I try to make an example:
>
> In my reference config file I have this
>
> CONFIG_HIGH_RES_TIMERS=y
>
> This can be found here "meta/cfg/kernel-cache/features/hrt/hrt.cfg" as
> a kernel feature.
> So I have to add the statement "include features/hrt/hrt.scc" into
> "stamp9g20.scc", right?
>
> But wait a minute ...
> $ grep -r hrt.scc linux-yocto-3.2-work/meta/cfg/kernel-cache/
>     linux-yocto-3.2-work/meta/cfg/kernel-cache/ktypes/standard/standard-nocfg.scc:include
> features/hrt/hrt.scc
>
> So its already included from "ktypes/standard" ... ;-(
>
> To get a better overview (and because I'm a famous magician) I made up
> a little spell:
>
> # Look for all kernel config parameters if they are defined somewhere inside
> # linux-yocto-3.2/meta/cfg/kernel-cache/(arch|cfg|features|ktypes/base|ktypes/standard)
> # if found print the matching file, if not print NOT FOUND.
> for i in $(grep -v '^#' ~/Development/linux-yocto-3.2-work/.config
> |grep -v '^$' | awk -F"=" '{print $1}'); do
>      grep -H $i $(find arch/ cfg/ features/ ktypes/base
> ktypes/standard/ -name *.cfg) || echo NOT FOUND: $i;
> done | sort | uniq>  ~/Development/features_all.txt
>
> # Split the features_all.txt file into found and not found
> grep -v '^NOT FOUND' features_all.txt>  features_found.txt
> grep '^NOT FOUND' features_all.txt>  features_not_found.txt
>
> # finally get a list of all scc files I need to include.
> cat features_found.txt |awk -F':' '{print $1}' |sed \
>      "s/.*\/\(.*\)\.cfg$/\1.scc/" |uniq>  modules_to_include.txt
>
> (I put all the mentioned files here: https://gist.github.com/3017292)
>
> I guess the config variables inside features_not_found.txt are the one
> I need to include into
> the stamp9g20.cfg, stamp9g20-non_hardware.cfg files? (Ok except the
> ones that get enabled

I wouldn't say that, was your input .config a minimal defconfig ?
You really don't need to list option in your BSPs configuration that
are not already defined, are not hardware and are the default
selection of the kernel already.

There are also the on-target scripts and techniques for streamling
your configuration that can result in a smaller input .config that you'd
feed to any process for streamlining a board's configuration.

> by some kernel dependency stuff ... but how to figure out this?)
>
> Is there a better way to go? Maybe one where you don't have to have
> magical powers? ;-)

There are few things that can help here:

   - I've just revived a script that takes a defconfig that has been
     fed to the kernel auditing subsystem and breaks it apart into the
     options that you really do or don't need in your BSP config

   - A lot of work on kernel configuration updating and policy has
     happened in the 3.4 kernel, and will be part of yocto 1.3. As part
     of that, the policy options (what you inherit), will be clear, or
     discoverable by script, as will optional and hardware configuration
     items.

   - there is a kernel-features.rc file that is part of the meta branch
     that will be further exposed. It lists all of the configuration
     fragments, with a description and whether or not they can be
     optionally included.

The end goal is that a developer / BSP that wants a quick bootstrap on
top of the existing configuration can just focus on the options that
make their board work and initially not be concerned with those software/
policy option .. until you get into a tuning phase on a BSP. Having
visibility and some scripts around this is part of the implementation
of that goal.

Cheers,

Bruce

> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto