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