Re: [yocto] [meta-ti] Building for AM335x with meta-ti and meta-qt5

[Denys Dmytriyenko]

On Wed, Jul 24, 2019 at 05:53:36PM +, Andy Pont wrote:
> I am trying to build a Yocto (warrior) image for the AM335x using meta-ti
> and meta-qt5 that will render directly to the GPU.  Initially this will be
> for the Beaglebone Black but then ultimately will be for a custom hardware
> platform.
> 
> In broad outline, I think, the software stack needs to look a bit like:
> 
> Qt Application
> QtBase, QtWebEngine, etc.
> Qt-OpenGL
> ti-sgx-ddk
> AM335x GPU
> 
> I have included meta-ti and meta-qt5 into my belayers.conf and added
> ti-sgx-ddk-km, ti-sgx-ddk-um, qtbase and qtwebengine to
> IMAGE_INSTALL_append.  When I try to bitbake core-image-minimal I start to
> get a failure to compile ti-sgx-ddk-km with a number of, what appear to be,
> warnings of the form:
> 
> KBUILD_EXTRA_SYMBOLS=
> | grep: 
> /home/me/Yocto/BeagleBoneBlack/tmp/work-shared/beaglebone/kernel-source/include/linux/amba:
> Is a directory
> | grep: 
> /home/me/Yocto/BeagleBoneBlack/tmp/work-shared/beaglebone/kernel-source/include/linux/avf:
> Is a directory
> 
> It then ultimately appears to give up with:
> 
> | *** Multiarch build: no
> | *** Primary arch:target_armel
> | *** Secondary arch:  none
> | ../config/core.mk:513: $(KERNELDIR)/vmlinux does not exist. Kbuild may
> fail.
> | eurasiacon/build/linux2/toplevel.mk:230:
> eurasiacon/build/linux2/moduledefs/target_armel.mk: No such file or
> directory
> 
> Is there a specific kernel I need to define in local.conf that the GPU
> drivers build against?
> 
> Also, is there any specific configuration I need to do in order to get Qt to
> use the SGX OpenGL drivers?

What's your DISTRO, your MACHINE, TUNES and any other special configs?


> I have had a search on the web but not found anything for recent Yocto
> versions, only very old stuff.

It's been working fine for years, hence no recent discussions. You may want to 
look into TI Processor SDK for AM335x - it's Yocto Project based Arago distro 
that is configured for Qt5-Wayland/Weston-SGX, but has been also tested with 
EGLFS QPA.

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

Re: [yocto] [meta-yocto-bsp][PATCH] beaglebone-yocto: Update u-boot config to match u-boot 19.04

[Denys Dmytriyenko]

On Thu, Apr 11, 2019 at 05:27:25PM +, Alistair Francis wrote:
> Signed-off-by: Alistair Francis 

Acked-by: Denys Dmytriyenko 

[YOCTO #13145]

This was announced at 2019.01:
https://www.mail-archive.com/u-boot@lists.denx.de/msg305424.html

Basically, am335x_boneblack is just a special subset of am335x_evm config, 
created and owned by BeagleBoard.org community. Since it was not migrated to 
use CONFIG_BLK in time for 2019.04 release, I was going to do the same - just 
switch it over to am335x_evm config, which supports all BeagleBone variants 
just fine.


> ---
>  meta-yocto-bsp/conf/machine/beaglebone-yocto.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf 
> b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> index 70d3cfe..bc18ee8 100644
> --- a/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> +++ b/meta-yocto-bsp/conf/machine/beaglebone-yocto.conf
> @@ -32,7 +32,7 @@ KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
>  
>  SPL_BINARY = "MLO"
>  UBOOT_SUFFIX = "img"
> -UBOOT_MACHINE = "am335x_boneblack_config"
> +UBOOT_MACHINE = "am335x_evm_defconfig"
>  UBOOT_ENTRYPOINT = "0x80008000"
>  UBOOT_LOADADDRESS = "0x80008000"
>  
> -- 
> 2.21.0
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] OEDEM in Edinburgh in 2 weeks

[Denys Dmytriyenko]

On Thu, Oct 04, 2018 at 02:42:41PM +0200, Marco Cavallini wrote:
> Il 04/10/2018 14:20, Philip Balister ha scritto:
> >OEDEM is basically full at this time.
> >
> >https://www.openembedded.org/wiki/OEDEM_2018
> >
> >We have had the room rearranged to seat 45 people and I am not sure how
> >we would handle anyone over this. If you know you can't make it, could
> >you please remove your name from the attendee list. We'd like to get a
> >better idea of how many people on the waiting list we can accommodate.
> >There are some long time contributors on the wait list we'd like to get in.
> >
> >Philip
> >
> 
> 
> Hi Philip,
> if I can participate remaining standing, will be a pleasure to leave
> my seat to one of the long time contributors on the wait list ;-)

Marco,

Unfortunately, I don't believe those are seating vs. standing spaces, but 
rather the maximum number of people allowed in the root at the same time, 
limited by a fire marshal for safety...

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

Re: [yocto] [Openembedded-architecture] [RFC] stable branch naming scheme

[Denys Dmytriyenko]

On Fri, Nov 03, 2017 at 09:20:43AM -0700, akuster808 wrote:
> Hello,
> 
> The problem I hope to solve is that a Maintainer can stage changes in
> any branch in the contrib repos making it difficult for folks to track
> their back port requests. The also makes it harder to automate any kind
> of build automation.
> 
> I would like to propose a contrib naming scheme for the stable release
> branches. I am thinking of the following:
> 
> stable/{version}-next or {special char}_stable/{version}-next.
> 
>    "version" is either the code name or numeric like in bitbake.
> 
>    "special char" would be used to have these branches at the top of th
> list, if we wont that.

I like this branch unification!

I know we discussed this at OEDEM and there was some convenience reason given, 
but can we also standardize on the tree? I.e. openembedded-core-contrib vs. 
poky-contrib?


> We can apply this to all OE / Yocto repos that have stable branch
> maintenance process.
> 
> If we standardize on a naming scheme, We can then document this so
> contributers can monitor their requests more easily. The community can
> see what changes are being backport.  This will enable the possibility
> to automate builds, etc. 
> 
> let me know what you think.
> 
> Kind regards,
> 
> Armin
> 
> 
> 
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [PATCH] recipes-support: Add recipe for libgpiod

[Denys Dmytriyenko]

Can libsoc help here? It's in meta-oe, but this libgpiod should be there too...

On Tue, May 09, 2017 at 02:24:18PM -0700, akuster808 wrote:
> Marek,
> 
> There is another mailing list that is geared towards the core
> development and recipes like this that are targeted for the main
> "meta" layer.
> 
> You should resend this patch to: openembedded-c...@lists.openembedded.org.
> 
> regards,
> 
> Armin
> 
> 
> On 05/09/2017 02:10 PM, Marek Belisko wrote:
> >libgpiod - C library and tools for interacting with the linux GPIO
> >character device
> >
> >Since linux 4.8 the GPIO sysfs interface is deprecated.
> >User space should use the character device instead.
> >This library encapsulates the ioctl calls and data structures behind a
> >straightforward API.
> >
> >Signed-off-by: Marek Belisko 
> >---
> >  meta/recipes-support/libgpiod/libgpiod_0.2.bb | 25 
> > +
> >  1 file changed, 25 insertions(+)
> >  create mode 100644 meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >
> >diff --git a/meta/recipes-support/libgpiod/libgpiod_0.2.bb 
> >b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >new file mode 100644
> >index 000..fe2cd80
> >--- /dev/null
> >+++ b/meta/recipes-support/libgpiod/libgpiod_0.2.bb
> >@@ -0,0 +1,25 @@
> >+SUMMARY = "C library and tools for interacting with the linux GPIO 
> >character device"
> >+HOMEPAGE = "https://github.com/brgl/libgpiod";
> >+
> >+LICENSE = "LGPLv2.1+"
> >+LIC_FILES_CHKSUM = "file://COPYING;md5=2caced0b25dfefd4c601d92bd15116de"
> >+
> >+UPSTREAM_CHECK_URI = "https://github.com/brgl/libgpiod/releases";
> >+
> >+SRC_URI = "https://github.com/brgl/libgpiod/archive/v${PV}.tar.gz";
> >+
> >+SRC_URI[md5sum] = "e3430f35b6efa842693d659c0bfb7ad5"
> >+SRC_URI[sha256sum] = 
> >"de1947f3cb2cc4174364af430309fe6238976658575655bdbd76c60cffa7df92"
> >+
> >+inherit autotools pkgconfig
> >+
> >+# enable tools
> >+PACKAGECONFIG ?= "tools"
> >+
> >+PACKAGECONFIG[tests] = "--enable-tests,--disable-tests,kmod udev"
> >+PACKAGECONFIG[tools] = "--enable-tools,--disable-tools,"
> >+
> >+PACKAGES += " ${PN}-tools"
> >+
> >+FILES_${PN} = "${libdir}/*"
> >+FILES_${PN}-tools = "${bindir}/*"
> 
> -- 
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] any YP machines or functionality that still require uImage creation?

[Denys Dmytriyenko]

On Thu, Mar 16, 2017 at 06:58:17AM -0400, Robert P. J. Day wrote:
> 
>   i just noticed that the machine config file for mpc8315e-rdb still
> lists "uImage" as the default image type:
> 
> KERNEL_IMAGETYPE = "uImage"
> IMAGE_BOOT_FILES ?= "u-boot.bin uImage uImage-mpc8315erdb.dtb;dtb"
> 
> is there anything about that target that still *requires* uImage
> creation, as opposed to zImage?
> 
>   given that uImage is considered u-boot's "legacy" format, is there
> any drawback to making zImage the default image type, and letting
> folks drop back to uImage if they choose?
> 
>   put another way, is there anything that currently *ever* requires
> the creation/use of a uImage format?

There are some boot methods/use-cases that only work with uImage. Not sure if 
that's the case with mpc8315e-rdb though...

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

Re: [yocto] Devtool: Script Not found

[Denys Dmytriyenko]

On Fri, Mar 03, 2017 at 10:06:21AM +0530, SatyaNarayana Sampangi wrote:
> Hi Denys,
> 
> I am using linux-ti-staging 4.4,
> 
> zImage--4.4.41+git0+7c580a51af-r22a-beaglebone-20170302194632.bin
> 
> Image: core-image-minimal
> 
> Could you pls clarify where i am going wrong?

Numerous people are reporting 4.4 working for them just fine. Not sure what 
defconfig you are using. Have you tried using am335x-evm machine instead?


> On Fri, Mar 3, 2017 at 4:32 AM, Denys Dmytriyenko  wrote:
> 
> > On Fri, Mar 03, 2017 at 02:31:42AM +0530, SatyaNarayana Sampangi wrote:
> > > Hi Denys,
> > >
> > > I build, system with krogoth and meta-ti with both version same, after
> > > running on the beaglebone it is showing like below,
> > >
> > > anything I need to change.
> > >
> > > No lease, forking to background
> > > done.
> > > hwclock: can't open '/dev/misc/rtc': No such file or directory
> > > Starting syslogd/klogd: done
> > > INIT: Id "O0" respawning too fast: disabled for 5 minutes
> > > [   92.942038] random: nonblocking pool is initialized
> > > INIT: Id "O0" respawning too fast: disabled for 5 minutes
> > >
> > > Note: This I did not get in Daisy 1.6 and meta-ti with compatible.
> > >
> > > Could you help me here.
> >
> > Would be nice to understand which kernel and which image you are building
> > and
> > using. The console in recent kernels moved from ttyO to ttyS, although our
> > kernel has fallback mechanism and should still boot with ttyO, hence the
> > question.
> >
> > --
> > Denys
> >
> >
> > > On Thu, Mar 2, 2017 at 10:26 PM, Denys Dmytriyenko 
> > wrote:
> > >
> > > > On Thu, Mar 02, 2017 at 04:19:33PM +, Burton, Ross wrote:
> > > > > On 2 March 2017 at 16:14, SatyaNarayana Sampangi <
> > satya.2...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I am using beagle bone black, for which meta-ti layer and poky
> > versions
> > > > > > compatible is daisy 1.6 as mention in the official website of
> > yocto.
> > > > If I
> > > > > > upgrade the poky to the latest version, then compatibity will be
> > lost.
> > > > Pls
> > > > > > help me out here.
> > > > > >
> > > > >
> > > > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/ has branches for
> > > > krogoth
> > > > > (2.1) and morty (2.2).  Where did you see that 1.6 is the last
> > release
> > > > > supported?
> > > >
> > > > ^^ This is all that matters! The rest is just fluff...
> > > >
> > > > --
> > > > Denys
> > > >
> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Devtool: Script Not found

[Denys Dmytriyenko]

On Fri, Mar 03, 2017 at 02:31:42AM +0530, SatyaNarayana Sampangi wrote:
> Hi Denys,
> 
> I build, system with krogoth and meta-ti with both version same, after
> running on the beaglebone it is showing like below,
> 
> anything I need to change.
> 
> No lease, forking to background
> done.
> hwclock: can't open '/dev/misc/rtc': No such file or directory
> Starting syslogd/klogd: done
> INIT: Id "O0" respawning too fast: disabled for 5 minutes
> [   92.942038] random: nonblocking pool is initialized
> INIT: Id "O0" respawning too fast: disabled for 5 minutes
> 
> Note: This I did not get in Daisy 1.6 and meta-ti with compatible.
> 
> Could you help me here.

Would be nice to understand which kernel and which image you are building and 
using. The console in recent kernels moved from ttyO to ttyS, although our 
kernel has fallback mechanism and should still boot with ttyO, hence the 
question.

-- 
Denys


> On Thu, Mar 2, 2017 at 10:26 PM, Denys Dmytriyenko  wrote:
> 
> > On Thu, Mar 02, 2017 at 04:19:33PM +, Burton, Ross wrote:
> > > On 2 March 2017 at 16:14, SatyaNarayana Sampangi 
> > > wrote:
> > >
> > > > I am using beagle bone black, for which meta-ti layer and poky versions
> > > > compatible is daisy 1.6 as mention in the official website of yocto.
> > If I
> > > > upgrade the poky to the latest version, then compatibity will be lost.
> > Pls
> > > > help me out here.
> > > >
> > >
> > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/ has branches for
> > krogoth
> > > (2.1) and morty (2.2).  Where did you see that 1.6 is the last release
> > > supported?
> >
> > ^^ This is all that matters! The rest is just fluff...
> >
> > --
> > Denys
> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Devtool: Script Not found

[Denys Dmytriyenko]

On Thu, Mar 02, 2017 at 04:26:32PM +, Burton, Ross wrote:
> On 2 March 2017 at 16:25, SatyaNarayana Sampangi 
> wrote:
> 
> >
> > Pls go through this link,
> >
> > https://www.yoctoproject.org/product/meta-ti-bsp-layer
> >
> > very clearly mentioned
> >
> 
> Clearly the meta-ti maintainers should update the site.

meta-ti maintainers have no control over that page.

It says "compatible" as defined in "Yocto Project Compatible 1.0":
https://www.yoctoproject.org/ecosystem/yocto-project-branding-program

That program has been in the process of upgrading and I've been asked to 
wait for the new and improved "Yocto Project Compatible 2.0" process...

So, technically, meta-ti is still following the rules and adhering to the 
compatibility guidelines all the way to version 2.2, just not running the 
official review process for the old program...


BTW, meta-ti says compatible with version 1.6, while meta-intel is 1.5:
https://www.yoctoproject.org/product/meta-intel-bsp-layer

So, clearly, the process has been abandoned by everyone...

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

Re: [yocto] Devtool: Script Not found

[Denys Dmytriyenko]

On Thu, Mar 02, 2017 at 04:19:33PM +, Burton, Ross wrote:
> On 2 March 2017 at 16:14, SatyaNarayana Sampangi 
> wrote:
> 
> > I am using beagle bone black, for which meta-ti layer and poky versions
> > compatible is daisy 1.6 as mention in the official website of yocto. If I
> > upgrade the poky to the latest version, then compatibity will be lost. Pls
> > help me out here.
> >
> 
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/ has branches for krogoth
> (2.1) and morty (2.2).  Where did you see that 1.6 is the last release
> supported?

^^ This is all that matters! The rest is just fluff...

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

Re: [yocto] [Openembedded-architecture] Patchwork and incoming patch testing

[Denys Dmytriyenko]

Paul,

That is some impressive work by the team! Thank you all for the hard work and 
bringing the plan to fruition - I'm sure this framework will benefit our 
entire Community and will improve and streamline the workflow!

-- 
Denys


On Wed, Jan 18, 2017 at 07:05:58AM +1300, Paul Eggleton wrote:
> Hi all,
> 
> As some of you are aware some of my colleagues and I have been working on 
> improving how incoming patches are handled - initially for OE-Core but we 
> hope 
> to arrive at something that will be useful for other layers as well. The aim 
> was to do so without adversely affecting existing workflows, so that means 
> building on top of the things we already have. It's taken a bit longer than 
> we'd originally planned - we embarked on this a little over a year ago [1] - 
> but now I am happy to be able to show some meaningful progress.
> 
> A few months ago we upgraded OE's patchwork instance [2], moving not just to 
> a 
> later version but to a fork of patchwork where a bunch of new functionality 
> was being developed for freedesktop.org [3], notably support for capturing 
> and 
> presenting patch series instead of just individual patches. There were some 
> teething problems but we've now resolved most of them. Unfortunately work on 
> said freedesktop.org fork appears to have stalled so for now we have forked 
> it 
> ourselves [4]; long term we'll have to see if we can merge back with 
> patchwork 
> upstream - at least for small fixes we'll try to push those back up 
> independent of any wholesale merge. In any event we are now finally in the 
> position where our patchwork instance can be relied upon to collect emails, 
> and the UI is much improved. This should give us a bit more visibility into 
> where patches are at in the process, although we are still working on a few 
> places where patch series status needs to be updated (e.g. when a patch goes 
> into testing).
> 
> On top of patchwork we have built a simple smoke-testing framework called 
> "patchtest" [5] along with a suite of corresponding tests for OE [6]. These 
> tests are fairly simplistic at this point but check the basics such as 
> whether 
> a patch has been properly signed off, etc. We should soon start seeing 
> replies 
> sent to the mailing list and to submitters with results if there are any 
> failures, saving us from noticing and pointing out some of the more obvious 
> classes of mistakes. The tests are easy to run locally without the rest of 
> the 
> infrastructure and can be extended without difficulty, and I expect we'll 
> continue to work on those as time progresses. Contributions would be very 
> welcome.
> 
> My sincere thanks to José Lamego, Leonardo Sandoval, Daniela Plascencia, 
> Belen Barros Pena, Michael Halstead, Damien Lespiau, Patrick Ohly and others 
> that have been part of implementing this, and to everyone else who has put up 
> with the delays.
> 
> Please let us know if you have issues with any part of this process or 
> suggestions on how to improve it. We're tracking improvements in the Yocto 
> Project bugzilla [7] so you can see what's being worked on there if you're 
> interested.
> 
> Cheers,
> Paul
> 
> [1] Earlier announcement:
> 
> https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg72952.html
> 
> [2] OE's patchwork instance:
> http://patchwork.openembedded.org
> 
> [3] Freedesktop.org patchwork fork:
> https://github.com/dlespiau/patchwork
> 
> [4] Our patchwork fork:
> http://git.yoctoproject.org/cgit/cgit.cgi/patchwork/
> 
> [5] Patchtest main repository:
> http://git.yoctoproject.org/cgit/cgit.cgi/patchtest/
> 
> [6] OE test suite for patchtest:
> http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe/
> 
> [7] Yocto Project bugzilla area for patchwork/patchtest:
> 
> https://bugzilla.yoctoproject.org/describecomponents.cgi?product=Patchwork%2FPatchtest
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> ___
> Openembedded-architecture mailing list
> openembedded-architect...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-architecture
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Save the dates (OEDEM and Yocto Project Developer Day)

[Denys Dmytriyenko]

On Thu, Jul 14, 2016 at 01:03:39PM -0400, Philip Balister wrote:
> ELCE is in Berlin this year on Oct 11-13 (Tuesday-Thursday). After
> conversations with the Yocto Project, we've worked out that there will
> be a Yocto Project developer day on Monday, Oct 10 and OEDEM
> (OpenEmbedded developer meeting) on Friday, Oct 14.
> 
> The Yocto Project developer day is basically a training class with
> beginner and advanced topics.
> 
> The OpenEmbedded developer meeting is a chance to talk with developers
> about various project topics. We'll work out the agenda closer to ELCE.

Wiki page for OEDEM 2016 has been created:

http://openembedded.org/wiki/OEDEM_2016

If you already know you will be attending, please add yourself to the list. 
Thanks.

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

Re: [yocto] [oe] [OE-core] OEDAM, April 8 in San Diego after ELC

[Denys Dmytriyenko]

On Mon, Apr 11, 2016 at 03:35:21PM -0700, Rudolf J Streif wrote:
> Hello Everyone:
> 
> If you attended OEDAM last Friday in San Diego, I very much hope that you 
> enjoyed being here.
> 
> The Catamaran Hotel, where we held the meeting, would very much appreciate 
> your feedback:
> 
> www.catamaranresort.com/trip
> 
> I hope you all had a safe trip back home,

And huge thanks to Rudi and Jefro for their help in organizing the event!

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

Re: [yocto] [Openembedded-architecture] Glibc 2.24 _might_ require minimum kernel version 3.2

[Denys Dmytriyenko]

On Sun, Jan 31, 2016 at 09:41:17AM -0800, Khem Raj wrote:
> Hi
> 
> This is FYI, as I have sent a RFT for glibc 2.24, there might be another 
> change
> coming which is under discussion on glibc mailing lists which is on
> supported minimum
> kernel version bump to 3.2 since 2.6.32 will be EOLed this summer [1]
> 
> If anyone is planning on using upcoming yocto/OE release and sticking
> to kernels older than  3.2 then please plan for upgrading your kernel.
> 
> Thanks
> -Khem
> 
> [1] - https://sourceware.org/ml/libc-alpha/2016-01/msg00885.html

What about our timeline - is glibc 2.24 planned for the next 2.1 release?

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

Re: [yocto] [meta-ti] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Denys Dmytriyenko]

On Tue, May 12, 2015 at 11:35:20AM -0400, Bruce Ashfield wrote:
> On 2015-05-12 10:20 AM, Brian Hutchinson wrote:
> >On Mon, May 11, 2015 at 3:06 PM, Bruce Ashfield
> > wrote:
> >>On 2015-05-11 02:10 PM, Brian Hutchinson wrote:
> >>>
> >>>On Thu, Apr 30, 2015 at 10:06 AM, Bruce Ashfield
> >>> wrote:
> 
> It is plausible. But in theory, linux-dummy should still provide
> what you need (but since it doesn't build anything, there is
> no abi .. and no modules can be built against it) .. so the
> error isn't graceful.
> 
> Bruce
> >>>
> >>>
> >>>I can confirm this same problem is happening to me.  I just updated
> >>>one of my builds from 1.7 to 1.8 and am also getting my rootfs to fail
> >>>due to no abi kernel version:
> >>
> >>
> >>We still have a race condition in the 1.8 branch for the population
> >>of the build-artifacts directory.
> >>
> >>If modules start building, they'll race against the population of the
> >>abiversion, and you may see that message.
> >>
> >>There's a proposed patch for master, but I don't think it is in
> >>fido yet.
> >>
> >>Bruce
> >
> >Hi Bruce,
> >
> >I did some searches and looks like there are a number of 'race'
> >condition fixes but it wasn't obvious which one I may need.  Is it
> >this one:
> >http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=02d0a003d603266114512160b209876199241e98
> >
> 
> That's the one that should make sure that the shared workdir
> (Which has the abiversion) is in place before building any modules.
> 
> I can't say that it is exactly your issue, but it is the change
> I was thinking of.

Brian,

Were you able to try the above mentioned commit against am180x in meta-ti? Did 
it solve the missing abi kernel version? Thanks.

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

Re: [yocto] OpenEmbedded Developer America's Meeting

[Denys Dmytriyenko]

On Tue, Feb 10, 2015 at 03:27:23PM -0500, Philip Balister wrote:
> We've scheduled a meeting in San Jose at a Monte Vista facility for

Correction, it's MontaVista with an 'a':
http://en.wikipedia.org/wiki/MontaVista

Do you have an address of said facility?


> March 27-28. This is after ELC (also in San Jose). There is a Yocto
> Project developer Day the day after ELC.
> 
> I've made a page on the wiki to start collecting information:
> 
> http://openembedded.org/wiki/OEDAM_2015
> 
> To get an idea of what we cover, see the page from the prior year:
> 
> http://openembedded.org/wiki/OEDAM_2014
> 
> I apologize for the late notice. There were issues that led to a delay
> with dates due to the YP Dev day.
> 
> Philip
> -- 
> ___
> Openembedded-members mailing list
> openembedded-memb...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-members
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference between target, cross, native and nativesdk.

[Denys Dmytriyenko]

