meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Next revision		Previous revision
sw:yocto:bitbake:multiconfig [2025/07/01 12:49] – created niziaksw:yocto:bitbake:multiconfig [2025/07/01 21:22] (current) – niziak
Line 1: Line 1:
 ====== multiconfig ====== ====== multiconfig ======
 +
 +[[https://docs.yoctoproject.org/next/dev-manual/multiconfig.html#building-images-for-multiple-targets-with-multiconfig|13 Building Images for Multiple Targets With Multiconfig]]
  
 With default - no multiconfig - usage bitbake works with one config ''local.conf''. With default - no multiconfig - usage bitbake works with one config ''local.conf''.
Line 16: Line 18:
  
 Pros: Pros:
 +  * Acts as predefined ''local.conf'' shipped within layer.
   * It has great benefits when SSTATE cache is already filled and when multiple rootfs images are assembled in parallel.   * It has great benefits when SSTATE cache is already filled and when multiple rootfs images are assembled in parallel.
 +  * The same TMPDIR can be used, when building the same distro for multiple similar machines and multiple similar images.
 +  * [[https://docs.yoctoproject.org/next/dev-manual/multiconfig.html#common-use-case-building-baremetal-firmware-alongside-a-linux-build|13.4 Common use case: building baremetal firmware alongside a Linux build]]
  
 Cons: Cons:
   * With empty SSTATE it can perform even worse than sequential build where 1st build will store some reusable object in sstate cache.   * With empty SSTATE it can perform even worse than sequential build where 1st build will store some reusable object in sstate cache.
 +    * See <code>
 +Note
 +Support for multiple configuration builds in the Yocto Project 5.3.999 (Whinlatter) Release does not 
 +include Shared State (sstate) optimizations. Consequently, if a build uses the same object twice in, for example,
 +two different TMPDIR directories, the build either loads from an existing sstate cache for that build at the
 +start or builds the object fresh.
 +</code>
 +  * Separate TMPDIR must be used when crucial configs are changed between multiconfis. Common practice is to use separate TMPDIR per distro.
  
  
Line 33: Line 46:
 </code> </code>
  
 +<file yaml myconfig.yml>
 +---
 +header:
 +  version: 18
 +
 +target:
 +  - mc:genio-510-sbc:core-image-minimal
 +  - mc:genio-700-sbc:core-image-minimal
 +  - mc:genio-700-evb:core-image-minimal
 +...
 +</file>
 +
 +
 +===== TMPDIR =====
 +
 +<file conf myconfig.conf>
 +DISTRO = "poky"
 +
 +# rename TMPDIR with option to override it:
 +MY_TMP_APPEND ?= "-poky"
 +TMPDIR:append = "${MY_TMP_APPEND}"
 +</file>
 +
 +or
 +
 +<file conf local.conf>
 +TMPDIR = "${TOPDIR}/tmp-${DISTRO}"
 +</file>
 +
 +[[https://lists.yoctoproject.org/g/meta-ti/topic/patch_multiconfig_use/91431962|[PATCH] multiconfig: use diferent TMPDIR for each machine]]
 +
 +[[https://git.yoctoproject.org/meta-ti/tree/meta-ti-bsp/conf/multiconfig/k3r5.conf?h=scarthgap|path: root/meta-ti-bsp/conf/multiconfig/k3r5.conf]]
  
 ===== references ===== ===== references =====
 +
  
 “Multiconfig Inception” by Joshua Watt: “Multiconfig Inception” by Joshua Watt:
Line 43: Line 89:
   * [[https://github.com/siemens/kas/issues/30|Multi-config support needs to be documented #30]]   * [[https://github.com/siemens/kas/issues/30|Multi-config support needs to be documented #30]]
   * [[https://github.com/siemens/jailhouse-images|Jailhouse Reference Images]]   * [[https://github.com/siemens/jailhouse-images|Jailhouse Reference Images]]
 +