date:20180802

Re: [yocto] Cannot use any TEST_TARGET besides simpleremote or qemu

2018-08-02 Thread Paul Eggleton

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


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][RFC PATCH 1/2] ref-manual: Added devicetree to the Classes section

2018-08-02 Thread Nathan Rossi

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 
---
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 @@
 
 
 
+
+devicetree.bbclass
+
+
+The devicetree 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 S directory
+or otherwise modify the variable DT_FILES_PATH
+to specify the location of device tree files.
+
+
+
+By default inheriting this class will cause the recipe to be
+incompatible with any machine.
+When using this class ensure to setup correct
+COMPATIBLE_MACHINE
+values that correspond to the machine/BSP supported by the device tree
+sources of the recipe.
+
+
+
+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
+"/include/" or "#include"
+directives.
+The default include paths from the kernel are:
+
+
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts
+
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/*
+
${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes
+
+
+
+
+These directories are set in the KERNEL_INCLUDE
+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 KERNEL_INCLUDE
+variable.
+
+Due to the inclusion of the kernel sources, this class defaults to
+setting the license as GPLv2.
+
+
+
+
 
 devshell.bbclass
 
-- 
2.18.0

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][RFC PATCH 2/2] bsp-guide: Add "BSP Device Tree Examples" section

2018-08-02 Thread Nathan Rossi

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 
---
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 @@
 
 
 
+
+
+BSP Device Tree Examples
+
+
+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.
+
+
+
+BSP Kernel Device Tree Example
+
+
+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. am335x-bone.dtb)
+for the desired device trees should be set in the variable
+KERNEL_DEVICETREE,
+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
+"BSP Machine 
Configuration Example".
+
+
+
+The device trees located in the kernel sources are within the
+
arch/architecture/boot/dts
+and or
+
arch/architecture/boot/dts/vendor
+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.
+
+
+
+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
+"Modifying an 
Existing Recipe".
+
+
+
+
+BSP Device Tree Recipe Example
+
+
+BSPs vary greatly is scope, relying on device tree sources
+being in the kernel sources may be undesired.
+The
+devicetree
+class allows for compiling of device tree sources from any
+location that bitbake can fetch.
+
+
+
+To setup the compilation of device tree sources create a BSP
+specific recipe.
+For more details on how to create recipes see the section
+"Writing a New 
Recipe".
+Inheriting the
+devicetree
+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.
+#include).
+Define the source device tree location, in the following
+example the source is provided as a file in the layer within
+the "files/" subdirectory.
+
+
+
+ inherit devicetree
+
+ COMPATIBLE_MACHINE = "beaglebone-yocto"
+ SRC_URI = "file://beaglebone-uart4.dts"
+
+
+
+The following is the source

Re: [yocto] Cannot use any TEST_TARGET besides simpleremote or qemu

2018-08-02 Thread Paulo Neves

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
 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
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Minutes: Yocto Project Weekly Triage Meeting

2018-08-02 Thread Jolley, Stephen K

Attendees: Armin, Stephen, Amanda, Joshua, Richard, Ross, Paul, Brian,

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

AR: Armin – Comment on 
12865
AR: Armin – Close 
12761, 
12839, 
12852, 
12853, 
12070, 
12766, 
12779, 
12812
AR: Paul – Review and update 
12102
AR: Richard – Review and update 
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.jol...@intel.com


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Non-deterministic build error in package gcc-source

2018-08-02 Thread Erik Nellessen

Hi Ross,

thanks for your response!

I deactivated the archiver and started about 40 builds. The problem did not 
occur.

We discussed the different archiver modes. For us, it is probably the best 
solution to run the archiver with the following configuration:

ARCHIVER_MODE[src] ?= "original"

ARCHIVER_MODE[diff] ?= "1"

To get the original source files and the patches.

I am running some builds right now to evaluate if this configuration runs 
without problems.

In any case I would like to report a bug concerning the problems when running 
the archiver in patched mode. I tried to create a Bugzilla account, but it was 
not possible, because all of my tries were automatically cancelled. I wrote an 
email to mich...@yoctoproject.org and hope to get an account soon.

Kind regards,

Erik

Von: Burton, Ross 
Gesendet: Dienstag, 31. Juli 2018 22:18
An: Erik Nellessen
Cc: yocto@yoctoproject.org
Betreff: Re: [yocto] Non-deterministic build error in package gcc-source

Obvious short answer is do you actually need to use the archiver in
patched mode?  Changing to a different mode, or disabling the archiver
entirely, may solve this.

Long answer is this is most likely a race in the archiver, so filing a
bug with as many details as you can would be good.

Ross

On 30 July 2018 at 08:48, Erik Nellessen  wrote:
> We are building an operating system based on poky
> (f0ec7c8b2dc1797ba22c45653a5f182b63354092, bitbake: toaster: add 'Sumo' to
> release selection).
>
>
> Sometimes (about 1 in 10 times) our build fails, because the task
> do_ar_patched fails for package gcc-source-7.3.0-7.3.0-r0.
>
>
> The short error message:
>
> 14:44:09 Exception: FileNotFoundError: [Errno 2] No such file or directory:
> '/home/jenkins/workspace/_Config_mguard_0.1.0_MG-254-QLU3J23WOWLZZG76AVHU5BVY3M7SIU3EOQQQSUQNOEXHTXRFTQMQ_2/build/qemux86-64_tmp/work-shared/gcc-7.3.0-r0/gcc-7.3.0/gcc/gengtype-lex.c'
> 14:44:09
> 14:44:09 ERROR: gcc-source-7.3.0-7.3.0-r0 do_ar_patched: Function failed:
> do_ar_patched
> 14:44:09 ERROR: Logfile of failure stored in:
> /home/jenkins/workspace/_Config_mguard_0.1.0_MG-254-QLU3J23WOWLZZG76AVHU5BVY3M7SIU3EOQQQSUQNOEXHTXRFTQMQ_2/build/qemux86-64_tmp/work-shared/gcc-7.3.0-r0/temp/log.do_ar_patched.43242
> 14:44:09 NOTE: recipe gcc-source-7.3.0-7.3.0-r0: task do_ar_patched: Failed
> 14:44:09 ERROR: Task
> (/home/jenkins/workspace/_Config_mguard_0.1.0_MG-254-QLU3J23WOWLZZG76AVHU5BVY3M7SIU3EOQQQSUQNOEXHTXRFTQMQ_2//mguard/poky/meta/recipes-devtools/gcc/gcc-source_7.3.bb:do_ar_patched)
> failed with exit code '1'
>
> I attached the full error message as a text file.
>
>
> Does anybody know this error message? Does anybody experience similar
> problems with non-deterministic build failure?
>
>
> Kind regards,
>
> Erik
>
> ..
> Phoenix Contact GmbH & Co. KG
>
> Sitz der Gesellschaft / registered office of the company: 32825 Blomberg
> USt-Id-Nr.: DE124613250
> Pers. haftende Gesellschafterin / personally liable partner: Phoenix Contact
> Verwaltungs GmbH
> Amtsgericht Lemgo HRB 5273 / district court Lemgo HRB 5273
> Kom. Ges. Amtsgericht Lemgo HRA 3746 / limited commercial partnership
> district court Lemgo HRA 3746
> Geschäftsführer / Executive Board: Frank Stührenberg (Vorsitzender / Chief
> Executive Officer), Roland Bent, Prof. Dr. Gunther Olesch, Axel Wachholz
> ___
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren, jegliche anderweitige
> Verwendung sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
> 
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure, distribution or other use of the material
> or parts thereof is strictly forbidden.
> ___
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions. 
Subscribe before posting to bypass moderation.

>
..
Phoenix Contact GmbH & Co. KG

Sitz der Gesellschaft / registered office of the company: 32825 Blomberg
USt-Id-Nr.: DE124613

[yocto] (无主题)

2018-08-02 Thread besk

gt; 
> 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 + 
From: "Jolley, Stephen K"  
To: "yocto@yoctoproject.org"  
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:stephen.k.jol...@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 
 -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cannot use any TEST_TARGET besides simpleremote or qemu

[yocto] [yocto-docs][RFC PATCH 1/2] ref-manual: Added devicetree to the Classes section

[yocto] [yocto-docs][RFC PATCH 2/2] bsp-guide: Add "BSP Device Tree Examples" section

Re: [yocto] Cannot use any TEST_TARGET besides simpleremote or qemu

[yocto] Minutes: Yocto Project Weekly Triage Meeting

Re: [yocto] Non-deterministic build error in package gcc-source

[yocto] (无主题)

7 matches

Site Navigation

Mail list logo

Footer information