On Fri, Jan 23, 2015 at 10:54:39AM -0200, Otavio Salvador wrote:
> On Thu, Jan 22, 2015 at 8:31 PM, Dominic Sacré  wrote:
> > On 2015-01-21 14:37, Otavio Salvador wrote:
> >> The fw tools inside of U-Boot qualifies for both target and cross use
> >> cases. When used in cross or crosssdk, it can be used to change things
> >> in the generated image (sdcard for example) while in the target case
> >> it can be used in the runtime system.
> >
> > I've been wondering about the "u-boot-fw-utils-cross" recipe myself.
> > When I build the recipe I get what appear to be the correct binaries for
> > the host architecture, located in the target-specific work directory
> > (e.g. tmp/work/imx6qsabresd-poky-linux-gnueabi/u-boot-fw-utils-cross).
> > However, these binaries don't get installed anywhere other recipes (like
> > my sdcard image) would be able to find them.
> >
> > My workaround so far has been to build a native package instead (by
> > simply adding BBCLASSEXTEND = "native" to the regular "u-boot-fw-utils"
> > recipe).
> > This way the binaries get installed to the host's sysroot and are found
> > just fine, but I feel like I'm missing something about how the cross
> > recipe should be used properly for this purpose.
> >
> > Can anyone shed some light on this?
> 
> I sent a patch and seems to do the right thing. Can you test it?

Well, again, you didn't really answer the question...

The question wasn't about the breakage, but rather about the process. How do 
you mean to use the u-boot-fw-utils-cross "package"?

In other words, SYSROOT_PREPROCESS_FUNCS doesn't seem to work, as no binaries 
are being deployed or staged in sysroots. Moreover, if you use rm_work class, 
the only binary in the tmp/work directory gets deleted right away and you 
can't use the output of this recipe in any way.

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

Re: [yocto] Difference between target, cross, native and nativesdk.

[Denys Dmytriyenko]

On Wed, Jan 21, 2015 at 09:23:35PM +, Richard Purdie wrote:
> On Wed, 2015-01-21 at 14:27 -0500, Denys Dmytriyenko wrote:
> > On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> > > I was explained about the difference in a different way.
> > > 
> > > cross generates binary for the host architecture. But the way this
> > > binary is generated depends of the target architecture. Native
> > > generated binaries that do not depend of the target architecture.
> > 
> > Pretty much.
> > 
> > But another big difference is that -native packages do not generate IPK, 
> > RPM 
> > or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.
> 
> -cross and -crosssdk do not generate packages.

Yeah, I thought so initially, but then I found depmodwrapper-cross and 
qemuwrapper-cross packages in my deploy/ipk, which got me confused... They 
seem to be special cases and only have scripts and not binaries. I wonder if 
the name is misleading...


> Another way to think of this is:
> 
> "native" build once
> 
> "cross" build once per target, run on native, output code for target
> 
> "crosssdk" build once per sdk, run on native, output code for sdk
> 
> "cross-canadian" build once per sdk, run on sdk, output code for target
> 
> Whilst native.bbclass and nativesdk.bbclass are useful generally,
> cross.bbclass is only useful for GNU tool projects like
> binutils/gcc/gdb.
> 
> Cheers,
> 
> Richard
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference between target, cross, native and nativesdk.

[Denys Dmytriyenko]

On Wed, Jan 21, 2015 at 11:23:38AM -0200, Raphael Philipe wrote:
> I was explained about the difference in a different way.
> 
> cross generates binary for the host architecture. But the way this
> binary is generated depends of the target architecture. Native
> generated binaries that do not depend of the target architecture.

Pretty much.

But another big difference is that -native packages do not generate IPK, RPM 
or DEB, while -nativesdk, -cross, -crosssdk and -cross-canadian do.

-- 
Denys


> On Tue, Jan 20, 2015 at 12:44 PM, Paul Eggleton
>  wrote:
> > On Tuesday 20 January 2015 12:39:16 Raphael Philipe wrote:
> >> On Tue, Jan 20, 2015 at 10:23 AM, Paul Eggleton
> >>  wrote:
> >> > On Tuesday 20 January 2015 09:17:49 Raphael Philipe wrote:
> >> >> I'm working on a set of recipes that must be configurable to be baked
> >> >> in native, nativesdk, cross and target.
> >> >>
> >> >> I have a bunch of questions concerning this terms. I searched the
> >> >> documentation and wasn't able to find a definitive explanation for
> >> >> these terms.
> >> >>
> >> >> I will write some statements bellow about my understanding on these
> >> >> terms, and I will ask you to please correct me if I'm wrong or add any
> >> >> additional information:
> >> >>
> >> >> - By default, recipes bake binaries for the target architecture that
> >> >> is described in the MACHINE variable in the local.conf
> >> >
> >> > Correct.
> >> >
> >> >> - One can use BBCLASSEXTEND = "native nativesdk" to bake binaries for
> >> >> the host architecture (native) and for target sdk architecture. The
> >> >> target sdk architecture is described in the SDKMACHINE variable and
> >> >> the host architecture is the architecture of the machine executing
> >> >> bitbake. BBCLASSEXTEND = "native nativesdk" will alow you to bake
> >> >> recipes that are "virtual" using the suffix native ( so ${PN}-native)
> >> >> and the prefix nativesdk (so nativesdk-${PN}).
> >> >
> >> > Correct. FYI alternatively you can also "inherit native" or "inherit
> >> > nativesdk" to make a recipe specific to either of those classes (in which
> >> > case the recipe itself should be named -native or nativesdk-
> >> > ), however BBCLASSEXTEND is preferred these days.
> >> >
> >> >> - Recipes that are cross need to inherit cross.bbclass. They are used 
> >> >> for
> >> >> 
> >> >
> >> > Cross tools, i.e. tools that need to run in the native context and 
> >> > produce
> >> > some binary output for the target.
> >>
> >> For u-boot-fw-utils-cross, the binary that you refer is the enviroment
> >> variables file of u-boot? In this case, the difference between cross
> >> and native is not clear for me.
> >
> > I'm not sure of the details for this recipe specifically. Perhaps one of the
> > people on CC can answer.
> >
> > Cheers,
> > Paul
> >
> > --
> >
> > Paul Eggleton
> > Intel Open Source Technology Centre
> -- 
> ___
> 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] [meta-yocto-bsp][PATCH] beaglebone.conf: update KERNEL_IMAGETYPE to match u-boot

[Denys Dmytriyenko]

On Tue, Dec 09, 2014 at 04:44:31PM +0100, Maciej Borzecki wrote:
> U-boot 2014.07 in Poky expects a zImage kernel image, thus a build done with
> current machien config will not be directly useable. Update machine config to
> produce a zImage.
> 
> Signed-off-by: Maciej Borzecki 
> Signed-off-by: Maciek Borzecki 

Acked-by: Denys Dmytriyenko 

This was sitting in my tree pending fixed update to U-boot 2014.10...


> ---
>  meta-yocto-bsp/conf/machine/beaglebone.conf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> b/meta-yocto-bsp/conf/machine/beaglebone.conf
> index a316207..fb0189d 100644
> --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> @@ -24,7 +24,7 @@ SERIAL_CONSOLE = "115200 ttyO0"
>  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>  PREFERRED_VERSION_linux-yocto ?= "3.14%"
>  
> -KERNEL_IMAGETYPE = "uImage"
> +KERNEL_IMAGETYPE = "zImage"
>  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
>  KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
>  
> -- 
> 1.9.3
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cannot run simple binary executable file

[Denys Dmytriyenko]

On Fri, Oct 10, 2014 at 05:51:08PM -0700, Wy kevinthesun wrote:
> These errors occur when I add "-mfloat-abi=hardfp" to the toolchain
> setting. If I don't add it, no error occurs. Now I think the problem is
> that 1.5.1 or 1.6.2 toolchain doesn't support hard float, which is required
> by my yocto 1.5.1 system.

Can you please explain how you got your "1.5.1 yocto system"? Did you built it 
yourself or downloaded prebuilt from the site? If latter, then it should match 
the toolchain...


> 2014-10-10 16:27 GMT-07:00 Denys Dmytriyenko :
> 
> > On Fri, Oct 10, 2014 at 04:15:42PM -0700, Wy kevinthesun wrote:
> > > I tried both hard and hardfp. They both returned 3 errors:
> > >
> > > C compiler cannot create executablesHello-1Configure
> > Problem
> > > in `/home/kevinthefire/workspace/Hello':Hello-1Configure
> > > Problem
> > > make: *** No rule to make target `all'.Hello C/C++
> > Problem
> >
> > That doesn't sound like a toolchain error, but rather an autotools one.
> > Make
> > sure you are setting up cross compilation properly.
> >
> >
> > > 2014-10-09 23:12 GMT-07:00 Nicolas Dechesne  > >:
> > >
> > > > On Thu, Oct 9, 2014 at 10:27 PM, Wy kevinthesun <
> > kevinthesu...@gmail.com>
> > > > wrote:
> > > > > It seems that Yocto 1.5.1 is built with hard float. However, the
> > 1.51,
> > > > 1.6
> > > > > and  1.62 toolchains are soft float. When I tried to set
> > > > > "-mfloat-abi=hardfp" in the compile option, the compiling process ran
> > > > into
> > > > > error. It seems these toolchains don't  support hard float? How can I
> > > > solve
> > > > > this problem?
> > > > >
> > > > > These are my set in the environment file of 1.5.1 toolchain:
> > > > > export CC="arm-poky-linux-gnueabi-gcc  -march=armv5te -marm
> > > > > -mthumb-interwork -mfloat-abi=hardfp
> > > > > --sysroot=/opt/poky/1.5.1/sysroots/armv5te-poky-linux-gnueabi"
> > > > > export CXX="arm-poky-linux-gnueabi-g++  -march=armv5te -marm
> > > > > -mthumb-interwork -mfloat-abi=hardfp
> > > > > --sysroot=/opt/poky/1.5.1/sysroots/armv5te-poky-linux-gnueabi"
> > > > > export CPP="arm-poky-linux-gnueabi-gcc -E  -march=armv5te -marm
> > > > > -mthumb-interwork -mfloat-abi=hardfp
> > > > > --sysroot=/opt/poky/1.5.1/sysroots/armv5te-poky-linux-gnueabi"
> > > > >
> > > > > It ran into error.
> > > >
> > > >
> > > > maybe because the gcc documentation says -mfloat-abi=hard, not =hardfp
> > ?
> > > >
> > > > in general, showing us the error you have is much preferred, otherwise
> > > > it's difficult to help if we don't really know what went wrong.
> > > >
> > > > cheers.
> > > >
> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cannot run simple binary executable file

[Denys Dmytriyenko]

On Fri, Oct 10, 2014 at 04:15:42PM -0700, Wy kevinthesun wrote:
> I tried both hard and hardfp. They both returned 3 errors:
> 
> C compiler cannot create executablesHello-1Configure Problem
> in `/home/kevinthefire/workspace/Hello':Hello-1Configure
> Problem
> make: *** No rule to make target `all'.Hello C/C++ Problem

That doesn't sound like a toolchain error, but rather an autotools one. Make 
sure you are setting up cross compilation properly.


> 2014-10-09 23:12 GMT-07:00 Nicolas Dechesne :
> 
> > On Thu, Oct 9, 2014 at 10:27 PM, Wy kevinthesun 
> > wrote:
> > > It seems that Yocto 1.5.1 is built with hard float. However, the 1.51,
> > 1.6
> > > and  1.62 toolchains are soft float. When I tried to set
> > > "-mfloat-abi=hardfp" in the compile option, the compiling process ran
> > into
> > > error. It seems these toolchains don't  support hard float? How can I
> > solve
> > > this problem?
> > >
> > > These are my set in the environment file of 1.5.1 toolchain:
> > > export CC="arm-poky-linux-gnueabi-gcc  -march=armv5te -marm
> > > -mthumb-interwork -mfloat-abi=hardfp
> > > --sysroot=/opt/poky/1.5.1/sysroots/armv5te-poky-linux-gnueabi"
> > > export CXX="arm-poky-linux-gnueabi-g++  -march=armv5te -marm
> > > -mthumb-interwork -mfloat-abi=hardfp
> > > --sysroot=/opt/poky/1.5.1/sysroots/armv5te-poky-linux-gnueabi"
> > > export CPP="arm-poky-linux-gnueabi-gcc -E  -march=armv5te -marm
> > > -mthumb-interwork -mfloat-abi=hardfp
> > > --sysroot=/opt/poky/1.5.1/sysroots/armv5te-poky-linux-gnueabi"
> > >
> > > It ran into error.
> >
> >
> > maybe because the gcc documentation says -mfloat-abi=hard, not =hardfp ?
> >
> > in general, showing us the error you have is much preferred, otherwise
> > it's difficult to help if we don't really know what went wrong.
> >
> > cheers.
> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] YP documentation survey

[Denys Dmytriyenko]

On Thu, Oct 09, 2014 at 11:19:15AM +0100, Burton, Ross wrote:
> On 8 October 2014 21:56, Denys Dmytriyenko  wrote:
> > fop: command not found
> >
> > Trying to install fop shows me about 100 (!) Java dependencies... Is this
> > expected?
> 
> Yes, FOP is implemented in Java and Java libraries are quite granular.
> 
> It's just XSLT so you can likely use a different XSLT processor if
> this bothers you sufficiently (but you may need to buy a license for a
> commercial processor).

Ok, I see. It's unfortunate, but understood. I ended up installing it on my 
other machine which has Java, so it wasn't as painful. Thanks.

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

Re: [yocto] YP documentation survey

[Denys Dmytriyenko]

For me, it fails with:

fop: command not found

Trying to install fop shows me about 100 (!) Java dependencies... Is this 
expected?

-- 
Denys


On Fri, Oct 03, 2014 at 11:08:34AM -0400, Trevor Woerner wrote:
> 
> On 09/30/14 14:22, Chris Hallinan wrote:
> > My only comment: make it easier to build the latest docs from git.  I
> > seem to always hit errors, and I've seen other posts about that, too.
> > I just did a quick make DOC=mega-manual on Daisy, and it failed with:
> > "tar: mega-manual.html: Cannot stat: No such file or directory"  
> >
> > make DOC=dev-manual failed due to missing dependencies, and in the 30
> > seconds I spent while writing this e-mail, I couldn't figure out what
> > to install on my U14.04 host to satisfy it.
> >
> > I don't have much use/fondness for html docs.  Give me a searchable
> > PDF any day.
> >
> 
> Attached is the little shell script I run right after I run my other
> shell script that updates all the layer repositories I follow :-)
> 
> I only build the PDFs and I've never been successful building the mega
> manual either (pdf, html, or otherwise).
> 
> Getting the docs to build on my openSUSE system was also a challenge
> since there are two packages which provide "docbook2x-texi" and I need
> the _other_ one :-)


> -- 
> ___
> 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] Cannot run simple binary executable file

[Denys Dmytriyenko]

On Tue, Oct 07, 2014 at 07:05:42PM -0700, Wy kevinthesun wrote:
> However, a new problem occurs. Now when I tries run HelloWorld binary,
> after "Hello World" is printed, the terminal also prints "Segmentation
> fault". It seems that some memory problems occurs. I guess it comes from
> that the 1.5.1 yocto system on boards hopes ld-linux-armhf.so.3 as dynamic
> linker, instead of ld-linux.so.3, which is used by toolchain. There may be
> some memory address problem between them. How can I solve it?

As Nicolas suggested earlier, it seems you are trying to mix ABIs here. 
Because ld-linux-armhf.so.3 indicates the system uses hardfp ABI, but the 
example app you built with your toolchain wants ld-linux.so.3, which is 
usually the old softfp ABI. You'd need to match ABIs and the easiest solution 
is to use the same toolchain that was used to build the system (1.5.1?)

-- 
Denys


> 2014-10-07 18:17 GMT-07:00 Wy kevinthesun :
> 
> > Problem solved! It turns out it is the mismatch of ld-linux.so. I referred
> > to this post
> > http://stackoverflow.com/questions/24543474/cross-compiled-gnu-arm-beagleboneblack-from-windows-runtime-error-on-elf,
> > and found my problem was exactly the same: the binary needs
> > /lib/ld-linux.so.3 to run, but that file is missing in the 1.5.1 yocto
> > system on board. Then I copied ld-linux.so.3 file from Yocto toolchain on
> > my pc. Then it works!
> >
> > Thank you!
> >
> > 2014-10-07 8:21 GMT-07:00 Nicolas Dechesne :
> >
> > On Tue, Oct 7, 2014 at 1:07 PM, Wy kevinthesun 
> >> wrote:
> >> > Hi, I am new to Yocto Project and learning to develop software on Atmel
> >> > SAMA5D3 Xplained board, on which Yocto 1.5.1 is pre-built. I followed
> >> the
> >> > instructions and got the 1.6.1 toolchain
> >> >
> >> > poky-eglibc-i686-core-image-sato-armv7a-vfp-neon-toolchain-1.6.1.sh.
> >> >
> >> > I can compile the simple HelloWorld program and binary file is made.
> >> Then I
> >> > copied the binary file
> >> >
> >> > into board and tried to run it. However, when I changed to the file
> >> located
> >> > directory and type
> >> >
> >> > "./Hello", it returned "sh: ./Hello: No such file or directory". Then I
> >> > tried "sh Hello", it gave
> >> >
> >> > me  "Hello: Hello: cannot execute binary file ". If I type "file
> >> Hello", it
> >> > gives "Hello: ELF 32-bit
> >> >  LSB  executable, ARM, EABI5 version 1 (SYSV), dynamically linked (uses
> >> > shared libs), for GNU/Linux 2.6.16,
> >> > BuildID[sha1]=9933a2d2ce212099c5f9902a8e612c1423e136da, not stripped". I
> >> > googled and someone
> >> >
> >> > said the problem may be the toolchain. Then I tried 1.3, 1.5.1
> >> toolchain for
> >> > arm, but still same
> >> >
> >> > error. Could you please help me about this problem?
> >>
> >>
> >> i suspect this is an armv7 soft-float vs hard-float mismatch. Either
> >> your prebuilt OE system is configured with soft-float and the
> >> toolchain you use compiled for hard-float by default, or the other way
> >> around. can you check how you've compile HelloWolrd and check the
> >> other ABI?
> >>
> >
> >

> -- 
> ___
> 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] Recommended Hardware for building

[Denys Dmytriyenko]

On Thu, Oct 02, 2014 at 11:04:43AM +0100, Burton, Ross wrote:
> On 2 October 2014 10:36, Oliver Novakovic  wrote:
> > Can anyone recommend a reasonable performant hardware setup to use ?
> >
> > What should be considered ? Are there any pitfalls ? What about bottlenecks
> > in the build system ?
> >
> > Specifically:
> >
> > How many cores are recommended ? And how much cache is necessary ?
> > How much of the main memory does Yocto really use ? Is 32 GB sufficient or
> > should I go for 64 ?
> >
> > Does it make sense to use two SSDs as Raid0  to get builds faster ?
> 
> As much of everything as you can afford.  :)  The build isn't heavy in
> any particular metric, so don't sacrifice RAM for SSDs for example.
> 
> RAID 0 over SSD would be nice and fast, but I prefer having a good
> amount of RAM and a tuned ext4 (no journal, long commit delay) so data
> doesn't actually hit the disk as frequently. Keeping the actual build
> directories on a separate disk is good for performance and not causing
> data loss when you lose a disk.
> 
> There are people that have 64GB in machines and then set TMPDIR to a
> tmpfs.  Surprisingly this isn't that much faster (5% or so), but it's
> a lot easier on the hardware and power consumption.

That's how I roll - after I lost few SSD drives by constantly building and 
rebuilding stuff, I ended up shoving 64GB of RAM into my gear and building 
into RAM-based tmpfs. Of course, there are size limits to what can be built in 
one go, but there are workarounds and ways to serialize builds...

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

Re: [yocto] yocto 1.6 - beaglebone black - cape manager

[Denys Dmytriyenko]

On Mon, Oct 06, 2014 at 02:57:08PM -0600, Gary Thomas wrote:
> On 2014-10-06 13:43, Denys Dmytriyenko wrote:
> >On Thu, Sep 04, 2014 at 07:02:13PM -0300, Diego Sueiro wrote:
> >>>I'm build yocto 1.6, My hardware is beaglebone black I successfull
> >>>build system image. But I can't see cape manager.
> >>>I need them to use SPI - enable spidev -
> >>>http://elinux.org/BeagleBone_Black_Enable_SPIDEV .
> >>>What do i do to build yocto with a cape manager?
> >>
> >>As far as I know, you have to use meta-beagleboard
> >><https://github.com/beagleboard/meta-beagleboard> (almost 1 year without
> >>any new commit) as your BSP layer to get capemanager support with Yocto.
> >>Take a look here
> >><https://github.com/beagleboard/meta-beagleboard/blob/dylan/common-bsp/recipes-kernel/linux/linux-mainline_3.8.bb>.
> >>The kernel version is 3.8.
> >>
> >>Here we have good news of having capemanager support on mainline:
> >>http://beagleboard.org/blog/2014-08-27-device-tree-overlay-support-lands-upstream/
> >>
> >>Here you have a beaglebord.org linux repo with capemanager support:
> >>https://github.com/beagleboard
> >>I don't know if there is any WIP to get this kernel compiled by Yocto/OE.
> >
> >Hi,
> >
> >[I was asked to provide additional comments to this topic - I'm the 
> >maintainer
> >of meta-ti and the author of BeagleBone Black support in meta-yocto-bsp]
> >
> >I see that Diego has pretty much covered all the basics above. I'll just add
> >few clarifications and details...
> >
> >
> >There are few different OE/Yocto BSPs for BeagleBone Black:
> >
> >1. meta-yocto-bsp provides "reference" BSPs for each of the supported
> >architectures. One for ARM (BeagleBone Black), one for MIPS, PPC and x86.
> >The keyword is "reference", as it is based on the mainline kernel/bootloader
> >and does not support any advanced features or anything not in the upstream
> >mainline kernel - e.g. no capes, no power management, no hardware
> >acceleration, no 3D, no PRU, etc. The purpose of this BSP is to have some
> >basic out-of-box experience for the select hardware platforms within Poky to
> >evaluate the Yocto Project and OpenEmbedded framework, but not the specific
> >hardware platforms. For proper and more comprehensive HW support users are
> >directed to the corresponding official BSPs - meta-intel, meta-ti, meta-fsl
> >(ARM, PPC), meta-amd, etc. etc.
> >
> >2. meta-ti is the official Texas Instruments BSP that provides the latest WIP
> >"staging" kernel and bootloader with most of the advanced features and
> >peripheral support for the wider range of latest TI platforms, including
> >BeagleBone Black. Most of the work in the "staging" area is being upstreamed,
> >so it eventually appears in the mainline kernel and u-boot. It doesn't 
> >support
> >capes on BBB, at least not yet - see below.
> >
> >3. meta-beagleboard (now defunct) was a split-off from meta-ti few years ago
> >to concentrate on the development of the BeagleBoard and BeagleBone 
> >specifics,
> >such as capes. At the time it was based on 3.8 kernel and had large patchsets
> >to add device tree overlays and cape management, among other things. 
> >Although,
> >meta-beagleboard seems to be dead now, the work on the devtree overlays and
> >cape manager has continued, thanks to Pantelis Antoniou - see the blog post 
> >on
> >beagleboard.org, linked by Diego above.
> >
> >
> >The plan always was for meta-ti and meta-beagleboard to meet upstream, hence
> >meta-ti will eventually have all the necessary pieces to support capes, once
> >it lands upstream. Meanwhile, TI now concentrates on supporting all the other
> >advanced features and upstreaming everything to mainline.
> >
> >BTW, the kernel repo from Robert Nelson (the last link from Diego above) is
> >now based on the TI "staging" kernel, i.e. the one provided by meta-ti, plus
> >some additional patches not yet accepted upstream. I might look into adding a
> >recipe to meta-ti to pull in that tree, but haven't decided yet...
> 
> Which, if any, of these choices is suitable for accelerated graphics?
> Which device(s) will that choice support?  HDMI, LCD cape, ???
> Can accelerated graphics, e.g. SGX, be supported by QT5?  If so, what
> additional magic needs to be done?

If you are asking about BeagleBone Black specifically, then meta-ti does 
provide accelerated GLES 3D graphics for SGX over HDMI. On other devices, 
built-in LCD is also supported, but not LCD cape, due to reasons above.
SGX is basically supported on Qt5, but there are some pieces missing, for 
which there is work either in progress or planned - for more details I'd 
recommend moving the discussion to meta-ti or meta-arago lists.

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

Re: [yocto] yocto 1.6 - beaglebone black - cape manager

[Denys Dmytriyenko]

On Thu, Sep 04, 2014 at 07:02:13PM -0300, Diego Sueiro wrote:
> > I'm build yocto 1.6, My hardware is beaglebone black I successfull
> > build system image. But I can't see cape manager.
> > I need them to use SPI - enable spidev -
> > http://elinux.org/BeagleBone_Black_Enable_SPIDEV .
> > What do i do to build yocto with a cape manager?
> 
> As far as I know, you have to use meta-beagleboard
>  (almost 1 year without
> any new commit) as your BSP layer to get capemanager support with Yocto.
> Take a look here
> .
> The kernel version is 3.8.
> 
> Here we have good news of having capemanager support on mainline:
> http://beagleboard.org/blog/2014-08-27-device-tree-overlay-support-lands-upstream/
> 
> Here you have a beaglebord.org linux repo with capemanager support:
> https://github.com/beagleboard
> I don't know if there is any WIP to get this kernel compiled by Yocto/OE.

Hi,

[I was asked to provide additional comments to this topic - I'm the maintainer 
of meta-ti and the author of BeagleBone Black support in meta-yocto-bsp]

I see that Diego has pretty much covered all the basics above. I'll just add 
few clarifications and details...


There are few different OE/Yocto BSPs for BeagleBone Black:

