Hi,
I am not sure if this is the right place to provide this info.
I came across an issue, which might be caused by a wrong entry in
meta-linaro. See
https://github.com/Angstrom-distribution/angstrom-manifest/issues/31
It seems that inheriting from image_types_uboot.bbclass is not required
anymore and causes a error with a newer openembedde-core.
The following seems to fix this little issue:
diff --git
a/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
b/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
index f928797..d83de70 100644
--- a/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
+++ b/meta-linaro/recipes-linaro/images/linaro-image-minimal-initramfs.bb
@@ -36,4 +36,4 @@ IMAGE_LINGUAS = ""
IMAGE_ROOTFS_SIZE = "8192"
-inherit core-image image_types_uboot
+inherit core-image
Regards
Feddischson
Hello,
I tried to build my distro with meta-linaro/meta-linaro, I've found an
issue on "perf".
When I added "perf" to IMAGE_INSTALL, it causes an error as below;
----
NOTE: Running task 1452 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_patch)
NOTE: Running task 1453 of 2124
(/home/linaro/vsbu/meta-uniphier/recipes-kernel/linux/linux-uniphier-arm64_4.4.bb:do_populate_lic)
NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task
do_kernel_configme: Started
NOTE: recipe perf-4.2-r9: task do_patch: Started
NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task
do_populate_lic: Started
NOTE: recipe perf-4.2-r9: task do_patch: Succeeded
NOTE: Running task 1454 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_populate_lic)
NOTE: recipe linux-uniphier-arm64-4.4.8-AUTOINC+5f1a02e66c-r0: task
do_populate_lic: Succeeded
NOTE: recipe perf-4.2-r9: task do_populate_lic: Started
WARNING: perf-4.2-r9 do_populate_lic: Could not copy license file
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING
to /home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/license-destdir/perf/COPYING:
[Errno 2] No such file or directory:
'/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING'
ERROR: perf-4.2-r9 do_populate_lic: QA Issue: perf: LIC_FILES_CHKSUM
points to an invalid file:
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/linux-tools-4.2/COPYING
[license-checksum]
NOTE: recipe perf-4.2-r9: task do_populate_lic: Succeeded
[...]
NOTE: Running task 2084 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_prepare_recipe_sysroot)
NOTE: recipe perf-4.2-r9: task do_prepare_recipe_sysroot: Started
NOTE: recipe perf-4.2-r9: task do_prepare_recipe_sysroot: Succeeded
NOTE: Running task 2085 of 2124
(/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_configure)
NOTE: recipe perf-4.2-r9: task do_configure: Started
ERROR: perf-4.2-r9 do_configure: Function failed: do_configure (log
file is located at
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/temp/log.do_configure.4060)
ERROR: Logfile of failure stored in:
/home/linaro/vsbu/develop/tmp-glibc/work/ph1_ld20_global-oe-linux/perf/4.2-r9/temp/log.do_configure.4060
NOTE: recipe perf-4.2-r9: task do_configure: Failed
ERROR: Task (/home/linaro/vsbu/openembedded-core/meta/recipes-kernel/perf/perf.bb:do_configure)
failed with exit code '1'
NOTE: recipe bind-9.10.3-P3-r0: task do_install: Succeeded
NOTE: recipe perl-5.24.1-r0: task do_package: Succeeded
NOTE: Tasks Summary: Attempted 2085 tasks of which 6 didn't need to be
rerun and 1 failed.
---
So it seems that it doesn't do do_fetch and just failed.
I've found you tried to re-enable do_fetch by d.delVarFlag() in
meta-linaro/meta-linaro/recipes-kernel/perf/perf.bbappend as below,
-----
LICENSE = "GPL-2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
PV = "4.2"
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI = "http://snapshot.debian.org/archive/debian/20150926T032755Z/pool/main/l/linu…"
SRC_URI[md5sum] = "9a4a83c22368281b85e4ab12dcc3ec95"
SRC_URI[sha256sum] =
"78b336fca5e250f205fe5bc10cc77943dc95c2d66899f0bc95963b3aab8ef644"
S = "${WORKDIR}/linux-tools-${PV}"
B = "${WORKDIR}/linux-tools-${PV}-build"
do_compile_prepend() {
mkdir -p ${S}/include/generated
echo "#define UTS_RELEASE \"${PV}\"" > ${S}/include/generated/utsrelease.h
}
# Ensure the above tarball gets fetched, unpackaged and patched
python () {
d.delVarFlag("do_fetch", "noexec")
d.delVarFlag("do_unpack", "noexec")
d.delVarFlag("do_patch", "noexec")
}
-----
But it seems not work correctly.
Actually, when I just removed the perf.bbappend file from meta-linaro
(just for debugging) bitbake completed to build rootfs image with perf.
I actually would like to know below
- Is there any recommended configuration for perf?
- Was that tested with any configure before?
- Is that tested (built) in nightly test build?
If it is clear, I can dig deeper by comparing configurations by myself.
Thank you,
--
Masami Hiramatsu
I'm still trying to get the external-linaro-toolchain going in master after
all the recent changes...
First of all, I'm seeing these:
ERROR: external-linaro-toolchain-2017.02-r0.arago35 do_install: oe_multilib_header: Unable to find header bits/long-double.h.
ERROR: external-linaro-toolchain-2017.02-r0.arago35 do_install: oe_multilib_header: Unable to find header bits/fp-fast.h.
They are coming from these changes:
http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/gli…http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-core/gli…
I believe (please correct me) those are due to Linaro toolchain 6.3 still
using glibc 2.23...
But the real problem comes when I try to build gcc (either "linaro-6.3" from
meta-linaro-toolchain, or "6.3" from oe-core) for the target using
external-linaro-toolchain:
| g++: error: gengtype-lex.c: No such file or directory
| g++: fatal error: no input files
It seems to come from oe-core gcc-source.inc, which removes gengtype-lex.c in
order to re-generate it:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/g…
Has anyone looked into fixing these issues? What's the status of
external-linaro-toolchain in master? Will this be looked at for 6.3 version,
or not until 7.x gets integrated? Thanks.
--
Denys
From: Denys Dmytriyenko <denys(a)ti.com>
When OE-Core updated binutils to version 2.28, many of the patches got updated
and renamed:
http://cgit.openembedded.org/openembedded-core/commit/?id=e9f839d5fe70a222c…
Most of those do not affect binutils recipes in meta-linaro-toolchain, as patches
are listed in version-specific .bb and .inc files for 2.25 and 2.27.
But binutils-cross.inc is one of the generic common .inc files in OE-Core, that
includes a patch that got renamed. Sync up this one patch with OE-Core to avoid
these warnings:
WARNING: /OE/master/sources/meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-crosssdk_linaro-2.25.bb: Unable to get checksum for binutils-crosssdk-x86_64-arago-linux SRC_URI entry 0002-binutils-cross-Do-not-generate-linker-script-directo.patch: file could not be found
WARNING: /OE/master/sources/meta-linaro/meta-linaro-toolchain/recipes-devtools/binutils/binutils-cross_linaro-2.25.bb: Unable to get checksum for binutils-cross-arm SRC_URI entry 0002-binutils-cross-Do-not-generate-linker-script-directo.patch: file could not be found
Signed-off-by: Denys Dmytriyenko <denys(a)ti.com>
---
...ss-Do-not-generate-linker-script-directo.patch} | 26 +++++++++++++++++-----
1 file changed, 20 insertions(+), 6 deletions(-)
rename meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/{no-tooldirpaths.patch => 0002-binutils-cross-Do-not-generate-linker-script-directo.patch} (75%)
diff --git a/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/no-tooldirpaths.patch b/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/0002-binutils-cross-Do-not-generate-linker-script-directo.patch
similarity index 75%
rename from meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/no-tooldirpaths.patch
rename to meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/0002-binutils-cross-Do-not-generate-linker-script-directo.patch
index 2bfc8d4..14299fd 100644
--- a/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/no-tooldirpaths.patch
+++ b/meta-linaro-toolchain/recipes-devtools/binutils/binutils-linaro-2.25/0002-binutils-cross-Do-not-generate-linker-script-directo.patch
@@ -1,20 +1,31 @@
+From 7c7de107b4b0a507d2aeca3e3a86d01cb4b51360 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem(a)gmail.com>
+Date: Mon, 6 Mar 2017 23:37:05 -0800
+Subject: [PATCH 02/15] binutils-cross: Do not generate linker script
+ directories
+
We don't place target libraries within ${exec_prefix}, we'd always place these
within the target sysroot within the standard library directories. Worse, the
append_to_lib_path code prefixes these paths with the sysroot which makes even
less sense.
-These directories therefore don't make sense in our case and mean we have to
-relocate all the linker scripts if they're present. Dropping them
+These directories therefore don't make sense in our case and mean we have to
+relocate all the linker scripts if they're present. Dropping them
gives a reasonable performance improvement/simplification.
Upstream-Status: Inappropriate
RP 2017/01/30
-Index: git/ld/genscripts.sh
-===================================================================
---- git.orig/ld/genscripts.sh
-+++ git/ld/genscripts.sh
+Signed-off-by: Khem Raj <raj.khem(a)gmail.com>
+---
+ ld/genscripts.sh | 23 -----------------------
+ 1 file changed, 23 deletions(-)
+
+diff --git a/ld/genscripts.sh b/ld/genscripts.sh
+index a42c4d7a4b..d727b4d07e 100755
+--- a/ld/genscripts.sh
++++ b/ld/genscripts.sh
@@ -189,29 +189,6 @@ append_to_lib_path()
fi
}
@@ -45,3 +56,6 @@ Index: git/ld/genscripts.sh
if [ "x${LIB_PATH}" = "x" ] && [ "x${USE_LIBPATH}" = xyes ] ; then
libs=${NATIVE_LIB_DIRS}
if [ "x${NATIVE}" = "xyes" ] ; then
+--
+2.12.0
+
--
2.7.4
not sure if this is the right list to point out oddities in the
documentation, but i'm reading this:
https://www.96boards.org/db410c-getting-started/HardwareDocs/HWUserManual.m…
and in the ToC, under "Low Speed Expansion Connector", there is no
mention of I2S, but in the very next section, "Introduction", under
"I/O Interfaces", one reads:
One 40-pin Low Speed (LS) expansion connector
UART, SPI, I2S, I2C x2, GPIO x12, DC power
^^^
should I2S be added to the ToC for consistency? or am i misreading
something?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
still clawing my way through the previous replies to my admittedly
tedious questions, but since i want to get specific with this issue, i
thought a new thread would be in order.
i think my biggest obstacle with this DB410C is just getting used to
a new boot process that is clearly more sophisticated than what i'm
used to with other boards, like my BBB.
rather than ask numerous questions, is there a canonical explanation
of the boot procedure, like say the hardware reference manual, or
something like that? i think a lot of my confusion will evaporate as
soon as i can say, "ah, so *that's* how the boot process works."
to that end, i'm going to check out the actual flashing utility in
the debian install image; i figure reading the source is the best way
to get to the bottom of this.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
i don't currently have access to the DB410C (colleague has wandered
off with it), but what should be a couple simple questions.
i'm reading the Installation Guide here:
https://github.com/96boards/documentation/wiki/Dragonboard-410c-Installatio…
and the basic recipe for installing the latest debian image without
using fastboot is given in the section:
https://github.com/96boards/documentation/wiki/Dragonboard-410c-Installatio…
i notice that that section clearly instructs the user to hook up a
mouse, keyboard and monitor to do this graphically. can you not do
that same install without all that hardware, like through the console
port?
and if i read a bit further, i see that if one uses "fastboot", it
appears that that would solve the problem. so if i had the board and
only a power adapter and USB cable to support a terminal window, what
would be the proper approach?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
before i get to installing and/or booting the linux image i build
with openembedded, i'd like to boot simply to the appropriate u-boot
binary for this target board.
first, i've already bitbaked an absolutely stock
"core-image-minimal" image for this board without issue using the
meta-qcom layer at
git://git.yoctoproject.org/meta-qcom
although nicolas tells me that that layer is more generally maintained
on github at:
https://github.com/ndechesne/meta-qcom
but that's easy enough to change. haven't booted into that image yet,
just wanted to verify that the build worked with no problem and
produced all the artifacts i expect from an OE build. worked
flawlessly.
to add u-boot to the build process, i went back and added the
following lines to my local.conf:
EXTRA_IMAGEDEPENDS += "u-boot"
UBOOT_MACHINE = "dragonboard410c_config"
again, build appeared to work perfectly, and generated the new
artifact:
u-boot-dragonboard-410c-2017.01-r0.bin
so, again, looks good. at this point, it appears that the recipe for
booting to u-boot is in the readme.txt file in the appropriate
directory in the u-boot source:
http://git.denx.de/?p=u-boot.git;a=blob;f=board/qualcomm/dragonboard410c/re…
can anyone verify that that is still the correct set of instructions?
and as i read it, to get to "fastboot" mode, i don't need the FTDI
connection, just USB OTG should do it, is that correct?
is there a way to install the u-boot binary on the SD card and boot
directly from there?
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
following up on a question i asked on the generic OE mailing list,
and nicolas dechesne's extensive reply:
http://lists.openembedded.org/pipermail/openembedded-core/2017-May/136547.h…
i figured i might as well move the discussion here since most of my
queries will be specific to that target board.
briefly, i unpacked my new dragonboard, cabled it up, plugged it in
and it popped into android as i expected it would, so i can at least
verify that that part works.
also, i have a fair bit of experience with ARM, openembedded and
u-boot, so i'll try not to ask idiotic questions. first question
coming shortly, might as well keep them modular and not try to ask
everything at once.
rday
--
========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca
Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
BTW, are there plans to fix external-linaro-toolchain flow with recipe
specific sysroot in master? Let me know if you need logs or any other help.
--
Denys
Hello
While using Linaro 'meta-linaro-toolchain' layer with own definition
of AArch64 machine (not using Linaro's meta-aarch64) I have noticed
seemingly incorrect use of LINKER_HASH_STYLE variable.
In the current master and morty branches (I have not checked others
yet), all meta-linaro-toolchain/recipes-devtools/gcc/gcc-linaro-*.inc
files contain following lines:
EXTRA_OECONF_BASE = "\
--disable-bootstrap \
--disable-libmudflap \
--with-system-zlib \
--with-linker-hash-style=${LINKER_HASH_STYLE} \
--enable-linker-build-id \
--with-ppl=no \
--with-cloog=no \
In my case, during the build, meta/recipes-devtools/gcc/gcc-cross.inc
gets included and breaks the libgcc qa checks by incorrectly
redefining hash style to SysV (snippet below, this was introduced in
morty):
# While we want the 'gnu' hash style, we explicitly set it to sysv here to
# ensure that any recipe which doesn't obey our LDFLAGS (which also set it to
# gnu) will hit a QA failure.
LINKER_HASH_STYLE ?= "sysv"
So, per my understanding, instead of directly using LINKER_HASH_STYLE,
Linaro GCC build shall parse LDFLAGS and get correct hash style there.
Of course, it may be also hardcoded or otherwise avoided but from the
comment above it seems that Yocto engineers explicitly insist on
LDFLAGS checking :)
Would this approach (use of LDFLAGS instead of LINKER_HASH_STYLE) be
acceptable for meta-linaro?
Best regards,
Artem Mygaiev
Hi folks,
I have two CES blockers with the master branch of https://github.com/ndechesne/meta-qcom
1. The build it defaulting to uni-proc. What change is required to enable all the cores.
2. Issuing reboot in a terminal window will not cause the device to reboot. A power cycle is required after issuing "reboot" from console.
Regards,
Joel Winarske (prior QC Senior Staff Engineer)
Senior Embedded Software Engineer
INRIX
(206) 512-6779
> Op 6 sep. 2016, om 20:42 heeft Denys Dmytriyenko <denis(a)denix.org> het volgende geschreven:
>
> Koen, Fathi, et al,
>
> Any chance to get EXTRA_OEMAKE to not hardcode ARM64 flags?
>
> https://git.linaro.org/openembedded/meta-linaro.git/blob/HEAD:/meta-optee/r…
It’s not planned, but we wouldn’t say no to patches :)
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Greetings,
Have to call it "v3" as I've sent a different patch with "v2" earlier.
This is a reworked version of "[PATCH] mali-userland-drm: add support for mali450 binaries for hikey":
- the __anonymous() function (inspired by mesa.inc) removed, as I doubt that it adds value in this case, and
am not sure it handles the package names correctly.
- recipe file name changed. Tried to minimize the use of non-default values where possible.
All in all, it now looks more similar to [1].
- using the mesa_%.bbappend looks unavoidable for me, and it should match the files included into the driver
tarball (from SRC_URI), so the mesa_%.bbappend has been added to this patch.
- more comments added.
Regarding the PACKAGE_ARCH = "${MACHINE_ARCH}", the driver is indeed specific for HiKey (would not fit
other boards with mali450), but I don't know the details.
Thanks,
Andrey
[1] https://github.com/ARM-software/meta-mali/blob/master/recipes-graphics/mali…
From: Andrey Konovalov <andrey.konovalov(a)linaro.org>
Date: Wed, 8 Jun 2016 00:07:21 +0300
Subject: [PATCH 1/4] Add public Mali450 driver for wayland
Signed-off-by: Andrey Konovalov <andrey.konovalov(a)linaro.org>
---
.../mali-userland/mali450-userland_r6p0_01rel0.bb | 55 ++++++++++++++++++++++
recipes-graphics/mesa/mesa_%.bbappend | 11 +++++
2 files changed, 66 insertions(+)
create mode 100644 recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
create mode 100644 recipes-graphics/mesa/mesa_%.bbappend
diff --git a/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb b/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
new file mode 100644
index 0000000..63bcf51
--- /dev/null
+++ b/recipes-graphics/mali-userland/mali450-userland_r6p0_01rel0.bb
@@ -0,0 +1,55 @@
+SUMMARY = "Mali450 libraries (drm backend)"
+
+LICENSE = "Proprietary"
+LIC_FILES_CHKSUM = "file://${WORKDIR}/END_USER_LICENCE_AGREEMENT.txt;md5=3918cc9836ad038c5a090a0280233eea"
+
+SRC_URI[md5sum] = "36f39e86ccfe5a6a4cb2090865c339ba"
+SRC_URI[sha256sum] = "dd136931cdbb309c0ce30297c06f7c6b0a48450f51acbbbc10529d341977f728"
+
+PROVIDES += "virtual/egl virtual/libgles1 virtual/libgles2 virtual/libdrm"
+
+DEPENDS = "virtual/mesa"
+
+BACKEND="drm"
+
+SRC_URI = " http://malideveloper.arm.com/downloads/drivers/binary/utgard/r6p0-01rel0/ma…"
+
+S = "${WORKDIR}/wayland-drm"
+
+# The SRC is just a set of binaries to install - nothing to configure and to
+# compile
+do_configure[noexec] = "1"
+do_compile[noexec] = "1"
+
+do_install() {
+ install -m 755 -d ${D}/${libdir}
+ install ${S}/libMali.so ${D}/${libdir}
+ ln -sf libMali.so ${D}/${libdir}/libEGL.so.1.4
+ ln -sf libEGL.so.1.4 ${D}/${libdir}/libEGL.so.1
+ ln -sf libEGL.so.1 ${D}/${libdir}/libEGL.so
+ ln -sf libMali.so ${D}/${libdir}/libGLESv1_CM.so.1.1
+ ln -sf libGLESv1_CM.so.1.1 ${D}/${libdir}/libGLESv1_CM.so.1
+ ln -sf libGLESv1_CM.so.1 ${D}/${libdir}/libGLESv1_CM.so
+ ln -sf libMali.so ${D}/${libdir}/libGLESv2.so.2.0
+ ln -sf libGLESv2.so.2.0 ${D}/${libdir}/libGLESv2.so.2
+ ln -sf libGLESv2.so.2 ${D}/${libdir}/libGLESv2.so
+ ln -sf libMali.so ${D}/${libdir}/libgbm.so.1
+ ln -sf libgbm.so.1 ${D}/${libdir}/libgbm.so
+ ln -sf libMali.so ${D}/${libdir}/libwayland-egl.so
+}
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+
+# The mali-450 driver tarball has only *.so files, so all the packages
+# except the ${PN} one would be empty
+PACKAGES = "${PN}"
+FILES_${PN} += "${libdir}/*.so* "
+
+INSANE_SKIP_${PN} = "ldflags dev-so"
+
+# To get the egl/gles headers and the packageconfig files (missing from this
+# mali-450 driver tarball) we have to build mesa, and to handle the conflicts
+# due to both mali450-userland, and mesa providing the same libraries.
+RREPLACES_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+RPROVIDES_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
+RCONFLICTS_${PN} = "libegl libegl1 libgles1 libglesv1-cm1 libgles2 libglesv2-2 libgbm"
diff --git a/recipes-graphics/mesa/mesa_%.bbappend b/recipes-graphics/mesa/mesa_%.bbappend
new file mode 100644
index 0000000..3020b2b
--- /dev/null
+++ b/recipes-graphics/mesa/mesa_%.bbappend
@@ -0,0 +1,11 @@
+# Remove the *.so libraries - the ones provided by mali-450 driver are to
+# be used for HiKey
+do_install_append() {
+ rm -f ${D}/${libdir}/libEGL.so*
+ rm -f ${D}/${libdir}/libGLESv1_CM.so*
+ rm -f ${D}/${libdir}/libGLESv2.so*
+ rm -f ${D}/${libdir}/libgbm.so*
+ rm -f ${D}/${libdir}/libwayland-egl.so*
+}
+
+PROVIDES_remove = "virtual/libgles1 virtual/libgles2 virtual/egl"
--
1.9.1
The base_contains function is deprecated and we ought to use
bb.utils.contains instead.
Signed-off-by: Max Krummenacher <max.krummenacher(a)toradex.com>
---
Hi
missed that one with my sed script in patch 9d228b1d2dc6e2e3f677c04cb83bbb6e04319e94
Sorry about that.
Max
.../external-linaro-toolchain/external-linaro-toolchain.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
index 6a72ff7..eb82e96 100644
--- a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
+++ b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
@@ -93,7 +93,7 @@ do_install() {
fi
# fix up the copied symlinks (they are still pointing to the multiarch directory)
- linker_name="${(a)bb.utils.contains("TUNE_FEATURES", "aarch64", "ld-linux-aarch64.so.1", base_contains("TUNE_FEATURES", "callconvention-hard", "ld-linux-armhf.so.3", "ld-linux.so.3",d), d)}"
+ linker_name="${(a)bb.utils.contains("TUNE_FEATURES", "aarch64", "ld-linux-aarch64.so.1", bb.utils.contains("TUNE_FEATURES", "callconvention-hard", "ld-linux-armhf.so.3", "ld-linux.so.3",d), d)}"
ln -sf ld-${ELT_VER_LIBC}.so ${D}${base_libdir}/${linker_name}
ln -sf ../../lib/libnsl.so.1 ${D}${libdir}/libnsl.so
ln -sf ../../lib/librt.so.1 ${D}${libdir}/librt.so
--
2.6.6
Are the instructions here:
https://wiki.linaro.org/HowTo/ARMv8/OpenEmbedded
...still accurate? That wiki has not been updated in ~3 years.
I'm looking for steps to build a simple openembedded based aarch64
rootfs.
Anywhere else I should be looking?
Thanks,
Stuart Yoder
NXP Semiconductor
Added into gerrit:
https://review.linaro.org/11498https://review.linaro.org/11499
On 20 April 2016 at 19:53, Denys Dmytriyenko <denis(a)denix.org> wrote:
> From: Denys Dmytriyenko <denys(a)ti.com>
>
> With migration from crosstool-NG to ABE, libgcov.a changed path and is now
> available in ${libdir}. So, instead of being packaged into own libgcov-dev
> package, it gets picked up by "catchall" libc6-staticdev package. This mostly
> works, as long as nothing directly depends on libgcov-dev. Unfortunately,
> packagegroup-core-standalone-sdk-target does and is the one being used when
> building SDKs with -c populate_sdk. Correct path to generate libgcov-dev pkg.
>
> Signed-off-by: Denys Dmytriyenko <denys(a)ti.com>
> ---
> This is required for fido/jethro, but krogoth/master introduces single -dev
> package rule, so separate libgcov-dev package can be dropped entirely.
>
> .../external-linaro-toolchain/external-linaro-toolchain.bb | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> index ea41179..531caf7 100644
> --- a/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> +++ b/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb
> @@ -301,7 +301,7 @@ PKGV_gdbserver = "${ELT_VER_GDBSERVER}"
> ALLOW_EMPTY_${PN}-mtrace = "1"
> FILES_${PN}-mtrace = "${bindir}/mtrace"
>
> -FILES_libgcov-dev = "${libdir}/${TARGET_SYS}/${BINV}/libgcov.a"
> +FILES_libgcov-dev = "${libdir}/libgcov.a"
>
> FILES_libsegfault = "${base_libdir}/libSegFault*"
>
> --
> 2.2.0
>
> _______________________________________________
> linaro-dev mailing list
> linaro-dev(a)lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/linaro-dev
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Hi Koen,
I think you mentioned that issue already briefly at ELC, but I stumbled
upon it independently again:
We have issues with the versioning of the Linaro toolchain in Ångström.
While it happens with the Ångström package feed, I think it is actually
a problem of how the meta-linaro layer uses PV/PR.
It seems that the change to the 2015.11-2 release added yet another
hyphen, which gets interpreted wrong by opkg. When we build a new image,
and try to download something which just asks for linaro-5.2, we get the
following error:
Not downgrading libgcc1 from linaro-5.2-r2015.11-2 to
linaro-5.2-r2015.11.0 on root.
Downgrading? The "2015.11-2" release should be an upgrade...
This can be verified when checking the versions using the
compare-versions command:
$ opkg compare-versions "linaro-5.2-r2015.11-2" '>='
"linaro-5.2-r2015.11"; echo $?
1
Error code is set, hence the comparison is _not_ satisfied. Whether
there is another .0 at the end of r2015.11 does not matter (Btw, where
is that coming from?)
Things after the hyphen are interpreted by opkg as package revision...
This leads to the following akward situation (added some debug prints
into opkg's source):
$ ./src/opkg --offline-root . compare-versions linaro-5.2-r2015.11-2
'>=' linaro-5.2-r2015.11
parse_version, version linaro-5.2-r2015.11, revision 2
parse_version, version linaro-5.2, revision r2015.11
This change introduced the additional hyphen:
https://git.linaro.org/openembedded/meta-linaro.git/commitdiff/62333718e8f3…
I think everything should work if that additional -2 would be a .2...
However, hyphens in the main version number are actually quite frowned
upon, also the debian policy does not allow hyphens:
https://www.debian.org/doc/debian-policy/ch-binary.html#s-versions
So maybe even the hyphen in linaro-5.2 should be something else...
--
Stefan
On 19 April 2016 at 07:30, Koen Kooi <koen.kooi(a)linaro.org> wrote:
> On 18 April 2016 at 23:03, Denys Dmytriyenko <denis(a)denix.org> wrote:
>> On Fri, Apr 15, 2016 at 08:01:48AM +0200, Koen Kooi wrote:
>>> On 14 April 2016 at 18:27, Denys Dmytriyenko <denis(a)denix.org> wrote:
>>> > On Thu, Apr 14, 2016 at 10:04:18AM +0200, Koen Kooi wrote:
>>> >> On 14 April 2016 at 07:09, Fathi Boudra <fathi.boudra(a)linaro.org> wrote:
>>> >> > On 14 April 2016 at 00:05, Denys Dmytriyenko <denis(a)denix.org> wrote:
>>> >> >> Koen, et al,
>>> >> >>
>>> >> >> With the release of 5.3-2016.02 Linaro toolchain it is now possible to use the
>>> >> >> binary version with the external-linaro-toolchain recipe. Are there any
>>> >> >> immediate plans to provide corresponding recipes to build the same version of
>>> >> >> the toolchain from sources? Thanks.
>>> >> >
>>> >> > Yes, the recipes for 5.3-2016.02 will be added. It's targeted for next cycle.
>>> >>
>>> >> The test build is still running, but here's the gerrit:
>>> >>
>>> >> https://review.linaro.org/11376
>>> >
>>> > Thanks!
>>>
>>> It breaks grub, I'll sort that out with the toolchain folks later today.
>>>
>>> > What about glibc-2.21?
>>>
>>> Haven't looked at that one yet.
>>
>> Any updates on the above 2 items? It's not exactly blocking me currently, as I
>> have workarounds in place, but it would be nice to get these resolved in
>> krogoth/2.1... Thanks!
>
> For grub we need both a newer toolchain and a newer binutils. Still
> haven't looked at glibc 2.21 yet, sorry.
An update to the gcc situation: we've decided to move it to the next
cycle (2016.06) so we can use a newer gcc release with the fix
included. I've retracted https://review.linaro.org/#/c/11376/ to
reflect this.
--
Koen Kooi
Builds and Baselines | Release Manager
Linaro.org | Open source software for ARM SoCs
Hi,
With RPB environment I can easily add some new layer via a local_manifest
way on top of rpb manifest.
In this case, I see a potential issue and I would like to open a
discussion about it.
If I add a layer:
- bsp layer: env setup script take into account all the bsp layer
available on the source tree.
- framework layer (like meta-qt5, meta-browser, ...): in this case there
is no automatic way to use this layer on the build, we must manually change
the bblayers.conf file before the compilation to take into account the
framework layer.
Question:
Have you some plan to support such request ?
The goal are to provide a reproducible build which are as based on RPB
which add the support of new frameworks by using the same way to initialize
the environment without making manual change on bblayers.conf.
Proposal:
- if there is bblayers.conf and local.conf files on local_manifest, this
files will overwrote the default files available on manifest via the env
setup script.
Thanks for your feedback.
Regards
Christophe Priouzeau
--
Christophe Priouzeau
Software Engineer from STMicroelectronics
Group: LHG (Linaro Digital Home Group)
STMicroelectronics | 9 Rue Pierre Felix Delarue | 72000 Le mans | France
I am trying to create an image in openembedded similar to the
hikey-jessie_developer_20151130-387.img. I created an image with 2
partitions, boot (fat32) and rootfs (ext4). My kernel (Image) and device
tree are located in the boot partition. When I put the card in the dev
board and turn it on it does not boot. I get a message "Fail to start
BootNext". I can boot the kernel using the sd card grub option on the
eMMC, but not by default. Are there directions on how to create an sd
card image like the hikey-jessie_developer_20151130-387.img?
-Machon
On Fri, Feb 19, 2016 at 1:38 PM, Xi Zhou Zhou <joel.zhou(a)broadcom.com> wrote:
> I download the pre-built toolchain for one of our armv6 board.
> https://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-…
This is the embedded toolchain, for systems not running linux.
> After plug it into Yocto as an external toolchain, it failed to install it
> correctly.
Yocto is linux, so there is a contradiction here. It isn't clear why
you are trying to do this, as this is not expected to work.
> ../meta-linaro/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/external-linaro-toolchain.bb,
> do_install
> | DEBUG: Executing shell function do_install
> | cp: cannot stat
> `/opt/gcc-linaro-arm-none-eabi-4.8-2014.04_linux/arm-none-eabi/libc/lib/*':
> No such file or directory
Yocto is looking for the linux toolchain sysroot, but this isn't a
linux toolchain, so there is no sysroot.
If Yocto is supposed to work with embedded toolchains, then you need
to fix the yocto scripts to make the toolchain sysroot optional.
Or if you are really trying to download the linux toolchain, then you
should instead grab
https://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-…
Jim
Hi all,
I download the pre-built toolchain for one of our armv6 board.
https://releases.linaro.org/14.04/components/toolchain/binaries/gcc-linaro-…
After plug it into Yocto as an external toolchain, it failed to install it
correctly.
../meta-linaro/meta-linaro-toolchain/recipes-devtools/external-linaro-toolchain/
external-linaro-toolchain.bb, do_install
| DEBUG: Executing shell function do_install
| cp: cannot stat
`/opt/gcc-linaro-arm-none-eabi-4.8-2014.04_linux/arm-none-eabi/libc/lib/*':
No such file or directory
Any suggestion?
Thanks,
Joel