Skip to contentSkip to conversation

linux-yocto (dylan 3.8) arm and recipe-space issues

DISCUSSION Peter A. Bigot 2 participants 3 messages Aug 9, 2013

lore
Share & tools
lore
#0 lore raw

I'm trying to use linux-yocto_3.8 under dylan (poky at 899e5cc) for gumstix overo as an experiment. Since there are no overo files in the meta branch of the linux-yocto-3.8 repo, I'm using recipe-space metadata. I've run into two anomalies.

First, in-tree metadata is still being found and referenced, which is good. In my case $KARCH=arm which brings in arm.scc, and arm.cfg has:

# Failure to use this on ARM results in lots of interesting runtime bugs. CONFIG_CC_OPTIMIZE_FOR_SIZE=y

But "bitbake linux-yocto -c kernel_configcheck" produces a merge_log.txt that has:

Using meta/cfg/kernel-cache/ktypes/base/base.cfg.sanitized as base Merging meta/cfg/kernel-cache/features/kgdb/kgdb.cfg.sanitized
...
Merging meta/cfg/kernel-cache/arch/arm/arm.cfg.sanitized
...
Merging meta/cfg/kernel-cache/ktypes/standard/standard.cfg.sanitized Value of CONFIG_CC_OPTIMIZE_FOR_SIZE is redefined by fragment
meta/cfg/kernel-cache/ktypes/standard/standard.cfg.sanitized:
Previous value: CONFIG_CC_OPTIMIZE_FOR_SIZE=y
New value: # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

and indeed CONFIG_CC_OPTIMIZE_FOR_SIZE is not set in the resulting config file. This seems wrong, and I haven't been able to figure out how to fix it. That it's not diagnosed by kernel_configcheck also seems wrong.

Second, seeing in that file that various features are being pulled in from in-tree meta/cfg/kernel-cache/features, in my recipe-space overo.scc I have:

include features/spi/spi.scc

because the in-tree metadata has that fragment with the contents I want. It seems that because the reference is from a file in recipe-space the existing metadata from in-tree isn't found in this case, and I have to copy it into recipe-space FILESEXTRAPATHS for it to be found.

Is there a way to reference in-tree metadata from a recipe-space scc file so I don't have to duplicate it?

Thanks.

Peter

#1 lore raw
Quoted 25 lines · Peter A. Bigot

I'm trying to use linux-yocto_3.8 under dylan (poky at 899e5cc) for gumstix overo as an experiment. Since there are no overo files in the meta branch of the linux-yocto-3.8 repo, I'm using recipe-space metadata. I've run into two anomalies.

First, in-tree metadata is still being found and referenced, which is good. In my case $KARCH=arm which brings in arm.scc, and arm.cfg has:

# Failure to use this on ARM results in lots of interesting runtime bugs. CONFIG_CC_OPTIMIZE_FOR_SIZE=y

But "bitbake linux-yocto -c kernel_configcheck" produces a merge_log.txt that has:

Using meta/cfg/kernel-cache/ktypes/base/base.cfg.sanitized as base Merging meta/cfg/kernel-cache/features/kgdb/kgdb.cfg.sanitized
...
Merging meta/cfg/kernel-cache/arch/arm/arm.cfg.sanitized
...
Merging meta/cfg/kernel-cache/ktypes/standard/standard.cfg.sanitized Value of CONFIG_CC_OPTIMIZE_FOR_SIZE is redefined by fragment
meta/cfg/kernel-cache/ktypes/standard/standard.cfg.sanitized:
Previous value: CONFIG_CC_OPTIMIZE_FOR_SIZE=y
New value: # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

Quoted 3 lines

and indeed CONFIG_CC_OPTIMIZE_FOR_SIZE is not set in the resulting config file. This seems wrong, and I haven't been able to figure out how to fix it. That it's not diagnosed by kernel_configcheck also seems wrong.

Definitely something odd going on here, we do want CONFIG_CC_OPTIMIZE_FOR_SIZE=y to be in the resulting configs. BSPs can disable it, but the default is set.

Let me have a poke at this, and get back to you.

Quoted 6 lines

Second, seeing in that file that various features are being pulled in from in-tree meta/cfg/kernel-cache/features, in my recipe-space overo.scc I have:

