Re: [yocto] [PATCH] bsp-guide: replace meta-intel with meta-xilinx as container layer

[Andrea Galbusera]

On Fri, May 3, 2019 at 12:56 PM Robert P. J. Day  wrote:
>
> On Thu, 2 May 2019, Scott Rifenbark wrote:
>
> > Great, thanks!
> >
> > On Thu, May 2, 2019 at 11:21 AM akuster  wrote:
> >
> >
> >   On 5/2/19 10:45 AM, Scott Rifenbark wrote:
> >   The term "Container Layer" was put in the ref-manual by me to 
> > describe a
> >   "meta-*" layer that had other "meta-*" layers (see
> >   
> > https://www.yoctoproject.org/docs/2.7/ref-manual/ref-manual.html#term-container-layer
> >   and the term "Container Layer").  Maybe this was never a good term?  
> > I don't
> >   know.  Nobody has said anything about that term for many releases.
> >
> > The problem Robert points out needs to be fixed in the BSP manual as 
> > "meta-intel" is
> > not longer qualifying by my definition.  I can fix that.
> >
> > Is "Container Layer" ok as I have defined it?
> >
> > in those terms above, yes its fine.
>
>   the more i think about it, the more i'm nervous about the phrase
> "container layer", as it suggests a "layer" of some kind in the
> context of OE. the one distinction i think worth making is that a "BSP
> layer" is a layer expressly designed to support identified target
> systems (eg., meta-xilinx-bsp), while a non-BSP layer simply packages
> functionality (recipes, classes) -- a good example is
> meta-virtualization.
>
>   in either case, the trivial property of an OE layer is something
> that can be specified in a bblayers.conf file. so i'm not sure *how*
> you would describe, for example, meta-openembedded.

Maybe just as a "metadata collection repo"? IMHO from a OE
perspective, a "layer" is a metadata set which provides its own
layer.conf file (which, as you say, means you can add it to your
project's bblayers.conf). Bundling more than one layer within the same
git repository (or whatever archive format use to distribute them)
does not qualify this metadata collection as anything otherwise
meaningful for bitbake. That said, meta-openembedded is definitely the
most evident example of such a "concept". I agree the term "container
layer" can be either confused with a OE layer, which technically is
not, or something having to do with containers (as I suspect from
Armin's reply), which is completely unrelated to. Maybe rewording a
little bit the manual here could reduce potential confusion to new
users. Moreover whatever term we choose to explain this concept, we
should make clear that it is orthogonal to any other layer
classification by content (i.e. BSP, distro, ...).

>   i'm sure i'm overthinking this.
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
>  http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [oe] OE Summit @ SCaLE 17x - Sunday March 10th 2019 - Pasadena CA

[Andrea Galbusera]

On Thu, Jan 31, 2019 at 8:26 AM Trevor Woerner  wrote:
>
> We're excited to announce the inaugural "OpenEmbedded Summit" taking place
> Sunday March 10th 2019 as part of the Southern California Linux Expo
> (SCaLE) 17x at the Pasadena Convention Center.
>
> For the past few years there's been an ever-growing OpenEmbedded event as
> part of SCaLE. This year, with the missing Spring ELC, we felt it was time
> to do something more "formally" so OE enthusiasts could get together
> without having to wait until August.
>
> The initial suggestion for this summit came at last year's OEDEM in
> Edinburgh. At that time an idea was also floated to hold this year's OEDAM
> at the same time. Just to be absolutely clear: this suggestion was
> rejected; there will be no OEDAM at the OE Summit at SCaLE 17x. However,
> this summit is taking place with the full approval of the OpenEmbedded
> Board of Directors, many of whom have also been helping out with its
> organization.
>
> The schedule for the OE Summit has been posted:
> https://www.socallinuxexpo.org/scale/17x/schedule/sunday
> https://www.socallinuxexpo.org/scale/17x/open-embedded-summit-0

To whoever can double check and fix the schedule... it looks like
there's a typo at the second link, where Alistair's talk is listed
twice. From the first link "Lokesh Kumar Goel
OpenEmbedded in LG Products" should be at 11.30am instead.

>
> So if you're in the Southern California area, or are generally interested
> in hanging out with some OpenEmbedded people, please join us in Pasadena on
> March 10th!
>
> Your OE Summit organizing committee:
>   Tom King
>   Behan Webster
>   Trevor Woerner
> --
> ___
> Openembedded-devel mailing list
> openembedded-de...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding package's license to the final image

[Andrea Galbusera]

Hi!

On Tue, Jun 12, 2018 at 8:53 PM Mathieu Alexandre-Tétreault
 wrote:
>
> Howdy,
>
> I am working on a project that requires the final image to contain a license 
> manifest for all the packaged installed on the image.

Take a look at [1]. There's background on licence tacking and a
technique to include licenses in target images (never tested myself).

[1] 
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#providing-license-text

>
> At first I though about using the tmp/deploy/licenses/xxx/license.manifest 
> but this file is deployed by the IMAGE_POSTPROCESS_COMMAND_prepend which 
> happens after the rootfs is done.
>
> Would anyone have a suggestion on how to this properly without using any 
> weird hack?
>
> Cheers,
> Mathieu
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Enabling the recipe from menuconfig

[Andrea Galbusera]

On Fri, May 18, 2018 at 6:14 AM, chandrasekhar  wrote:
> you want to see in kernel menuconfig??
>
>
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Ugesh Reddy
> Sent: Friday, May 18, 2018 7:52 AM
> To: 'Yocto-mailing-list'; chandrasekhar
> Subject: Re: [yocto] Enabling the recipe from menuconfig
>
>
>
> Hi,
>
> Thanks for the response,
>
>
>
>  This will add the recipe as a part of image but I want to build and add the
> recipe when it has been selected from the menuconfig.
>
> How to make visible the recipe in menuconfig?

Unlike other distribution build systems, Yocto/OE don't provide any
menuconfig based configuration interface for selecting which package
to include in images you build. There is indeed support for accessing
menuconfig interfaces provided by specific recipes like the linux
kernel. If you need a high level recipe selection tool, your best bet
is probably to look at Toaster.

>
> On Thursday, 17 May, 2018, 9:32:15 AM IST, chandrasekhar
>  wrote:
>
>
>
>
>
> Hi
>
> You can use
>
> IMAGE_INSTALL += "Package Name/Recipes name"
>
>
>
> Regards,
>
> Chandrasekhar
>
>
>
> From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
> On Behalf Of Ugesh Reddy
> Sent: Wednesday, May 16, 2018 9:57 PM
> To: Yocto-mailing-list
> Subject: [yocto] Enabling the recipe from menuconfig
>
>
>
> Hello Team,
>
>
>
>  I have a list of recipes in my custom layer. The recipes in this layer
> shall be enabled/selected through the menuconfig, once it is enabled then it
> shall be the part of image. is it possible to achieve it ? do we have any
> references?
>
>
>
> Regards,
>
> Ugesh
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Recipe availability through eSDK (cppzmq)

[Andrea Galbusera]

On Wed, May 2, 2018 at 2:33 PM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi Andrea,
>
> You are right, the recipe works-as-is, when adding 'cppzmq-dev' to the image 
> rather than just 'cppzmq' - I was not aware of this. From an eSDK perspective 
> it seems to work when the package is installed according to
>
> devtool sdk-install -s cppzmq
>
> and then adding 'IMAGE_INSTALL += "cppzmq-dev"' to local.conf.
>
> On the variables passed in from the shell, can you refer to the location of 
> this whitelist - for future reference?

https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_WHITELIST

>
> Thanks for your support - highly appreciated.
> Martin
>
>
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Wednesday, May 2, 2018 10:33
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
>
> On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt <m...@gomspace.com> wrote:
>> Hi,
>>
>>
>> Hacking the recipe according to:
>>
>>
>> martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
>> diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> index a64745c94..aba1d6edb 100644
>> --- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> +++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
>> @@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
>>
>>  do_install () {
>>  install -d ${D}/usr/include
>> +install -d ${D}/etc
>>  install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
>> +install -m 0755 ${S}/zmq.hpp ${D}/etc
>>  }
>>
>> -PACKAGES = "${PN}-dev"
>> +PACKAGES = "${PN}-dev ${PN}"
>
> If you go down the patch-the-recipe way, you can probably leave
> PACKAGES at its default: both ${PN} and ${PN}-dev are there by
> default.
>
>> RDEPENDS_${PN}-dev = "zeromq-dev"
>>
>> triggers both ${PN}-dev and ${PN} variants to be packaged and included by
>> the image. Leaving out the installation into /etc causes ${PN} package not
>> to be generated and the image generation does not pick up the ${PN}-dev
>> variant.
>
> Better would be adding:
>
> ALLOW_EMPTY_${PN} = "1"
>
> This way it's cleaner and should work as well. However, you'll need to
> force your image to depend upon an empty package to be added
> (meaningless for the target), for the sake of the corresponding -dev
> package to be part of the tailored eSDK... Maybe there's a better way
> to achieve this, possibly by adding cppzmq-dev to the SDK explicitly
> with something like TOOLCHAIN_TARGET_TASK_append (never used it in
> practice though). Hopefully someone can further comment on this to add
> some wisdom.
>
>> In essence, it looks like image generation disregards recipes residing
>> exclusively in the ${PN}-dev variant - question is whether this is intended
>> or not?
>
> Yes it is. -dev packages are not intended to be installed into target
> image by design.
>
>>
>>
>> Br,
>>
>> Martin
>>
>>
>> 
>> From: Martin Siegumfeldt
>> Sent: Tuesday, May 1, 2018 8:49:17 PM
>> To: Andrea Galbusera
>>
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>>
>>
>> Hi Andrea,
>>
>>
>>
>> 
>> From: Andrea Galbusera <giz...@gmail.com>
>> Sent: Tuesday, May 1, 2018 16:06
>> To: Martin Siegumfeldt
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>>
>> Hi Martin,
>>
>> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
>> wrote:
>>> Hi,
>>>
>>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>>> search function does not return anything, despite the recipe being available
>>> through local recipe:
>>>
>>> martin@dell:~/gomspace_sdk$ ls
>>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>>> cppzmq_git.bb  files  zeromq_4.1.6.bb
>>>
>>> I assume this is expected since it does not come prebuilt as part of the
>>> eSDK - is this correct understood?
>>>
>>> Fortunately, 'devtool modify/build/package'

Re: [yocto] Recipe availability through eSDK (cppzmq)

[Andrea Galbusera]

On Wed, May 2, 2018 at 9:52 AM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi,
>
>
> Hacking the recipe according to:
>
>
> martin@dell:~/work/z7000-distro-zcu102/meta-openembedded$ git diff
> diff --git a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> index a64745c94..aba1d6edb 100644
> --- a/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> +++ b/meta-oe/recipes-connectivity/zeromq/cppzmq_git.bb
> @@ -13,9 +13,11 @@ S = "${WORKDIR}/git"
>
>  do_install () {
>  install -d ${D}/usr/include
> +install -d ${D}/etc
>  install -m 0755 ${S}/zmq.hpp ${D}/usr/include/
> +install -m 0755 ${S}/zmq.hpp ${D}/etc
>  }
>
> -PACKAGES = "${PN}-dev"
> +PACKAGES = "${PN}-dev ${PN}"

If you go down the patch-the-recipe way, you can probably leave
PACKAGES at its default: both ${PN} and ${PN}-dev are there by
default.

> RDEPENDS_${PN}-dev = "zeromq-dev"
>
> triggers both ${PN}-dev and ${PN} variants to be packaged and included by
> the image. Leaving out the installation into /etc causes ${PN} package not
> to be generated and the image generation does not pick up the ${PN}-dev
> variant.

Better would be adding:

ALLOW_EMPTY_${PN} = "1"

This way it's cleaner and should work as well. However, you'll need to
force your image to depend upon an empty package to be added
(meaningless for the target), for the sake of the corresponding -dev
package to be part of the tailored eSDK... Maybe there's a better way
to achieve this, possibly by adding cppzmq-dev to the SDK explicitly
with something like TOOLCHAIN_TARGET_TASK_append (never used it in
practice though). Hopefully someone can further comment on this to add
some wisdom.

> In essence, it looks like image generation disregards recipes residing
> exclusively in the ${PN}-dev variant - question is whether this is intended
> or not?

Yes it is. -dev packages are not intended to be installed into target
image by design.

>
>
> Br,
>
> Martin
>
>
> 
> From: Martin Siegumfeldt
> Sent: Tuesday, May 1, 2018 8:49:17 PM
> To: Andrea Galbusera
>
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
>
> Hi Andrea,
>
>
>
> 
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Tuesday, May 1, 2018 16:06
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
> Hi Martin,
>
> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
> wrote:
>> Hi,
>>
>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>> search function does not return anything, despite the recipe being available
>> through local recipe:
>>
>> martin@dell:~/gomspace_sdk$ ls
>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>> cppzmq_git.bb  files  zeromq_4.1.6.bb
>>
>> I assume this is expected since it does not come prebuilt as part of the
>> eSDK - is this correct understood?
>>
>> Fortunately, 'devtool modify/build/package' generates the package -
>> unfortunately it is not included in the subsequent image generation:
>>
>> martin@dell:~/gomspace_sdk$ devtool package cppzmq
>> NOTE: Starting bitbake server...
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:03
>> Loaded 2773 entries from dependency cache.
>> Parsing recipes: 100%
>> |##|
>> Time: 0:00:01
>> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets,
>> 305 skipped, 11 masked, 0 errors.
>> NOTE: Resolving any missing task queue dependencies
>> Initialising tasks: 100%
>> |###|
>> Time: 0:00:00
>> Checking sstate mirror object availability: 100%
>> |###

Re: [yocto] Recipe availability through eSDK (cppzmq)

[Andrea Galbusera]

Martin,

On Tue, May 1, 2018 at 8:49 PM, Martin Siegumfeldt <m...@gomspace.com> wrote:
> Hi Andrea,
>
>
>
> ____
> From: Andrea Galbusera <giz...@gmail.com>
> Sent: Tuesday, May 1, 2018 16:06
> To: Martin Siegumfeldt
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Recipe availability through eSDK (cppzmq)
>
> Hi Martin,
>
> On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt <m...@gomspace.com>
> wrote:
>> Hi,
>>
>> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The
>> search function does not return anything, despite the recipe being available
>> through local recipe:
>>
>> martin@dell:~/gomspace_sdk$ ls
>> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
>> cppzmq_git.bb  files  zeromq_4.1.6.bb
>>
>> I assume this is expected since it does not come prebuilt as part of the
>> eSDK - is this correct understood?
>>
>> Fortunately, 'devtool modify/build/package' generates the package -
>> unfortunately it is not included in the subsequent image generation:
>>
>> martin@dell:~/gomspace_sdk$ devtool package cppzmq
>> NOTE: Starting bitbake server...
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:03
>> Loaded 2773 entries from dependency cache.
>> Parsing recipes: 100%
>> |##|
>> Time: 0:00:01
>> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets,
>> 305 skipped, 11 masked, 0 errors.
>> NOTE: Resolving any missing task queue dependencies
>> Initialising tasks: 100%
>> |###|
>> Time: 0:00:00
>> Checking sstate mirror object availability: 100%
>> |###|
>> Time: 0:00:00
>> NOTE: Executing SetScene Tasks
>> NOTE: Executing RunQueue Tasks
>> NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be
>> rerun and all succeeded.
>>
>> Summary: There was 1 WARNING message shown.
>> NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk
>>
>> martin@dell:~/gomspace_sdk$ devtool build-image
>> NOTE: Starting bitbake server...
>> WARNING: Host distribution "ubuntu-17.10" has not been validated with this
>> version of the build system; you may possibly experience unexpected
>> failures. It is recommended that you use a tested distribution.
>> Loading cache: 100%
>> ||
>> Time: 0:00:00
>> Loaded 2773 entries from dependency cache.
>> Parsing recipes: 100%
>> |##|
>> Time: 0:00:02
>> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets,
>> 305 skipped, 11 masked, 0 errors.
>>
>> Summary: There was 1 WARNING message shown.
>> WARNING: Skipping recipe cppzmq as it doesn't produce a package with the
>> same name
>
> This is the suspicious bit... If you look at the recipe, you'll notice
> it's re-defining the PACKAGES variable. Then, it's not generating a
> package called 'cppzmq', but only one named 'cppzmq-dev'. That said,
> I'm not sure why you'd want to add a package which only provides
> development headers to your target image...
>
> I understand your doubt here. The header file installed is a wrapper around
> zeromq and thus DEPENDS/RDEPENDS on this library. zeromq is included in the
> image, for which the SDK is generated, hence I would expect this to be a
> valid use case?
>
> Anyhow, I realized that the recipe does not even work in a BB environment -
> the following is encountered for an image includin

Re: [yocto] Recipe availability through eSDK (cppzmq)

[Andrea Galbusera]

Hi Martin,

On Mon, Apr 30, 2018 at 9:10 PM, Martin Siegumfeldt  wrote:
> Hi,
>
> I am trying to build cppzmq through a Yocto (Rocko) generated eSDK. The 
> search function does not return anything, despite the recipe being available 
> through local recipe:
>
> martin@dell:~/gomspace_sdk$ ls 
> layers/meta-openembedded/meta-oe/recipes-connectivity/zeromq/
> cppzmq_git.bb  files  zeromq_4.1.6.bb
>
> I assume this is expected since it does not come prebuilt as part of the eSDK 
> - is this correct understood?
>
> Fortunately, 'devtool modify/build/package' generates the package - 
> unfortunately it is not included in the subsequent image generation:
>
> martin@dell:~/gomspace_sdk$ devtool package cppzmq
> NOTE: Starting bitbake server...
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:03
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:01
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> Initialising tasks: 100% 
> |###|
>  Time: 0:00:00
> Checking sstate mirror object availability: 100% 
> |###|
>  Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 492 tasks of which 491 didn't need to be rerun 
> and all succeeded.
>
> Summary: There was 1 WARNING message shown.
> NOTE: Your packages are in /home/martin/gomspace_sdk/tmp/deploy/ipk
>
> martin@dell:~/gomspace_sdk$ devtool build-image
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:00
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:02
> Parsing of 1968 .bb files complete (1960 cached, 8 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
>
> Summary: There was 1 WARNING message shown.
> WARNING: Skipping recipe cppzmq as it doesn't produce a package with the same 
> name

This is the suspicious bit... If you look at the recipe, you'll notice
it's re-defining the PACKAGES variable. Then, it's not generating a
package called 'cppzmq', but only one named 'cppzmq-dev'. That said,
I'm not sure why you'd want to add a package which only provides
development headers to your target image...

>
> Inspecting the manifest file confirms that the package is not installed - any 
> idea why not? I also tried installing though sdk-install:
>
> martin@dell:~/gomspace_sdk$ devtool sdk-install -s cppzmq
> NOTE: Starting bitbake server...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is recommended that you use a tested distribution.
> Loading cache: 100% 
> ||
>  Time: 0:00:00
> Loaded 2773 entries from dependency cache.
> Parsing recipes: 100% 
> |##|
>  Time: 0:00:02
> Parsing of 1968 .bb files complete (1961 cached, 7 parsed). 2780 targets, 305 
> skipped, 11 masked, 0 errors.
>
> Summary: There was 1 WARNING message shown.
> NOTE: Installing cppzmq...
> WARNING: Host distribution "ubuntu-17.10" has not been validated with this 
> version of the build system; you may possibly experience unexpected failures. 
> It is 

Re: [yocto] Installing a package on the board at runtime

[Andrea Galbusera]

On Fri, Apr 27, 2018 at 5:39 PM, Alan Martinovic
<alan.martino...@senic.com> wrote:
> Hey
>
>> A more
> controlled way of installing packages would be to have
> package-management added to your IMAGE_FEATURES [1] to leverage a
> fully fledged package manager on the target (like any mainstream
> distro).
>
> Yeah, I admit I have been ignorantly avoiding this, always thinking that
> it isn't worth the overhead of setting the server and the additional
> aps on the board.
> Will check it out.
>
>> This shouldn't be the case. When using 'devtool modify'
> workspace/sources/ gets populated with a git repository
> which includes a 'devtool' branch which includes any patch the recipe
> declare in its SRC_URI.
>
> Cool share about the devtool branch, tnx.
>
>> Those patches are already applied to the
> fetched sources in the form of git commits on the 'devtool' branch
> [3].
>
> I guess it isn't a patch that is directly applied to the source but a
> config file that gets modified.
>
> 
> SRC_URI += "file://bluetooth.conf"
>
> python do_render_templates() {
>   render_template('bluetooth.conf')
> }

Can't see the render_template() implementation here, but my guess is
that, unless you are prepending any extra path to 'bluetooth.conf' you
are relying on the current working directory for the task, which
should be S.
While outside the devtool context S defaults to ${WORKDIR} (again,
unless you are setting it elsewhere), likely allowing
render_template() to find the file, when using devtool, S gets a
different value which comes from the externalsrc class and points to
the workspace.

My suggestion is trying to rework your render logic in a way that it
looks for source template in ${WORKDIR} and deploys the rendered
configuration file in ${D}, even better without overwriting the
template itself in ${WORKDIR}. You can find a similar pattern,
implemented as a shell snippet instead of a python function, i.e. in
meta/recipes-support/nspr/nspr_4.13.1.bb or
meta/recipes-support/nss/nss_3.28.1.bb from the poky repo, which do
both render their pkg-config templates that way and work seamlessly
either inside or outside devtool.

> addtask render_templates after do_compile before do_install
>
> do_install_append() {
> install -m 644 ${WORKDIR}/bluetooth.conf
> ${D}${sysconfdir}/dbus-1/system.d/bluetooth.conf
> install -d ${D}${systemd_unitdir}/system
> install -m 0644 ${WORKDIR}/bluetooth.service
> ${D}${systemd_unitdir}/system
> }
> do_render_templates[nostamp] = "1"
>
>
> The render_template changes some entries in bluetooth.conf.
> I guess when it's run from devshell it gets confused as where to look
> for it.
> Works ok with bitbake.
>
> Be Well :)
> Alan
>
>
> On Fri, Apr 27, 2018 at 4:47 PM, Andrea Galbusera <giz...@gmail.com> wrote:
>> Hi Alan,
>>
>> On Fri, Apr 27, 2018 at 1:38 PM, Alan Martinovic
>> <alan.martino...@senic.com> wrote:
>>> Hey,
>>> I know there is a method in devtool called devtool deploy-target.
>>> It's a great thing to install a package on the board at runtime.
>>>
>>> Is there something like that available without devtool?
>>
>> The devtool deploy-target way of deploying recipes' artefacts is
>> mostly oriented to easing development loops with the eSDK. A more
>> controlled way of installing packages would be to have
>> package-management added to your IMAGE_FEATURES [1] to leverage a
>> fully fledged package manager on the target (like any mainstream
>> distro). You can choose among different format by setting the
>> PACKAGE_CLASSES configuration variable. Using a package manager on the
>> target won't differ from how you install/upgrade your desktop
>> distribution. The only extra step you'll need to accomplish is setting
>> up a proper package feed to let your targets grab the packages from
>> your build/deploy/ dir. See the manual at [2] for more
>> details.
>>
>> Also, devtool works at a recipe scope, not at package level. You can
>> imagine it as a sort of 'make install' that leverages ssh to work
>> update the target filesystem. Recipes can provide more than one
>> package, then only a proper package manager will let you select any of
>> the packages a recipe provides for installation/upgrade.
>>
>>> A digression:
>>> Am asking for a non devtool option because it
>>> seems like devtool is ignoring the patch and config files
>>> the recipe depends on (can't find any in workspace/sources).
>>
>> This shouldn't be the case. When using 'devtool modify'
>> workspace/sources/ gets populated

Re: [yocto] Installing a package on the board at runtime

[Andrea Galbusera]

Hi Alan,

On Fri, Apr 27, 2018 at 1:38 PM, Alan Martinovic
 wrote:
> Hey,
> I know there is a method in devtool called devtool deploy-target.
> It's a great thing to install a package on the board at runtime.
>
> Is there something like that available without devtool?

The devtool deploy-target way of deploying recipes' artefacts is
mostly oriented to easing development loops with the eSDK. A more
controlled way of installing packages would be to have
package-management added to your IMAGE_FEATURES [1] to leverage a
fully fledged package manager on the target (like any mainstream
distro). You can choose among different format by setting the
PACKAGE_CLASSES configuration variable. Using a package manager on the
target won't differ from how you install/upgrade your desktop
distribution. The only extra step you'll need to accomplish is setting
up a proper package feed to let your targets grab the packages from
your build/deploy/ dir. See the manual at [2] for more
details.

Also, devtool works at a recipe scope, not at package level. You can
imagine it as a sort of 'make install' that leverages ssh to work
update the target filesystem. Recipes can provide more than one
package, then only a proper package manager will let you select any of
the packages a recipe provides for installation/upgrade.

> A digression:
> Am asking for a non devtool option because it
> seems like devtool is ignoring the patch and config files
> the recipe depends on (can't find any in workspace/sources).

This shouldn't be the case. When using 'devtool modify'
workspace/sources/ gets populated with a git repository
which includes a 'devtool' branch which includes any patch the recipe
declare in its SRC_URI. Those patches are already applied to the
fetched sources in the form of git commits on the 'devtool' branch
[3].

> My particular recipe has a custom build step that
> depends on rendering config file templates (which fails due to missing
> not finding the config file).

This might be due to errors in setting up the extra task: difficult to
say without looking at how the custom step is defined. Maybe you can
share your recipe together with the error logs bitbake is reporting.

[1] 
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-features-image
[2] 
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#runtime-package-management-server
[3] 
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#devtool-modifying-a-recipe
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Extensible SDK and DEFAULT_PREFERENCE

[Andrea Galbusera]

On Wed, Apr 18, 2018 at 2:41 PM, Martin Siegumfeldt  wrote:
> Hi,
>
> I am having a number of recipes residing in two versions, some (development 
> versions) being down-prioritized using:
>
> DEFAULT_PREFERENCE = "-1"
>
>
> The source code is hosted at a private git repository, and the git version is 
> selected using 'AUTOREV'. The extensible SDK renders successfully, however 
> the installation (by third party) fails:
>
> Traceback (most recent call last):
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 412, in DataSmart.expandWithRefs(s='dev+git${SRCPV}', varname='PV'):
>  try:
> >s = __expand_var_regexp__.sub(varparse.var_sub, s)
>  try:
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 111, in VariableParse.var_sub(match=<_sre.SRE_Match object; span=(7, 
> 15), match='${SRCPV}'>):
>  else:
> >var = self.d.getVarFlag(key, "_content")
>  self.references.add(key)
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 794, in DataSmart.getVarFlag(var='SRCPV', flag='_content', expand=True, 
> noweakdefault=False, parsing=False):
>  cachename = var + "[" + flag + "]"
> >value = self.expand(value, cachename)
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 436, in DataSmart.expand(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  def expand(self, s, varname = None):
> >return self.expandWithRefs(s, varname).value
>
>   File "/home/martin/gomspace_sdk/layers/poky/bitbake/lib/bb/data_smart.py", 
> line 426, in DataSmart.expandWithRefs(s='${@bb.fetch2.get_srcrev(d)}', 
> varname='SRCPV'):
>  except Exception as exc:
> >raise ExpansionError(varname, s, exc) from exc
>
> bb.data_smart.ExpansionError: Failure expanding variable SRCPV, expression 
> was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher 
> failure: Fetch command export GIT_SSL_CAINFO="/home
> /martin/gomspace_sdk/buildtools/sysroots/x86_64-gomspacesdk-linux/etc/ssl/certs/ca-certificates.crt";
>  export 
> PATH="/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0
> /recipe-sysroot-native/usr/bin/python-native:/home/martin/gomspace_sdk/layers/poky/scripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/u
> sr/bin/aarch64-gomspace-linux:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot/usr/bin/crossscripts:/home/martin/gomspace_sdk/tmp/work/aarch64-gomsp
> ace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/usr/bin:/home/marti
> n/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-sysroot-native/sbin:/home/martin/gomspace_sdk/tmp/work/aarch64-gomspace-linux/libgsisl/fetcheravoidrecurse-r0/recipe-s
> ysroot-native/bin:/home/martin/gomspace_sdk/layers/poky/bitbake/bin:/home/martin/gomspace_sdk/tmp/hosttools";
>  export HOME="/home/martin"; git -c core.fsyncobjectfiles=0 ls-remote 
> ssh://g...@github.com/GomS
> pace/libisl  failed with exit code 128, output:
> Host key verification failed.
> fatal: Could not read from remote repository.
>
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> It is not the intention that third party will ever need access to the 
> development version, and I don't see why the version information is fetched 
> given the reduced priority. Have I encountered an 'undocumented bug' or is 
> there an alternate approach to achieve this?

eSDK and recipes doing AUTOREV are known to not play well (yet). There
is a bug open to address it at
https://bugzilla.yoctoproject.org/show_bug.cgi?id=11350

>
> Thanks,
> Martin
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] selectively enabling/disabling multiple systemd services in recipes

[Andrea Galbusera]

Hi!
I know a recipe can list more than one service in SYSTEMD_SERVICE
variable. Then, is there a way to selectively enable/disable each of
them? To me, it looks like SYSTEMD_AUTO_ENABLE acts globally on every
service in the above list.

I have a recipe which provides a single executable (/usr/bin/foo), a
template service file (foo@.service) and two service instances which
runs the executable with different configuration arguments
(foo@bar.service and foo@baz.service).

I'm considering splitting into separate packages then allowing
configuration to optionally override SYSTEMD_AUTO_ENABLE package-wise.
Is that the preferred way to achieve this goal?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] use of variables in wic files

[Andrea Galbusera]

Hi,

Is there any way to reference bitbake variable within the wic file
syntax? Got to this question after a wic file of mine recently broke
due to a u-boot artifact changing its name after an upstream update of
the u-boot recipe. The wic had the artifact's name hardcoded as a
parameter to the rawcopy plugin. Could I have been referencing the
u-boot artifact via UBOOT_BINARY variable instead?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] crops/poky workflow and git

[Andrea Galbusera]

Hi!

Anyone here regularly doing yocto builds from crops/poky [1] containers?
If I got it right, the idea behind using containers derived from
crops/poky image for builds is to keep the entire development workflow
outside the container and use the container for build related commands
only (ideally setting up the env and running bitbake).

Then, a very annoying issue I face in trying to enforce this idea as
my regular workflow is that interacting with git repositories created
while the build runs is becoming almost impossible from outside the
container, where regular git work is expected to be more conveniently
done.

The point is that repos get created when bitbake fetches sources from
within the container and git itself hardcodes absolute paths in some
of its control files. What I see is while running git from within the
repo but outside the contained scope, is git itself complaining with
messages like this:

error: object directory /workdir/blah/blah/blah does not exist; check
.git/objects/info/alternates. fatal: bad object HEAD docker

I'm using crops/poky as suggested in [1] hence bind mounting a volume
with the entire project rootdir under /workdir within the container.

Any suggestion how to make this more friendly, other than moving the
entire git workflow inside the same or another container that bind
mounts the volume at the same location? I'm curious to know if/how
people try to leverage the isolation of containers and how they do
mitigate sharp edges I found in migrating builds to them.

[1] https://github.com/crops/poky-container
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] recipes: use oe.utils.conditional instead of deprecated base_conditional

[Andrea Galbusera]

On Wed, Jan 31, 2018 at 8:19 AM, Andrea Galbusera <giz...@gmail.com> wrote:
> On Wed, Jan 31, 2018 at 8:05 AM, Andrea Galbusera <giz...@gmail.com> wrote:
>> Hi Martin,
>>
>> On Tue, Jan 30, 2018 at 2:31 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
>>> Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
>>> ---
>>>  recipes-kernel/linux/linux-raspberrypi.inc | 6 +++---
>>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>>> b/recipes-kernel/linux/linux-raspberrypi.inc
>>> index df3a3d7..a1c4e52 100644
>>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>>> @@ -22,10 +22,10 @@ KBUILD_DEFCONFIG_raspberrypi3-64 ?= "bcmrpi3_defconfig"
>>>  CMDLINE ?= "dwc_otg.lpm_enable=0 console=serial0,115200 
>>> root=/dev/mmcblk0p2 rootfstype=ext4 rootwait"
>>>
>>>  # Add the kernel debugger over console kernel command line option if 
>>> enabled
>>> -CMDLINE_append = ' ${@base_conditional("ENABLE_KGDB", "1", 
>>> "kgdboc=serial0,115200", "", d)}'
>>> +CMDLINE_append = ' ${@oe.utils.conditional("ENABLE_KGDB", "1", 
>>> "kgdboc=serial0,115200", "", d)}'
>>>
>>>  # Disable rpi logo on boot
>>> -CMDLINE_append += ' ${@base_conditional("DISABLE_RPI_BOOT_LOGO", "1", 
>>> "logo.nologo", "", d)}'
>>> +CMDLINE_append += ' ${@oe.utils.conditional("DISABLE_RPI_BOOT_LOGO", "1", 
>>> "logo.nologo", "", d)}'
>>>
>>>  # You can define CMDLINE_DEBUG as "debug" in your local.conf or distro.conf
>>>  # to enable kernel debugging.
>>> @@ -124,7 +124,7 @@ do_configure_prepend() {
>>>  kernel_configure_variable ROOT_NFS y
>>>  kernel_configure_variable CMDLINE "\"${CMDLINE_NFSROOT_USB}\""
>>>  fi
>>> -if [ "${@base_conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 
>>> 'False', d)}" ]; then
>>> +if [ "${@oe.utils.conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 
>>> 'False', d)}" ]; then
>>>  kernel_configure_variable BLK_DEV_INITRD y
>>>  kernel_configure_variable INITRAMFS_SOURCE ""
>>>  kernel_configure_variable RD_GZIP y
>>> --
>>> 2.15.1
>>>
>>> --
>>> ___
>>> yocto mailing list
>>> yocto@yoctoproject.org
>>> https://lists.yoctoproject.org/listinfo/yocto
>>
>> Although it's trivial, this one doesn't look to apply neither to
>> current master nor to any object in the index of meta-raspberrypi
>> repo...
>>
>> $ git show df3a3d7
>> fatal: ambiguous argument 'df3a3d7': unknown revision or path not in
>> the working tree.
>
> Also consider that, according to [1] patches should be submitted as
> pull request on github, being the mailing list only a
>
> [1] 
> https://github.com/agherzan/meta-raspberrypi/blob/master/docs/contributing.md#patches-and-pull-requests

