OpenEmbedded

openembedded@lists.linaro.org

1 participants
652 discussions

external-linaro-toolchain and TI's meta-arago/meta-argao-extra

by chris.laplante＠agilent.com

Hello all, It seems that the external-linaro-toolchain recipe (in meta-linaro/meta-linaro-toolchain) doesn't work unless TI's meta-arago/meta-arago-extras layer is also present. That layer contains, among other things: meta-arago-extras/recipes-devtools/meta/ * external-linaro-toolchain.bbappend - seems to fix a variety of packaging errors, and relaxes the requirement that external-linaro-toolchain itself provide libc Linux headers * external-linaro-sdk-toolchain.bb - provides the cross-canadian toolchain, for building nativesdk packages. My understanding is that part is useable when the host machine is the same as the SDK machine (e.g. both x86_64-linux), since otherwise you would need two external toolchains. * external-linaro-toolchain-cross.bb - seems to just provides some tweaks * external-linaro-bfd-version.inc - populates ELT_VER_BFD with the detected version meta-arago-extras/conf/distro/include/ * tclibc-external-linaro-toolchain.inc - the TCLIBC configuration that tells Yocto you're using the external Linaro glibc, instead of having Yocto built it. Is my understanding correct? If so, I'd be curious to know why these files are in meta-arago, as opposed to just being moved into meta-linaro-toolchain itself. If it's just due to a lack of time, then I'd be more than willing to help out. As things currently exist, I find the 'external-linaro-toolchain' recipe in meta-linaro to be a bit of a "carrot on a stick" - it looks really promising and enticing, but you can't get it to work without lots of effort. That effort ultimately amounts to implementing the changes that are present in meta-arago-extras... Thank you, Chris Laplante

8 years, 9 months

[PATCH] python-wand: add SRCREV, fix QA issue and add comment about imagemagick version

by Martin Jansa

* use SRCREV instead of tag name, so that bitbake doesn't translate tag to SRCREV every time it's parsing this recipe * fix QA issue: ERROR: QA Issue: python-wand: Files/directories were installed but not shipped in any package: /usr/share /usr/share/README.rst * add comment about imagemagick version needed to use python-wand-native otherwise it will use imagemagick from host Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com> --- This is needed in all 3 branches: [morty][pyro][master] But for pyro you'll need to first backport from master (or forward port from pyro) the upgrade to 0.4.4 from: commit 7ed523b06bde259f99b21a15e8c936af4f18c752 Author: Fathi Boudra <fathi.boudra(a)linaro.org> Date: Thu Oct 5 22:46:48 2017 +0300 meta-optee: python-wand: upgrade to latest release 0.4.4 Latest python-wand release is from October 2016. Update to latest release: 0.4.4. Change-Id: I23dc1fbb817bbb26357c3ab6dcc86b251eea36e6 Signed-off-by: Fathi Boudra <fathi.boudra(a)linaro.org> .../recipes-devtools/python/python-wand_0.4.4.bb | 24 +++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb index 1043987..9679b9c 100644 --- a/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb +++ b/meta-optee/recipes-devtools/python/python-wand_0.4.4.bb @@ -6,11 +6,33 @@ LIC_FILES_CHKSUM = "file://LICENSE;md5=170eafd687d4a2b950819cd5e067e6d5" SRCNAME = "wand" -SRC_URI = "git://github.com/dahlia/wand.git;tag=${PV}" +SRCREV = "c731c620c3c96c409a194dafab396ffbb97d6702" +SRC_URI = "git://github.com/dahlia/wand.git" S = "${WORKDIR}/git" inherit setuptools +# Requires imagemagick-6 while meta-oe morty and newer provides imagemagick-7 which isn't compatible with wand +# +# You can import imagemagick-5 from older meta-oe, before this upgrade: +# commit ec660639ecea3fcb6e554b6f1bafc504e8f2fc78 +# Author: Randy MacLeod <randy.macleod(a)windriver.com> +# Date: Mon Aug 8 17:41:34 2016 -0400 +# imagemagick: upgrade from 6.9.2 to 7.0.2 +# and add this commit on top of that: +# commit dfcb67af35936a351789044039a55e3fad299c1a +# Author: Andreas Müller <schnitzeltony(a)googlemail.com> +# Date: Sun Sep 18 02:47:26 2016 +0200 +# imagemagick: depend on fftw not virtual/fftw +# +# We need this old version becase python-wand-native used here +# depends on older imagemagick-native as discussed here: +# https://stackoverflow.com/questions/37011291/python-wand-image-is-not-recog… +# there still isn't newer python-wand supporting 7.* version: +# https://github.com/dahlia/wand/blob/4fe2c6ba9cb0d4105361cea6e9e9e8311608047… + DEPENDS += " imagemagick-native" BBCLASSEXTEND = "native" + +FILES_${PN} += "${datadir}" -- 2.7.4

