Kernel config fragments are not applied

Kernel config fragments are not applied

[Neuer User]

Hello

I am trying to add a custom kernel config to my layer. I followed the
following guide:
http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#creating-config-fragments

I have the following files in my layer:

recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

inherit kernel
COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"

SRC_URI += "file://videoin.cfg"


recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:

CONFIG_VIDEOBUF_VMALLOC=y
CONFIG_VIDEO_TVEEPROM=y
CONFIG_VIDEO_TUNER=y
CONFIG_VIDEO_ADV7180=y
CONFIG_VIDEO_MXC_CAMERA=y
CONFIG_MXC_TVIN_ADV7180=y
CONFIG_USB_VIDEO_CLASS=y
CONFIG_USB_GSPCA=y
CONFIG_USB_M5602=y
CONFIG_USB_STV06XX=y
...

The layer is included in conf/bblayers.conf. The file videoin.cfg is
found and "installed" in the correct tmp/work directory. However the
config is never added to the kernel config file.

What am I doing wrong?

I use Yocto "master-next", cubox-i4pro.

Thanks

Michael

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-04-28 04:03 AM, Neuer User wrote:
> Hello
>
> I am trying to add a custom kernel config to my layer. I followed the
> following guide:
> http://www.yoctoproject.org/docs/1.6/dev-manual/dev-manual.html#creating-config-fragments
>
> I have the following files in my layer:
>
> recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:

The answer to your question depends on the base linux-cubox-i
recipe.

Config fragment support works for kernels that inherit from linux-yocto,
versus ones that inherit directly from kernel.bbclass. So if you
pop open that base recipe, and look for a reference to linux-yocto.inc,
you'll have the answer.

It is possible to bbappend the linux-yocto support into the kernel
recipe via your layer, and might be worth a try.

The separation between the two classes exists to not break compatibility
with existing kernel recipes, or change long standing oe workflow with
the existing classes.

Cheers,

Bruce

>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> inherit kernel
> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>
> SRC_URI += "file://videoin.cfg"
>
>
> recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:
>
> CONFIG_VIDEOBUF_VMALLOC=y
> CONFIG_VIDEO_TVEEPROM=y
> CONFIG_VIDEO_TUNER=y
> CONFIG_VIDEO_ADV7180=y
> CONFIG_VIDEO_MXC_CAMERA=y
> CONFIG_MXC_TVIN_ADV7180=y
> CONFIG_USB_VIDEO_CLASS=y
> CONFIG_USB_GSPCA=y
> CONFIG_USB_M5602=y
> CONFIG_USB_STV06XX=y
> ...
>
> The layer is included in conf/bblayers.conf. The file videoin.cfg is
> found and "installed" in the correct tmp/work directory. However the
> config is never added to the kernel config file.
>
> What am I doing wrong?
>
> I use Yocto "master-next", cubox-i4pro.
>
> Thanks
>
> Michael
>

Re: Kernel config fragments are not applied

[Neuer User]

Am 28.04.2014 15:03, schrieb Bruce Ashfield:
> 
> The answer to your question depends on the base linux-cubox-i
> recipe.
> 
> Config fragment support works for kernels that inherit from linux-yocto,
> versus ones that inherit directly from kernel.bbclass. So if you
> pop open that base recipe, and look for a reference to linux-yocto.inc,
> you'll have the answer.
> 
> It is possible to bbappend the linux-yocto support into the kernel
> recipe via your layer, and might be worth a try.
> 
> The separation between the two classes exists to not break compatibility
> with existing kernel recipes, or change long standing oe workflow with
> the existing classes.
> 
> Cheers,
> 
> Bruce
> 
Ahh, I see. That is probably the reason then. It includes from linux-imx:

include recipes-kernel/linux/linux-imx.inc

