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