1. meta-yocto-bsp provides "reference" BSPs for each of the supported 
architectures. One for ARM (BeagleBone Black), one for MIPS, PPC and x86.
The keyword is "reference", as it is based on the mainline kernel/bootloader 
and does not support any advanced features or anything not in the upstream 
mainline kernel - e.g. no capes, no power management, no hardware 
acceleration, no 3D, no PRU, etc. The purpose of this BSP is to have some 
basic out-of-box experience for the select hardware platforms within Poky to 
evaluate the Yocto Project and OpenEmbedded framework, but not the specific 
hardware platforms. For proper and more comprehensive HW support users are 
directed to the corresponding official BSPs - meta-intel, meta-ti, meta-fsl 
(ARM, PPC), meta-amd, etc. etc.

2. meta-ti is the official Texas Instruments BSP that provides the latest WIP 
"staging" kernel and bootloader with most of the advanced features and 
peripheral support for the wider range of latest TI platforms, including 
BeagleBone Black. Most of the work in the "staging" area is being upstreamed, 
so it eventually appears in the mainline kernel and u-boot. It doesn't support 
capes on BBB, at least not yet - see below.

3. meta-beagleboard (now defunct) was a split-off from meta-ti few years ago 
to concentrate on the development of the BeagleBoard and BeagleBone specifics, 
such as capes. At the time it was based on 3.8 kernel and had large patchsets 
to add device tree overlays and cape management, among other things. Although, 
meta-beagleboard seems to be dead now, the work on the devtree overlays and 
cape manager has continued, thanks to Pantelis Antoniou - see the blog post on 
beagleboard.org, linked by Diego above.


The plan always was for meta-ti and meta-beagleboard to meet upstream, hence 
meta-ti will eventually have all the necessary pieces to support capes, once 
it lands upstream. Meanwhile, TI now concentrates on supporting all the other 
advanced features and upstreaming everything to mainline.

BTW, the kernel repo from Robert Nelson (the last link from Diego above) is 
now based on the TI "staging" kernel, i.e. the one provided by meta-ti, plus 
some additional patches not yet accepted upstream. I might look into adding a 
recipe to meta-ti to pull in that tree, but haven't decided yet...


If there are any questions remain, please find me on meta-ti mailing list at 
meta...@yoctoproject.org. Thanks.

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

Re: [yocto] OEDAM: OpenEmbedded Developers (Americas) Meeting

[Denys Dmytriyenko]

The OpenEmbedded Board of Directors would like to thank everyone who was able 
to participate (either in person in Santa Clara or online) in our first OEDAM 
OpenEmbedded Developers (Americas) Meeting on May 2nd and 3rd! The meeting was 
a huge success and a lot of fun!

We would also like to thank Ettus Research/NI for providing the premises, as 
well as Jefro and the Yocto Project for sponsoring the event and providing 
food!

The meeting minutes should be published shortly.

-- 
Denys


On Thu, Feb 20, 2014 at 07:03:24PM -0500, Philip Balister wrote:
> The OpenEmbedded Project is holding a developers meeting May 2-3,
> 2014, in Santa Clara, CA. This meeting is immediately after the Embedded
> Linux Conference North America. All active OpenEmbedded and Yocto
> Project developers are invited to attend.
> 
> NOTE: this is a development meeting for the project itself, not a
> training session.
> 
> May 2-3, 2014
> time TBD
> 
> Ettus Research/National Instruments
> 4600 Patrick Henry Drive
> Santa Clara, CA 95054 USA
> 
> Lunch will be provided on both days.
> 
> For more information and to add yourself to the list of attendees, see
> the wiki page at
> http://openembedded.org/wiki/OEDAM
> 
> Here are a couple of photos from 2009:
> 
> http://www.flickr.com/photos/32615155@N00/sets/72157622653686647/
> 
> I'd like to thank Jefro for help with this announcement. Any errors are
> mine though.
> 
> Philip, OpenEmbedded eV Chair.
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] No USB devices on BeagleBoard xM!

[Denys Dmytriyenko]

On Sun, Apr 20, 2014 at 08:44:57AM +1200, Jeremy Cole-Baker wrote:
> 
> Hi, I still can't figure out how to get the USB hardware working on
> my BeagelBoard xM.
> 
> I've managed to build a couple of different recipes for my
> BeagleBoard (BeagleBoard xM Rev C), and also had a go at customising
> it.  I think I've tried core-image-minimal and core-image-basic.
> 
> The build works OK, and I can set up my micro SD card and get it to
> boot. I see lots of messages about loading drivers during boot, and
> I can log in to linux.
> 
> However, the USB devices don't seem to be working. The built in
> USB-Ethernet isn't there, and when I plug in a USB stick nothing
> happens - nothing in /dev/ and no messages in the system log.
> 
> I don't know whether this is something I missed in the build, or
> some configuration I need to do. I also don't know whether it is
> specific to the Beagle or a general problem. Unfortunately I am new
> to Kernel builds and device drivers.
> 
> Here's what I've looked into:
> 
> The boot-up messages indicate that the USB drivers are loaded, e.g.:
> 
> 
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> ...
> usbcore: registered new interface driver smsc75xx
> usbcore: registered new interface driver smsc95xx
> ...etc
> 
> (I think smsc95xx is the USB-Ethernet chip on the beagle board xM).
> 
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ehci-omap: OMAP-EHCI Host Controller driver
> ehci-omap 48064800.ehci: EHCI Host Controller
> ehci-omap 48064800.ehci: new USB bus registered, assigned bus number 1
> ehci-omap 48064800.ehci: irq 93, io mem 0x48064800
> ehci-omap 48064800.ehci: USB 2.0 started, EHCI 1.00
> hub 1-0:1.0: USB hub found
> hub 1-0:1.0: 3 ports detected
> usbcore: registered new interface driver usb-storage
> musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -6
> mousedev: PS/2 mouse device common for all mice
> ...Etc
> 
> There's a modprobe error which occurs a couple of times:
> 
> udevd[71]: starting version 175
> modprobe: chdir(3.10.11-yocto-standard): No such file or directory

Doesn't seem like you have modules installed in your rootfs ^^^

If you build core-image-minimal, you then need to extract the modules from a 
tarball you got in the deplot area...


> I also saw errors from the ethernet subsystem (?), along the lines
> of "eth0: device not found" and "usb0: device not found". This
> occurred during boot and also when I used "ifup eth0". I'm actually
> seeing a different error now: "ifconfig: SIOCGIFFLAGS: No such
> device". In either case, I think it's because something to do with
> the actual USB hardware is missing or not configured.
> 
> "lsmod" shows no modules loaded, i.e.:
> 
> root@beagleboard:~# lsmod
> Module Size Used by
> root@beagleboard:~#
> 
> Does this mean that the various device drivers, etc, above are built
> in to the kernel?
> 
> Any suggestions for how to diagnose / fix this problem? Anybody else
> have experience with the BeagleBoard xM? I'm a bit lost.
> 
> Thanks!
> 
> Jeremy Cole-Baker
> 
> -- 
> ___
> 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] BBB doesn't boot

[Denys Dmytriyenko]

On Thu, Apr 17, 2014 at 04:25:51PM -0700, Khem Raj wrote:
> On Thu, Apr 17, 2014 at 2:31 PM, William Mills  wrote:
> > On 04/17/2014 03:10 PM, Denys Dmytriyenko wrote:
> >>
> >> On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
> >>>
> >>> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> >>>>
> >>>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> >>>>>>>>>
> >>>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's
> >>>>>>>>> the
> >>>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
> >>>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this
> >>>>>>>>> helped:
> >>>>>>>>>
> >>>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>>> * u-boot from
> >>>>>>>>> http://downloads.angstrom-distribution.org/demo/beaglebone/
> >>>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >>>>>>>>>
> >>>>>>>>> I think we're now at the point where we'd benefit from someone with
> >>>>>>>>> better
> >>>>>>>>> knowledge debugging the issue.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Ok, should we expand the search area? Since this is supposed to be
> >>>>>>>> vanilla
> >>>>>>>> 3.14 kernel, can we try other platforms and see if they are
> >>>>>>>> similarly
> >>>>>>>> affected? I'll try pinging our kernel guys for any ideas...
> >>>>>>>
> >>>>>>>
> >>>>>>> As far as I know it has only been observed with beaglebone (both
> >>>>>>> white and
> >>>>>>> black, if it makes a difference). FWIW, qemuarm images from the
> >>>>>>> autobuilder
> >>>>>>> boot just fine, and apparently the same is true of edgerouter
> >>>>>>> (different
> >>>>>>> architecture but also uses u-boot).
> >>>>>>
> >>>>>>
> >>>>>> But do those other platforms use uImage or zImage?
> >>>>
> >>>>
> >>>> I don't yet know what is going on, but building in the same directory
> >>>> with
> >>>> sources (B = S) makes it work regarless of the path length:
> >>>>
> >>>>
> >>>> /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> >>>>
> >>>> So, I just commented out setting kernel-specific B in linux-yocto.inc
> >>>> and any
> >>>> kernel now boots with long path:
> >>>>
> >>>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> >>>>
> >>>> I'm copying Richard and Bruce directly to see if they may have a quick
> >>>> insight
> >>>> and/or accept it as a workaround for the release. I'll keep digging
> >>>> further,
> >>>> but if anyone cares to verify the above workaround works for them, I
> >>>> would
> >>>> appreciate. Thanks!
> >>>>
> >>>
> >>> Verified - I rebuilt the kernel in a working tree with a longer
> >>> path (one in fact that had failed before) and it boots fine.
> >>>
> >>> Wonder what ${B} != ${S} is doing wacky...?
> >>
> >>
> >> Gary, et al,
> >>
> >> I've just submitted a patch to oe-core and yocto MLs that fixes this issue
> >> -
> >> could you please test it in your setup and confirm? Thanks!
> >>
> >
> > I updated Stefan's bug w/ more explanation.
> > I verified that Stefan's uImage-bad failed for me and then added the
> > following to uEnv.txt:
> > fdtaddr=0x8800
> 
> hmmm so it seems kernel size grew enough to overwrite the area where
> uboot would put divice tree ?

Exactly! The overall kernel size was very close to the limit of previous space 
allocation in U-boot and enabling another feature or growing the build path a 
bit would overflow into and corrupt the device tree.


> has happened to me on ppc with kernel+initramfs where initramfs kept growing

I was told no other platforms were affected, including qemuarm! :) Yeah, I 
know, it can happen to anyone, even though by default it works fine...


> > uImage-bad (and uImage-good) worked w/ the above change to uEnv.txt.
> > Denys' patch fixes all the defaults in u-boot so that no uEnv.txt change is
> > needed.
> >
> > --
> > ___
> > 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] BBB doesn't boot

[Denys Dmytriyenko]

On Thu, Apr 17, 2014 at 04:48:27PM -0600, Gary Thomas wrote:
> On 2014-04-17 13:10, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
> >> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> >>> On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> >>>>>>>> Some other things I tried with a "long" TMPDIR path (note that it's 
> >>>>>>>> the
> >>>>>>>> TMPDIR path that makes the difference - in my tests I've been using
> >>>>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> >>>>>>>>
> >>>>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> >>>>>>>> * u-boot from 
> >>>>>>>> http://downloads.angstrom-distribution.org/demo/beaglebone/
> >>>>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >>>>>>>>
> >>>>>>>> I think we're now at the point where we'd benefit from someone with 
> >>>>>>>> better
> >>>>>>>> knowledge debugging the issue.
> >>>>>>>
> >>>>>>> Ok, should we expand the search area? Since this is supposed to be 
> >>>>>>> vanilla
> >>>>>>> 3.14 kernel, can we try other platforms and see if they are similarly
> >>>>>>> affected? I'll try pinging our kernel guys for any ideas...
> >>>>>>
> >>>>>> As far as I know it has only been observed with beaglebone (both white 
> >>>>>> and 
> >>>>>> black, if it makes a difference). FWIW, qemuarm images from the 
> >>>>>> autobuilder 
> >>>>>> boot just fine, and apparently the same is true of edgerouter 
> >>>>>> (different 
> >>>>>> architecture but also uses u-boot).
> >>>>>
> >>>>> But do those other platforms use uImage or zImage?
> >>>
> >>> I don't yet know what is going on, but building in the same directory 
> >>> with 
> >>> sources (B = S) makes it work regarless of the path length:
> >>>
> >>> /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> >>>
> >>> So, I just commented out setting kernel-specific B in linux-yocto.inc and 
> >>> any 
> >>> kernel now boots with long path:
> >>>
> >>> #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> >>>
> >>> I'm copying Richard and Bruce directly to see if they may have a quick 
> >>> insight 
> >>> and/or accept it as a workaround for the release. I'll keep digging 
> >>> further, 
> >>> but if anyone cares to verify the above workaround works for them, I 
> >>> would 
> >>> appreciate. Thanks!
> >>>
> >>
> >> Verified - I rebuilt the kernel in a working tree with a longer
> >> path (one in fact that had failed before) and it boots fine.
> >>
> >> Wonder what ${B} != ${S} is doing wacky...?
> > 
> > Gary, et al,
> > 
> > I've just submitted a patch to oe-core and yocto MLs that fixes this issue 
> > - 
> > could you please test it in your setup and confirm? Thanks!
> > 
> 
> Yes, verified it works great!  Thanks for figuring this one out.

And thank you for stumbling upon it in the first place :) and your continued 
help validating it until completion! Thanks Stefan, Bill and everyone else 
involed. Now let's hope Richard takes it into the release shortly... :)

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 05:07:10PM -0600, Gary Thomas wrote:
> On 2014-04-15 13:43, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> >>>>>> Some other things I tried with a "long" TMPDIR path (note that it's the
> >>>>>> TMPDIR path that makes the difference - in my tests I've been using
> >>>>>> /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> >>>>>>
> >>>>>> * kernel built with gcc 4.7.2 and binutils 2.23.2
> >>>>>> * u-boot built with gcc 4.7.2 and binutils 2.23.2
> >>>>>> * u-boot from 
> >>>>>> http://downloads.angstrom-distribution.org/demo/beaglebone/
> >>>>>> * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> >>>>>>
> >>>>>> I think we're now at the point where we'd benefit from someone with 
> >>>>>> better
> >>>>>> knowledge debugging the issue.
> >>>>>
> >>>>> Ok, should we expand the search area? Since this is supposed to be 
> >>>>> vanilla
> >>>>> 3.14 kernel, can we try other platforms and see if they are similarly
> >>>>> affected? I'll try pinging our kernel guys for any ideas...
> >>>>
> >>>> As far as I know it has only been observed with beaglebone (both white 
> >>>> and 
> >>>> black, if it makes a difference). FWIW, qemuarm images from the 
> >>>> autobuilder 
> >>>> boot just fine, and apparently the same is true of edgerouter (different 
> >>>> architecture but also uses u-boot).
> >>>
> >>> But do those other platforms use uImage or zImage?
> > 
> > I don't yet know what is going on, but building in the same directory with 
> > sources (B = S) makes it work regarless of the path length:
> > 
> > /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> > 
> > So, I just commented out setting kernel-specific B in linux-yocto.inc and 
> > any 
> > kernel now boots with long path:
> > 
> > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> > 
> > I'm copying Richard and Bruce directly to see if they may have a quick 
> > insight 
> > and/or accept it as a workaround for the release. I'll keep digging 
> > further, 
> > but if anyone cares to verify the above workaround works for them, I would 
> > appreciate. Thanks!
> > 
> 
> Verified - I rebuilt the kernel in a working tree with a longer
> path (one in fact that had failed before) and it boots fine.
> 
> Wonder what ${B} != ${S} is doing wacky...?

Gary, et al,

I've just submitted a patch to oe-core and yocto MLs that fixes this issue - 
could you please test it in your setup and confirm? Thanks!

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

[yocto] [PATCH] u-boot: fix beaglebone boot issue with large kernel images

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Fix beaglebone boot issue with large kernel images overwriting Device Tree.
See very detailed comments inside the patch.

The original patch is being reviewed upstream and is targeting mainline U-boot
version 2014.07. This is the adaptation of the patch for 2013.07 version we use

Signed-off-by: Denys Dmytriyenko 
---
 ...h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch | 74 ++
 meta/recipes-bsp/u-boot/u-boot_2013.07.bb  |  4 +-
 2 files changed, 77 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch

diff --git 
a/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
 
b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
new file mode 100644
index 000..77e35bb
--- /dev/null
+++ 
b/meta/recipes-bsp/u-boot/files/0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch
@@ -0,0 +1,74 @@
+From 5701384cea4a829b772bf7a96a74825b58c22385 Mon Sep 17 00:00:00 2001
+From: Denys Dmytriyenko 
+Date: Thu, 17 Apr 2014 12:25:40 -0400
+Subject: [PATCH] am335x_evm.h: Add, use DEFAULT_LINUX_BOOT_ENV environment
+ string
+
+Modified version of the patch currently being reviewed for mainline:
+http://patchwork.ozlabs.org/patch/334861/
+
+To deal with a reoccurring problem properly we need to specify addresses
+for the Linux kernel, Flatted Device Tree and ramdisk that obey the
+constraints within the kernel's Documentation/arm/Booting file but also
+make sure that we relocate things within a valid address range.
+
+Signed-off-by: Denys Dmytriyenko 
+Signed-off-by: Tom Rini 
+
+Upstream-Status: Pending
+---
+ include/configs/am335x_evm.h | 31 ++-
+ 1 file changed, 26 insertions(+), 5 deletions(-)
+
+diff --git a/include/configs/am335x_evm.h b/include/configs/am335x_evm.h
+index c5a6d4b..01e32b3 100644
+--- a/include/configs/am335x_evm.h
 b/include/configs/am335x_evm.h
+@@ -54,10 +54,7 @@
+ #define CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
+ #ifndef CONFIG_SPL_BUILD
+ #define CONFIG_EXTRA_ENV_SETTINGS \
+-  "loadaddr=0x8020\0" \
+-  "fdtaddr=0x80F8\0" \
+-  "fdt_high=0x\0" \
+-  "rdaddr=0x8100\0" \
++  DEFAULT_LINUX_BOOT_ENV \
+   "bootdir=/boot\0" \
+   "bootfile=uImage\0" \
+   "fdtfile=undefined\0" \
+@@ -197,7 +194,31 @@
+ #define CONFIG_SYS_MEMTEST_END(CONFIG_SYS_MEMTEST_START \
+   + (8 * 1024 * 1024))
+ 
+-#define CONFIG_SYS_LOAD_ADDR  0x8100 /* Default load address */
++/*
++ * Our DDR memory always starts at 0x8000 and U-Boot shall have
++ * relocated itself to higher in memory by the time this value is used.
++ * However, set this to a 32MB offset to allow for easier Linux kernel
++ * booting as the default is often used as the kernel load address.
++ */
++#define CONFIG_SYS_LOAD_ADDR  0x8200 /* Default load address */
++
++/*
++ * We setup defaults based on constraints from the Linux kernel, which should
++ * also be safe elsewhere.  We have the default load at 32MB into DDR (for
++ * the kernel), FDT above 128MB (the maximum location for the end of the
++ * kernel), and the ramdisk 512KB above that (allowing for hopefully never
++ * seen large trees).  We say all of this must be within the first 256MB
++ * as that will normally be within the kernel lowmem and thus visible via
++ * bootm_size and we only run on platforms with 256MB or more of memory.
++ */
++#define DEFAULT_LINUX_BOOT_ENV \
++  "loadaddr=0x8200\0" \
++  "kernel_addr_r=0x8200\0" \
++  "fdtaddr=0x8800\0" \
++  "fdt_addr_r=0x8800\0" \
++  "rdaddr=0x8808\0" \
++  "ramdisk_addr_r=0x8808\0" \
++  "bootm_size=0x1000\0"
+ 
+ #define CONFIG_MMC
+ #define CONFIG_GENERIC_MMC
+-- 
+1.9.2
+
diff --git a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb 
b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
index 3141a2d..f8a8856 100644
--- a/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
+++ b/meta/recipes-bsp/u-boot/u-boot_2013.07.bb
@@ -16,7 +16,9 @@ SRCREV = "62c175fbb8a0f9a926c88294ea9f7e88eb898f6c"
 
 PV = "v2013.07+git${SRCPV}"
 
-SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master \
+   
file://0001-am335x_evm.h-Add-use-DEFAULT_LINUX_BOOT_ENV-environm.patch \
+"
 
 S = "${WORKDIR}/git"
 
-- 
1.9.2

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 09:12:30PM -0400, Denys Dmytriyenko wrote:
> On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
> > On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> > > I don't yet know what is going on, but building in the same directory 
> > > with 
> > > sources (B = S) makes it work regarless of the path length:
> > > 
> > > /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> > > 
> > > So, I just commented out setting kernel-specific B in linux-yocto.inc and 
> > > any 
> > > kernel now boots with long path:
> > > 
> > > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> > > 
> > > I'm copying Richard and Bruce directly to see if they may have a quick 
> > > insight 
> > > and/or accept it as a workaround for the release. I'll keep digging 
> > > further, 
> > > but if anyone cares to verify the above workaround works for them, I 
> > > would 
> > > appreciate. Thanks!
> > 
> > I'm travelling and don't have hardware so I'm limited in what I can look
> > at right now. I suspect this workaround "works" because it makes the
> > "beaglebone-standard-build" extra characters on the path. I have a
> > feeling your -111 test above may have reused sstate or something
> > like that and given misleading results. I'd be interested in the vmlinux
> > file from the build above to see if the poky-11 pathnames are in
> > there (they get stripped out when you create the zImage).
> 
> Nope, I was fooled by sstate once, so this time I tested with cleansstate and 
> compared timestamps of the kernel when it boots - it is definitely the new 
> one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect 
> it, I increased the path length even further - that extra level with 333 is 
> there to over-compensate, as it was failing before even with just 111 and 222 
> levels only... Looks like Gary was also able to verify it.
> 
> But, you are right about vmlinux - it doesn't have those paths in there any 
> more! I've seen them there when building with B != S, but they are gone when 
> building with B = S. Wondering why. You can check it for yourself:
> 
> http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard

And, as a follow up, all those long paths in vmlinux when built with B != S 
point to sources. Here are few examples:

B != S strings:

/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
/OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux/arch/arm/vfp/vfpmodule.c
6VFP support v0.3: 


B = S same strings:

init/main.c
earlycon
4Malformed early option '%s'
3Starting init: %s exists but couldn't execute it (error %d)
...
6Trying to unpack rootfs image as initramfs...
init/initramfs.c
6rootfs image is not initramfs (%s); looks like an initrd
TRAILER!!!
...
%lu.%02lu BogoMIPS (lpj=%lu)
arch/arm/vfp/vfpmodule.c
6VFP support v0.3: 


So, that explains why B = S works regardless of the location, as it doesn't 
embed full path to source files...

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Wed, Apr 16, 2014 at 12:36:58AM +0100, Richard Purdie wrote:
> On Tue, 2014-04-15 at 15:43 -0400, Denys Dmytriyenko wrote:
> > I don't yet know what is going on, but building in the same directory with 
> > sources (B = S) makes it work regarless of the path length:
> > 
> > /OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux
> > 
> > So, I just commented out setting kernel-specific B in linux-yocto.inc and 
> > any 
> > kernel now boots with long path:
> > 
> > #B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"
> > 
> > I'm copying Richard and Bruce directly to see if they may have a quick 
> > insight 
> > and/or accept it as a workaround for the release. I'll keep digging 
> > further, 
> > but if anyone cares to verify the above workaround works for them, I would 
> > appreciate. Thanks!
> 
> I'm travelling and don't have hardware so I'm limited in what I can look
> at right now. I suspect this workaround "works" because it makes the
> "beaglebone-standard-build" extra characters on the path. I have a
> feeling your -111 test above may have reused sstate or something
> like that and given misleading results. I'd be interested in the vmlinux
> file from the build above to see if the poky-11 pathnames are in
> there (they get stripped out when you create the zImage).

Nope, I was fooled by sstate once, so this time I tested with cleansstate and 
compared timestamps of the kernel when it boots - it is definitely the new 
one. And to make sure 'beaglebone-standard-build' extra suffix doesn't affect 
it, I increased the path length even further - that extra level with 333 is 
there to over-compensate, as it was failing before even with just 111 and 222 
levels only... Looks like Gary was also able to verify it.

But, you are right about vmlinux - it doesn't have those paths in there any 
more! I've seen them there when building with B != S, but they are gone when 
building with B = S. Wondering why. You can check it for yourself:

http://arago-project.org/files/short-term/misc/vmlinux-3.14.0-yocto-standard

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 01:41:12PM -0400, Denys Dmytriyenko wrote:
> > > > > Some other things I tried with a "long" TMPDIR path (note that it's 
> > > > > the
> > > > > TMPDIR path that makes the difference - in my tests I've been using
> > > > > /home/paul/poky/build2/much/longer/path/to/tmp). None of this helped:
> > > > > 
> > > > > * kernel built with gcc 4.7.2 and binutils 2.23.2
> > > > > * u-boot built with gcc 4.7.2 and binutils 2.23.2
> > > > > * u-boot from 
> > > > > http://downloads.angstrom-distribution.org/demo/beaglebone/
> > > > > * earlyprintk and CONFIG_DEBUG_LL - no additional output printed
> > > > > 
> > > > > I think we're now at the point where we'd benefit from someone with 
> > > > > better
> > > > > knowledge debugging the issue.
> > > > 
> > > > Ok, should we expand the search area? Since this is supposed to be 
> > > > vanilla
> > > > 3.14 kernel, can we try other platforms and see if they are similarly
> > > > affected? I'll try pinging our kernel guys for any ideas...
> > > 
> > > As far as I know it has only been observed with beaglebone (both white 
> > > and 
> > > black, if it makes a difference). FWIW, qemuarm images from the 
> > > autobuilder 
> > > boot just fine, and apparently the same is true of edgerouter (different 
> > > architecture but also uses u-boot).
> > 
> > But do those other platforms use uImage or zImage?

