Age | Commit message (Collapse) | Author |
|
do_kernel_configme was recently removed from SRCTREECOVEREDTASKS so this
task still runs when externalsrc is used. This task normally runs after
do_patch but when externalsrc is used, do_patch is removed and this ordering
restriction does nothing. This allows bitbake to execute do_kernel_configme
too early, causing races with do_unpack.
This is fixed by adding in a dependency on do_unpack when externalsrc is
used.
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The merging of config fragments is performend in the do_kernel_configme
task and so config fragments will not be supported when this task is
removed from the dependency tree.
kernel-yocto adds additional tasks which may modify the source directory
to SRCTREECOVEREDTASKS so that they are removed when using externalsrc.
However, do_kernel_configme should be safe to use, the only modification
to the source tree is the potential creation of the '.kernel-meta'
directory and the '.metadir' file.
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
do_kernel_checkout and do_symlink_kernsrc are both modifying ${S}, they
could conflict with eacher other, move do_kernel_checkout after
do_symlink_kernsrc does fix that.
Signed-off-by: Ming Liu <liu.ming@toradex.com>
Signed-off-by: Stefan Agner <stefan.agner@toradex.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
To ensure that the kernel linker is used when allno/mod/yes config
merge_config steps were executed, the call to make was tweaked to
explicitly pass LD.
But since the variable wasn't quoted, any parameters to LD (like
the sysroot) were mistakenly passed to make, and hence could trigger
an error on some architectures.
We also tweak the logging to hightlight errors like this in the
future and avoid losing it in the noise of merge configs sometimes
overly verbose output.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The current code would cause a file like "config.bin" to added to the
config sources list. I am sure the intention was to add any files with
defconfig in its name and not the other way around.
Signed-off-by: Gavin Li <gavinli@thegavinli.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
merge_config_build.log and fail when /.config wasn't created
* for whatever reason, instead of silently continuing to build default kernel config
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* when ld-is-gold is used, merge_config.sh silently fails and doesn't generate anything
useful in .config (and also include directory isn't created):
tmp-glibc-bfd-qemux86-do_kernel_configme/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build:
total 164K
drwxr-xr-x 4 martin martin 4.0K Feb 5 02:27 .
drwxrwxr-x 7 martin martin 4.0K Feb 5 02:27 ..
-rw-rw-r-- 1 martin martin 133K Feb 5 02:28 .config
-rw-rw-r-- 1 martin martin 39 Feb 5 02:27 .gitignore
drwxr-xr-x 4 martin martin 4.0K Feb 5 02:27 include
-rw-rw-r-- 1 martin martin 201 Feb 5 02:27 Makefile
drwxrwxr-x 4 martin martin 4.0K Feb 5 02:27 scripts
lrwxrwxrwx 1 martin martin 61 Feb 5 02:27 source -> /OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source
tmp-glibc-gold-qemux86-do_kernel_configme/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build:
total 28K
drwxr-xr-x 3 martin martin 4.0K Feb 5 02:26 .
drwxrwxr-x 7 martin martin 4.0K Feb 5 02:26 ..
-rw-rw-r-- 1 martin martin 74 Feb 5 02:26 .config
-rw-rw-r-- 1 martin martin 39 Feb 5 02:26 .gitignore
-rw-rw-r-- 1 martin martin 201 Feb 5 02:26 Makefile
drwxrwxr-x 4 martin martin 4.0K Feb 5 02:26 scripts
lrwxrwxrwx 1 martin martin 61 Feb 5 02:26 source -> /OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source
$ cat tmp-glibc-gold-qemux86-do_kernel_configme/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build/.config
CONFIG_LOCALVERSION="-yocto-standard"
* and because the failure is silent, it will happily start building
kernel with default defconfig, which even builds OK for qemux86-64
but on qemux86 I've noticed this issue, because incorrectly
configured kernel build fails with:
$ tail -n 20 tmp-glibc-gold-qemux86/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/temp/log.do_compile
LD /OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build/tools/objtool/libsubcmd-in.o
AR /OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build/tools/objtool/libsubcmd.a
HOSTCC scripts/mod/mk_elfconfig
CC scripts/mod/devicetable-offsets.s
CC scripts/mod/empty.o
cc1: error: code model 'kernel' not supported in the 32 bit mode
cc1: sorry, unimplemented: 64-bit mode not compiled in
make[2]: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source/scripts/Makefile.build:99: scripts/mod/devicetable-offsets.s] Error 1
make[2]: *** Waiting for unfinished jobs....
cc1: error: code model 'kernel' not supported in the 32 bit mode
cc1: sorry, unimplemented: 64-bit mode not compiled in
make[2]: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source/scripts/Makefile.build:266: scripts/mod/empty.o] Error 1
make[1]: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source/Makefile:1111: prepare0] Error 2
make[1]: *** Waiting for unfinished jobs....
LD /OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build/tools/objtool/objtool-in.o
/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source/tools/objtool
LINK /OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build/tools/objtool/objtool
make: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source/Makefile:179: sub-make] Error 2
WARNING: exit code 1 from a shell command.
* the issue happens in log.do_kernel_configme, but the log is completely useless:
cat tmp-glibc-gold-qemux86-do_kernel_configme/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/temp/log.do_kernel_configme
DEBUG: Executing python function extend_recipe_sysroot
NOTE: Direct dependencies are ['virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-devtools/bison/bison_3.5.bb:do_populate_sysroot', '/OE/build/oe-core/openembedded-core/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb:do_populate_sysroot', 'virtual:native:/OE/build/oe-core/openembedded-core/meta/recipes-extended/bc/bc_1.07.1.bb:do_populate_sysroot', '/OE/build/oe-core/openembedded-core/meta/recipes-devtools/binutils/binutils-cross_2.33.bb:do_populate_sysroot', '/OE/build/oe-core/openembedded-core/meta/recipes-devtools/quilt/quilt-native_0.66.bb:do_populate_sysroot', '/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-cross_9.2.bb:do_populate_sysroot']
NOTE: Installed into sysroot: ['bison-native', 'bc-native', 'binutils-cross-i686', 'gcc-cross-i686', 'autoconf-native', 'xz-native', 'flex-native', 'gnu-config-native', 'automake-native', 'libtool-native', 'texinfo-dummy-native', 'gettext-minimal-native', 'readline-native', 'zlib-native', 'gmp-native', 'libmpc-native', 'mpfr-native', 'linux-libc-headers', 'm4-native', 'ncurses-native', 'pkgconfig-native']
NOTE: Skipping as already exists in sysroot: ['kern-tools-native', 'quilt-native']
DEBUG: sed -e 's:^[^/]*/:/OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/:g' /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/bison-native/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/gcc-cross-i686/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/autoconf-native/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/gnu-config-native/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/automake-native/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/libtool-native/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/gmp-native/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/ncurses-native/fixmepath /OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/pkgconfig-native/fixmepath | xargs sed -i -e 's:FIXMESTAGINGDIRTARGET:/OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot:g; s:FIXMESTAGINGDIRHOST:/OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native:g' -e 's:FIXME_PSEUDO_SYSROOT:/OE/build/oe-core/tmp-glibc/sysroots-components/x86_64/pseudo-native:g' -e 's:FIXME_HOSTTOOLS_DIR:/OE/build/oe-core/tmp-glibc/hosttools:g' -e 's:FIXME_PKGDATA_DIR:/OE/build/oe-core/tmp-glibc/pkgdata/qemux86:g' -e 's:FIXME_PSEUDO_LOCALSTATEDIR:/OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/pseudo/:g' -e 's:FIXME_LOGFIFO:/OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/temp/fifo.10476:g'
DEBUG: Python function extend_recipe_sysroot finished
DEBUG: Executing shell function do_kernel_configme
DEBUG: Shell function do_kernel_configme finished
]because merge_config.sh is redirected to work-shared/qemux86/kernel-source/.kernel-meta/cfg/merge_config_build.log
and bbfatal_log called in do_kernel_configme only when merge_config.sh fails which it should in this case
but doesn't.
The merge_config_build.log shows 5.4 specific error:
scripts/Kconfig.include:39: gold linker 'i686-oe-linux-ld' not supported
but then it happily continues reporting what isn't applied in not created
.config file
--- tmp-glibc-bfd-qemux86-do_kernel_configme/work-shared/qemux86/kernel-source/.kernel-meta/cfg/merge_config_build.log 2020-02-05 02:28:01.455520207 +0100
+++ tmp-glibc-gold-qemux86-do_kernel_configme/work-shared/qemux86/kernel-source/.kernel-meta/cfg/merge_config_build.log 2020-02-05 02:26:30.656470909 +0100
@@ -171,586 +171,5113 @@
HOSTCC scripts/kconfig/symbol.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --alldefconfig Kconfig
-./.tmp.config.jDjIEYi9Yq:2208:warning: unexpected data: #
-./.tmp.config.jDjIEYi9Yq:2209:warning: unexpected data: # Generic Driver Options
-./.tmp.config.jDjIEYi9Yq:2210:warning: unexpected data: #
-./.tmp.config.jDjIEYi9Yq:3102:warning: symbol value 'm' invalid for SAMPLE_SECCOMP
-./.tmp.config.jDjIEYi9Yq:3119:warning: symbol value 'm' invalid for NF_CT_PROTO_GRE
-./.tmp.config.jDjIEYi9Yq:3120:warning: symbol value 'm' invalid for NF_CT_PROTO_SCTP
-./.tmp.config.jDjIEYi9Yq:3121:warning: symbol value 'm' invalid for NF_CT_PROTO_UDPLITE
-#
-# configuration written to .config
-#
+scripts/Kconfig.include:39: gold linker 'i686-oe-linux-ld' not supported
+make[2]: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source/scripts/kconfig/Makefile:73: alldefconfig] Error 1
+make[1]: *** [/OE/build/oe-core/tmp-glibc/work-shared/qemux86/kernel-source/Makefile:567: alldefconfig] Error 2
make[1]: Leaving directory '/OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build'
+make: *** [Makefile:179: sub-make] Error 2
+grep: /OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build/.config: No such file or directory
+Value requested for CONFIG_LOCALVERSION not in final .config
+Requested value: CONFIG_LOCALVERSION=""
+Actual value:
+
+grep: /OE/build/oe-core/tmp-glibc/work/qemux86-oe-linux/linux-yocto/5.4.15-r0/linux-qemux86-standard-build/.config: No such file or directory
+Value requested for CONFIG_LOCALVERSION_AUTO not in final .config
+Requested value: # CONFIG_LOCALVERSION_AUTO is not set
+Actual value:
* I don't know why merge_config.sh uses separate more difficult to find merge_config_build.log
instead of leaving the output to end in log.do_kernel_configme, I'll send it as separate
commit so that it can be discussed there.
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
is set
CONFIG_LOCALVERSION may already be set in a defconfig or config fragment
and this should not be unconditionally overridden.
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The machine_branch and machine_srcrev variables were set but not used in
do_kernel_metadata.
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
This allows the kernel-yocto bbclass to be inherited in a recipe without
needing to include linux-yocto.inc. The bbclass should stand on its own
and linux-yocto.inc does a few things which may not be desired in other
kernel recipes (such as modifying KERNEL_FEATURES).
The LINUX_VERSION_EXTENSION default is not moved as other kernel recipes
may not want this setting in place.
Signed-off-by: Paul Barker <pbarker@konsulko.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* resolves following exceptions in log.do_kernel_configcheck:
DEBUG: Executing python function do_kernel_configcheck
Traceback (most recent call last):
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2776, in _expand_macro
res += args[int(new_args[0])]
ValueError: invalid literal for int() with base 10: 'error-if'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/symbol_why.py", line 295, in <module>
conf = kconfiglib.Kconfig( kconf, show_errors, show_errors )
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 947, in __init__
self._init(filename, warn, warn_to_stderr, encoding)
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 1085, in _init
self._parse_block(None, self.top_node, self.top_node).next = None
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2982, in _parse_block
prev = self._parse_block(None, parent, prev)
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2907, in _parse_block
while self._next_line():
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2234, in _next_line
self._tokens = self._tokenize(line)
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2364, in _tokenize
self._parse_assignment(s)
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2604, in _parse_assignment
s, i = self._expand_macro(s, i, ())
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2780, in _expand_macro
res += self._fn_val(new_args)
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2843, in _fn_val
return py_fn(self, *args)
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 6769, in _error_if_fn
kconf.filename, kconf.linenr, msg))
kconfiglib.KconfigError: scripts/Kconfig.include:39: gold linker 'x86_64-oe-linux-ld --sysroot=/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot ' not supported
Traceback (most recent call last):
File "/OE/build/oe-core/tmp-glibc/work/qemux86_64-oe-linux/linux-yocto/5.4.15-r0/recipe-sysroot-native/usr/bin/kconfiglib.py", line 2776, in _expand_macro
res += args[int(new_args[0])]
ValueError: invalid literal for int() with base 10: 'error-if'
* there is still 291 mismatched options in default 5.4.15 builds,
but at least the 11804 lines long log doesn't start with 9022 lines of above exceptions
DEBUG: Executing python function do_kernel_configcheck
[mismatch (291)]: /OE/build/oe-core/tmp-glibc/work-shared/qemux86-64/kernel-source/.kernel-meta/cfg/mismatch.txt
There were hardware options requested that do not
have a corresponding value present in the final ".config" file.
This probably means you aren't getting the config you wanted.
WARNING: [kernel config]: specified values did not make it into the kernel's final configuration:
...
Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
By default, only explicitly specified .scc files or patches are applied
to a BSP as part of the patching phase. This allows the reference BSPs
to be integrated into a kernel tree, and use the same meta data for tree
generation and for runtime building. It also greatly simplies the
processing of kernel meta data.
That being said, if an external (and fully standalone) kmeta repository
is used, it very well may contain both patches and configuration. To
allow the BSP definition to supply patches and config, we introduce a
new kernel meta data definition:
define KMETA_EXTERNAL_BSP t
This can be set in any .scc file that wants to specify both patches
and configuration.
If specifying this per-BSP is not desired, a secondary variable is
used:
KMETA_EXTERNAL_BSPS
When that is set in a bbappend, any located BSP definitions will be used
for both patches and configuration.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As reported by Paul Barker, my attempt to allow the patching
of kernel meta data broke other repository configurations, since
the meta data patch routing was matching too broadly and the
same repo would end up being patched twice.
Using his suggested fix, we are up and running with both types
of repos again.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
For testing purposes, it is often easier to patch a fragment
in a kernel-meta repository versus needing to make a copy or
modify the source repository.
We can allow this sort of patching when a patchdir of kernel-meta
is passed (to indicate the nested kernel-meta repository).
Also note that we must patch the meta data before they are
processed/gathered, since migrated copies to the kernel source
directory will be used later.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When using Kmeta directories, devtool finish will add every single file
in the directory to the bbappend. This is because in the current
implementation, the get_recipe_local_files function treats the kmeta
directory like a file. Modifying the function to loop through the
provided directories and return all included files instead of just the
top level directory. This will enable correct file to file comparison
when determing which files are new/changed and need to be added to the
bbappend.
Adding an extra check in devtool-source.bbclass to not copy the cfg file
if its already included somewhere in the kmeta directory
Also during 'modify', when moving necessary files in the kmeta directory
from the workdir to oe-local-files, the dangling parent directories are
left behind. This in itself is not an issue as the temporary devtool
workspace is automatically deleted, but this causes an incorrect include
directory to be added in kernel-yocto.bbclass. Changing the order of
the if statements to catch the correct conditional. This is safe to do
as when not in the devtool context, there will be no oe-local-files
directory.
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Acked-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
If "scc --configs" fails, do_kernel_configcheck() crashes like this:
0338: try:
0339: configs = subprocess.check_output(['scc', '--configs', '-o', s + '/.kernel-meta'], env=env).decode('utf-8')
0340: except subprocess.CalledProcessError:
*** 0341: bb.fatal( "Cannot gather config fragments for audit: %s" % configs)
0342:
0343: try:
0344: subprocess.check_call(['kconf_check', '--report', '-o',
0345: '%s/%s/cfg' % (s, kmeta), d.getVar('B') + '/.config', s, configs], cwd=s, env=env)
Exception: UnboundLocalError: local variable 'configs' referenced before assignment
This crash bug was introduced by commit
21de5cc43cfedc703e5bc0515507a6dae36afb74
Signed-off-by: Max Kellermann <max.kellermann@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
During the re-working of kernel fragments and status output cleanup the
visibility for BSP level errors was dropped/removed.
The audit phase can detect errors, redefinition and invalid
configuration fragments. We control the visibility of these reports via
the existing KCONF_BSP_AUDIT_LEVEL variable.
By default, errors and invalid configuration values will be displayed as
a warning. If redefinition values are to be shown the audit level must
be raised above the deafult value of '2'. We inhibit these by default,
since there are many valid reasons why a BSP will change a default /
base config .. and showing them offers no value to the BSP user.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Replace usage of os.utils.getstatusoutput() with direct subprocess
calls. Pass a modified environment and working directory where necessary
to bypass the need to execute in a shell.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The devtool-source class moves all local files specified in SRC_URI to
an oe-local-files directory. When using devtool and a recipe space kernel-meta,
devtool modify throws an error because the paths the kernel-yocto class
is looking for feature directories in, don't include the oe-local-files
directory which devtool is using.
This patch checks for feature directories in oe-local-files,
and if present, adds that path to include directives.
[YOCTO #12855]
Signed-off-by: Jaewon Lee <jaewon.lee@xilinx.com>
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
With recent kernels (i.e. 4.17+) the configuration phase of the kernel
will check for capabilities/options of the compiler for CVE and other
mitigation support.
For a general kernel, we want to ensure that CC is fully defined when
the config targets are invoked (so the proper compiler will be checked).
For linux-yocto, we also need to specify the compiler/tools dependencies
for the configme task since it executes before configure and hence the
main kernel build DEPENDS will not always be in the sysroot before it
executes. Without those dependencies the kernel will be incorrectly
configured (i.e. bison is missing) or the configuration will fail the
mitigation tests.
[YOCTO #12757]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Initialize the git config prior creating a git repository in a plain
directory.
Signed-off-by: Justin Bronder <jsbronder@cold-front.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
commit 7e98c295c1bb511e [kernel-yocto: ensure that only a single
defconfig is processed] has an overly broad replacement strategy
for 'defconfig' and hence will chop up any fragment name that
happens to contain that string.
If we change the processing to split on whitespace and drop
any full work 'defconfig' fragments, we'll get the behaviour
we want (no duplicate defconfigs, but fragments with defconfig
in their name are fine).
[YOCTO #12487]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
|
|
As a follow up to the changes to ensure that KBUILD_DEFCONFIG will
always get its defconfig into the processing, we also should ensure that
we don't get both a KBUILD_DEFCONFIG and a SRC_URI defconfig in the
configuration queue. If both are in the configuration queue, we end up
with competing values and a potentially long running check of 5000+
options x 2 against the final .config.
By removing the defconfig found from the SRC_URI when one is found
via KBUILD_DEFCONFIG, we ensure that only one will be processed.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The bberror does not stop the build correctly, this should be a
bbfatal_log to ensure the failure correctly stops the build and logs
the failure.
Part of
[YOCTO #12162]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set and the
defconfig is not found correctly.
Part of
[YOCTO #12162]
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
commit 44aea7b873 [kernel-yocto: ensure that only valid BSPs are built]
introduced a new check to ensure that a valid BSP definition was found,
rather than building something that 'closely' matched the current
MACHINE.
This check breaks valid configurations which do not have a bsp
definition but are otherwise completely configured machines.
To allow both elements to co-exist (and not add warnings or errors
to otherwise valid builds), we first check to see if an empty bsp
definition was found, but then check to see if a defconfig was
provided.
If a defconfig has been provided, that is a sign that the board
configuration is complete and we should continue the build without
otherwise bothering the user.
Tested on meta-raspberrypi and linux-yocto*
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
There was a bug in the search routines responsible for locating
BSP definitions which returned a valid match if only the ktype
matched.
This meant that someone looking for "qemux86foo" (which is an
invalid definition) would potentially end up building "qemuarm"
and be none the wiser (until it didn't boot).
With this fix to the tools search routine, and improved return
code testing, we will now stop the build and report and error to
the user.
[YOCTO: #11878]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
As pointed out by klapperichpaul@johndeere.com, missing configuration
fragments were being picked up twice, once by the tools and once by the
bbclass. Unfortunately, the tools error message was being detected as
configs, and hence no error was reported at all.
Rather than catching the output of the tools, we can instead check the
return code and propagate the error message from the tools directly to
the user.
[YOCTO #11649]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
It was reported that do_validate_branches was failing with the following
error:
Log data follows:
| DEBUG: Executing shell function do_validate_branches
| HEAD is now at fe0fb8d Merge tag 'v4.10.9' into standard/base
| mkdir: cannot create directory .: File exists
|
| [ERROR] Can't find patch dir at ./patches/standard/base
| usage: kgit s2q
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_validate_branches
This was triggered by the execution of 'kgit-s2q --clean' after forcing
the SRCREV to something other than the tip of the branch. --clean is
being run to remove any sentinel files from previous kernel builds to
ensure that the tree is in a consistent state.
There were two bugs, --clean was being executed and not exiting the
script as it was supposed to. Hence validation for applying patches
was done, and threw the error that eventually makes it to the console.
And the second bug is that since do_validate_branches actually calls
kgit-s2q --clean, the dependency on kern-tools-native needs to be on
that function (versus do_kernel_metadata which runs later).
With the tweaked kern-tool + the dependency fix, we no longer see this
error.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
A typo introduced an extra } in the logging of the bsp_definition.
While this won't cause problems .. it needs to be fixed!
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
In some cases it is seen that kernel_checkout and validate_branches are
run again in simultaneous builds. During do_patch the kgit-s2q mechanism
looks for a sentinel file inside the .git directory, finds a fence post
and starts picking up patches after that.
This can create trouble as validate_branches checks out the HEAD of the
branch and so the patches should be reapplied rather than skipped due to
finding of the fence post.
We can call kgit-s2q --clean to remove the sentinel file when the
branches are checked out.
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
When debugging a kernel configuration issue, one of the first questions
is "what BSP was used". To answer this qusetion, we log the BSP .scc
file that was used to generate the kernel configuration in the kernel
source meta directory.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The ability to merge two branches directly from a .scc file was
dropped during the streamlining of the tools.
As was pointed out by David Vincent <freesilicon@gmail.com>, there is
once again a valid use case for this functionality, so we restore the
capability.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
There were a few straggling expansion parameter removals left for
getVar/getVarFlag where the odd whitespace meant they were missed
on previous passes. There were also some plain broken ussages such
as:
d.getVar('ALTERNATIVE_TARGET', old_name, True)
path = d.getVar('PATH', d, True)
d.getVar('IMAGE_ROOTFS', 'True')
which I've corrected (they happend to work by luck).
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
To trap errors and halt processing, do_kernel_metadata was recently
switched to exit on any non zero return code. While the concept is
sound, there are subcommands that have legitimate non-zero return
codes.
Instead of removing set +e, we'll explicitly check the return code
of the commands that can error, and throw a bbfatal to alert the
user.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Historically the processing of kernel meta data contained some
commands that exited with a non-zero return code. Special processing
was required to properly deal with their exit.
That is no longer true, and instead of handling all return codes
and doing an explicit 'exit' call, we can remove set -e from the
routine and have all errors be trapped and stop processing.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
If attempting to patch a git repo without a proper git config setup,
an error will occur saying user.name/user.email are needed by git
am/apply. After some code was removed from kernel-yocto, it was
simple enough to reproduce this error by creating a kernel patch and
using a container to build.
This patch abstracts out functionality that existed in buildhistory
for use in other classes. It also adds a call to this functionality
to the kernel-yocto class.
Fixes [YOCTO #10346]
introduced in OE-core revision
0f698dfd1c8bbc0d53ae7977e26685a7a3df52a3
Signed-off-by: Stephano Cetola <stephano.cetola@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Various recipes depend on the kernel's do_shared_workdir
task, a quick grep suggests all external kernel modules
(via module.bbclass), but also perf, and potentially any
additional headers as outlined in linux-libc-headers.inc
are affected.
Having do_shared_workdir in SRCTREECOVEREDTASKS means this
task is removed when externalsrc is enabled, making all
those recipes fail as the task they depend on,
virtual/kernel:do_shared_workdir, doesn't exist.
Remove do_shared_workdir from SRCTREECOVEREDTASKS so that
all those recipes work even if externalsrc is activated.
According to the comment in here, the reason for
do_shared_workdir to be removed as a task is because it
modifies the source tree, but that doesn't seem to be
case.
Signed-off-by: Andre Draszik <git@andred.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Previously merge_config.sh was wrapped by the configme script, configme
took the different KCONFIG_MODES as options, and used --allnoconfig
or --alldefconfig.
With the switch to merge_config.sh no longer being wrapped, the new
processing wasn't matching the existing values and only supported
allnoconfig or alldefconfig.
To avoid breaking existing layers, and also keep any working that
have already switched, we can make the case statement match both.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Before the kernel tools were simplified and streamlined, there was code
which not only migrated a patch/cfg/scc to the kernel build tree, it
also migrated any subdirectories of those patches.
The effect of this data migration was that any other meta data in
a patch's directory structure would be available for processing.
While we don't want to do this migration anymore, it is possible to
check the path of any SRC_URI patches, and if they include a "kernel-meta"
subdirectory add it to the search path.
This restores the functionality without the old complexity.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
do_kernel_configme calls merge_config.sh (installed in the sysroot by
the kern-tools-native recipe) which may invoke the compiler to complete
the configuration process.
Depending on the build (and dependencies), this may error due to sysroot poisoning [1].
The errors are similar to:
make[1]: Entering directory '4.1+gitAUTOINC+a7e53ecc27-r0/linux-x64-standard-build' HOSTCC scripts/basic/fixdep
work-shared/x64/kernel-source/scripts/basic/fixdep.c:106:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
make[2]: *** [work-shared/x64/kernel-source/scripts/basic/Makefile:22: scripts/basic/x86_64-nilrt-linux-fixdep] Error 1
Adding $TOOLCHAIN_OPTIONS to $CFLAGS before calling merge_configs.sh
fixes the error because $TOOLCHAIN_OPTIONS defines the sysroot and make
uses it to correctly compile & fill all missing kernel config options.
[1] http://lists.openembedded.org/pipermail/openembedded-core/2014-October/098253.html
Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
With the updated kernel tools, we generate a list of sccs, patches,
configs and BSP definitions as part of the meta data generation.
It is valid if there aren't any of these artifacts found (i.e. you
are just building a branch and a default config), but invoking the
tools with no inputs isn't a good idea.
To avoid this issue, we generate a string based on the artifacts
and skip calling the tools if there's nothing to do.
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
We've been running with a set of kern-tools that were designed to work
with build systems that knew nothing about git, trees, commits, etc.
As such, there's been a set of shims/wrappers in place to work with
within bitbake/oe-core. These were the *me scripts: createme, updateme,
patchme and configme.
With this commit, we strip that legacy code and use the tools directly.
This means less complexity, fewer corner cases .. and no surprises
when the tools are arunning. As another benefit, the tools consume
much less time during a typical build and have no noticeable impact
on the overall build time.
Existing .scc files, features, and processing are not impacted as
these tools are compatible with existing feature descriptions and
kerne configuration fragments.
The audit of kernel configuration fragments is now detached
from the linux-yocto build structure and process. This means that
they can eventually be tweaked to offer kernel audit to any type of
kernel build and configuration process.
Additionally, the kernel symbol audit phase can now resolve symbol
dependencies and offer guidance when a symbol is missing:
WARNING: linux-yocto-4.4.15+gitAUTOINC+b030d96c7b_f5e2c49d58-r0 do_kernel_configcheck: [kernel config]: specified values did not make it into the kernel's final configuration:
---------- CONFIG_BT_6LOWPAN -----------------
Config: CONFIG_BT_6LOWPAN
From: /home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-source/.kernel-meta/configs/standard/features/bluetooth/bluetooth.cfg
Requested value: CONFIG_BT_6LOWPAN=y
Actual value:
Config 'BT_6LOWPAN' has the following conditionals:
BT_LE && 6LOWPAN (value: "n")
Dependency values are:
BT_LE [y] 6LOWPAN [n]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
When working on the yocto-bsp and kernel-lab update for yocto 1.2
we found it was impossible for a end-user BSP to isolate patches
on a branch, since with the following commit:
[kernel-yocto: enforce SRC_URI specified branch]
Any new branch would be switched to whatever was specified on the
SRC_URI and undoing the work that the yocto-bsp tool did to support
board specific patches.
To fix this, we'll keep the enforcing of branch consistency enabled
by default, but introduce a variable "KMETA_AUDIT" that when not
set will skip the check.
There's no impact for existing users, and it is only something that
other plumbing commands and tools will need to use (or care about).
[YOCTO: #9120]
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
During the simplication and cleanup of branches and kernel meta data
handling, the ability to force build a branch that didn't match the
meta data was dropped.
There are valid uses cases when a different branch should be built
(testing, development, etc), so we restore the capability with this
change.
If after the kernel meta data is processed the current branch does
not match the SRC_URI specified branch, a warning is generated
about the impending branch switch and that the user should double
check that they are building what they expect.
WARNING: After meta data application, the kernel tree branch is standard/base. The
WARNING: SRC_URI specified branch standard/gt. The branch will be forced to standard/gt,
WARNING: but this means the board meta data (.scc files) do not match the SRC_URI specification.
WARNING: The meta data and branch standard/gt should be inspected to ensure the proper
WARNING: kernel is being built.
Reported-by: Steve Sakoman" <steve.sakoman@intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Move do_kernel_link_vmlinux() from kernel-yocto.bbclass into
kernel.bbclass so that it's available to any kernel recipe.
Note that the task is not enabled by default in kernel-yocto.bbclass,
so don't enable by default in kernel.bbclass either. To enable, see
the example in linux-yocto.inc, ie:
addtask kernel_link_vmlinux after do_compile before do_install
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The do_kernel_link_vmlinux() task modifies the build directory (not
the source tree) and should not be skipped when externalsrc is being
used.
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The existing code doesn't tell regular (with .git) and bare cases and
just move the unpacked repo to the place of kernel source. But later
steps will fail on a bare-cloned repo because we can not checkout
directly in a bare cloned repo.
This change performs another clone to fix the issue.
Note: This change doesn't cover the case that S and WORKDIR are same
and the repo is bare cloned.
Signed-off-by: Jianxun Zhang <jianxun.zhang@linux.intel.com>
Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|