Zuletzt aktualisiert am 26. Oktober 2023

Wie kann man herausfinden, warum Fragmente der Kernelkonfiguration nicht oder nicht wie erwartet angewendet werden?

Zielsetzungen

Dieser Beitrag zeigt Ihnen, wie Sie herausfinden können, warum Fragmente der Kernelkonfiguration nicht oder nicht wie erwartet angewendet werden - siehe .ssc/.cfg Dateien.

Voraussetzungen

Sie haben also Ihre tägliche Dosis Yocto Project® Mega Manual gelesen und sind auf Kapitel wie Adding Recipe-Space Kernel Features und Working with Advanced Metadata (yocto-kernel-cache) gestoßen.

Mögliche Probleme

Sie fangen an, damit herumzuspielen, aber .scc Dateien funktionieren einfach nicht für Sie. Sie tun nicht das, was Sie erwartet haben.

Was nun?

Bruce (der Yocto Project® Kernel Maintainer) versprach einen neuen und verbesserten Weg in der nächsten Version von Pokyaber im Moment sagt er: "Die config.queue und merge-config Logs sind die Dateien von größtem Interesse (beim derzeitigen Stand der Dinge wird es bald bessere Dateien geben). Beginnend mit gatesgarth sehen Sie auf Ihrer Build-Konsole weitere Informationen zum Kernel-Tooling. Die config.queue ist in work-shared/$MACHINE/kernel-source/.kmeta/ und die merge-config Artefakte sind ein Verzeichnis tiefer unter cfg/."

Schauen wir uns einige der Dateien unter work-shared/${MACHINE}/kernel-source/.kmeta an

bsp_definition

Die bsp_definition definiert meinen Kernel-Typ (arm64-ml-std) und sieht wie folgt aus:

<where-ever>/tmp/work/<MACHINE>-<DISTRO>-linux/<PREFERRED_PROVIDER_virtual/kernel>/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/arm64-ml-common/bsp/arm64-ml/arm64-ml-std.scc

config.queue

Die config.queue meines arm64-ml-std-Kernels sieht wie folgt aus:

configs///defconfig # non-hardware
configs//ktypes/std/std.cfg # non-hardware
configs//features/ikconfig/ikconfig.cfg # non-hardware
configs//features/posix-mqueue/posix-mqueue.cfg # non-hardware
configs//features/ramdisk/ramdisk.cfg # non-hardware
configs//features/mtd/mtd.cfg # non-hardware
configs//features/snvs-rtc/snvs-rtc.cfg # non-hardware
configs//features/tun/tun.cfg # non-hardware
configs//features/btrfs/btrfs.cfg # non-hardware
configs//features/tracepoints/tracepoints.cfg # non-hardware
configs//features/syn-cookies/syn-cookies.cfg # non-hardware

Das klingt vielversprechend.

Es sieht so aus, als ob mein Kernel-Typ, die .scc-Dateien und die .cfg-Dateien tatsächlich verwendet werden. Für den Fall, dass sie nicht erkannt werden, ist es hilfreich zu wissen, dass diese Variablen in einer Datei namens meta-series auftauchen (was bedeutet, dass sie irgendwo definiert werden müssen).

meta-series

# _mark arm64-ml-std.scc start 
# _define KMACHINE 'arm64-ml' 
# _define KTYPE 'std' 
# _define KARCH 'aarch64' 
# _mark std.scc start

Die obige Datei ist recht nützlich, da Sie sehen, in welcher Reihenfolge die .scc-Dateien und Patches angewendet werden. Sie können dies im nächsten Auszug aus "meta-series" sehen:

