OpenEmbedded

openembedded@lists.linaro.org

2 participants
140 discussions

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

8 years, 10 months

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

8 years, 11 months

[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

8 years, 11 months

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

8 years, 12 months

[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

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

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, 1 month

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, 1 month

building and booting into u-boot on the dragonboard 410c?

by Robert P. J. Day

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

9 years, 1 month

upcoming questions on building u-boot and OE for dragonboard 410c

by Robert P. J. Day

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

9 years, 1 month

← Newer
1
...
8
9
10
11
12
13
14
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

OpenEmbedded