Sorry! Hit "send" too early on my previous one... Well you know what I
meant: "...being the mailing list only an additional place for
discussion".
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] recipes: use oe.utils.conditional instead of deprecated base_conditional

[Andrea Galbusera]

On Wed, Jan 31, 2018 at 8:05 AM, Andrea Galbusera <giz...@gmail.com> wrote:
> Hi Martin,
>
> On Tue, Jan 30, 2018 at 2:31 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
>> Signed-off-by: Martin Jansa <martin.ja...@gmail.com>
>> ---
>>  recipes-kernel/linux/linux-raspberrypi.inc | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
>> b/recipes-kernel/linux/linux-raspberrypi.inc
>> index df3a3d7..a1c4e52 100644
>> --- a/recipes-kernel/linux/linux-raspberrypi.inc
>> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
>> @@ -22,10 +22,10 @@ KBUILD_DEFCONFIG_raspberrypi3-64 ?= "bcmrpi3_defconfig"
>>  CMDLINE ?= "dwc_otg.lpm_enable=0 console=serial0,115200 root=/dev/mmcblk0p2 
>> rootfstype=ext4 rootwait"
>>
>>  # Add the kernel debugger over console kernel command line option if enabled
>> -CMDLINE_append = ' ${@base_conditional("ENABLE_KGDB", "1", 
>> "kgdboc=serial0,115200", "", d)}'
>> +CMDLINE_append = ' ${@oe.utils.conditional("ENABLE_KGDB", "1", 
>> "kgdboc=serial0,115200", "", d)}'
>>
>>  # Disable rpi logo on boot
>> -CMDLINE_append += ' ${@base_conditional("DISABLE_RPI_BOOT_LOGO", "1", 
>> "logo.nologo", "", d)}'
>> +CMDLINE_append += ' ${@oe.utils.conditional("DISABLE_RPI_BOOT_LOGO", "1", 
>> "logo.nologo", "", d)}'
>>
>>  # You can define CMDLINE_DEBUG as "debug" in your local.conf or distro.conf
>>  # to enable kernel debugging.
>> @@ -124,7 +124,7 @@ do_configure_prepend() {
>>  kernel_configure_variable ROOT_NFS y
>>  kernel_configure_variable CMDLINE "\"${CMDLINE_NFSROOT_USB}\""
>>  fi
>> -if [ "${@base_conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 
>> 'False', d)}" ]; then
>> +if [ "${@oe.utils.conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 
>> 'False', d)}" ]; then
>>  kernel_configure_variable BLK_DEV_INITRD y
>>  kernel_configure_variable INITRAMFS_SOURCE ""
>>  kernel_configure_variable RD_GZIP y
>> --
>> 2.15.1
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> Although it's trivial, this one doesn't look to apply neither to
> current master nor to any object in the index of meta-raspberrypi
> repo...
>
> $ git show df3a3d7
> fatal: ambiguous argument 'df3a3d7': unknown revision or path not in
> the working tree.

Also consider that, according to [1] patches should be submitted as
pull request on github, being the mailing list only a

[1] 
https://github.com/agherzan/meta-raspberrypi/blob/master/docs/contributing.md#patches-and-pull-requests
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi][PATCH] recipes: use oe.utils.conditional instead of deprecated base_conditional

[Andrea Galbusera]

Hi Martin,

On Tue, Jan 30, 2018 at 2:31 PM, Martin Jansa  wrote:
> Signed-off-by: Martin Jansa 
> ---
>  recipes-kernel/linux/linux-raspberrypi.inc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-kernel/linux/linux-raspberrypi.inc 
> b/recipes-kernel/linux/linux-raspberrypi.inc
> index df3a3d7..a1c4e52 100644
> --- a/recipes-kernel/linux/linux-raspberrypi.inc
> +++ b/recipes-kernel/linux/linux-raspberrypi.inc
> @@ -22,10 +22,10 @@ KBUILD_DEFCONFIG_raspberrypi3-64 ?= "bcmrpi3_defconfig"
>  CMDLINE ?= "dwc_otg.lpm_enable=0 console=serial0,115200 root=/dev/mmcblk0p2 
> rootfstype=ext4 rootwait"
>
>  # Add the kernel debugger over console kernel command line option if enabled
> -CMDLINE_append = ' ${@base_conditional("ENABLE_KGDB", "1", 
> "kgdboc=serial0,115200", "", d)}'
> +CMDLINE_append = ' ${@oe.utils.conditional("ENABLE_KGDB", "1", 
> "kgdboc=serial0,115200", "", d)}'
>
>  # Disable rpi logo on boot
> -CMDLINE_append += ' ${@base_conditional("DISABLE_RPI_BOOT_LOGO", "1", 
> "logo.nologo", "", d)}'
> +CMDLINE_append += ' ${@oe.utils.conditional("DISABLE_RPI_BOOT_LOGO", "1", 
> "logo.nologo", "", d)}'
>
>  # You can define CMDLINE_DEBUG as "debug" in your local.conf or distro.conf
>  # to enable kernel debugging.
> @@ -124,7 +124,7 @@ do_configure_prepend() {
>  kernel_configure_variable ROOT_NFS y
>  kernel_configure_variable CMDLINE "\"${CMDLINE_NFSROOT_USB}\""
>  fi
> -if [ "${@base_conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 
> 'False', d)}" ]; then
> +if [ "${@oe.utils.conditional('INITRAMFS_IMAGE_BUNDLE', '1', 'True', 
> 'False', d)}" ]; then
>  kernel_configure_variable BLK_DEV_INITRD y
>  kernel_configure_variable INITRAMFS_SOURCE ""
>  kernel_configure_variable RD_GZIP y
> --
> 2.15.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

Although it's trivial, this one doesn't look to apply neither to
current master nor to any object in the index of meta-raspberrypi
repo...

$ git show df3a3d7
fatal: ambiguous argument 'df3a3d7': unknown revision or path not in
the working tree.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Andrea Galbusera]

Hi Anuj,

On Sun, Jan 21, 2018 at 4:23 PM, Anuj Mittal <anuj.mit...@intel.com> wrote:
> On 01/21/2018 01:07 AM, Andrea Galbusera wrote:
>> On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal <anuj.mit...@intel.com> wrote:
>>> On 01/19/2018 08:32 PM, Alexander Kanavin wrote:
>>>>
>>>>> I'll try to recap a little bit but, please, forgive my ignorance in
>>>>> graphics stacks and libraries.
>>>>> Disclaimer: mostly working on headless systems... my bad!
>>>>> This is what I think I understand here (remember I test building poky
>>>>> + meta-raspberrypi):
>>>>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>>>>> on virtual/X11 when this is available in DISTRO_FEATURE
>>>>> * the latter is the case for poky which is the DISTRO I'm building
>>>>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>>>>> * upstream meson.build conditionally builds tests if X11 is
>>>>> available... so we expect they should build fine in this case
>>>>> * compile fails on test/egl_common.c which does not explicitly include
>>>>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>>>>> not seem to be the right thing to do.
>>>>>
>>>>> Is this correct to assume that the upstream tested usecases are
>>>>> probably getting the include otherwise, maybe conditionally as Alex
>>>>> initially suggested. If so, where should we look for the missing
>>>>> pieces?
>>>>
>>>> I'm similarly ignorant about this stuff (our resident graphics stack
>>>> expert Jussi Kukkonen left a few months ago), but let's consider the
>>>> build files:
>>>>
>>>> - the offending tests are wrapped in "if build_egl and build_x11_tests"
>>>>
>>>> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
>>>> available
>>>>
>>>> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is
>>>> similarly controlled by a PACKAGECONFIG, and enabled if x11 is in
>>>> DISTRO_FEATURES:
>>>>
>>>> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
>>>> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>>>>
>>>> This is where I think the configuration is not quite right. Instead of
>>>> virtual/libx11, it should say virtual/libgl. And if that dependency
>>>> cannot be satisfied, then the x11 option should be altogether disabled
>>>> in the distro/local config (in poky mesa provides virtual/libgl). At
>>>> least that's how it's configured in many other recipes throughout oe-core.
>>>>
>>>> Can you try:
>>>> a) disabling x11 PACKAGECONFIG in your local config and see if things 
>>>> build?
>>>> b) changing the dependency in that option to virtual/libgl and see what
>>>> kind of error you get, if any. I guess this is the right fix after all.
>>>
>>> Yes, glx in libepoxy should be disabled if it is not in DISTRO_FEATURES.
>>> glx depends on gl and x11 so if it is to be enabled, both of them should
>>> be present.
>>>
>>> However, x11 without glx and just egl should still be valid configuration.
>>>
>>> I think the correct configuration should be:
>>>
>>>
>>> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> index 72167a2..0043bec 100644
>>> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
>>> @@ -15,12 +15,14 @@ UPSTREAM_CHECK_URI =
>>> "https://github.com/anholt/libepoxy/releases;
>>>
>>>  inherit meson pkgconfig distro_features_check
>>>
>>> -REQUIRED_DISTRO_FEATURES = "opengl"
>>> -
>>>  DEPENDS = "util-macros"
>>>
>>> +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
>>> 'glx', 'x11', '', d)}"
>>> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'glx x11', d)} \
>>
>> Did you mean 'opengl x11' or is glx a valid distro feature? I don't
>> see it mentioned anywhere else...
>
> Oh yes, you're right. I was trying something out & didn't clean before
> sending. It should be:
>
> bb.utils.contains('DISTRO

Re: [yocto] Error do_compile libepoxy

[Andrea Galbusera]

On Sat, Jan 20, 2018 at 10:29 AM, Anuj Mittal  wrote:
> On 01/19/2018 08:32 PM, Alexander Kanavin wrote:
>>
>>> I'll try to recap a little bit but, please, forgive my ignorance in
>>> graphics stacks and libraries.
>>> Disclaimer: mostly working on headless systems... my bad!
>>> This is what I think I understand here (remember I test building poky
>>> + meta-raspberrypi):
>>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>>> on virtual/X11 when this is available in DISTRO_FEATURE
>>> * the latter is the case for poky which is the DISTRO I'm building
>>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>>> * upstream meson.build conditionally builds tests if X11 is
>>> available... so we expect they should build fine in this case
>>> * compile fails on test/egl_common.c which does not explicitly include
>>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>>> not seem to be the right thing to do.
>>>
>>> Is this correct to assume that the upstream tested usecases are
>>> probably getting the include otherwise, maybe conditionally as Alex
>>> initially suggested. If so, where should we look for the missing
>>> pieces?
>>
>> I'm similarly ignorant about this stuff (our resident graphics stack
>> expert Jussi Kukkonen left a few months ago), but let's consider the
>> build files:
>>
>> - the offending tests are wrapped in "if build_egl and build_x11_tests"
>>
>> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
>> available
>>
>> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is
>> similarly controlled by a PACKAGECONFIG, and enabled if x11 is in
>> DISTRO_FEATURES:
>>
>> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
>> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>>
>> This is where I think the configuration is not quite right. Instead of
>> virtual/libx11, it should say virtual/libgl. And if that dependency
>> cannot be satisfied, then the x11 option should be altogether disabled
>> in the distro/local config (in poky mesa provides virtual/libgl). At
>> least that's how it's configured in many other recipes throughout oe-core.
>>
>> Can you try:
>> a) disabling x11 PACKAGECONFIG in your local config and see if things build?
>> b) changing the dependency in that option to virtual/libgl and see what
>> kind of error you get, if any. I guess this is the right fix after all.
>
> Yes, glx in libepoxy should be disabled if it is not in DISTRO_FEATURES.
> glx depends on gl and x11 so if it is to be enabled, both of them should
> be present.
>
> However, x11 without glx and just egl should still be valid configuration.
>
> I think the correct configuration should be:
>
>
> diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> index 72167a2..0043bec 100644
> --- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> +++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
> @@ -15,12 +15,14 @@ UPSTREAM_CHECK_URI =
> "https://github.com/anholt/libepoxy/releases;
>
>  inherit meson pkgconfig distro_features_check
>
> -REQUIRED_DISTRO_FEATURES = "opengl"
> -
>  DEPENDS = "util-macros"
>
> +REQUIRED_DISTRO_FEATURES = "${@bb.utils.contains('PACKAGECONFIG',
> 'glx', 'x11', '', d)}"
> +PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'glx x11', d)} \

Did you mean 'opengl x11' or is glx a valid distro feature? I don't
see it mentioned anywhere else...

> +   ${@bb.utils.contains('DISTRO_FEATURES', 'opengl',
> 'egl', '', d)}"
> +
>  PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
> -PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
> -PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
> +PACKAGECONFIG[glx] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
> +PACKAGECONFIG[x11] = ",, virtual/libx11"
>
>  EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "
>
> I didn't test this on all combinations. Perhaps someone can help test on
> rpi?

Thanks, I volunteer to keep testing with rpi configurations, but I
don't understand the realm enough to judge the patch effect on other
scenarios.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Andrea Galbusera]

On Fri, Jan 19, 2018 at 1:32 PM, Alexander Kanavin
 wrote:
>
>> I'll try to recap a little bit but, please, forgive my ignorance in
>> graphics stacks and libraries.
>> Disclaimer: mostly working on headless systems... my bad!
>> This is what I think I understand here (remember I test building poky
>> + meta-raspberrypi):
>> * libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
>> on virtual/X11 when this is available in DISTRO_FEATURE
>> * the latter is the case for poky which is the DISTRO I'm building
>> for. This gives i.e. a populated recipe-sysroot/usr/include/X11
>> * upstream meson.build conditionally builds tests if X11 is
>> available... so we expect they should build fine in this case
>> * compile fails on test/egl_common.c which does not explicitly include
>> X11/Xlib.h by itself. Doing so moves things forward but, to me, does
>> not seem to be the right thing to do.
>>
>> Is this correct to assume that the upstream tested usecases are
>> probably getting the include otherwise, maybe conditionally as Alex
>> initially suggested. If so, where should we look for the missing
>> pieces?
>
>
> I'm similarly ignorant about this stuff (our resident graphics stack expert
> Jussi Kukkonen left a few months ago), but let's consider the build files:

Yes! Jussi helped a lot in the past with issues raised by graphic
recipes from meta-raspberrypi, most notably 'userland' (see below)...

> - the offending tests are wrapped in "if build_egl and build_x11_tests"
>
> - build_egl is controlled by a PACKAGECONFIG, and I guess you do have it
> available

Yes, if I understand correctly, meta-raspberrypi uses either 'mesa' or
'userland' [1]
as providers for virtual/egl, mesa being chosen only for 64bit builds
of raspberrypi3.

PREFERRED_PROVIDER_virtual/egl ?=
"${@bb.utils.contains("MACHINE_FEATURES", "vc4graphics", "mesa",
"userland", d)}"

BTW I gave the 64bit a spin right now to see if something changed with
mesa instead of userland... and it turned out to build just fine
(tests included).
Nailing it down to something userland is supposed to provide but does
not as expected?

[1] https://github.com/raspberrypi/userland

> - "build_x11_tests = build_glx and x11_dep.found()" - build_glx is similarly
> controlled by a PACKAGECONFIG, and enabled if x11 is in DISTRO_FEATURES:
>
> PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
> PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"
>
> This is where I think the configuration is not quite right. Instead of
> virtual/libx11, it should say virtual/libgl. And if that dependency cannot
> be satisfied, then the x11 option should be altogether disabled in the
> distro/local config (in poky mesa provides virtual/libgl). At least that's
> how it's configured in many other recipes throughout oe-core.

Can you point to any in particular so I can have a look at the pattern?

> Can you try:
> a) disabling x11 PACKAGECONFIG in your local config and see if things build?

Yes, they do. As expected, meson does not find the X11 dependency and
skips building tests...

> b) changing the dependency in that option to virtual/libgl and see what kind
> of error you get, if any. I guess this is the right fix after all.

Nope, below change has no effect. The error is the same as in the
original post (missing symbols from X11/Xlib.h)

diff --git a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
index 72167a2..ee9db24 100644
--- a/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
+++ b/meta/recipes-graphics/libepoxy/libepoxy_1.4.3.bb
@@ -20,7 +20,7 @@ REQUIRED_DISTRO_FEATURES = "opengl"
 DEPENDS = "util-macros"

 PACKAGECONFIG[egl] = "-Denable-egl=yes, -Denable-egl=no, virtual/egl"
-PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libx11"
+PACKAGECONFIG[x11] = "-Denable-glx=yes, -Denable-glx=no, virtual/libgl"
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'x11', d)} egl"

 EXTRA_OEMESON_append_libc-musl = " -Dhas-dlvsym=false "
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Andrea Galbusera]

On Fri, Jan 19, 2018 at 8:45 AM, Alexander Kanavin
 wrote:
> On 01/19/2018 05:29 AM, Andre McCurdy wrote:
>>>
>>> Note that this same test does build fine in poky, so disabling the tests
>>> is
>>> not a good fix. You should figure out what is about the non-poky EGL
>>> headers
>>> that is causing the failure, and whether you need to configure the
>>> provider
>>> of those headers differently, or add missing dependencies etc.
>>
>>
>> Upstream documents that the test suite relies on X11:
>>
>>https://github.com/anholt/libepoxy/blob/1.4.3/README.md#building
>>
>> So disabling the test suite for targets without X11 seems like a
>> perfectly reasonable approach.
>
>
> The meson.build files already have guards for lack of X11 around the test
> files that are failing here. It looks like in this particular configuration
> meson erroneously detects that X11 is present, when it's not.
>
> Alex

I'll try to recap a little bit but, please, forgive my ignorance in
graphics stacks and libraries.
Disclaimer: mostly working on headless systems... my bad!
This is what I think I understand here (remember I test building poky
+ meta-raspberrypi):
* libepoxy recipe in poky uses PACKAGECONFIG to conditionally depend
on virtual/X11 when this is available in DISTRO_FEATURE
* the latter is the case for poky which is the DISTRO I'm building
for. This gives i.e. a populated recipe-sysroot/usr/include/X11
* upstream meson.build conditionally builds tests if X11 is
available... so we expect they should build fine in this case
* compile fails on test/egl_common.c which does not explicitly include
X11/Xlib.h by itself. Doing so moves things forward but, to me, does
not seem to be the right thing to do.

Is this correct to assume that the upstream tested usecases are
probably getting the include otherwise, maybe conditionally as Alex
initially suggested. If so, where should we look for the missing
pieces?

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

Re: [yocto] Error do_compile libepoxy

[Andrea Galbusera]

On Thu, Jan 18, 2018 at 2:13 PM, Max Krummenacher <max.oss...@gmail.com> wrote:
> Hi
>
> 2018-01-18 10:05 GMT+01:00 Alexander Kanavin
> <alexander.kana...@linux.intel.com>:
>>
>> On 01/18/2018 10:58 AM, Andrea Galbusera wrote:
>>>
>>>
>>> Looks like my first guess was not that bad. Reverting below commit,
>>> which switched to meson build system brought my build back to green.
>>> Also CC-ing the patch author who might suggest further investigations.
>>>
>>>  libepoxy: convert to meson build
>>>
>>
>> There's probably a missing header include - carefully compare do_compile
>> logs in both cases and see how they differ for the failing file. Also
>> inspect the file for any conditional define macros and see if they're
>> enabled or not in both cases.
>>
>
> I've seen this also with a build for Nviidia Tegras which have non
> 'standard' (i.e. not from the mesa build) EGL/OpenGLES header files. (And
> there is no OpenGL/GLX.)
>
> Above error and a linking attempt against the not existing GLX are both in
> the test binaries produced from the libepoxy-1.4.3/test directory. All
> artefacts from in there are not packaged by our recipe. Before the switch to
> meson those binaries were not built, so I guess that the issues have been
> there all along but they did not trigger.
>
> My interim fix is to remove the test directory from the top-level
> meson.build file but I'm unsure if that is a way forward.
> I did not yet build nativesdk-libepoxy with this.
>
> --- libepoxy-1.4.3/meson.build~ 2017-06-06 11:55:31.0 +0200
> +++ libepoxy-1.4.3/meson.build  2018-01-18 14:10:49.517098475 +0100
> @@ -258,7 +258,6 @@
>
>  subdir('include/epoxy')
>  subdir('src')
> -subdir('test')
>
>  if get_option('enable-docs')
>doxygen = find_program('doxygen', required: false)
> [
>
> Max

Yes, this is coherent with what Alexander's commit message says. We
started building stuff in test/ while switching to meson...
If we can't easily fix the upstream ourself and/or reproduce outside
of OE to ask for help from upstream devels, IMO we should temporarily
prevent meson from building the tests.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Andrea Galbusera]

On Wed, Jan 17, 2018 at 1:58 PM, Andrea Galbusera <giz...@gmail.com> wrote:
> Hi!
>
> On Wed, Jan 17, 2018 at 1:46 PM, Mathias Rudnik
> <rudnik.math...@googlemail.com> wrote:
>> Hello,
>>
>> I am trying to build libepoxy but the do_compile tasks breaks.
>> I found following error messages in the logs:
>>
>> arm-poky-linux-gnueabi-gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard
>> -mtune=arm1176jzf-s -mfpu=vfp
>> --sysroot=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot
>> '-Itest/egl_common at sta' '-Itest' '-Iinclude/epoxy'
>> '-I../libepoxy-1.4.3/test' '-Iinclude' '-I../libepoxy-1.4.3/include' '-Isrc'
>> '-I../libepoxy-1.4.3/src' '-fdiagnostics-color=always' '-pipe'
>> '-D_FILE_OFFSET_BITS=64' '-Wall' '-Winvalid-pch' '-std=gnu99' '-O2' '-g'
>> '-O2' '-g' '-feliminate-unused-debug-types'
>> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0'
>> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot-native='
>> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot='
>> '-lEGL' '-fPIC' '-Wpointer-arith' '-Wmissing-declarations' '-Wformat=2'
>> '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wnested-externs'
>> '-Wbad-function-cast' '-Wold-style-definition'
>> '-Wdeclaration-after-statement' '-Wunused' '-Wuninitialized' '-Wshadow'
>> '-Wmissing-noreturn' '-Wmissing-format-attribute' '-Wredundant-decls'
>> '-Wlogical-op' '-Werror=implicit' '-Werror=nonnull' '-Werror=init-self'
>> '-Werror=main' '-Werror=missing-braces' '-Werror=sequence-point'
>> '-Werror=return-type' '-Werror=trigraphs' '-Werror=array-bounds'
>> '-Werror=write-strings' '-Werror=address' '-Werror=int-to-pointer-cast'
>> '-Werror=pointer-to-int-cast' '-fno-strict-aliasing' '-Wno-int-conversion'
>> '-MMD' '-MQ' 'test/egl_common at sta/egl_common.c.o' '-MF' 'test/egl_common
>> at sta/egl_common.c.o.d' -o 'test/egl_common at sta/egl_common.c.o' -c
>> ../libepoxy-1.4.3/test/egl_common.c
>> ../libepoxy-1.4.3/test/egl_common.c: In function 'get_egl_display_or_skip':
>> ../libepoxy-1.4.3/test/egl_common.c:36:5: error: unknown type name
>> 'Display'; did you mean 'EGLDisplay'?
>>  Display *dpy = XOpenDisplay(NULL);
>>  ^~~
>>  EGLDisplay
>> ../libepoxy-1.4.3/test/egl_common.c:36:20: error: implicit declaration of
>> function 'XOpenDisplay'; did you mean 'eglGetDisplay'?
>> [-Werror=implicit-function-declaration]
>>  Display *dpy = XOpenDisplay(NULL);
>> ^~~~
>> eglGetDisplay
>> ../libepoxy-1.4.3/test/egl_common.c:36:20: warning: nested extern
>> declaration of 'XOpenDisplay' [-Wnested-externs]
>> cc1: some warnings being treated as errors
>>
>> Does anybody know what i am doing wrong?
>
> Just noticed this also here in CI builds. Unfortunately I'm building
> with lot of new stuff from master branches wrt latest successful
> build. In my case meta-raspberrypi is in the pile, but I haven't had
> the time to investigate yet. At first glance at least commit
> 043f0218491452de223a5f0b47945fc6ec1633eb (libepoxy related) should be
> in my bisecting range. Will report back if something comes up.

Looks like my first guess was not that bad. Reverting below commit,
which switched to meson build system brought my build back to green.
Also CC-ing the patch author who might suggest further investigations.

commit 043f0218491452de223a5f0b47945fc6ec1633eb
Author: Alexander Kanavin <alexander.kana...@linux.intel.com>
AuthorDate: Thu Jan 4 15:12:33 2018 +0200
Commit: Richard Purdie <richard.pur...@linuxfoundation.org>
CommitDate: Fri Jan 5 12:02:37 2018 +

libepoxy: convert to meson build

Add a patch to work around absence of dlvsym() on musl
(wasn't previously a problem as autotools weren't building tests by default)

(From OE-Core rev: aaa523e87c73abc2cf8cf3ea55d9e2c6789d3b9a)