I don't yet know what is going on, but building in the same directory with 
sources (B = S) makes it work regarless of the path length:

/OE/RAM/poky-1///tmp/work/beaglebone-poky-linux-gnueabi/linux-yocto/3.14+gitAUTOINC+928d7b2dda_0143c6ebb4-r0/linux

So, I just commented out setting kernel-specific B in linux-yocto.inc and any 
kernel now boots with long path:

#B = "${WORKDIR}/linux-${PACKAGE_ARCH}-${LINUX_KERNEL_TYPE}-build"

I'm copying Richard and Bruce directly to see if they may have a quick insight 
and/or accept it as a workaround for the release. I'll keep digging further, 
but if anyone cares to verify the above workaround works for them, I would 
appreciate. Thanks!

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 01:16:01PM -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 05:36:10PM +0100, Paul Eggleton wrote:
> > On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > > > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > > > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie 
> > wrote:
> > > > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko 
> > > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas 
> > wrote:
> > > > > > > > > > > > > Very interesting results!  These are the results from
> > > > > > > > > > > > > the
> > > > 
> > > > build hosts I have:
> > > > > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > > > 
> > > > > > > > > > > > Interesting indeed. I have no idea what's so special 
> > > > > > > > > > > > about
> > > > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > > > with
> > > > > > > > > > > > it. I may try experimenting with different VMs once I 
> > > > > > > > > > > > have
> > > > > > > > > > > > more time...
> > > > > > > > > > > 
> > > > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > > > can
> > > > > > > > > > > find
> > > > > > > > > > > between working and non working builds is the path length 
> > > > > > > > > > > to
> > > > > > > > > > > the
> > > > > > > > > > > build
> > > > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > > > files
> > > > > > > > > > > from
> > > > > > > > > > > working and non working builds.
> > > > > > > > > > > 
> > > > > > > > > > > Works:
> > > > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > > > 
> > > > > > > > > > > Doesn't Work:
> > > > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > > > x-gn
> > > > > > > > > > > ueabi
> > > > > > > > > > > 
> > > > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > > > making
> > > > > > > > > > > a
> > > > > > > > > > > difference.
> > > > > > > > > > > 
> > > > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > > > build
> > > > > > > > > > > where I
> > > > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > > > and
> > > > > > > > > > > patched
> > > > > > > > > > > in the same version strings:
> > > > > 

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 05:36:10PM +0100, Paul Eggleton wrote:
> On Tuesday 15 April 2014 12:26:39 Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> > > On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > > > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie 
> wrote:
> > > > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas 
> wrote:
> > > > > > > > > > > > Very interesting results!  These are the results from
> > > > > > > > > > > > the
> > > 
> > > build hosts I have:
> > > > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > > > 
> > > > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > > > Fedora host - this is the first time I hear about issues
> > > > > > > > > > > with
> > > > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > > > more time...
> > > > > > > > > > 
> > > > > > > > > > I've been having a look at this. The biggest differences I
> > > > > > > > > > can
> > > > > > > > > > find
> > > > > > > > > > between working and non working builds is the path length to
> > > > > > > > > > the
> > > > > > > > > > build
> > > > > > > > > > directory for the kernel. This is from comparing vmlinux
> > > > > > > > > > files
> > > > > > > > > > from
> > > > > > > > > > working and non working builds.
> > > > > > > > > > 
> > > > > > > > > > Works:
> > > > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > > > 
> > > > > > > > > > Doesn't Work:
> > > > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linu
> > > > > > > > > > x-gn
> > > > > > > > > > ueabi
> > > > > > > > > > 
> > > > > > > > > > I also have been wondering if the version strings may be
> > > > > > > > > > making
> > > > > > > > > > a
> > > > > > > > > > difference.
> > > > > > > > > > 
> > > > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken
> > > > > > > > > > build
> > > > > > > > > > where I
> > > > > > > > > > truncated the path length to a "working" build path length
> > > > > > > > > > and
> > > > > > > > > > patched
> > > > > > > > > > in the same version strings:
> > > > > > > > > > 
> > > > > > > > > > const char linux_banner[] =
> > > > > > > > > > 
> > > > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > > > > 
> > > > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > > > 2014\n";
> > > > >

[yocto] [not-for-merge][PATCH 1/2] u-boot: update to 2014.01

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Signed-off-by: Denys Dmytriyenko 
---
 meta/recipes-bsp/u-boot/u-boot_2014.01.bb | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/recipes-bsp/u-boot/u-boot_2014.01.bb

diff --git a/meta/recipes-bsp/u-boot/u-boot_2014.01.bb 
b/meta/recipes-bsp/u-boot/u-boot_2014.01.bb
new file mode 100644
index 000..5c522ec
--- /dev/null
+++ b/meta/recipes-bsp/u-boot/u-boot_2014.01.bb
@@ -0,0 +1,22 @@
+require u-boot.inc
+
+# To build u-boot for your machine, provide the following lines in your machine
+# config, replacing the assignments as appropriate for your machine.
+# UBOOT_MACHINE = "omap3_beagle_config"
+# UBOOT_ENTRYPOINT = "0x80008000"
+# UBOOT_LOADADDRESS = "0x80008000"
+
+LICENSE = "GPLv2+"
+LIC_FILES_CHKSUM = 
"file://Licenses/README;md5=025bf9f768cbcb1a165dbe1a110babfb"
+
+# This revision corresponds to the tag "v2014.01"
+# We use the revision in order to avoid having to fetch it from the repo 
during parse
+SRCREV = "b44bd2c73c4cfb6e3b9e7f8cf987e8e39aa74a0b"
+
+PV = "v2014.01+git${SRCPV}"
+
+SRC_URI = "git://git.denx.de/u-boot.git;branch=master"
+
+S = "${WORKDIR}/git"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
-- 
1.9.2

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

[yocto] [not-for-merge][PATCH 2/2] beaglebone: switch default kernel format to zImage

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Requires U-boot 2013.10+

Signed-off-by: Denys Dmytriyenko 
---
 meta-yocto-bsp/conf/machine/beaglebone.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
b/meta-yocto-bsp/conf/machine/beaglebone.conf
index 4263715..7ce2563 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
@@ -24,7 +24,7 @@ SERIAL_CONSOLE = "115200 ttyO0"
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "3.14%"
 
-KERNEL_IMAGETYPE = "uImage"
+KERNEL_IMAGETYPE = "zImage"
 KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
 KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
-- 
1.9.2

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 03:49:42PM +0100, Paul Eggleton wrote:
> On Tuesday 15 April 2014 11:52:49 Stanacar, StefanX wrote:
> > On Tue, 2014-04-15 at 09:03 +, Stanacar, StefanX wrote:
> > > On Tue, 2014-04-15 at 01:17 -0400, Denys Dmytriyenko wrote:
> > > > On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> > > > > On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > > > > > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > > > > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > > > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > > > > > Very interesting results!  These are the results from the 
> build hosts I have:
> > > > > > > > > >   Fedora 13 (i686) - fails
> > > > > > > > > >   Fedora 17 (i686) - fails
> > > > > > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > > > > > 
> > > > > > > > > Interesting indeed. I have no idea what's so special about
> > > > > > > > > Fedora host - this is the first time I hear about issues with
> > > > > > > > > it. I may try experimenting with different VMs once I have
> > > > > > > > > more time...
> > > > > > > > 
> > > > > > > > I've been having a look at this. The biggest differences I can
> > > > > > > > find
> > > > > > > > between working and non working builds is the path length to the
> > > > > > > > build
> > > > > > > > directory for the kernel. This is from comparing vmlinux files
> > > > > > > > from
> > > > > > > > working and non working builds.
> > > > > > > > 
> > > > > > > > Works:
> > > > > > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > > > > > 
> > > > > > > > Doesn't Work:
> > > > > > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gn
> > > > > > > > ueabi
> > > > > > > > 
> > > > > > > > I also have been wondering if the version strings may be making
> > > > > > > > a
> > > > > > > > difference.
> > > > > > > > 
> > > > > > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build
> > > > > > > > where I
> > > > > > > > truncated the path length to a "working" build path length and
> > > > > > > > patched
> > > > > > > > in the same version strings:
> > > > > > > > 
> > > > > > > > const char linux_banner[] =
> > > > > > > > 
> > > > > > > >"Linux version 3.14.0-yocto-standard
> > > > > > > >(paul@ubuntu-build01) (gcc
> > > > > > > > 
> > > > > > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST
> > > > > > > > 2014\n";
> > > > > > > > 
> > > > > > > > const char linux_proc_banner[] = "%s version %s
> > > > > > > > (paul@ubuntu-build01)
> > > > > > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > > > > > 
> > > > > > > > to init/version.c.
> > > > > > > > 
> > > > > > > > I don't have hardware and would be interested to know if the
> > > > > > > > kernel
> > > > > > > > linked to above works or not. If it doesn't, it rules out these
> > > > > > > > path and
> > > > > > > > string lengths, if it does work, it points to a problem there.
> > > > > > > 
> > > > > > > Richard,
> > > > > > 
> > > > > > > Good catch! It boots:
> > > > > > Thanks Denys, this helps narrow down the issue. I've shared
> > > > > > http://dan.rpsys.net/uImage-rp3 which is the same as the last

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 01:07:28AM -0400, Denys Dmytriyenko wrote:
> On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> > On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > > Very interesting results!  These are the results from the build 
> > > > > > hosts I have:
> > > > > >   Fedora 13 (i686) - fails
> > > > > >   Fedora 17 (i686) - fails
> > > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > > 
> > > > > Interesting indeed. I have no idea what's so special about Fedora 
> > > > > host - this 
> > > > > is the first time I hear about issues with it. I may try 
> > > > > experimenting with 
> > > > > different VMs once I have more time...
> > > > 
> > > > I've been having a look at this. The biggest differences I can find
> > > > between working and non working builds is the path length to the build
> > > > directory for the kernel. This is from comparing vmlinux files from
> > > > working and non working builds.
> > > > 
> > > > Works:
> > > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > 
> > > > Doesn't Work:
> > > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > > 
> > > > I also have been wondering if the version strings may be making a
> > > > difference.
> > > > 
> > > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> > > > truncated the path length to a "working" build path length and patched
> > > > in the same version strings:
> > > > 
> > > > const char linux_banner[] = 
> > > >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > > > 
> > > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > > 
> > > > to init/version.c.
> > > > 
> > > > I don't have hardware and would be interested to know if the kernel
> > > > linked to above works or not. If it doesn't, it rules out these path and
> > > > string lengths, if it does work, it points to a problem there.
> > > 
> > > Richard,
> > > 
> > > Good catch! It boots:
> > 
> > Thanks Denys, this helps narrow down the issue. I've shared
> > http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> > with my changes to version.c reverted. The one should tell us if its the
> > paths or the strings.
> 
> This one also boots for me:
> 
> Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) 
> #2 PREEMPT Tue Apr 15 05:40:19 IST 2014
> 
> 
> > I'm guessing the path problem is more likely but anything is possible.
> > This is starting to look like some kind of compiler or linker issue. If
> > it is that, it would help to have more data points about what works and
> > what doesn't. With that in mind could people who have good or bad builds
> > please share the paths they built the kernels in so we can see if we can
> > spot some kind of pattern.

BTW, my path is /OE/RAM/poky/tmp/work/beaglebone-poky-linux-gnueabi and it 
works.

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 05:44:04AM +0100, Richard Purdie wrote:
> On Mon, 2014-04-14 at 21:38 -0400, Denys Dmytriyenko wrote:
> > On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> > > On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > > > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > > > Very interesting results!  These are the results from the build hosts 
> > > > > I have:
> > > > >   Fedora 13 (i686) - fails
> > > > >   Fedora 17 (i686) - fails
> > > > >   Ubuntu 12.04 (x86_64) - boots
> > > > 
> > > > Interesting indeed. I have no idea what's so special about Fedora host 
> > > > - this 
> > > > is the first time I hear about issues with it. I may try experimenting 
> > > > with 
> > > > different VMs once I have more time...
> > > 
> > > I've been having a look at this. The biggest differences I can find
> > > between working and non working builds is the path length to the build
> > > directory for the kernel. This is from comparing vmlinux files from
> > > working and non working builds.
> > > 
> > > Works:
> > > /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > 
> > > Doesn't Work:
> > > /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> > > 
> > > I also have been wondering if the version strings may be making a
> > > difference.
> > > 
> > > http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> > > truncated the path length to a "working" build path length and patched
> > > in the same version strings:
> > > 
> > > const char linux_banner[] = 
> > >"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> > > version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> > > 
> > > const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> > > (gcc version 4.8.2 (GCC) ) %s\n";
> > > 
> > > to init/version.c.
> > > 
> > > I don't have hardware and would be interested to know if the kernel
> > > linked to above works or not. If it doesn't, it rules out these path and
> > > string lengths, if it does work, it points to a problem there.
> > 
> > Richard,
> > 
> > Good catch! It boots:
> 
> Thanks Denys, this helps narrow down the issue. I've shared
> http://dan.rpsys.net/uImage-rp3 which is the same as the last one but
> with my changes to version.c reverted. The one should tell us if its the
> paths or the strings.

This one also boots for me:

Linux version 3.14.0-yocto-standard (richard@ted) (gcc version 4.8.2 (GCC) ) #2 
PREEMPT Tue Apr 15 05:40:19 IST 2014


> I'm guessing the path problem is more likely but anything is possible.
> This is starting to look like some kind of compiler or linker issue. If
> it is that, it would help to have more data points about what works and
> what doesn't. With that in mind could people who have good or bad builds
> please share the paths they built the kernels in so we can see if we can
> spot some kind of pattern.
> 
> Cheers,
> 
> Richard
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Tue, Apr 15, 2014 at 01:20:03AM +0100, Richard Purdie wrote:
> On Mon, 2014-04-14 at 18:44 -0400, Denys Dmytriyenko wrote:
> > On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> > > Very interesting results!  These are the results from the build hosts I 
> > > have:
> > >   Fedora 13 (i686) - fails
> > >   Fedora 17 (i686) - fails
> > >   Ubuntu 12.04 (x86_64) - boots
> > 
> > Interesting indeed. I have no idea what's so special about Fedora host - 
> > this 
> > is the first time I hear about issues with it. I may try experimenting with 
> > different VMs once I have more time...
> 
> I've been having a look at this. The biggest differences I can find
> between working and non working builds is the path length to the build
> directory for the kernel. This is from comparing vmlinux files from
> working and non working builds.
> 
> Works:
> /home/paul/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> 
> Doesn't Work:
> /media/data1/build1/poky/build/tmp/work/beaglebone-poky-linux-gnueabi
> 
> I also have been wondering if the version strings may be making a
> difference.
> 
> http://dan.rpsys.net/uImage-rp2 is a uImage from a broken build where I
> truncated the path length to a "working" build path length and patched
> in the same version strings:
> 
> const char linux_banner[] = 
>"Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc
> version 4.8.2 (GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014\n";
> 
> const char linux_proc_banner[] = "%s version %s (paul@ubuntu-build01)
> (gcc version 4.8.2 (GCC) ) %s\n";
> 
> to init/version.c.
> 
> I don't have hardware and would be interested to know if the kernel
> linked to above works or not. If it doesn't, it rules out these path and
> string lengths, if it does work, it points to a problem there.

Richard,

Good catch! It boots:


U-Boot SPL 2013.07 (Apr 10 2014 - 04:47:32)
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
OMAP SD/MMC: 0
reading args
spl: error reading image args, err - -1
reading u-boot.img
reading u-boot.img


U-Boot 2013.07 (Apr 10 2014 - 04:47:32)

I2C:   ready
DRAM:  512 MiB
WARNING: Caches not enabled
NAND:  0 MiB
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
*** Warning - readenv() failed, using default environment

musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0 
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Peripheral mode controller at 47401000 using PIO, IRQ 0
musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
musb-hdrc: MHDRC RTL version 2.0
musb-hdrc: setup fifo_mode 4
musb-hdrc: 28/31 max ep, 16384/16384 memory
USB Host mode controller at 47401800 using PIO, IRQ 0
Net:not set. Validating first E-fuse MAC
cpsw, usb_ether
Hit any key to stop autoboot:  0
mmc0 is current device
SD/MMC found on device 0
reading uEnv.txt
** Unable to read file uEnv.txt **
4985376 bytes read in 853 ms (5.6 MiB/s)
29192 bytes read in 28 ms (1017.6 KiB/s)
Booting from mmc ...
## Booting kernel from Legacy Image at 8020 ...
   Image Name:   Linux-3.14.0-yocto-standard
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:4985312 Bytes = 4.8 MiB
   Load Address: 80008000
   Entry Point:  80008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 80f8
   Booting using the fdt blob at 0x80f8
   Loading Kernel Image ... OK
   Using Device Tree in place at 80f8, end 80f8a207

Starting kernel ...

Booting Linux on physical CPU 0x0
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Initializing cgroup subsys cpuacct
Linux version 3.14.0-yocto-standard (paul@ubuntu-build01) (gcc version 4.8.2 
(GCC) ) #1 PREEMPT Mon Apr 14 16:00:52 BST 2014
CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: TI AM335x BeagleBone
cma: CMA: reserved 16 MiB at 9e80
Memory policy: Data cache writeback
CPU: All CPU(s) started in SVC mode.
AM335X ES2.0 (sgx neon )
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 129792
Kernel command line: console=ttyO0,115200n8 root=/dev/mmcblk0p2 ro 
rootfstype=ext4 rootwait
PID hash table entries: 2048 (order: 1, 8192 bytes)
Dentry cache hash table entries:

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Mon, Apr 14, 2014 at 02:11:05PM -0600, Gary Thomas wrote:
> Very interesting results!  These are the results from the build hosts I have:
>   Fedora 13 (i686) - fails
>   Fedora 17 (i686) - fails
>   Ubuntu 12.04 (x86_64) - boots

Interesting indeed. I have no idea what's so special about Fedora host - this 
is the first time I hear about issues with it. I may try experimenting with 
different VMs once I have more time...


> Note that I routinely build for other targets (which does imply other, mostly
> older, kernels) using all of these machines with no differences based on the
> build host.

Same here - building for different targets with different kernels from meta-ti 
and on 32 and 64 bit hosts and never had an issue like that...


> I don't know what's unique about an x86_64 host, but it does seem to work.
> 
> I was trying this to see how the stock Yocto support for the BBB competes with
> building using meta-beaglebone which I've been using successfully.  Based on
> these results, I'll be sticking with the meta-beaglebone approach for now
> (not just for the booting issue, but support for my LCD cape and other things
> that aren't there in the Yocto kernel)

This is not a "Yocto" kernel, this is a vanilla mainline 3.14 kernel (as a 
successor to 3.12 work done in meta-ti). Indeed, cape support is missing, as 
it is still not merged upstream, going through numerous iterations... The 
point of meta-beagleboard was to work on cape support and such, with the goal 
to upstream it, while meta-ti kept on working on SoC and peripheral support. 
Due to different circumstances, meta-beagleboard still uses 3.8 kernel. Once 
it is accepted upstream, it will be part of the mainline kernel and one of the 
later versions of the Yocto Project reference BSP.

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Mon, Apr 14, 2014 at 10:04:41AM -0600, Gary Thomas wrote:
> On 2014-04-14 10:00, Denys Dmytriyenko wrote:
> > On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
> >> On 2014-04-14 09:46, Denys Dmytriyenko wrote:
> >>> On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
> >>>> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
> >>>>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> >>>>>> I just tried building (core-image-sato) for my BeagleBoneBlack
> >>>>>> using the latest Poky/Yocto master:
> >>>>>>
> >>>>>> Build Configuration:
> >>>>>> BB_VERSION= "1.23.0"
> >>>>>> BUILD_SYS = "i686-linux"
> >>>>>> NATIVELSBSTRING   = "Fedora-13"
> >>>>>> TARGET_SYS= "arm-poky-linux-gnueabi"
> >>>>>> MACHINE   = "beaglebone"
> >>>>>> DISTRO= "poky"
> >>>>>> DISTRO_VERSION= "1.6+snapshot-20140411"
> >>>>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> >>>>>> TARGET_FPU= "vfp-neon"
> >>>>>> meta
> >>>>>> meta-yocto
> >>>>>> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >>>>>>
> >>>>>> This built the kernel using SRCREV 928d7b2dda
> >>>>>>
> >>>>>> I followed the bring-up instructions from README.hadware and the
> >>>>>> boot failed to even start the kernel.  Here's what I see:
> >>>>>>
> >>>>>> === boot log 
> >>>>>> =
> >>>>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >>>>>>
> >>>>>> I2C:   ready
> >>>>>> DRAM:  512 MiB
> >>>>>> WARNING: Caches not enabled
> >>>>>> NAND:  0 MiB
> >>>>>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >>>>>> *** Warning - readenv() failed, using default environment
> >>>>>>
> >>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> >>>>>> SoftConn)
> >>>>>> musb-hdrc: MHDRC RTL version 2.0
> >>>>>> musb-hdrc: setup fifo_mode 4
> >>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >>>>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> >>>>>> SoftConn)
> >>>>>> musb-hdrc: MHDRC RTL version 2.0
> >>>>>> musb-hdrc: setup fifo_mode 4
> >>>>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>>>> USB Host mode controller at 47401800 using PIO, IRQ 0
> >>>>>> Net:not set. Validating first E-fuse MAC
> >>>>>> Phy not found
> >>>>>> PHY reset timed out
> >>>>>> cpsw, usb_ether
> >>>>>> Hit any key to stop autoboot:  0
> >>>>>> mmc0 is current device
> >>>>>> SD/MMC found on device 0
> >>>>>> reading uEnv.txt
> >>>>>> ** Unable to read file uEnv.txt **
> >>>>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
> >>>>>> 29192 bytes read in 46 ms (619.1 KiB/s)
> >>>>>> Booting from mmc ...
> >>>>>> ## Booting kernel from Legacy Image at 8020 ...
> >>>>>>Image Name:   Linux-3.14.0-yocto-standard
> >>>>>>Image Type:   ARM Linux Kernel Image (uncompressed)
> >>>>>>Data Size:4981624 Bytes = 4.8 MiB
> >>>>>>Load Address: 80008000
> >>>>>>Entry Point:  80008000
> >>>>>>Verifying Checksum ... OK
> >>>>>> ## Flattened Device Tree blob at 80f8
> >>>>>>Booting using the fdt blob at 0x80f8
> >>>>>>Loading Kernel Image ... OK
> >>>>>>Using Device Tree in place at 80f8, end 80f8a207
> >>>>>>
> >>>>>> Starting kernel ...
> >>>>

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Mon, Apr 14, 2014 at 09:51:49AM -0600, Gary Thomas wrote:
> On 2014-04-14 09:46, Denys Dmytriyenko wrote:
> > On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
> >> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
> >>> On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> >>>> I just tried building (core-image-sato) for my BeagleBoneBlack
> >>>> using the latest Poky/Yocto master:
> >>>>
> >>>> Build Configuration:
> >>>> BB_VERSION= "1.23.0"
> >>>> BUILD_SYS = "i686-linux"
> >>>> NATIVELSBSTRING   = "Fedora-13"
> >>>> TARGET_SYS= "arm-poky-linux-gnueabi"
> >>>> MACHINE   = "beaglebone"
> >>>> DISTRO= "poky"
> >>>> DISTRO_VERSION= "1.6+snapshot-20140411"
> >>>> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> >>>> TARGET_FPU= "vfp-neon"
> >>>> meta
> >>>> meta-yocto
> >>>> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >>>>
> >>>> This built the kernel using SRCREV 928d7b2dda
> >>>>
> >>>> I followed the bring-up instructions from README.hadware and the
> >>>> boot failed to even start the kernel.  Here's what I see:
> >>>>
> >>>> === boot log 
> >>>> =
> >>>> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >>>>
> >>>> I2C:   ready
> >>>> DRAM:  512 MiB
> >>>> WARNING: Caches not enabled
> >>>> NAND:  0 MiB
> >>>> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >>>> *** Warning - readenv() failed, using default environment
> >>>>
> >>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> >>>> SoftConn)
> >>>> musb-hdrc: MHDRC RTL version 2.0
> >>>> musb-hdrc: setup fifo_mode 4
> >>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >>>> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> >>>> SoftConn)
> >>>> musb-hdrc: MHDRC RTL version 2.0
> >>>> musb-hdrc: setup fifo_mode 4
> >>>> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >>>> USB Host mode controller at 47401800 using PIO, IRQ 0
> >>>> Net:not set. Validating first E-fuse MAC
> >>>> Phy not found
> >>>> PHY reset timed out
> >>>> cpsw, usb_ether
> >>>> Hit any key to stop autoboot:  0
> >>>> mmc0 is current device
> >>>> SD/MMC found on device 0
> >>>> reading uEnv.txt
> >>>> ** Unable to read file uEnv.txt **
> >>>> 4981688 bytes read in 613 ms (7.7 MiB/s)
> >>>> 29192 bytes read in 46 ms (619.1 KiB/s)
> >>>> Booting from mmc ...
> >>>> ## Booting kernel from Legacy Image at 8020 ...
> >>>>Image Name:   Linux-3.14.0-yocto-standard
> >>>>Image Type:   ARM Linux Kernel Image (uncompressed)
> >>>>Data Size:4981624 Bytes = 4.8 MiB
> >>>>Load Address: 80008000
> >>>>Entry Point:  80008000
> >>>>Verifying Checksum ... OK
> >>>> ## Flattened Device Tree blob at 80f8
> >>>>Booting using the fdt blob at 0x80f8
> >>>>Loading Kernel Image ... OK
> >>>>Using Device Tree in place at 80f8, end 80f8a207
> >>>>
> >>>> Starting kernel ...
> >>>> ==
> >>>>
> >>>> Any ideas what I've done wrong?
> >>>
> >>> Hmm, everything looks sane. What revision is your BBB? And did you press 
> >>> USER/BOOT button or erased eMMC partition per instructions?
> >>>
> >>
> >> Revision A5A, with an LCD cape
> > 
> > Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in 
> > this BSP. Can you try w/o it?
> 
> Sure I can try it but I don't think that's it.  I got the kernel that StefanX
> built and booted and tried it on my board and it came up.  No clue why the
> kernels are different - ostensibly we both built the same image from the same
> meta data, but they are slightly different (only in size - I compared the
> System.map files from both builds and they contain exactly the same bits,
> just a few changes in memory layout which I can't explain).

Yeah, good point. Doesn't look like your cape causes the issue...
The only other difference is in the host. Do you have access to another Linux 
box you can try? FWIW, I'm using 64-bit Gentoo with gcc-4.7.3. Yours is 32-bit 
Fedora 13, right?


> I'm trying another build from scratch using a different build host to see
> if that makes a difference.

Do you have any other layers or customizations on top? (the metadata above 
suggests you build just pure Poky though)

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

Re: [yocto] New RC for 1.6.

[Denys Dmytriyenko]

On Thu, Apr 10, 2014 at 10:15:49PM -0700, Flanagan, Elizabeth wrote:
> All,
> 
> A few much needed bug fixes came in to fix some of the issues we saw
> with rc3. We decided that we should just roll and rc4. Please begin
> testing this as soon as possible.
> 
> We're seeing one issue on the world build:
> 
> http://autobuilder.yoctoproject.org/main/builders/nightly-world/builds/42/steps/BuildImages/logs/stdio
> 
> but as this produces no published artifacts, I think we're ok with at
> least the release artifacts.
> 
> http://autobuilder.yoctoproject.org/pub/releases/yocto-1.6_M5.rc4
> 
> bitbake bb4980c63db386ce7d30d9a6b86e9f3861b3bc3a
> eclipse-poky-juno 26bfc407781aa185f244a47ba63120343cee4a37
> eclipse-poky-kepler 1dfe1d2f1322b5fda8e1a7637c447b0e060efb3e
> meta-fsl-arm d4316faef78ceb01ff023579e15110939ec69408
> meta-fsl-ppc c4fa1b431f4efc4982a168119db95236cfa8cad3
> meta-intel db84acfc8d9ed8dccd4a79de39fee337bc729662
> meta-minnow 7bdcd1140b729598bae6246a4bbc21c3950aadd8
> meta-qt3 3016129d90b7ac8517a5227d819f10ad417b5b45
> oecore dca1b4f073fff740364f066f6a68bb3c8697b7a6
> poky a0958261265049904fd78a2ba0198d46e5e65ea9

And the question I have is how one gets his own layers into Yocto 
autobuilder?

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Mon, Apr 14, 2014 at 04:25:55AM -0600, Gary Thomas wrote:
> On 2014-04-13 20:33, Denys Dmytriyenko wrote:
> > On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> >> I just tried building (core-image-sato) for my BeagleBoneBlack
> >> using the latest Poky/Yocto master:
> >>
> >> Build Configuration:
> >> BB_VERSION= "1.23.0"
> >> BUILD_SYS = "i686-linux"
> >> NATIVELSBSTRING   = "Fedora-13"
> >> TARGET_SYS= "arm-poky-linux-gnueabi"
> >> MACHINE   = "beaglebone"
> >> DISTRO= "poky"
> >> DISTRO_VERSION= "1.6+snapshot-20140411"
> >> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> >> TARGET_FPU= "vfp-neon"
> >> meta
> >> meta-yocto
> >> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> >>
> >> This built the kernel using SRCREV 928d7b2dda
> >>
> >> I followed the bring-up instructions from README.hadware and the
> >> boot failed to even start the kernel.  Here's what I see:
> >>
> >> === boot log 
> >> =
> >> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> >>
> >> I2C:   ready
> >> DRAM:  512 MiB
> >> WARNING: Caches not enabled
> >> NAND:  0 MiB
> >> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> >> *** Warning - readenv() failed, using default environment
> >>
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> >> SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> >> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, 
> >> SoftConn)
> >> musb-hdrc: MHDRC RTL version 2.0
> >> musb-hdrc: setup fifo_mode 4
> >> musb-hdrc: 28/31 max ep, 16384/16384 memory
> >> USB Host mode controller at 47401800 using PIO, IRQ 0
> >> Net:not set. Validating first E-fuse MAC
> >> Phy not found
> >> PHY reset timed out
> >> cpsw, usb_ether
> >> Hit any key to stop autoboot:  0
> >> mmc0 is current device
> >> SD/MMC found on device 0
> >> reading uEnv.txt
> >> ** Unable to read file uEnv.txt **
> >> 4981688 bytes read in 613 ms (7.7 MiB/s)
> >> 29192 bytes read in 46 ms (619.1 KiB/s)
> >> Booting from mmc ...
> >> ## Booting kernel from Legacy Image at 8020 ...
> >>Image Name:   Linux-3.14.0-yocto-standard
> >>Image Type:   ARM Linux Kernel Image (uncompressed)
> >>Data Size:4981624 Bytes = 4.8 MiB
> >>Load Address: 80008000
> >>Entry Point:  80008000
> >>Verifying Checksum ... OK
> >> ## Flattened Device Tree blob at 80f8
> >>Booting using the fdt blob at 0x80f8
> >>Loading Kernel Image ... OK
> >>Using Device Tree in place at 80f8, end 80f8a207
> >>
> >> Starting kernel ...
> >> ==
> >>
> >> Any ideas what I've done wrong?
> > 
> > Hmm, everything looks sane. What revision is your BBB? And did you press 
> > USER/BOOT button or erased eMMC partition per instructions?
> > 
> 
> Revision A5A, with an LCD cape

