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
========================================================================