Automating an SDK build

Discussion about Parallella (and Epiphany) Software Development

Moderators: amylaar, jeremybennett, simoncook

Re: Automating an SDK build

Postby snim2 » Tue Feb 10, 2015 12:41 pm

Hi Pete,

I have finally gotten round to having a got at this, and for me
Code: Select all
bitbake hdmi-image

fails with a compiler error. Is there a log file somewhere I can grep through? There didn't seem to be anything in tmp/ like that?

Thanks,

Sarah
snim2
 
Posts: 53
Joined: Mon Feb 03, 2014 5:02 pm

Re: Automating an SDK build

Postby peteasa » Tue Feb 10, 2015 9:42 pm

Sorry that you have had problems with the build.. Yocto is complex and this layer is new and complex so I am not surprised.

The first place to look for logs is in the output of bitbake. This will point you to a more detailed log file. I would say it is impossible to start from scratch and solve a problem from the log files so I will attempt to provide some tips below. The Log files are found in the work folders for each package for example tmp/work/armv7ahf-vfp-neon-poky-linux-gnueabi and tmp/work/x86_64-poky-linux-gnueabi and tmp/work/parallella_hdmi-poky-linux-gnueabi/hdmi-image. Building a compiler has multiple stages and in this case in the yocto environment I try to use as much of standard poky/meta/classes as possible so you will find work folders for epiphany-elf-gcc in the same place as gcc etc..

To fix the problem - first check that you have the latest release so navigate to the root folder of the project and type:
Code: Select all
git submodule foreach git pull
git pull

Now as this is the first time in this shell type
Code: Select all
prepareyoctobuild.sh

This will move you to the build_parallella folder and set BUILDDIR and PATH. At this point the easy thing to try is
Code: Select all
bitbake hdmi-image


Thats it.. no need to read further or try more things!

Hope that helps.. If you want to know more read on...

What will happen is that all the previous build products will be checked in the cache and then the updated builds will start. Yocto build is complex and I have had problems with build dependencies so with luck the second time you run bitbake hdmi-image the build will proceed without errors because in the first build the dependency was not completely built. The good thing about the cache is that previous build information is very rapidly used to populate the sysroots so the second time you run a build it hardly takes any time. The bad thing about the cache is that I hardly every build from scratch so I miss the dependency problems! Also because the builds happen in parallel its is possible to get different results each time. So dont press CTRL-C more than once to stop a build because you can leave the cache in a corrupt state and then end up with unexpected problems. I will say that again because it is important and everyone does it... Dont press CTRL-C more than once to stop a bitbake build because you can corrupt the cache and cause many hours of failing builds for unexplained reasons.

It is possible to bitbake each epiphany package in turn:
Code: Select all
bitbake virtual/epiphany-elf-binutils
bitbake virtual/epiphany-elf-gcc-initial
bitbake epiphany-elf-newlib
bitbake virtual/epiphany-elf-gcc
bitbake epiphany-elf-libgcc
bitbake epiphany-elf-gcc-runtime
bitbake epiphany-elf-libgloss
bitbake epiphany-elf-binutils
bitbake epiphany-elf-gcc
bitbake hdmi-image

The first four are configured with host=x86_64-linux, target=epiphany-elf and produce build products that are stored in tmp/sysroots/x86_64-linux. These are then used to compile the second set that are configured with host=epiphany-elf, target=epiphany-elf and the third set that are configured with host=arm-poky-linux-gnueabi, target=epiphany-elf. The build products of the second and third set of packages is output to tmp/sysroots/parallella-hdmi. The bitbake hdmi-image creates a sysroot in its TOPDIR that is quite close to what goes to the target at tmp/work/parallella_hdmi-poky-linux-gnueabi/hdmi-image/1.0-r1/rootfs.

You can do many jobs on one bitbake command so for example to clean the cache for these packages you can type
Code: Select all
bitbake -c cleansstate epiphany-elf-binutils virtual/epiphany-elf-binutils epiphany-elf-gcc virtual/epiphany-elf-gcc virtual/epiphany-elf-gcc-initial epiphany-elf-libgcc epiphany-elf-libgloss  epiphany-elf-newlib epiphany-elf-gcc-runtime hdmi-image

You will not clean the cache for all the other packages with this command so your next build will not need to rebuild everything, just the things you have cleaned. The build will create a log folder in ${TOPDIR}/temp with a log for every step taken. Look for run.do_compile to see what steps are taken in the compile stage and log.do_compile for the output. Use devshell to actually repeat the commands run in the stage as detailed in run.do?? on the command line in the same environment that the script has when bitbake is run. For example
Code: Select all
bitbake -c devshell epiphany-elf-libgloss
User avatar
peteasa
 
Posts: 117
Joined: Fri Nov 21, 2014 7:04 pm

Re: Automating an SDK build

Postby peteasa » Mon Aug 31, 2015 8:51 am

Just spotted this - https://www.yoctoproject.org/tools-reso ... ntegration

So it seems like it would be possible to get the yocto build working with continuous integration!
User avatar
peteasa
 
Posts: 117
Joined: Fri Nov 21, 2014 7:04 pm

Previous

Return to Programming Q & A

Who is online

Users browsing this forum: No registered users and 9 guests

cron