Signed-off-by: Alexander Kanavin <alexander.kana...@linux.intel.com>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>

My configuration is as follows:

Build Configuration:
BB_VERSION   = "1.37.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "arm-poky-linux-gnueabi"
MACHINE  = "raspberrypi3"
DISTRO   = "poky"
DISTRO_VERSION   = "2.4+sn

Re: [yocto] Error do_compile libepoxy

[Andrea Galbusera]

Hi!

On Wed, Jan 17, 2018 at 1:46 PM, Mathias Rudnik
 wrote:
> Hello,
>
> I am trying to build libepoxy but the do_compile tasks breaks.
> I found following error messages in the logs:
>
> arm-poky-linux-gnueabi-gcc -march=armv6 -mfpu=vfp -mfloat-abi=hard
> -mtune=arm1176jzf-s -mfpu=vfp
> --sysroot=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot
> '-Itest/egl_common at sta' '-Itest' '-Iinclude/epoxy'
> '-I../libepoxy-1.4.3/test' '-Iinclude' '-I../libepoxy-1.4.3/include' '-Isrc'
> '-I../libepoxy-1.4.3/src' '-fdiagnostics-color=always' '-pipe'
> '-D_FILE_OFFSET_BITS=64' '-Wall' '-Winvalid-pch' '-std=gnu99' '-O2' '-g'
> '-O2' '-g' '-feliminate-unused-debug-types'
> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0=/usr/src/debug/libepoxy/1.4.3-r0'
> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot-native='
> '-fdebug-prefix-map=/hdd_gold1/mathias/git/poky/rpi-build/tmp/work/arm1176jzfshf-vfp-poky-linux-gnueabi/libepoxy/1.4.3-r0/recipe-sysroot='
> '-lEGL' '-fPIC' '-Wpointer-arith' '-Wmissing-declarations' '-Wformat=2'
> '-Wstrict-prototypes' '-Wmissing-prototypes' '-Wnested-externs'
> '-Wbad-function-cast' '-Wold-style-definition'
> '-Wdeclaration-after-statement' '-Wunused' '-Wuninitialized' '-Wshadow'
> '-Wmissing-noreturn' '-Wmissing-format-attribute' '-Wredundant-decls'
> '-Wlogical-op' '-Werror=implicit' '-Werror=nonnull' '-Werror=init-self'
> '-Werror=main' '-Werror=missing-braces' '-Werror=sequence-point'
> '-Werror=return-type' '-Werror=trigraphs' '-Werror=array-bounds'
> '-Werror=write-strings' '-Werror=address' '-Werror=int-to-pointer-cast'
> '-Werror=pointer-to-int-cast' '-fno-strict-aliasing' '-Wno-int-conversion'
> '-MMD' '-MQ' 'test/egl_common at sta/egl_common.c.o' '-MF' 'test/egl_common
> at sta/egl_common.c.o.d' -o 'test/egl_common at sta/egl_common.c.o' -c
> ../libepoxy-1.4.3/test/egl_common.c
> ../libepoxy-1.4.3/test/egl_common.c: In function 'get_egl_display_or_skip':
> ../libepoxy-1.4.3/test/egl_common.c:36:5: error: unknown type name
> 'Display'; did you mean 'EGLDisplay'?
>  Display *dpy = XOpenDisplay(NULL);
>  ^~~
>  EGLDisplay
> ../libepoxy-1.4.3/test/egl_common.c:36:20: error: implicit declaration of
> function 'XOpenDisplay'; did you mean 'eglGetDisplay'?
> [-Werror=implicit-function-declaration]
>  Display *dpy = XOpenDisplay(NULL);
> ^~~~
> eglGetDisplay
> ../libepoxy-1.4.3/test/egl_common.c:36:20: warning: nested extern
> declaration of 'XOpenDisplay' [-Wnested-externs]
> cc1: some warnings being treated as errors
>
> Does anybody know what i am doing wrong?

Just noticed this also here in CI builds. Unfortunately I'm building
with lot of new stuff from master branches wrt latest successful
build. In my case meta-raspberrypi is in the pile, but I haven't had
the time to investigate yet. At first glance at least commit
043f0218491452de223a5f0b47945fc6ec1633eb (libepoxy related) should be
in my bisecting range. Will report back if something comes up.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] kernel-dev: fix typo

[Andrea Galbusera]

On Mon, Oct 16, 2017 at 4:48 PM, Richard Purdie
 wrote:
> Hi,
>
>
>>...I'm sorry to insist, but I can't figure out why this trivial typo
>> fix has been ignored for long.
>
> I mentioned this to Scott who hadn't seen it for some reason. He's
> merged it now, thanks.

Thanks! ;-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] kernel-dev: fix typo

[Andrea Galbusera]

Hi!

On Thu, Aug 31, 2017 at 10:56 AM, Andrea Galbusera <giz...@gmail.com> wrote:
> On Sun, Aug 13, 2017 at 4:29 PM, Andrea Galbusera <giz...@gmail.com> wrote:
>>
>> Signed-off-by: Andrea Galbusera <giz...@gmail.com>
>> ---
>>  documentation/kernel-dev/kernel-dev-advanced.xml | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml
>> b/documentation/kernel-dev/kernel-dev-advanced.xml
>> index 0394e08..c7e5a3a 100644
>> --- a/documentation/kernel-dev/kernel-dev-advanced.xml
>> +++ b/documentation/kernel-dev/kernel-dev-advanced.xml
>> @@ -867,7 +867,7 @@
>>  When stored outside of the recipe-space, the kernel Metadata
>>  files reside in a separate repository.
>>  The OpenEmbedded build system adds the Metadata to the build
>> as
>> -a "ktype=meta" repository through the
>> +a "type=kmeta" repository through the
>>  > url='_DOCS_REF_URL;#var-SRC_URI'>SRC_URI
>>  variable.
>>  As an example, consider the following
>> SRC_URI
>> --
>> 2.7.4
>>
>
> ping...
>
> Just to check I'm not mistakenly using the wrong list/subject/workflow...

pinging again...
...I'm sorry to insist, but I can't figure out why this trivial typo
fix has been ignored for long.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] weston and xorg-xserver fail to build when using Raspberry Pi 3 user land

[Andrea Galbusera]

Hi Francesco,

On Thu, Sep 28, 2017 at 9:25 AM, Francesco Giancane <
francescogianca...@gmail.com> wrote:

> Hi everyone,
>
> I noticed that if I changed the provider for virtual/mesa (in
> particular, virtual/egl) to 'userland' for a raspberry pi 3 build,
> bitbake fails to resolve the dependency chain, complaining about
> missing RPROVIDES libegl.
>
> The point is that NO libegl is ever provided, only "egl" package.
> Thought it was a typo. No building errors so far.
>
> What do you think?
> Patch attached.
>

This probably goes to oe-core mailing list, which is the upstream project
the patch applies to. Also consider sending inline patches instead of
attachments [1].

[1] https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] do_populate_sdk_ext always being triggered

[Andrea Galbusera]

On Wed, Sep 27, 2017 at 9:52 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Hi Andrea,
>
> On Wednesday, 27 September 2017 10:17:42 PM NZDT Andrea Galbusera wrote:
> > I noticed that periodically running 'bitbake -c do_populate_sdk_ext' for
> an
> > image in my CI loop does always trigger the task to be executed even if
> no
> > changes where applied either to metadata or to the configuration between
> > two iterations. Is this expected? If so, why? Shouldn't SDK artifacts
> > exploit the sstate as i.e. images do?
>
> Ideally yes, but it's hard for us to tell if the metadata has changed or
> not,
> given that we care not just about the actual metadata but also any other
> files
> (scripts etc.) that come with it. Thus we've erred on the side of making it
> build every time.
>

Fair enough! Thanks Paul for confirming and clarifying it is intended
behaviour.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] do_populate_sdk_ext always being triggered

[Andrea Galbusera]

I noticed that periodically running 'bitbake -c do_populate_sdk_ext' for an
image in my CI loop does always trigger the task to be executed even if no
changes where applied either to metadata or to the configuration between
two iterations. Is this expected? If so, why? Shouldn't SDK artifacts
exploit the sstate as i.e. images do?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eSDK install script failure

[Andrea Galbusera]

Paul,

On Tue, Sep 26, 2017 at 6:33 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Hi Andrea,
>
> On Tuesday, 26 September 2017 4:33:46 AM NZDT Andrea Galbusera wrote:
> > I'm back to this issue after the weeken break. See below the feedback
> from
> > your suggestions.
> >
> > On Thu, Sep 21, 2017 at 11:49 PM, Paul Eggleton <
> > paul.eggle...@linux.intel.com> wrote:
> >
> > > On Friday, 22 September 2017 9:40:41 AM NZST Paul Eggleton wrote:
> > > > On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote:
> > > > > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
> > > > > paul.eggle...@linux.intel.com> wrote:
> > > > > > Right, so the next step would be looking for the hash for
> > > > > > python-native.do_populate_sysroot in conf/locked_sigs.inc
> within the
> > > > > > failed SDK install directory and then looking for that in both
> the
> > > sstate-
> > > > > > cache directory within the failed SDK and then in the
> sstate-cache
> > > > > > directory of the build that built it. I suspect it may not be
> there,
> > > but
> > > > > > let me know what you find.
> > > > >
> > > > > Good catch! In the failing SDK neither conf/locked_sigs.inc nor
> > > > > sstate-cache do include any python-native signature or object...
> Only
> > > > > python3-native stuff is there. Weird! As said, SDKs from the same
> build
> > > > > directory, used to work since a few weeks ago. May any recent
> change in
> > > > > poky master have caused this while periodically upgrading without
> > > > > regenerating the sstate-cache?
> > > >
> > > > No, I can't see any added references to python-native anywhere in the
> > > last few
> > > > weeks. If you do bitbake -c clean python-native and then rebuild the
> SDK
> > > does
> > > > the issue go away?
> > >
> > > Actually scratch that, that's not going to help. The question is where
> is
> > > this dependency coming from and why isn't it properly picked up such
> > > that it gets included. bitbake -g -c populate_sdk_ext your-image might
> be
> > > useful in determining that.
> > >
> >
> > $ bitbake core-image-base-dlms -c populate_sdk_ext -g
> >
> > Grepping task-depends.dot for "python-native" gives no match.
> Surprisingly
> > enough (at least for me) I read a different story when doing the same for
> > the image itself
> >
> > $ bitbake core-image-base-dlms -g
> > $ grep python-native task-depends.dot
> >  "python-native.do_populate_lic" [label="python-native
> > do_populate_lic\n:2.7.13-r1.1\n/home/gizero/work/
> smartliving/distro/repo-master/build-poky/conf/../../
> layers/poky/meta/recipes-devtools/python/python[18/7956]
> > .7.13.bb"]
> > "python-native.do_populate_lic" -> "python-native.do_patch"
> > "python-native.do_prepare_recipe_sysroot" [label="python-native
> > do_prepare_recipe_sysroot\n:2.7.13-r1.1\n/home/gizero/work/
> smartliving/distro/repo-master/build-poky/conf/../../
> layers/poky/meta/recipes-devtools/py
> > thon/python-native_2.7.13.bb"]
> > "python-native.do_prepare_recipe_sysroot" ->
> > "openssl-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "pkgconfig-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "automake-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "expat-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "sqlite3-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" -> "python-native.do_fetch"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "bzip2-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "readline-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "zlib-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "autoconf-native.do_populate_sysroot"
> > "python-native.do_prepare_recipe_sysroot" ->
> > "gnu-config-native.do_populate_sysr

Re: [yocto] eSDK install script failure

[Andrea Galbusera]

Hi Paul,

I'm back to this issue after the weeken break. See below the feedback from
your suggestions.

On Thu, Sep 21, 2017 at 11:49 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Friday, 22 September 2017 9:40:41 AM NZST Paul Eggleton wrote:
> > On Friday, 22 September 2017 9:22:08 AM NZST Andrea Galbusera wrote:
> > > On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
> > > paul.eggle...@linux.intel.com> wrote:
> > > > Right, so the next step would be looking for the hash for
> > > > python-native.do_populate_sysroot in conf/locked_sigs.inc within the
> > > > failed SDK install directory and then looking for that in both the
> sstate-
> > > > cache directory within the failed SDK and then in the sstate-cache
> > > > directory of the build that built it. I suspect it may not be there,
> but
> > > > let me know what you find.
> > >
> > > Good catch! In the failing SDK neither conf/locked_sigs.inc nor
> > > sstate-cache do include any python-native signature or object... Only
> > > python3-native stuff is there. Weird! As said, SDKs from the same build
> > > directory, used to work since a few weeks ago. May any recent change in
> > > poky master have caused this while periodically upgrading without
> > > regenerating the sstate-cache?
> >
> > No, I can't see any added references to python-native anywhere in the
> last few
> > weeks. If you do bitbake -c clean python-native and then rebuild the SDK
> does
> > the issue go away?
>
> Actually scratch that, that's not going to help. The question is where is
> this dependency coming from and why isn't it properly picked up such
> that it gets included. bitbake -g -c populate_sdk_ext your-image might be
> useful in determining that.
>

$ bitbake core-image-base-dlms -c populate_sdk_ext -g

Grepping task-depends.dot for "python-native" gives no match. Surprisingly
enough (at least for me) I read a different story when doing the same for
the image itself

$ bitbake core-image-base-dlms -g
$ grep python-native task-depends.dot
 "python-native.do_populate_lic" [label="python-native
do_populate_lic\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/python/python[18/7956]
.7.13.bb"]
"python-native.do_populate_lic" -> "python-native.do_patch"
"python-native.do_prepare_recipe_sysroot" [label="python-native
do_prepare_recipe_sysroot\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/py
thon/python-native_2.7.13.bb"]
"python-native.do_prepare_recipe_sysroot" ->
"openssl-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"pkgconfig-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"automake-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"expat-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"sqlite3-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" -> "python-native.do_fetch"
"python-native.do_prepare_recipe_sysroot" ->
"bzip2-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"readline-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"zlib-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"autoconf-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"gnu-config-native.do_populate_sysroot"
"python-native.do_prepare_recipe_sysroot" ->
"libtool-native.do_populate_sysroot"
"python-native.do_rm_work_all" [label="python-native
do_rm_work_all\n:2.7.13-r1.1\n/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/poky/meta/recipes-devtools/python/python-native_2.7
.13.bb"]
"python-native.do_rm_work_all" -> "readline-native.do_rm_work"
"python-native.do_rm_work_all" -> "gnu-config-native.do_rm_work"
"python-native.do_rm_work_all" -> "openssl-native.do_rm_work"
"python-native.do_rm_work_all" -> "automake-native.do_rm_work"
"python-native.do_rm_work_all" -> "m4-native.do_rm_work"
"python-native.do_rm_work_all" -> "makedepend-native.do_rm_work"
"python-native.do_rm_work_all" -> "xproto-native.do_rm_work"
"python-native.do_rm_work_all" -> "b

Re: [yocto] eSDK install script failure

[Andrea Galbusera]

On Thu, Sep 21, 2017 at 10:48 PM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Friday, 22 September 2017 1:06:19 AM NZST Andrea Galbusera wrote:
> > On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbusera <giz...@gmail.com>
> wrote:
> > > On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton <
> > > paul.eggle...@linux.intel.com> wrote:
> > >> On Wednesday, 20 September 2017 8:44:22 PM NZST Andrea Galbusera
> wrote:
> > >> > Seeing the errors below while installing an eSDK. This is a
> routinely
> > >> > generated VM that installs the eSDK from installation script. The
> errors
> > >> > appeared with the latest iteration of the eSDK script, which is
> > >> generated
> > >> > with almost up-to-date revisions from master. Of course I have extra
> > >> layers
> > >> > in the mix, but none of them apparently had relevant changed since
> last
> > >> > (working) iteration: mostly synching to master branches happened.
> Can
> > >> > anyone help suggesting how to investigate this further? What do
> those
> > >> > unexpected task mean? I'm blocked on releasing this SDK to
> developers
> > >> and
> > >> > clues from expert would be very appreciated...
> > >> >
> > >> > ==> default: Checking sstate mirror object availability...
> > >> > ==> default: done.
> > >> > ==> default: ERROR: Task python-native.do_fetch attempted to execute
> > >> > unexpectedly
> > >> > ==> default: ERROR: Task python-native.do_prepare_recipe_sysroot
> > >> attempted
> > >> > to execute unexpectedly
> > >> > ==> default: ERROR: Task python-native.do_unpack attempted to
> execute
> > >> > unexpectedly
> > >> > ==> default: ERROR: Task python-native.do_patch attempted to execute
> > >> > unexpectedly
> > >> > ==> default: ERROR: Task python-native.do_populate_lic attempted to
> > >> execute
> > >> > unexpectedly and should have been setscened
> > >> > ==> default: ERROR: Task python-native.do_configure attempted to
> execute
> > >> > unexpectedly
> > >> > ==> default: ERROR: Task python-native.do_compile attempted to
> execute
> > >> > unexpectedly
> > >> > ==> default: ERROR: Task python-native.do_install attempted to
> execute
> > >> > unexpectedly
> > >> > ==> default: ERROR: Task python-native.do_populate_sysroot
> attempted to
> > >> > execute unexpectedly and should have been setscened
> > >> > ==> default: ERROR: SDK preparation failed: error log written to
> > >> > /home/vagrant/poky_sdk/preparing_build_system.log
> > >> >
> > >>
> > >> Basically this means that these tasks tried to execute where really
> the
> > >> results should have been able to be restored from sstate.
> > >>
> > >> The cause of this type of error is one of three things:
> > >>
> > >> 1) The sstate archive corresponding to a task wasn't able to be
> fetched
> > >> from
> > >> the server (for a minimal eSDK) or wasn't present in the installer
> (for a
> > >> full
> > >> eSDK - less likely as we basically do a trial run as part of building
> the
> > >> eSDK
> > >> in the first place)
> > >>
> > >> 2) The signature was somehow different to what it should have been.
> > >> (Locked
> > >> signatures are supposed to guard against this.)
> > >>
> > >> 3) A task that wasn't expected to execute did execute and thus the
> sstate
> > >> wasn't available.
> > >>
> > >> Given that this was python-native which I would expect would be a
> normal
> > >> part
> > >> of the SDK, I would suspect #1. Is this a minimal or full eSDK (i.e.
> what
> > >> is
> > >> SDK_EXT_TYPE set to)?
> > >>
> > >
> > > That was a "full" eSDK. I noticed that the "same" eSDK installer from
> > > another build host was not affected and I'm trying to rebuild on the
> > > original one with even more recent revision and see if it still
> happens or
> > > not. Failure with the first one was repeatable, hence I suspect an
> issue at
> > > sdk population stage, not during installation.
> >
> > Nuking

Re: [yocto] eSDK install script failure

[Andrea Galbusera]

On Wed, Sep 20, 2017 at 11:26 PM, Andrea Galbusera <giz...@gmail.com> wrote:

> Hi Paul,
> thanks for explaining and helping sorting this out.
>
> On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton <
> paul.eggle...@linux.intel.com> wrote:
>
>> Hi Andrea,
>>
>> On Wednesday, 20 September 2017 8:44:22 PM NZST Andrea Galbusera wrote:
>> > Seeing the errors below while installing an eSDK. This is a routinely
>> > generated VM that installs the eSDK from installation script. The errors
>> > appeared with the latest iteration of the eSDK script, which is
>> generated
>> > with almost up-to-date revisions from master. Of course I have extra
>> layers
>> > in the mix, but none of them apparently had relevant changed since last
>> > (working) iteration: mostly synching to master branches happened. Can
>> > anyone help suggesting how to investigate this further? What do those
>> > unexpected task mean? I'm blocked on releasing this SDK to developers
>> and
>> > clues from expert would be very appreciated...
>> >
>> > ==> default: Checking sstate mirror object availability...
>> > ==> default: done.
>> > ==> default: ERROR: Task python-native.do_fetch attempted to execute
>> > unexpectedly
>> > ==> default: ERROR: Task python-native.do_prepare_recipe_sysroot
>> attempted
>> > to execute unexpectedly
>> > ==> default: ERROR: Task python-native.do_unpack attempted to execute
>> > unexpectedly
>> > ==> default: ERROR: Task python-native.do_patch attempted to execute
>> > unexpectedly
>> > ==> default: ERROR: Task python-native.do_populate_lic attempted to
>> execute
>> > unexpectedly and should have been setscened
>> > ==> default: ERROR: Task python-native.do_configure attempted to execute
>> > unexpectedly
>> > ==> default: ERROR: Task python-native.do_compile attempted to execute
>> > unexpectedly
>> > ==> default: ERROR: Task python-native.do_install attempted to execute
>> > unexpectedly
>> > ==> default: ERROR: Task python-native.do_populate_sysroot attempted to
>> > execute unexpectedly and should have been setscened
>> > ==> default: ERROR: SDK preparation failed: error log written to
>> > /home/vagrant/poky_sdk/preparing_build_system.log
>> >
>>
>> Basically this means that these tasks tried to execute where really the
>> results should have been able to be restored from sstate.
>>
>> The cause of this type of error is one of three things:
>>
>> 1) The sstate archive corresponding to a task wasn't able to be fetched
>> from
>> the server (for a minimal eSDK) or wasn't present in the installer (for a
>> full
>> eSDK - less likely as we basically do a trial run as part of building the
>> eSDK
>> in the first place)
>>
>> 2) The signature was somehow different to what it should have been.
>> (Locked
>> signatures are supposed to guard against this.)
>>
>> 3) A task that wasn't expected to execute did execute and thus the sstate
>> wasn't available.
>>
>> Given that this was python-native which I would expect would be a normal
>> part
>> of the SDK, I would suspect #1. Is this a minimal or full eSDK (i.e. what
>> is
>> SDK_EXT_TYPE set to)?
>>
>
> That was a "full" eSDK. I noticed that the "same" eSDK installer from
> another build host was not affected and I'm trying to rebuild on the
> original one with even more recent revision and see if it still happens or
> not. Failure with the first one was repeatable, hence I suspect an issue at
> sdk population stage, not during installation.
>

Nuking tmp/ and rebuilding with the same revisions of the successful build
host didn't fix the issue... Same error on installation of the generated
eSDK. Would you suggest any other investigation step? On my todo list I'd
put using the sstate from that other build host than nuking local
sstate-cache/ and going to take a very long coffee break. :-(
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] eSDK install script failure

[Andrea Galbusera]

Hi Paul,
thanks for explaining and helping sorting this out.

On Wed, Sep 20, 2017 at 11:54 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> Hi Andrea,
>
> On Wednesday, 20 September 2017 8:44:22 PM NZST Andrea Galbusera wrote:
> > Seeing the errors below while installing an eSDK. This is a routinely
> > generated VM that installs the eSDK from installation script. The errors
> > appeared with the latest iteration of the eSDK script, which is generated
> > with almost up-to-date revisions from master. Of course I have extra
> layers
> > in the mix, but none of them apparently had relevant changed since last
> > (working) iteration: mostly synching to master branches happened. Can
> > anyone help suggesting how to investigate this further? What do those
> > unexpected task mean? I'm blocked on releasing this SDK to developers and
> > clues from expert would be very appreciated...
> >
> > ==> default: Checking sstate mirror object availability...
> > ==> default: done.
> > ==> default: ERROR: Task python-native.do_fetch attempted to execute
> > unexpectedly
> > ==> default: ERROR: Task python-native.do_prepare_recipe_sysroot
> attempted
> > to execute unexpectedly
> > ==> default: ERROR: Task python-native.do_unpack attempted to execute
> > unexpectedly
> > ==> default: ERROR: Task python-native.do_patch attempted to execute
> > unexpectedly
> > ==> default: ERROR: Task python-native.do_populate_lic attempted to
> execute
> > unexpectedly and should have been setscened
> > ==> default: ERROR: Task python-native.do_configure attempted to execute
> > unexpectedly
> > ==> default: ERROR: Task python-native.do_compile attempted to execute
> > unexpectedly
> > ==> default: ERROR: Task python-native.do_install attempted to execute
> > unexpectedly
> > ==> default: ERROR: Task python-native.do_populate_sysroot attempted to
> > execute unexpectedly and should have been setscened
> > ==> default: ERROR: SDK preparation failed: error log written to
> > /home/vagrant/poky_sdk/preparing_build_system.log
> >
>
> Basically this means that these tasks tried to execute where really the
> results should have been able to be restored from sstate.
>
> The cause of this type of error is one of three things:
>
> 1) The sstate archive corresponding to a task wasn't able to be fetched
> from
> the server (for a minimal eSDK) or wasn't present in the installer (for a
> full
> eSDK - less likely as we basically do a trial run as part of building the
> eSDK
> in the first place)
>
> 2) The signature was somehow different to what it should have been. (Locked
> signatures are supposed to guard against this.)
>
> 3) A task that wasn't expected to execute did execute and thus the sstate
> wasn't available.
>
> Given that this was python-native which I would expect would be a normal
> part
> of the SDK, I would suspect #1. Is this a minimal or full eSDK (i.e. what
> is
> SDK_EXT_TYPE set to)?
>

That was a "full" eSDK. I noticed that the "same" eSDK installer from
another build host was not affected and I'm trying to rebuild on the
original one with even more recent revision and see if it still happens or
not. Failure with the first one was repeatable, hence I suspect an issue at
sdk population stage, not during installation.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] eSDK install script failure

[Andrea Galbusera]

Seeing the errors below while installing an eSDK. This is a routinely
generated VM that installs the eSDK from installation script. The errors
appeared with the latest iteration of the eSDK script, which is generated
with almost up-to-date revisions from master. Of course I have extra layers
in the mix, but none of them apparently had relevant changed since last
(working) iteration: mostly synching to master branches happened. Can
anyone help suggesting how to investigate this further? What do those
unexpected task mean? I'm blocked on releasing this SDK to developers and
clues from expert would be very appreciated...

==> default: Checking sstate mirror object availability...
==> default: done.
==> default: ERROR: Task python-native.do_fetch attempted to execute
unexpectedly
==> default: ERROR: Task python-native.do_prepare_recipe_sysroot attempted
to execute unexpectedly
==> default: ERROR: Task python-native.do_unpack attempted to execute
unexpectedly
==> default: ERROR: Task python-native.do_patch attempted to execute
unexpectedly
==> default: ERROR: Task python-native.do_populate_lic attempted to execute
unexpectedly and should have been setscened
==> default: ERROR: Task python-native.do_configure attempted to execute
unexpectedly
==> default: ERROR: Task python-native.do_compile attempted to execute
unexpectedly
==> default: ERROR: Task python-native.do_install attempted to execute
unexpectedly
==> default: ERROR: Task python-native.do_populate_sysroot attempted to
execute unexpectedly and should have been setscened
==> default: ERROR: SDK preparation failed: error log written to
/home/vagrant/poky_sdk/preparing_build_system.log
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] u-boot: drop now upstreamed patches

[Andrea Galbusera]

oe-core now provides v2017.09 of u-boot which already merged both patches
introduced by commit 94e2929f746f7e49a7870f7ea889dcbed05296c7 so we can
drop them from meta-raspberrypi.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 ...01-Revert-dm-arm-rpi-Drop-CONFIG_OF_EMBED.patch | 67 
 .../0002-rpi-Enable-USB-keyboard-support.patch | 71 --
 recipes-bsp/u-boot/u-boot_%.bbappend   |  7 ---
 3 files changed, 145 deletions(-)
 delete mode 100644 
recipes-bsp/u-boot/u-boot/0001-Revert-dm-arm-rpi-Drop-CONFIG_OF_EMBED.patch
 delete mode 100644 
recipes-bsp/u-boot/u-boot/0002-rpi-Enable-USB-keyboard-support.patch

diff --git 
a/recipes-bsp/u-boot/u-boot/0001-Revert-dm-arm-rpi-Drop-CONFIG_OF_EMBED.patch 
b/recipes-bsp/u-boot/u-boot/0001-Revert-dm-arm-rpi-Drop-CONFIG_OF_EMBED.patch
deleted file mode 100644
index ffabe89..000
--- 
a/recipes-bsp/u-boot/u-boot/0001-Revert-dm-arm-rpi-Drop-CONFIG_OF_EMBED.patch
+++ /dev/null
@@ -1,67 +0,0 @@
-From 46035d84eb75d54e524d068c29a42c4f562f757a Mon Sep 17 00:00:00 2001
-From: Paul Barker <pbar...@toganlabs.com>
-Date: Wed, 2 Aug 2017 11:37:30 +0100
-Subject: [PATCH 1/2] Revert "dm: arm: rpi: Drop CONFIG_OF_EMBED"
-
-This reverts commit 25877d4e4c45451c5398aec3de50e0d5befe0e9f.
-
-Signed-off-by: Paul Barker <pbar...@toganlabs.com>
-Upstream-status: Pending

- configs/rpi_2_defconfig | 1 +
- configs/rpi_3_32b_defconfig | 1 +
- configs/rpi_3_defconfig | 1 +
- configs/rpi_defconfig   | 1 +
- 4 files changed, 4 insertions(+)
-
-diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
-index 862203f..6aa0532 100644
 a/configs/rpi_2_defconfig
-+++ b/configs/rpi_2_defconfig
-@@ -13,6 +13,7 @@ CONFIG_CMD_MMC=y
- CONFIG_CMD_USB=y
- # CONFIG_CMD_FPGA is not set
- CONFIG_CMD_GPIO=y
-+CONFIG_OF_EMBED=y
- CONFIG_DM_MMC=y
- CONFIG_MMC_SDHCI=y
- CONFIG_MMC_SDHCI_BCM2835=y
-diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
-index 95b1677..7396925 100644
 a/configs/rpi_3_32b_defconfig