kconf /workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/arm64-ml-base/features/tracepoints/tracepoints.cfg # non-hardware
# _mark tracepoints.scc end
# _mark syn-cookies.scc start
# _define KFEATURE_DESCRIPTION 'Enable CONFIG_SYN_COOKIES support'
# _define KFEATURE_COMPATIBILITY 'all'
kconf /workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/arm64-ml-base/features/syn-cookies/syn-cookies.cfg # non-hardware
# _mark syn-cookies.scc end
# _mark std-collection.scc end
# _mark std.scc end
# _mark arm64-ml-std.scc end
# _mark arm64-ml-user-patches.scc start
patch patches//patches/phyboard-polis-imx8mm/dts/0001-freescale-imx8mm-phyboard-polis-rdk.dts-dependencies.patch
# _mark arm64-ml-user-patches.scc end

Die .scc-Dateien werden in der gleichen Reihenfolge verarbeitet, wie sie in meiner Kernel-Typ-Datei (arm64-ml-std) auf oberster Ebene erscheinen. Sie können einen Patch am Ende sehen.

tree .kernel-meta/

Ich denke, Sie haben die Idee verstanden. Hier ist der Baum mit allen Dateien:

student@e450-tr1:/workdir$ tree .kernel-meta/
.kernel-meta/
├── bsp_definition
├── cfg
│   ├── merge_config_build.log
│   └── scratch
├── config.queue
├── configs
│   ├── defconfig
│   ├── features
│   │   ├── btrfs
│   │   │   └── btrfs.cfg
│   │   ├── ikconfig
│   │   │   └── ikconfig.cfg
│   │   ├── mtd
│   │   │   └── mtd.cfg
│   │   ├── posix-mqueue
│   │   │   └── posix-mqueue.cfg
│   │   ├── ramdisk
│   │   │   └── ramdisk.cfg
│   │   ├── snvs-rtc
│   │   │   └── snvs-rtc.cfg
│   │   ├── syn-cookies
│   │   │   └── syn-cookies.cfg
│   │   ├── tracepoints
│   │   │   └── tracepoints.cfg
│   │   └── tun
│   │       └── tun.cfg
│   └── ktypes
│       └── std
│           └── std.cfg
├── meta-series
├── non-hardware_frags.txt
├── patches
│   └── patches
│       └── phyboard-polis-imx8mm
│           └── dts
│               └── 0001-freescale-imx8mm-phyboard-polis-rdk.dts-dependencies.patch
├── patch.queue
└── series -> patch.queue

19 directories, 19 files

cfg/merge_config_build.log

Falls einige Konfigurationsfragmente nicht wie erwartet angewendet werden, können Sie auch einen Blick in die Datei cfg/merge_config_build.log werfen:

Using .kernel-meta/configs///defconfig as base
Merging .kernel-meta/configs//ktypes/std/std.cfg
Merging .kernel-meta/configs//features/ikconfig/ikconfig.cfg
Merging .kernel-meta/configs//features/posix-mqueue/posix-mqueue.cfg
Merging .kernel-meta/configs//features/ramdisk/ramdisk.cfg
Merging .kernel-meta/configs//features/mtd/mtd.cfg
Value of CONFIG_MTD_CFI_ADV_OPTIONS is redefined by fragment .kernel-meta/configs//features/mtd/mtd.cfg:
Previous value: CONFIG_MTD_CFI_ADV_OPTIONS=y
New value: # CONFIG_MTD_CFI_ADV_OPTIONS is not set

Merging .kernel-meta/configs//features/snvs-rtc/snvs-rtc.cfg
Merging .kernel-meta/configs//features/tun/tun.cfg
Value of CONFIG_TUN is redefined by fragment .kernel-meta/configs//features/tun/tun.cfg:
Previous value: CONFIG_TUN=y
New value: CONFIG_TUN=m

Merging .kernel-meta/configs//features/btrfs/btrfs.cfg
Value of CONFIG_BTRFS_FS is redefined by fragment .kernel-meta/configs//features/btrfs/btrfs.cfg:
Previous value: CONFIG_BTRFS_FS=m
New value: CONFIG_BTRFS_FS=y

