Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
On 8 August 2018 at 06:27, Jaewon Lee wrote: > > Hi Nathan, > > > On 08/07/2018 04:59 AM, Nathan Rossi wrote: >> >> On 7 August 2018 at 07:16, Jaewon Lee wrote: >>> >>> Hi Nathan, >>> >>> What do you think about adding support for dts include files as well >>> (.dtsi)? >> >> Hi Jaewon, >> >> Device tree include files already work with the implementation in this >> patch. The default include path is the same as the path of the dts >> files, so if you use "/include/ ".dtsi";" (dtc) or "#include >> " (preprocessor) it will search within the DT_FILES_PATH >> (which is WORKDIR by default) and then the KERNEL_INCLUDE paths. >> Though if the dtsi is in another path you can add it to DT_INCLUDE, >> and it will be searched. > > If i'm understanding correctly, this flow just supports compiling a dts file > that has a plugin tag (it can include dtsi files) > in short I can't compile the dtsi file itself to a dtbo Correct, that is the common practice when it comes to dts and dtsi files. >> >> Does this cover the support you are after or is there another >> configuration you would like it to support? > > Yes for us, if dt overlays are enabled, we don't include a dtsi in the base > dts and compile that dtsi separately as a dtbo which is loaded later. > so would be great to loop through all dtsi files as well and compile if it > has a plugin tag. > > Your thoughts? The behaviour you are after sounds specific to the sources you have. There would be some issues if the default behaviour of the class worked in the way you desire, such as name conflicts (a.dtsi -> a.dtbo, a.dts -> a.dtbo, which one is used?). However the class should be able to handle your use case. With the current implementation you could handle it by creating a custom or appended do_compile and using the devicetree_compile function. But maybe it is worth handling the use case in a more generic way. For example the class could instead have "DT_FILES" instead of "DT_FILES_PATH", where DT_FILES is a space separated list of files which expands with globbing. Then to enable building .dtsi files append the paths to DT_FILES in your recipe, e.g. DT_FILES += "${S}/*.dtsi". Though it would not be able to filter out dtsi's that are not /plugin/;. Regards, Nathan > > Thanks, > Jaewon > > >> >> Thanks, >> Nathan >> >>> Thanks, >>> Jaewon >>> >>> >>> -----Original Message- >>> From: openembedded-core-boun...@lists.openembedded.org >>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of >>> Nathan Rossi >>> Sent: Thursday, August 2, 2018 1:55 AM >>> To: openembedded-core@lists.openembedded.org >>> Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree >>> source compilation class >>> >>> This bbclass implements the device tree compilation for user provided >>> device trees. In order to use this class, it should be inherited in a BSP >>> recipe which provides the sources. The default setup enables inclusion of >>> kernel device tree sources (though can be disabled by the recipe by >>> overriding DT_INCLUDE or KERNEL_INCLUDE). >>> >>> This provides an additional mechanism for BSPs to provide device trees >>> and device tree overlays for their target machines. Whilst still enabling >>> access to the kernel device trees for base SoC includes and headers. >>> >>> This approach to providing device trees has benefits for certain use >>> cases over patching the device trees into the kernel source. >>> >>> * device trees are separated from kernel source, allows for selection of >>> kernel and or kernel versions without needing to explicitly patch the kernel >>> (or appending to the kernel recipes). >>> >>> * providing device trees from separate sources, from the layer, generated >>> by the recipe or other recipes. >>> >>> This class also implements some additional features that are not >>> available in the kernel-devicetree flow. This includes population of device >>> tree blobs into the sysroot which allows for other recipes to consume built >>> dtbs (e.g. U-Boot with EXT_DTB compilation), device tree overlay compilation >>> and customizing DTC compilation args (boot cpu/padding/etc.). >>> >>> Signed-off-by: Nathan Rossi >>> Acked-by: Martin Hundebøll >>> --- >>> In addition to this patch I have written some documentation for the Yocto >>> BSP guide that cov
Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
Hi Nathan, On 08/07/2018 04:59 AM, Nathan Rossi wrote: On 7 August 2018 at 07:16, Jaewon Lee wrote: Hi Nathan, What do you think about adding support for dts include files as well (.dtsi)? Hi Jaewon, Device tree include files already work with the implementation in this patch. The default include path is the same as the path of the dts files, so if you use "/include/ ".dtsi";" (dtc) or "#include " (preprocessor) it will search within the DT_FILES_PATH (which is WORKDIR by default) and then the KERNEL_INCLUDE paths. Though if the dtsi is in another path you can add it to DT_INCLUDE, and it will be searched. If i'm understanding correctly, this flow just supports compiling a dts file that has a plugin tag (it can include dtsi files) in short I can't compile the dtsi file itself to a dtbo Does this cover the support you are after or is there another configuration you would like it to support? Yes for us, if dt overlays are enabled, we don't include a dtsi in the base dts and compile that dtsi separately as a dtbo which is loaded later. so would be great to loop through all dtsi files as well and compile if it has a plugin tag. Your thoughts? Thanks, Jaewon Thanks, Nathan Thanks, Jaewon -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Nathan Rossi Sent: Thursday, August 2, 2018 1:55 AM To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class This bbclass implements the device tree compilation for user provided device trees. In order to use this class, it should be inherited in a BSP recipe which provides the sources. The default setup enables inclusion of kernel device tree sources (though can be disabled by the recipe by overriding DT_INCLUDE or KERNEL_INCLUDE). This provides an additional mechanism for BSPs to provide device trees and device tree overlays for their target machines. Whilst still enabling access to the kernel device trees for base SoC includes and headers. This approach to providing device trees has benefits for certain use cases over patching the device trees into the kernel source. * device trees are separated from kernel source, allows for selection of kernel and or kernel versions without needing to explicitly patch the kernel (or appending to the kernel recipes). * providing device trees from separate sources, from the layer, generated by the recipe or other recipes. This class also implements some additional features that are not available in the kernel-devicetree flow. This includes population of device tree blobs into the sysroot which allows for other recipes to consume built dtbs (e.g. U-Boot with EXT_DTB compilation), device tree overlay compilation and customizing DTC compilation args (boot cpu/padding/etc.). Signed-off-by: Nathan Rossi Acked-by: Martin Hundebøll --- In addition to this patch I have written some documentation for the Yocto BSP guide that covers details about both methods. The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly like this class for some time. It has been very useful for out-of-kernel device tree compilation as well as for a mechanism so that users of Xilinx SoCs can provide their customizations (FPGA devices) and board specific configuration. This compilation flow also makes sense for other BSPs, which is the reason for creating this bbclass for common shared use by other BSPs. Examples of this classes usage can be seen for meta-xilinx: https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb --- meta/classes/devicetree.bbclass | 140 1 file changed, 140 insertions(+) create mode 100644 meta/classes/devicetree.bbclass diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass new file mode 100644 index 00..dbc83f2a1d --- /dev/null +++ b/meta/classes/devicetree.bbclass @@ -0,0 +1,140 @@ +# This bbclass implements device tree compliation for user provided +device tree # sources. The compilation of the device tree sources is +the same as the kernel # device tree compilation process, this includes +being able to include sources # from the kernel such as soc dtsi files +or header files such as gpio.h. In # addition to device trees this +bbclass also handles compilation of device tree # overlays. +# +# The output of this class behaves similar to how +kernel-devicetree.bbclass # operates in that the output files are installed into /boot/devicetree. +# However this class on purpose separates the deployed device trees +into the # 'devicetree' subdirectory. This prevents clashes with the +kernel-devicetree # output. Additionally the device trees are populated +into the sysroot for # access via the sysroot from within oth
Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
On 7 August 2018 at 07:16, Jaewon Lee wrote: > Hi Nathan, > > What do you think about adding support for dts include files as well (.dtsi)? Hi Jaewon, Device tree include files already work with the implementation in this patch. The default include path is the same as the path of the dts files, so if you use "/include/ ".dtsi";" (dtc) or "#include " (preprocessor) it will search within the DT_FILES_PATH (which is WORKDIR by default) and then the KERNEL_INCLUDE paths. Though if the dtsi is in another path you can add it to DT_INCLUDE, and it will be searched. Does this cover the support you are after or is there another configuration you would like it to support? Thanks, Nathan > > Thanks, > Jaewon > > > -Original Message- > From: openembedded-core-boun...@lists.openembedded.org > [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Nathan > Rossi > Sent: Thursday, August 2, 2018 1:55 AM > To: openembedded-core@lists.openembedded.org > Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source > compilation class > > This bbclass implements the device tree compilation for user provided device > trees. In order to use this class, it should be inherited in a BSP recipe > which provides the sources. The default setup enables inclusion of kernel > device tree sources (though can be disabled by the recipe by overriding > DT_INCLUDE or KERNEL_INCLUDE). > > This provides an additional mechanism for BSPs to provide device trees and > device tree overlays for their target machines. Whilst still enabling access > to the kernel device trees for base SoC includes and headers. > > This approach to providing device trees has benefits for certain use cases > over patching the device trees into the kernel source. > > * device trees are separated from kernel source, allows for selection of > kernel and or kernel versions without needing to explicitly patch the kernel > (or appending to the kernel recipes). > > * providing device trees from separate sources, from the layer, generated by > the recipe or other recipes. > > This class also implements some additional features that are not available in > the kernel-devicetree flow. This includes population of device tree blobs > into the sysroot which allows for other recipes to consume built dtbs (e.g. > U-Boot with EXT_DTB compilation), device tree overlay compilation and > customizing DTC compilation args (boot cpu/padding/etc.). > > Signed-off-by: Nathan Rossi > Acked-by: Martin Hundebøll > --- > In addition to this patch I have written some documentation for the Yocto BSP > guide that covers details about both methods. > > The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly like > this class for some time. It has been very useful for out-of-kernel device > tree compilation as well as for a mechanism so that users of Xilinx SoCs can > provide their customizations (FPGA devices) and board specific configuration. > This compilation flow also makes sense for other BSPs, which is the reason > for creating this bbclass for common shared use by other BSPs. > > Examples of this classes usage can be seen for meta-xilinx: > https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb > --- > meta/classes/devicetree.bbclass | 140 > 1 file changed, 140 insertions(+) > create mode 100644 meta/classes/devicetree.bbclass > > diff --git a/meta/classes/devicetree.bbclass > b/meta/classes/devicetree.bbclass new file mode 100644 index > 00..dbc83f2a1d > --- /dev/null > +++ b/meta/classes/devicetree.bbclass > @@ -0,0 +1,140 @@ > +# This bbclass implements device tree compliation for user provided > +device tree # sources. The compilation of the device tree sources is > +the same as the kernel # device tree compilation process, this includes > +being able to include sources # from the kernel such as soc dtsi files > +or header files such as gpio.h. In # addition to device trees this > +bbclass also handles compilation of device tree # overlays. > +# > +# The output of this class behaves similar to how > +kernel-devicetree.bbclass # operates in that the output files are installed > into /boot/devicetree. > +# However this class on purpose separates the deployed device trees > +into the # 'devicetree' subdirectory. This prevents clashes with the > +kernel-devicetree # output. Additionally the device trees are populated > +into the sysroot for # access via the sysroot from within other recipes. > + > +SECTION ?= "bsp" > + > +# The default inclusion of kernel device tree includes
Re: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
Hi Nathan, What do you think about adding support for dts include files as well (.dtsi)? Thanks, Jaewon -Original Message- From: openembedded-core-boun...@lists.openembedded.org [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Nathan Rossi Sent: Thursday, August 2, 2018 1:55 AM To: openembedded-core@lists.openembedded.org Subject: [OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class This bbclass implements the device tree compilation for user provided device trees. In order to use this class, it should be inherited in a BSP recipe which provides the sources. The default setup enables inclusion of kernel device tree sources (though can be disabled by the recipe by overriding DT_INCLUDE or KERNEL_INCLUDE). This provides an additional mechanism for BSPs to provide device trees and device tree overlays for their target machines. Whilst still enabling access to the kernel device trees for base SoC includes and headers. This approach to providing device trees has benefits for certain use cases over patching the device trees into the kernel source. * device trees are separated from kernel source, allows for selection of kernel and or kernel versions without needing to explicitly patch the kernel (or appending to the kernel recipes). * providing device trees from separate sources, from the layer, generated by the recipe or other recipes. This class also implements some additional features that are not available in the kernel-devicetree flow. This includes population of device tree blobs into the sysroot which allows for other recipes to consume built dtbs (e.g. U-Boot with EXT_DTB compilation), device tree overlay compilation and customizing DTC compilation args (boot cpu/padding/etc.). Signed-off-by: Nathan Rossi Acked-by: Martin Hundebøll --- In addition to this patch I have written some documentation for the Yocto BSP guide that covers details about both methods. The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly like this class for some time. It has been very useful for out-of-kernel device tree compilation as well as for a mechanism so that users of Xilinx SoCs can provide their customizations (FPGA devices) and board specific configuration. This compilation flow also makes sense for other BSPs, which is the reason for creating this bbclass for common shared use by other BSPs. Examples of this classes usage can be seen for meta-xilinx: https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb --- meta/classes/devicetree.bbclass | 140 1 file changed, 140 insertions(+) create mode 100644 meta/classes/devicetree.bbclass diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass new file mode 100644 index 00..dbc83f2a1d --- /dev/null +++ b/meta/classes/devicetree.bbclass @@ -0,0 +1,140 @@ +# This bbclass implements device tree compliation for user provided +device tree # sources. The compilation of the device tree sources is +the same as the kernel # device tree compilation process, this includes +being able to include sources # from the kernel such as soc dtsi files +or header files such as gpio.h. In # addition to device trees this +bbclass also handles compilation of device tree # overlays. +# +# The output of this class behaves similar to how +kernel-devicetree.bbclass # operates in that the output files are installed into /boot/devicetree. +# However this class on purpose separates the deployed device trees +into the # 'devicetree' subdirectory. This prevents clashes with the +kernel-devicetree # output. Additionally the device trees are populated +into the sysroot for # access via the sysroot from within other recipes. + +SECTION ?= "bsp" + +# The default inclusion of kernel device tree includes and headers +means that # device trees built with them are at least GPLv2 (and in +some cases dual # licensed). Default to GPLv2 if the recipe does not specify a license. +LICENSE ?= "GPLv2" +LIC_FILES_CHKSUM ?= "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" + +INHIBIT_DEFAULT_DEPS = "1" +DEPENDS += "dtc-native" + +inherit deploy kernel-arch + +COMPATIBLE_MACHINE ?= "^$" + +PACKAGE_ARCH = "${MACHINE_ARCH}" + +SYSROOT_DIRS += "/boot/devicetree" +FILES_${PN} = "/boot/devicetree/*.dtb /boot/devicetree/*.dtbo" + +S = "${WORKDIR}" +B = "${WORKDIR}/build" + +# Default kernel includes, these represent what are normally used for +in-kernel # sources. +KERNEL_INCLUDE ??= " \ +${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \ +${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/* \ +${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \ +" + +DT_INCLUDE[doc] = "Search
[OE-core] [PATCH] devicetree.bbclass: User/BSP device tree source compilation class
This bbclass implements the device tree compilation for user provided device trees. In order to use this class, it should be inherited in a BSP recipe which provides the sources. The default setup enables inclusion of kernel device tree sources (though can be disabled by the recipe by overriding DT_INCLUDE or KERNEL_INCLUDE). This provides an additional mechanism for BSPs to provide device trees and device tree overlays for their target machines. Whilst still enabling access to the kernel device trees for base SoC includes and headers. This approach to providing device trees has benefits for certain use cases over patching the device trees into the kernel source. * device trees are separated from kernel source, allows for selection of kernel and or kernel versions without needing to explicitly patch the kernel (or appending to the kernel recipes). * providing device trees from separate sources, from the layer, generated by the recipe or other recipes. This class also implements some additional features that are not available in the kernel-devicetree flow. This includes population of device tree blobs into the sysroot which allows for other recipes to consume built dtbs (e.g. U-Boot with EXT_DTB compilation), device tree overlay compilation and customizing DTC compilation args (boot cpu/padding/etc.). Signed-off-by: Nathan Rossi Acked-by: Martin Hundebøll --- In addition to this patch I have written some documentation for the Yocto BSP guide that covers details about both methods. The meta-xilinx layer has a recipe (device-tree.bb) that behaves exactly like this class for some time. It has been very useful for out-of-kernel device tree compilation as well as for a mechanism so that users of Xilinx SoCs can provide their customizations (FPGA devices) and board specific configuration. This compilation flow also makes sense for other BSPs, which is the reason for creating this bbclass for common shared use by other BSPs. Examples of this classes usage can be seen for meta-xilinx: https://github.com/nathanrossi/meta-xilinx/blob/nrossi/devicetree-classify/meta-xilinx-bsp/recipes-bsp/device-tree/device-tree.bb --- meta/classes/devicetree.bbclass | 140 1 file changed, 140 insertions(+) create mode 100644 meta/classes/devicetree.bbclass diff --git a/meta/classes/devicetree.bbclass b/meta/classes/devicetree.bbclass new file mode 100644 index 00..dbc83f2a1d --- /dev/null +++ b/meta/classes/devicetree.bbclass @@ -0,0 +1,140 @@ +# This bbclass implements device tree compliation for user provided device tree +# sources. The compilation of the device tree sources is the same as the kernel +# device tree compilation process, this includes being able to include sources +# from the kernel such as soc dtsi files or header files such as gpio.h. In +# addition to device trees this bbclass also handles compilation of device tree +# overlays. +# +# The output of this class behaves similar to how kernel-devicetree.bbclass +# operates in that the output files are installed into /boot/devicetree. +# However this class on purpose separates the deployed device trees into the +# 'devicetree' subdirectory. This prevents clashes with the kernel-devicetree +# output. Additionally the device trees are populated into the sysroot for +# access via the sysroot from within other recipes. + +SECTION ?= "bsp" + +# The default inclusion of kernel device tree includes and headers means that +# device trees built with them are at least GPLv2 (and in some cases dual +# licensed). Default to GPLv2 if the recipe does not specify a license. +LICENSE ?= "GPLv2" +LIC_FILES_CHKSUM ?= "file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6" + +INHIBIT_DEFAULT_DEPS = "1" +DEPENDS += "dtc-native" + +inherit deploy kernel-arch + +COMPATIBLE_MACHINE ?= "^$" + +PACKAGE_ARCH = "${MACHINE_ARCH}" + +SYSROOT_DIRS += "/boot/devicetree" +FILES_${PN} = "/boot/devicetree/*.dtb /boot/devicetree/*.dtbo" + +S = "${WORKDIR}" +B = "${WORKDIR}/build" + +# Default kernel includes, these represent what are normally used for in-kernel +# sources. +KERNEL_INCLUDE ??= " \ +${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \ +${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/* \ +${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \ +" + +DT_INCLUDE[doc] = "Search paths to be made available to both the device tree compiler and preprocessor for inclusion." +DT_INCLUDE ?= "${DT_FILES_PATH} ${KERNEL_INCLUDE}" +DT_FILES_PATH[doc] = "Defaults to source directory, can be used to select dts files that are not in source (e.g. generated)." +DT_FILES_PATH ?= "${S}" + +DT_PADDING_SIZE[doc] = "Size of padding on the device tree blob, used as extra space typically for additional properties during boot." +DT_PADDING_SIZE ??= "0x3000" +DT_RESERVED_MAP[doc] = "Number of reserved map entires." +DT_RESERVED_MAP ??= "8" +DT_BOOT_CPU[doc] = "The boot cpu, defaults to 0" +DT_BOOT_CPU ??= "0" + +DTC_FLAGS