8 years, 9 months

Possible issue in meta-linaro (http://git.linaro.org/openembedded/meta-linaro)

by Christian Haettich

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

9 years

Failed to build perf package with meta-linaro/receipes-kernel/perf

by Masami Hiramatsu

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

9 years

[meta-optee][PATCH] optee-client: Respect LDFLAGS set from OE build

by Martin Jansa

* Unify LFLAGS/LDFLAGS variable names (only tee-supplicant was using LDFLAGS). * Fixes: ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/bin/tee-supplicant' No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/lib/libteec.so.1.0' [ldflags] ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: Function failed: do_package_qa ERROR: Logfile of failure stored in: optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/temp/log.do_package_qa.31246 Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com> --- meta-optee/recipes-security/optee/optee-client.bb | 1 + .../0001-Respect-LDFLAGS-set-from-OE-build.patch | 105 +++++++++++++++++++++ 2 files changed, 106 insertions(+) create mode 100644 meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch diff --git a/meta-optee/recipes-security/optee/optee-client.bb b/meta-optee/recipes-security/optee/optee-client.bb index 7b471f3..4c5ac1a 100644 --- a/meta-optee/recipes-security/optee/optee-client.bb +++ b/meta-optee/recipes-security/optee/optee-client.bb @@ -9,6 +9,7 @@ PV = "2.4.0+git${SRCPV}" inherit pythonnative systemd SRC_URI = "git://github.com/OP-TEE/optee_client.git \ + file://0001-Respect-LDFLAGS-set-from-OE-build.patch \ file://tee-supplicant.service" S = "${WORKDIR}/git" diff --git a/meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch b/meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch new file mode 100644 index 0000000..4d25b76 --- /dev/null +++ b/meta-optee/recipes-security/optee/optee-client/0001-Respect-LDFLAGS-set-from-OE-build.patch @@ -0,0 +1,105 @@ +From 73cb675c16bd63ee0e760a4067ffda4b050d19fa Mon Sep 17 00:00:00 2001 +From: Martin Jansa <Martin.Jansa(a)gmail.com> +Date: Thu, 15 Jun 2017 17:20:35 -0700 +Subject: [PATCH] Respect LDFLAGS set from OE build + +* Unify LFLAGS/LDFLAGS variable names (only tee-supplicant was using LDFLAGS). +* Fixes: + ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/bin/tee-supplicant' + No GNU_HASH in the elf binary: 'optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/packages-split/optee-client/usr/lib/libteec.so.1.0' [ldflags] + ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: QA run found fatal errors. Please consider fixing them. + ERROR: optee-client-2.4.0+gitAUTOINC+1df4046bd7-r0 do_package_qa: Function failed: do_package_qa + ERROR: Logfile of failure stored in: optee-client/2.4.0+gitAUTOINC+1df4046bd7-r0/temp/log.do_package_qa.31246 + +Upstream-Status: Pending +Signed-off-by: Martin Jansa <Martin.Jansa(a)gmail.com> + +--- + libsqlfs/Makefile | 2 +- + libsqlite3/Makefile | 2 +- + libteec/Makefile | 2 +- + tee-supplicant/Makefile | 10 +++++----- + 4 files changed, 8 insertions(+), 8 deletions(-) + +diff --git a/libsqlfs/Makefile b/libsqlfs/Makefile +index b53ccde..7a3bde6 100644 +--- a/libsqlfs/Makefile ++++ b/libsqlfs/Makefile +@@ -38,7 +38,7 @@ SQLFS_CFLAGS := $(addprefix -I, $(SQLFS_INCLUDES)) \ + $(filter-out $(SQLFS_CFLAGS_REMOVE),$(CFLAGS)) \ + -Wno-missing-format-attribute + +-SQLFS_LFLAGS := -lpthread ++SQLFS_LFLAGS := $(LDFLAGS) -lpthread + SQLFS_LIBS := $(OUT_DIR)/../libsqlite3/libsqlite3.a + SQLFS_LIBRARY := $(OUT_DIR)/$(LIB_MAJ_MIN) + +diff --git a/libsqlite3/Makefile b/libsqlite3/Makefile +index a69aabd..6a6d833 100644 +--- a/libsqlite3/Makefile ++++ b/libsqlite3/Makefile +@@ -19,7 +19,7 @@ SQLITE3_CFLAGS_REMOVE := -Wall -Wbad-function-cast -Wswitch-default \ + -Wfloat-equal -Werror -Wwrite-strings -Wcast-align + SQLITE3_CFLAGS := $(addprefix -I, $(SQLITE3_INCLUDES)) \ + $(filter-out $(SQLITE3_CFLAGS_REMOVE),$(CFLAGS)) +-SQLITE3_LFLAGS := ++SQLITE3_LFLAGS := $(LDFLAGS) + SQLITE3_LIBRARY := $(OUT_DIR)/$(LIB_NAME) + + libsqlite3: $(SQLITE3_LIBRARY) +diff --git a/libteec/Makefile b/libteec/Makefile +index 66055a7..d3eb2a1 100644 +--- a/libteec/Makefile ++++ b/libteec/Makefile +@@ -29,7 +29,7 @@ TEEC_CFLAGS := $(addprefix -I, $(TEEC_INCLUDES)) $(CFLAGS) -D_GNU_SOURCE \ + -DDEBUGLEVEL_$(CFG_TEE_CLIENT_LOG_LEVEL) \ + -DBINARY_PREFIX=\"TEEC\" + +-TEEC_LFLAGS := -lpthread ++TEEC_LFLAGS := $(LDFLAGS) -lpthread + TEEC_LIBRARY := $(OUT_DIR)/$(LIB_MAJ_MIN) + + libteec: $(TEEC_LIBRARY) +diff --git a/tee-supplicant/Makefile b/tee-supplicant/Makefile +index 204273f..40df763 100644 +--- a/tee-supplicant/Makefile ++++ b/tee-supplicant/Makefile +@@ -57,7 +57,7 @@ ifeq ($(CFG_TA_TEST_PATH),y) + TEES_CFLAGS += -DCFG_TA_TEST_PATH=1 + endif + TEES_FILE := $(OUT_DIR)/$(PACKAGE_NAME) +-TEES_LDFLAGS := -L$(OUT_DIR)/../libteec -lteec ++TEES_LFLAGS := $(LDFLAGS) -L$(OUT_DIR)/../libteec -lteec + + ifeq ($(CFG_SQL_FS),y) + TEES_CFLAGS += -DCFG_SQL_FS +@@ -67,22 +67,22 @@ TEES_CFLAGS_sql_fs.c := -Wno-strict-prototypes \ + # Note: explicitly requesting a shared library (.so) here, because statically + # linking a LGPL library has licensing implications. Make sure you review + # and comply with libsqlfs/COPYING section 6 before doing so. +-TEES_LDFLAGS += -L$(OUT_DIR)/../libsqlfs -l:libsqlfs.so -ldl ++TEES_LFLAGS += -L$(OUT_DIR)/../libsqlfs -l:libsqlfs.so -ldl + endif + + ifeq ($(CFG_TA_GPROF_SUPPORT),y) + TEES_CFLAGS += -DCFG_TA_GPROF_SUPPORT + endif + +-TEES_LDFLAGS += -lpthread ++TEES_LFLAGS += -lpthread + # Needed to get clock_gettime() for for glibc versions before 2.17 +-TEES_LDFLAGS += -lrt ++TEES_LFLAGS += -lrt + + tee-supplicant: $(TEES_FILE) + + $(TEES_FILE): $(TEES_OBJS) + @echo " LINK $@" +- $(VPREFIX)$(CC) -o $@ $+ $(TEES_LDFLAGS) ++ $(VPREFIX)$(CC) -o $@ $+ $(TEES_LFLAGS) + @echo "" + + $(TEES_OBJ_DIR)/%.o: $(TEES_SRC_DIR)/%.c +-- +1.9.1 + -- 2.13.1

9 years

external-linaro-toolchain issues in master

by Denys Dmytriyenko

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

9 years, 1 month

[PATCH] binutils: update binutils-cross specific patch to follow oe-core

by Denys Dmytriyenko

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

9 years, 1 month

possible inconsistency in dragonboard HW user manual

by Robert P. J. Day

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

9 years, 1 month

creating a bootable image for DB410C? (and other 96boards?)

by Robert P. J. Day

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

9 years, 2 months

couple questions about installing latest debian image on DB410C

by Robert P. J. Day

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

9 years, 2 months

← Newer
1
...
59
60
61
62
63
64
65
66
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

OpenEmbedded