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%3Ba=blob%3Bf=board/qualcomm/dragonboard410c...
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
hi Robert,
On Fri, May 19, 2017 at 5:20 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
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:
they really are the same layer. the one on YP git is a mirror. So you can use one or the other, without any constraint. I just mentioned github in my other email so that you know where to send patches if needed.
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
nice.. i never tried building uboot from OE for DB410c!
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%3Ba=blob%3Bf=board/qualcomm/dragonboard410c...
can anyone verify that that is still the correct set of instructions?
yes, the instructions are still correct. basically what we are doing is a 'chained' bootloader. u-boot is loaded by the LK bootloader, and it is not a full replacement for the QCOM bootloader. So we create a 'boot' image that can be loaded and started by LK.
You have mkbootimg and dtbTool recipes in meta-qcom, i would happily take u-boot .bbappend patch that implement the instructions from the readme and build a 'working' u-boot image file.
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?
yes, correct, you don't *need* serial console.. however if anything goes wrong you will really need serial console.. My recommendation is to plan for it.. In fact I recommend the 96boards serial adaptor: http://www.96boards.org/product/uarts/.
is there a way to install the u-boot binary on the SD card and boot directly from there?
yes, it's possible to boot from SD, instructions to create a bootable SD card (on DB410c) are available here:
https://github.com/96boards/documentation/blob/master/ConsumerEdition/Dragon...
of course I would happily take patches in meta-qcom to facilitate the creation of bootable SD cards.. ;)
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
OpenEmbedded mailing list OpenEmbedded@lists.linaro.org https://lists.linaro.org/mailman/listinfo/openembedded
On Fri, 19 May 2017, Nicolas Dechesne wrote:
hi Robert,
On Fri, May 19, 2017 at 5:20 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
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
nice.. i never tried building uboot from OE for DB410c!
i have not verified the proper operation of this u-boot image yet, but since u-boot allegedly has support for the DB410C, it seemed reasonable to just ask my current poky layer to build it for me, and it did, no complaints ... if someone else wants to try it and see if the generated image is valid, let me know. otherwise, i'll be trying it soon enough.
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%3Ba=blob%3Bf=board/qualcomm/dragonboard410c...
can anyone verify that that is still the correct set of instructions?
yes, the instructions are still correct. basically what we are doing is a 'chained' bootloader. u-boot is loaded by the LK bootloader, and it is not a full replacement for the QCOM bootloader. So we create a 'boot' image that can be loaded and started by LK.
still getting used to the terminology, i assume "LK" stands for "Little Kernel." whatever that is.
You have mkbootimg and dtbTool recipes in meta-qcom, i would happily take u-boot .bbappend patch that implement the instructions from the readme and build a 'working' u-boot image file.
i was literally *just* about to ask about this ... i see in my poky-based build for the DB410C that the native sysroot already has the following:
./sysroots-components/x86_64/skales-native/usr/bin/dtbTool ./sysroots-components/x86_64/skales-native/usr/bin/mkbootimg
which suggests i could ignore all that "git clone skales" stuff and just extend the u-boot recipe to finish things off, yes?
more later...
rday
p.s. technically, you don't have mkbootimg and dtbTool "recipes" in meta-qcom, you have the "skales" recipe which produces them. yes, i am that pedantic.
p.p.s. interestingly, the meta-oe layer has a recipes-devtools/android-tools/ directory, but that appears to be unnecessary as long as the skales recipe provides what's necessary.
On Fri, May 19, 2017 at 8:39 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
On Fri, 19 May 2017, Nicolas Dechesne wrote:
hi Robert,
On Fri, May 19, 2017 at 5:20 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
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
nice.. i never tried building uboot from OE for DB410c!
i have not verified the proper operation of this u-boot image yet, but since u-boot allegedly has support for the DB410C, it seemed reasonable to just ask my current poky layer to build it for me, and it did, no complaints ... if someone else wants to try it and see if the generated image is valid, let me know. otherwise, i'll be trying it soon enough.
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%3Ba=blob%3Bf=board/qualcomm/dragonboard410c...
can anyone verify that that is still the correct set of instructions?
yes, the instructions are still correct. basically what we are doing is a 'chained' bootloader. u-boot is loaded by the LK bootloader, and it is not a full replacement for the QCOM bootloader. So we create a 'boot' image that can be loaded and started by LK.
still getting used to the terminology, i assume "LK" stands for "Little Kernel." whatever that is.
yes, right. this is the standard bootloader that Qualcomm uses (so far).
You have mkbootimg and dtbTool recipes in meta-qcom, i would happily take u-boot .bbappend patch that implement the instructions from the readme and build a 'working' u-boot image file.
i was literally *just* about to ask about this ... i see in my poky-based build for the DB410C that the native sysroot already has the following:
./sysroots-components/x86_64/skales-native/usr/bin/dtbTool ./sysroots-components/x86_64/skales-native/usr/bin/mkbootimg
which suggests i could ignore all that "git clone skales" stuff and just extend the u-boot recipe to finish things off, yes?
yes, this is what I meant. These tools are use in recipes-kernel/linux/linux-qcom-bootimg.inc to create the boot image with the kernel Image file. you would need something similar but with the uboot image instead.
more later...
rday
p.s. technically, you don't have mkbootimg and dtbTool "recipes" in meta-qcom, you have the "skales" recipe which produces them. yes, i am that pedantic.
yes ;-)
p.p.s. interestingly, the meta-oe layer has a recipes-devtools/android-tools/ directory, but that appears to be unnecessary as long as the skales recipe provides what's necessary.
the mkbootimg in the skales tools is (sadly) different from the 'upstream' mkbootimg from android-tools. so we can't really use it in our case. I have a patch (which i thought I had pushed, but I haven't yet) that changed the location of mkbootimg tools from $bindir to $bindir/skales to avoid file name conflicts with android-tools mkbootimg, it shouldn't be an issue for you, but i will push that soon anyways.
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
-
Nicolas Dechesne -
Robert P. J. Day