[yocto] KBUILD_DEFCONFIG_KMACHINE not used anywhere

Alan Martinovic alan.martinovic at senic.com
Thu Nov 9 07:53:06 PST 2017


>
>  - what branch/release of yocto are you using ?


Morty


> - can you try just using: KBUILD_DEFCONFIG="senic_defconfig"


Yup, same error.

.. and finally, the KBUILD_DEFCONFIG processing is meant to pick
> up in-tree defconfigs for use in the build, so whatever you reference
> must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
> sure that is the case with senic_defconfig.


Yup, it's in there.


You can always add the defconfig directly to the SRC_URI as well
> (i.e. copy it into your layer and call it 'defconfig' and add it
> to the SRC_URI like any other element.


Yup, am using that as a workaround .

What is the difference between do_kernel_configme and do_configure?
Not quite clear on why both exist.
I ask because I originally wanted to override do_configure as a fix,
and it seems that wouldn't have helped because it fails at
do_kernel_configme.


On Thu, Nov 9, 2017 at 3:13 PM, Bruce Ashfield <bruce.ashfield at windriver.com
> wrote:

> On 2017-11-09 8:11 AM, Alan Martinovic wrote:
>
>>     What is your kernel recipe ? Something you wrote, or something
>>     from a vendor ?
>>
>>
>> Something I inherited.
>> It does seem to have been based on linux-yocto-custom.bb <
>> http://linux-yocto-custom.bb>.
>>
>>
>> SECTION = "kernel"
>> DESCRIPTION = "Mainline Linux kernel"
>> LICENSE = "GPLv2"
>> LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>>
>> COMPATIBLE_MACHINE = "(senic-hub-beta|senic-hub)"
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> KBRANCH = "senic/4.13"
>> SRCREV = "e469b218af6fe7cb8c50c4395ae9f3204f8033ae"
>>
>> PV = "4.13+git${SRCPV}"
>> S = "${WORKDIR}/git"
>>
>> KBUILD_DEFCONFIG_senic-hub-beta="senic_defconfig"
>>
>> SRC_URI = "git://github.com/TheMeaningfulEngineer/senic-os-linux.git;
>> nobranch=1;protocol=git;branch=${KBRANCH}
>> <http://github.com/TheMeaningfulEngineer/senic-os-linux.git;nobranch=1;protocol=git;branch=$%7BKBRANCH%7D>
>> <http://github.com/TheMeaningfulEngineer/senic-os-linux.git;
>> nobranch=1;protocol=git;branch=${KBRANCH}> \
>>            "
>>
>>
>> Running it with:
>>
>> bitbake -v linux-senic
>>
>>
>> It fails with:
>>
>> ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme:
>> Could not configure senic-hub-beta-standard
>> ERROR: linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme:
>> Function failed: do_kernel_configme (log file is located at
>> /home/alan/senic-o
>> s/build/tmp-glibc/work/senic_hub_beta-senic-linux-gnueabi/li
>> nux-senic/4.13+gitAUTOINC+e469b218af-r0/temp/log.do_kernel_configme.5641)
>>
>> ERROR: Logfile of failure stored in: /home/alan/senic-os/build/tmp-
>> glibc/work/senic_hub_beta-senic-linux-gnueabi/linux-senic/4.
>> 13+gitAUTOINC+e469b2
>> 18af-r0/temp/log.do_kernel_configme.5641
>>
>>
>> Not sure when "-standard" got appended...?
>>
>
> That's just part of the localversion processing in the bbclass, so
> no worries there.
>
> A more exact error seems to be:
>>
>> linux-senic-4.13+gitAUTOINC+e469b218af-r0 do_kernel_configme: +
>> configs=[ERROR]: no configuration queue found in outdir (.kernel-meta)
>>
>> Could it be expecting a "linux-yocto style" with the meta branches?
>>
>>
> Nope. Well, you do need some sort of configuration available, but it
> doesn't have to be in that format.
>
> That error is indicating that no configuration was found (no defconfig
> or fragments).
>
> A couple more questions, and I can probably sort this out.
>
> - what branch/release of yocto are you using ?
> - can you try just using: KBUILD_DEFCONFIG="senic_defconfig"
>
> For that second one, I'm wondering if the variable expansion is not
> working with the machine override.
>
> .. and finally, the KBUILD_DEFCONFIG processing is meant to pick
> up in-tree defconfigs for use in the build, so whatever you reference
> must bein in arch/<your arch>/configs/<kbuild defconfig> .. so make
> sure that is the case with senic_defconfig.
>
> You can always add the defconfig directly to the SRC_URI as well
> (i.e. copy it into your layer and call it 'defconfig' and add it
> to the SRC_URI like any other element.
>
> Bruce
>
>
>>
>>
>> On Tue, Nov 7, 2017 at 6:47 PM, Bruce Ashfield <
>> bruce.ashfield at windriver.com <mailto:bruce.ashfield at windriver.com>>
>> wrote:
>>
>>     On 11/07/2017 08:46 AM, Alan Martinovic wrote:
>>
>>         Hi,
>>         I'm trying to get yocto to build the kernel with an in-tree
>>         defconfig.
>>         For that I found references to the variable
>>         KBUILD_DEFCONFIG_KMACHINE.
>>
>>         However, I've been experiencing that the kernel is being built
>> with
>>         some default defconfig, and not the in-tree one that came with the
>>         kernel and I defined with the KBUILD_DEFCONFIG_KMACHINE.
>>
>>         I've looked through all yocto sources for where the
>>         KBUILD_DEFCONFIG_KMACHINE is actually used, and found it only in
>> my
>>         kernel recipe. So I decided to dissect my recipe.
>>
>>
>>     What is your kernel recipe ? Something you wrote, or something
>>     from a vendor ?
>>
>>
>>
>>         There is a:
>>
>>         inherit kernel
>>
>>         in my recipe for which, besides others, defines how the kernel
>>         config
>>         will be selected.
>>         Looking at the sources of oe/meta/classes/kernel.bbclass exposes
>> how
>>         the kernel configuration happens:
>>
>>         kernel_do_configure() {
>>                   # fixes extra + in /lib/modules/2.6.37+
>>                   # $ scripts/setlocalversion . => +
>>                   # $ make kernelversion => 2.6.37
>>                   # $ make kernelrelease => 2.6.37+
>>                   touch ${B}/.scmversion ${S}/.scmversion
>>
>>                   if [ "${S}" != "${B}" ] && [ -f "${S}/.config" ] && [ !
>> -f
>>         "${B}/.config" ]; then
>>                           mv "${S}/.config" "${B}/.config"
>>                   fi
>>
>>                   # Copy defconfig to .config if .config does not exist.
>>         This allows
>>                   # recipes to manage the .config themselves in
>>         do_configure_prepend().
>>                   if [ -f "${WORKDIR}/defconfig" ] && [ ! -f
>>         "${B}/.config" ]; then
>>                           cp "${WORKDIR}/defconfig" "${B}/.config"
>>                   fi
>>
>>                   ${KERNEL_CONFIG_COMMAND}
>>         }
>>
>>
>>         I'm planning a workaround by overriding the do_configure in my
>>         recipe
>>         to select the correct defconfig from the kernel. It does seem
>>         however
>>         like the KBUILD_DEFCONFIG_KMACHINE is exactly here to not have to
>> do
>>         the workarounds.
>>
>>         Anyone has experiences with successfully using
>>         KBUILD_DEFCONFIG_KMACHINE?
>>         Is it a specific poky feature (I'm not using poky but specific
>> open
>>         embedded layers and bitbake)?
>>
>>     That is a feature of kernel-yocto, so if your recipe is inheriting
>>     kernel-yocto you can use what you are looking for.
>>
>>     But note, in the documentation you are referencing you have to replace
>>     KMACHINE with your actual machine .. not use the string KMACHINE.
>>
>>     i.e. in your recipe (or bbappend)
>>
>>     # for cases where the KMACHINE (KERNEL MACHINE) and bitbake
>>     # machine match, just do this:
>>     KMACHINE=$MACHINE
>>
>>     KBUILD_DEFCONFIG_${KMACHINE}="your defconfig"
>>
>>     i.e. it is just a standard bitbake variable with a machine OVERRIDE
>>     to make it specific to the machine you are building.
>>
>>     Bruce
>>
>>
>>
>>         Be Well,
>>         Alan
>>
>>         Ref.
>>         https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev.
>> html#using-an-in-tree-defconfig-file
>>         <https://www.yoctoproject.org/docs/2.2/kernel-dev/kernel-dev
>> .html#using-an-in-tree-defconfig-file>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20171109/626d2c9f/attachment.html>


More information about the yocto mailing list