Re: BSP for taskit stamp9g20

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

On 12-06-29 11:08 AM, Markus Hubig wrote:
> On Fri, Jun 29, 2012 at 3:47 PM, Bruce Ashfield
> <bruce.ashfield@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 ;-)

At times .. smaller is better, at least it's less to sort in this case.
Plus it lets the default yocto kernel policy make it through the the
.config without any intervention required.

>
>> 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! ;-)

I can definitely have a look, I've reviewed several hundred of these
over the years .. so I know what to look for :)

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

Agreed, and I'm working to address this with some scripts that both
work on the config, and can report the policy options clearly. The script
is quite raw at the moment, and needs work, but it is better than
nothing.

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

No problem, it is this sort of thing that shows where the gaps are, and
where we should spend time improving things.

Cheers,

Bruce

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