Now, should I just forget the fragment idea and use my own defconfig
file? Or can I just include linux-yocto.inc in my bbappend?

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-04-28 09:14 AM, Neuer User wrote:
> Am 28.04.2014 15:03, schrieb Bruce Ashfield:
>>
>> The answer to your question depends on the base linux-cubox-i
>> recipe.
>>
>> Config fragment support works for kernels that inherit from linux-yocto,
>> versus ones that inherit directly from kernel.bbclass. So if you
>> pop open that base recipe, and look for a reference to linux-yocto.inc,
>> you'll have the answer.
>>
>> It is possible to bbappend the linux-yocto support into the kernel
>> recipe via your layer, and might be worth a try.
>>
>> The separation between the two classes exists to not break compatibility
>> with existing kernel recipes, or change long standing oe workflow with
>> the existing classes.
>>
>> Cheers,
>>
>> Bruce
>>
> Ahh, I see. That is probably the reason then. It includes from linux-imx:
>
> include recipes-kernel/linux/linux-imx.inc
>
> Now, should I just forget the fragment idea and use my own defconfig
> file? Or can I just include linux-yocto.inc in my bbappend?

It all depends on how adventurous you are today :) Using a defconfig
will work, and you can generate one without much trouble. Using
fragments will allow you to keep your changes separate from the
baseline configuration, but you'll need to tweak the recipe .. which
always carries a risk of some unexpected side effects.

I'm around to help regardless of which way you chose.

Cheers,

Bruce

>

Re: Kernel config fragments are not applied

[Neuer User]

Am 28.04.2014 15:16, schrieb Bruce Ashfield:
> It all depends on how adventurous you are today :) Using a defconfig
> will work, and you can generate one without much trouble. Using
> fragments will allow you to keep your changes separate from the
> baseline configuration, but you'll need to tweak the recipe .. which
> always carries a risk of some unexpected side effects.
> 
> I'm around to help regardless of which way you chose.
> 
> Cheers,
> 
> Bruce
> 

Well, I looked at the linux-yocto file and tried a couple of
combinations in my bbappend. All of them geenrated lots of different errors.

e.g. I used:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"

SRC_URI += "file://videoin.cfg"

addtask kernel_configme before do_configure after do_patch

# Pick up shared functions
inherit kernel
inherit kernel-yocto
#require linux-dtb.inc

# extra tasks
addtask kernel_configcheck after do_configure before do_compile


The error messages are too long to include here :-/

Guess, it is probably best to go the defconfig way.

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-04-28 09:35 AM, Neuer User wrote:
> Am 28.04.2014 15:16, schrieb Bruce Ashfield:
>> It all depends on how adventurous you are today :) Using a defconfig
>> will work, and you can generate one without much trouble. Using
>> fragments will allow you to keep your changes separate from the
>> baseline configuration, but you'll need to tweak the recipe .. which
>> always carries a risk of some unexpected side effects.
>>
>> I'm around to help regardless of which way you chose.
>>
>> Cheers,
>>
>> Bruce
>>
>
> Well, I looked at the linux-yocto file and tried a couple of
> combinations in my bbappend. All of them geenrated lots of different errors.

If you send me pointers to your bblayers and local.conf settings, I'll
run a build to see what happens here as well.

I'm always interested in tracking these down regardless.

Bruce

>
> e.g. I used:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>
> SRC_URI += "file://videoin.cfg"
>
> addtask kernel_configme before do_configure after do_patch
>
> # Pick up shared functions
> inherit kernel
> inherit kernel-yocto
> #require linux-dtb.inc
>
> # extra tasks
> addtask kernel_configcheck after do_configure before do_compile
>
>
> The error messages are too long to include here :-/
>
> Guess, it is probably best to go the defconfig way.
>

Re: Kernel config fragments are not applied

[Neuer User]

Am 28.04.2014 15:37, schrieb Bruce Ashfield:
> 
> If you send me pointers to your bblayers and local.conf settings, I'll
> run a build to see what happens here as well.
> 
> I'm always interested in tracking these down regardless.
> 
> Bruce
> 