-+++ b/configs/rpi_3_32b_defconfig
-@@ -14,6 +14,7 @@ CONFIG_CMD_MMC=y
- CONFIG_CMD_USB=y
- # CONFIG_CMD_FPGA is not set
- CONFIG_CMD_GPIO=y
-+CONFIG_OF_EMBED=y
- CONFIG_DM_MMC=y
- CONFIG_MMC_SDHCI=y
- CONFIG_MMC_SDHCI_BCM2835=y
-diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
-index f91b53d..1b1ee67 100644
 a/configs/rpi_3_defconfig
-+++ b/configs/rpi_3_defconfig
-@@ -14,6 +14,7 @@ CONFIG_CMD_MMC=y
- CONFIG_CMD_USB=y
- # CONFIG_CMD_FPGA is not set
- CONFIG_CMD_GPIO=y
-+CONFIG_OF_EMBED=y
- CONFIG_DM_MMC=y
- CONFIG_MMC_SDHCI=y
- CONFIG_MMC_SDHCI_BCM2835=y
-diff --git a/configs/rpi_defconfig b/configs/rpi_defconfig
-index e2d81ab..c7cf6e0 100644
 a/configs/rpi_defconfig
-+++ b/configs/rpi_defconfig
-@@ -13,6 +13,7 @@ CONFIG_CMD_MMC=y
- CONFIG_CMD_USB=y
- # CONFIG_CMD_FPGA is not set
- CONFIG_CMD_GPIO=y
-+CONFIG_OF_EMBED=y
- CONFIG_DM_MMC=y
- CONFIG_MMC_SDHCI=y
- CONFIG_MMC_SDHCI_BCM2835=y
--- 
-2.7.4
-
diff --git 
a/recipes-bsp/u-boot/u-boot/0002-rpi-Enable-USB-keyboard-support.patch 
b/recipes-bsp/u-boot/u-boot/0002-rpi-Enable-USB-keyboard-support.patch
deleted file mode 100644
index 675d7d9..000
--- a/recipes-bsp/u-boot/u-boot/0002-rpi-Enable-USB-keyboard-support.patch
+++ /dev/null
@@ -1,71 +0,0 @@
-From e4ddccdcf2360c104de502db140a2dbb90b63cfe Mon Sep 17 00:00:00 2001
-From: Simon Glass <s...@chromium.org>
-Date: Thu, 24 Aug 2017 19:45:31 -0600
-Subject: [PATCH 2/2] rpi: Enable USB keyboard support
-
-This is currently disabled, so USB keyboards are not detected in U_Boot.
-Enable this option to fix that.
-
-Backported to v2017.07.
-
-Signed-off-by: Simon Glass <s...@chromium.org>
-Signed-off-by: Paul Barker <pbar...@toganlabs.com>
-Upstream-status: Backport

- configs/rpi_2_defconfig | 1 +
- configs/rpi_3_32b_defconfig | 1 +
- configs/rpi_3_defconfig | 1 +
- configs/rpi_defconfig   | 1 +
- 4 files changed, 4 insertions(+)
-
-diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
-index 6aa0532..9851836 100644
 a/configs/rpi_2_defconfig
-+++ b/configs/rpi_2_defconfig
-@@ -22,6 +22,7 @@ CONFIG_USB=y
- CONFIG_DM_USB=y
- CONFIG_USB_STORAGE=y
- CONFIG_USB_KEYBOARD=y
-+CONFIG_DM_KEYBOARD=y
- CONFIG_DM_VIDEO=y
- CONFIG_SYS_WHITE_ON_BLACK=y
- CONFIG_CONSOLE_SCROLL_LINES=10
-diff --git a/configs/rpi_3_32b_defconfig b/configs/rpi_3_32b_defconfig
-index 7396925..c9bdcd7 100644
 a/configs/rpi_3_32b_defconfig
-+++ b/configs/rpi_3_32b_defconfig
-@@ -24,6 +24,7 @@ CONFIG_USB=y
- CONFIG_DM_USB=y
- CONFIG_USB_STORAGE=y
- CONFIG_USB_KEYBOARD=y
-+CONFIG_DM_KEYBOARD=y
- CONFIG_DM_VIDEO=y
- CONFIG_SYS_WHITE_ON_BLACK=y
- CONFIG_CONSOLE_SCROLL_LINES=10
-diff --git a/configs/rpi_3_defconfig b/configs/rpi_3_defconfig
-index 1b1ee67..e9c9806 100644
 a/configs/rpi_3_defconfig
-+++ b/configs/rpi_3_defconfig
-@@ -24,6 +24,7 @@ CONFIG_USB=y
- CONFIG_DM_USB=y
- CONFIG_USB_STORAGE=y
- CONFIG_USB_KEYBOAR

Re: [yocto] [meta-raspberrypi] enable serial communication pi 3

[Andrea Galbusera]

On Wed, Sep 13, 2017 at 10:04 AM, yahia farghaly 
wrote:

>
> Thanks for replying but it gives me this error log
>
>
>> *ERROR: rpi-hwup-image-1.0-r0 do_rootfs: Unable to install packages.
>> Command
>> '/yocto/poky/build/tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-hwup-image/1.0-r0/recipe-sysroot-native/usr/bin/apt-get
>>  install --force-yes --allow-unauthenticated run-postinsts
>> packagegroup-core-boot kernel-modules rpi-config' returned 100:*
>> *Reading package lists...*
>> *Building dependency tree...*
>> *Reading state information...*
>> *Package rpi-config is not available, but is referred to by another
>> package.*
>> *This may mean that the package is missing, has been obsoleted, or**is
>> only available from another source*
>> *E: Package 'rpi-config' has no installation candidate*
>>
>> *ERROR: rpi-hwup-image-1.0-r0 do_rootfs: Function failed: do_rootfs*
>> *ERROR: Logfile of failure stored in:
>> /yocto/poky/build/tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-hwup-image/1.0-r0/temp/log.do_rootfs.2252**ERROR:
>> Task
>> (/yocto/poky/meta-raspberrypi/recipes-core/images/rpi-hwup-image.bb:do_rootfs)
>> failed with exit code '1'*
>
>
> All what i did is  IMAGE_INSTALL_append = "rpi-config" , the recipe file
> is not exist in the meta-raspberry
>

You missed the space before rpi-config from the original suggestion in
IMAGE_INSTALL_append. This is always required when overriding variables
with _append


>
> ‌
>
> On 13 September 2017 at 09:27, Ayoub Zaki  wrote:
>
>> I ran into the same problem:
>>
>> ENABLE_UART = "1" is not enough you should also add INSTALL_append= "
>> rpi-config" to your local.conf and Serial port will be enabled.
>>
>> On 12.09.2017 14:09, yahia farghaly wrote:
>>
>> I have bitbaked rpi-hwup-image for raspberry pi 3 on sd card and
>> connected the serial ports to *usb to ttl device* . i have set the
>> minicom to
>> port: /dev/ttyUSB0
>> baud rate: 115200
>> the image is booting fine and i can see the prompt on the screen but
>> cannot see in my serial console using minicom.
>> *is serial enabled by default for this image ? *
>> i also tried ENABLE_UART = "1" in local.conf but doesn't help.
>>
>> how to enable it ? and what the serial device name with respect to
>> raspberry pi
>>
>> thanks,
>>
>> --
>> Yahia Farghaly
>> Graduated from Faculty of Engineering - Electronics and Communications
>> Department at Cairo University.
>> Linkedin  - GitHub
>> 
>>
>>
>>
>> ‌
>>
>>
>>
>> --
>>
>> Ayoub Zaki
>> Embedded Systems Consultant
>>
>> Vaihinger Str. 2/1
>> 71634 Ludwigsburg
>>
>> e-mail: ayoub.z...@embexus.com
>> Tel: +49176-62901545 <+49%20176%2062901545>https://embexus.com
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
>
> --
> Yahia Farghaly
> Graduated from Faculty of Engineering - Electronics and Communications
> Department at Cairo University.
> Linkedin  - GitHub
> 
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] raspberrypi3-64 target not booting

[Andrea Galbusera]

On Fri, Sep 8, 2017 at 11:22 AM, Paul Barker <pbar...@toganlabs.com> wrote:

> On Fri, Sep 8, 2017 at 10:18 AM, Andrea Galbusera <giz...@gmail.com>
> wrote:
> > Hi!
> >
> > On Mon, Sep 4, 2017 at 10:31 PM, Paul Barker <pbar...@toganlabs.com>
> wrote:
> >>
> >> On Fri, Aug 25, 2017 at 6:27 PM, Khem Raj <raj.k...@gmail.com> wrote:
> >> > On Fri, Aug 25, 2017 at 10:14 AM, Bill Jenkins <b...@korgrd.com>
> wrote:
> >> >>
> >> >> On Aug 25, 2017, at 9:42 AM, Khem Raj <raj.k...@gmail.com> wrote:
> >> >>
> >> >>
> >> >> On Fri, Aug 25, 2017 at 9:39 AM Bill Jenkins <b...@korgrd.com>
> wrote:
> >> >>>
> >> >>> I am trying to just get the simple 64-bit rpi-basic-image to work,
> but
> >> >>> the
> >> >>> Raspberry Pi 3 seems to hang with the rainbow screen at startup.
> >> >>
> >> >>
> >> >> Can you plugin a serial cable and see if that worked or try to add
> ssh
> >> >> daemon on target and try to ssh into pi
> >> >>>
> >> >>>
> >> >>
> >> >> That was a good call. I can login with the ssh daemon, so it does
> >> >> successfully boot. I just
> >> >> cannot access it from the HDMI port. (I do not have the hardware for
> a
> >> >> serial connection
> >> >> at the moment)
> >> >>
> >> >> Any ideas on how to get the HDMI port to function the same way as it
> >> >> does
> >> >> for the
> >> >> 32-bit case?
> >> >>
> >> >
> >> > Readding the mailing list.
> >> >
> >> > what you have is exactly what I had when I submitted the port to
> >> > meta-raspberrypi. Haven;t had a chance to revisit it. but this could
> >> > be related to device tree files we are using here. I have had reports
> >> > from other devs of having been able to boot into graphics using older
> >> > kernels but I never got
> >> > that far myself.
> >>
> >> I'm seeing the same issue on builds from both pyro and master
> >> branches. I've confirmed this isn't a HW issue by trying out an
> >> OpenSUSE Leap 42.2 64-bit build for Raspberry Pi 3.
> >>
> >> Khem, are you saying this is the current expected state of Raspberry
> >> Pi 3 64-bit support? If so I'd really like us to document this in the
> >> readme and open a bug so we don't lose track of it.
> >
> >
> > Reading this thread made me curious to get back to building/testing for
> > raspberrypi3-64 myself as I used to do for a while till a few months ago.
> > Not really in the need for that now, but, it would be nice to help
> keeping
> > the support healthy if possible. Then tonight I added back
> > MACHINE=raspberrypi3-64 bitbake myimage to the builds I run daily with
> > master branches of poky and meta-raspberrypi and felt into a even earlier
> > showstopper than the boot issue described here. My kernel build fails
> with:
> >
> > Build Configuration:
> > BB_VERSION= "1.35.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "universal"
> > TARGET_SYS= "aarch64-poky-linux"
> > MACHINE   = "raspberrypi3-64"
> > DISTRO= "poky"
> > DISTRO_VERSION= "2.3+snapshot-20170908"
> > TUNE_FEATURES = "aarch64"
> > TARGET_FPU= ""
> > meta
> > meta-poky
> > meta-yocto-bsp= "HEAD:8b4f16a9cbbaf521461f699b7264fac2ac872581"
> > meta-raspberrypi  = "HEAD:e59132bdcc092597ed5f08a77e7160b0f3bb3547"
> >
> > Initialising tasks: 100%
> > |###
> 
> 
> ##|
> > Time: 0:00:11
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 do_compile:
> > oe_runmake failed
> > ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 do_compile:
> > Function failed: do_compile (log file is located at
> > /workdir/bsl/build-poky/tmp-poky/work/raspberrypi3_64-
> poky-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r
> > 0/temp/log.do_compile.8392)
> 

Re: [yocto] raspberrypi3-64 target not booting

[Andrea Galbusera]

Hi!

On Mon, Sep 4, 2017 at 10:31 PM, Paul Barker  wrote:

> On Fri, Aug 25, 2017 at 6:27 PM, Khem Raj  wrote:
> > On Fri, Aug 25, 2017 at 10:14 AM, Bill Jenkins  wrote:
> >>
> >> On Aug 25, 2017, at 9:42 AM, Khem Raj  wrote:
> >>
> >>
> >> On Fri, Aug 25, 2017 at 9:39 AM Bill Jenkins  wrote:
> >>>
> >>> I am trying to just get the simple 64-bit rpi-basic-image to work, but
> the
> >>> Raspberry Pi 3 seems to hang with the rainbow screen at startup.
> >>
> >>
> >> Can you plugin a serial cable and see if that worked or try to add ssh
> >> daemon on target and try to ssh into pi
> >>>
> >>>
> >>
> >> That was a good call. I can login with the ssh daemon, so it does
> >> successfully boot. I just
> >> cannot access it from the HDMI port. (I do not have the hardware for a
> >> serial connection
> >> at the moment)
> >>
> >> Any ideas on how to get the HDMI port to function the same way as it
> does
> >> for the
> >> 32-bit case?
> >>
> >
> > Readding the mailing list.
> >
> > what you have is exactly what I had when I submitted the port to
> > meta-raspberrypi. Haven;t had a chance to revisit it. but this could
> > be related to device tree files we are using here. I have had reports
> > from other devs of having been able to boot into graphics using older
> > kernels but I never got
> > that far myself.
>
> I'm seeing the same issue on builds from both pyro and master
> branches. I've confirmed this isn't a HW issue by trying out an
> OpenSUSE Leap 42.2 64-bit build for Raspberry Pi 3.
>
> Khem, are you saying this is the current expected state of Raspberry
> Pi 3 64-bit support? If so I'd really like us to document this in the
> readme and open a bug so we don't lose track of it.
>

Reading this thread made me curious to get back to building/testing for
raspberrypi3-64 myself as I used to do for a while till a few months ago.
Not really in the need for that now, but, it would be nice to help keeping
the support healthy if possible. Then tonight I added back
MACHINE=raspberrypi3-64 bitbake myimage to the builds I run daily with
master branches of poky and meta-raspberrypi and felt into a even earlier
showstopper than the boot issue described here. My kernel build fails with:

Build Configuration:
BB_VERSION= "1.35.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "aarch64-poky-linux"
MACHINE   = "raspberrypi3-64"
DISTRO= "poky"
DISTRO_VERSION= "2.3+snapshot-20170908"
TUNE_FEATURES = "aarch64"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= "HEAD:8b4f16a9cbbaf521461f699b7264fac2ac872581"
meta-raspberrypi  = "HEAD:e59132bdcc092597ed5f08a77e7160b0f3bb3547"

Initialising tasks: 100%
|#|
Time: 0:00:11
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 do_compile:
oe_runmake failed
ERROR: linux-raspberrypi-1_4.9.41+gitAUTOINC+4153f509b4-r0 do_compile:
Function failed: do_compile (log file is located at
/workdir/bsl/build-poky/tmp-poky/work/raspberrypi3_64-poky-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r
0/temp/log.do_compile.8392)
ERROR: Logfile of failure stored in:
/workdir/bsl/build-poky/tmp-poky/work/raspberrypi3_64-poky-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/temp/log.do_compile.8392
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make -j 8 HOSTCC=gcc  HOSTCPP=gcc  -E uImage
CC=aarch64-poky-linux-gcc   -fuse-ld=bfd
 
--sysroot=/workdir/bsl/build-poky/tmp-poky/work/raspberrypi3_64-poky-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/recipe-sysroot
-
ffile-prefix-map=/workdir/bsl/build-poky/tmp-poky/work-shared/raspberrypi3-64/kernel-source=/kernel-source/
 LD=aarch64-poky-linux-ld.bfd
 
--sysroot=/workdir/bsl/build-poky/tmp-poky/work/raspberrypi3_64-poky-linux/linux-raspberrypi/1_4.
9.41+gitAUTOINC+4153f509b4-r0/recipe-sysroot LOADADDR=0x8000
| make[2]: *** No rule to make target 'uImage'.  Stop.
| Makefile:150: recipe for target 'sub-make' failed
| make[1]: *** [sub-make] Error 2
| Makefile:24: recipe for target '__sub-make' failed
| make: *** [__sub-make] Error 2
| ERROR: oe_runmake failed
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/workdir/bsl/build-poky/tmp-poky/work/raspberrypi3_64-poky-linux/linux-raspberrypi/1_4.9.41+gitAUTOINC+4153f509b4-r0/temp/log.do_compile.8392)
ERROR: Task
(/workdir/bsl/build-poky/conf/../../layers/meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi_4.9.bb:do_compile)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4764 tasks of which 4763 didn't need to be
rerun and 1 failed.

The only particular 

Re: [yocto] cannot re-use shared state cache between build hosts

[Andrea Galbusera]

On Mon, Sep 4, 2017 at 10:56 AM, Paul Eggleton <
paul.eggle...@linux.intel.com> wrote:

