* (无主题)
[not found] <mailman.89165.1533222691.15860.yocto@yoctoproject.org>
@ 2018-08-03 1:24 ` besk
0 siblings, 0 replies; only message in thread
From: besk @ 2018-08-03 1:24 UTC (permalink / raw)
To: yocto
[-- Attachment #1: Type: text/plain, Size: 19917 bytes --]
2018-08-03
besk
发件人：yocto-request@yoctoproject.org
发送时间：2018-08-02 23:11
主题：yocto Digest, Vol 95, Issue 5
收件人："yocto"<yocto@yoctoproject.org>
抄送：
Send yocto mailing list submissions to
yocto@yoctoproject.org
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
yocto-request@yoctoproject.org
You can reach the person managing the list at
yocto-owner@yoctoproject.org
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 <nathan@nathanrossi.com>
To: yocto@yoctoproject.org
Subject: [yocto] [yocto-docs][RFC PATCH 1/2] ref-manual: Added
devicetree to the Classes section
Message-ID: <20180802093435.17849-1-nathan@nathanrossi.com>
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 <nathan@nathanrossi.com>
---
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 <nathan@nathanrossi.com>
To: yocto@yoctoproject.org
Subject: [yocto] [yocto-docs][RFC PATCH 2/2] bsp-guide: Add "BSP
Device Tree Examples" section
Message-ID: <20180802093435.17849-2-nathan@nathanrossi.com>
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 <nathan@nathanrossi.com>
---
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 <ptsneves@gmail.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: Yocto list discussion <yocto@yoctoproject.org>
Subject: Re: [yocto] Cannot use any TEST_TARGET besides simpleremote
or qemu
Message-ID:
<CAJO0J4gX-dqwwkSS9dRvoSFS1Zt-xtiWs7dtod++aZUo44-0kw@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
<paul.eggleton@linux.intel.com> 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" <stephen.k.jolley@intel.com>
To: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: [yocto] Minutes: Yocto Project Weekly Triage Meeting
Message-ID:
<9ADD3FDE8B189B4AA2F8A3C711F8155EC736986C@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: stephen.k.jolley@intel.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20180802/694a244b/attachment.html>
------------------------------
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
End of yocto Digest, Vol 95, Issue 5
************************************
[-- Attachment #2: Type: text/html, Size: 50779 bytes --]
^ permalink raw reply related [flat|nested] only message in thread