Testing this should be pretty straightforward, if see that correctly.

Just init the repo with yocto master-next. Then export MACHINE=cubox-i.

My layer has:

recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:

FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

inherit kernel
COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"

SRC_URI += "file://videoin.cfg"


And in recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:

CONFIG_VIDEO_ADV7180=y

(for a test this should suffice)

Then after a "bitbake linux-cubix-i -c configure" you can grep ADV7180
in tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/git/.config

Normally it is "=n", now it should be "=y".

Thanks

Michael

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-04-28 09:54 AM, Neuer User wrote:
> Am 28.04.2014 15:37, schrieb Bruce Ashfield:
>>
>> If you send me pointers to your bblayers and local.conf settings, I'll
>> run a build to see what happens here as well.
>>
>> I'm always interested in tracking these down regardless.
>>
>> Bruce
>>
>
> Testing this should be pretty straightforward, if see that correctly.
>
> Just init the repo with yocto master-next. Then export MACHINE=cubox-i.
>
> My layer has:
>
> recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:

Can you send me your bblayers out of band ? I'm using meta-fsl-arm
and meta-fsl-arm-extra to get a build going, and running into
expansion errors in the kernel recipes. Rather than hunt around
more than necessary, I'll check against your layers.

Bruce

>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> inherit kernel
> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>
> SRC_URI += "file://videoin.cfg"
>
>
> And in recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:
>
> CONFIG_VIDEO_ADV7180=y
>
> (for a test this should suffice)
>
> Then after a "bitbake linux-cubix-i -c configure" you can grep ADV7180
> in tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/git/.config
>
> Normally it is "=n", now it should be "=y".
>
> Thanks
>
> Michael
>

Re: Kernel config fragments are not applied

[Neuer User]

Am 30.04.2014 20:44, schrieb Bruce Ashfield:
> Can you send me your bblayers out of band ? I'm using meta-fsl-arm
> and meta-fsl-arm-extra to get a build going, and running into
> expansion errors in the kernel recipes. Rather than hunt around
> more than necessary, I'll check against your layers.
> 
> Bruce
> 
Sure:

LCONF_VERSION = "6"

BBPATH = "${TOPDIR}"
BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) +
'/../..')}"

BBFILES ?= ""
BBLAYERS = " \
  ${BSPDIR}/sources/poky/meta \
  ${BSPDIR}/sources/poky/meta-yocto \
  \
  ${BSPDIR}/sources/meta-openembedded/meta-oe \
  ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
  \
  ${BSPDIR}/sources/meta-fsl-arm \
  ${BSPDIR}/sources/meta-fsl-arm-extra \
  ${BSPDIR}/sources/meta-fsl-demos \
  ${BSPDIR}/sources/meta-openembedded/meta-ruby \
  ${BSPDIR}/sources/meta-qt5 \
  ${BSPDIR}/sources/meta-mylayer \
"

 Not sure that you need all. meta-ruby and qt5 is needed for my application.

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-04-30 03:16 PM, Neuer User wrote:
> Am 30.04.2014 20:44, schrieb Bruce Ashfield:
>> Can you send me your bblayers out of band ? I'm using meta-fsl-arm
>> and meta-fsl-arm-extra to get a build going, and running into
>> expansion errors in the kernel recipes. Rather than hunt around
>> more than necessary, I'll check against your layers.
>>
>> Bruce
>>
> Sure:
>
> LCONF_VERSION = "6"
>
> BBPATH = "${TOPDIR}"
> BSPDIR := "${@os.path.abspath(os.path.dirname(d.getVar('FILE', True)) +
> '/../..')}"
>
> BBFILES ?= ""
> BBLAYERS = " \
>    ${BSPDIR}/sources/poky/meta \
>    ${BSPDIR}/sources/poky/meta-yocto \
>    \
>    ${BSPDIR}/sources/meta-openembedded/meta-oe \
>    ${BSPDIR}/sources/meta-openembedded/meta-multimedia \
>    \
>    ${BSPDIR}/sources/meta-fsl-arm \
>    ${BSPDIR}/sources/meta-fsl-arm-extra \
>    ${BSPDIR}/sources/meta-fsl-demos \
>    ${BSPDIR}/sources/meta-openembedded/meta-ruby \
>    ${BSPDIR}/sources/meta-qt5 \
>    ${BSPDIR}/sources/meta-mylayer \
> "