> On Monday, 4 September 2017 7:59:55 PM NZST Andrea Galbusera wrote:
> > On Mon, Sep 4, 2017 at 9:33 AM, Patrick Ohly <patrick.o...@intel.com>
> wrote:
> > > More recent bitbake should not fail like that anymore. It's still
> > > better to use an HTTP server that performs better, though.
> > >
> > > commit 6fa07752bbd3ac345cd8617da49a70e0b2dd565f
> > > Author: Patrick Ohly <patrick.o...@intel.com>
> > > Date:   Mon Jul 17 15:25:10 2017 +0200
> > >
> > > fetch2/wget.py: improve error handling during sstate check
> > >
> > > When the sstate is accessed via HTTP, the existence check can fail
> due
> > > to network issues, in which case bitbake silently continues without
> > > sstate.
> > >
> > > One such network issue is an HTTP server like Python's own
> SimpleHTTP
> > > which closes the TCP connection despite an explicit "Keep-Alive" in
> > > the HTTP request header. The server does that without a "close" in
> the
> > > HTTP response header, so the socket remains in the connection
> cache,
> > > leading to "urlopen failed:  > > descriptor>" (only visible in "bitbake -D -D" output) when trying
> to
> > > use the cached connection again.
> > >
> > > The connection might also get closed for other reasons (proxy,
> > > timeouts, etc.), so this is something that the client should be
> able
> > > to handle.
> > >
> > > This is achieved by checking for the error, removing the bad
> > > connection, and letting the check_status() method try again with a
> new
> > > connection. It is necessary to let the second attempt fail
> > > permanently, because bad proxy setups have been observed to also
> lead
> > > to such broken connections. In that case, we need to abort for real
> > > after trying twice, otherwise a build would just hang forever.
> > >
> > > [YOCTO #11782]
> > >
> >
> > Thank you Patrick for pointing that out. While debugging the issue on
> morty
> > I had some reminiscence of seeing your patch on the list, but I wasn't
> able
> > to find it back in morty's history hence inferring it landed later on.
> > Anyway doing this test on morty was a requirement... Thanks again for
> your
> > clarification. Would such a patch be suitable for eventually being
> > back-ported to morty?
>
> Doesn't look too invasive to me at least, so I'd support it.
>

I did some positive tests with Patrick's patch on top of morty and it
improves a lot the situation even with SimpleHTTPServer. Than I'd like to
propose it is backported to morty and, after further testing, reasonably
should land in pyro too. But I'm unsure how such a request should be
submitted. Since it affects bitbake, what's the proper way and which list
should I send such a request?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cannot re-use shared state cache between build hosts

[Andrea Galbusera]

On Mon, Sep 4, 2017 at 9:33 AM, Patrick Ohly <patrick.o...@intel.com> wrote:

> On Fri, 2017-09-01 at 17:04 +0200, Andrea Galbusera wrote:
> > Hi Maciej,
> >
> > On Fri, Sep 1, 2017 at 4:08 PM, Maciej Borzęcki <maciej.borzecki@rndi
> > ty.com> wrote:
> > > On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera <giz...@gmail.com>
> > > wrote:
> > > > Hi!
> > > >
> > > > I was trying to share sstate between different hosts, but the
> > > consumer build
> > > > system seems to be unable to use re-use any sstate object. My
> > > scenario is
> > > > setup as follows:
> > > >
> > > > * The cache was populated by a pristine qemux86 core-image-
> > > minimal build of
> > > > morty. This was done in a crops/poky container (running in docker
> > > on Mac)
> > > > * The cache was then served via HTTP
> > >
> > > Make sure that you use a decent HTTP server. Simple `python3 -m
> > > http.server` will quickly choke when the mirror is being checked.
> > > Also
> > > running bitbake -DDD -v makes investigating this much easier.
> >
> > To be honest, the current server was indeed setup with python's
> > SimpleHTTPServer... As you suggest, I checked the verbose debug log
> > and noticed what's happening behind the apparently happy "Checking
> > sstate mirror object availability" step. After a first "SState:
> > Successful fetch test for" that I see correctly served with 200 on
> > the server side, tests for any other sstate object suddenly and
> > systematically fail with logs like this:
> ...
> > DEBUG: checkstatus() urlopen failed:  > file descriptor>
>
> More recent bitbake should not fail like that anymore. It's still
> better to use an HTTP server that performs better, though.
>
> commit 6fa07752bbd3ac345cd8617da49a70e0b2dd565f
> Author: Patrick Ohly <patrick.o...@intel.com>
> Date:   Mon Jul 17 15:25:10 2017 +0200
>
> fetch2/wget.py: improve error handling during sstate check
>
> When the sstate is accessed via HTTP, the existence check can fail due
> to network issues, in which case bitbake silently continues without
> sstate.
>
> One such network issue is an HTTP server like Python's own SimpleHTTP
> which closes the TCP connection despite an explicit "Keep-Alive" in
> the HTTP request header. The server does that without a "close" in the
> HTTP response header, so the socket remains in the connection cache,
> leading to "urlopen failed:  descriptor>" (only visible in "bitbake -D -D" output) when trying to
> use the cached connection again.
>
> The connection might also get closed for other reasons (proxy,
> timeouts, etc.), so this is something that the client should be able
> to handle.
>
> This is achieved by checking for the error, removing the bad
> connection, and letting the check_status() method try again with a new
> connection. It is necessary to let the second attempt fail
> permanently, because bad proxy setups have been observed to also lead
> to such broken connections. In that case, we need to abort for real
> after trying twice, otherwise a build would just hang forever.
>
> [YOCTO #11782]
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>

Thank you Patrick for pointing that out. While debugging the issue on morty
I had some reminiscence of seeing your patch on the list, but I wasn't able
to find it back in morty's history hence inferring it landed later on.
Anyway doing this test on morty was a requirement... Thanks again for your
clarification. Would such a patch be suitable for eventually being
back-ported to morty?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] cannot re-use shared state cache between build hosts

[Andrea Galbusera]

Hi Maciej,

On Fri, Sep 1, 2017 at 4:08 PM, Maciej Borzęcki <maciej.borze...@rndity.com>
wrote:

> On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera <giz...@gmail.com> wrote:
> > Hi!
> >
> > I was trying to share sstate between different hosts, but the consumer
> build
> > system seems to be unable to use re-use any sstate object. My scenario is
> > setup as follows:
> >
> > * The cache was populated by a pristine qemux86 core-image-minimal build
> of
> > morty. This was done in a crops/poky container (running in docker on Mac)
> > * The cache was then served via HTTP
>
> Make sure that you use a decent HTTP server. Simple `python3 -m
> http.server` will quickly choke when the mirror is being checked. Also
> running bitbake -DDD -v makes investigating this much easier.
>

To be honest, the current server was indeed setup with python's
SimpleHTTPServer... As you suggest, I checked the verbose debug log and
noticed what's happening behind the apparently happy "Checking sstate
mirror object availability" step. After a first "SState: Successful fetch
test for" that I see correctly served with 200 on the server side, tests
for any other sstate object suddenly and systematically fail with logs like
this:

DEBUG: SState: Attempting to fetch file://7d/sstate:libxml2:i586-
poky-linux:2.9.4:r0:i586:3:7da8fc3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz
DEBUG: Searching for 7d/sstate:libxml2:i586-poky-linux:2.9.4:r0:i586:3:
7da8fc3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz in paths:
/home/vagrant/koan/morty/build/sstate-cache
DEBUG: Defaulting to /home/vagrant/koan/morty/build/sstate-cache/7d/sstate:
libxml2:i586-poky-linux:2.9.4:r0:i586:3:7da8fc3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz
for 7d/sstate:libxml2:i586-poky-linux:2.9.4:r0:i586:3:7da8fc3f7f5ed0102d23b
db86ac7ab32_package_qa.tgz
DEBUG: Testing URL file://7d/sstate:libxml2:i586-poky-linux:2.9.4:r0:i586:3:
7da8fc3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz
DEBUG: For url ['file', '', '7d/sstate:libxml2:i586-poky-
linux:2.9.4:r0:i586:3:7da8fc3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz', '',
'', OrderedDict()] comparing ['file', '', '.*', '', '', OrderedDict()] to
['http', '192.168.33.1:8000', '
/sstate-cache/PATH', '', '', OrderedDict([('downloadfilename', 'PATH')])]
DEBUG: For url file://7d/sstate:libxml2:i586-poky-linux:2.9.4:r0:i586:3:
7da8fc3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz returning
http://192.168.33.1:8000/sstate-cache/7d/sstate%3Alibxml2%3Ai586-poky-linux%
3A2.9.4%3Ar0%3Ai586%3A3%3A7da8fc
3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz;downloadfilename=7d/sstate:
libxml2:i586-poky-linux:2.9.4:r0:i586:3:7da8fc3f7f5ed0102d23bdb86ac7ab
32_package_qa.tgz
DEBUG: checkstatus: trying again
DEBUG: checkstatus() urlopen failed: 
DEBUG: SState: Unsuccessful fetch test for file://7d/sstate:libxml2:i586-
poky-linux:2.9.4:r0:i586:3:7da8fc3f7f5ed0102d23bdb86ac7ab32_package_qa.tgz

Nothing is reported server-side for any of these failures... As you
recommend, I'll try to setup something more "decent" for the HTTP server
and see if it helps.



> > * The second host is a VM running Ubuntu 16.04 where I set
> SSTATE_MIRRORS to
> > point to the hosted sstate cache like this:
> >
> > SSTATE_MIRRORS ?= "\
> > file://.* http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename=
> PATH"
> >
> > * I checked with curl that the VM can successfully get sstate objects
> from
> > the server.
> > * Then I start a new build (same metadata revisions, default
> configuration
> > for core-image-minimal) and each and every task run from scratch with no
> > sstate cache re-use.
> >
> > Here are the two configurations from bitbake and /etc/lsb-release files:
> >
> > On the container used to seed sstate cache:
> >
> > Build Configuration:
> > BB_VERSION= "1.32.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "universal"
> > TARGET_SYS= "i586-poky-linux"
> > MACHINE   = "qemux86"
> > DISTRO= "poky"
> > DISTRO_VERSION= "2.2.2"
> > TUNE_FEATURES = "m32 i586"
> > TARGET_FPU= ""
> > meta
> > meta-poky
> > meta-yocto-bsp= "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128"
> >
> > $ cat /etc/lsb-release
> > DISTRIB_ID=Ubuntu
> > DISTRIB_RELEASE=16.04
> > DISTRIB_CODENAME=xenial
> > DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
> >
> > On the VM that should consume the cache:
> >
> > Build Configuration:
> > BB_VERSION= "1.32.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "Ubuntu-16.04"

Re: [yocto] cannot re-use shared state cache between build hosts

[Andrea Galbusera]

On Fri, Sep 1, 2017 at 3:57 PM, Martin Jansa <martin.ja...@gmail.com> wrote:

> Why do you use:
>
> ";downloadfilename=PATH
> <http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename=PATH>"
>
> ?
>

Most likely because I copy/pasted from local.conf comments. I see the same
syntax on both "morty" [1] and "current" documentation. Shouldn't this be
part of the "keep the same two-character subdirectories layout of the
mirror" thing?

[1]
http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html#var-SSTATE_MIRRORS


> On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera <giz...@gmail.com> wrote:
>
>> Hi!
>>
>> I was trying to share sstate between different hosts, but the consumer
>> build system seems to be unable to use re-use any sstate object. My
>> scenario is setup as follows:
>>
>> * The cache was populated by a pristine qemux86 core-image-minimal build
>> of morty. This was done in a crops/poky container (running in docker on Mac)
>> * The cache was then served via HTTP
>> * The second host is a VM running Ubuntu 16.04 where I set SSTATE_MIRRORS
>> to point to the hosted sstate cache like this:
>>
>> SSTATE_MIRRORS ?= "\
>> file://.* http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename=
>> PATH"
>>
>> * I checked with curl that the VM can successfully get sstate objects
>> from the server.
>> * Then I start a new build (same metadata revisions, default
>> configuration for core-image-minimal) and each and every task run from
>> scratch with no sstate cache re-use.
>>
>> Here are the two configurations from bitbake and /etc/lsb-release files:
>>
>> On the container used to seed sstate cache:
>>
>> Build Configuration:
>> BB_VERSION= "1.32.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING   = "universal"
>> TARGET_SYS= "i586-poky-linux"
>> MACHINE   = "qemux86"
>> DISTRO= "poky"
>> DISTRO_VERSION= "2.2.2"
>> TUNE_FEATURES = "m32 i586"
>> TARGET_FPU= ""
>> meta
>> meta-poky
>> meta-yocto-bsp= "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128"
>>
>> $ cat /etc/lsb-release
>> DISTRIB_ID=Ubuntu
>> DISTRIB_RELEASE=16.04
>> DISTRIB_CODENAME=xenial
>> DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
>>
>> On the VM that should consume the cache:
>>
>> Build Configuration:
>> BB_VERSION= "1.32.0"
>> BUILD_SYS = "x86_64-linux"
>> NATIVELSBSTRING   = "Ubuntu-16.04"
>> TARGET_SYS= "i586-poky-linux"
>> MACHINE   = "qemux86"
>> DISTRO= "poky"
>> DISTRO_VERSION= "2.2.2"
>> TUNE_FEATURES = "m32 i586"
>> TARGET_FPU= ""
>> meta
>> meta-poky
>> meta-yocto-bsp= "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128"
>>
>> $ cat /etc/lsb-release
>> DISTRIB_ID=Ubuntu
>> DISTRIB_RELEASE=16.04
>> DISTRIB_CODENAME=xenial
>> DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"
>>
>>
>> To me, the only differing bit that in my understanding can lead to sstate
>> cache objects invalidation is the value of NATIVELSBSTRING which is
>> "universal" inside the container and "Ubuntu-16.04". This sounds strange to
>> me, since both underlying systems are Ubuntu 16.04 (although not exactly
>> the same dot release) as confirmed by /etc/lsb-release contents.
>>
>> Is the different NATIVELSBSTRING the root cause for everything being
>> re-built? If so, what's causing them being different in the end and what
>> does "universal" exactly mean (to me it looks like a more generic and
>> incluse term than any distro label, so I'm confused...)?
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] cannot re-use shared state cache between build hosts

[Andrea Galbusera]

Hi!

I was trying to share sstate between different hosts, but the consumer
build system seems to be unable to use re-use any sstate object. My
scenario is setup as follows:

* The cache was populated by a pristine qemux86 core-image-minimal build of
morty. This was done in a crops/poky container (running in docker on Mac)
* The cache was then served via HTTP
* The second host is a VM running Ubuntu 16.04 where I set SSTATE_MIRRORS
to point to the hosted sstate cache like this:

SSTATE_MIRRORS ?= "\
file://.* http://192.168.33.1:8000/sstate-cache/PATH;downloadfilename=PATH;

* I checked with curl that the VM can successfully get sstate objects from
the server.
* Then I start a new build (same metadata revisions, default configuration
for core-image-minimal) and each and every task run from scratch with no
sstate cache re-use.

Here are the two configurations from bitbake and /etc/lsb-release files:

On the container used to seed sstate cache:

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal"
TARGET_SYS= "i586-poky-linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "2.2.2"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128"

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"

On the VM that should consume the cache:

Build Configuration:
BB_VERSION= "1.32.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-16.04"
TARGET_SYS= "i586-poky-linux"
MACHINE   = "qemux86"
DISTRO= "poky"
DISTRO_VERSION= "2.2.2"
TUNE_FEATURES = "m32 i586"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= "morty:2a70e84643381eca0e7bf7928d4a3d56f9651128"

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.3 LTS"


To me, the only differing bit that in my understanding can lead to sstate
cache objects invalidation is the value of NATIVELSBSTRING which is
"universal" inside the container and "Ubuntu-16.04". This sounds strange to
me, since both underlying systems are Ubuntu 16.04 (although not exactly
the same dot release) as confirmed by /etc/lsb-release contents.

Is the different NATIVELSBSTRING the root cause for everything being
re-built? If so, what's causing them being different in the end and what
does "universal" exactly mean (to me it looks like a more generic and
incluse term than any distro label, so I'm confused...)?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [yocto-docs][PATCH] kernel-dev: fix typo

[Andrea Galbusera]

On Sun, Aug 13, 2017 at 4:29 PM, Andrea Galbusera <giz...@gmail.com> wrote:

> Signed-off-by: Andrea Galbusera <giz...@gmail.com>
> ---
>  documentation/kernel-dev/kernel-dev-advanced.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml
> b/documentation/kernel-dev/kernel-dev-advanced.xml
> index 0394e08..c7e5a3a 100644
> --- a/documentation/kernel-dev/kernel-dev-advanced.xml
> +++ b/documentation/kernel-dev/kernel-dev-advanced.xml
> @@ -867,7 +867,7 @@
>  When stored outside of the recipe-space, the kernel Metadata
>  files reside in a separate repository.
>  The OpenEmbedded build system adds the Metadata to the build
> as
> -a "ktype=meta" repository through the
> +a "type=kmeta" repository through the
>  SRC_URI
>  variable.
>  As an example, consider the following
> SRC_URI
> --
> 2.7.4
>
>
ping...

Just to check I'm not mistakenly using the wrong list/subject/workflow...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] why do we get do_configure() fuction fail

[Andrea Galbusera]

Il 18 ago 2017 7:24 AM, "mohammed aqdam"  ha
scritto:

root@pcz-ee207837-2:/u/my_poky/poky-2/poky/build# bitbake -k rpi-basic-image
Loading cache: 100%
|###
##|
Time: 0:00:01
Loaded 2716 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "universal-4.8"
TARGET_SYS= "arm-poky-linux-gnueabi"
MACHINE   = "raspberrypi3"
DISTRO= "poky"
DISTRO_VERSION= "2.3.1"
TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
callconvention-hard cortexa7"
TARGET_FPU= "hard"
meta
meta-poky
meta-yocto-bsp= "pyro:4a39979c8d1e560fa54240e99734a651dfbaa63a"
meta-raspberrypi  = "pyro:8ba2d6fc80b31c87d25c87c863e2a77752b07c3c"
meta-oe
meta-multimedia
meta-networking
meta-python   = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"

NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 2876 of 4136
(virtual:native:/u/my_poky/poky-2/poky/meta/recipes-core/
coreutils/coreutils_8.26.bb:do_configure)
NOTE: recipe coreutils-native-8.26-r0: task do_configure: Started
ERROR: coreutils-native-8.26-r0 do_configure: configure failed
ERROR: coreutils-native-8.26-r0 do_configure: Function failed:
do_configure (log file is located at
/u/my_poky/poky-2/poky/build/tmp/work/x86_64-linux/
coreutils-native/8.26-r0/temp/log.do_configure.5008)
ERROR: Logfile of failure stored in:
/u/my_poky/poky-2/poky/build/tmp/work/x86_64-linux/
coreutils-native/8.26-r0/temp/log.do_configure.5008
NOTE: recipe coreutils-native-8.26-r0: task do_configure: Failed
ERROR: Task (virtual:native:/u/my_poky/poky-2/poky/meta/recipes-core/
coreutils/coreutils_8.26.bb:do_configure)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4114 tasks of which 4113 didn't need to
be rerun and 1 failed.

why i'm getting this error?
and how to solve this?


What does the mentioned logfile show?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-docs][PATCH] kernel-dev: fix typo

[Andrea Galbusera]

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 documentation/kernel-dev/kernel-dev-advanced.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml 
b/documentation/kernel-dev/kernel-dev-advanced.xml
index 0394e08..c7e5a3a 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -867,7 +867,7 @@
 When stored outside of the recipe-space, the kernel Metadata
 files reside in a separate repository.
 The OpenEmbedded build system adds the Metadata to the build as
-a "ktype=meta" repository through the
+a "type=kmeta" repository through the
 SRC_URI
 variable.
 As an example, consider the following SRC_URI
-- 
2.7.4

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

Re: [yocto] rpi-basic-image-1.0-r0 do_rootfs: Function failed: do_rootfs

[Andrea Galbusera]

On Fri, Aug 11, 2017 at 9:27 AM, mohammed aqdam <mohammedaq...@gmail.com>
wrote:

> thanks for your response.
> I made the reqd changes from the [1] link and added the open embedded
> layer as well and in that layer I found v4l-utils,so hopefully it will work.
> But in order to take pic I need gstreamer and OMXplayer which is present
> in met area so berry pi/recipes-multimedia.now I want yo use this,how
> to add those two utilities to my image?
>

AFAICT omxplayer is part of rpi-test-image, a more feature reach image than
rpi-basic-image: you could try building that instead, or refer to
customising images content on the Yocto Reference Manual if you want to add
it to rpi-basic-image (i.e. by setting IMAGE_INSTALL_append). A simple
search for omxplayer in meta-raspberrypi documentation shows you'd also
need to enable building that specific recipe, since it depends on non-free
libraries. gstreamer is available from poky and meta-raspberrypi only
provides some customisation to that recipe via bbappends. Again, if not
already present in your image it should be possible to add it via the usual
IMAGE_INSTALL_append mechanism.


>
>
> On Aug 10, 2017 10:34 PM, "Andrea Galbusera" <giz...@gmail.com> wrote:
>
>> On Thu, Aug 10, 2017 at 4:06 PM, mohammed aqdam <mohammedaq...@gmail.com>
>> wrote:
>>
>>> Thanks for your response
>>> I did it from scratch and it worked even apt is there but its not
>>> working properly.its giving failed to fork and no installation packages
>>> for all commandshow to fix apt?
>>>
>>
>> Did you try to follow the suggestion to use "package-management" image
>> feature instead? Beside installing the tools like apt, it's going to deploy
>> all related configuration files, like the installed packages database and
>> whatever is needed to have a working package management on the target.
>>
>>
>>> Next I want to enable picamera v2 on rpi3 and use v4l2's api's..so
>>> how to add/enable camera? One more thing do I need to download any camera
>>> related folder and add it to bblayer.conf?
>>>
>>
>> I've never used the picamera myself, but I'd expect you'll need a lot of
>> stuff from kernel support to appropriate device tree overlays and user
>> space tools. A quick skim to meta-raspberrypi documentation showed [1] as a
>> starting point. Also, some v4l related utils can be found in meta-oe which,
>> yes, is one optional "layer" you can add to your bblayer.conf if needed.
>> For searching which layer includes recipes for the software you need,
>> please refer to the OpenEmbedded Layer Index [2]: it should be the most
>> up-to-date source for such a bit.
>>
>> [1] https://github.com/agherzan/meta-raspberrypi/blob/master/doc
>> s/extra-build-config.md#video-camera-support-with-v4l2-drivers
>> [2] https://layers.openembedded.org/layerindex/branch/master/layers/
>>
>>
>>> On Aug 10, 2017 3:04 PM, "Andrea Galbusera" <giz...@gmail.com> wrote:
>>>
>>>> On Thu, Aug 10, 2017 at 10:58 AM, mohammed aqdam <
>>>> mohammedaq...@gmail.com> wrote:
>>>>
>>>>> thanks for your response...
>>>>> How to change my meta-raspberrypi branch to pyro?
>>>>>
>>>>
>>>> Just checkout pyro branch from meta-raspberrypi repo... This is plain
>>>> git, nothing specific to Yocto/OE.
>>>>
>>>>
>>>>> And yeah I'm trying to customize for Debian,and trying to add apt into
>>>>> my kernel using IMAGE_INSTALL_append +=" apt".
>>>>>
>>>>
>>>> If you want to add package management features to your image (which
>>>> rpi-basic-image does not include by default), the supported way is by using
>>>> the "package-management" image feature. This can be enabled either by
>>>> IMAGE_FEATURES += "package-management" in your custom image recipe or by
>>>> extending EXTRA_IMAGE_FEATURES in local.conf. See [1] for best practices on
>>>> enabling additional image features and dig the docs for package-management
>>>> to grasp the advantages of using this approach.
>>>>
>>>> That said, I just run a build with your exact metadata commits and it
>>>> went fine to the end, also resulting in apt-get related files to be in the
>>>> final image rootfs. You might have messed up something while changing your 
>>>> PACKAGE_CLASSES
>>>> value. Have you tried wiping tmp/ and ru

Re: [yocto] extensible SDK build failure

[Andrea Galbusera]

Hi,

On Wed, Aug 2, 2017 at 8:34 PM, RUSSELL PETERSON 
wrote:

> Frustrating in that I can't get the eSDK to fully build. I'm past the issue
> with kernel-devsrc and harfbuzz... but now I see hundreds of messages like
> below. Anyone seen this before? From what I can tell these tasks are being
> executed out of the run queue.  Not all the messages are from cve-check
> but most.
>
> Anyone seen this?
>
Are you using devtool to work on recipes/sources? If so, try to run
'devtool reset -a' before building the eSDK.

>
>
> ERROR: Task attr-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task binutils-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task dbus-glib.do_cve_check attempted to execute unexpectedly
> ERROR: Task libtool-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task fixesproto.do_cve_check attempted to execute unexpectedly
> ERROR: Task bc.do_cve_check attempted to execute unexpectedly
> ERROR: Task lsof.do_cve_check attempted to execute unexpectedly
> ERROR: Task python-setuptools-native.do_cve_check attempted to execute
> unexpectedly
> ERROR: Task libxrandr-native.do_cve_check attempted to execute unexpectedly
> ERROR: Task libpciaccess.do_cve_check attempted to execute unexpectedly
> ERROR: Task xf86driproto.do_cve_check attempted to execute unexpectedly
> ERROR: Task ncurses-native.do_cve_check attempted to execute unexpectedly
>
> On August 1, 2017 at 8:55 PM Russell Peterson 
> wrote:
>
> FYI: For those interested…
>
> Just as a test/workaround I added a harfbuzz_%.bbappend file to my meta
> layer
> and directly set the acpaths variable to the STAGING native directory and
> that
> seems to work fine. Works for now but I will try to come up with a cleaner,
> more generic fix.
>
> acpaths = “-I ${STAGING_DATADIR_NATIVE}/aclocal/“
>
> Regards,
>
> Russell
>
> On Aug 1, 2017, at 5:52 PM, RUSSELL PETERSON 
> wrote:
>
> Thank you for the response, Paul. You were correct that I had the
> TOOLCHAIN_*_TASK variables set in my machine.conf file. I put it into my
> image bb file and things seem far more sane... although I must admit I am
> not 100% sure why it works but I will study it a bit and figure it out.
> Thanks for your help.
>
> I have run into another issue while trying to generate the eSDK in that
> there appears to be an issue with building harfbuzz. From what I can tell,
> this appears to be an issue with the search paths for the autoreconf call.
> The autoreconf tool is finding the pkg.m4 file in the harfbuzz m4 directory
> FIRST and therefore not getting the one in
> harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal which indeed has
> the correct m4_pattern_allow.
>
> Do you think that's a bug or something with my recipe? Seems like I just
> want to reverse the -I options... but I don't know how, exactly.
>
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/
> recipe-sysroot-native/usr/bin/autoconf
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-
> poky-linux/harfbuzz/1.4.1-r0/harfbuzz-1.4.1/m4/
> --include=/scratch/russell/yocto-00dc025f/work/aarch64-
> poky-linux/harfbuzz/1.4.1-r0/recipe-sysroot-native/usr/share/aclocal/
> --force
>
> ../../../autoconf-2.69/lib/autoconf/specific.m4:368:
> AC_USE_SYSTEM_EXTENSIONS is expanded from...
> | configure.ac:22: the top level
> | configure:18902: error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR
> | If this token and others are legitimate, please use m4_pattern_allow.
> | See the Autoconf documentation.
> | autoreconf:
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-linux/harfbuzz/1.4.1-r0/
> recipe-sysroot-native/usr/bin/autoconf
> failed with exit status: 1
> | ERROR: Function failed: do_configure (log file is located at
> /scratch/russell/yocto-00dc025f/work/aarch64-poky-
> linux/harfbuzz/1.4.1-r0/temp/log.do_configure.14956)
>
> On July 31, 2017 at 9:50 AM Paul Eggleton 
> wrote:
>
> Hi Russell,
>
> It looks to me like you have added kernel-devsrc to the TOOLCHAIN_*_TASK
> variable at the global level, which you really don't want to do if you're
> going to be building buildtools-tarball (which eSDK will build as a
> dependency). I'd suggest moving that setting to your image recipe.
>
> Cheers,
> Paul
>
> On Sunday, 30 July 2017 4:22:24 PM CEST Russell Peterson wrote:
>
> Hello, all.
>
> I’m trying to build the eSDK for my platform and I just can’t figure out
> why dnf can’t find kernel-devsrc. It’s there, I added it. The “normal
> SDK” uses it and builds fine. Just no luck with the eSDK.
> Any help out there? Poky is pyro. aarch64 SoC target platform with an
> x86 build host (CentOS 7.3). Basically I just bitbake -c
> do_populate_sdk_ext core-image-full. I do have a linux kernel recipe
> that pulls the kernel from the standard kernel.org 
> repo.
>
> ERROR: buildtools-tarball-1.0-r0 do_populate_sdk: Could not invoke 

[yocto] [meta-raspberrypi][PATCH] sdcard_image-rpi: fix absolute path in vfat symlink

[Andrea Galbusera]

Fix bitbake complaining with:

ERROR: core-image-minimal-1.0-r0 do_image_complete: sstate found an absolute
path symlink [...].vfat pointing at [...].vfat. Please replace this with a
relative link.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 classes/sdcard_image-rpi.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/classes/sdcard_image-rpi.bbclass b/classes/sdcard_image-rpi.bbclass
index 1f75ef7..42753d6 100644
--- a/classes/sdcard_image-rpi.bbclass
+++ b/classes/sdcard_image-rpi.bbclass
@@ -73,7 +73,7 @@ SDIMG = "${IMGDEPLOYDIR}/${IMAGE_NAME}.rootfs.rpi-sdimg"
 FATPAYLOAD ?= ""
 
 # SD card vfat partition image name
-SDIMG_VFAT = "${IMGDEPLOYDIR}/${IMAGE_NAME}.vfat"
+SDIMG_VFAT = "${IMAGE_NAME}.vfat"
 SDIMG_LINK_VFAT = "${IMGDEPLOYDIR}/${IMAGE_LINK_NAME}.vfat"
 
 IMAGE_CMD_rpi-sdimg () {
@@ -152,7 +152,7 @@ IMAGE_CMD_rpi-sdimg () {
 # Deploy vfat partition (for u-boot case only)
 case "${KERNEL_IMAGETYPE}" in
 "uImage")
-cp ${WORKDIR}/boot.img ${SDIMG_VFAT}
+cp ${WORKDIR}/boot.img ${IMGDEPLOYDIR}/${SDIMG_VFAT}
 ln -sf ${SDIMG_VFAT} ${SDIMG_LINK_VFAT}
 ;;
 *)
-- 
2.7.4

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

Re: [yocto] Cross compile recipe cmake

[Andrea Galbusera]

On Thu, Jul 13, 2017 at 10:48 AM, Elmar van Rijnswou <
elmarbla...@hotmail.com> wrote:

> Hello! I've been doing a lot of searching on the internet,but I can't seem
> to find anybody with my problem. I'm trying to add a recipe to my image and
> deliver it straight with the system. Everything goes fine, up until the
> recipe I created links to other libraries. I have dependencies to Qt4. I
> used the hello world example recipe, which I can bitbake successfully. My
> recipe is the following:
>
>
> SUMMARY = "Simple helloworld application"
> SECTION = "examples"
> LICENSE = "Closed"
> SRC_URI = "file://media/traffic/Yocto/src/elva/"
> S = "/media/traffic/Yocto/src/elva/proj/src"
>

it looks like you're trying to build from an "external" source tree. Yocto
does support this with a dedicated class you can inherit (externalsrc). See
[1] for the relevant doc. Maybe it can help solving the issue with cmake...

[1]
http://www.yoctoproject.org/docs/2.3/mega-manual/mega-manual.html#building-software-from-an-external-source


> inherit cmake
> EXTRA_OECMAKE = ""
>
> The problem I'm having now is that, using the generated toolchain, cmake
> is looking at the wrong directories. The rootpath is also crooked when I
> print it out in my cmake project file:
>
> CMAKE_FIND_ROOT_PATH:/media/traffic/Yocto/QorIQ-SDK-V2.0-
> 20160527-yocto/build_ls2080abluebox/tmp/sysroots/ls2080abluebox
> /media/traffic/Yocto/QorIQ-SDK-V2.0-20160527-yocto/build_ls2080abluebox/
> tmp/sysroots/x86_64-linux
>
>
> What am I doing wrong? My target is arm. I can build my image fine without
> the recipe, so I'm thinking that there is a step I'm missing. Also when I
> export the SDK I can see that all the right libraries and findscripts are
> available (in the sysroot). But whenever I change my source, it still looks
> in the sysroot of the host system. Any help would be greatly appreciated!
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] userland: Add missing EGL_CAST defines

[Andrea Galbusera]

Needed by libepoxy

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 .../0015-EGL-glplatform.h-define-EGL_CAST.patch| 32 ++
 recipes-graphics/userland/userland_git.bb  |  1 +
 2 files changed, 33 insertions(+)
 create mode 100644 
recipes-graphics/userland/userland/0015-EGL-glplatform.h-define-EGL_CAST.patch

diff --git 
a/recipes-graphics/userland/userland/0015-EGL-glplatform.h-define-EGL_CAST.patch
 
b/recipes-graphics/userland/userland/0015-EGL-glplatform.h-define-EGL_CAST.patch
new file mode 100644
index 000..5a80a26
--- /dev/null
+++ 
b/recipes-graphics/userland/userland/0015-EGL-glplatform.h-define-EGL_CAST.patch
@@ -0,0 +1,32 @@
+From 382e3b16cbcc09d825540d5bd3e45a2fca4484fe Mon Sep 17 00:00:00 2001
+From: Andrea Galbusera <giz...@gmail.com>
+Date: Fri, 14 Jul 2017 09:52:54 +0200
+Subject: [PATCH] EGL/glplatform.h: define EGL_CAST
+
+C++ / C typecast macros for special EGL handle values: used by libepoxy code
+The definition comes from the updated version of this header in mesa.
+
+Upstream-Status: Pending
+---
+ interface/khronos/include/EGL/eglplatform.h | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/interface/khronos/include/EGL/eglplatform.h 
b/interface/khronos/include/EGL/eglplatform.h
+index 1f7c930..c39d425 100644
+--- a/interface/khronos/include/EGL/eglplatform.h
 b/interface/khronos/include/EGL/eglplatform.h
+@@ -202,4 +202,11 @@ EGLAPI void EGLAPIENTRY 
BEGL_GetDefaultDriverInterfaces(BEGL_DriverInterfaces *i
+ #include "interface/khronos/common/khrn_client_mangle.h"
+ #endif
+ 
++/* C++ / C typecast macros for special EGL handle values */
++#if defined(__cplusplus)
++#define EGL_CAST(type, value) (static_cast(value))
++#else
++#define EGL_CAST(type, value) ((type) (value))
++#endif
++
+ #endif /* __eglplatform_h */
+-- 
+2.7.4
+
diff --git a/recipes-graphics/userland/userland_git.bb 
b/recipes-graphics/userland/userland_git.bb
index 26bbfaf..893fcba 100644
--- a/recipes-graphics/userland/userland_git.bb
+++ b/recipes-graphics/userland/userland_git.bb
@@ -34,6 +34,7 @@ SRC_URI = "\
 file://0012-implement-buffer-wrapping-interface-for-dispmanx.patch \
 file://0013-Implement-triple-buffering-for-wayland.patch \
 file://0014-GLES2-gl2ext.h-Define-GL_R8_EXT-and-GL_RG8_EXT.patch \
+file://0015-EGL-glplatform.h-define-EGL_CAST.patch \
 "
 S = "${WORKDIR}/git"
 
-- 
2.7.4

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

Re: [yocto] [meta-raspberrypi] How to add a own dts file and patch the dts makefile

[Andrea Galbusera]

Hi,

On Fri, Jun 30, 2017 at 3:35 PM,  wrote:

> Hej
>
> It's friday and I have some time to play a bit around. I like to build a
> simple test-adapter using a RPi. I want to connect some of the 40GPIO pins
> with a custom mainboard. For that I like to define the pin behaviour by an
> own dts file.
>
> I created my own dts file (testboard.dts) + a simple patch for
> "arch/arm/boot/dts/Makefile" to add the file.
>
> For adding them into the build-process I am append the kernel build
> (linux-raspberrypi%.bbappend).
>
> Now I have problems bringing them together, because the name of the
> git/source links changes (git -> linux-raspberrypi2-standard-build/source
> ). Maybe some one has an idea?
>
> I put the listings of the files below:
>
> ## linux-raspberrypi%.bbappend ##
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>
> SRC_URI += "file://testboard.dts;subdir=linux-raspberrypi2-standard-
> build/source/arch/arm/boot/dts \
> file://0001-add-testboard-to-makefile.patch \
> "
>

Why aren't you just crafting a patch that does both things? I mean adding
the .dts and changing Makefile in the same patch.


> PACKAGE_ARCH = "raspberrypi2"
>
> KERNEL_DEVICETREE += "testboard.dtb"
> #
>
> ## 0001-add-testboard-to-makefile.patch ##
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
>
> @@ -1,4 +1,8 @@
>  ifeq ($(CONFIG_OF),y)
> +
> +# my own dts files
> +dtb-$(CONFIG_ARCH_BCM2835) += \
> +testboard.dts
>
>  dtb-$(CONFIG_ARCH_BCM2835) += \
>  bcm2708-rpi-b.dtb \
> #
>
> ## testboard.dts ##
> /dts-v1/;
> #include "bcm2836.dtsi"
> #include "bcm2835-rpi.dtsi"
> #include "bcm283x-rpi-smsc9514.dtsi"
> #include "bcm283x-rpi-usb-host.dtsi"
>
> / {
> compatible = "raspberrypi,2-model-b", "brcm,bcm2836";
> model = "RPi test";
>
> memory {
> reg = <0 0x4000>;
> };
>
> leds {
> act {
> gpios = < 47 0>;
> };
>
> pwr {
> label = "PWR";
> gpios = < 35 0>;
> default-state = "keep";
> linux,default-trigger = "default-on";
> };
> };
>
> };
>
>  {
> pinctrl-0 = <  _alt0>;
>
> /* I2S interface */
> i2s_alt0: i2s_alt0 {
> brcm,pins = <18 19 20 21>;
> brcm,function = ;
> status = "disabled";
> };
>
> cord0: cord0 {
> brcm,pins = <5 6 25>;
> brcm,function = ;
> status = "okay";
> };
>
> };
>
>  {
> hpd-gpios = < 46 GPIO_ACTIVE_LOW>;
> status = "disabled";
> };
> #
>
> For that I put a question on stackoverflow:
> https://stackoverflow.com/questions/44702426/how-to-
> setup-an-own-device-tree-for-a-raspberrypi-in-yocto
>
> Regards form Germany!
>
> Stefan
>
> 
> ESA Elektroschaltanlagen Grimma GmbH
> Broner Ring 30
> 04668 Grimma
> Telefon: +49 3437 9211 181 <+49%203437%209211181>
> Telefax: +49 3437 9211 26 <+49%203437%20921126>
> E-Mail: s.jar...@esa-grimma.de
> Internet: www.esa-grimma.de
>
>
> Geschäftsführer:
> Dipl.-Ing. Jörg Gaitzsch
> Jörg Reinker
>
> Sitz der Gesellschaft: Grimma
> Ust.-ID: DE 141784437
> Amtsgericht: Leipzig, HRB 5159
> Steuernummer: 238/108/00755
>
>
> 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 löschen Sie diese
> Nachricht. Das unerlaubte Kopieren 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 or distribution of the material in this e-mail is
> strictly
> forbidden.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] rpi-base: wic: generate entries for u-boot

[Andrea Galbusera]

This commit allow wic generated images to work when we want u-boot to
load the kernel image.

Augment IMAGE_BOOT_FILES with the proper entries when KERNEL_IMAGETYPE
is "uImage". More specifically add u-boot image and boot.scr to deployed files
and give the proper name to the kernel image accordingly.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 conf/machine/include/rpi-base.inc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/conf/machine/include/rpi-base.inc 
b/conf/machine/include/rpi-base.inc
index 4a0ea2a..71bb071 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -83,7 +83,9 @@ def make_dtb_boot_files(d):
 
 IMAGE_BOOT_FILES ?= "bcm2835-bootfiles/* \
  ${@make_dtb_boot_files(d)} \
- ${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE} \
+ ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage', 
'${KERNEL_IMAGETYPE}', '${KERNEL_IMAGETYPE};${SDIMG_KERNELIMAGE}', d)} \
+ ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage', 
'u-boot.bin;${SDIMG_KERNELIMAGE}', '', d)} \
+ ${@bb.utils.contains('KERNEL_IMAGETYPE', 'uImage', 
'boot.scr;boot.scr', '', d)} \
  "
 
 # The kernel image is installed into the FAT32 boot partition and does not need
-- 
2.7.4

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

Re: [yocto] Can Yocto treat layers like an external package?

[Andrea Galbusera]

Il 25 mag 2017 6:12 AM, "Trevor Woerner"  ha scritto:

Hi Yannick,

This is a feature many people have been wanting for a while, but
getting there has been slow. So slow, in fact, that many projects have
simply gone ahead and implemented their own solutions, all of which
are different from each other, making it all that much harder to get
everyone back together to support one idea :-(

As Gary mentions, "repo" is a popular solution. See, for example, how
the Linaro people have done it with their "rpb" distro and associated
setup tools/scripts:

https://github.com/96boards/oe-rpb-manifest

The freescale project was the first such instance I saw (but I can't
say whether they were the first or not):

https://github.com/Freescale/fsl-community-bsp-platform
http://freescale.github.io/#download

Mark Hatle (windriver) has been working on and releasing a tool
they've been using internally for a while:

https://www.openembedded.org/wiki/OEDEM_2016#Windriver_.E2.
80.98setup.E2.80.99_Demo

I'm sure there are better links for Mark's work, but I can't find them
at the moment. Hopefully someone jumps in and fills in the blanks :-)


https://github.com/Wind-River/wr-lx-setup


I'm sure there are other such examples.
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BB Equivalent for %config(noreplace)

[Andrea Galbusera]

