2018-08-03
besk 发件人：[email protected] 发送时间：2018-08-02 23:11 主题：yocto Digest, Vol 95, Issue 5 收件人："yocto"<[email protected]> 抄送： Send yocto mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://lists.yoctoproject.org/listinfo/yocto or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of yocto digest..." Today's Topics: 1. [yocto-docs][RFC PATCH 1/2] ref-manual: Added devicetree to the Classes section (Nathan Rossi) 2. [yocto-docs][RFC PATCH 2/2] bsp-guide: Add "BSP Device Tree Examples" section (Nathan Rossi) 3. Re: Cannot use any TEST_TARGET besides simpleremote or qemu (Paulo Neves) 4. Minutes: Yocto Project Weekly Triage Meeting (Jolley, Stephen K) ---------------------------------------------------------------------- Message: 1 Date: Thu, 02 Aug 2018 19:34:35 +1000 From: Nathan Rossi <[email protected]> To: [email protected] Subject: [yocto] [yocto-docs][RFC PATCH 1/2] ref-manual: Added devicetree to the Classes section Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Add the devicetree class to the classes section of the ref-manual. This section covers the details around how the devicetree class works and how to use. Signed-off-by: Nathan Rossi <[email protected]> --- This change includes documentation about the devicetree class which is not yet in oe-core. As such this documentation is just an RFC in order to get feedback for when the changes are included in oe-core. The oe-core patch for the devicetree class can be found here: https://patchwork.openembedded.org/patch/153268/ --- documentation/ref-manual/ref-classes.xml | 49 ++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/documentation/ref-manual/ref-classes.xml b/documentation/ref-manual/ref-classes.xml index 77f21ede79..ea3704b7fb 100644 --- a/documentation/ref-manual/ref-classes.xml +++ b/documentation/ref-manual/ref-classes.xml @@ -631,6 +631,55 @@ </para> </section> +<section id='ref-classes-devicetree'> + <title><filename>devicetree.bbclass</filename></title> + + <para> + The <filename>devicetree</filename> class handles the compilation, + preprocessing, installation and deployment of device trees and device + tree overlays. + Recipes inheriting this class should provide the device tree sources + in the <link linkend='var-S'><filename>S</filename></link> directory + or otherwise modify the variable <filename>DT_FILES_PATH</filename> + to specify the location of device tree files. + </para> + + <para> + By default inheriting this class will cause the recipe to be + incompatible with any machine. + When using this class ensure to setup correct + <link linkend='var-COMPATIBLE_MACHINE'><filename>COMPATIBLE_MACHINE</filename></link> + values that correspond to the machine/BSP supported by the device tree + sources of the recipe. + </para> + + <para> + This class will depends on the kernel sources to allow for inclusion + within device tree sources. + These source can be included in device tree sources using the + "<filename>/include/</filename>" or "<filename>#include</filename>" + directives. + The default include paths from the kernel are: + <itemizedlist> + <listitem><filename>${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts</filename></listitem> + <listitem><filename>${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/*</filename></listitem> + <listitem><filename>${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes</filename></listitem> + </itemizedlist> + </para> + + <para> + These directories are set in the <filename>KERNEL_INCLUDE</filename> + variable (globbing in paths is expanded at compile time). + When this variable is set the recipe will depend on the kernel, to + disable this dependency empty the <filename>KERNEL_INCLUDE</filename> + variable. + <note> + Due to the inclusion of the kernel sources, this class defaults to + setting the license as <filename>GPLv2</filename>. + </note> + </para> +</section> + <section id='ref-classes-devshell'> <title><filename>devshell.bbclass</filename></title> -- 2.18.0 ------------------------------ Message: 2 Date: Thu, 02 Aug 2018 19:34:35 +1000 From: Nathan Rossi <[email protected]> To: [email protected] Subject: [yocto] [yocto-docs][RFC PATCH 2/2] bsp-guide: Add "BSP Device Tree Examples" section Message-ID: <[email protected]> Content-Type: text/plain; charset="utf-8" Add the "BSP Device Tree Examples" section and sub-sections for documenting the two options for compiling device trees that are part of the meta layer. These sections cover examples for the beaglebone-yocto machine, as well as providing some information around reasons to use one method over the other or in conjunction with the other. Signed-off-by: Nathan Rossi <[email protected]> --- This change includes documentation about the devicetree class which is not yet in oe-core. As such this documentation is just an RFC in order to get feedback for when the changes are included in oe-core. The oe-core patch for the devicetree class can be found here: https://patchwork.openembedded.org/patch/153268/ --- documentation/bsp-guide/bsp.xml | 168 ++++++++++++++++++++++++++++++++ 1 file changed, 168 insertions(+) diff --git a/documentation/bsp-guide/bsp.xml b/documentation/bsp-guide/bsp.xml index 0bb0b68ab2..2244cdee59 100644 --- a/documentation/bsp-guide/bsp.xml +++ b/documentation/bsp-guide/bsp.xml @@ -2265,5 +2265,173 @@ </itemizedlist> </para> </section> + + <section id='bsp-device-tree-example'> + <title>BSP Device Tree Examples</title> + + <para> + Certain BSPs (like the BeagleBone) require device tree + configuration. + There are two common configuration mechanisms to enable + compilation and deployment of device trees (and/or + overlays). + These following configurations for device tree compilation + are not mutually exclusive, depending on the BSP both can be + used to achieve one or more desired device tree configurations. + </para> + + <section id='bsp-device-tree-kernel-example'> + <title>BSP Kernel Device Tree Example</title> + + <para> + It is common for machines to have their device tree sources + maintained in the kernel sources. + In order to build these device trees during the kernel build + the make targets (e.g. <filename>am335x-bone.dtb</filename>) + for the desired device trees should be set in the variable + <ulink url='&YOCTO_DOCS_REF_URL;#var-KERNEL_DEVICETREE'><filename>KERNEL_DEVICETREE</filename></ulink>, + multiple targets can be set with spaces seperating the target + names. + For details on how and where to specify this variable see the + previous section + "<ulink url='&YOCTO_DOCS_BSP_URL;#bsp-machine-configuration-example'>BSP Machine Configuration Example</ulink>". + </para> + + <para> + The device trees located in the kernel sources are within the + <filename>arch/<replaceable>architecture</replaceable>/boot/dts</filename> + and or + <filename>arch/<replaceable>architecture</replaceable>/boot/dts/<replaceable>vendor</replaceable></filename> + directories. + Depending on the kernel recipe used the sources will vary and + as such the supported/available device trees will differ. + This is a limitation of using device trees located in the + kernel sources. + For custom BSPs this setup may be desired such that the device + tree for the custom board can be maintained as patches to the + kernel or as part of a forked kernel tree. + </para> + + <para> + To add device trees for custom BSPs or where the device tree + sources are not already located in the kernel source, the + target kernel recipe needs to be appended or modified. + For more details on how to modify existing recipes and + patching the kernel sources see the + "<ulink url='&YOCTO_DOCS_KERNEL_DEV_URL;#modifying-an-existing-recipe'>Modifying an Existing Recipe</ulink>". + </para> + </section> + + <section id='bsp-device-tree-recipe-example'> + <title>BSP Device Tree Recipe Example</title> + + <para> + BSPs vary greatly is scope, relying on device tree sources + being in the kernel sources may be undesired. + The + <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-devicetree'><filename>devicetree</filename></ulink> + class allows for compiling of device tree sources from any + location that bitbake can fetch. + </para> + + <para> + To setup the compilation of device tree sources create a BSP + specific recipe. + For more details on how to create recipes see the section + "<ulink url='&YOCTO_DOCS_DEV_URL;#new-recipe-writing-a-new-recipe'>Writing a New Recipe</ulink>". + Inheriting the + <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-devicetree'><filename>devicetree</filename></ulink> + class provides all the setup for compilation, preprocessing as + well as providing kernel includes. + This compilation and preprocessing allows for the sources to be + processed like kernel device trees, where a device tree may use + C style preprocessor directives (e.g. + <filename>#include</filename>). + Define the source device tree location, in the following + example the source is provided as a file in the layer within + the "<filename>files/</filename>" subdirectory. + </para> + + <literallayout class='monospaced'> + inherit devicetree + + COMPATIBLE_MACHINE = "beaglebone-yocto" + SRC_URI = "file://beaglebone-uart4.dts" + </literallayout> + + <para> + The following is the source device tree, located under + <filename>files/beaglebone-uart4.dts</filename>. + </para> + + <literallayout class='monospaced'> + #include "am335x-bone.dts" + + &am33xx_pinmux { + bb_uart4_pins: pinmux_bb_uart4_pins { + pinctrl-single,pins = + <0x070 (PIN_INPUT | MUX_MODE6)>, /* P9.11 uart4 rx */ + <0x074 (PIN_OUTPUT | MUX_MODE6)>; /* P9.13 uart4 tx */ + }; + }; + + &uart4 { + status = "okay"; + pinctrl-names = "default"; + pinctrl-0 = <&bb_uart4_pins>; + }; + </literallayout> + + <para> + The + <ulink url='&YOCTO_DOCS_REF_URL;#ref-classes-devicetree'><filename>devicetree</filename></ulink> + class can also handle the compilation of device tree overlays. + Overlay <filename>.dts</filename> files are determined to be + overlays based on the use of "<filename>/plugin/;</filename>". + The previous example of enabling UART 4 for the BeagleBone can + be configured as an overlay, the following example shows the + equivalent configuration for the BeagleBone to enable UART 4. + </para> + + <para> + The following is the source device tree overlay, located + within the layer under + <filename>files/beaglebone-uart4.dts</filename> + within the recipes directory. + </para> + + <literallayout class='monospaced'> + /dts-v1/; + /plugin/; + #include <dt-bindings/pinctrl/am33xx.h> + / { + compatible = "ti,beaglebone", "ti,beaglebone-black"; + part-number = "BB-UART4"; + version = "00A0"; + exclusive-user = "P9.11", "P9.13", "uart4"; + + fragment@0 { + target = <&am33xx_pinmux>; + __overlay__ { + bb_uart4_pins: pinmux_bb_uart4_pins { + pinctrl-single,pins = + <0x070 (PIN_INPUT | MUX_MODE6)>, /* P9.11 uart4 rx */ + <0x074 (PIN_OUTPUT | MUX_MODE6)>; /* P9.13 uart4 tx */ + }; + }; + }; + + fragment@1 { + target = <&uart4>; + __overlay__ { + status = "okay"; + pinctrl-name = "default"; + pinctrl-0 = <&bb_uart4_pins>; + }; + }; + }; + </literallayout> + </section> + </section> </section> </chapter> -- 2.18.0 ------------------------------ Message: 3 Date: Thu, 2 Aug 2018 16:53:03 +0200 From: Paulo Neves <[email protected]> To: Paul Eggleton <[email protected]> Cc: Yocto list discussion <[email protected]> Subject: Re: [yocto] Cannot use any TEST_TARGET besides simpleremote or qemu Message-ID: <cajo0j4gx-dqwwkss9drvosfs1zt-xtiws7dtod++azuo44-...@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" Hello Paul, I find this functionality very useful for test benches of embedded systems. Now that you said it was broken i started pruning code and have 3 ways we can and save the current functionality: 1 In the testimage.bbclass, pass the td variable to OERuntimeTestContextExecutor.getTarget(). Also greatly simplifying argument passing. 2 In the testimage.bbclass add the td variable to the kwargs so that controllers can access the datastore at __init__ time. 3 Have the user set a variable with a list of variables (!) that should available in kwargs. I will give it a try by simply passing td. This way we give all the information that controllers might need to work. As td is retrieved by the json file generated at the image creation time the external test (bitbakeless) functionality should be unaffected. Let me know if you have different opinions. Paulo Neves On Thu, Aug 2, 2018 at 10:35 AM, Paul Eggleton <[email protected]> wrote: > Hi Paulo, > > On Thursday, 2 August 2018 12:11:37 AM BST Paulo Neves wrote: >> I am trying to create my own test controller. After copy pasting and >> adapting the skeleton from BeagleBoneTarget to >> $MYLAYER/lib/oeqa/controllers I set the appropriate TEST_TARGET. >> >> When I run the testimage task I always have errors like in [1]. The >> actual keyword that is unexpected changes from invocation to >> invocation. There was a similar error previously reported in this >> mailing list but the presented solution was to actually stop using the >> TEST_TARGET variable, which is not applicable. >> >> I have tried setting TEST_TARGET to any of the proposed options in the >> manual [2] and the same unhelping error shows. I know that some of >> that these controller targets, are not appropriate for my target >> (odroid [cortex-arm15]), but the errors seems to not be related to any >> functionality or these boards. >> >> I have analyzed and cannot really understand also how all the example >> targets classes have a constructor which takes the d variable, while >> the context.py call has some more variables including a dictionary, >> kwargs, which does not actually have the d variable. > > I discovered this as well: > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12842 > > This code got broken during the refactoring a while ago, and I think the > person doing the work considered it to be legacy functionality and was going > to remove it. Personally I'd like to see it stay and get fixed up, but the > issue is having the time to fix it and maintain it - if you do by any chance > then that would be great. > > At the moment I believe "simpleremote" does still work, it's just the actual > classes that are broken, but I didn't give it extensive testing. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > ------------------------------ Message: 4 Date: Thu, 2 Aug 2018 15:11:28 +0000 From: "Jolley, Stephen K" <[email protected]> To: "[email protected]" <[email protected]> Subject: [yocto] Minutes: Yocto Project Weekly Triage Meeting Message-ID: <9add3fde8b189b4aa2f8a3c711f8155ec7369...@fmsmsx111.amr.corp.intel.com> Content-Type: text/plain; charset="utf-8" Attendees: Armin, Stephen, Amanda, Joshua, Richard, Ross, Paul, Brian, Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage AR: Armin ? Comment on 12865<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12865> AR: Armin ? Close 12761<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12761>, 12839<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12839>, 12852<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12852>, 12853<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12853>, 12070<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12070>, 12766<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12766>, 12779<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12779>, 12812<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12812> AR: Paul ? Review and update 12102<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12102> AR: Richard ? Review and update 12866<https://bugzilla.yoctoproject.org/show_bug.cgi?id=12866> Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 ? Cell: (208) 244-4460 ? Email: [email protected] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180802/694a244b/attachment.html> ------------------------------ -- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto End of yocto Digest, Vol 95, Issue 5 ************************************
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
