[yocto] BSP for taskit stamp9g20

[Markus Hubig]

On Fri, Jun 29, 2012 at 3:47 PM, Bruce Ashfield
<bruce.ashfield at windriver.com> wrote:
>
> On 12-06-29 09:34 AM, Markus Hubig wrote:
>>
>> 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 ?

Hmm yes (or no) it's the .config file that gets created with
make ARCH=arm stamp9g20_defconfig. I doubt this is minimal,
but that's the only reference I have.

Uhh, I found something more minimal:

linux-yocto-3.2-work/arch/arm/configs/stamp9g20_defconfig

maybe this is what I need? (just 129 lines ;-)

> 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.

Hmm ok ... I'll put my BSP repo online later today and maybe you can
take a quick look if it's ok? This would be really helpfull! ;-)

> 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

Oh I would really like to try this! This would be really helpful for me,
and I think there are a lot of people out there who have a working
kernel .config file (like I do) and are looking for an easy way to
include this into a BSP. And the most relevant information one needs
to do so are (IMHO):

1. What config options can I ignore because there are handled by yocto.
2. What config options can I ignore because there are set by dependencies.
3. What config options do I absolutely have to set.

>  - 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.

I wish I could have this now ... looking forward to it!

>  - 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.

Thank you for this explanation!

- Markus