Merging .kernel-meta/configs//features/tracepoints/tracepoints.cfg
Value of CONFIG_FTRACE is redefined by fragment .kernel-meta/configs//features/tracepoints/tracepoints.cfg:
Previous value: # CONFIG_FTRACE is not set
New value: CONFIG_FTRACE=y

Merging .kernel-meta/configs//features/syn-cookies/syn-cookies.cfg
make[1]: Entering directory '/workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/linux-phyboard_polis_imx8mm-std-build'
  GEN     Makefile
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  HOSTCC  scripts/kconfig/confdata.o
  HOSTCC  scripts/kconfig/expr.o
  LEX     scripts/kconfig/lexer.lex.c
  YACC    scripts/kconfig/parser.tab.[ch]
  HOSTCC  scripts/kconfig/lexer.lex.o
  HOSTCC  scripts/kconfig/parser.tab.o
  HOSTCC  scripts/kconfig/preprocess.o
  HOSTCC  scripts/kconfig/symbol.o
  HOSTCC  scripts/kconfig/util.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --alldefconfig Kconfig
#
# configuration written to .config
#
make[1]: Leaving directory '/workdir/build/phyboard-polis-imx8mm-wic/tmp/work/phyboard_polis_imx8mm-resy-linux/linux-yocto-custom/5.8.5-custom-ml-std+gitAUTOINC+9ece50d8a4-r0/linux-phyboard_polis_imx8mm-std-build'
Value requested for CONFIG_ACPI_APEI_PCIEAER not in final .config
Requested value:  CONFIG_ACPI_APEI_PCIEAER=y
Actual value:

Value requested for CONFIG_USB_CONN_GPIO not in final .config
Requested value:  CONFIG_USB_CONN_GPIO=m
Actual value:     CONFIG_USB_CONN_GPIO=y

Value requested for CONFIG_BUILD_BIN2C not in final .config
Requested value:  CONFIG_BUILD_BIN2C=y
Actual value:

Value requested for CONFIG_MTD_IMPA7 not in final .config
Requested value:  # CONFIG_MTD_IMPA7 is not set
Actual value:

Schlussfolgerung

Ich hoffe, das hilft. Wenn Sie Ihre Konfigurationsänderungen immer noch nicht sehen, können Sie auch KERNEL_FEATURES:append ausprobieren, um z.B. Kernel-Metadaten bedingt einzubeziehen. Diese Funktionen werden nach dem Kernel-Tooling ausgeführt, also sollte es funktionieren.

Vielleicht so:

# --> EW-7811UN USB/Wifi dongle
# USB realtek wifi
#
# conditionally include kernel fragment:
KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'wifi', ' features/rtl8xxxu/rtl8xxxu.scc', '', d)}"
# which seems to work
#
# conditionally automatically load the kernel module
KERNEL_MODULE_AUTOLOAD += " ${@bb.utils.contains("MACHINE_FEATURES", "wifi", "rtl8xxxu", "",d)}"
#
# make sure 'wifi' is also set in DISTRO_FEATURES to install various extra things
# and make wifi work out of the box
#
# <-- EW-7811UN USB/Wifi dongle

Anhang

Ein Blog-Beitrag, der beschreibt, wie man den Upstream-Kernel ohne das Yocto Project® baut, ist hier zu finden. Wenn Sie wissen wollen, wie Embedded Linux funktioniert, schauen Sie hier nach. Um mehr über das Yocto Project® zu erfahren, schauen Sie hier.

Kommende Veranstaltungen

Unsere 3 Punkte

der Differenzierung

Wir stellen Host- und Zielhardware für alle unsere Kurse zur Verfügung.

Drei oder mehr Personen aus demselben Unternehmen? Wir bieten maßgeschneiderte Privatschulungen an - Beratung inklusive.

Fachexperten entwickeln hochwertige, berufsbezogene, aktuelle und authentische Kursunterlagen.