Hmm, I'm wondering if LCD cape conflicts here - there's no cape support in 
this BSP. Can you try w/o it?

As of the board revision - I was testing on different ones from A1 to A6 and 
didn't see any major issue...

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

Re: [yocto] BBB doesn't boot

[Denys Dmytriyenko]

On Sun, Apr 13, 2014 at 03:12:16AM -0600, Gary Thomas wrote:
> I just tried building (core-image-sato) for my BeagleBoneBlack
> using the latest Poky/Yocto master:
> 
> Build Configuration:
> BB_VERSION= "1.23.0"
> BUILD_SYS = "i686-linux"
> NATIVELSBSTRING   = "Fedora-13"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "beaglebone"
> DISTRO= "poky"
> DISTRO_VERSION= "1.6+snapshot-20140411"
> TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa8"
> TARGET_FPU= "vfp-neon"
> meta
> meta-yocto
> meta-yocto-bsp= "master:863cc7483f5ee43189537940de8ee5c0964d24cc"
> 
> This built the kernel using SRCREV 928d7b2dda
> 
> I followed the bring-up instructions from README.hadware and the
> boot failed to even start the kernel.  Here's what I see:
> 
> === boot log 
> =
> U-Boot 2013.07 (Apr 11 2014 - 15:03:04)
> 
> I2C:   ready
> DRAM:  512 MiB
> WARNING: Caches not enabled
> NAND:  0 MiB
> MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
> *** Warning - readenv() failed, using default environment
> 
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Peripheral mode controller at 47401000 using PIO, IRQ 0
> musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, HB-ISO Rx, HB-ISO Tx, SoftConn)
> musb-hdrc: MHDRC RTL version 2.0
> musb-hdrc: setup fifo_mode 4
> musb-hdrc: 28/31 max ep, 16384/16384 memory
> USB Host mode controller at 47401800 using PIO, IRQ 0
> Net:not set. Validating first E-fuse MAC
> Phy not found
> PHY reset timed out
> cpsw, usb_ether
> Hit any key to stop autoboot:  0
> mmc0 is current device
> SD/MMC found on device 0
> reading uEnv.txt
> ** Unable to read file uEnv.txt **
> 4981688 bytes read in 613 ms (7.7 MiB/s)
> 29192 bytes read in 46 ms (619.1 KiB/s)
> Booting from mmc ...
> ## Booting kernel from Legacy Image at 8020 ...
>Image Name:   Linux-3.14.0-yocto-standard
>Image Type:   ARM Linux Kernel Image (uncompressed)
>Data Size:4981624 Bytes = 4.8 MiB
>Load Address: 80008000
>Entry Point:  80008000
>Verifying Checksum ... OK
> ## Flattened Device Tree blob at 80f8
>Booting using the fdt blob at 0x80f8
>Loading Kernel Image ... OK
>Using Device Tree in place at 80f8, end 80f8a207
> 
> Starting kernel ...
> ==
> 
> Any ideas what I've done wrong?

Hmm, everything looks sane. What revision is your BBB? And did you press 
USER/BOOT button or erased eMMC partition per instructions?

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

Re: [yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates

[Denys Dmytriyenko]

On Thu, Apr 10, 2014 at 04:35:51PM +, Stanacar, StefanX wrote:
> 
> 
> 
> On Thu, 2014-04-10 at 11:58 -0400, Denys Dmytriyenko wrote:
> > On Thu, Apr 10, 2014 at 03:27:43PM +, Stanacar, StefanX wrote:
> > > 
> > > 
> > > 
> > > On Thu, 2014-04-10 at 14:14 +, Stanacar, StefanX wrote:
> > > > 
> > > > 
> > > > On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:
> > > > > Hi Denys,
> > > > > 
> > > > > With this patch applied and the updated README I can boot a Beaglebone
> > > > > Black (rev A6) with a default yocto image/config (I've used
> > > > > core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of 
> > > > > tests
> > > > > on the image, except for X - it doesn't start :(.
> > > > > I've built with fbdev and omapfb too.
> > > > > 
> > > > > X log for fbdev: 
> > > > > http://pastebin.com/sqNc35U0
> > > > > 
> > > > > for omapfb:
> > > > > http://pastebin.com/fMkzMW8U
> > > > > 
> > > > > Is there anything else that needs to changed/added? I could add a
> > > > > xorg.conf on the image too, but then it beats the point...
> > > > > 
> > > > 
> > > > What I was trying to say is that we are missing a .bbappend for
> > > > xserver-xf86-config that adds the right xorg.conf (either for fbdev or
> > > > omapfb). I'll try to come up with one.
> > > 
> > > 
> > > Okay ignore that it didn't helped, I think I know what's missing.. I
> > > need the latest SRCREV_meta for kernel.
> > 
> > Sorry for the delay - yes, couple tweaks are needed from BSP as well.
> 
> I've rebuit with latest SRCREV_meta and indeed X starts fine now,
> thanks.

Great, thanks for verifying it!

-- 
Denys


> > > > > On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> > > > > > From: Denys Dmytriyenko 
> > > > > > 
> > > > > > * Use fbdev video driver for xserver-xorg
> > > > > > * Recommend installing device tree DTB files into rootfs /boot 
> > > > > > directory
> > > > > > * Switch back to uImage kernel format from zImage, as U-boot was 
> > > > > > not updated
> > > > > >   - default has changed to zImage in newer U-boot 2013.10+, but we 
> > > > > > use 2013.07
> > > > > > * Correct copy/paste typo in serial console
> > > > > > 
> > > > > > Signed-off-by: Denys Dmytriyenko 
> > > > > > ---
> > > > > >  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
> > > > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > > > 
> > > > > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> > > > > > b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > > index f2ef0cf..4263715 100644
> > > > > > --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > > +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > > > @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= 
> > > > > > "xserver-xorg"
> > > > > >  XSERVER ?= "xserver-xorg \
> > > > > > xf86-input-evdev \
> > > > > > xf86-input-mouse \
> > > > > > -   xf86-video-omapfb \
> > > > > > +   xf86-video-fbdev \
> > > > > > xf86-input-keyboard"
> > > > > >  
> > > > > > -# Ship all kernel modules by default
> > > > > > -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> > > > > > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
> > > > > >  
> > > > > >  EXTRA_IMAGEDEPENDS += "u-boot"
> > > > > >  
> > > > > > @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
> > > > > >  IMAGE_FSTYPES += "tar.bz2 jffs2"
> > > > > >  EXTRA_IMAGECMD_jffs2 = "-lnp "
> > > > > >  
> > > > > > -SERIAL_CONSOLE = "115200 ttyO2"
> > > > > > +SERIAL_CONSOLE = "115200 ttyO0"
> > > > > >  
> > > > > >  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> > > > > >  PREFERRED_VERSION_linux-yocto ?= "3.14%"
> > > > > >  
> > > > > > -KERNEL_IMAGETYPE = "zImage"
> > > > > > +KERNEL_IMAGETYPE = "uImage"
> > > > > >  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> > > > > > +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
> > > > > >  
> > > > > >  SPL_BINARY = "MLO"
> > > > > >  UBOOT_SUFFIX = "img"
> > > > > > -- 
> > > > > > 1.9.1
> > > > > > 
> > > > > 
> > > > 
> > > 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Why increment PRINC by 2?

[Denys Dmytriyenko]

On Thu, Apr 10, 2014 at 12:23:31PM -0400, Denys Dmytriyenko wrote:
> On Thu, Apr 10, 2014 at 11:55:08AM -0400, Patrick Doyle wrote:
> > The BSP guide gives the following helpful tip for installing a custom
> > /etc/network/interfaces file (see
> > https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp
> > -- and thank you, BTW -- that addressed a specific problem I needed to
> > solve):
> > 
> > 1. Edit the init-ifupdown_1.0.bbappend file so that it contains the 
> > following:
> > 
> >  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >  PRINC := "${@int(PRINC) + 2}"
> > 
> > 
> > The append file needs to be in the meta-xyz/recipes-core/init-ifupdown
> > directory.
> > 
> > 2. Create and place the new interfaces configuration file in the BSP's
> > layer here:
> > 
> >  meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
> > 
> > In my continuing attempt to understand the mindset of Yocto
> > practitioners, I would appreciate any light folks can shed on this... it
> > opens up so many questions to me...
> > 
> > 1) Why does FILESEXTRAPATHS exist?  The documentation says, "You can
> > extend FILESPATH variable by using FILESEXTRAPATHS."  Errr, can't one
> > extend FILESPATH with
> > 
> > FILESPATH = "blah:" + $FILESPATH
> > 
> > or
> > FILESPATH_prepend = "blah:"
> > 
> > I see that the documentation for FILESPATH specifically states:
> > 
> > "Do not hand-edit the FILESPATH variable. If you want the build system
> > to look in directories other than the defaults, extend the FILESPATH
> > variable by using the FILESEXTRAPATHS variable."
> > 
> > but that doesn't help me understand why this method is preferred for
> > extending FILESPATH.
> > 
> > 2) Why does PRINC exist?  The documentation says that PRINC "causes
> > the PR variable of .bbappend files to dynamically increment" and that
> > "This increment minimizes the impact of layer ordering."  I guess that
> > means that the init-ifupdown_1.0.bb file has some revision (which I
> > think is "1.0") and that, when my .bbappend file is appended to it,
> > causes the recipe to effectively be "3.0".  Why do I care?  If there
> > is an "init-ifupdown_5.0.bb" file someplace in my search path, won't I
> > get that one anyway?  How does this minimize the impact of layer
> > ordering?
> 
> That is PV (package version) you are thinking of. But PRINC increments PR 
> (package revision).
> 
> PR is not used in the recipe names, but rather in resulting binary packages. 
> So your init-ifupdown_1.0.bb/bbappend will result in a binary package of 
> init-ifupdown_1.0-r0_.ipk/rpm
> 
> That portion -r0 will be incremented, becoming -r2 or the original+2 (can be 
> any number)
> 
> PV usually corresponds to changes in the sources, while PR corresponds to 
> changes in the recipe. If a recipe is composed from multiple parts (.inc file 
> or .bbappend) you may want to distinguish that.
> 
> As an alternative, some distro chose to append a more meaningful suffix to PR 
> instead of just incrementing PR. I.e. our Arago distro appends "-aragoX" 
> where 
> X is the number of revisions we made in our distro on top of the main recipe. 
> The end result of the package version will be "3.5-r6-arago2". It means the 
> sources for the package are of version 3.5, the main recipe was updated 6 
> times and there were also 2 more recipe bbappend updates by the distro...
> 
> It's a common practice in Linux Distro world - Ubuntu uses the same 
> principle, 
> when updating packages inherited from Debian, e.g. bash_4.1-2ubuntu3_i386.deb

Ah, and forgot to mention the new way of dealing with PR increments:
https://wiki.yoctoproject.org/wiki/PR_Service


> > Oh yeah, and why increment by 2?  Why not 1, or pi?
> > 
> > I guess I only had 2 questions... but 1,000,000 subquestions :-)
> > 
> > Thanks for any tips you can give me.
> > 
> > --wpd
> > -- 
> > ___
> > 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 mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Why increment PRINC by 2?

[Denys Dmytriyenko]

On Thu, Apr 10, 2014 at 11:55:08AM -0400, Patrick Doyle wrote:
> The BSP guide gives the following helpful tip for installing a custom
> /etc/network/interfaces file (see
> https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html#customizing-a-recipe-for-a-bsp
> -- and thank you, BTW -- that addressed a specific problem I needed to
> solve):
> 
> 1. Edit the init-ifupdown_1.0.bbappend file so that it contains the following:
> 
>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>  PRINC := "${@int(PRINC) + 2}"
> 
> 
> The append file needs to be in the meta-xyz/recipes-core/init-ifupdown
> directory.
> 
> 2. Create and place the new interfaces configuration file in the BSP's
> layer here:
> 
>  meta-xyz/recipes-core/init-ifupdown/files/xyz/interfaces
> 
> In my continuing attempt to understand the mindset of Yocto
> practitioners, I would appreciate any light folks can shed on this... it
> opens up so many questions to me...
> 
> 1) Why does FILESEXTRAPATHS exist?  The documentation says, "You can
> extend FILESPATH variable by using FILESEXTRAPATHS."  Errr, can't one
> extend FILESPATH with
> 
> FILESPATH = "blah:" + $FILESPATH
> 
> or
> FILESPATH_prepend = "blah:"
> 
> I see that the documentation for FILESPATH specifically states:
> 
> "Do not hand-edit the FILESPATH variable. If you want the build system
> to look in directories other than the defaults, extend the FILESPATH
> variable by using the FILESEXTRAPATHS variable."
> 
> but that doesn't help me understand why this method is preferred for
> extending FILESPATH.
> 
> 2) Why does PRINC exist?  The documentation says that PRINC "causes
> the PR variable of .bbappend files to dynamically increment" and that
> "This increment minimizes the impact of layer ordering."  I guess that
> means that the init-ifupdown_1.0.bb file has some revision (which I
> think is "1.0") and that, when my .bbappend file is appended to it,
> causes the recipe to effectively be "3.0".  Why do I care?  If there
> is an "init-ifupdown_5.0.bb" file someplace in my search path, won't I
> get that one anyway?  How does this minimize the impact of layer
> ordering?

That is PV (package version) you are thinking of. But PRINC increments PR 
(package revision).

PR is not used in the recipe names, but rather in resulting binary packages. 
So your init-ifupdown_1.0.bb/bbappend will result in a binary package of 
init-ifupdown_1.0-r0_.ipk/rpm

That portion -r0 will be incremented, becoming -r2 or the original+2 (can be 
any number)

PV usually corresponds to changes in the sources, while PR corresponds to 
changes in the recipe. If a recipe is composed from multiple parts (.inc file 
or .bbappend) you may want to distinguish that.

As an alternative, some distro chose to append a more meaningful suffix to PR 
instead of just incrementing PR. I.e. our Arago distro appends "-aragoX" where 
X is the number of revisions we made in our distro on top of the main recipe. 
The end result of the package version will be "3.5-r6-arago2". It means the 
sources for the package are of version 3.5, the main recipe was updated 6 
times and there were also 2 more recipe bbappend updates by the distro...

It's a common practice in Linux Distro world - Ubuntu uses the same principle, 
when updating packages inherited from Debian, e.g. bash_4.1-2ubuntu3_i386.deb

-- 
Denys


> Oh yeah, and why increment by 2?  Why not 1, or pi?
> 
> I guess I only had 2 questions... but 1,000,000 subquestions :-)
> 
> Thanks for any tips you can give me.
> 
> --wpd
> -- 
> ___
> 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] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates

[Denys Dmytriyenko]

On Thu, Apr 10, 2014 at 03:27:43PM +, Stanacar, StefanX wrote:
> 
> 
> 
> On Thu, 2014-04-10 at 14:14 +, Stanacar, StefanX wrote:
> > 
> > 
> > On Thu, 2014-04-10 at 13:36 +, Stanacar, StefanX wrote:
> > > Hi Denys,
> > > 
> > > With this patch applied and the updated README I can boot a Beaglebone
> > > Black (rev A6) with a default yocto image/config (I've used
> > > core-image-sato-sdk FWIW). Everything seems fine, I ran a bunch of tests
> > > on the image, except for X - it doesn't start :(.
> > > I've built with fbdev and omapfb too.
> > > 
> > > X log for fbdev: 
> > > http://pastebin.com/sqNc35U0
> > > 
> > > for omapfb:
> > > http://pastebin.com/fMkzMW8U
> > > 
> > > Is there anything else that needs to changed/added? I could add a
> > > xorg.conf on the image too, but then it beats the point...
> > > 
> > 
> > What I was trying to say is that we are missing a .bbappend for
> > xserver-xf86-config that adds the right xorg.conf (either for fbdev or
> > omapfb). I'll try to come up with one.
> 
> 
> Okay ignore that it didn't helped, I think I know what's missing.. I
> need the latest SRCREV_meta for kernel.

Sorry for the delay - yes, couple tweaks are needed from BSP as well.


> > > On Thu, 2014-04-10 at 04:02 -0400, Denys Dmytriyenko wrote:
> > > > From: Denys Dmytriyenko 
> > > > 
> > > > * Use fbdev video driver for xserver-xorg
> > > > * Recommend installing device tree DTB files into rootfs /boot directory
> > > > * Switch back to uImage kernel format from zImage, as U-boot was not 
> > > > updated
> > > >   - default has changed to zImage in newer U-boot 2013.10+, but we use 
> > > > 2013.07
> > > > * Correct copy/paste typo in serial console
> > > > 
> > > > Signed-off-by: Denys Dmytriyenko 
> > > > ---
> > > >  meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
> > > >  1 file changed, 5 insertions(+), 5 deletions(-)
> > > > 
> > > > diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
> > > > b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > index f2ef0cf..4263715 100644
> > > > --- a/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > +++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
> > > > @@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
> > > >  XSERVER ?= "xserver-xorg \
> > > > xf86-input-evdev \
> > > > xf86-input-mouse \
> > > > -   xf86-video-omapfb \
> > > > +   xf86-video-fbdev \
> > > > xf86-input-keyboard"
> > > >  
> > > > -# Ship all kernel modules by default
> > > > -MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
> > > > +MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
> > > >  
> > > >  EXTRA_IMAGEDEPENDS += "u-boot"
> > > >  
> > > > @@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
> > > >  IMAGE_FSTYPES += "tar.bz2 jffs2"
> > > >  EXTRA_IMAGECMD_jffs2 = "-lnp "
> > > >  
> > > > -SERIAL_CONSOLE = "115200 ttyO2"
> > > > +SERIAL_CONSOLE = "115200 ttyO0"
> > > >  
> > > >  PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> > > >  PREFERRED_VERSION_linux-yocto ?= "3.14%"
> > > >  
> > > > -KERNEL_IMAGETYPE = "zImage"
> > > > +KERNEL_IMAGETYPE = "uImage"
> > > >  KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
> > > > +KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
> > > >  
> > > >  SPL_BINARY = "MLO"
> > > >  UBOOT_SUFFIX = "img"
> > > > -- 
> > > > 1.9.1
> > > > 
> > > 
> > 
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-yocto][PATCH 2/2] README.hardware: update with Texas Instruments Beaglebone instructions

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Replaces outdated Beagleboard instructions with Beaglebone Black (and White).

Signed-off-by: Denys Dmytriyenko 
---
 README.hardware | 78 +
 1 file changed, 78 insertions(+)

diff --git a/README.hardware b/README.hardware
index 68e1dd2..37fdab0 100644
--- a/README.hardware
+++ b/README.hardware
@@ -46,6 +46,7 @@ Hardware Reference Boards
 
 The following boards are supported by the meta-yocto-bsp layer:
 
+  * Texas Instruments Beaglebone (beaglebone)
   * Freescale MPC8315E-RDB (mpc8315e-rdb)
 
 For more information see the board's section below. The appropriate MACHINE
@@ -179,6 +180,83 @@ USB Device:
   