Hrm. I have all the key layers right, which leaves me with the expansion
issue. The README indicates the danny branch for the meta-fsl-* layers,
is that what you are using ?

Bruce

>
>   Not sure that you need all. meta-ruby and qt5 is needed for my application.
>
>

Re: Kernel config fragments are not applied

[Neuer User]

Am 30.04.2014 21:21, schrieb Bruce Ashfield:
> 
> Hrm. I have all the key layers right, which leaves me with the expansion
> issue. The README indicates the danny branch for the meta-fsl-* layers,
> is that what you are using ?
> 
> Bruce
> 
No, I'm using master-next. Only in master-next you can find the cubox-i
machine definition.

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-04-28 09:54 AM, Neuer User wrote:
> Am 28.04.2014 15:37, schrieb Bruce Ashfield:
>>
>> If you send me pointers to your bblayers and local.conf settings, I'll
>> run a build to see what happens here as well.
>>
>> I'm always interested in tracking these down regardless.
>>
>> Bruce
>>
>
> Testing this should be pretty straightforward, if see that correctly.

I'm heading out, but wanted to send an update. I can confirm that
there are some issues on master as it currently stands .. but the
good news, is that in my queue of changes for Yocto 1.7, you can
seamlessly add fragement support to that recipe and it works.

I'll be looking at this again later, and will send a branch reference
for testing. I need to bisect for the particular change first, since
the entire queue can't go into the tree yet (it breaks some use cases).
But I will submit the ones that fix this case.

Cheers,

Bruce

>
> Just init the repo with yocto master-next. Then export MACHINE=cubox-i.
>
> My layer has:
>
> recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>
> inherit kernel
> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>
> SRC_URI += "file://videoin.cfg"
>
>
> And in recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:
>
> CONFIG_VIDEO_ADV7180=y
>
> (for a test this should suffice)
>
> Then after a "bitbake linux-cubix-i -c configure" you can grep ADV7180
> in tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/git/.config
>
> Normally it is "=n", now it should be "=y".
>
> Thanks
>
> Michael
>

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 2014-04-30, 5:08 PM, Bruce Ashfield wrote:
> On 14-04-28 09:54 AM, Neuer User wrote:
>> Am 28.04.2014 15:37, schrieb Bruce Ashfield:
>>>
>>> If you send me pointers to your bblayers and local.conf settings, I'll
>>> run a build to see what happens here as well.
>>>
>>> I'm always interested in tracking these down regardless.
>>>
>>> Bruce
>>>
>>
>> Testing this should be pretty straightforward, if see that correctly.
>
> I'm heading out, but wanted to send an update. I can confirm that
> there are some issues on master as it currently stands .. but the
> good news, is that in my queue of changes for Yocto 1.7, you can
> seamlessly add fragement support to that recipe and it works.
>
> I'll be looking at this again later, and will send a branch reference
> for testing. I need to bisect for the particular change first, since
> the entire queue can't go into the tree yet (it breaks some use cases).
> But I will submit the ones that fix this case.

I'm glad that I looked again, I though there was an error without my
clean up series .. but what I was seeing was a legitimate double
application of the patch.

What error where you seeing when you tried a bbappend like so:

------------
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"

SRC_URI += "file://videoin.cfg"
--------------

Your error message will set me straight .. and tell me if it is just
the late night hacking fooling my eyes .. or not!


