All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Chris Tapp <opensource@keylevel.com>
Cc: "yocto@yoctoproject.org Project" <yocto@yoctoproject.org>
Subject: Re: yocto-bsp create
Date: Wed, 15 Aug 2012 16:14:10 -0400	[thread overview]
Message-ID: <502C0312.2080905@windriver.com> (raw)
In-Reply-To: <073A7998-3D05-4835-AA03-113960D00553@keylevel.com>

On 12-08-15 04:06 PM, Chris Tapp wrote:
> I've been looking at using yocto-bsp to create a BSP. Good job! Looks like it's going to be much easier to do it this way :-)

You really want TomZ to answer, but I'll throw in a few comments
here, since I'm currently reviewing a batch of code from Tom.

>
> I've got a few questions/comments:
>
> 1) The documentation (7.0.1) says that the machine branch defaults to standard/default, but that is not an option that gets presented when I created a BSP. Should that be standard/base, standard/default/base, or something else? Master shows this as standard/default/common-pc, but that still isn't one of the listed options (standard/default/common-pc/base ?).

For the 3.2 tree, it is standard/default/base, which is a name that we
quickly determined was not optimal, and in the 3.4 kernel tree it is 
standard/base.
So the answer is, it depends on the kernel you are using, but the tools
know and have the right defaults.

>
> 2) What are these machine branches anyway? As in, how do I decide which one I should choose? For an ALIX 3D3 system I used standard/default/common-pc/base. Is that reasonable?

They are collections of functionality and configuration. So if you are
working on a new machine that is close to something that is already
in tree, you'd start from the existing machine branch. If you want to
do something new, standard/base, if you want the preempt-rt kernel,
standard/preempt-rt/base, etc.

>
> 3) I selected core2 as the tune option and then had to change this in the created meta-data as I needed i586 tuning and this was not given as a tune option. Should all available tunes be offered?
>
> 4) Is there any way to select the kernel CPU (I got MATOM but needed MGEODE_LX - easily changed in the<mybsp>.cfg file)?

AFAIK, no. Since that would imply that all the kernel tunings were parsed
and made available. Adding it to your .cfg is the right thing. If
there is a BSP that already falls into your class, and you inherit
it, you'd get the right tuning by default.

>
> 5) The created BSP refers to various feature/x/y.scc files. Are these documented somewhere so that they can be easily re-used, or am I better off simply producing a complete defconfig? A pointer to the documentation for the whole kernel meta data structure would also be helpful.

Tom and I were working on a way to dump these, I'm not sure if that
ever completed. The meta branch of the kernel repo has all the details,
with short descriptions in the .scc files.

As with anything, documenting a moving source code target is hard, so
I suggest looking at the branch.

Have a look at the 3.4 kernel tree, meta branch, there's a README with
details about the categories, and contents.

Cheers,

Bruce

>
> Chris Tapp
>
> opensource@keylevel.com
> www.keylevel.com
>
>
>
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



  reply	other threads:[~2012-08-15 20:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-15 20:06 yocto-bsp create Chris Tapp
2012-08-15 20:14 ` Bruce Ashfield [this message]
2012-08-16 20:26   ` Chris Tapp
2012-08-16 23:48     ` Bruce Ashfield
     [not found]       ` <5053D9BB-9E6B-4D25-B5B0-9B08DBB381E5@keylevel.com>
     [not found]         ` <502E5C6B.7040709@windriver.com>
     [not found]           ` <35B0FBF5-FE52-4C75-BBF6-F260A1954F76@keylevel.com>
     [not found]             ` <502E9C97.6000209@windriver.com>
     [not found]               ` <860E0816-033F-4091-ABFB-A3B699D260BD@keylevel.com>
     [not found]                 ` <502E9FED.8070907@windriver.com>
2012-08-17 19:56                   ` Chris Tapp
2012-08-21 17:50                     ` Tom Zanussi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=502C0312.2080905@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=opensource@keylevel.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.