http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob_plain;f=doc/usbkey.txt;hb=HEAD
 
 
+Texas Instruments Beaglebone (beaglebone)
+=
+
+The Beaglebone is an ARM Cortex-A8 development board with USB, Ethernet, 2D/3D
+accelerated graphics, audio, serial, JTAG, and SD/MMC. The Black adds a faster
+CPU, more RAM, eMMC flash and a micro HDMI port. The beaglebone MACHINE is
+tested on the following platforms:
+
+  o Beaglebone Black A6
+  o Beaglebone A6 (the original "White" model)
+
+The Beaglebone Black has eMMC, while the White does not. Pressing the USER/BOOT
+button when powering on will temporarily change the boot order. But for the 
sake
+of simplicity, these instructions assume you have erased the eMMC on the Black,
+so its boot behavior matches that of the White and boots off of SD card. To do
+this, issue the following commands from the u-boot prompt:
+
+# mmc dev 1
+# mmc erase 0 512
+
+To further tailor these instructions for your board, please refer to the
+documentation at http://www.beagleboard.org/bone and 
http://www.beagleboard.org/black
+
+From a Linux system with access to the image files perform the following steps
+as root, replacing mmcblk0* with the SD card device on your machine (such as 
sdc
+if used via a usb card reader):
+
+  1. Partition and format an SD card:
+ # fdisk -lu /dev/mmcblk0
+
+ Disk /dev/mmcblk0: 3951 MB, 3951034368 bytes
+ 255 heads, 63 sectors/track, 480 cylinders, total 7716864 sectors
+ Units = sectors of 1 * 512 = 512 bytes
+
+ Device Boot  Start End  Blocks  Id System
+ /dev/mmcblk0p1   *  63  144584   72261   c Win95 FAT32 
(LBA)
+ /dev/mmcblk0p2  144585  465884  160650  83 Linux
+
+ # mkfs.vfat -F 16 -n "boot" /dev/mmcblk0p1
+ # mke2fs -j -L "root" /dev/mmcblk0p2
+
+  The following assumes the SD card partitions 1 and 2 are mounted at
+  /media/boot and /media/root respectively. Removing the card and reinserting
+  it will do just that on most modern Linux desktop environments.
+
+  The files referenced below are made available after the build in
+  build/tmp/deploy/images.
+
+  2. Install the boot loaders
+ # cp MLO-beaglebone /media/boot/MLO
+ # cp u-boot-beaglebone.img /media/boot/u-boot.img
+
+  3. Install the root filesystem
+ # tar x -C /media/root -f core-image-$IMAGE_TYPE-beaglebone.tar.bz2
+
+  4. If using core-image-base or core-image-sato images, the SD card is ready
+ and rootfs already contains the kernel, modules and device tree (DTB)
+ files necessary to be booted with U-boot's default configuration, so
+ skip directly to step 8.
+ For core-image-minimal, proceed through next steps.
+
+  5. If using core-image-minimal rootfs, install the modules
+ # tar x -C /media/root -f modules-beaglebone.tgz
+
+  6. If using core-image-minimal rootfs, install the kernel uImage into /boot
+ directory of rootfs
+ # cp uImage-beaglebone.bin /media/root/boot/uImage
+
+  7. If using core-image-minimal rootfs, also install device tree (DTB) files
+ into /boot directory of rootfs
+ # cp uImage-am335x-bone.dtb /media/root/boot/am335x-bone.dtb
+ # cp uImage-am335x-boneblack.dtb /media/root/boot/am335x-boneblack.dtb
+
+  8. Unmount the SD partitions, insert the SD card into the Beaglebone, and
+ boot the Beaglebone
+
+
 Freescale MPC8315E-RDB (mpc8315e-rdb)
 =
 
-- 
1.9.1

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

[yocto] [meta-yocto][PATCH 1/2] beaglebone.conf: configuration updates

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

* Use fbdev video driver for xserver-xorg
* Recommend installing device tree DTB files into rootfs /boot directory
* Switch back to uImage kernel format from zImage, as U-boot was not updated
  - default has changed to zImage in newer U-boot 2013.10+, but we use 2013.07
* Correct copy/paste typo in serial console

Signed-off-by: Denys Dmytriyenko 
---
 meta-yocto-bsp/conf/machine/beaglebone.conf | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
b/meta-yocto-bsp/conf/machine/beaglebone.conf
index f2ef0cf..4263715 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
@@ -6,11 +6,10 @@ PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
 XSERVER ?= "xserver-xorg \
xf86-input-evdev \
xf86-input-mouse \
-   xf86-video-omapfb \
+   xf86-video-fbdev \
xf86-input-keyboard"
 
-# Ship all kernel modules by default
-MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
+MACHINE_EXTRA_RRECOMMENDS = " kernel-modules kernel-devicetree"
 
 EXTRA_IMAGEDEPENDS += "u-boot"
 
@@ -20,13 +19,14 @@ include conf/machine/include/tune-cortexa8.inc
 IMAGE_FSTYPES += "tar.bz2 jffs2"
 EXTRA_IMAGECMD_jffs2 = "-lnp "
 
-SERIAL_CONSOLE = "115200 ttyO2"
+SERIAL_CONSOLE = "115200 ttyO0"
 
 PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
 PREFERRED_VERSION_linux-yocto ?= "3.14%"
 
-KERNEL_IMAGETYPE = "zImage"
+KERNEL_IMAGETYPE = "uImage"
 KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
+KERNEL_EXTRA_ARGS += "LOADADDR=${UBOOT_ENTRYPOINT}"
 
 SPL_BINARY = "MLO"
 UBOOT_SUFFIX = "img"
-- 
1.9.1

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

Re: [yocto] OEDAM updates

[Denys Dmytriyenko]

On Mon, Apr 07, 2014 at 04:01:57PM -0700, Philip Balister wrote:
> Once again, please add yourself (or email Jefro or myself) if you plan
> to attend OEDAM. We have room for about 5-10 more people.
> 
> http://www.openembedded.org/wiki/OEDAM
> 
> We should also get serious about creating an agenda. Even if you are not
> able to attend please take a look at the agenda and add topics you think
> should be discussed. We'll likely have to review the agenda when we
> start, but now is a good time to air your grievances.

I'm not sure how many will be staying all day Saturday, but can we try to 
group agenda topics so most pressing matters fall on Friday and maybe Saturday 
morning?

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

[yocto] [PATCH] beaglebone: fix typo in the U-Boot config name

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Signed-off-by: Denys Dmytriyenko 
---
 meta-yocto-bsp/conf/machine/beaglebone.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
b/meta-yocto-bsp/conf/machine/beaglebone.conf
index 1dcf351..8b474a5 100644
--- a/meta-yocto-bsp/conf/machine/beaglebone.conf
+++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
@@ -30,7 +30,7 @@ KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
 
 SPL_BINARY = "MLO"
 UBOOT_SUFFIX = "img"
-UBOOT_MACHINE = "am335_evm_config"
+UBOOT_MACHINE = "am335x_evm_config"
 UBOOT_ENTRYPOINT = "0x80008000"
 UBOOT_LOADADDRESS = "0x80008000"
 
-- 
1.9.1

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

[yocto] [meta-yocto][PATCH] beaglebone: add OE machine definition for use with linux-yocto kernels

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

Kernel support is now in linux-yocto-dev and will be moved to a versioned
recipe once 3.14 is released.

Signed-off-by: Denys Dmytriyenko 
Cc: Bruce Ashfield 
---
 meta-yocto-bsp/conf/machine/beaglebone.conf| 37 ++
 .../recipes-kernel/linux/linux-yocto-dev.bbappend  |  3 ++
 2 files changed, 40 insertions(+)
 create mode 100644 meta-yocto-bsp/conf/machine/beaglebone.conf
 create mode 100644 meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend

diff --git a/meta-yocto-bsp/conf/machine/beaglebone.conf 
b/meta-yocto-bsp/conf/machine/beaglebone.conf
new file mode 100644
index 000..0765b33
--- /dev/null
+++ b/meta-yocto-bsp/conf/machine/beaglebone.conf
@@ -0,0 +1,37 @@
+#@TYPE: Machine
+#@NAME: Beaglebone machine
+#@DESCRIPTION: Machine configuration for http://beagleboard.org/bone and 
http://beagleboard.org/black boards
+
+PREFERRED_PROVIDER_virtual/xserver ?= "xserver-xorg"
+XSERVER ?= "xserver-xorg \
+   xf86-input-evdev \
+   xf86-input-mouse \
+   xf86-video-omapfb \
+   xf86-input-keyboard"
+
+# Ship all kernel modules by default
+MACHINE_EXTRA_RRECOMMENDS = " kernel-modules"
+
+EXTRA_IMAGEDEPENDS += "u-boot"
+
+DEFAULTTUNE ?= "cortexa8hf-neon"
+include conf/machine/include/tune-cortexa8.inc
+
+IMAGE_FSTYPES += "tar.bz2 jffs2"
+EXTRA_IMAGECMD_jffs2 = "-lnp "
+
+SERIAL_CONSOLE = "115200 ttyO2"
+
+PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto-dev"
+PREFERRED_VERSION_linux-yocto-dev ?= "3.14%"
+
+KERNEL_IMAGETYPE = "zImage"
+KERNEL_DEVICETREE = "am335x-bone.dtb am335x-boneblack.dtb"
+
+SPL_BINARY = "MLO"
+UBOOT_SUFFIX = "img"
+UBOOT_MACHINE = "am335_evm_config"
+UBOOT_ENTRYPOINT = "0x80008000"
+UBOOT_LOADADDRESS = "0x80008000"
+
+MACHINE_FEATURES = "usbgadget usbhost vfat alsa"
diff --git a/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend 
b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend
new file mode 100644
index 000..6cb7e55
--- /dev/null
+++ b/meta-yocto-bsp/recipes-kernel/linux/linux-yocto-dev.bbappend
@@ -0,0 +1,3 @@
+KBRANCH_beaglebone = "standard/beaglebone"
+
+COMPATIBLE_MACHINE_beaglebone = "beaglebone"
-- 
1.8.3.2

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

Re: [yocto] SPL_IMAGE, SPL_BINARY, and SPL_SYMLINK definitions

[Denys Dmytriyenko]

On Mon, Nov 25, 2013 at 01:02:35PM -0500, William Mills wrote:
> On 11/25/2013 09:06 AM, Rifenbark, Scott M wrote:
> >Anyone have descriptions for these three variables?  I would like to 
> >document them and am wondering if anyone has used them or knows how they 
> >work.

git blame u-boot.inc would have shown the commit 2965aa2f that added those 
vars into the main u-boot.inc. The commit log does provide some explanation. 
Although, that is the commit that unified SPL_* vars into a common .inc file, 
previously we used to add them into specific u-boot_*.bb recipes along with 
the necessary do_install_append() and do_deploy_append()...


> SPL is the preloader for U-boot required on some platforms.

And it stands for Secondary Program Loader:
http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.SPL;hb=HEAD


> The base include for u-boot defines the SPL_IMAGE and SPL_SYMLINK
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-bsp/u-boot/u-boot.inc
> 
> One example of use of SPL_BINARY is here:
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/u-boot/u-boot_2011.12.bb
> 
> So the SPL_BINARY defines the name of the file in the filesystem image.
> The SPL_IMAGE and SPL_SYMLINK appear to specific the long version
> specific image file produced by the build and the somewhat shorter
> symlink that points to it.  These will be in a machine specific dir
> on the build machine; the same place the kernel is found.
> (The kernel also gets a very long name and a symlink  you can reuse
> wording from the description if you have that already.)
> 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-arago] GCC SVN repo too slow?

[Denys Dmytriyenko]

On Mon, Aug 19, 2013 at 05:51:59PM +1200, Christian Gagneraud wrote:
> CC: meta-ar...@arago-project.org
> 
> 
> On 19/08/13 17:16, Khem Raj wrote:
> >
> >On Aug 18, 2013, at 7:34 PM, Christian Gagneraud  wrote:
> >
> >>Hi all,
> >>
> >>I'm having problems with the GCC SVN repo being so slow to checkout, that 
> >>svn failed (and so my build too).
> >>I first suspected the proxy we have here, but i tried a checkout from an 
> >>outside machine (but still in New Zealand) and it seems the problem comes 
> >>from gcc.gnu.org.
> >>
> >>I am using the arago layer, which requires 
> >>svn://gcc.gnu.org/svn/gcc/branches;module=gcc-4_5-branch;protocol=http for 
> >>gcc-crosssdk-intermediate.
> >>
> >>By slow, I really mean slow: 1 to 2 files are checkout per second!?!
> >>
> >>Has anyone encountered the same kind of problems?
> >
> >
> >thats a known issue and one of pressing reasons to not use svn version on 
> >later versions if you see new recipes
> >best case you could hit a mirror from yocto project and download the source 
> >mirror
> 
> 
> From the logs, I can see that bitbake is trying (among others):
> downloads.yoctoproject.org
> sources.openembedded.org
> 
> but hits a 404, so it fall-backs to GCC's SVN repo directly.
> 
> On the side, from the bitbake logs, I end up with a rather obscure error:
> svn: E175002: REPORT of '/svn/gcc/!svn/vcc/default': 200 OK
> (http://gcc.gnu.org)
> 
> When trying a checkout manually from the outside machine, it fails
> too, but the error message is a bit more friendly:
> svn: REPORT of '/svn/gcc/!svn/vcc/default': Could not read response
> body: connection was closed by server (http://gcc.gnu.org)
> 
> I found plenty of "black magic" workarounds on the web while looking
> for the strange "Error: [...] 200 OK", among them was to increase
> Apache time out! Which won't even really solve my problem, because
> the checkout will takes hours, if not days!
> 
> Right now, I'm really stuck. The only solutions I can think of are:
> - Ask kindly Arago not to use GCC code from SVN, or maybe to upload
> an archive on yocto/oe mirrors.
> - Check with GNU/GCC guys if they can do something about it (maybe
> it's a temporary issue with their server)
> - Wait and see, cross my fingers. :(

Chris,

I'm just wondering why do you even need gcc-4.5? Unless you specifically use  
gcc-4.5 based toolchain with meta-arago. That is the only reason I keep 
gcc-4.5 recipes in meta-arago to support old products with old toolchains. 
We've moved to 4.7 Linaro quite some time ago - when you use that, you won't  
need to download 4.5 version.

If you really need gcc-4.5 and it's not just a misconfiguration, then I have 
a tarball available that can be uploaded to a mirror...

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

Re: [yocto] Yocto + meta-networking

[Denys Dmytriyenko]

On Wed, Jul 17, 2013 at 02:03:41PM +0100, Paul Eggleton wrote:
> On Wednesday 17 July 2013 08:56:34 Brian Hutchinson wrote:
> > Thanks Paul, I worried about mixing branches since I've never tried that
> > before.  The only reason I picked Denzil is because I need ti816x support
> > and Dylan and Danny don't have machine confs for it in meta-ti.  So what
> > would be easier, getting the machine support I need in Dylan or back
> > porting the net-snmp recipe to Denzil?
> 
> I don't have a feel for the former - if the reason is not already clear you'd 
> probably want to ask the meta-ti folks why that machine isn't supported in 
> later branches and how hard it would be to update support. This might be 
> worth 

Just to update everyone on this list - the issue with ti81x has been discussed 
on meta-ti list multiple times before and Brian already knew the answer to that.


> doing if you're starting something new with denzil, since that's two versions 
> behind current stable.
> 
> Having said that, backporting the net-snmp recipe should be fairly trivial 
> though.

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

Re: [yocto] Should I be worried about this nativesdk-packagegroup-sdk-host warning while building meta-toolchain

[Denys Dmytriyenko]

On Tue, Jul 23, 2013 at 04:13:18PM +0100, Paul Eggleton wrote:
> On Tuesday 23 July 2013 10:13:10 Brian Hutchinson wrote:
> > I'm using master branch of Yocto and meta-ti (and meta-openembedded).
> > 
> > I built meta-toolchain for beaglebone machine type and then I went into my
> > local.conf and changed sdkmachine to i686 as I need both 64bit & 32bit
> > toolchains.  After modifying my local.conf I ran bitbake meta-toolchain
> > again and received these warnings:
> > 
> > hutch@neo:~/yocto_master_beaglebone/poky/build$ bitbake meta-toolchain
> > WARNING: Host distribution "Debian-7.1" 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.
> > WARNING: Variable key FILES_${PN}-dev (${includedir} ${FILES_SOLIBSDEV}
> > ${libdir}/*.la ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig
> > ${datadir}/aclocal ${base_libdir}/*.o ${libdir}/${BPN}/*.la
> > ${base_libdir}/*.la) replaces original key FILES_ti-ipc-dev (${libdir}/*).
> > 
> > WARNING: Variable key FILES_${PN}-dev (${includedir} ${FILES_SOLIBSDEV}
> > ${libdir}/*.la ${libdir}/*.o ${libdir}/pkgconfig ${datadir}/pkgconfig
> > ${datadir}/aclocal ${base_libdir}/*.o ${libdir}/${BPN}/*.la
> > ${base_libdir}/*.la) replaces original key FILES_ti-syslink-dev
> > (${libdir}/*).

These FILES_${PN}-dev warnings indeed come from meta-ti and so far harmless - 
I haven't had bandwidth to fix them, as they seem low priority.


> > Parsing recipes: 100%
> > 
> > NOTE: Resolving any missing task queue dependencies
> > NOTE: Preparing runqueue
> > NOTE: Executing SetScene Tasks
> > NOTE: Executing RunQueue Tasks
> > WARNING: The recipe nativesdk-packagegroup-sdk-host is trying to install
> > files into a shared area when those files already exist. Those files and
> > their manifest location are:
> > 
> >  /home/hutch/yocto_master_beaglebone/poky/build/tmp/pkgdata/all-pokysdk-linu
> > x/nativesdk-packagegroup-sdk-host Matched in
> > manifest-x86_64-nativesdk-packagegroup-sdk-host.packagedata
> > 
> >  /home/hutch/yocto_master_beaglebone/poky/build/tmp/pkgdata/all-pokysdk-linu
> > x/runtime/nativesdk-packagegroup-sdk-host.packaged Matched in
> > manifest-x86_64-nativesdk-packagegroup-sdk-host.packagedata
> > 
> >  /home/hutch/yocto_master_beaglebone/poky/build/tmp/pkgdata/all-pokysdk-linu
> > x/runtime/nativesdk-packagegroup-sdk-host Matched in
> > manifest-x86_64-nativesdk-packagegroup-sdk-host.packagedata
> > 
> >  /home/hutch/yocto_master_beaglebone/poky/build/tmp/pkgdata/all-pokysdk-linu
> > x/runtime-reverse/nativesdk-packagegroup-sdk-host Matched in
> > manifest-x86_64-nativesdk-packagegroup-sdk-host.packagedata Please verify
> > which package should provide the above files.
> > 
> > 
> > Should I be worried or do I need to do something about the
> > nativesdk-packagegroup-sdk-host warnings?
> > 
> > I've never seen them before and I couldn't find anyone else talking about
> > them so I thought I'd ask.
> 
> Depends. Without looking at the recipe and output closely it's hard to tell 
> whether this is indicative or a problem or not, but it should be resolved by 
> the meta-ti maintainers. Denys, you might want to take a closer look at this.

And the warnings in question about nativesdk-packagegroup-sdk-host have 
absolutely nothing to do with meta-ti - there are no SDK packagegroup recipes 
in meta-ti.

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

Re: [yocto] yocto with meta-ti

[Denys Dmytriyenko]

On Wed, Jun 05, 2013 at 08:05:52AM +0200, Nicolas Dechesne wrote:
> On Wed, Jun 5, 2013 at 7:55 AM, Akshay Sahota  wrote:
> 
> > *
> > BBMASK ?= ".*/meta-ti/recipes-(misc|bsp/formfactor|graphics/mesa)/"
> >  #BBMASK = "meta-ti/recipes-misc meta-oe/recipes-graphics"
> > #BBMASK = "meta-oe/recipes-devtools"
> > #BBMASK = "meta-oe/recipes-graphics"
> > #
> > # Parallelism Options*...
> >
> >
> > and bblayers.conf
> >
> > *BBLAYERS ?= " \
> >   /home/asahota/poky-try/poky/meta \
> >   /home/asahota/poky-try/poky/meta-yocto \
> >   /home/asahota/poky-try/poky/meta-yocto-bsp \
> >   /home/asahota/poky-try/poky/meta-ti \

Please pay attention to the order of BSP layers, especially those providing 
the same machine configuration... For example, in the above setup, you won't 
be able to use "beagleboard" machine config from meta-ti, as you have it 
shadowed by the config from meta-yocto-bsp.

-- 
Denys


> >   /home/asahota/poky-try/poky/meta-openembedded/meta-oe \
> >   "
> > *
> >
> 
> i suspect you are using wrong combination of branch/version, but you don't
> give what branch/version you are using, not cannot confirm.
> 
> 
> > *
> > BBLAYERS_NON_REMOVABLE ?= " \
> >   /home/asahota/poky-try/poky/meta \
> >   /home/asahota/poky-try/poky/meta-yocto \
> >   "*
> >
> > and the output is :
> > *$ bitbake -k core-image-minimal
> > Pseudo is not present but is required, building this first before the main
> > build
> > WARNING: Host distribution "Ubuntu 12.04.2 LTS" 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.
> > ERROR: ParseError at
> > /home/asahota/poky-try/poky/meta-openembedded/meta-oe/recipes-devtools/cloud9/
> > cloud9_0.6.bb:11: Could not inherit file classes/systemd.bbclass
> > *
> >
> 
> systemd.bbclass was introduced in 'dylan' version of Yocto (aka 1.4). are
> you sure this is what you are using? to be it sounds like you are using
> Yocto/danny with meta-ti and meta-oe 'master' branch (or dylan branch).
> 
> 
> *ERROR: Command execution failed: Exited with 1
> >
> > Summary: There was 1 WARNING message shown.
> > Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> > *
> > What is the mistake, sounds too silly.!

> ___
> 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] yocto with meta-ti

[Denys Dmytriyenko]

On Tue, Jun 04, 2013 at 08:58:27AM -0700, mich...@cubic.org wrote:
> Hi,
> 
> As a quick hack you can mask out recipes-misc by adding the following line
> to your conf/local.conf :
> 
> BBMASK = "meta-ti/recipes-misc"
> 
> It seem to mask out everything in meta-ti/recipes-misc.
> 
> This was a suggestion I found on the net.

Apparently, nobody reads documentation:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/README


> The better way would be if
> meta-ti would be split into multiple layers where one of them is a
> meta-ti-bsp layer.

meta-ti is a BSP layer.

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

Re: [yocto] [meta-ti] Wifi Module + udev configs

[Denys Dmytriyenko]

On Mon, Feb 18, 2013 at 08:56:06AM -0300, Raul Rosetto Munoz wrote:
> Any suggestions?
> 
> I really do not know what to do, the file "/lib/udev/firmware" never appear.

FYI, starting with 176, udev handles loading firmware images internally, hence 
dropping the /lib/udev/firmware binary. But there were some bugs related to 
that functionality, which got fixed in version 178...

http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=ChangeLog;hb=HEAD
http://upstream-tracker.org/changelogs/libudev/181/changelog.html

As I said before, if you are using Danny branch, then you should stick to the 
proven udev-164 that is in oe-core, unless you really want to have systemd, in 
which case you look into meta-openembedded...

-- 
Denys


> 2013/2/14 Raul Rosetto Munoz 
> 
> > Now Im with 173 from meta-fsl bbapend, but I tryed with many others from
> > meta-oe and poky.
> >
> >
> >
> >
> >
> >
> > 2013/2/14 Denys Dmytriyenko 
> >
> >> On Thu, Feb 14, 2013 at 02:23:14PM -0200, Raul Rosetto Munoz wrote:
> >> > Denys,
> >> > There are something strange,
> >> >
> >> > First there are no  linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
> >> > installed at rfs.
> >>
> >> I was talking about packages, looks like you have them already installed.
> >>
> >>
> >> > raul@phi04:.../tmp/deploy/images$ find
> >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name "*8192*"
> >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
> >> >
> >> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
> >> >
> >> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
> >> >
> >> > Another problem is that "/lib/udev/firmware" are not installed to.
> >> >
> >> > raul@phi04:.../tmp/deploy/images$ find
> >> > /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name "*firmware*"
> >> > raul@phi04:.../tmp/deploy/images$
> >>
> >> What is your udev version?
> >>
> >>
> >> > But I can see theses files at my "tmp/sysroots/beaglebone"
> >> >
> >> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name
> >> "*8192*"
> >> > lib/firmware/RTL8192E
> >> > lib/firmware/rtlwifi/rtl8192sefw.bin
> >> > lib/firmware/rtlwifi/rtl8192defw.bin
> >> > lib/firmware/rtlwifi/rtl8192cfw.bin
> >> > lib/firmware/rtlwifi/rtl8192cufw.bin
> >> >
> >> > raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name
> >> "*firmware*"
> >> > lib/udev/firmware
> >> > lib/udev/rules.d/50-firmware.rules
> >> >
> >> > I tryed copy this files for the sdcard but doesnt work.
> >> >
> >> > Do you have any suggest?
> >> >
> >> > Thanks for all help.
> >>
> >
> >
> >
> > --
> > *Raul Rosetto Muñoz*
> >
> 
> 
> 
> -- 
> *Raul Rosetto Muñoz*

> ___
> meta-ti mailing list
> meta...@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-ti

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

Re: [yocto] [meta-ti] Wifi Module + udev configs

[Denys Dmytriyenko]

On Thu, Feb 14, 2013 at 02:23:14PM -0200, Raul Rosetto Munoz wrote:
> Denys,
> There are something strange,
> 
> First there are no  linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}
> installed at rfs.

I was talking about packages, looks like you have them already installed.


> raul@phi04:.../tmp/deploy/images$ find
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/ -name "*8192*"
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/RTL8192E
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192sefw.bin
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/firmware/rtlwifi/rtl8192defw.bin
> 
> Another problem is that "/lib/udev/firmware" are not installed to.
> 
> raul@phi04:.../tmp/deploy/images$ find
> /media/ed86e6a2-20c2-464e-a2f3-f28ff48983ef/lib/udev/ -name "*firmware*"
> raul@phi04:.../tmp/deploy/images$

What is your udev version?


> But I can see theses files at my "tmp/sysroots/beaglebone"
> 
> raul@phi04:.../tmp/sysroots/beaglebone$ find lib/firmware/ -name "*8192*"
> lib/firmware/RTL8192E
> lib/firmware/rtlwifi/rtl8192sefw.bin
> lib/firmware/rtlwifi/rtl8192defw.bin
> lib/firmware/rtlwifi/rtl8192cfw.bin
> lib/firmware/rtlwifi/rtl8192cufw.bin
> 
> raul@phi04:.../tmp/sysroots/beaglebone$ find lib/udev/ -name "*firmware*"
> lib/udev/firmware
> lib/udev/rules.d/50-firmware.rules
> 
> I tryed copy this files for the sdcard but doesnt work.
> 
> Do you have any suggest?
> 
> Thanks for all help.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ti] Wifi Module + udev configs

[Denys Dmytriyenko]

There's /lib/udev/firmware which is a firmware loading helper.

The actual firmware files go into /lib/firmware/ directory.

Please make sure you have the correct packages installed with firmware for 
your WiFi - linux-firmware-{rtl8192cu,rtl8192ce,rtl8192su}

-- 
Denys


On Thu, Feb 14, 2013 at 09:17:43AM -0200, Raul Rosetto Munoz wrote:
> Yes I install this package,
> But I think that the problem is that the binary firmware at "/lib/udev"
> doesn't come with the build.
> 
> Some one know how to build the binary firmware at "/lib/udev" responsible
> to record the firmware in wifi dongle and enable the udev rules for this
> action.
> 
> Thanks for all Help
> 
> 
> 2013/2/12 Denys Dmytriyenko 
> 
> > On Thu, Feb 07, 2013 at 06:26:46PM -0200, Raul Rosetto Munoz wrote:
> > > Hello All,
> > > I need to configure my yocto project to work with wifi dongle realteck
> > > rtl8192cu.
> > >
> > > My first problem is that the module does not go up automatically
> > rtl8192cu
> > > different than Angstron distro that when I plug the dongle all modules
> > rise.
> > >
> > > Another important difference is that on Angstron distro I have on
> > /lib/udev
> > > the "firmware" binary file.  I really was not able to install this
> > > functionality in udev.
> >
> > Have you looked at linux-firmware package? rtl8192* should be well
> > supported.
> >
> >
> > > And How to make this firmware binary go to /lib/udev?
> >
> > By default, firmware files go into /lib/firmware
> >
> > --
> > Denys
> >
> 
> 
> 
> -- 
> *Raul Rosetto Mu?oz*
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-ti] Wifi Module + udev configs

[Denys Dmytriyenko]

On Thu, Feb 07, 2013 at 06:26:46PM -0200, Raul Rosetto Munoz wrote:
> Hello All,
> I need to configure my yocto project to work with wifi dongle realteck
> rtl8192cu.
> 
> My first problem is that the module does not go up automatically rtl8192cu
> different than Angstron distro that when I plug the dongle all modules rise.
> 
> Another important difference is that on Angstron distro I have on /lib/udev
> the "firmware" binary file.  I really was not able to install this
> functionality in udev.

Have you looked at linux-firmware package? rtl8192* should be well supported.


> And How to make this firmware binary go to /lib/udev?

By default, firmware files go into /lib/firmware

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

Re: [yocto] [meta-ti] build failure with xf86-video-omap

[Denys Dmytriyenko]

On Thu, Nov 22, 2012 at 12:26:12AM +0100, Nicolas Dechesne wrote:
> looping rob clark (upstream author)
> 
> 
> On Thu, Nov 22, 2012 at 12:07 AM, Burton, Ross wrote:
> 
> > On 21 November 2012 22:52, Nicolas Dechesne  wrote:
> > > since xf86-video-omap was recently merged in oe-core and poky, i am
> > trying
> > > to remove the recipes we had staged in meta-ti trees for some weeks
> > > (
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/commit/?id=410dc026f2ee24a2346e7563a83f0181c79809cf
> > ).
> > > so i was trying to build  poky/master with meta-ti/master, for
> > pandaboard,
> > > and I get build failures in xf86-video-omap [1] and [2].
> > >
> > > so [1] is actually trivial, as we are missing a DEPENDS in the recipe, i
> > can
> > > send a patch in oe-core for that.
> >
> > Please do.
> >
> 
> sure, will do.
> 
> >
> > > [2] is a bit more cryptic to me.. so I quickly tried to build with danny
> > ( i
> > > just cherry picked the commit that introduced xf86-video-omap from
> > master)
> > > and this time it built fine.
> > >
> > > has anyone actually tested this recipe? if so I must be doing something
> > > wrong, any hint would be helpful.
> >
> > This was discussed a few hours ago.  It's caused by a) the
> > configure.ac being broken and b) the workaround for this being removed
> > by me in e828faf027540bc5def8b7371a959884caad9557 (which is in master
> > only).  Presumably this code was test built before that patch landed.
> >
> > As this is a genuine upstream bug (ARM-specific driver that doesn't
> > cross-compile?!) I've just filed fdo #57386.
> >
> 
> i suspect you opened a OE bug, since I can't find it in yocto BZ, however
> bugs.openembedded.org doesn't seem to answer at the moment..

