summaryrefslogtreecommitdiffstats
path: root/meta/classes/kernel-devicetree.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* kernel*.bbclass: rename *_SYMLINK_NAME variables to *_LINK_NAME and ↵Martin Jansa2018-08-211-11/+11
| | | | | | | | | | | | | | *_BASE_NAME to *_NAME * for consistency with IMAGE_NAME and IMAGE_LINK_NAME and to avoid confusion with IMAGE_BASENAME (which is the actual name of the artifact, e.g. PN while KERNEL_IMAGE_BASE_NAME was only the version suffix) (From OE-Core rev: f952c8e08b4798aa0f8bf764cfd70bda0eae9b8b) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-devicetree.bbclass: Fix and simplify instalation of DTB filesMartin Jansa2018-07-101-32/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * add 2 new variables: KERNEL_DTB_BASE_NAME KERNEL_DTB_SYMLINK_NAME instead of reusing KERNEL_IMAGE_SYMLINK_NAME and than expecting that default value ${MACHINE} was being used in e.g.: DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"` * install normal DTB files only once even if there is multiple entries in KERNEL_IMAGETYPE_FOR_MAKE and don't prefix them with the type of the kernel image, use the KERNEL_IMAGETYPE_FOR_MAKE as a prefix only when installing them bundled with kernel or initramfs image. * deploy the files from ${D}/${KERNEL_IMAGEDEST}/ instead of kernel build directory, so that we don't need to call DTB_PATH=`get_real_dtb_path_in_kernel "${DTB}"` again in do_deploy * create all links in do_deploy task, because default KERNEL_DTB_BASE_NAME like KERNEL_IMAGE_BASE_NAME contains PKGR and PKGR is different in do_install and do_deploy, because kernel.bbclass calls meta/classes/kernel.bbclass:do_install[prefuncs] += "package_get_auto_pr" meta/classes/kernel.bbclass:do_deploy[prefuncs] += "package_get_auto_pr" * the filenames are a bit different, but with separate variable it should be easier for other bbclasses which use these DTB files to find them correctly, just use either the cannonical name $dtb_base_name.$dtb_ext or $dtb_base_name-${KERNEL_DTB_SYMLINK_NAME}.$dtb_ext because PKGR (and other PKG* variables) might be different in your task and kernel.do_deploy task. * fix DTB files being deployed with incorrect filenames when KERNEL_IMAGE_SYMLINK_NAME isn't set to ${MACHINE}, e.g. instead of the default: -rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 07:41 deploy/images/raspberrypi3-64/Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/Image-lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo lrwxrwxrwx 2 bitbake bitbake 64 Nov 20 07:41 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-1-4.9.59+git0+e7976b2aff-r0.2-lirc-rpi-20171120043031.dtbo I was getting: -rw-r--r-- 2 bitbake bitbake 1348 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi.dtbo lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/Image-linux-raspberrypi-lirc-rpi-master-20171120102653.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo lrwxrwxrwx 2 bitbake bitbake 37 Nov 20 10:28 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> Image-linux-raspberrypi-lirc-rpi.dtbo and e.g. sdcard_image-rpi.bbclass from meta-raspberrypi: https://github.com/agherzan/meta-raspberrypi/blob/37e4e18f4a745ce8dc11f7e40a29da0859ff13c6/classes/sdcard_image-rpi.bbclass was failing in: mcopy -i ${WORKDIR}/boot.img -s ${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb ::${DTB_BASE_NAME}.dtb because ${KERNEL_IMAGETYPE}-${DTB_BASE_NAME}.dtb doesn't exist in my build, due to DTB_SYMLINK_NAME=`echo ${symlink_name} | sed "s/${MACHINE}/${DTB_BASE_NAME}/g"` not replacing whole "${KERNEL_IMAGE_SYMLINK_NAME}" (read ${MACHINE}) with just ${DTB_BASE_NAME} * with this change applied the deploy dir looks like this: -rw-r--r-- 2 bitbake bitbake 1.4K Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo lrwxrwxrwx 2 bitbake bitbake 74 Nov 20 15:49 deploy/images/raspberrypi3-64/lirc-rpi-raspberrypi3-64.dtbo -> lirc-rpi-1-4.9.59+git0+e7976b2aff-r0.8-raspberrypi3-64-20171120154716.dtbo and works correctly even with DISTRO using different naming scheme * the sdcard_image-rpi.bbclass still needs to be modified, I've provided updated version here: https://github.com/agherzan/meta-raspberrypi/pull/159 * mpc8315e-rdb.conf MACHINE in meta-yocto-bsp also needs small fix: https://lists.yoctoproject.org/pipermail/poky/2018-July/011436.html (From OE-Core rev: 1860d9d3c62e2e94cd68a809385873ffd8270b6d) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-devicetree.bbclass: Use lowercase names for shell variablesMartin Jansa2018-07-101-40/+40
| | | | | | | | | | | | * just to make it more clear what is local shell variable and what is replaced by bitbake from the metadata and also to prevent the variable to be incorrectly expanded by bitbake if someone happens to define e.g. DTB_BASE_NAME (From OE-Core rev: 98b0f13f0650d970aac7441e7fcfc1089570785f) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Revert "kernel-devicetree: Corrected normalize_dtb"Martin Jansa2018-07-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 2e7f3b2b9318d1e5395ad58131eafb873f614326. It was breaking quite common use case that the dtb files are in some subdirectory and then kernel build fails to build them. As reported by khem: http://lists.openembedded.org/pipermail/openembedded-core/2018-July/152578.html me: http://lists.openembedded.org/pipermail/openembedded-core/2018-July/152579.html on raspberrypi3 build: make[3]: *** No rule to make target 'arch/arm/boot/dts/dwc2.dtbo'. Stop. arch/arm/Makefile:345: recipe for target 'dwc2.dtbo' failed make[2]: *** [dwc2.dtbo] Error 2 Makefile:146: recipe for target 'sub-make' failed and trevor on the IRC: 20:35:49 < tlwoerner> the recent 2e7f3b2b9318d1e5395ad58131eafb873f614326 commit in oe-core seems to cause dragonboard-410c's kernel to fail to build 20:36:26 < tlwoerner> for the dragonboard-410c, KERNEL_DEVICETREE is set to "qcom/apq8016-sbc.dtb" but the build failure is: 20:36:37 < tlwoerner> *** No rule to make target 'arch/arm64/boot/dts/dts/qcom/apq8016-sbc.dtb'. Stop. 20:36:44 < tlwoerner> i.e. the "qcom/" is getting removed 20:37:08 < tlwoerner> oops!! 20:37:33 < tlwoerner> wrong copy&paste, the actual error is: 20:37:36 < tlwoerner> *** No rule to make target 'arch/arm64/boot/dts/apq8016-sbc.dtb'. Stop. 20:37:53 < tlwoerner> i.e., the "qcom/" is being stripped out (From OE-Core rev: 0d725c76c113dec441a7319a6ee997e4ae8c4c88) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-devicetree: Corrected normalize_dtbPaulo Neves2018-07-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | The normalize_dtb function was buggy because it only converted from .dts suffix to .dtb suffix if the user passed a full source path to KERNEL_DEVICETREE containing the /dts/ path. The problem is that if the user did that there would be a warning. On the othet hand if user just set the variable KERNEL_DEVICETREE="file.dts" the bbclass translation to the respective .dtb target did not occur and make would fail saying it has no rule to make target file.dts This patch decouples the logic of having /dts/ in the path from the target translation. (From OE-Core rev: 2e7f3b2b9318d1e5395ad58131eafb873f614326) Signed-off-by: Paulo Neves <ptsneves@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: Add support for multiple kernel packagesHaris Okanovic2018-01-021-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some distros may want to provide alternate kernel "flavors" via feeds or within bootable images. For example, readily available builds which provide certain diagnostic features can enable developers and testers to more quickly resolve issues by avoiding lengthy kernel builds. This change allows for building multiple flavors of the kernel and module packages by templatizing kernel package names via a new KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old name of "kernel", but can be overridden by certain recipes providing alternate kernel flavors. To maintain compatibility, recipes providing alternate kernel flavors cannot be the "preferred provider" for virtual/kernel. This is because OE puts the preferred provider's build and source at "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build in the old location and may be preferred provider -- while recipes using all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't provide "virtual/kernel". Testing: 1. Add `KERNEL_PACKAGE_NAME_pn-linux-yocto-tiny = "tiny-linux"` to local.conf so that linux-yocto-tiny may build alongside the main kernel (linux-yocto). 2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors. 3. Verified image and modules IPKs exist for both: tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny 4. Verified linux-yocto is the "preferred provider", and was built in shared directory: tmp-glibc/work-shared/qemux86/kernel-* 5. Add `CORE_IMAGE_BASE_INSTALL_append_pn-core-image-base = "tiny-linux"` to local.conf to install both kernel flavors in core-image-base. 6. `bitbake core-image-base` to build an image. 7. Verified image contains two bzImage's under /boot/, with "yocto-standard" (linux-yocto recipe) selected to boot via symlink. Discussion threads: http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122 http://lists.openembedded.org/pipermail/openembedded-core/2017-July/thread.html#139130 [YOCTO #11363] (From OE-Core rev: 6c8c899849d101fd1b86aad0b8eed05c7c785924) Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com> Signed-off-by: Gratian Crisan <gratian.crisan@ni.com> Signed-off-by: Haris Okanovic <haris.okanovic@ni.com> Coauthored-by: Gratian Crisan <gratian.crisan@ni.com> Coauthored-by: Haris Okanovic <haris.okanovic@ni.com> Coauthored-by: Josh Hernstrom <josh.hernstrom@ni.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-devicetree.bbclass: Add support to generate append to kernelOtavio Salvador2017-09-251-1/+51
| | | | | | | | | | | | | | The are use cases where the Device Tree appended to the kernel is convinient, so we generate the bundle concatenating the kernel (and potentionally the initramfs) and the Device Tree binaries. To enable it, set KERNEL_DEVICETREE_BUNDLE variable to '1' (From OE-Core rev: f044567326988e84e5d72040e9387c3240836ddb) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: Move Device Tree support to kernel.bbclassOtavio Salvador2017-09-131-0/+62
The Device Tree is commonly used but it is still kept as a .inc file instead of a proper class. Instead now we move the Device Tree code to a kernel-devicetree class and automatically enable it when the KERNEL_DEVICETREE variable is set. To avoid breakage in existing layers, we kept a linux-dtb.inc file which raises a warning telling the user about the change so in next release this can be removed. (From OE-Core rev: 03a00be7f2062aefef0e51ef20a4c9737f6685e7) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>