include features/spi/spi.scc

Quoted 7 lines

because the in-tree metadata has that fragment with the contents I want. It seems that because the reference is from a file in recipe-space the existing metadata from in-tree isn't found in this case, and I have to copy it into recipe-space FILESEXTRAPATHS for it to be found.

Is there a way to reference in-tree metadata from a recipe-space scc file so I don't have to duplicate it?

Absolutely, use:

KERNEL_FEATURES += " features/spi/spi.scc"

in your recipe, and you'll reach in and reuse the fragments and follow the kernel tree around.

Cheers,

Bruce

Quoted 8 lines

Thanks.

Peter
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
#2 lore raw
Quoted 26 lines · Bruce Ashfield
Quoted 25 lines · Peter A. Bigot

I'm trying to use linux-yocto_3.8 under dylan (poky at 899e5cc) for gumstix overo as an experiment. Since there are no overo files in the meta branch of the linux-yocto-3.8 repo, I'm using recipe-space metadata. I've run into two anomalies.

First, in-tree metadata is still being found and referenced, which is good. In my case $KARCH=arm which brings in arm.scc, and arm.cfg has:

# Failure to use this on ARM results in lots of interesting runtime bugs. CONFIG_CC_OPTIMIZE_FOR_SIZE=y

But "bitbake linux-yocto -c kernel_configcheck" produces a merge_log.txt that has:

Using meta/cfg/kernel-cache/ktypes/base/base.cfg.sanitized as base Merging meta/cfg/kernel-cache/features/kgdb/kgdb.cfg.sanitized
...
Merging meta/cfg/kernel-cache/arch/arm/arm.cfg.sanitized
...
Merging meta/cfg/kernel-cache/ktypes/standard/standard.cfg.sanitized Value of CONFIG_CC_OPTIMIZE_FOR_SIZE is redefined by fragment
meta/cfg/kernel-cache/ktypes/standard/standard.cfg.sanitized:
Previous value: CONFIG_CC_OPTIMIZE_FOR_SIZE=y
New value: # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

Quoted 7 lines
Quoted 3 lines

and indeed CONFIG_CC_OPTIMIZE_FOR_SIZE is not set in the resulting config file. This seems wrong, and I haven't been able to figure out how to fix it. That it's not diagnosed by kernel_configcheck also seems wrong.

Definitely something odd going on here, we do want CONFIG_CC_OPTIMIZE_FOR_SIZE=y to be in the resulting configs. BSPs can disable it, but the default is set.

Let me have a poke at this, and get back to you.

FWIW, there's a bunch of other things in merge_log.txt that look peculiar, like:

Value requested for CONFIG_HZ not in final .config Requested value: CONFIG_HZ=100
Actual value: CONFIG_HZ=128

Quoted 11 lines
Quoted 11 lines

Second, seeing in that file that various features are being pulled in from in-tree meta/cfg/kernel-cache/features, in my recipe-space overo.scc I have:

include features/spi/spi.scc

because the in-tree metadata has that fragment with the contents I want. It seems that because the reference is from a file in recipe-space the existing metadata from in-tree isn't found in this case, and I have to copy it into recipe-space FILESEXTRAPATHS for it to be found.

Quoted 8 lines
Quoted 2 lines

Is there a way to reference in-tree metadata from a recipe-space scc file so I don't have to duplicate it?

Absolutely, use:

KERNEL_FEATURES += " features/spi/spi.scc"

in your recipe, and you'll reach in and reuse the fragments and follow the kernel tree around.

Thanks. I'd rather have them in the machine.scc file, but KERNEL_FEATURES works.

I did get:

| WARNING: addon feature "features/leds/leds" was not found
| WARNING: addon feature "features/spi/spi" was not found
| WARNING: addon feature "features/usb/usb-gadgets" was not found

because meta/recipes-kernel/linux/linux-yocto*_3.8.bb SRCREV_meta hasn't been updated to the tip of the repository branch yet. Similarly SRCREV_machine's default explains why I'm getting 3.8.11 instead of 3.8.13. Easy enough to fix in the recipe.

Peter

Quoted 14 lines

Cheers,

Bruce

Quoted 7 lines

Thanks.

Peter
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core