Skip to main content

Kernel configuration

defconfig and fragments​

OpenSTLinux does not carry a monolithic defconfig for the STM32MP1. It reuses the generic ARMv7 config and layers STM32MP-specific options on top as fragments.

  • Base defconfig, in the kernel tree: arch/arm/configs/multi_v7_defconfig

    CONFIG_SYSVIPC=y
    CONFIG_NO_HZ_IDLE=y
    CONFIG_HIGH_RES_TIMERS=y
    ...

  • STM32MP fragments, in the BSP layer: meta-st/meta-st-stm32mp/recipes-kernel/linux/linux-stm32mp/<kernel version>/fragment-*.config

Every kernel release brings new options. Rather than fork multi_v7_defconfig each time, ST keeps using the shared ARMv7 defconfig and expresses the STM32MP1 specifics as fragments merged on top. That is why building the config is a merge_config step, not a single make defconfig.

The resulting .config after a build is at:

  • build-openstlinuxweston-<machine name>/tmp-glibc/work/<machine>-ostl-linux-gnueabi/linux-stm32mp/<kernel recipe version>/build/.config

or the deployed copy at:

  • build-openstlinuxweston-<machine name>/tmp-glibc/deploy/image/<machine name>/kernel/config-<kernel recipe version>

Editing the configuration​

Do not hand-edit .config. Use one of the menu tools, which understand the dependencies between options:

make config       # line-by-line question and answer
make menuconfig    # ncurses terminal UI (the usual choice)
make xconfig       # Qt-based GUI

Each option ends up in one of three states, and only one line for a given symbol appears in .config:

CONFIG_SCSI=y             # built into the kernel
CONFIG_SCSI=m             # built as a loadable module
# CONFIG_SCSI is not set   # not selected

An unselected option shows either as a # ... is not set line or by the line being absent entirely — both mean the same thing.

Making a change permanent​

Menuconfig edits the .config in the build directory, not the source tree, so they are lost on a clean rebuild. Persisting a change means capturing it as a fragment. The exact steps differ between the two package flows.

Developer Package​

Capture the delta between the old and new defconfig and save it into a fragment-*.config, based on the fragment.cfg file (as the README.HOW_TO.txt helper explains).

# The SDK environment must be sourced; CROSS_COMPILE should be set
set | grep CROSS

cd LINUX_KERNEL_BUILD_DIR
# e.g. .../Developer-Package/.../linux-stm32mp-6.1.28-stm32mp-r1-r0/linux-6.1.28

# Snapshot the current config before changing anything
make arch=ARM savedefconfig
cp defconfig defconfig.old

make arch=ARM menuconfig

# Snapshot again, then diff to see exactly what changed
make arch=ARM savedefconfig
meld defconfig defconfig.old

# Rebuild the uImage (check the load address in README.HOW_TO.txt)
make arch=ARM uImage LOADADDR=0xC2000040
cp arch/arm/boot/uImage install_artifact/boot/

scp install_artifact/boot/uImage root@BOARD_IP:/boot/

On the board:

cd /boot && sync && systemctl reboot

Distribution Package​

Here the change is saved into a fragment based on fragment.cfg, and the config and compile are re-run through BitBake — bitbake <name of kernel recipe>.

# e.g. .../Distribution-Package/build-openstlinuxweston-stm32mp13-disco
bitbake virtual/kernel -c menuconfig    # edit the configuration
bitbake virtual/kernel                  # rebuild

scp BUILD_DIR/tmp-glibc/deploy/images/MACHINE_NAME/kernel/uImage root@BOARD_IP:/boot

On the board:

cd /boot && sync && systemctl reboot

The virtual/kernel name resolves to whichever kernel recipe the machine selects, so the same command works regardless of the exact recipe version. See Distribution Package for the surrounding build workflow.