AFAIK, OE bugzilla was deprecated some time ago. We were considering taking it 
down, as a matter of fact. OE-Core issues are logged into Yocto bugzilla. Not 
sure where Ross filed this one though.


> so, I checked our configure.ac , and clearly, that needs some love...
> 
> Rob: any chance you can look into that? it's the xf86-video-omap
> configure.ac file that's wrong, we should mimic what's in the
> xf-video-intel one i guess..  otherwise i can try later this week.

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

Re: [yocto] Newbie looking for a Recipe Box for AM1707 aka Texas Instruments TMDXEVM1707

[Denys Dmytriyenko]

On Tue, Sep 25, 2012 at 09:27:22AM -0400, Wesley J. Miller wrote:
> The subject pretty much says it all.
> 
> I am looking for a build package for the TI AM1707 ARM9 EVM. This is a 
> Sitara family processor.
> 
> And if the answer is "there isn't one", what's the best package choice to 
> use as a starting point?

Hi,

Sorry for the delay. You can start with the MACHINE=am180x-evm from meta-ti[1], 
as it's close enough and from basic BSP perspective should be the same.

[1] http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/

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

Re: [yocto] [meta-ti] meta-gumstix proceedings

[Denys Dmytriyenko]

On Mon, Oct 08, 2012 at 12:18:24PM +0100, Paul Eggleton wrote:
> Hi Andreas,
> 
> On Monday 08 October 2012 12:54:46 Andreas Müller wrote:
> > as some of you might know, gumstix created an official BSP layer
> > [1][2]. To avoid confusion I renamed my layer from meta-gumstix to
> > meta-gumstix-community [3]. Users should either switch to the official
> > meta-gumstix layer or rename meta-gumstix to meta-gumstix-community
> > [3] in git configuration (users of angstrom-setup-scripts should also
> > change the name in layers.txt).
> 
> So what should we do with the layer index [4]? Do we list both? What is the 
> delta between them, and is there a hope that there will be only one layer at 
> some point?

Paul,

FYI, 
http://thread.gmane.org/gmane.linux.distributions.gumstix.general/65109/focus=65131

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

Re: [yocto] Documenting the mailing lists.

[Denys Dmytriyenko]

On Mon, Aug 20, 2012 at 08:55:34PM +, Rifenbark, Scott M wrote:
> Regarding the text on the https://lists.yoctoproject.org link.  Who 
> maintains that page?

It's generated from each list's configuration data. Corresponding list 
maintainers or mailman admin (Michael?) can change the descriptions, like I 
just did for meta-ti.

-- 
Denys


> -Original Message-
> From: Denys Dmytriyenko [mailto:de...@ti.com] 
> Sent: Monday, August 20, 2012 12:15 PM
> To: Darren Hart
> Cc: Yocto Project; Rifenbark, Scott M; Paul Gortmaker; Richard Purdie; Wold, 
> Saul; Paul Eggleton; Osier-mixon, Jeffrey; Zanussi, Tom; Hudson, Sean; Koen 
> Kooi; Jason Kridner; Flanagan, Elizabeth; Michael Halstead
> Subject: Re: Documenting the mailing lists.
> 
> On Mon, Aug 20, 2012 at 11:43:38AM -0700, Darren Hart wrote:
> > Scott,
> > 
> > We've come across some more confusion about mailing lists recently. I've
> > sent a patch against poky to try and clear it up a bit in the source,
> > but we should also see about cleaning up the web descriptions of the lists.
> > 
> > We have two pages that describe the lists:
> > 
> > http://www.yoctoproject.org/community/mailing-lists
> > https://lists.yoctoproject.org/
> > 
> > My first recommendation would be to eliminate
> > http://www.yoctoproject.org/community/mailing-lists and replace links to
> > it with links to https://lists.yoctoproject.org. This eliminates the
> > need to keep the CMS version in sync with the mailman page. The mailman
> > page should be considered the master anyway as the Description field is
> > taken directly from the list administrative settings.
> 
> I completely agree with this proposal to unify and clean up the mailing list 
> references and descriptions. I didn't even know there was a separate page at 
> http://www.yoctoproject.org/community/mailing-lists - probably because I was 
> happy with https://lists.yoctoproject.org/ all the time :)
> 
> 
> > We should then work to create meaningful Descriptions of all the lists.
> > These should still fit on a single line, but I think we can improve on
> > what we have. For example:
> > 
> > meta-ti Mailing list for the meta-ti layer
> > 
> > is not particularly enlightening. Perhaps something like:
> > 
> > meta-ti Usage and development of the meta-ti layer
> 
> Not sure if this improves much - in either case it's just a generic 
> description of the mailing list that is specific to the corresponding layer, 
> meta-ti. But I'm fine with the change, as long as we are unifying all the 
> other list descriptions.
> 
> 
> > If we do this all at once, we can also ensure a consistent language,
> > tone, etc.
> 
> Exactly! Thanks for initiating this.
> 
> 
> > I'll propose something for each list here and ask that
> > interested parties comment and correct in reply. Once agreed upon, the
> > admins of the respective lists can make the changes (all CC'd)
> > 
> > Current:
> > 
> > linux-yocto Development list for the linux-yocto*.git Linux kernel
> > repositories
> > meta-ti Mailing list for the meta-ti layer
> > pokyPoky build system developer discussion & patch
> > submission for meta-yocto
> > shoeleather Neutral Board Lab Mailing List
> > yocto   Discussion of all things Yocto
> > yocto-abYocto Project Advisory Board
> > yocto-advocacy  Yocto Project Advocacy & Outreach AB Subgroup
> > yocto-announce  Announcements from the Yocto Project
> > yocto-bsp   BSP Interest Group
> > Yocto-buildsBuild failures and discusion about the build system
> > yocto-infrastructureInfrastructure
> > 
> > 
> > Proposed:
> > =
> > linux-yocto Development list for the linux-yocto*.git Linux kernel
> > repositories
> > meta-ti Usage and development list for the meta-ti layer
> > pokyUsage and development list for the Poky build system
> > (see README for patch submission)
> > shoeleather Neutral Board Lab Mailing List
> > 
> > I'm not sure what "neutral" is meant to convey. How about:
> > 
> > Discussion list for the Shoeleather embedded board lab
> > 
> > yocto   General discussion list for the Yocto Project and
> > development for projects without dedicated lists
> > 
> > I think the yocto list is a bit problematic in that it mixes project
> > con

Re: [yocto] Documenting the mailing lists.

[Denys Dmytriyenko]

On Mon, Aug 20, 2012 at 11:43:38AM -0700, Darren Hart wrote:
> Scott,
> 
> We've come across some more confusion about mailing lists recently. I've
> sent a patch against poky to try and clear it up a bit in the source,
> but we should also see about cleaning up the web descriptions of the lists.
> 
> We have two pages that describe the lists:
> 
> http://www.yoctoproject.org/community/mailing-lists
> https://lists.yoctoproject.org/
> 
> My first recommendation would be to eliminate
> http://www.yoctoproject.org/community/mailing-lists and replace links to
> it with links to https://lists.yoctoproject.org. This eliminates the
> need to keep the CMS version in sync with the mailman page. The mailman
> page should be considered the master anyway as the Description field is
> taken directly from the list administrative settings.

I completely agree with this proposal to unify and clean up the mailing list 
references and descriptions. I didn't even know there was a separate page at 
http://www.yoctoproject.org/community/mailing-lists - probably because I was 
happy with https://lists.yoctoproject.org/ all the time :)


> We should then work to create meaningful Descriptions of all the lists.
> These should still fit on a single line, but I think we can improve on
> what we have. For example:
> 
> meta-ti   Mailing list for the meta-ti layer
> 
> is not particularly enlightening. Perhaps something like:
> 
> meta-ti   Usage and development of the meta-ti layer

Not sure if this improves much - in either case it's just a generic 
description of the mailing list that is specific to the corresponding layer, 
meta-ti. But I'm fine with the change, as long as we are unifying all the 
other list descriptions.


> If we do this all at once, we can also ensure a consistent language,
> tone, etc.

Exactly! Thanks for initiating this.


> I'll propose something for each list here and ask that
> interested parties comment and correct in reply. Once agreed upon, the
> admins of the respective lists can make the changes (all CC'd)
> 
> Current:
> 
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Mailing list for the meta-ti layer
> poky  Poky build system developer discussion & patch
>   submission for meta-yocto
> shoeleather   Neutral Board Lab Mailing List
> yocto Discussion of all things Yocto
> yocto-ab  Yocto Project Advisory Board
> yocto-advocacyYocto Project Advocacy & Outreach AB Subgroup
> yocto-announceAnnouncements from the Yocto Project
> yocto-bsp BSP Interest Group
> Yocto-builds  Build failures and discusion about the build system
> yocto-infrastructure  Infrastructure
> 
> 
> Proposed:
> =
> linux-yocto   Development list for the linux-yocto*.git Linux kernel
>   repositories
> meta-ti   Usage and development list for the meta-ti layer
> poky  Usage and development list for the Poky build system
>   (see README for patch submission)
> shoeleather   Neutral Board Lab Mailing List
> 
> I'm not sure what "neutral" is meant to convey. How about:
> 
>   Discussion list for the Shoeleather embedded board lab
> 
> yocto General discussion list for the Yocto Project and
>   development for projects without dedicated lists
> 
> I think the yocto list is a bit problematic in that it mixes project
> conceptual discussion, user help desk, and development all on the same
> list. However, I'm trying to clarify what these actually are here - not
> change anything.
> 
> yocto-ab  Yocto Project Advisory Board ???
> 
> This should imply the intended audience. Is it just meant for members?
> Is it meant as a way for non-AB members to observe what is going on?
> 
> yocto-advocacyYocto Project advocacy & outreach AB subgroup
> 
> Same as above.
> 
> yocto-announceAnnouncements from the Yocto Project (low traffic)
> yocto-bsp BSP Interest Group ???
> 
> There is no detailed description for this list, so I'm not sure what
> this is really about.
> 
> Yocto-builds  Build failures and discussion about the autobuilder
> 
> (includes typo fix, "build system" removed to avoid confusion with the
> "poky build system")
> 
> yocto-infrastructure  Infrastructure ???
> 
> Jefro or Michael, can you come up with something appropriate here?
> 
> 
> For lists where certain guidelines should be used in communications and
> patch submission, we should document that in the detailed description of
> the list, such as [project] tags for example.

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

Re: [yocto] Raspberry Pi

[Denys Dmytriyenko]

On Tue, May 08, 2012 at 12:58:32AM -0700, Osier-mixon, Jeffrey wrote:
> Hi Chris & all - there is a small group working on a Yocto Project BSP
> for the Raspberry Pi, particularly to get Qt working (this is the
> QtonPi group to which Brian referred in an earlier message). I can put
> you in touch with them if you like.

There is even a repository available for it now:

https://github.com/djwillis/meta-raspberrypi

-- 
Denys


> On Tue, May 8, 2012 at 12:43 AM, Chris Tapp  wrote:
> > On 15 Dec 2011, at 21:47, Chris Tapp wrote:
> >
> >> Is anyone on this list considering (or working on) a BSP for the Raspberry 
> >> Pi (http://www.raspberrypi.org/faqs) ?
> >>
> >> For those that haven't seen it, it's a credit-card sized 'home pc' aimed 
> >> primarily at educational users that includes a 700MHz ARM11 core, HDMI, 
> >> OpenGL ES 2.0, ethernet and audio for about $35. It will be supporting 
> >> Debian, Fedora and ArchLinux at launch.
> >>
> >> Looks like a good board for people that want to get in to Yocto / embedded 
> >> linux. Also looks like it's a good platform for some of my stuff...
> >>
> >> I would be interested in working on a BSP / distro if anyone is working on 
> >> it or would like to work on it.
> >
> > Well, I've finally got to the top of the order list and should be getting 
> > some hardware within the next few days. Time to get started!
> >
> > I guess the first thing to do is get a kernel built. I'm not up-to-date 
> > with ARM - are there any BSPs available for similar devices / the ARM11 
> > core?
> >
> > Chris Tapp
> >
> > opensou...@keylevel.com
> > www.keylevel.com
> >
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> 
> 
> -- 
> Jeff Osier-Mixon http://jefro.net/blog
> Yocto Project Community Manager @Intel http://yoctoproject.org
> ___
> 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] How to fix warning: set SYSTEMD_PACKAGES as -systemd

[Denys Dmytriyenko]

On Thu, May 03, 2012 at 09:11:49PM +0200, Elvis Dowson wrote:
> Hi,
>   I get a bunch of warnings asking me to set SYSTEMD_PACKAGES as 
> -systemd.

You get those from the recipes that inherit systemd.bbclass, but not set 
SYSTEMD_PACKAGES with ${PN}-systemd for some reason. Sometimes it's wrong and 
needs fixing, but often it's done on purpose and the warning just needs to be 
silenced.

> WARNING: /tool/yocto/meta-ti/recipes-misc/payload/bonescript.bb: it is 
> recommended to set SYSTEMD_PACKAGES as -systemd

The first one is now silenced in meta-ti.

> WARNING: 
> /tool/yocto/meta-openembedded/meta-oe/recipes-connectivity/networkmanager/networkmanager_0.9.2.0.bb:
>  it is recommended to set SYSTEMD_PACKAGES as -systemd
> WARNING: /tool/yocto/poky/meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb: 
> it is recommended to set SYSTEMD_PACKAGES as -systemd

For these 2 please report them on openembedded-devel mailing list, where 
meta-oe things are being discussed. The last warning is confisuing, as it 
reports the recipe is in poky/oe-core, but it actually comes from the 
corresponding .bbappend in meta-oe.

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

Re: [yocto] ERROR: ParseError at /tool/yocto/poky-extras/meta-linaro/recipes-devtools/gcc/gcc-4.5.1.linaro.inc:1: Could not include required file recipes-devtools/gcc/gcc-4.5.1.inc

[Denys Dmytriyenko]

On Thu, May 03, 2012 at 10:02:08AM -0700, Khem Raj wrote:
> On Thu, May 3, 2012 at 9:25 AM, Elvis Dowson  wrote:
> >  /tool/yocto/poky-extras/meta-linaro \
> 
> I think you should remove above layer from BBLAYERS

I agree - that one is unofficial and unmaintained. Linaro is working on the 
official meta-linaro layer for OE/Yocto.

Darren,

What are you plans for the old meta-linaro in poky-extras? Do you plan to 
update it or do you want to drop it?

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

Re: [yocto] How to specify a machine defconfig for a linux recipe

[Denys Dmytriyenko]

On Thu, May 03, 2012 at 05:57:41PM -0400, Bruce Ashfield wrote:
> On 12-05-03 05:42 PM, Elvis Dowson wrote:
> >Hi,
> >
> >On May 3, 2012, at 9:55 PM, Elvis Dowson wrote:
> >
> >>How can I specify a machine defconfig for a linux recipe?
> >>
> >>For example, if I set
> >>
> >># kernel provider
> >>PREFERRED_PROVIDER_virtual/kernel = "linux-omap3"
> >>
> >>and try to build my machine, I get the following errors:
> >>
> >>ERROR: Function failed: Fetcher failure for URL: 'file://defconfig'. Unable 
> >>to fetch URL from any source.
> >>NOTE: package linux-omap3-3.2-r0: task do_fetch: Failed
> >>ERROR: Task 125 
> >>(/tool/yocto/meta-gumstix/recipes-kernel/linux/linux-omap3_3.2.bb, 
> >>do_fetch) failed with exit code '1'
> >>NOTE: Tasks Summary: Attempted 304 tasks of which 302 didn't need to be 
> >>rerun and 1 failed.
> >>
> >>Summary: 1 task failed:
> >>  /tool/yocto/meta-gumstix/recipes-kernel/linux/linux-omap3_3.2.bb, do_fetch
> >
> >I solved this one.
> >
> >Turns out, since I defined a new machine called overo-fire-chestnut43, I had 
> >to also create a folder called overo-fire-chestnut43 to hold the defconfig 
> >file as follows:
> >
> >meta-gumstix/recipes-kernel/linux/linux-omap3/overo-fire-chestnut43/defconfig
> >
> >I recall, the trend was to move away from user supplied defconfigs, and have 
> >it get generated automatically by the build process, and then specify some 
> >hints. Is there any example of how I can modify the existing meta-gumstix or 
> >any other meta-layer, to get the defconfig to get generated automatically?
> 
> Are you thinking about the linux-yocto config fragment support ?
> Or maybe something else ? If you were thinking about the fragments,
> it would only replace your defconfigs directly when you use a linux-yocto
> kernel tree (and it's included meta branch with configuration frags).
> In that scenario, you only put your board specific fragments on the end,
> and let the rest be constructed.
> 
> When I return home next week, I will have some patches for 1.3 that make
> the fragments apply more easily to any git repository, but in either
> case (1.2 or 1.3), you'd still need to build up a series of fragments
> outside the tree, or migrate to linux-yocto* for maxium re-use.

Bruce,

I'd be willing to start using config fragments for our kernels in meta-ti, 
when this feature is not tightly bundled with linux-yocto kernel. While we 
might want to eventually start using the entire linux-yocto framework for our 
kernels, it may take longer time due to many internal constraints. And having 
config fragments available as a separate feature would be very helpful and 
enable us to take baby steps... :) That's what we discussed last month at the 
Yocto BSP Summit. Thanks.

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

Re: [yocto] Build error: Could not inherit file classes/systemd.bbclass

[Denys Dmytriyenko]

On Thu, May 03, 2012 at 01:07:06PM -0600, Gary Thomas wrote:
> On 2012-05-03 12:22, Elvis Dowson wrote:
> >Hi,
> >
> >On May 3, 2012, at 5:39 PM, Gary Thomas wrote:
> >
> >>On 2012-05-03 07:21, Paul Eggleton wrote:
> >>I saw this checkin yesterday on meta-ti:
> >>Module: meta-ti
> >>Branch: refs/tags/v2012.05-yocto1.2
> >>Tag: ccae351a692bf6fa17a4a1e35b89ff6efcd35c6c
> >>URL: 
> >>http://arago-project.org/git/meta-ti.git/?a=tag;h=ccae351a692bf6fa17a4a1e35b89ff6efcd35c6c
> >>
> >>Tagger: Denys Dmytriyenko mailto:de...@ti.com>>
> >>Date: Wed May 2 03:41:43 2012 -0400
> >>
> >>2012.05 release, compatible with Yocto Project 1.2 Denzil
> >>
> >>So it looks like it should be close at least :-) I don't know how the
> >>meta-ti repo on yoctoproject.org <http://yoctoproject.org> tracks the 
> >>arago-project one...
> >
> >The meta-ti repo on yoctoproject.org <http://yoctoproject.org> tracks the 
> >arago-project one closely.
> >
> >The following bblayers.conf configuration worked
> >
> >BBFILES ?= ""
> >BBLAYERS ?= " \
> >/tool/yocto/poky/meta \
> >/tool/yocto/poky/meta-yocto \
> >/tool/yocto/meta-openembedded/meta-oe \
> >/tool/yocto/meta-gumstix \
> >/tool/yocto/meta-ti \
> >/tool/yocto/meta-xilinx \
> >"
> 
> IMO, you should be able to use meta-ti *without* meta-oe (I do anyway)

You still need to BBMASK recipes-misc to avoid systemd when used w/o meta-oe

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

Re: [yocto] Build error: Could not inherit file classes/systemd.bbclass

[Denys Dmytriyenko]

On Thu, May 03, 2012 at 09:39:17AM -0600, Gary Thomas wrote:
> On 2012-05-03 07:21, Paul Eggleton wrote:
> >On Thursday 03 May 2012 14:56:03 Elvis Dowson wrote:
> >>  I've setup and configured an Ubuntu-12.04 LTS 64-bit system, and I get
> >>a build error when I run the following command:
> >>
> >>$ bitbake -c fetchall core-image-minimal
> >>
> >>Pseudo is not present but is required, building this first before the main
> >>build WARNING: Host distribution "Ubuntu 12.04 LTS" 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.
> >
> >This can be ignored - 12.04 *is* supported; it's just that the final version
> >string wasn't what I expected it to be. I'll send a patch for this soon and 
> >it
> >can hopefully go into 1.2.1.
> >
> >>ERROR: ParseError at
> >>/tool/yocto/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not inherit
> >>file classes/systemd.bbclass ERROR: Command execution failed: Exited with 1
> >
> >systemd.bbclass is part of the meta-oe layer, so you'll need to add that to
> >your bblayers.conf.
> >
> >BTW I'm not sure if the meta-ti maintainers have finished their work to 
> >ensure
> >meta-ti works with distros other than Angstrom. If they haven't you may
> >experience problems.
> 
> I saw this checkin yesterday on meta-ti:
>   Module: meta-ti
>   Branch: refs/tags/v2012.05-yocto1.2
>   Tag:ccae351a692bf6fa17a4a1e35b89ff6efcd35c6c
>   URL:
> http://arago-project.org/git/meta-ti.git/?a=tag;h=ccae351a692bf6fa17a4a1e35b89ff6efcd35c6c
> 
>   Tagger: Denys Dmytriyenko 
>   Date:   Wed May  2 03:41:43 2012 -0400
> 
>   2012.05 release, compatible with Yocto Project 1.2 Denzil
> 
> So it looks like it should be close at least :-)  I don't know how the
> meta-ti repo on yoctoproject.org tracks the arago-project one...