Bruce

>
> Cheers,
>
> Bruce
>
>>
>> Just init the repo with yocto master-next. Then export MACHINE=cubox-i.
>>
>> My layer has:
>>
>> recipes-kernel/linux/linux-cubox-i_3.0.35.bbappend:
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>
>> inherit kernel
>> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>>
>> SRC_URI += "file://videoin.cfg"
>>
>>
>> And in recipes-kernel/linux/linux-cubox-i-3.0.35/videoin.cfg:
>>
>> CONFIG_VIDEO_ADV7180=y
>>
>> (for a test this should suffice)
>>
>> Then after a "bitbake linux-cubix-i -c configure" you can grep ADV7180
>> in
>> tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/git/.config
>>
>> Normally it is "=n", now it should be "=y".
>>
>> Thanks
>>
>> Michael
>>
>

Re: Kernel config fragments are not applied

[Neuer User]

Hi Bruce

Here is the error messega, I get after a "bitbake linux-cubox-i -c
cleansstate; bitbake linux-cubox-i" using the recipe you posted:

ERROR: Function failed: do_patch (log file is located at
/home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
ERROR: Logfile of failure stored in:
/home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660
Log data follows:
| DEBUG: Executing shell function do_patch
| WARNING: no meta data branch found ...
| ls: cannot access .meta*: No such file or directory
| Already on 'imx_3.0.35_4.1.0'
| [INFO] validating against known patches  (cubox-i-standard-meta)
error: patch failed: arch/arm/lib/memset.S:19#############] (/)(110 %)
| error: arch/arm/lib/memset.S: patch does not apply
| ERROR. could not update git tree
| ERROR. Could not apply patches for cubox-i.
|        Patch failures can be resolved in the devshell (bitbake -c
devshell linux-cubox-i)
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_patch (log file is located at
/home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
ERROR: Task 3
(/home/ubuntu/yocto/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-cubox-i_3.0.35.bb,
do_patch) failed with exit code '1'

Hope, it helps!

Michael

Am 01.05.2014 06:29, schrieb Bruce Ashfield:
> I'm glad that I looked again, I though there was an error without my
> clean up series .. but what I was seeing was a legitimate double
> application of the patch.
> 
> What error where you seeing when you tried a bbappend like so:
> 
> ------------
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> 
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
> 
> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
> 
> SRC_URI += "file://videoin.cfg"
> --------------
> 
> Your error message will set me straight .. and tell me if it is just
> the late night hacking fooling my eyes .. or not!
> 
> 
> Bruce

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-05-01 02:32 AM, Neuer User wrote:
> Hi Bruce
>
> Here is the error messega, I get after a "bitbake linux-cubox-i -c
> cleansstate; bitbake linux-cubox-i" using the recipe you posted:

Aha. This is what I was seeing as well, and there's some issues and 
assumptions
that are built into those kernel recipes that are causing the yocto
tools to attempt a patch (which is already on the branch) and hence
the failure (the recipes should really be tweaked .. but I digress).

I'm prepping a small patch that will have this particular recipe and
use case working out of the box.

Bruce

>
> ERROR: Function failed: do_patch (log file is located at
> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
> ERROR: Logfile of failure stored in:
> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660
> Log data follows:
> | DEBUG: Executing shell function do_patch
> | WARNING: no meta data branch found ...
> | ls: cannot access .meta*: No such file or directory
> | Already on 'imx_3.0.35_4.1.0'
> | [INFO] validating against known patches  (cubox-i-standard-meta)
> error: patch failed: arch/arm/lib/memset.S:19#############] (/)(110 %)
> | error: arch/arm/lib/memset.S: patch does not apply
> | ERROR. could not update git tree
> | ERROR. Could not apply patches for cubox-i.
> |        Patch failures can be resolved in the devshell (bitbake -c
> devshell linux-cubox-i)
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_patch (log file is located at
> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
> ERROR: Task 3
> (/home/ubuntu/yocto/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-cubox-i_3.0.35.bb,
> do_patch) failed with exit code '1'
>
> Hope, it helps!
>
> Michael
>
> Am 01.05.2014 06:29, schrieb Bruce Ashfield:
>> I'm glad that I looked again, I though there was an error without my
>> clean up series .. but what I was seeing was a legitimate double
>> application of the patch.
>>
>> What error where you seeing when you tried a bbappend like so:
>>ll ticking.. ;-)

If anyone has more suggestions or info, please let me know! I’ll keep 
you posted.

Update: Just reached 4 days of uptime!

Update 2: Today it’s 4 month’s after I wrote this blog. The machine is 
still up & running and has reached 106 days of uptime!

Update 3: After 7 months (222 days of uptime) I finally retired the 
machine since we migrated to our CloudStack cloud. The fix described ab
>> ------------
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>>
>> SRC_URI += "file://videoin.cfg"
>> --------------
>>
>> Your error message will set me straight .. and tell me if it is just
>> the late night hacking fooling my eyes .. or not!
>>
>>
>> Bruce
>
>

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-05-01 01:12 PM, Bruce Ashfield wrote:
> On 14-05-01 02:32 AM, Neuer User wrote:
>> Hi Bruce
>>
>> Here is the error messega, I get after a "bitbake linux-cubox-i -c
>> cleansstate; bitbake linux-cubox-i" using the recipe you posted:
>
> Aha. This is what I was seeing as well, and there's some issues and
> assumptions
> that are built into those kernel recipes that are causing the yocto
> tools to attempt a patch (which is already on the branch) and hence
> the failure (the recipes should really be tweaked .. but I digress).
>
> I'm prepping a small patch that will have this particular recipe and
> use case working out of the box.

... and I managed to get this working without a patch. You just
need the following as your bbappend:

----------------
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"

inherit kernel
require recipes-kernel/linux/linux-yocto.inc

COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"

SRC_URI += "file://videoin.cfg"

SRCREV_machine = "${SRCREV}"
----------------

The key is the addition of SRCREV_machine. It deals with the issue
that I mentioned with the kernel recipes. They have a series of patches
that are already on the branch being built. But yet the SRCREV backs
the branch off and allows the patches to apply (something I wouldn't
do .. but that's not the point).

The linux-yocto validation can do a similar back off, but it currently
triggers on SRCREV_machine, which wasn't set .. this is already fixed
in my current series that will go out for Yocto 1.7.

After this:

]> pwd
/home/bruce/poky/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0
yow-bashfiel-d3 [/home/bruc.../3.0.35-r0]> grep CONFIG_VIDEO_ADV7180 
linux-cubox_i-standard-build/.config
CONFIG_VIDEO_ADV7180=y

Note, the fragment you were working with needs this:

 > cat videoin.cfg
CONFIG_VIDEO_CAPTURE_DRIVERS=y
CONFIG_VIDEO_ADV7180=y

Or you'll be missing a dependency and have the config dropped from
the final .config.

Bruce


>
> Bruce
>
>>
>> ERROR: Function failed: do_patch (log file is located at
>> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
>>
>> ERROR: Logfile of failure stored in:
>> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660
>>
>> Log data follows:
>> | DEBUG: Executing shell function do_patch
>> | WARNING: no meta data branch found ...
>> | ls: cannot access .meta*: No such file or directory
>> | Already on 'imx_3.0.35_4.1.0'
>> | [INFO] validating against known patches  (cubox-i-standard-meta)
>> error: patch failed: arch/arm/lib/memset.S:19#############] (/)(110 %)
>> | error: arch/arm/lib/memset.S: patch does not apply
>> | ERROR. could not update git tree
>> | ERROR. Could not apply patches for cubox-i.
>> |        Patch failures can be resolved in the devshell (bitbake -c
>> devshell linux-cubox-i)
>> | WARNING: exit code 1 from a shell command.
>> | ERROR: Function failed: do_patch (log file is located at
>> /home/ubuntu/yocto/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0/temp/log.do_patch.5660)
>>
>> ERROR: Task 3
>> (/home/ubuntu/yocto/sources/meta-fsl-arm-extra/recipes-kernel/linux/linux-cubox-i_3.0.35.bb,
>>
>> do_patch) failed with exit code '1'
>>
>> Hope, it helps!
>>
>> Michael
>>
>> Am 01.05.2014 06:29, schrieb Bruce Ashfield:
>>> I'm glad that I looked again, I though there was an error without my
>>> clean up series .. but what I was seeing was a legitimate double
>>> application of the patch.
>>>
>>> What error where you seeing when you tried a bbappend like so:
>>> ll ticking.. ;-)
>
> If anyone has more suggestions or info, please let me know! I’ll keep
> you posted.
>
> Update: Just reached 4 days of uptime!
>
> Update 2: Today it’s 4 month’s after I wrote this blog. The machine is
> still up & running and has reached 106 days of uptime!
>
> Update 3: After 7 months (222 days of uptime) I finally retired the
> machine since we migrated to our CloudStack cloud. The fix described ab
>>> ------------
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>>
>>> inherit kernel
>>> require recipes-kernel/linux/linux-yocto.inc
>>>
>>> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>>>
>>> SRC_URI += "file://videoin.cfg"
>>> --------------
>>>
>>> Your error message will set me straight .. and tell me if it is just
>>> the late night hacking fooling my eyes .. or not!
>>>
>>>
>>> Bruce
>>
>>
>

Re: Kernel config fragments are not applied

[Neuer User]

That's great! And just one line to add. Perfect solution!

Thanks a lot!

Michael

Am 02.05.2014 19:24, schrieb Bruce Ashfield:
> On 14-05-01 01:12 PM, Bruce Ashfield wrote:
>> On 14-05-01 02:32 AM, Neuer User wrote:
>>> Hi Bruce
>>>
>>> Here is the error messega, I get after a "bitbake linux-cubox-i -c
>>> cleansstate; bitbake linux-cubox-i" using the recipe you posted:
>>
>> Aha. This is what I was seeing as well, and there's some issues and
>> assumptions
>> that are built into those kernel recipes that are causing the yocto
>> tools to attempt a patch (which is already on the branch) and hence
>> the failure (the recipes should really be tweaked .. but I digress).
>>
>> I'm prepping a small patch that will have this particular recipe and
>> use case working out of the box.
> 
> ... and I managed to get this working without a patch. You just
> need the following as your bbappend:
> 
> ----------------
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
> 
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
> 
> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
> 
> SRC_URI += "file://videoin.cfg"
> 
> SRCREV_machine = "${SRCREV}"
> ----------------
> 
> The key is the addition of SRCREV_machine. It deals with the issue
> that I mentioned with the kernel recipes. They have a series of patches
> that are already on the branch being built. But yet the SRCREV backs
> the branch off and allows the patches to apply (something I wouldn't
> do .. but that's not the point).
> 
> The linux-yocto validation can do a similar back off, but it currently
> triggers on SRCREV_machine, which wasn't set .. this is already fixed
> in my current series that will go out for Yocto 1.7.
> 
> After this:
> 
> ]> pwd
> /home/bruce/poky/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.0.35-r0
> 
> yow-bashfiel-d3 [/home/bruc.../3.0.35-r0]> grep CONFIG_VIDEO_ADV7180
> linux-cubox_i-standard-build/.config
> CONFIG_VIDEO_ADV7180=y
> 
> Note, the fragment you were working with needs this:
> 
>> cat videoin.cfg
> CONFIG_VIDEO_CAPTURE_DRIVERS=y
> CONFIG_VIDEO_ADV7180=y
> 
> Or you'll be missing a dependency and have the config dropped from
> the final .config.
> 
> Bruce
> 

Re: Kernel config fragments are not applied

[Neuer User]

Hi Bruce

Have you got any further?

I currently use a "defconfig" replacement, but honestly, it feels very
dumb. Fragments seem to be much smarter to combine and test different
configurations.

Cheers

Michael

Am 28.04.2014 15:37, schrieb Bruce Ashfield:
> On 14-04-28 09:35 AM, Neuer User wrote:
>> Am 28.04.2014 15:16, schrieb Bruce Ashfield:
>>> It all depends on how adventurous you are today :) Using a defconfig
>>> will work, and you can generate one without much trouble. Using
>>> fragments will allow you to keep your changes separate from the
>>> baseline configuration, but you'll need to tweak the recipe .. which
>>> always carries a risk of some unexpected side effects.
>>>
>>> I'm around to help regardless of which way you chose.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>
>> Well, I looked at the linux-yocto file and tried a couple of
>> combinations in my bbappend. All of them geenrated lots of different
>> errors.
> 
> If you send me pointers to your bblayers and local.conf settings, I'll
> run a build to see what happens here as well.
> 
> I'm always interested in tracking these down regardless.
> 
> Bruce
> 
>>
>> e.g. I used:
>>
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>
>> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>>
>> SRC_URI += "file://videoin.cfg"
>>
>> addtask kernel_configme before do_configure after do_patch
>>
>> # Pick up shared functions
>> inherit kernel
>> inherit kernel-yocto
>> #require linux-dtb.inc
>>
>> # extra tasks
>> addtask kernel_configcheck after do_configure before do_compile
>>
>>
>> The error messages are too long to include here :-/
>>
>> Guess, it is probably best to go the defconfig way.
>>
> 

Re: Kernel config fragments are not applied

[Bruce Ashfield]

On 14-04-30 06:24 AM, Neuer User wrote:
> Hi Bruce
>
> Have you got any further?

Your timing is good. I was preeempted by another issue yesterday, but
I have the fsl-imx layers cloned and am about to start a build. I'll
send a follow up when I know more.

Bruce

>
> I currently use a "defconfig" replacement, but honestly, it feels very
> dumb. Fragments seem to be much smarter to combine and test different
> configurations.
>
> Cheers
>
> Michael
>
> Am 28.04.2014 15:37, schrieb Bruce Ashfield:
>> On 14-04-28 09:35 AM, Neuer User wrote:
>>> Am 28.04.2014 15:16, schrieb Bruce Ashfield:
>>>> It all depends on how adventurous you are today :) Using a defconfig
>>>> will work, and you can generate one without much trouble. Using
>>>> fragments will allow you to keep your changes separate from the
>>>> baseline configuration, but you'll need to tweak the recipe .. which
>>>> always carries a risk of some unexpected side effects.
>>>>
>>>> I'm around to help regardless of which way you chose.
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>
>>> Well, I looked at the linux-yocto file and tried a couple of
>>> combinations in my bbappend. All of them geenrated lots of different
>>> errors.
>>
>> If you send me pointers to your bblayers and local.conf settings, I'll
>> run a build to see what happens here as well.
>>
>> I'm always interested in tracking these down regardless.
>>
>> Bruce
>>
>>>
>>> e.g. I used:
>>>
>>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
>>>
>>> COMPATIBLE_MACHINE_cubox-i = "(cubox-i)"
>>>
>>> SRC_URI += "file://videoin.cfg"
>>>
>>> addtask kernel_configme before do_configure after do_patch
>>>
>>> # Pick up shared functions
>>> inherit kernel
>>> inherit kernel-yocto
>>> #require linux-dtb.inc
>>>
>>> # extra tasks
>>> addtask kernel_configcheck after do_configure before do_compile
>>>
>>>
>>> The error messages are too long to include here :-/
>>>
>>> Guess, it is probably best to go the defconfig way.
>>>
>>
>
>