On Wed, May 10, 2017 at 3:59 PM, Chris Trobridge  wrote:

> When applying rpm updates generated by yocto, configuration
> files/directories are overwritten with files from the rpm.
>
> My spec file for generating equivalent native packages with rpmbuild
> specifies these files with %config(noreplace) so that this overwriting does
> no occur.
>
> Is it possible to get this information into the rpm files generated by
> yocto?
>

The usual way is to add the configuration files to the CONFFILES variable
in your recipe. This does what you want in a package management system
agnostic way. See [1] for details.

http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-CONFFILES
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] how to apply custom kernel configuration?

[Andrea Galbusera]

Hi!

I was wondering how to apply some extra kernel configuration from a custom
layer via a bbappend. I know that with meta-raspberrypi there exist some
variables you can define in local.conf that will drive how the kernel is
configured: but what about some very specific device driver nobody than me
is interest in? To me it seems it doesn't deserve a dedicated global oe
variable.

Some investigation showed this topic already came up on the list from time
to time in the past (most recently in [1]). To me it looks like there is
some common desire to get rid of the current "magic" carried out by
linux-rpi.inc by moving the linux-raspberrypi recipes into the
configuration fragments style.

In the short term, my question are: how do you guys manage to add your
custom kernel configurations? Do you rely on full blown static defconfigs?
Have you found any reliable way to do "differential" configurations with
the current state of metadata?

In a longer term, I'd really like to help moving towards supporting
configuration fragments for linux-raspberrypi, but I suspect it'd be a too
much hard task for my current understanding of the whole kernel
configuration workflow. Do you know of anyone already working on this or
does anyone have a clear idea of what is needed to get the work done? Some
times ago I tried to resurrect [2], but with no luck, probably due to some
changes that happened in the linux-yocto files in the meanwhile.

Comments from gurus are welcome! ;-)

[1] https://lists.yoctoproject.org/pipermail/yocto/2016-December/033559.html
[2] https://lists.yoctoproject.org/pipermail/yocto/2015-October/027034.html
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Creating a new recipe

[Andrea Galbusera]

On Fri, May 5, 2017 at 4:40 PM, Giuseppe Di Guglielmo <
giuseppe.diguglie...@gmail.com> wrote:

> Hi all,
> I am trying to create a new recipe for Bazel (from Google):
> https://bazel.build/versions/master/docs/install-compile-source.html
>
> The standard compilation flow is relatively simple: "Unzip the archive
> and call bash ./compile.sh; this will create a bazel binary in
> output/bazel. This binary is self-contained, so it can be copied to a
> directory on the PATH (such as /usr/local/bin) or used in-place."
>
> I need some support on how to debug the recipe file that I attach.
>
> In do_compile(), I run bash ./compile.sh. This requires the JAVA_HOME
> variable that I export hard-coded because at the moment I do not know how
> to fetch that path in a recipe. At this point the compile.sh fails and I do
> not know how to debug. Please, can you have a look at it and provide me
> some comments?
>

How does it fail? What is the log from bitbake? Please also provide the
layers configuration that bitbake shows.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Building rpi-test-image for Pi3 64 bit

[Andrea Galbusera]

Il 03 mag 2017 6:19 PM, "Luca Carlon" <carlon.l...@gmail.com> ha scritto:

What I'd like to be able to do is setup is a 64bit system including the
libraries from the userland repo: https://github.com/raspberrypi/userland.
I suspect vc4graphic is something different, isn't it?
But maybe you're right and those libs will never be built, as I see that
according to https://github.com/raspberrypi/userland/pull/347 not
everything builds in userland. In the recipe I however see that the ARM64
macro is defined and so I'm asking myself which libraries are currently
supported and which are not. Anyone who knows?
Thank you!


As far as I know, machine configuration for raspberrypi3-64, at least in
master branch of meta-raspberry does set vc4graphic in MACHINE_FEATURES,
which in turn selects mesa instead of userland exclusively. This is what
the metadata say, and what I recently experimented myself while switching
to 64bit builds. I'm not using graphics, but found convenient to monitor
RPi temperature via vcgencmd tool that comes with userland. Had a recipe of
mine RDEPENDing on userland and found out that this was breaking the 64bit
build. For me it was just a matter of using a different source for
temperature monitoring. In the end, Herve's explanation gives the more
technical background.



Luca

On Wed, May 3, 2017 at 2:35 PM, Khem Raj <raj.k...@gmail.com> wrote:

>
> On Wed, May 3, 2017 at 8:28 AM Luca Carlon <carlon.l...@gmail.com> wrote:
>
>> Hello,
>> thank you for your help. I followed your advice and I'm now able to build
>> rpi-test-image for raspberrypi2 and raspberrypi3. When I try
>> raspberrypi3-64 instead I'm getting a few errors. I fixed one build error,
>> but then I got: https://pastebin.com/pL2mei9s. It seems that those libs
>> were not added to the sysroot for some reason. I think those come from the
>> userspace package probably. As it seems to work for the other machines I'm
>> trying to determine what difference raspberrypi3-64 is introducing but for
>> the moment I'm failing. Any idea what is causing this error? Are you able
>> to build rpi-test-image? rpi-basic-image seems to work but not
>> rpi-test-image, which includes omxplayer and other libs that I need like
>> libEGL, libGLESv2, libopenmax etc...
>>
>> These are my current conf files:
>>
>> https://pastebin.com/LJnRfDUj
>> https://pastebin.com/axt9RLQS
>>
>> Any idea why those libs cannot be found?
>> Thank you!
>> Regards.
>>
>
> I don't know if anyone here has got GUI up with rpi64 using yocto yet
> however you could try to use vc4 graphics drivers by adding "vc4graphic" to
> MACHINE_FEATURES
>
>>
>> Luca
>>
>> On Sat, Apr 29, 2017 at 9:40 AM, Andrea Galbusera <giz...@gmail.com>
>> wrote:
>>
>>> On Sat, Apr 29, 2017 at 2:39 AM, Luca Carlon <carlon.l...@gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>> thank you very much for your advice. It seems I can build both a
>>>> minimal image and rpi-basic-image. I would like to test to see if the Pi is
>>>> able to boot with these images but it seems that the images directory does
>>>> not contain any sdimg file. By reading https://github.com/agherzan/me
>>>> ta-raspberrypi and https://github.com/Nuand/blade
>>>> RF/wiki/Creating-Linux-based-Embedded-System-Images-with-Yocto it
>>>> seems I should find a sdimg file to flash to the sdcard. I suppose this
>>>> image file contains both the boot and rootfs partitions. But it seems I do
>>>> not see this image at all, this is a list of what I can see in
>>>> tmp/deploy/images/raspberrypi3-64: https://pastebin.com/8XsRHzUY. I
>>>> see the rootfs filesystem that I can extract in a partition, but not the
>>>> boot partition the Pi needs. Maybe I'm missing some line in the conf files?
>>>>
>>>
>>> If you are using the local.conf you previously posted, the line:
>>>
>>> IMAGE_FSTYPES = "tar.xz"
>>>
>>> is overriding default configuration from rpi-base.inc in
>>> meta-raspberrypi which is:
>>>
>>> IMAGE_FSTYPES ?= "tar.bz2 ext3 rpi-sdimg"
>>>
>>> You can also consider using wic image format to generate a flashable
>>> image (see Yocto documentation on how to do that).
>>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Redis on Yocto

[Andrea Galbusera]

Hi,

On Wed, May 3, 2017 at 9:21 AM, Pello Heriz <
pello.he...@alumni.mondragon.edu> wrote:

> Hi,
>
> I want to implement Redis in an image that I have created with Yocto
> master branch. What I have understood is that there are some recipes into
> meta-oe layer that support to have Redis in the created image. Anyway, what
> steps do I need to do in order to install/start-up/execute Redis in the
> created image on MPSoC QEMU?
>

As soon as meta-oe is in your conf/bblayers.conf, adding the following line
to your conf/local.conf should be enough to get the server enabled at boot
(at least with systemd as the chosen init system) with default
configuration
from meta-openembedded/meta-oe/recipes-extended/redis/redis/redis.conf in
whatever image you are building.

IMAGE_INSTALL_append = " redis"

You might want to override the default configuration with an appropriate
bbappend in one of your custom layers..
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] Building rpi-test-image for Pi3 64 bit

[Andrea Galbusera]

On Fri, Apr 28, 2017 at 6:01 PM, Luca Carlon  wrote:

> Hello,
> I'm trying to build rpi-test-image for Raspberry Pi 3 64 bit but I'm
> getting this error: https://pastebin.com/rYJ0PL7h. It seems it is looking
> for a file that is not there, and I don't see it in the linux repo either:
> https://github.com/raspberrypi/linux/tree/53460a0a50f3dd5e60266e945d0ac7
> 94ce0eca77/arch/arm64/boot/dts.
>
> The same build seems to succeed for machine raspberrypi2 and raspberrypi3,
> instead. Any idea what I may be doing wrong?
>

Could you please share your layer config and revisions? Up to yesterday, I
built from master (poky and meta-raspberrypi) with no error with
MACHINE=raspberrypi3-64
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi][PATCH] rpi-base: fix make_dtb_boot_files() for raspberrypi3-64

[Andrea Galbusera]

Building the stock wic image for raspberrypi3-64 failed to find dtbs listed in
IMAGE_BOOT_FILES. This patch updates the make_dtb_boot_files() function to
account for dtbs listed in KERNEL_DEVICETREE that do include a path prefix:
this is the case for things like broadcom/bcm2710-rpi-3-b.dtb (the dts dir
layout in the kernel sources is different for arm64). Use the same approach
already used for overlays/ dir. While at it also fix a typo in dtb overlay
code path comments.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 conf/machine/include/rpi-base.inc | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/conf/machine/include/rpi-base.inc 
b/conf/machine/include/rpi-base.inc
index 517d5ba..4a0ea2a 100644
--- a/conf/machine/include/rpi-base.inc
+++ b/conf/machine/include/rpi-base.inc
@@ -61,16 +61,17 @@ def make_dtb_boot_files(d):
 
 def transform(dtb):
 if dtb.endswith('dtb'):
-# eg: bcm2708-rpi-b.dtb has:
+# eg: whatever/bcm2708-rpi-b.dtb has:
 # DEPLOYDIR file: ${KERNEL_IMAGETYPE}-bcm2708-rpi-b.dtb
 # destination: bcm2708-rpi-b.dtb
-src = '{}-{}'.format(imgtyp, dtb)
-dst = dtb
+base = os.path.basename(dtb)
+src = '{}-{}'.format(imgtyp, base)
+dst = base
 return '{};{}'.format(src, dst)
 elif dtb.endswith('dtbo'):
 # overlay dtb:
 # eg: overlays/hifiberry-amp.dtbo has:
-# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbp
+# DEPLOYDIR file: ${KERNEL_IMAGETYPE}-hifiberry-amp.dtbo
 # destination: overlays/hifiberry-amp.dtbo
 base = os.path.basename(dtb)
 src = '{}-{}'.format(imgtyp, base)
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH v2] rpi-config: fix invalid shell variable name

[Andrea Galbusera]

Commit da32aac introduced an invalid shell variable name in do_deploy():
according to bash manpage variable names cannot contain dots. Replace
dot with underscore to fix it.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---

v2: also update README accordingly
Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 README  | 2 +-
 recipes-bsp/bootfiles/rpi-config_git.bb | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/README b/README