meta-ti on yoctoproject.org is the same exact as on arago-project.org - those 
are just mirrors of the same repository.

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

Re: [yocto] Build error: Could not inherit file classes/systemd.bbclass

[Denys Dmytriyenko]

On Thu, May 03, 2012 at 02:21:40PM +0100, Paul Eggleton wrote:
> On Thursday 03 May 2012 14:56:03 Elvis Dowson wrote:
> >  I've setup and configured an Ubuntu-12.04 LTS 64-bit system, and I get
> > a build error when I run the following command:
> > 
> > $ bitbake -c fetchall core-image-minimal
> > 
> > Pseudo is not present but is required, building this first before the main
> > build WARNING: Host distribution "Ubuntu 12.04 LTS" 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.
> 
> This can be ignored - 12.04 *is* supported; it's just that the final version 
> string wasn't what I expected it to be. I'll send a patch for this soon and 
> it 
> can hopefully go into 1.2.1.
> 
> > ERROR: ParseError at
> > /tool/yocto/meta-ti/recipes-misc/payload/bonescript.bb:5: Could not inherit
> > file classes/systemd.bbclass ERROR: Command execution failed: Exited with 1
> 
> systemd.bbclass is part of the meta-oe layer, so you'll need to add that to 
> your bblayers.conf.
> 
> BTW I'm not sure if the meta-ti maintainers have finished their work to 
> ensure 
> meta-ti works with distros other than Angstrom. If they haven't you may 
> experience problems.

Yes, meta-ti does not require Angstrom.

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

Re: [yocto] meta-gumstix.git layer dependencies

[Denys Dmytriyenko]

On Thu, May 03, 2012 at 08:01:58AM +0200, Elvis Dowson wrote:
> Hi Andreas,
>  I was just taking a look at your meta-gumstix.git 
> repository, and it mentions that it depends upon
> 
> git://git.openembedded.org/openembedded-core
> git://git.angstrom-distribution.org/meta-texasinstruments
> 
> Isn't openembedded-core shared with yocto's poky? If so, do I really need to 
> add openembedded-core to my bblayers.conf file?
> 
> Also there is a meta-ti.git repository for texas instruments on the yocto 
> website: git://git.yoctoproject.org/meta-ti
> 
> Should one use the meta-ti or the meta-texasinstruments layer?

Please use git://git.yoctoproject.org/meta-ti since 
git.angstrom-distribution.org server is long since gone. Please update your 
layers accordingly. Thanks.

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

Re: [yocto] Agenda: Yocto Project Technical Team Meeting - Tuesday, April 24, 2012 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

[Denys Dmytriyenko]

On Tue, Apr 24, 2012 at 10:51:20AM +0100, Paul Eggleton wrote:
> On Monday 23 April 2012 20:32:41 Guo Tang wrote:
> > Is this meeting an open meeting, or limited to Yocto team only?
> 
> It's open to anyone who is interested - you're more than welcome :)

Well, there is a limit on the number of participants, IIRC, so hopefully 
people won't "abuse" it... :)

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

Re: [yocto] meta-chromium

[Denys Dmytriyenko]

On Tue, Apr 17, 2012 at 10:40:28PM +0200, Eric B?nard wrote:
> Hi,
> 
> we have pushed the begining of our (Eukr?a Electromatique's team and
> especially Denis) work to get Chromium to build with OpenEmbedded Core
> to : git://github.com/eukrea/meta-chromium.git
> https://github.com/eukrea/meta-chromium
> 
> For the moment it's only tested on ARMv7 platforms (i.MX515 and i.MX535
> based) where it seems robust and quite fast on most of the HTML5 tests
> we ran (only WebGL doesn't yet work).
> 
> Feel free to send patches to improve the recipes and add support for
> other platforms.
> 
> TODO :
> - enable WebGL with OpenGL ES support
> - support other platforms than armv7
> - merge with meta-mozilla to create a meta-browser layer

Eric, Denis,

Great news! Thanks for your work!

-- 
Denys

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

[yocto] [PATCH] linux-yocto 3.0: fix beagleboard boot hang on mmc init due to preempt

[Denys Dmytriyenko]

From: Denys Dmytriyenko 

The boot hangs with the message:
mmc0: error -110 whilst initialising SD card

The MMC driver has issues initializing when PREEMPT is enabled (either forced
or voluntary). Unplugging and then plugging the card back will reset the
driver and continue booting. Alternatively, disable preemption.

Signed-off-by: Denys Dmytriyenko 
---
 .../recipes-kernel/linux/files/no-preempt.cfg  |1 +
 .../recipes-kernel/linux/files/no-preempt.scc  |1 +
 .../recipes-kernel/linux/linux-yocto_3.0.bbappend  |6 ++
 3 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 meta-yocto/recipes-kernel/linux/files/no-preempt.cfg
 create mode 100644 meta-yocto/recipes-kernel/linux/files/no-preempt.scc

diff --git a/meta-yocto/recipes-kernel/linux/files/no-preempt.cfg 
b/meta-yocto/recipes-kernel/linux/files/no-preempt.cfg
new file mode 100644
index 000..0cbeb5a
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/files/no-preempt.cfg
@@ -0,0 +1 @@
+CONFIG_PREEMPT_NONE=y
diff --git a/meta-yocto/recipes-kernel/linux/files/no-preempt.scc 
b/meta-yocto/recipes-kernel/linux/files/no-preempt.scc
new file mode 100644
index 000..1e75e15
--- /dev/null
+++ b/meta-yocto/recipes-kernel/linux/files/no-preempt.scc
@@ -0,0 +1 @@
+kconf non-hardware no-preempt.cfg
diff --git a/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend 
b/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend
index 944f601..d5460fd 100644
--- a/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-yocto/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -1,3 +1,5 @@
+FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
+
 KMACHINE_atom-pc  = "yocto/standard/common-pc/atom-pc"
 KMACHINE_routerstationpro = "yocto/standard/routerstationpro"
 KMACHINE_mpc8315e-rdb = "yocto/standard/fsl-mpc8315e-rdb"
@@ -13,3 +15,7 @@ COMPATIBLE_MACHINE_mpc8315e-rdb = "mpc8315e-rdb"
 COMPATIBLE_MACHINE_routerstationpro = "routerstationpro"
 COMPATIBLE_MACHINE_beagleboard = "beagleboard"
 COMPATIBLE_MACHINE_atom-pc = "atom-pc"
+
+KERNEL_FEATURES_append_beagleboard = " no-preempt.scc"
+
+SRC_URI_append_beagleboard = " file://no-preempt.scc"
-- 
1.7.0.4

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

Re: [yocto] kernel26 'machine feature'

[Denys Dmytriyenko]

On Thu, Apr 05, 2012 at 09:17:28PM +0100, Chris Tapp wrote:
> On 5 Apr 2012, at 21:10, Gary Thomas wrote:
> 
> > On 2012-04-05 14:02, Chris Tapp wrote:
> >> Quite a few machine conf files specify the kernel26 machine feature. e.g., 
> >> crownbay.conf has:
> >> 
> >> MACHINE_FEATURES = "kernel26 screen keyboard pci usbhost ext2 ext3 x86 \
> >> acpi serial usbgadget"
> >> 
> >> What does this do? It's not listed at 
> >> http://www.yoctoproject.org/docs/latest/poky-ref-manual/poky-ref-manual.html#ref-features-machine
> >>  and seems to be at odds with:
> >> 
> >> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
> >> PREFERRED_VERSION_linux-yocto = "3.0%"
> > 
> > I don't think it does anything any more.  I'm pretty sure it used
> > to be used to select which style of kernel module utilities to
> > install (there was a change in kernel module format between 2.4
> > and 2.6), but it seems that's gone now.  At least in the Poky/Yocto
> > tree (oe-core + meta-yocto), there is no active use of this feature.

Yes, Classic OE (unlike OE-Core) used to support 2.4 and 2.6 kernels, hence 
the use flag.

> Thanks, I was hoping it was something as simple as that.
> 
> Another (possibly related) question - when the kernel built I noticed that 
> linux_libc_headers_yocto-2.6.37 was 'mentioned' in the log output. Why was 
> this used and not the headers for 3.0.18 ? The host is 2.6.32, so it doesn't 
> look like is was for the tool chain.

Those are "user-space" kernel headers for libc. Those usually don't need to 
match the exact kernel version, as APIs don't change that often between the 
kernel and user-space. Unless you need some specific new API that got added in 
the latest kernel...

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

Re: [yocto] [meta-intel][PATCH v2] ia32-base.inc: Use '=+' for IMAGE_FSTYPES

[Denys Dmytriyenko]

On Wed, Mar 28, 2012 at 05:50:30PM -0700, Khem Raj wrote:
> On Wed, Mar 28, 2012 at 4:53 PM, Darren Hart  wrote:
> 
> > Doesn't seem to me that it would impact the final output at all.
> 
> exactly that was my point.

FYI,
http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/17731/focus=18041

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

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[Denys Dmytriyenko]

On Sun, Mar 04, 2012 at 04:38:36PM -0500, Robert P. J. Day wrote:
> On Sun, 4 Mar 2012, Gary Thomas wrote:
> 
> > Can you explain what the toolchain problems are and why the versions
> > in oe-core don't work for meta-ti?
> 
>   i just finished doing a "bitbake core-image-minimal" for a
> beagleboard using the meta-ti layer, and having only to set a
> preferred version for udev.
> 
>   the build finished (albeit with a few warnings), and i have all of
> the images i would expect for a beagle xM.  should i consider this a
> form of success -- the simple fact that the build appeared to succeed?

Did you have meta-oe in your layer stack?

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

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[Denys Dmytriyenko]

On Sun, Mar 04, 2012 at 12:45:01PM -0700, Gary Thomas wrote:
> On 2012-03-04 12:27, Denys Dmytriyenko wrote:
> >On Sun, Mar 04, 2012 at 01:14:17PM -0500, Robert P. J. Day wrote:
> >>On Sun, 4 Mar 2012, Gary Thomas wrote:
> >>
> >>>On 2012-03-04 05:19, Robert P. J. Day wrote:
> >>>>
> >>>>not sure if you're suggesting i should now be able to build
> >>>>for, say, beagleboard with the meta-ti layer, but i cloned meta-ti
> >>>>into my yocto tree, added that layer to bblayers.conf, and tried
> >>>>to
> >>>>
> >>>>$ bitbake core-image-minimal
> >>>>
> >>>>and got what i believe gary was referring to above:
> >>>>
> >>>>$ bitbake core-image-minimal
> >>>>Pseudo is not present but is required, building this first before the main
> >>>>build
> >>>>ERROR: ParseError at
> >>>>/home/rpjday/yocto/git/meta-ti/recipes-misc/payload/bonescript.bb:5:
> >>>>Could not inherit file classes/systemd.bbclass
> >>>>ERROR: Command execution failed: Exited with 1
> >>>>
> >>>>or am i misreading what you wrote?
> >>>
> >>>Oops, that's one more workaround I forgot to mention.  This file
> >>>is in OE-core, but not in poky.  I made a local copy in my distro
> >>>layer, but there must be a better way to handle it.
> >>
> >>   um ... AFAICT, that .bbclass file is in meta-oe, not oe-core.  and
> >>since i have meta-openembedded checked out, i simply copied the whole
> >>thing into my yocto tree, then tweaked my bblayers.conf file to look
> >>like:
> >>
> >>BBLAYERS ?= " \
> >>   /home/rpjday/yocto/git/meta \
> >>   /home/rpjday/yocto/git/meta-yocto \
> >>   /home/rpjday/yocto/git/meta-ti \
> >>   /home/rpjday/yocto/git/meta-openembedded/meta-oe \
> >>   "
> >
> >Either way, meta-oe is still required for meta-ti due to toolchain issues...
> 
> Can you explain what the toolchain problems are and why the versions in
> oe-core don't work for meta-ti?

One of the issues:

https://lists.yoctoproject.org/pipermail/meta-ti/2012-February/000491.html

I haven't tried if either 3.0 or a pending 3.1 update for Panda (from 
omapzoom/ti-ubuntu), resolve this gcc-4.6 build issue. But either way I 
believe there was something else with one of our components not building with 
gcc-4.6 - SGX or multimedia, don't remember exactly.

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

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[Denys Dmytriyenko]

On Sun, Mar 04, 2012 at 01:14:17PM -0500, Robert P. J. Day wrote:
> On Sun, 4 Mar 2012, Gary Thomas wrote:
> 
> > On 2012-03-04 05:19, Robert P. J. Day wrote:
> > >
> > >not sure if you're suggesting i should now be able to build
> > > for, say, beagleboard with the meta-ti layer, but i cloned meta-ti
> > > into my yocto tree, added that layer to bblayers.conf, and tried
> > > to
> > >
> > > $ bitbake core-image-minimal
> > >
> > > and got what i believe gary was referring to above:
> > >
> > > $ bitbake core-image-minimal
> > > Pseudo is not present but is required, building this first before the main
> > > build
> > > ERROR: ParseError at
> > > /home/rpjday/yocto/git/meta-ti/recipes-misc/payload/bonescript.bb:5:
> > > Could not inherit file classes/systemd.bbclass
> > > ERROR: Command execution failed: Exited with 1
> > >
> > >or am i misreading what you wrote?
> >
> > Oops, that's one more workaround I forgot to mention.  This file
> > is in OE-core, but not in poky.  I made a local copy in my distro
> > layer, but there must be a better way to handle it.
> 
>   um ... AFAICT, that .bbclass file is in meta-oe, not oe-core.  and
> since i have meta-openembedded checked out, i simply copied the whole
> thing into my yocto tree, then tweaked my bblayers.conf file to look
> like:
> 
> BBLAYERS ?= " \
>   /home/rpjday/yocto/git/meta \
>   /home/rpjday/yocto/git/meta-yocto \
>   /home/rpjday/yocto/git/meta-ti \
>   /home/rpjday/yocto/git/meta-openembedded/meta-oe \
>   "

Either way, meta-oe is still required for meta-ti due to toolchain issues...

> then started:
> 
>   $ bitbake core-image-minimal(MACHINE=beagleboard)
> 
> and it seems to be building.  i'm entirely prepared for this to fail
> at some point, but i might as well see how far it gets.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[Denys Dmytriyenko]

On Fri, Mar 02, 2012 at 04:18:41PM -0700, Gary Thomas wrote:
> On 2012-03-02 15:50, William Mills wrote:
> >We will update the README when it is merely in need of testing.
> >Today, we know there is code that does not work with GCC 4.6.
> >Today, we know there are features in the recipes that do not work w/o 
> >Angstrom.
> 
> Can you elaborate on the above?  I have been [I think] successfully using 
> poky+meta-ti
> to support internal platform based on DM8148 and DM3730 - meta-ti is the best 
> choice
> for a kernel "jumping off point" for these platforms.  So far, I've only
> had to make a scant few tweaks to get this combo to work, in particular:
> 
> * In conf/local.conf, I use this to avoid parsing problems with some meta-ti
>   recipes (none of which I need at the moment)
> # Ignore troublesome TI recipes
> BBMASK = ".*/meta-ti/recipes-misc/"
> 
> * In distro.conf (I do have my own distro, but it's very close to poky), I 
> needed
> # Allow hardware overrides, e.g. armv7a
> OVERRIDES .= ":${SOC_FAMILY}"
> 
> With these minor additions, I've been able to use the meta-ti layer for [some]
> kernel work, u-boot, DSP support, etc - all the stuff one expects the layer
> to provide.
> 
> I know my setup is a bit outside pure poky+meta-ti, but it does show that
> you don't actually have to have Angstrom to use meta-ti.
> 
> It would be nice to understand what your concerns are, certainly the details
> of your two "Today,..." statements above, if they fall outside what I've 
> outlined
> here.

Gary,

Clearly, the README is meant for the new people, who might find it too 
complicated for the above fixes to be applied in order for them to avoid using 
Angstrom. But you are correct, besides known isues with gcc-4.6 not working 
for some components and hence requiring meta-oe; SOC_FAMILY and systemd 
dependency in recipes-misc/images were the only other two things requiring 
meta-angstrom layer.

You can try the updated meta-ti now, as it should solve those dependencies, 
thanks to Koen's latest patches. Please let us know how it works for you. 
Thanks.

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

Re: [yocto] proper recipe for building for beagle xM? meta-ti?

[Denys Dmytriyenko]

On Fri, Mar 02, 2012 at 05:22:30PM -0500, William Mills wrote:
> 
> 
> On 02/28/2012 05:28 PM, Robert P. J. Day wrote:
> >On Tue, 28 Feb 2012, Koen Kooi wrote:
> >
> >>Op 28 feb. 2012, om 22:55 heeft Robert P. J. Day het volgende geschreven:
> >>
> >>>On Tue, 28 Feb 2012, Bruce Ashfield wrote:
> >>>
> It is true that the beagleboard is a hardware reference board in the
> yocto consolidated kernel tree and meta-yocto layers. That means
> that it gets the yocto standard QA builds and boot testing.
> 
> That being said, if you are looking for the latest + specific
> features then you've been pointed in a good direction .. meta-ti
> will meet your needs.
> 
> As for disentangling and reducing questions in this area .. rest
> assured, we are working on it.
> >>>  ok, that's perfectly reasonable -- meta-yocto provides a generic,
> >>>well-tested product, while the meta-ti layer provides more
> >>>leading-edge content, correct?
> >>No, the amount of testing is not the difference, the amount of
> >>support for the board is. Meta-ti supports the camera interfaces, 3d
> >>engine, dsp, crypto engines, expansion boards, etc. Meta-yocto lacks
> >>all that for beagleboard.
> >   i understand that reasonably well, and i'll make one more
> >observation, then i'll shut up.
> >
> >   i cloned the meta-ti layer into my yocto clone, and here's the
> >majority of the meta-ti README:
> >
> >= start
> >
> >This layer depends on:
> >
> >URI: git://git.openembedded.org/openembedded-core
> >branch: master
> >revision: HEAD
> >
> >URI: git://git.openembedded.org/meta-openembedded
> >branch: master
> >revision: HEAD
> >
> >URI: git://git.angstrom-distribution.org/meta-angstrom
> >branch: master
> >revision: HEAD
> >
> >Currently meta-ti only works with the Angstrom distribution and hence
> >requires the meta-angstrom layer. There are known issues when using
> >gcc-4.6 based toolchain from OpenEmbedded-Core, thus gcc-4.5
> >toolchain, provided by meta-openembedded, is needed. It is planned to
> >fix these shortcomings in the near future and allow building the base
> >BSP part of meta-ti with different distributions and layer stacks,
> >such as: distro-less (only with OE-Core), with Yocto/Poky, with
> >Angstrom or Arago.
> >
> >Due to the above, it is now recommended to follow the instructions at
> >http://www.angstrom-distribution.org/building-angstrom
> >
> >This will set it up for the OpenEmbedded-core layout instead of the
> >old "Classic" OpenEmbedded-dev layout. You can optionally tweak
> >sources/layers.txt and conf/bblayers.conf to (de)select BSP layers.
> >
> >= end
> >
> >   by the time i'm done reading that, i'm not sure whether i've been
> >told i can use yocto as long as i do the necessary prep first, or that
> >i should give up on yocto and just use angstrom directly.  i'm fine
> >with either approach, but the README seems to just waffle *totally* on
> >which strategy to use.
> >
> >   quite simply, that README seems to provide nothing but more
> >confusion than anything else.
> 
> Congratulations you are the first beta tester for the new README.txt
> language :) (patched two days ago).

Actually, he is the first one to complain about the meat (i.e. added one 
paragraph with 3 statements) - everyone else before him was complaining about 
not enough info in the README, hence the addition.

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

Re: [yocto] [oe] Guidelines for creating a layer

[Denys Dmytriyenko]

On Fri, Nov 11, 2011 at 09:17:51AM -0500, Philip Balister wrote:
> Sorry to hack the subject and delete the earlier conversation, but Koen
> raises a good point here and I do not want it lost in the earlier
> discussion since I among others stopped reading the emails in detail.
> 
> Is there a good set of guidelines on the web site (not buried in a git
> repo) to guide people making the decision when to create a new layer, as
> opposed to contributing to an existing layer?
> 
> How do we make sure layers are well thought out and not people taking
> the path of least resistance?

I think this is a more generic and broad question to discuss it just between 
OE devs. So, my apologies for cross-post, but lets ask wider audience...

Denys


>  Original Message 
> Subject: Re: [oe] RFC Creation of a meta-telephony repository
> Date: Fri, 11 Nov 2011 11:45:52 +0100
> From: Koen Kooi 
> Reply-To: openembedded-de...@lists.openembedded.org
> To: openembedded-de...@lists.openembedded.org
> 
> 
> Having worked with layers for quite a while now I go through the following
> list before creating one:
> 
> Does it need to be a layer? -> no -> send patches to existing layers
>   |
>   yes
>   |
> Does it need to be a seperate repo? -> no -> send patches to existing repos
>   |
>   yes
>   |
> Is github/gitorious/etc good enough? -> no -> ...
>   |
>   yes
>   |
> Create repo + layer
> 
> And after a I while re-evaluate it.
> 
> regards,
> 
> Koen
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Agenda: Yocto Technical Team (Tuesday, June 21, 2011 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada))

[Denys Dmytriyenko]

On Fri, Jun 17, 2011 at 10:16:47PM +, Liu, Song wrote:
> All,
> 
> In order to make the meeting more effective, I would like to suggest that we 
> use the following status categories to track the status of each feature:
> 
> 1.Design (still in design stage)
> 2.Design Review (who is reviewing it)
> 3.Development (if you can tell the % completed so far, it would be great. 
> If it's too hard, don't bother)
> 4.Patch Review (Patch sent out for review)
> 5.Done (checked into master)
> 
> At the same time, we can certainly talk about blocking issues and any help 
> you would like from the team. Let me know if you have any suggestions or 
> would like to add anything to the Agenda.
> 
> 
> Agenda:
>  
> - Review Yocto 1.1 M2 schedule and Release Criteria - 20 min (Song)
> See details at: 
> https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.1_Release_Criteria 
> - Go over Sprint C items - 20 min (Song)
> - Opens - 10 min
> 
> 
> 
> Tuesday, June 21, 2011, 08:00 AM US Pacific Time 
> 916-356-2663, 8-356-2663, Bridge: 94, Passcode: 7964061
> Speed dialer: inteldialer://94,7964061 | Learn more

Hi,

Is there a meeting today (June 28th) and was the new bridge information 
published anywhere?

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

Re: [yocto] [oe] Collab Summit + ELC + TSC Meeting

[Denys Dmytriyenko]

On Mon, Mar 14, 2011 at 09:15:22PM -0400, Philip Balister wrote:
> On 03/14/2011 08:44 PM, Jeff Osier-Mixon wrote:
>>>
 There also was a request for more general purpose OEDAM over the 
 weekend,
 maybe in parallel or before/after TSC meeting:

 Any thoughts on that?
>>>
>>> Most of the replies there are from TSC people who are going to be there
>>> with the exceptions of yourself and Mike. I'm ok with having a more
>>> general meeting if the demand is there and Jefro can arrange it. If
>>> there are only a few people, I'd suggest something like meeting after
>>> the TSC meeting and finding food/drink together.
>>>
>>
>>
>> For those who don't know me, I'm Jefro.  :)
>>
>> As Richard says, a small crowd would probably interact better over
>> refreshments.  If you are interested in such a gathering, send me a note 
>> at
>> je...@jefro.net and let me know when you are available, and I'll see what 
>> I
>> can pull together.
>
> A quick show of hands, how many OE people can be in San Francisco over the 
> weekend of April 9-10? TSC people, go ahead and chime in for completeness.

I plan to be there.

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