Hi,
On 2017-06-15 17:52, Thomas A. F. Thorne MEng AUS MIET wrote:
Good afternoon,
I am putting together a meta-company-name layer to hold some internal
code. This will contain a few BSPs for our units, some internally
developed applications and a few config file patches. I am having
trouble g
On 2017-05-31 21:20, Andre McCurdy wrote:
Keeping the existing platform but updating the CPU would have the
advantage that qemuarm could then share binaries and sstate with real
world ARM targets.
It would also be a step towards defining an official "generic ARMv7"
tuning target within OE, whic
Hi,
Great that you managed to get to get open-source graphics on those
boards!
I would be very interested in the i.mx6 stuff. In roughly a week I'll
fly to a board manufacturer to train some of their customers in Yocto/OE
and friends.
Maybe I can get them to send you some i.mx6 quad board
Hi,
On 2017-04-13 11:24, Gary Thomas wrote:
On 2017-04-13 09:34, Gary Thomas wrote:
I'm trying to understand why 'perl' is being built for my target
even though I don't mention it in any of the package recipes used
to build that target. When I used 'taskexp', I found that
'perl:do_build'
only
Hi,
On 2017-01-18 04:54, Joshua Watt wrote:
external SDK:
everything the same as above, but for some packages there should be
only libraries - no header files.
Is there a reason why you want the libraries without the headers? It
doesn't seem particularly useful to be able to link a program ag
Hi,
A client would like to dish out an SDK to their customers, but only with
a subset of header files compared to those they use internally.
internal SDK:
As it is right now when you build an sdk with e.g. bitbake whatever -c
populate_sdk
external SDK:
everything the same as above, but for
Hi,
On 2016-10-14 04:27, Joshua Lock wrote:
This is a reasonable goal, but something I'd rather see addressed in
the proposed PublishArtifacts rewrite. As we're trying to release morty
right now I'd like to avoid changes to the AB behaviour until after the
release.
I'm absolutely happy with t
Hi Robert,
On 2016-10-14 05:12, Robert Yang wrote:
QB_SYSTEM_NAME: qemu name, e.g., "qemu-system-i386"
QB_OPT_APPEND: options to append to qemu, e.g., "-show-cursor"
...
Could you also please mention which of those values are obligatory and
what are the default values in case they are not c
Hi,
On 2016-10-13 16:29, Lock, Joshua G wrote:
Can you help me understand why you needed to create this patch?
We've run into some issues recently where toolchains we expected to be
built weren't and the PublishArtifacts buildstep failing because
they're missing is useful. With this change we'l
Hi,
On 2016-10-11 17:39, Joshua Lock wrote:
aren't set.
If you point PRSERV_HOST and PRSERV_PORT at a non-localhost PRServer
the git repo won't be fetched/updated.
I use the Y-AB for nightly builds and to populate DL_DIR and friends.
It's also not unusual to use this machine as the "master"
Hi,
With a latest and greatest Yocto Autobuilder I noticed stuff like this
when I restart it:
---
...
Updating PRSERV
remote: Counting objects: 20, done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 20 (delta 17), reused 0 (delta 0)
Unpacking objects: 100% (20/20), done.
Fro
From 8f28afbfc21dc84f076b0cc620e578f9607d1465 Mon Sep 17 00:00:00 2001
From: Robert Berger
Date: Mon, 10 Oct 2016 06:26:06 +
Subject: [yocto-autobuilder][PATCH] PublishArtifacts.py: deal only with built toolchains, cp also
md5 and manifests
Signed-off-by: Robert Berger
---
.../autobuilder
Hi,
On 2016-10-08 18:17, Bill Randle wrote:
Hi,
I think I would leave the toolchain artifact as is, but just surround
the the 'cp' with an 'if' statement. E.g.,:
if [ -e ]; then
cp ;
fi;
if [ -e ]; then
cp ;
fi;
This sounds like a brilliant idea. It looks like now I hav
Hi,
On 2016-10-08 09:28, Bill Randle wrote:
All the "standard" build configs produce both x86 and x86_64
toolchains - which makes sense, since it's not known what build host
the user is using and the AB needs to show both are buildable. In your
case, you know you have an x86_64 machine and don'
Hi,
On 2016-10-07 22:05, Bill Randle wrote:
Hi Robert,
I see a couple of problems with this proposed patch. First, it's not
clear the existing code is broken.
Try this [1] to see the problem.
[1]
https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.4.x/multi-v7-ml/yocto-aut
Hi,
On 2016-10-07 22:05, Bill Randle wrote:
Hi Robert,
I see a couple of problems with this proposed patch. First, it's not
clear the existing code is broken.
Here[1] is a paste of the error.
cp: cannot stat
'/tmp/yocto-autobuilder/yocto-autobuilder/yocto-worker/res-custom-morty-multi-v7-co
Hi,
I use the latest and greatest yocto autobuilder:
f9b4e02730a5e712ee9085e2480f9a3b8b00f56d
It looks like Publishing Artifacts tries to find the toolchain instead
of build/build/tmp/deploy/sdk (where it is built) here
build/build/tmp/deploy/images/toolchain-x86_64
This patch [1] fixes th
Hi,
On 2016-09-27 11:03, s.jar...@esa-grimma.de wrote:
Hej
Some error occurred. I give a print (sorry for that German text - but
the error should be clear):
##
GEN ./Makefile
HOSTLD scripts/kconfig/mconf
scripts/kconfig/mconf.o: In Funktion `show_help':
mconf.c:(.text+0x914): N
Hi,
On 2016-09-13 21:55, Ronald Oakes wrote:
Any ideas how to proceed?
1) Can you try to use it from an in-tree kernel module? (modify the
attachment)
2) Can you grep in your kernel config for
CONFIG_CC_STACKPROTECTOR and friends?
Regards,
Robert
>From 69cabc395bd097dde34664b4e1fe1c57
Hi,
I use multi-v7 kernel for the zedboard and create a custom packagegroup
which contains openCV[1] which I add to the image.
[1]
https://github.com/RobertBerger/meta-mainline/blob/jethro-training-v4.4.x/multi-v7-ml/recipes-core/packagegroups/packagegroup-opencv.bb
Regards,
Robert
--
__
Hi,
Shouldn't it be possible to build a bare-metal Cortex-M4 compiler with
the YP and build a small RTOS like FreeRTOS with this compiler?
Regards,
Robert
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yoct
Hi,
On 2016-08-09 07:20, Daniel. wrote:
Hi Patrick,
If you are running your image embedded at some board, and have easy
access to the board, you can plug it to network and make u-boot
download kernel from your machine. So that deploy a new kernel becomes
simple as copy the new kernel to the tft
Hi,
On 2016-08-05 10:24, s.jar...@esa-grimma.de wrote:
@TOOLCHAIN_OPTIONS: Where these are set in custom layers(like meta-atmel)?
If you ask me I would say here [1]:
DEFAULTTUNE = "cortexa5thf"
Here [2] are the available HF options:
# HF Tunes
AVAILTUNES += "cortexa5hf cortexa5thf cortexa
Hi,
On 2016-08-04 16:21, Maciej Borzęcki wrote:
Another option that I see is to set BBMASK =
"meta-ivi/recipes-graphics/wayland/" in local.conf, but that's a bit
ugly, hence I'd say it's a temporary solution only.
BBMASK does not seem to apply only to local.conf anymore[1], so this
might not
Hi,
I was wondering if there is something like kernel config fragments also
available for device trees from the YP.
It would be convenient, since kernel configuration and device tree might
be related in some cases.
Regards,
Robert
--
___
yocto ma
Hi,
It may sound slightly crazy:) but can I use a toolchain, which was
created by Poky as an external toolchain for Poky?
What I am after is something like this:
I create a multiplatfrom v7 compatible Yocto project, which spits out
toolchain/rootfs/kernel/various device trees.[1]
Now I nee
-pkgs -p mtd-utils
mtd-utils-jffs2
mtd-utils-ubifs
mtd-utils-misc
mtd-utils-dbg
mtd-utils-dev
mtd-utils-doc
mtd-utils
oe-pkgdata-util list-pkgs -p mtd-utils-native
oe-pkgdata-util list-pkgs -p mtdev
mtdev-dbg
mtdev-staticdev
mtdev-dev
mtdev
PS if you wish to email me could you please use my em
On 2016-02-16 05:40, Burton, Ross wrote:
Hi,
On 16 February 2016 at 09:03,
wrote:
It seems to be insufficient to add mtd-utils to a packagegroup[1]
and add this to the image for it to be installed in the image.
The package is being built and I can install it afterwards e.g.
opkg install mtd-u
Hi,
I would like to have ubi-utils, which is part of mtd-utils, installed on
my target.
It seems to be insufficient to add mtd-utils to a packagegroup[1] and
add this to the image for it to be installed in the image.
The package is being built and I can install it afterwards e.g. opkg
instal
Hi,
I have a simple recipe like this:
---
DESCRIPTION = "Simple helloworld application + git"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM =
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRCREV = "ecf1f0
Hi,
I hacked together a qemu target which supports vexpress-a9.
In order to get
core-image-minimal -c testimage
to work as well I had to cook
meta/lib/oeqa/utils/qemurunner.py
scripts/runqemu
scripts/runqemu-internal
This does not seem to be a generic way to do such a thing.
What's the prop
Hi,
On 2014-07-14 05:46, Paul Eggleton wrote:
Absolutely. As a starting point I'd recommend the following section of
the
manual:
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#performing-automated-runtime-testing
Thanks!
Some of the capabilities in this area were ad
Hi,
On 2014-07-21 08:35, Stoicescu, CorneliuX wrote:
Hello Robert,
Sorry for the late reply, I missed this mail.
We do have an almost fully automated way of doing what you need. First
of all, how do you want to run the automated tests? From the
autobuilder as a build step OR from another machi
33 matches
Mail list logo