* Splitting processor and target in BSPs
@ 2011-09-02 7:26 Chris Tapp
2011-09-02 15:48 ` Bruce Ashfield
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: Chris Tapp @ 2011-09-02 7:26 UTC (permalink / raw)
To: yocto
How should meta data be structured so that a layer can support a set
of systems using a set of processors?
For example, many of the 'eBox' systems use variants of the Vortex86
SoC. So, a set of machine files are needed for these (e.g. ebox-3300,
ebox-3500mx, etc.).
These have different peripherals available (e.g. some have serial,
some don't) and use different SoC variants with different cpu, sound,
etc. It would therefore make sense for the machine configuration to
inherit the SoC attributes (for the common features) and add (or
remove) machine specific attributes (e.g. serial) to these. This can
be done by putting the SoC bits in to an include.
However, kernel configuration becomes a little bit more complicated as
this is done by machine name. A kernel recipe will be needed for each
machine (e.g. for the different sound drivers), but I can't work out
how to do this using a base configuration for the SoCs that are shared
and then adding machine specific parts. I can do it using (for
example) a .defconfig for each machine, but that would require updates
to multiple files to change the SoC configuration.
I guess what I'm really asking is, is it possible to have a base CPU
configuration and add a machine configuration to this ?
I've recently seen discussion of .cfg kernel fragment files. Are these
what I should be looking at? Are these available in the releases or
only in the development branch?
Chris Tapp
opensource@keylevel.com
www.keylevel.com
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Splitting processor and target in BSPs 2011-09-02 7:26 Splitting processor and target in BSPs Chris Tapp @ 2011-09-02 15:48 ` Bruce Ashfield 2011-09-02 15:49 ` McClintock Matthew-B29882 2011-09-02 19:39 ` Tom Zanussi 2 siblings, 0 replies; 6+ messages in thread From: Bruce Ashfield @ 2011-09-02 15:48 UTC (permalink / raw) To: Chris Tapp; +Cc: yocto On 11-09-02 03:26 AM, Chris Tapp wrote: > How should meta data be structured so that a layer can support a set of > systems using a set of processors? > > For example, many of the 'eBox' systems use variants of the Vortex86 > SoC. So, a set of machine files are needed for these (e.g. ebox-3300, > ebox-3500mx, etc.). > > These have different peripherals available (e.g. some have serial, some > don't) and use different SoC variants with different cpu, sound, etc. It > would therefore make sense for the machine configuration to inherit the > SoC attributes (for the common features) and add (or remove) machine > specific attributes (e.g. serial) to these. This can be done by putting > the SoC bits in to an include. > > However, kernel configuration becomes a little bit more complicated as > this is done by machine name. A kernel recipe will be needed for each > machine (e.g. for the different sound drivers), but I can't work out how > to do this using a base configuration for the SoCs that are shared and > then adding machine specific parts. I can do it using (for example) a > .defconfig for each machine, but that would require updates to multiple > files to change the SoC configuration. > > I guess what I'm really asking is, is it possible to have a base CPU > configuration and add a machine configuration to this ? > > I've recently seen discussion of .cfg kernel fragment files. Are these > what I should be looking at? Are these available in the releases or only > in the development branch? What you've described is one of the primary reasons that the configuration fragments exist :) You define a common set of config fragments, extend and then select what you want. These are available in all the releases, but the capabilities are evolving and I merge more changes into the yocto bindings for manipulating the configuration fragments outside of a kernel tree proper. If you have your own kernel repository based on linux-yocto, you could implement any of this inside the tree. If you are re-using existing machines/branches in the linux-yocto tree, you can also do what you want, but have to do it via a collection of configuration fragments that are appended to the SRC_URI based on the machine you are building,. Cheers, Bruce > > Chris Tapp > > opensource@keylevel.com > www.keylevel.com > > > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Splitting processor and target in BSPs 2011-09-02 7:26 Splitting processor and target in BSPs Chris Tapp 2011-09-02 15:48 ` Bruce Ashfield @ 2011-09-02 15:49 ` McClintock Matthew-B29882 2011-09-03 11:32 ` Chris Tapp 2011-09-02 19:39 ` Tom Zanussi 2 siblings, 1 reply; 6+ messages in thread From: McClintock Matthew-B29882 @ 2011-09-02 15:49 UTC (permalink / raw) To: Chris Tapp; +Cc: yocto On Fri, Sep 2, 2011 at 2:26 AM, Chris Tapp <opensource@keylevel.com> wrote: > However, kernel configuration becomes a little bit more complicated as this > is done by machine name. A kernel recipe will be needed for each machine > (e.g. for the different sound drivers), but I can't work out how to do this > using a base configuration for the SoCs that are shared and then adding > machine specific parts. I can do it using (for example) a .defconfig for > each machine, but that would require updates to multiple files to change the > SoC configuration. > > I guess what I'm really asking is, is it possible to have a base CPU > configuration and add a machine configuration to this ? > > I've recently seen discussion of .cfg kernel fragment files. Are these what > I should be looking at? Are these available in the releases or only in the > development branch? I think this is a good solution for you. It's a little confusing to find were this work is but you can look in the linux-yocto kernel tree - then the actual cfg fragment stuff on different branches. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/ meta branch contains meta/ which contains a lot of the cfg fragments, and patches, etc. There is also a document in the git repo as well which is worth a look. -M ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Splitting processor and target in BSPs 2011-09-02 15:49 ` McClintock Matthew-B29882 @ 2011-09-03 11:32 ` Chris Tapp 2011-09-03 14:40 ` Bruce Ashfield 0 siblings, 1 reply; 6+ messages in thread From: Chris Tapp @ 2011-09-03 11:32 UTC (permalink / raw) To: McClintock Matthew-B29882; +Cc: yocto On 2 Sep 2011, at 16:49, McClintock Matthew-B29882 wrote: > On Fri, Sep 2, 2011 at 2:26 AM, Chris Tapp <opensource@keylevel.com> > wrote: >> However, kernel configuration becomes a little bit more complicated >> as this >> is done by machine name. A kernel recipe will be needed for each >> machine >> (e.g. for the different sound drivers), but I can't work out how to >> do this >> using a base configuration for the SoCs that are shared and then >> adding >> machine specific parts. I can do it using (for example) >> a .defconfig for >> each machine, but that would require updates to multiple files to >> change the >> SoC configuration. >> >> I guess what I'm really asking is, is it possible to have a base CPU >> configuration and add a machine configuration to this ? >> >> I've recently seen discussion of .cfg kernel fragment files. Are >> these what >> I should be looking at? Are these available in the releases or only >> in the >> development branch? > > I think this is a good solution for you. It's a little confusing to > find were this work is but you can look in the linux-yocto kernel tree > - then the actual cfg fragment stuff on different branches. > http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/ > > meta branch contains meta/ which contains a lot of the cfg fragments, > and patches, etc. Thanks, I can see what they look like now ;-) What are 'the rules' for cfg files? I.e.: 1) Does adding #CONFIG_this_bit not set disable a node and its dependencies? For example, if I turn off usb serial support do the usb serial drivers get disabled as well or do I have to do this manually? 2) Similarly, if a node is enabled what happens to the dependent nodes? Do they all need to be covered, or only the ones that need to be enabled? I've also noticed that there are scc files. These seem to pull features in to sets? How do these work? meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg contains CONFIG_ATH5K CONFIG_ATH_COMMON ... CONFIG_SERIAL_8250_CONSOLE It seems as if this file does something else, as these don't look like valid kernel configuration options. > There is also a document in the git repo as well which is worth a > look. I couldn't see one, but there's a lot in there ;-) Sorry for all the questions, but there's a lot to understand for someone new :-) Chris Tapp opensource@keylevel.com www.keylevel.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Splitting processor and target in BSPs 2011-09-03 11:32 ` Chris Tapp @ 2011-09-03 14:40 ` Bruce Ashfield 0 siblings, 0 replies; 6+ messages in thread From: Bruce Ashfield @ 2011-09-03 14:40 UTC (permalink / raw) To: Chris Tapp; +Cc: McClintock Matthew-B29882, yocto On 11-09-03 7:32 AM, Chris Tapp wrote: > On 2 Sep 2011, at 16:49, McClintock Matthew-B29882 wrote: > >> On Fri, Sep 2, 2011 at 2:26 AM, Chris Tapp <opensource@keylevel.com> >> wrote: >>> However, kernel configuration becomes a little bit more complicated >>> as this >>> is done by machine name. A kernel recipe will be needed for each machine >>> (e.g. for the different sound drivers), but I can't work out how to >>> do this >>> using a base configuration for the SoCs that are shared and then adding >>> machine specific parts. I can do it using (for example) a .defconfig for >>> each machine, but that would require updates to multiple files to >>> change the >>> SoC configuration. >>> >>> I guess what I'm really asking is, is it possible to have a base CPU >>> configuration and add a machine configuration to this ? >>> >>> I've recently seen discussion of .cfg kernel fragment files. Are >>> these what >>> I should be looking at? Are these available in the releases or only >>> in the >>> development branch? >> >> I think this is a good solution for you. It's a little confusing to >> find were this work is but you can look in the linux-yocto kernel tree >> - then the actual cfg fragment stuff on different branches. >> http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/ >> >> meta branch contains meta/ which contains a lot of the cfg fragments, >> and patches, etc. > > Thanks, I can see what they look like now ;-) > > What are 'the rules' for cfg files? I.e.: > > 1) Does adding #CONFIG_this_bit not set > disable a node and its dependencies? For example, if I turn off usb > serial support do the usb serial drivers get disabled as well or do I > have to do this manually? There's no extra processing on top of what LKC gets you, so yes, that's how it would work. If you disable a top level option in your fragment, lkc will then disable everything that depends on it. > > 2) Similarly, if a node is enabled what happens to the dependent nodes? > Do they all need to be covered, or only the ones that need to be enabled? Same as #1. If you select FOO, you can now select anything that depends on FOO. If FOO has its own "select BAR" statements in it, they'll be enabled in the final .config. So just cover what needs to be enabled. > > I've also noticed that there are scc files. These seem to pull features > in to sets? How do these work? It's best to check the yocto kernel manual for some desriptions on this, rather than me writing it all here. I also have an updated set of docs for 1.1 that I can send along shortly. The .scc files are feature descriptions that cover patches (if you have any), git operations (if you have any) and configuration. They allow a feature and configuration to be kept together and associated. Once in a .scc file, that feature + config can be re-use and imported by other features. > > meta/cfg/kernel-cache/bsp/common-pc/hardware.cfg contains > > CONFIG_ATH5K > CONFIG_ATH_COMMON > ... > CONFIG_SERIAL_8250_CONSOLE > > It seems as if this file does something else, as these don't look like > valid kernel configuration options. Covered in some of the docs, but there is a kernel configuation audit that runs at the end. It is intended to let the user know if something they didn't expect happened. i.e.: - you had CONFIG_FOO=y in your fragment, but the final .config didn't or had it as another value. - high level configuration fragments are supposed to set non-hardware options that are a 'policy' for the system. And BSPs should be setting hardware options. These are the "kconf hardware <foo>.cfg" and "kconf non-hardware <bar>.cfg" that you see in the files. If a BSP option overrides a system policy (and hence may behave differently in an important way), you get a warning. - if an option is repeated you get a warning - if a BSP sets a non-hardware option you get a warning. The config audit has 'buckets' for options that are hardware and non-hardware, so it can emit this warning. But that's not perfect. If a BSP developer says 'hey, this IS hardware for my board', you can list those options in "hardware.cfg" in your BSP dir and the audit system will leave these options out of testing. > >> There is also a document in the git repo as well which is worth a look. > > I couldn't see one, but there's a lot in there ;-) > > Sorry for all the questions, but there's a lot to understand for someone > new :-) Check the docs of the yocto twiki page for some theory and examples. And I'm happy to fill in any blanks (since those would be doc gaps, and I'll write something up). Bruce > > > Chris Tapp > > opensource@keylevel.com > www.keylevel.com > > > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Splitting processor and target in BSPs 2011-09-02 7:26 Splitting processor and target in BSPs Chris Tapp 2011-09-02 15:48 ` Bruce Ashfield 2011-09-02 15:49 ` McClintock Matthew-B29882 @ 2011-09-02 19:39 ` Tom Zanussi 2 siblings, 0 replies; 6+ messages in thread From: Tom Zanussi @ 2011-09-02 19:39 UTC (permalink / raw) To: Chris Tapp; +Cc: yocto On Fri, 2011-09-02 at 00:26 -0700, Chris Tapp wrote: > How should meta data be structured so that a layer can support a set > of systems using a set of processors? > > For example, many of the 'eBox' systems use variants of the Vortex86 > SoC. So, a set of machine files are needed for these (e.g. ebox-3300, > ebox-3500mx, etc.). > > These have different peripherals available (e.g. some have serial, > some don't) and use different SoC variants with different cpu, sound, > etc. It would therefore make sense for the machine configuration to > inherit the SoC attributes (for the common features) and add (or > remove) machine specific attributes (e.g. serial) to these. This can > be done by putting the SoC bits in to an include. > > However, kernel configuration becomes a little bit more complicated as > this is done by machine name. A kernel recipe will be needed for each > machine (e.g. for the different sound drivers), but I can't work out > how to do this using a base configuration for the SoCs that are shared > and then adding machine specific parts. I can do it using (for > example) a .defconfig for each machine, but that would require updates > to multiple files to change the SoC configuration. > > I guess what I'm really asking is, is it possible to have a base CPU > configuration and add a machine configuration to this ? > > I've recently seen discussion of .cfg kernel fragment files. Are these > what I should be looking at? Are these available in the releases or > only in the development branch? > You might also be able to use 'KERNEL_FEATURES' to help manage the .cfg fragments by machine. For example, in the kernel recipes you can see: meta/recipes-kernel/linux/linux-yocto_3.0.bb: # Functionality flags KERNEL_FEATURES="features/netfilter" KERNEL_FEATURES_append=" features/taskstats" KERNEL_FEATURES_append_qemux86=" cfg/sound" KERNEL_FEATURES_append_qemux86-64=" cfg/sound" which map to features in the yocto kernel meta branch. And in the kernel .bbappends in the kernel dev layer some more explanation: poky-extras/meta-kernel-dev/recipes-kernel/linux/linux-yocto_3.0.bbappend: # KERNEL_FEATURES are features to be added to the kernel, and must # point to configurations stored on the 'meta' branch of the kernel # that is being built. # KERNEL_FEATURES ?= <FOO> Tom > Chris Tapp > > opensource@keylevel.com > www.keylevel.com > > > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-03 14:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-02 7:26 Splitting processor and target in BSPs Chris Tapp 2011-09-02 15:48 ` Bruce Ashfield 2011-09-02 15:49 ` McClintock Matthew-B29882 2011-09-03 11:32 ` Chris Tapp 2011-09-03 14:40 ` Bruce Ashfield 2011-09-02 19:39 ` Tom Zanussi
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.