11363 2017-04-13 22:17:26 +0000 Support building and deploying multiple kernels for a single image 2018-01-17 18:30:17 +0000 1 1 7 Build System, Metadata & Runtime OE-Core kernel unspecified x86 Multiple RESOLVED FIXED LET Medium+ enhancement 2.5 M2 12320 1 california.l.sullivan haris.okanovic blloyd bluelightning brian.avery haris.okanovic pokylinux randy.e.witt randy.macleod tim.orling tom.zanussi --- --- Yes (doc changes required) oldest_to_newest 72502 0 california.l.sullivan 2017-04-13 22:17:26 +0000 Currently an image we create will only ever have one kernel in it. It should be possible to have a 4.9 and 4.10 kernel in the same image, for example. Ideally, we would have boot targets set up using each kernel automatically as well. 75263 1 tim.orling 2017-07-24 19:52:34 +0000 If it can be designed to build from a list of kernels (we might want up to 4 different kernels in one image) that would be even better. 77776 2 sgw 2017-10-23 23:57:51 +0000 *** Bug 3732 has been marked as a duplicate of this bug. *** 77949 3 pokylinux 2017-11-03 17:06:00 +0000 The question is, do we really want different kernel versions, like 4.9, 4.10,... or would it be OK to have different patches and configs. Best would be to have a different sets of kernel version/kernel config/patches per "kernel". Could kernel patches/configs be handled by yocto ktypes? I would be extremely happy with those kernels: 1) 4.9.x configured as a standard/release kernel[1] 2) 4.9.x configured as a debug kernel[2] 3) 4.9.47 preemp-rt patched/configured 4) 4.9.51 xenomai patched/configured At the moment I create one rootfs/kernel with Yocto and the other 3 with a Yocto SDK, add user space xenomai and just exchange kernel/device trees to perform some tests. [1] https://github.com/RobertBerger/meta-mainline/blob/rocko-training-v4.9.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-base/ktypes/standard/standard.scc [2] https://github.com/RobertBerger/meta-mainline/blob/rocko-training-v4.9.x/multi-v7-ml/recipes-kernel/linux/config/multi-v7-ml-base/ktypes/debug/debug.scc 78046 4 tim.orling 2017-11-08 03:23:50 +0000 The first part of support for this has been occurring in a thread on oe-core mailing list. The latest installment is: http://lists.openembedded.org/pipermail/openembedded-core/2017-November/144031.html Please test this approach and give feedback. I performed a simple qemux86 build with the following in my local.conf: PREFERRED_PROVIDER_virtual/kernel = "linux-yocto" KERNEL_PACKAGE_NAME_pn-linux-yocto-rt = "rt-linux" KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux" CORE_IMAGE_EXTRA_INSTALL = "rt-linux tiny-linux" The resulting bzImages were in /boot as expected: bzImage -> bzImage-4.12.12-yocto-standard bzImage-4.12.12-yocto-preempt-rt bzImage-4.12.12-yocto-tiny 78652 5 sgw 2017-12-11 00:50:07 +0000 Assigning to actual implementor! 79111 6 haris.okanovic 2018-01-17 18:30:17 +0000 Resolved by commit 6c8c8998 in openembedded-core:master