On 12-06-29 11:08 AM, Markus Hubig wrote:
On Fri, Jun 29, 2012 at 3:47 PM, Bruce Ashfield
<[email protected]> 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
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
_______________________________________________
yocto mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/yocto
