citadel/meta-citadel/recipes-citadel/images/citadel-image.inc


CITADEL_IMAGE_CHANNEL = "dev"

CITADEL_IMAGE_VERSION_rootfs = "1"
CITADEL_IMAGE_VERSION_extra = "1"
CITADEL_IMAGE_VERSION_kernel = "1"

CITADEL_KERNEL_VERSION = "5.19.9"

CITADEL_KERNEL_CONFIG = "${COREBASE}/../meta-citadel/recipes-kernel/citadel-kernel/files/defconfig"

generate_kernel_id() {
    sha256sum ${CITADEL_KERNEL_CONFIG} | cut -d' ' -f1
}
New set of images: rootfs, modules, extra 2018-12-31 18:37:43 -05:00
			`CITADEL_IMAGE_CHANNEL = "dev"`

			`CITADEL_IMAGE_VERSION_rootfs = "1"`
			`CITADEL_IMAGE_VERSION_extra = "1"`
rename citadel-modules-image to citadel-kernel-image ...and add some metadata 2019-01-06 18:20:41 -05:00			`CITADEL_IMAGE_VERSION_kernel = "1"`
New set of images: rootfs, modules, extra 2018-12-31 18:37:43 -05:00
Kernel upgraded to 5.19.9 2022-09-15 12:41:20 -04:00			`CITADEL_KERNEL_VERSION = "5.19.9"`
generate kernel.id in a more reliable way The kernel id is a sha256sum that is embedded in the kernel image header and also in the initramfs (in /etc/initrd-release). It exists so that when resource images are being located during boot, the compatibility of the citadel kernel image can be matched with the currently booting kernel. This ensures that the correct set of modules will be mounted. The kernel id had previously been calculated from the sha256sum of the kernel binary before attaching the initramfs, but the sequence of steps performed by poky when building a kernel changed and caused this method to fail. Now the sha256sum is calculated from the 'defconfig' file in the recipe directory instead. This should work equally as well to uniquely identify a kernel instance. 2020-11-30 10:10:56 -05:00
			`CITADEL_KERNEL_CONFIG = "${COREBASE}/../meta-citadel/recipes-kernel/citadel-kernel/files/defconfig"`

			`generate_kernel_id() {`
			`sha256sum ${CITADEL_KERNEL_CONFIG} \| cut -d' ' -f1`
			`}`