All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: "Paul D. DeRocco" <pderocco@ix.netcom.com>, <yocto@yoctoproject.org>
Subject: Re: Kernel config fragments ignored
Date: Tue, 30 May 2017 21:25:35 -0400	[thread overview]
Message-ID: <719d84c4-a891-c7d0-2c5d-316e9b98ae1d@windriver.com> (raw)
In-Reply-To: <6DDD0E6DF5E245EEBEE64A478C162BBD@PAULD>

On 2017-05-30 9:15 PM, Paul D. DeRocco wrote:
>> From: Paul D. DeRocco
>>
>> I ported a working build from Fido to Morty, made a few
>> tweaks in response
>> to error messages (mostly updating version numbers), but it's
>> not finding
>> my kernel configuration fragments. This is supposed to be an i386 arch
>> system, but it insists upon building an x86_64 kernel. The
>> .config file it
>> generates does not include my configuration fragments, which contain
>> things like CONFIG_64BIT=n and CONFIG_X86_32=y.
> 
> I'm still stumped by this, but I've debugged it further. My top level
> chroma32-bsp-preempt-rt.scc file contains (among other things) the line
> 
>      include ktypes/preempt-rt/preempt-rt.scc nopatch
> 
> Building the kernel copies the following files into
> tmp/work/chroma32_bsp-poky-linux/linux-yocto-rt/4.8.12+blahblah
> 
>      chroma32-bsp-user-config.cfg
>      chroma32-bsp-user-features.scc (empty)
> 
> but it doesn't copy the following files anywhere
> 
>      chroma32-bsp-preempt-rt.scc
>      chroma32-bsp.scc
>      chroma32-bsp.cfg
> 
> so none of the values from either .cfg file appear in the resulting
> .config file.
> 
> If I change the above line to
> 
>      include ktypes/standard/standard.scc nopatch
> 
> then tmp/work/chroma32_bsp-poky-linux/linux-yocto-rt/4.8.12+blahblah
> contains
> 
>      chroma32-bsp-preempt-rt.scc
>      chroma32-bsp-user-config.cfg
>      chroma32-bsp-user-features.scc (empty)
> 
> and
> tmp/work-shared/chroma32-bsp/kernel-source/.kernel-meta/configs/standard
> contains
> 
>      chroma32-bsp.cfg
>      chroma32-bsp-user-config.cfg
> 
> and everything in them is included in the .config file.
> 
> Both the preempt-rt.scc and standard.scc files pull in a lot of stuff, and
> they are quite different from each other. What difference between the two
> could account for my config fragments being ignored when I use the first
> one?

It wouldn't be the difference.

Is this something that I can configure and build myself ? I changed
the processing model between those releases, but I tested migration
of a few BSPs and they all worked.

So something different is happening here.

I can't say what is is just by reading the description, but if I could
build something like you are describing, I can figure out what's happening.

Bruce

> 






      reply	other threads:[~2017-05-31  1:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-29  7:21 Kernel config fragments ignored Paul D. DeRocco
2017-05-29 14:38 ` Leonardo Sandoval
2017-05-31  1:15 ` Paul D. DeRocco
2017-05-31  1:25   ` Bruce Ashfield [this message]

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=719d84c4-a891-c7d0-2c5d-316e9b98ae1d@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=pderocco@ix.netcom.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.