index c58bc99..9fdd5eb 100644
--- a/README
+++ b/README
@@ -247,7 +247,7 @@ List of currently supported models:
 If you would like to use the Waveshare "C" 1024×600, 7 inch Capacitive Touch
 Screen LCD, HDMI interface (http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
 Rev 2.1, please set the following in your local.conf
-WAVESHARE_1024X600_C_2.1 = "1"
+WAVESHARE_1024X600_C_2_1 = "1"
 
 3.P. Enable UART
 ===
diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb 
b/recipes-bsp/bootfiles/rpi-config_git.bb
index 8adc938..af55983 100644
--- a/recipes-bsp/bootfiles/rpi-config_git.bb
+++ b/recipes-bsp/bootfiles/rpi-config_git.bb
@@ -112,7 +112,7 @@ do_deploy() {
 fi
 
 # Waveshare "C" 1024x600 7" Rev2.1 IPS capacitive touch 
(http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
-if [ "${WAVESHARE_1024X600_C_2.1}" = "1" ]; then
+if [ "${WAVESHARE_1024X600_C_2_1}" = "1" ]; then
 echo "# Waveshare \"C\" 1024x600 7\" Rev2.1 IPS capacitive touch 
screen" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 echo "max_usb_current=1" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 echo "hdmi_group=2" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
-- 
2.7.4

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

[yocto] [meta-raspberrypi][PATCH] rpi-config: fix invalid shell variable name

[Andrea Galbusera]

Commit da32aac introduced an invalid shell variable name in do_deploy():
according to bash manpage variable names cannot contain dots. Replace
dot with underscore to fix it.

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 recipes-bsp/bootfiles/rpi-config_git.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb 
b/recipes-bsp/bootfiles/rpi-config_git.bb
index 8adc938..af55983 100644
--- a/recipes-bsp/bootfiles/rpi-config_git.bb
+++ b/recipes-bsp/bootfiles/rpi-config_git.bb
@@ -112,7 +112,7 @@ do_deploy() {
 fi
 
 # Waveshare "C" 1024x600 7" Rev2.1 IPS capacitive touch 
(http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
-if [ "${WAVESHARE_1024X600_C_2.1}" = "1" ]; then
+if [ "${WAVESHARE_1024X600_C_2_1}" = "1" ]; then
 echo "# Waveshare \"C\" 1024x600 7\" Rev2.1 IPS capacitive touch 
screen" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 echo "max_usb_current=1" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
 echo "hdmi_group=2" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
-- 
2.7.4

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

Re: [yocto] [meta-raspberrypi][PATCH] rpi-config: waveshare screen support

[Andrea Galbusera]

On Tue, Apr 4, 2017 at 12:17 PM, Andrei Gherzan <and...@gherzan.com> wrote:

> Hi,
>
> On 4 April 2017 09:48:32 BST, Andrea Galbusera <giz...@gmail.com> wrote:
> >On Fri, Mar 24, 2017 at 6:49 PM, Trevor Woerner <twoer...@gmail.com>
> >wrote:
> >
> >> Add support for the Waveshare 1024x600 "C" Rev2.1 7" IPS Capacitive
> >Touch
> >> Screen LCD with HDMI interface:
> >>
> >> http://www.waveshare.com/7inch-HDMI-LCD-C.htm
> >> http://www.waveshare.com/wiki/7inch_HDMI_LCD_(C)
> >>
> >> This product works "out of the box" with the Raspberry Pi. Simply
> >connect
> >> the provided HDMI and USB cables between the two devices. The
> >touch<=>mouse
> >> integration works automatically.
> >>
> >> Tested with a Raspberry Pi 3, with a 32-bit raspberrypi3 build.
> >>
> >> Signed-off-by: Trevor Woerner <twoer...@gmail.com>
> >> ---
> >>  README  | 13 ++---
> >>  recipes-bsp/bootfiles/rpi-config_git.bb | 10 ++
> >>  2 files changed, 20 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/README b/README
> >> index 65a1e5f..c58bc99 100644
> >> --- a/README
> >> +++ b/README
> >> @@ -29,7 +29,8 @@ Contents:
> >>  3.L. Enable SPI bus
> >>  3.M. Enable I2C
> >>  3.N. Enable PiTFT support
> >> -3.O. Enable UART support
> >> +3.O. Misc. display
> >> +3.P. Enable UART support
> >>  4. Extra apps
> >>  4.A. omxplayer
> >>  5. Board Configuration
> >> @@ -241,9 +242,15 @@ List of currently supported models:
> >>  - pitft22
> >>  - pitft28r
> >>
> >> -3.O. Enable UART
> >> -===
> >> +3.O. Misc. display
> >> +==
> >> +If you would like to use the Waveshare "C" 1024×600, 7 inch
> >Capacitive
> >> Touch
> >> +Screen LCD, HDMI interface
> >(http://www.waveshare.com/7inch-HDMI-LCD-C.htm
> >> )
> >> +Rev 2.1, please set the following in your local.conf
> >> +WAVESHARE_1024X600_C_2.1 = "1"
> >>
> >> +3.P. Enable UART
> >> +===
> >>  RaspberryPi 1, 2 and CM will have UART console enabled by default.
> >>
> >>  RaspberryPi 3 does not have the UART enabled by default because this
> >> needs a
> >> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
> >> b/recipes-bsp/bootfiles/rpi-config_git.bb
> >> index 20ec343..8adc938 100644
> >> --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> >> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> >> @@ -110,6 +110,16 @@ do_deploy() {
> >>  echo "# Enable VC4 Graphics" >> ${DEPLOYDIR}/bcm2835-
> >> bootfiles/config.txt
> >>  echo "dtoverlay=vc4-kms-v3d,${VC4_CMA_SIZE}" >>
> >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> >>  fi
> >> +
> >> +# Waveshare "C" 1024x600 7" Rev2.1 IPS capacitive touch (
> >> http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
> >> +if [ "${WAVESHARE_1024X600_C_2.1}" = "1" ]; then
> >> +echo "# Waveshare \"C\" 1024x600 7\" Rev2.1 IPS capacitive
> >touch
> >> screen" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> >> +echo "max_usb_current=1" >> ${DEPLOYDIR}/bcm2835-
> >> bootfiles/config.txt
> >> +echo "hdmi_group=2" >>
> >${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> >> +echo "hdmi_mode=87" >>
> >${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> >> +echo "hdmi_cvt 1024 600 60 6 0 0 0" >> ${DEPLOYDIR}/bcm2835-
> >> bootfiles/config.txt
> >> +echo "hdmi_drive=1" >>
> >${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> >> +fi
> >>  }
> >>
> >>  do_deploy_append_raspberrypi3-64() {
> >> --
> >> 2.12.0.rc1.48.g076c053
> >>
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >
> >
> >After applying this commit the build fails with:
> >
> >ERROR: rpi-config-git-r5 do_deploy: Function failed: do_deploy (log
> >

Re: [yocto] [meta-raspberrypi][PATCH] rpi-config: waveshare screen support

[Andrea Galbusera]

On Fri, Mar 24, 2017 at 6:49 PM, Trevor Woerner  wrote:

> Add support for the Waveshare 1024x600 "C" Rev2.1 7" IPS Capacitive Touch
> Screen LCD with HDMI interface:
>
> http://www.waveshare.com/7inch-HDMI-LCD-C.htm
> http://www.waveshare.com/wiki/7inch_HDMI_LCD_(C)
>
> This product works "out of the box" with the Raspberry Pi. Simply connect
> the provided HDMI and USB cables between the two devices. The touch<=>mouse
> integration works automatically.
>
> Tested with a Raspberry Pi 3, with a 32-bit raspberrypi3 build.
>
> Signed-off-by: Trevor Woerner 
> ---
>  README  | 13 ++---
>  recipes-bsp/bootfiles/rpi-config_git.bb | 10 ++
>  2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/README b/README
> index 65a1e5f..c58bc99 100644
> --- a/README
> +++ b/README
> @@ -29,7 +29,8 @@ Contents:
>  3.L. Enable SPI bus
>  3.M. Enable I2C
>  3.N. Enable PiTFT support
> -3.O. Enable UART support
> +3.O. Misc. display
> +3.P. Enable UART support
>  4. Extra apps
>  4.A. omxplayer
>  5. Board Configuration
> @@ -241,9 +242,15 @@ List of currently supported models:
>  - pitft22
>  - pitft28r
>
> -3.O. Enable UART
> -===
> +3.O. Misc. display
> +==
> +If you would like to use the Waveshare "C" 1024×600, 7 inch Capacitive
> Touch
> +Screen LCD, HDMI interface (http://www.waveshare.com/7inch-HDMI-LCD-C.htm
> )
> +Rev 2.1, please set the following in your local.conf
> +WAVESHARE_1024X600_C_2.1 = "1"
>
> +3.P. Enable UART
> +===
>  RaspberryPi 1, 2 and CM will have UART console enabled by default.
>
>  RaspberryPi 3 does not have the UART enabled by default because this
> needs a
> diff --git a/recipes-bsp/bootfiles/rpi-config_git.bb
> b/recipes-bsp/bootfiles/rpi-config_git.bb
> index 20ec343..8adc938 100644
> --- a/recipes-bsp/bootfiles/rpi-config_git.bb
> +++ b/recipes-bsp/bootfiles/rpi-config_git.bb
> @@ -110,6 +110,16 @@ do_deploy() {
>  echo "# Enable VC4 Graphics" >> ${DEPLOYDIR}/bcm2835-
> bootfiles/config.txt
>  echo "dtoverlay=vc4-kms-v3d,${VC4_CMA_SIZE}" >>
> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
>  fi
> +
> +# Waveshare "C" 1024x600 7" Rev2.1 IPS capacitive touch (
> http://www.waveshare.com/7inch-HDMI-LCD-C.htm)
> +if [ "${WAVESHARE_1024X600_C_2.1}" = "1" ]; then
> +echo "# Waveshare \"C\" 1024x600 7\" Rev2.1 IPS capacitive touch
> screen" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +echo "max_usb_current=1" >> ${DEPLOYDIR}/bcm2835-
> bootfiles/config.txt
> +echo "hdmi_group=2" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +echo "hdmi_mode=87" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +echo "hdmi_cvt 1024 600 60 6 0 0 0" >> ${DEPLOYDIR}/bcm2835-
> bootfiles/config.txt
> +echo "hdmi_drive=1" >> ${DEPLOYDIR}/bcm2835-bootfiles/config.txt
> +fi
>  }
>
>  do_deploy_append_raspberrypi3-64() {
> --
> 2.12.0.rc1.48.g076c053
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>


After applying this commit the build fails with:

ERROR: rpi-config-git-r5 do_deploy: Function failed: do_deploy (log file is
located at
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-config/git-r5/temp/log.do_deploy.32154)
ERROR: Logfile of failure stored in:
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-config/git-r5/temp/log.do_deploy.32154
Log data follows:
| DEBUG: Executing python function sstate_task_prefunc
| DEBUG: Removing manifest:
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/deploy/images/raspberrypi3/bcm2835-bootfiles/config.txt
| DEBUG: Removing manifest:
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/deploy/images/raspberrypi3/bcm2835-bootfiles/
| DEBUG: Python function sstate_task_prefunc finished
| DEBUG: Executing shell function do_deploy
|
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-config/git-r5/temp/run.do_deploy.32154:
192:
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-config/git-r5/temp/run.do_deploy.32154:
Bad substitution
| WARNING: exit code 2 from a shell command.
| ERROR: Function failed: do_deploy (log file is located at
/home/gizero/work/smartliving/distro/repo-master/build-poky/tmp/work/raspberrypi3-poky-linux-gnueabi/rpi-config/git-r5/temp/log.do_deploy.32154)
ERROR: Task
(/home/gizero/work/smartliving/distro/repo-master/build-poky/conf/../../layers/meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git.bb:do_deploy)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 4857 tasks of which 4855 didn't need to be
rerun and 1 failed.

Still to look at it 

Re: [yocto] Yocto Dev Day at ELC 2017

[Andrea Galbusera]

On Fri, Mar 3, 2017 at 1:41 AM, Steve Burt <st...@planet.com> wrote:

> The slides are on the wiki:
> https://wiki.yoctoproject.org/wiki/DevDay_US_2017
>
> Hope this helps.
>

Thanks for the link, Steve: appreciated!


>
> On Thu, Mar 2, 2017 at 2:22 AM, Andrea Galbusera <giz...@gmail.com> wrote:
>
>> Hi,
>>
>> I was expecting to find some material from the Dev Day at ELC at [1] as
>> usual. Was it published somewhere else than the usual page?
>>
>> [1] https://www.yoctoproject.org/tools-resources/presentations
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Dev Day at ELC 2017

[Andrea Galbusera]

Hi,

I was expecting to find some material from the Dev Day at ELC at [1] as
usual. Was it published somewhere else than the usual page?

[1] https://www.yoctoproject.org/tools-resources/presentations
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building on MacOS X

[Andrea Galbusera]

On Thu, Jan 12, 2017 at 6:55 PM, Maciej Borzęcki  wrote:

> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>  wrote:
> > You can also build using Docker containers:
> > https://github.com/crops/docker-win-mac-docs/wiki
>
> IIRC docker on mac relies on docker-machine, which in turn spins up a
> virtualbox VM.
>

Not anymore! There's a native implementation [1] but still a linux kernel
around anyway! ;-)

[1]
https://www.docker.com/docker-news-and-press/docker-released-native-mac-and-windows-apps-optimize-developer-experience


>
>
> >
> > On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
> >
> >
> > On 12 January 2017 at 15:14, Roger Smith  wrote:
> >>
> >> Is there any documentation for running the Yocto build system on Mac OS
> X
> >> or macOS as Apple now calls it? I am working with the Intel Aero board.
> >> Before I go down the rabbit hole of fixing issues like this one (and I
> am
> >> using the bash shell), I’d like to know if anyone has build it on os x
> >> before.
> >
> >
> > If you install all of the GNU tools using brew or similar and put them
> first
> > on $PATH then you can get bitbake started.  Then you need to stub out the
> > linux-specific bits in bitbake.  I've previously started on this work
> > already
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
> log/?h=ross/darwin).
> > The next step is figuring out how to configure OE to build and link
> natively
> > on OSX using LLVM instead of GCC.
> >
> > However all of this is mostly academic because in Sierra (iirc) onwards
> > there is tighter security on processes, which means that pseudo won't
> work
> > even if you port it to macOS.
> >
> > So unless you fancy some non-trivial engineering the short version is
> just
> > use something like Docker to run a Linux system on your Mac.
> >
> > Ross
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
>
>
> --
> Maciej Borzecki
> RnDity
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building on MacOS X

[Andrea Galbusera]

On Thu, Jan 12, 2017 at 5:21 PM, Belisko Marek 
wrote:

> On Thu, Jan 12, 2017 at 4:39 PM, Tim Orling
>  wrote:
> > You can also build using Docker containers:
> > https://github.com/crops/docker-win-mac-docs/wiki
> Well the re is other limitation about slow filesystem access from
> docker on osx. There is workaround to use nfs but it's not possible to
> use nfs for building yocto - so it's kind of chicken-egg problem ;)
>

I shortly tested the CROPS docker-based setup after watching some
presentation at ELCE 2016 in Berlin. It basically worked but I experienced
the filesystem slowness your are talking about. I ended up waiting hours to
see a simple core-image-minimal build complete (even after giving more
cores to docker). One more point is that slightly more complex build
scenarios, i.e. building resin.os, also required tweaking docker run
parameters for the build container in order to give bitbake access to
features like loop devices it needed (not always easily debuggable issues
indeed). Turned out I decided to stick with more canonical linux based
environments for the moment.

Anyway, the technology behind CROPS is *very* interesting to me, and I'd
like to hear from people closely involved (Tim?) what the state of the art
is and what we can expect to see in the near future. IIRC, the roadmap for
Yocto 2.3 release was supposed to resurrect the Eclipse plugin and adopt
CROPS as an alternative for running eSDK in a seamless way on different
development host OSs. Beside from the images on docker hub and the github
projects that didn't have high activity in the latest months, I hardly find
discussions and documentation on the whole approach. Isn't this hot enough
anymore or are there big issues that will prevent this technology from
taking off. I often manage SDKs for Windows-minded developers and I
strongly yearn to find a better approach to help them feel at home while
building stuff for OE/Yocto based systems...



> >
> > On Jan 12, 2017, at 7:34 AM, Burton, Ross  wrote:
> >
> >
> > On 12 January 2017 at 15:14, Roger Smith  wrote:
> >>
> >> Is there any documentation for running the Yocto build system on Mac OS
> X
> >> or macOS as Apple now calls it? I am working with the Intel Aero board.
> >> Before I go down the rabbit hole of fixing issues like this one (and I
> am
> >> using the bash shell), I’d like to know if anyone has build it on os x
> >> before.
> >
> >
> > If you install all of the GNU tools using brew or similar and put them
> first
> > on $PATH then you can get bitbake started.  Then you need to stub out the
> > linux-specific bits in bitbake.  I've previously started on this work
> > already
> > (http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/
> log/?h=ross/darwin).
> > The next step is figuring out how to configure OE to build and link
> natively
> > on OSX using LLVM instead of GCC.
> >
> > However all of this is mostly academic because in Sierra (iirc) onwards
> > there is tighter security on processes, which means that pseudo won't
> work
> > even if you port it to macOS.
> >
> > So unless you fancy some non-trivial engineering the short version is
> just
> > use something like Docker to run a Linux system on your Mac.
> >
> > Ross
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
> >
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel config incremental modification not working.

[Andrea Galbusera]

On Fri, Dec 9, 2016 at 5:47 PM, Bruce Ashfield <bruce.ashfi...@windriver.com
> wrote:

> On 2016-12-09 11:17 AM, Andrea Galbusera wrote:
>
>> Hi Bruce,
>>
>> On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield
>> <bruce.ashfi...@windriver.com <mailto:bruce.ashfi...@windriver.com>>
>> wrote:
>>
>> On 2016-12-08 09:06 AM, Bent Bisballe Nyeng wrote:
>>
>> Hi list
>>
>> I am working on a project based on the iMX6UL-EVK using the
>> meta-fsl-arm
>> layer for the kernel.
>> In a local layer I have a bbappend recipe containing a patch for
>> an
>> extra kernel feature (a framebuffer device) in that kernel as
>> well as a
>> .cfg enabling said feature.
>> The bbappend recipe is located in
>> recipes-kernel/linux/linux-fslc-imx_%.bbappend and looks like
>> this:
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> SRC_URI += " \
>> file://0001-mxc-4.1.patch \
>> file://ST7789S.cfg \
>> "
>>
>> KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb"
>>
>> The .cfg is located in
>> recipes-kernel/linux/linux-fslc-imx/ST7789S.cfg
>> and looks like:
>> CONFIG_FB_MXS_ST7789S_QVGA=y
>>
>> The 0001-mxc-4.1.patch patch is correctly applied but the .cfg
>> is either
>> ignored or overwritten by some later buyild step since the
>> resulting
>> .config after kernel compilation contains:
>> # CONFIG_FB_MXS_ST7789S_QVGA is not set
>>
>> I have tried finding the script in the build/.../temp folder
>> that takes
>> care of the .cfg file patching but have not been able to find
>> anything
>> useful.
>>
>> Any hints as to where I should start looking for a solution?
>>
>>
>> Fragment processing using the kernel tools + auditing is only
>> currently
>> available to kernel recipes that use the kernel-yocto bbclass. That
>> opt-in requirement was to ensure that existing recipes and workflows
>> weren't broken by the new features.
>>
>> Last time I checked, the meta-fsl* kernel recipes don't use the
>> kernel-yocto bbclass, so the fragment would be ignored.
>>
>> I'm taking the processing of fragments and making it universally
>> available in the upcoming 2.3 release, so what I just described
>> won't be an issue for much longer.
>>
>> In the mean time, you have a few options:
>>
>>  - in your bbappend, add "inherit kernel-yocto" and the processing
>>of fragments will be enabled (I can't say that I've tested
>>it against that recipe .. but the entire point of the new tasks
>>is that they are transparent/don't break existing worflows)
>>
>>  - carry a defconfig in your layer, and add it to the SRC_URI. That
>>defconfig would be the existing kernel recipe's defconfig + your
>>options
>>
>>
>> I was just testing one of my layers against your recent patchset on
>> kernel-yocto when I noticed this thread. My build is broken by commit
>> 476ffd57cf5b6fba40d4e3f5dd913824ab8a8d3d on oe-core
>> (e38775a1d82e6dc60fc96cf243ecb94be964d9b2 on the poky repo side).
>>
>> WARNING: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
>> do_kernel_metadata: GIZERO: before 'cmp'
>> ERROR: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
>> do_kernel_metadata: Function failed: do_kernel_metadata (log file is
>> located at
>> /scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-
>> poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUT
>> OINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274)
>> ERROR: Logfile of failure stored in:
>> /scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-
>> poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUT
>> OINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274
>> Log data follows:
>> | DEBUG: Executing shell function do_kernel_metadata
>> | WARNING: GIZERO: before 'cmp'
>> |
>> /scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-
>> poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUT
>> OINC+76bdba2700-r0/defconfig
>> /scratch/gizero/mitysom-5csx-master-build/tmp/work-shared/cy
>> clone5/kernel-source/arch/arm/configs/socfpga_defconfig
>> differ: byte 

Re: [yocto] Kernel config incremental modification not working.

[Andrea Galbusera]

Hi Bruce,

On Thu, Dec 8, 2016 at 3:36 PM, Bruce Ashfield  wrote:

> On 2016-12-08 09:06 AM, Bent Bisballe Nyeng wrote:
>
>> Hi list
>>
>> I am working on a project based on the iMX6UL-EVK using the meta-fsl-arm
>> layer for the kernel.
>> In a local layer I have a bbappend recipe containing a patch for an
>> extra kernel feature (a framebuffer device) in that kernel as well as a
>> .cfg enabling said feature.
>> The bbappend recipe is located in
>> recipes-kernel/linux/linux-fslc-imx_%.bbappend and looks like this:
>> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
>>
>> SRC_URI += " \
>> file://0001-mxc-4.1.patch \
>> file://ST7789S.cfg \
>> "
>>
>> KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb"
>>
>> The .cfg is located in recipes-kernel/linux/linux-fslc-imx/ST7789S.cfg
>> and looks like:
>> CONFIG_FB_MXS_ST7789S_QVGA=y
>>
>> The 0001-mxc-4.1.patch patch is correctly applied but the .cfg is either
>> ignored or overwritten by some later buyild step since the resulting
>> .config after kernel compilation contains:
>> # CONFIG_FB_MXS_ST7789S_QVGA is not set
>>
>> I have tried finding the script in the build/.../temp folder that takes
>> care of the .cfg file patching but have not been able to find anything
>> useful.
>>
>> Any hints as to where I should start looking for a solution?
>>
>
> Fragment processing using the kernel tools + auditing is only currently
> available to kernel recipes that use the kernel-yocto bbclass. That
> opt-in requirement was to ensure that existing recipes and workflows
> weren't broken by the new features.
>
> Last time I checked, the meta-fsl* kernel recipes don't use the
> kernel-yocto bbclass, so the fragment would be ignored.
>
> I'm taking the processing of fragments and making it universally
> available in the upcoming 2.3 release, so what I just described
> won't be an issue for much longer.
>
> In the mean time, you have a few options:
>
>  - in your bbappend, add "inherit kernel-yocto" and the processing
>of fragments will be enabled (I can't say that I've tested
>it against that recipe .. but the entire point of the new tasks
>is that they are transparent/don't break existing worflows)
>
>  - carry a defconfig in your layer, and add it to the SRC_URI. That
>defconfig would be the existing kernel recipe's defconfig + your
>options
>

I was just testing one of my layers against your recent patchset on
kernel-yocto when I noticed this thread. My build is broken by commit
476ffd57cf5b6fba40d4e3f5dd913824ab8a8d3d on oe-core
(e38775a1d82e6dc60fc96cf243ecb94be964d9b2 on the poky repo side).

WARNING: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: GIZERO: before 'cmp'
ERROR: linux-altera-ltsi-4.1.22-ltsi+gitAUTOINC+76bdba2700-r0
do_kernel_metadata: Function failed: do_kernel_metadata (log file is
located at
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274)
ERROR: Logfile of failure stored in:
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274
Log data follows:
| DEBUG: Executing shell function do_kernel_metadata
| WARNING: GIZERO: before 'cmp'
|
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/defconfig
/scratch/gizero/mitysom-5csx-master-build/tmp/work-shared/cyclone5/kernel-source/arch/arm/configs/socfpga_defconfig
differ: byte 1525, line 72
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_kernel_metadata (log file is located at
/scratch/gizero/mitysom-5csx-master-build/tmp/work/cyclone5-poky-linux-gnueabi/linux-altera-ltsi/4.1.22-ltsi+gitAUTOINC+76bdba2700-r0/temp/log.do_kernel_metadata.28274)
ERROR: Task
(/home/gizero/work/decos/repo-master/poky/../meta-altera/recipes-kernel/linux/linux-altera-ltsi_4.1.22.bb:do_kernel_metadata)
failed with exit code '1'

The commit in the patch remove the 'set +e' bits, but the following legit
code path expects the cmp command to have a non-zero return value.

if [ -n "${KBUILD_DEFCONFIG}" ]; then
if [ -f "${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}" ];
then
if [ -f "${WORKDIR}/defconfig" ]; then
# If the two defconfig's are different,
warn that we didn't overwrite the
# one already placed in WORKDIR by the
fetcher.
cmp "${WORKDIR}/defconfig"
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"
if [ $? -ne 0 ]; then
bbwarn "defconfig detected in
WORKDIR. ${KBUILD_DEFCONFIG} skipped"
fi

My layer provides a defconfig on top of a bsp layer which
defines 

Re: [yocto] [meta-raspberrypi] Current master broken

[Andrea Galbusera]

On Tue, Dec 6, 2016 at 4:29 PM, Andrei Gherzan  wrote:

> On Mon, Dec 5, 2016 at 4:50 PM, Khem Raj  wrote:
> > On Sun, Dec 4, 2016 at 10:03 PM, Gary Thomas  wrote:
> >> On 2016-12-05 01:54, Andrei Gherzan wrote:
> >>>
> >>> Hi Gary,
> >>>
> >>>
> >>> On Sat, Dec 3, 2016 at 2:16 PM, Paul Barker 
> wrote:
> 
>  On Sat, 3 Dec 2016 08:33:40 +0100
>  Gary Thomas  wrote:
> 
> > I'm currently unable to build for the RaspberryPi-3 using the master
> > branch:
> >
> > Build Configuration:
> > BB_VERSION= "1.32.0"
> > BUILD_SYS = "x86_64-linux"
> > NATIVELSBSTRING   = "universal"
> > TARGET_SYS= "arm-amltd-linux-gnueabi"
> > MACHINE   = "raspberrypi3"
> > DISTRO= "amltd"
> > DISTRO_VERSION= "2.2+snapshot-20161202"
> > TUNE_FEATURES = "arm armv7ve vfp thumb neon vfpv4
> > callconvention-hard cortexa7"
> > TARGET_FPU= "hard"
> > meta  = "master:9e63f81c78e284c9b325fe04a1b59e
> 61c7ad8a1a"
> > meta-amltd= "master:074120ab3a82cea0ac50d4e9eec891
> 30a860a4fa"
> > meta-raspberrypi  = "master:44d41bf3e94c4c8fe5ad5a3650572c
> 8d17ef36c9"
> >
> > Initialising tasks: 100%
> > |#|
> Time:
> > 0:00:00
> > Checking sstate mirror object availability: 100%
> > |#| Time: 0:00:00
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > ERROR: linux-raspberrypi-1_4.4.28+gitAUTOINC+5afda48c34-r0
> > do_kernel_metadata: Function failed: do_kernel_metadata (log
> > file is located at
> >
> > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-
> gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/
> temp/log.do_kernel_metadata.5647)
> > ERROR: Logfile of failure stored in:
> >
> > /build/rpi3_2016-09-13/tmp/work/raspberrypi3-amltd-linux-
> gnueabi/linux-raspberrypi/1_4.4.28+gitAUTOINC+5afda48c34-r0/
> temp/log.do_kernel_metadata.5647
> > Log data follows:
> > | DEBUG: Executing shell function do_kernel_metadata
> > | [ERROR]: processing of file /tmp/tmp.bXPr8PVPz3 failed
> > |
> > /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/
> scc-cmds/patch.cmd:
> > line 29: : No such file or directory
> > |
> > | Context around the error is:
> > |
> > | #
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/
> > | kconf non-hardware
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/
> > | patch
> > "/local/poky-cutting-edge/meta-raspberrypi/recipes-
> kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
> > | # run time: 0 seconds
> > | # processed files:
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> > |
> > | See pre-processed file /tmp/tmp.bXPr8PVPz3 for more details
> > | #
> > | # scc v0.8
> > | # processed: Fri Dec  2 04:12:25 CET 2016
> > | #
> > | # This is a scc output file, do not edit
> > | #
> > | [ERROR]: processing of file /tmp/tmp.eTLAT789Q2 failed
> > | # _reloc_dir
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> > | # _reloc_dir
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/linux
> > |
> > /build/rpi3_2016-09-13/tmp/sysroots/x86_64-linux/usr/bin/
> scc-cmds/patch.cmd:
> > line 29: : No such file or directory
> > |
> > | Context around the error is:
> > |
> > | #
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/
> > | kconf non-hardware
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | prefix
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/
> > | patch
> > "/local/poky-cutting-edge/meta-raspberrypi/recipes-
> kernel/linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch"
> > | # run time: 1 seconds
> > | # processed files:
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi/defconfig
> > | # _cfg
> > /local/poky-cutting-edge/meta-raspberrypi/recipes-kernel/
> linux/linux-raspberrypi-4.4/0001-fix-dtbo-rules.patch
> > |
> > | See pre-processed 

[yocto] [PATCH] ref-manual: fix typo

[Andrea Galbusera]

Signed-off-by: Andrea Galbusera <giz...@gmail.com>
---
 documentation/kernel-dev/kernel-dev-advanced.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/kernel-dev/kernel-dev-advanced.xml 
b/documentation/kernel-dev/kernel-dev-advanced.xml
index 9e15f17..ed982fb 100644
--- a/documentation/kernel-dev/kernel-dev-advanced.xml
+++ b/documentation/kernel-dev/kernel-dev-advanced.xml
@@ -256,7 +256,7 @@
 When stored outside of the recipe-space, the kernel Metadata
 files reside in a separate repository.
 The OpenEmbedded build system adds the Metadata to the build as
-a "ktype=meta" repository through the
+a "type=kmeta" repository through the
 SRC_URI
 variable.
 As an example, consider the following SRC_URI
-- 
1.9.1

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

Re: [yocto] Raspberry pi (version 1) model B+

[Andrea Galbusera]

Hi,

On Thu, Oct 27, 2016 at 1:35 PM, S. M. Anayetullah 
wrote:

> Dear Experts,
> I got the error while running bitbake rpi-basic-image
>
> Loading cache...done.
> Loaded 1361 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION= "1.30.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "universal"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "raspberrypi"
> DISTRO= "poky"
> DISTRO_VERSION= "2.1.1"
> TUNE_FEATURES = "arm armv6  vfp arm1176jzfs callconvention-hard"
> TARGET_FPU= "hard"
> meta
> meta-poky
> meta-yocto-bsp
> meta-raspberrypi  = "krogoth:204b2bae4a5958735fdd19c63a69f4ed3780bba7"
>

Where di you get this layer from? The commit doesn't seems to belong to
meta-raspberrypi repository.


> meta-multimedia   = "fido:902964a4da26e46018d2a8d17dcdda1ac4627a39"
>

Mixing different main branches (krogoth and fido) might hit you with
problems... Any reason for not using the same branch?


>
> NOTE: Preparing RunQueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 2196 of 2202 (ID: 18, /home/anayet/workspace/yocto_
> project/testProj/poky/meta-raspberrypi/recipes-core/images/
> rpi-basic-image.bb, do_image_rpi_sdimg)
> NOTE: recipe rpi-basic-image-1.0-r0: task do_image_rpi_sdimg: Started
> Log data follows:
> | DEBUG: Executing python function set_image_size
> | DEBUG: Python function set_image_size finished
> | DEBUG: Executing shell function do_image_rpi_sdimg
> | Creating filesystem with Boot partition 40960 KiB and RootFS 90112 KiB
> | dd: failed to open '/rpi-basic-image-raspberrypi-
> 20161027061952.rootfs.rpi-sdimg': Permission denied
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_image_rpi_sdimg (log file is located at
> /home/anayet/workspace/yocto_project/testProj/poky/build/
> tmp/work/raspberrypi-poky-linux-gnueabi/rpi-basic-image/
> 1.0-r0/temp/log.do_image_rpi_sdimg.2917)
> NOTE: recipe rpi-basic-image-1.0-r0: task do_image_rpi_sdimg: Failed
> NOTE: Tasks Summary: Attempted 2198 tasks of which 2197 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>   /home/anayet/workspace/yocto_project/testProj/poky/meta-
> raspberrypi/recipes-core/images/rpi-basic-image.bb, do_image_rpi_sdimg
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>
>
> Can anyone tell me what could be the reason?
>
> N.B- I just started learning Yocto.
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libtomcrypt libtomfastmath recipe

[Andrea Galbusera]

Hi Vivek,

Il 20 ott 2016 1:42 PM, "Vivek Per"  ha scritto:
>
> Hi All,
>
> Thank you very much this recipe worked for me.

If it worked, as already suggested by Ross, please consider posting it to
the mailing list for further review and hopefully for merging into meta-oe
or where it belongs best.

Instructions for contributing can be found at
https://github.com/openembedded/meta-openembedded/blob/master/README and in
READMEs from each layer.

>
> Thanks and Regards,
>
>
> On Thu, Oct 20, 2016 at 3:40 AM, Burton, Ross 
wrote:
>>
>> Please considering posting these recipe into meta-oe or similar,
tomcrypt etc comes up every few months.  And posting a recipe to the list
implies you want review, right? :)
>>
>> On 19 October 2016 at 10:12, Markus Volk  wrote:
>>>
>>> DESCRIPTION = "tomcrypt"
>>> HOMEPAGE = " http://www.libtom.net;
>>> LICENSE = "DWTFYW"
>>
>> Second worst license known to man.  :(
>>>
>>> LIC_FILES_CHKSUM =
"file://${S}/LICENSE;md5=71baacc459522324ef3e2b9e052e8180"
>>
>> These URLs are relative to ${S} so just file://LICENSE works.
>>>
>>> SRC_URI = "git://github.com/libtom/libtomcrypt.git;branch=develop \
>>> "
>>>
>>> SRCREV = "${AUTOREV}"
>>
>> In general it's recommended to use a fixed SHA and then override SRVREV
if you need to for testing/CI/whatever.
>>>
>>> PV = "${SRCPV}"
>>> PR = "1"
>>
>> No need for PR in general.
>>>
>>> S = "${WORKDIR}/git"
>>>
>>> inherit autotools-brokensep
>>
>> Boo.  Is upstream fixable or is it beyond help?
>>>
>>> SRC_URI[md5sum] = "d2f152e4dc83ee4cdb1b4f1a4866fe7f"
>>> SRC_URI[sha256sum] =
"d0ff89397f9a5fd1d13b1cbc419d5d426e14473135515d72bfcb58e5babf5032"
>>
>> No need for SRC_URI if you're using git fetcher.
>>
>> Ross
>
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what other layers make extensive use of "UBOOT_CONFIG[...] = "?

[Andrea Galbusera]

Hi,

On Sat, Jun 25, 2016 at 11:02 AM, Robert P. J. Day
 wrote:
>
>   was looking for docs on proper usage of the UBOOT_CONFIG[sd]
> construct and other variations (doesn't seem to be a lot), and noticed
> that while the meta-fsl-{arm,ppc} layers make extensive use of this
> feature, i don't see much more of that across the other layers i have
> checked out.
>
>   are there any other layers that use the UBOOT_CONFIG[] to any
> extent? thanks.

i.e. meta-altera [1] does... See the machine conf files it provides.

[1] https://github.com/kraj/meta-altera
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] images installing other images and artifacts

[Andrea Galbusera]

Hi!
I'm building an image for a production system, let's call it
'production-image'. All required artifacts (kernel, dtbs, bootloader
and the image itself) are built by the process as expected and
available in tmp/deploy/images. The production machine is configured
to boot from flash.

As a production tool, I use a variation of the final target, the main
difference being it boots from SD card. The image it boots (i.e.
'flasher-image'), runs a tool for flashing SOMs (the hardware is
modular) with the production artifacts.

It would be nice to have a package installed in flasher-image that
provides all the artifacts required by the flasher tool in order to
flash production-image together with other binaries it needs. Having
such a package available through a package feed would simplify future
upgrades of artifacts on potentially many (and distributed) such
flashing stations. Being that package, say
'production-image-mymachine-artifacts' the same or not as the one
providing the flashing tool should not be the real issue here.

I've being reasoning and doing some trial mostly following a couple
approaches. At first I've considered building the package as a sort of
'side-effect' of building production-image itself but it seems like an
awkward idea since image recipes are not designed to build packages. I
then crafted a separate recipe, which depends on 'production-image'
and that I can use to package artifacts. Before trying to refine this
last approach, currently very rough (it uses hardcoded names for all
the artifacts) but somewhat promising, I stopped by to ask for some
community wisdom.

Does anyone know of any custom layer doing something similar to what
I'm looking for? Do you even think this is something
reasonable/feasible with the current tooling? I don't know of any
other part of the build system, other than the wic utility, that's
designed to use artifacts as inputs for further processing.

In the hope I've been clear enough in explaining my needs. TIA for any
clue or suggestions.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] replace udhcpc

[Andrea Galbusera]

Hi,

On Fri, May 9, 2014 at 12:28 PM, Neuer User auslands...@gmx.de wrote:
 Connman is really a problem without documentation. :-(

 I tried it out and first I noticed that it depends on the creation of an
 xuser account. It also needs iptables, so probably can configure these, too.

 I also found that it does not correctly configure the dns entries:

 cat /etc/resolv.conf:
 # Generated by Connection Manager
 nameserver 127.0.0.1
 nameserver ::1

This is in fact a working configuration for the DNS proxy feature that
connman offers built-in. See [1].
I personally went through your same frustration when trying to
understand how connman is supposed to work in order to evaluate its
maturity. Not yet an expert at all, but [2] and [3] gave me a
reasonable bootstrap into connman's main logic. Beside this, git
grepping the source tree is your best friend.
Angstrom distribution, i.e. available on the beaglebone boards is also
a good example of a real connman based system.

 I really would like to understand what it does with these and how I can
 change or modify it's behaviour.

 It's definitely not just when ethernet cable inserted, bring up the
 interface using DHCP.

 I even can't find a config file for connman. Is there one?

Yes, there usually is one for each service handled by connman. See [4]
for details on configuration file format and their default location.
As you can see from previously suggested references, you'll usually
modify configurations by using the connmanctl client tool instead of
editing those files by hand.

[1] http://git.kernel.org/cgit/network/connman/connman.git/tree/README
[2] http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
[3] http://www.ptrackapp.com/apclassys-notes/embedded-linux-using-connma/
[4] 
http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt


 Thanks

 Michael

 Am 08.05.2014 12:27, schrieb Burton, Ross:
 On 8 May 2014 04:58, Neuer User auslands...@gmx.de wrote:
 I had a brief look at connman half a year ago, but that time I was
 unable to find a good documentation about it. Do you have by chance a
 link to some tutorial or at least man entry for the configuration?

 What do you need to configure?  For when ethernet cable inserted,
 bring up the interface using DHCP this is default behaviour and won't
 need any configuring.  connman is sadly under-documented but the IRC
 channel is fairly responsive.

 Ross



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

Re: [yocto] replace udhcpc

[Andrea Galbusera]

Michael,

On Fri, May 9, 2014 at 3:21 PM, Auslands-KV auslands...@gmx.de wrote:
 Thanks a lot. I will look through these links and hope I will understand
 better then :-)

 I hope it works nicely with a read-only rootfs. It seems to write to its
 own config data (which is a strange behaviour).

One of the reasons I started looking at connman was the hope to find a
solution to the hell that comes with runtime configuration of network
connections in embedded systems. What I had to address many and many
time in the past was designing the glue logic sitting between the
application specific way of saying I want eth1 to have this address
instead of add this DNS server and the backend required to deploy
such a new configuration. This usually involved poking with some
configuration file and restarting/signaling a service to pickup the
new configuration.

If I understand it correctly, one of the main goals of connman's
design is to provide a backend functionality for handling
configurations and deploying them all in a standard and well defined
way. This is accomplished by implementing appropriate interfaces
exposed over d-bus. It turns out to allows client application, either
the provided connmanctl client or your application specific
configuration frontend, to interact with the low-level configuration
engine, connman daemon, which support plugins for different connection
technologies specific needs.

So, yes, in my understanding, connman manages its own configuration
files. You're supposed to interact with it at an higher level, through
methods calls over d-bus: this allows, amongst other things, multiple
applications to interact with connman in a safe and controlled way. I
guess the design got highly inspired by network configuration tools
included in modern Linux distros and the way they work, GNOME's
networkmanager being probably one of them. Connman brings all this to
the embedded by making it a little bit more lightweight and modular.
Anyway, quite far from classic write myriads of format-heterogeneous
config files and fire up some hacked script for reconfiguration.

Read-only filesystem shouldn't be a problem itself. I guess you can
configure connman to have its own configuration files placed on a
tmpfs or similar. Of course, if you need to change configurations at
runtime and persistency is required, you probably still need some
writable filesystem. But this would be so, even without connman!

 Do you by chance know, why it depends on the xuser-account package? I
 don't want any additional user accounts on my system. If it is not
 essential I would remove it.

I'd guess depending on xuser-account grants providing the correct
d-bus permissions for interacting with connman to processes which run
under a GUI session (non-root). IMHO this RDEPEND should be somewhat
conditional to X being enabled on your distro/image. I couldn't find
any explicit reference to xuser in connman source code... Maybe
someone more expert than me on the list can give a better explanation.


 Thanks

 Michael

 Am 09.05.2014 15:06, schrieb Andrea Galbusera:
 Hi,

 On Fri, May 9, 2014 at 12:28 PM, Neuer User auslands...@gmx.de wrote:
 Connman is really a problem without documentation. :-(

 I tried it out and first I noticed that it depends on the creation of an
 xuser account. It also needs iptables, so probably can configure these, too.

 I also found that it does not correctly configure the dns entries:

 cat /etc/resolv.conf:
 # Generated by Connection Manager
 nameserver 127.0.0.1
 nameserver ::1
 This is in fact a working configuration for the DNS proxy feature that
 connman offers built-in. See [1].
 I personally went through your same frustration when trying to
 understand how connman is supposed to work in order to evaluate its
 maturity. Not yet an expert at all, but [2] and [3] gave me a
 reasonable bootstrap into connman's main logic. Beside this, git
 grepping the source tree is your best friend.
 Angstrom distribution, i.e. available on the beaglebone boards is also
 a good example of a real connman based system.

 I really would like to understand what it does with these and how I can
 change or modify it's behaviour.

 It's definitely not just when ethernet cable inserted, bring up the
 interface using DHCP.

 I even can't find a config file for connman. Is there one?
 Yes, there usually is one for each service handled by connman. See [4]
 for details on configuration file format and their default location.
 As you can see from previously suggested references, you'll usually
 modify configurations by using the connmanctl client tool instead of
 editing those files by hand.

 [1] http://git.kernel.org/cgit/network/connman/connman.git/tree/README
 [2] 
 http://derekmolloy.ie/set-ip-address-to-be-static-on-the-beaglebone-black/
 [3] http://www.ptrackapp.com/apclassys-notes/embedded-linux-using-connma/
 [4] 
 http://git.kernel.org/cgit/network/connman/connman.git/tree/doc/config-format.txt

 Thanks

 Michael

 Am 08.05.2014

Re: [yocto] ADT: understanding YOCTOADT_TARGET_MACHINE_arch

[Andrea Galbusera]

Hi Jonathan,

On Wed, Mar 12, 2014 at 7:08 PM, Jonathan Austin
jonathan.aus...@arm.com wrote:
 Hi list,

 I've been looking at the ADT, and specifically building a custom SDK/ADT for
 a particular board...

 This is an ARM board, so I thought I'd set:
 YOCTOADT_TARGET_MACHINE_arm=myboard

 Sadly, that doesn't work. I'm trying to understand why.

 Despite changing YOCTOADT_REPO in my adt_installer.conf, the adt_installer
 fails to find the cross canadian package group for my board...

 Unknown package 'packagegroup-cross-canadian-myboard

 Looking at the log, I see that the installer is still looking on the yocto
 servers for (nativesdk) files. I can see that the nativesdk locations are
 hard-coded in opkg/conf/opkg-sdk-i686.conf - so I guess it isn't surprising
 that it can't find the right board, the Yocto servers know nothing of
 myboard at this stage!

Noticed your unanswered questions only today, while looking for
ADT-related threads on the list: hope this can still be helpful...
Urls in the opkg config files you mention depend upon the value of the
variable ADTREPO in
meta/recipes-devtools/installer/adt-installer_1.0.bb.
Try setting ADTREPO accordingly to your local repo (i.e. in you
local.conf) and bitbake adt-installer again.

Otherwise, adt-installer's recipe sets default to:

ADTREPO ?= http://adtrepo.yoctoproject.org/${SDK_VERSION};


 Seeing those hardcoded paths made me wonder if I was using the
 YOCTOADT_TARGET_MACHINE_arm variable wrong...

 Would it be 'right' to specify just 'arm' here? This is an imx6 board, and
 TARGET_SYS = arm-poky-linux-gnueabi. By my understanding, this will affect
 which toolchain I get, among other things. I'd defintiely like a machine
 specific sysroot, for example[1]

 So - what's the meaning/point of this TARGET_MACHINE_arch option? I see that
 there exists:
 packagegroup-cross-canadian-imx53qsb_1.0-r0_all.ipk

  - so clearly someone's felt the need to use something other than just 'arm'
 here in the past!

 Has anyone else done an ADT for a custom board that uses the ADT
 infrastructure?

 Do you create a detailed overlay to the adt-installer recipe and change
 config, etc?

 It feels a little like I'm missing a step when generating the ADT that tells
 it more important details about what I'm creating - if so, sorry for the
 questions, but please could you point me there?

BTW, did you manage to support developers by providing a custom
adt-insteller for your machine?
I'm also investigating a productive workflow for supporting
application developers with evolving SDKs... Would be nice to share
findings and solutions on the topic.

Regards!


 Thanks

 Jonny

 [1] I think that my images currently have to be called 'core-image-xxx' to
 work with existing ADT scripts, unless I'm missing some config somewhere,
 but that's a different issue that I'll dig into shortly


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

Re: [yocto] anyone building for the arrow sockit eval board?

[Andrea Galbusera]

Hi Robert,
Hi Jack,

On Tue, Jun 4, 2013 at 3:59 PM, Robert P. J. Day rpj...@crashcourse.ca wrote:
 On Tue, 4 Jun 2013, Jack Mitchell wrote:

 The interesting ones in there are meta-altera and meta-linaro; it
 would also be interesting to see if anything else is modified or if
 it is vanilla Yocto. I have a sinking feeling it may not be...
 mainly due to the tightly coupled DT and socfpga implementation with
 the Altera tools.

 Could you post the altera-init script; I would imagine that hides
 the demons ;)

   i've finished adding a couple more things to this page:

 http://www.crashcourse.ca/wiki/index.php/SoCKit_Yocto_bsx_build

 showing a successful build of an altera-image-minimal image, at
 least with respect to the artifacts that show up in the images/
 directory, so that's a good sign (although i haven't boot-tested that
 stuff yet).

   i may spend some time perusing the contents of the meta-altera/
 directory to see how easy it would be to just extract that as a
 separate layer and use stock layers for everything else -- doesn't
 look like it would be hard as i would prefer to use the latest git
 pull content when possible.

 rday

 p.s. i know nothing about the issues involving the combination of the
 device tree and FPGA, but the build process did generate dtb files, so
 maybe it really is self-contained. feel free to follow along with that
 page and see if it all works for you as well.

Just started to poke around with Yocto trees from rocketboards in
these days and Yocto ml archives returned this thread. I'm still
waiting for the real hardware (Altera's EVB) to go hands-on. After
reading Robert's wiki page documenting his tests, I noticed that
poky-socfpga.git also include a dylan-altera branch. I guess this
should bring Altera's stuff to the next Yocto release. Did you try
building against this branch and do you have any boot tests report
also? I did try a build and it worked after applying a trivial fix to
a failing recipe (gatord).

This branch is not referenced yet by official documentation, but it
might be a better bet for starting new developments. I'm also a little
bit concerned by the approach of providing a full 'clone' of the yocto
instead of confining Altera specifics in a dedicated meta-altera layer
only. Did you get any new insight on the topic? Maybe Jack also can
provide new details after attending training days on the topic...

Very curious to road-test the socfpga with Yocto!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to customize a file coming from another recipe?

[Andrea Galbusera]

Hi Brad,

On Wed, Sep 11, 2013 at 10:30 PM, Brad Litterell b...@evidence.com wrote:
 I'm building w/the Arago distribution which contains lighttpd for a web
 server.  I include this in my image as follows:

 IMAGE_INSTALL = packagegroup-core-boot \
 ...
 lighttpd lighttpd-module-cgi lighttpd-module-compress lighttpd-module-expire
 \
 ...
 

 This installs a default configuration file for the service which I now want
 to customize.  What is the recommended way to overwrite or customize files
 in another package?
 Is the best course to create a recipe bbappend for the lighttpd_1.4.31.bb
 file that is being used?  And can I just include a new file with the same
 name in my append and will it overwrite the old one, or do I need to create
 an actual patch file?

In my experience, the suggested approach for packaging and deploying a
custom configuration file in your target rootfs is to define an
override for the corresponding recipe.
The way you do this is slightly different depending upon the Arago
Project your using: from some details you provide, I guess you are
using meta-arago layer on top of Yocto build system and not the old
Arago Project based on OpenEmbedded Classic. If this is not the case
you might have better luck posting this to the arago mailing list.

If this is correct instead, the suggested approach for packaging and
deploying a custom configuration file is to define a .bbappend for
lighttpd recipe i.e. in your own layer. See [1] for more details and
examples on using bbappend files.

[1] 
http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#using-bbappend-files


 Or is it better to create a new separate  recipe that just ships my version
 of the configuration file?

This is not convenient, since it would generate metadata duplication
and a lot of unnecessary maintenance burden when the upstream recipe
gets updated.

 How are conflicts handled when two recipes
 attempt to install the same file?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] software updates on Yocto based systems with limited connectivity

[Andrea Galbusera]

Hi all,

I've recently been faced the need to support an upgrade path for a system
designed with Yocto. The format for packages is currently ipk.

While the system was under development, I was heavily relying on package
feeds and opkg update/upgrade based upgrades. However, once deployed, this
device will have very limited to no connection to the network. Having the
upgrades deployed by an http feed seems to be a no-option here. Also, every
update should be better delivered in a single file for convenience.

My first approach to the problem, which I'm currently experimenting with,
is to find a suitable way to deliver onto the device whatever is required
to keep going with the opkg update/upgrade logic.
Basically, I'm trying to give the device a filesystem based feed. This can
be deployed as a self-extracting script whose main purpose is to deliver
the usual feed content and to provide a shell script running the usual opkg
update/upgrade recipe. Such an approach would meet the requirement of
delivering a single file, i.e. by uploading it to the system's web
interface.

Now, the most challenging issue I see in moving this solution from an
experimental to a real-world one is that upgrades should be as small as
possible for the sake of efficiency. This will probably involve generating
some sort of differential package feed, say between two know hashes of
the system project's metadata. This would allow to only deliver the
required packages: basically those that need to be upgraded, any possibly
changed dependency and, maybe, any additional package that might be
required to instal during the update.

Here comes the question. Is there any effort for solving this or similar
issues, which I guess are not so uncommon in production environments with
limited connectivity? Since I'm not aware of any, I might be completely out
of luck with the described approach.

If you have any experience to share in delivering in-field updates, I'd be
very pleased to learn from your comments or suggestions.

Regards,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] AUTOREVing with legacy recipe fetching from cvs

[Andrea Galbusera]

In a custom layer I maintain, which is based on Yocto denzil, there is
a recipe that fetches sources from a cvs repository. Since there is
still some development of such a software, for testing reasons, I need
to be able to automate the generation of an image with the latest
revision of a given branch of such a repository (say a nightly build).

After reading the manual I understand that the ${AUTOREV} method is
not working with cvs. Is there an alternative approach to instruct the
fetcher to always perform an update/checkout from the repository?

At moment I can force re-fetching and re-building with:

bitbake -c cleansstate myrecipe  bitbake myrecipe

but I'm looking for a cleaner approach, if it does exist. The goal
being to simply run:

bitbake myimage

...and get the latest myrecipe sources fetched from cvs.

TIA,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH] documentation: kernel-concepts: fixed typo

[Andrea Galbusera]

Signed-off-by: Andrea Galbusera giz...@gmail.com
---
 documentation/kernel-manual/kernel-concepts.xml |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/documentation/kernel-manual/kernel-concepts.xml 
b/documentation/kernel-manual/kernel-concepts.xml
index 8b9e71f..157443d 100644
--- a/documentation/kernel-manual/kernel-concepts.xml
+++ b/documentation/kernel-manual/kernel-concepts.xml
@@ -320,7 +320,7 @@
 Conceptually, configuration of a Yocto Project kernel occurs 
similarly to that needed for any
 Linux kernel.
 The build process for a Yocto Project kernel uses a 
filename.config/filename file, which 
-is created through the Linux Kernel Coinfiguration (LKC) tool.
+is created through the Linux Kernel Configuration (LKC) tool.
 You can directly set various configurations in the 
 filename.config/filename file by using the 
filenamemenuconfig/filename 
 tool as built by BitBake.
-- 
1.7.9.5

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

[yocto] Yocto Project 1.3 beta feedback

[Andrea Galbusera]

Below you can find my answers to the Yocto Project 1.3 beta testing survey.

Regards,
Andrea


Experience survey of using Yocto 1.3

Q: Which architecture did you choose to build?

A: qemuppc, beagleboard

Q: How easily were you able to build an image and boot an image?

A: Quite easily. I also took some time for reviewing the QS guide
which looks adequate to me either for newbies or users coming from
different build systems.

Q: Is there any surprise to you in the process of doing this Beta
testing? If so, would you please describe
it and tell us how you expected it to work?

A: Not really a surprise (already knew about that), but a very
pleasant experience was knotty2. It results cleaner than its
forever-scrolling parent.

Q: How do you like our HOB interface? Please provide us with your
thoughts and suggestions on HOB
interface and functionality.

A: I like the hob design. It actually does not support yet a few
workflows that I consider much important for my work: i.e. adding new
recipes, supporting kernel development (mainly configuration,
patching). I understand not every user does require them and hence I
don't consider myself as the actual hob's average target user. Anyway
I appreciate the project is working on more intuitive tools like HOB
and I look forward to see if similar effort will also bring us webhob
experience in the future. People doing mainly package integration
would benefit the best from HOB, since they need not to dig into the
build system's details.

Q: Was it easy to find the support you needed to build and boot an image?

A: Procedures for the official emulated target are well documented and
clear enough for the task required by this beta testing. Support for
deploying and booting on reference real-hardware target is a little
bit lacking but a lot of resources and documentation are already
available online and I agree on not duplicating reference material.

Q: Which Bugzilla reports did you submit?

A: None till now. Still investigating on some oddities and discussing
with the team on IRC. Also hit bug #3135, which is already fixed in
master now.

Q: Did you try anything else with Yocto 1.3?

A: Building an SDK and investigating procedures to deploy toolchains,
SDKs and ADTs is one of my primary goals. I built toolchains for the
arm architecture and tested the environment to build a simple C
source. Relocatable SDK is a good improvement in term of flexibility
when deploying for application developers. The beta snapshot does
bring bug #3135, but it's already fixed in master.

Q: What would you like to have in Yocto Project for future releases?

A: Documentation as a whole IMHO should and must improve a bit to make
it more useful for reference. At the design level, I see the team is
working very well, by keeping the documentation in a single place:
this grants us consistency and its really a good point. I still see
some confusion between online documentation, documentation source you
can build from master and the latest online documentation which is
often referenced on the mailing list. However I know that keeping all
the docs up-to-date and consistent is not an easy job.
Needs with respect to documentation do largely depend on the user's
perspective. For instance, if your goal is writing new recipes for
your own layers, you'll ask for a good variables reference and, maybe,
a reasonable checklist with best conventions for keeping metadata
consistent. This is also required if you want to contribute back with
high degree of confidence that your patches will be considered and
reviewed. If, on the other hand, your are more involved in kernel
configuration and customization, your hope is to keep your work as
much as possible integrated with the build system: this will grant you
a closer develop-deploy-test flow by using the same tools will be used
for production. Such a workflow does have documentation but I
personally believe this is a point we can improve a lot.
Yocto Project users do belong to a very heterogeneous base: I see a
great challenge in keeping docs usable by differently focused people!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] meta-toolchain-sdk fails in edison with package_ipk

[Andrea Galbusera]

Hello,
Is there any known problem when building meta-toolchain-sdk target
with PACKAGE_CLASSES = package_ipk ?

I have deterministic failure in do_populate_sdk with latest edison
metadata and default local.conf (other than changing PACKAGE_CLASSES
to ipk).
Don't have a denzil tree at hand, but I'm going to check if this is
reproducible with 1.2 too.

To me it seem the failing task is trying to access host files on my
build system. Here is the first error I can see:

 Installing libtelepathy-dbg (0.3.3-r3) to root...
 Downloading 
 file:/scratch/gizero/edison-build-raid.orig/tmp/deploy/ipk/i586/libtelepathy-dbg_0.3.3-r3_i586.ipk.
 touch: cannot touch `/etc/shells': Permission denied
 mkdir: cannot create directory `/var/lib/opkg/alternatives': Permission denied

Here you can see the full log (few lines stripped to satisfy pastebin
size limits...):

http://pastebin.com/Gim3DacX

Build works when I switch to rpm instead of ipk, but I want ipk for my
target and, at moment, I need to switch back and forth the two formats
when I need to update either my images or my sdk. Is there a smarter
way to stay with rpm for the sdk and with ipk for the target images?

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

Re: [yocto] meta-toolchain-sdk fails in edison with package_ipk

[Andrea Galbusera]

Hi Joshua,

On Thu, May 17, 2012 at 8:01 PM, Joshua Lock j...@linux.intel.com wrote:
 Hello Andrea,


 On 17/05/12 01:21, Andrea Galbusera wrote:

 Hello,
 Is there any known problem when building meta-toolchain-sdk target
 with PACKAGE_CLASSES = package_ipk ?

 I have deterministic failure in do_populate_sdk with latest edison
 metadata and default local.conf (other than changing PACKAGE_CLASSES
 to ipk).
 Don't have a denzil tree at hand, but I'm going to check if this is
 reproducible with 1.2 too.

 To me it seem the failing task is trying to access host files on my
 build system. Here is the first error I can see:

 Installing libtelepathy-dbg (0.3.3-r3) to root...
 Downloading
 file:/scratch/gizero/edison-build-raid.orig/tmp/deploy/ipk/i586/libtelepathy-dbg_0.3.3-r3_i586.ipk.
 touch: cannot touch `/etc/shells': Permission denied
 mkdir: cannot create directory `/var/lib/opkg/alternatives': Permission
 denied


 Here you can see the full log (few lines stripped to satisfy pastebin
 size limits...):

 http://pastebin.com/Gim3DacX

 Build works when I switch to rpm instead of ipk, but I want ipk for my
 target and, at moment, I need to switch back and forth the two formats
 when I need to update either my images or my sdk. Is there a smarter
 way to stay with rpm for the sdk and with ipk for the target images?


 I've discovered that this is fixed in Denzil

Thank you for your investigation! I ran out of time and could not test
with denzil today, but you anticipated results... ;-)

 https://bugzilla.yoctoproject.org/show_bug.cgi?id=1869

 http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=c4de612298266653130dd2e5b8378f62dda77e9f

 I tested here and can report that the issue is resolved with that patch
 applied.

 This patch has been applied to my josh/edison branch of the poky-contrib
 repository and should make it into the main edison branch, and a point
 release, in the near future.

 Thanks for the report,

Glad to hear edison too will benefit of the fix! I noticed another
strange behavior while experimenting with different configurations of
PACKAGE_CLASSES: but I'd prefer repeating my tests before reporting
issues.

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

Re: [yocto] Not booting on BeagleBoard xM 0x2

[Andrea Galbusera]

Hi Tomas,

On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych
tf+lists.yo...@r-finger.com wrote:
 Hi,

 I am trying to get Yocto image built from yesterday's master
 (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of
 BeagleBoard xM, but the kernel panics with:

 - console log start 

 Waiting for root device /dev/mmcblk0p2...
 mmc0: new SDHC card at address 1234
 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro)
  mmcblk0: p1 p2

 VFS: Cannot open root device mmcblk0p2 or unknown-block(179,2)
 Please append a correct root= boot option; here are the available
 partitions:

 b300         3858432 mmcblk0  driver: mmcblk
  b301          120456 mmcblk0p1 ----0mmcblk0p1
  b302         3445942 mmcblk0p2 ----0mmcblk0p2

 VFS: Unable to mount root fs on unknown-block(179,2)
 User configuration error - no valid root filesystem found
 Kernel panic - not syncing: Invalid configuration from end user prevents
 continuing

 -- console log end 

 My guess would be the problem is the card being detected as 'ro' (line
 3), but I do not know why that is (there is no lock switch on mmc cards).

 The card itself is fine, it's the original card that came with the
 board, the original Angstrom demo boots fine from it, and yocto kernel
 2.6.37 also used to boot.

 Tomas

Looks related to the comment I wrote here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892
I have a slightly different failure with yocto 1.2 beta snapshot (same
kernel) but seems related. Needs more investigation.
Anyone else having problem booting on beagleboard xM? Seems something
wrong happened after 1.1 release...

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

Re: [yocto] Not booting on BeagleBoard xM 0x2

[Andrea Galbusera]

Hi Gary,

On Wed, Apr 4, 2012 at 4:10 PM, Gary Thomas g...@mlbassoc.com wrote:
 On 2012-04-04 06:50, Bruce Ashfield wrote:

 On 12-04-04 08:04 AM, Andrea Galbusera wrote:

 Hi Tomas,

 On Wed, Apr 4, 2012 at 12:14 PM, Tomas Frydrych
 tf+lists.yo...@r-finger.com wrote:

 Hi,

 I am trying to get Yocto image built from yesterday's master
 (Linux-3.0.23-yocto-standard) to boot on the NAND-less version of
 BeagleBoard xM, but the kernel panics with:

 - console log start 

 Waiting for root device /dev/mmcblk0p2...
 mmc0: new SDHC card at address 1234
 mmcblk0: mmc0:1234 SA04G 3.67 GiB (ro)
 mmcblk0: p1 p2

 VFS: Cannot open root device mmcblk0p2 or unknown-block(179,2)
 Please append a correct root= boot option; here are the available
 partitions:

 b300 3858432 mmcblk0 driver: mmcblk
 b301 120456 mmcblk0p1 ----0mmcblk0p1
 b302 3445942 mmcblk0p2 ----0mmcblk0p2

 VFS: Unable to mount root fs on unknown-block(179,2)
 User configuration error - no valid root filesystem found
 Kernel panic - not syncing: Invalid configuration from end user prevents
 continuing

 -- console log end 

 My guess would be the problem is the card being detected as 'ro' (line
 3), but I do not know why that is (there is no lock switch on mmc
 cards).

 The card itself is fine, it's the original card that came with the
 board, the original Angstrom demo boots fine from it, and yocto kernel
 2.6.37 also used to boot.

 Tomas


 Looks related to the comment I wrote here:
 https://bugzilla.yoctoproject.org/show_bug.cgi?id=1892
 I have a slightly different failure with yocto 1.2 beta snapshot (same
 kernel) but seems related. Needs more investigation.
 Anyone else having problem booting on beagleboard xM? Seems something
 wrong happened after 1.1 release...


 We are working on several bugs on our reference beagleboard. The problem
 is that my beagleboard died (a horrible painful death) and the other
 boards
 that are directly available to are RevC and they are booting. So things
 are slowed down a bit .. but we are trying to get to the bottom of it,
 as fast as possible.


 Just FYI, it also doesn't boot on my rev-C3 (not xM), albeit with a
 different
 error pattern.  It hangs at this point:

  Waiting for root device /dev/mmcblk0p2...
  mmc0: error -110 whilst initialising SD card

That's exactly the same error I see! Happy to know am not alone...

 Looks like you might need the attached patch?

I'm going to give it a try as soon as I can. Did you already submit it
somewhere?

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

[yocto] 1.2 beta testing report

[Andrea Galbusera]

Experience survey of using Yocto 1.2

Q: Which architecture did you choose to build?

A: qemux86 and beagleboard

Q: How easily were you able to build an image and boot an image?

A: This may be a lightly polarized answer, since my build host was
already setup to work with edison. Anyways building and booting images
for qemux86 was as easy as the Yocto Project Quick Start lets the
reader hope.

Q: Is there any surprise to you in the process of doing this Beta
testing? If so, would you please describe
it and tell us how you expected it to work?

A: The approach to building an image with the new 1.2 version is
reasonably similar (at least the command line terminal based approach)
to the one edison was based upon. So, no particular surprise here.

Q: How do you like our HOB interface? Please provide us with your
thoughts and suggestions on HOB
interface and functionality.

A: It was the first time with HOB for me: heard about it but never
tried before. Looks very promising expecially at simplifying life to
new users. I personaly apprecieted the list of recipes and packages
that gives a more usable overview of what's available for a given
layers setup.

Q: Was it easy to find the support you needed to build and boot an image?

A: Online documentation was enought for this beta testing

Q: Which Bugzilla reports did you submit?

A: None yet. Having some problem booting beagleboard image on real
hardware, but still nvestigating if this is really an issue. But don't
want to be late with the report here.

Q: Did you try anything else with Yocto 1.2?

A: Tried the following bitbake targets for qemux86:
core-image-minimal, core-image-sato, meta-toolchain,
meta-toolchain-sdk, adt-installer, meta-ide-support.

Q: What would you like to have in Yocto Project for future releases?

A:

Regards,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Suspicious warnings while beta testing yocto 1.2

[Andrea Galbusera]

Bruce,

On Fri, Mar 30, 2012 at 7:20 PM, Bruce Ashfield
bruce.ashfi...@windriver.com wrote:
 On 12-03-30 01:18 PM, Andrea Galbusera wrote:

 While beta testing yocto 1.2 I'm building for beagleboard with:

 OE Build Configuration:
 BB_VERSION        = 1.15.1
 TARGET_ARCH       = arm
 TARGET_OS         = linux-gnueabi
 MACHINE           = beagleboard
 DISTRO            = poky
 DISTRO_VERSION    = 1.1+snapshot-20120330
 TUNE_FEATURES     = armv7a vfp neon cortexa8
 TARGET_FPU        = vfp-neon
 meta
 meta-yocto        = unknown:unknown

 I see warnings complaining that some options set by the BSP are not
 valid for the kernel being built. This is the first time I noticed and
 it's confusing me. After some search I find a past conversation where
 it was suggested that warnings like this for a Yocto maintained BSP
 should be considered bugs. Can anyone explain this? Build is
 completing successfully. Not yet tested the kernel on actual hardware.
 Later I will see if something similar also happens in edison not.


 There are a few outstanding items for 1.2 as part of M4 .. one of
 them is squashing the remaining configuration values that are
 causing warnings.

Ok, thanks! Ignoring for now...


 Cheers,

 Bruce


 Here is the log:

 This BSP sets 15 invalid/obsolete kernel options.
 These config options are not offered anywhere within this kernel.
 The full list can be found in your workspace at:

 /home/gizero/Documents/research/yocto-1.2-beta/yp-beta-build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.23+git1+e559129b4a6f39f68b75141096b2d516cf7a7f35_1+fccd4e4041454f16f1e7a25569ec530eaa1bf89e-r4/linux/meta/cfg/yocto/standard/beagleboard/invalid.cfg

 This BSP sets 50 kernel options that are possibly non-hardware related.
 The full list can be found in your workspace at:

 /home/gizero/Documents/research/yocto-1.2-beta/yp-beta-build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.23+git1+e559129b4a6f39f68b75141096b2d516cf7a7f35_1+fccd4e4041454f16f1e7a25569ec530eaa1bf89e-r4/linux/meta/cfg/yocto/standard/beagleboard/specified_non_hdw.cfg

 WARNING: There were 12 hardware options requested that do not
          have a corresponding value present in the final .config file.
          This probably means you aren't getting the config you wanted.
 The full list can be found in your workspace at:

 /home/gizero/Documents/research/yocto-1.2-beta/yp-beta-build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.23+git1+e559129b4a6f39f68b75141096b2d516cf7a7f35_1+fccd4e4041454f16f1e7a25569ec530eaa1bf89e-r4/linux/meta/cfg/yocto/standard/beagleboard/mismatch.cfg

 Waiting a second to make sure you get a chance to see this...

 If useful I can provide the list of options as per given log files.
 ___
 yocto mailing list
 yocto@yoctoproject.org
 https://lists.yoctoproject.org/listinfo/yocto


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

[yocto] Suspicious warnings while beta testing yocto 1.2

[Andrea Galbusera]

While beta testing yocto 1.2 I'm building for beagleboard with:

OE Build Configuration:
BB_VERSION= 1.15.1
TARGET_ARCH   = arm
TARGET_OS = linux-gnueabi
MACHINE   = beagleboard
DISTRO= poky
DISTRO_VERSION= 1.1+snapshot-20120330
TUNE_FEATURES = armv7a vfp neon cortexa8
TARGET_FPU= vfp-neon
meta
meta-yocto= unknown:unknown

I see warnings complaining that some options set by the BSP are not
valid for the kernel being built. This is the first time I noticed and
it's confusing me. After some search I find a past conversation where
it was suggested that warnings like this for a Yocto maintained BSP
should be considered bugs. Can anyone explain this? Build is
completing successfully. Not yet tested the kernel on actual hardware.
Later I will see if something similar also happens in edison not.

Here is the log:

This BSP sets 15 invalid/obsolete kernel options.
These config options are not offered anywhere within this kernel.
The full list can be found in your workspace at:
/home/gizero/Documents/research/yocto-1.2-beta/yp-beta-build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.23+git1+e559129b4a6f39f68b75141096b2d516cf7a7f35_1+fccd4e4041454f16f1e7a25569ec530eaa1bf89e-r4/linux/meta/cfg/yocto/standard/beagleboard/invalid.cfg

This BSP sets 50 kernel options that are possibly non-hardware related.
The full list can be found in your workspace at:
/home/gizero/Documents/research/yocto-1.2-beta/yp-beta-build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.23+git1+e559129b4a6f39f68b75141096b2d516cf7a7f35_1+fccd4e4041454f16f1e7a25569ec530eaa1bf89e-r4/linux/meta/cfg/yocto/standard/beagleboard/specified_non_hdw.cfg

WARNING: There were 12 hardware options requested that do not
 have a corresponding value present in the final .config file.
 This probably means you aren't getting the config you wanted.
The full list can be found in your workspace at:
/home/gizero/Documents/research/yocto-1.2-beta/yp-beta-build/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto-3.0.23+git1+e559129b4a6f39f68b75141096b2d516cf7a7f35_1+fccd4e4041454f16f1e7a25569ec530eaa1bf89e-r4/linux/meta/cfg/yocto/standard/beagleboard/mismatch.cfg

Waiting a second to make sure you get a chance to see this...

If useful I can provide the list of options as per given log files.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] adt-installer: cannot install package autoconf-nativesdk

[Andrea Galbusera]

Hi,
I'm having the following error while trying the adt-installer for the
first time. I'm using current edison git branch and following the ADT
user's guide. The adt_installer tarball was generated inside my Yocto
build tree. The adt_installer.conf I use is basically the default one
(just changed YOCTOADT_TARGET_SYSROOT_LOC_arm to my needs). Here is
the log relevant snip:

Start installing selected native ADT for archs: arm x86...
###
Please note from this point on installation requires sudo password ...
###

Dangling opkg cache folder ///var/lib/opkg detected. Continue
installation will remove the folder!
[ADT_INST] Do you want to continue installation? Please enter Y/N:
Updating opkg...
Downloading http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/Packages.
Updated list of available packages in ///var/lib/opkg/lists/yp-i686-nativesdk.
opkg update process ended...
Installing pseudo nativesdk ...

Installing pseudo-nativesdk (1.1.1-r2) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/pseudo-nativesdk_1.1.1-r2_i686-nativesdk.ipk.
Installing eglibc-nativesdk (2.13-r15+svnr14157) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/eglibc-nativesdk_2.13-r15+svnr14157_i686-nativesdk.ipk.
Configuring eglibc-nativesdk.
Configuring pseudo-nativesdk.
Installing opkg nativesdk ...

Installing opkg-nativesdk (1:0.1.8+svnr625-r2) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/opkg-nativesdk_0.1.8+svnr625-r2_i686-nativesdk.ipk.
Configuring opkg-nativesdk.
Installing pkgconfig nativesdk ...

Installing pkgconfig-nativesdk (0.25-r0) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/pkgconfig-nativesdk_0.25-r0_i686-nativesdk.ipk.
Configuring pkgconfig-nativesdk.
Installing libtool nativesdk ...

Installing libtool-nativesdk (2.4-r2) to root...
Downloading 
http://adtrepo.yoctoproject.org/1.1/adt-ipk/i686-nativesdk/libtool-nativesdk_2.4-r2_i686-nativesdk.ipk.
Configuring libtool-nativesdk.
Installing autoconf nativesdk ...

Unknown package 'autoconf-nativesdk'.
Collected errors:
 * opkg_install_cmd: Cannot install package autoconf-nativesdk.

#
# Meet error(s) when installing Yocto ADT! Please check log file for details.
#


The installer was built against the latest version of its recipe as
per commit c6ec5a0d9e31a1694aba25e2ff76f1c933e556d5,
adt-installer-0.1.8+svnr596-r6. I guess a change was made with commit
de68393270d5455b4861d38cef3f081b9667d25f which requires installing
autoconf/automake-nativesdk but relevant ipks are missing from
http://adtrepo.yoctoproject.org/1.1/adt-ipk/, which is still default
in latest adt_installer.conf.

Am I guessing right? First time digging into the adt_installer so I
might be completely out of track! Is this a known limit if building
adt_installer with latest edison branch? Should I file a bug for this?
If so, what's the best solution right now? Maybe using the edison
original adt_installer from the yocto downloads...

Thanks in advance
Regards,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BeagleBone with meta-ti layer

[Andrea Galbusera]

Hi Jack,

Il giorno 20/feb/2012, alle ore 10:29, Jack Mitchell m...@communistcode.co.uk 
ha scritto:

 On 20/02/12 06:39, Andrea Galbusera wrote:
 Hi,
 
 On Thu, Jan 26, 2012 at 4:38 PM, Brian Hutchinsonb.hutch...@gmail.com  
 wrote:
 I grabbed a bag of chips and a beverage ... watching this thread!  I'm
 right behind you guys so thanks for blazing the trail.  I have other
 TI parts to work with but starting with first BeagleBoard (
 BeagleBone) since that is the reference.
 
 Was this an happy ending story? Where you guys successful in building
 meta-ti layer under Yocto umbrella?
 
 Regards,
 Andrea
 
 It's still in the air at the moment. Texas Instruments are going through a 
 process to abstract meta-ti layer into a pure BSP and cut out all the distro 
 specific features. When this is complete then it will be good to go in Yocto.
 
 If you look at the archives of the meta-ti mailing list there has been 
 extensive discussions on it recently.

Thanks for pointing me to the relevant discussion. I joined meta-ti list too 
now.

Cheers,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] i486sx machine porting from oe-classic

[Andrea Galbusera]

Hi,

In oe-classic there used to be a machine configuration for an i486sx
based machine called vortex86sx. In the past I was successful in
building a running image for such a target. Since I'd like to make a
new system based on vortex, my goal is to leverage the whole Yocto
Project infrastructure and port that old configuration to a BSP layer.
This will save me a lot of time in supporting developers with SDKs and
so.

Since I could not find any BSP based on hardware older than i586 in
recent Yocto trees, I'm concerned about this. Do you know of any
obstacle in doing such a port? I'm mainly interested in building
images with no graphics for that target: core-image-minimal is a
reasonable reference for me.

My plan was to initially lay out a new BSP by following guidelines
from Development Manual and BSP Guide. Then, what I suspect to be a
little trickier for my expertise, is the porting of the original
tune-i486sx.inc file to the current Yocto infrastructure. Is there any
document I can leverage to map the variables defined in the
oe-classic's syntax to the current ones for such a machine
configuration file?

The original i486 tune file was defining the following:

TARGET_ARCH = i486
TARGET_CC_ARCH = -march=i486
PACKAGE_EXTRA_ARCHS = 486sx
BASE_PACKAGE_ARCH = 486sx
FEED_ARCH = ${BASE_PACKAGE_ARCH}

Are they still valid variables? Do I need any more?

Thank you in advance. Regards,
Andrea
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto