Troubleshooting notes

^{Home / parallella-yoctobuild / Troubleshooting notes}

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

Ensure that you have the correct build dependencies

Recently I did a build on a laptop and hit problems. After a quick search I found Yocto Project Quick Start and ran

$ sudo apt-get install gawk wget git-core diffstat unzip texinfo gcc-multilib build-essential chrpath socat libsdl1.2-dev xterm

Notice that this pulls in gcc-multilib. Anyway that fixed the build for me, I must have set my build machine up some time ago with all the correct dependencies so I did not see any problems till I tried on a different machine and being in a bit of a rush did not search out the latest quick start information and assumed all would be ok. Have a good look at the Yocto Project Quick Start and see if there is anything else that might help you.

Are you on the right branch?

The branch that I tend to use most, at the moment, is elink-redesign. Every now and then you will see from the git history that I update parallella-elink-redesign with changes from elink-redesign and very occasionally (only in parallella-yoctobuild), I update yoctobuild.

In theory parallella-elink-redesign will be identical to elink-redesign with the exception of the presence of absence of meta-example. In elink-redesign the folder parallella/parallella-yoctobuild/meta-example is excluded from updates by the .gitignore file. You can copy the contents of meta-example into any of the folders parallella/parallella-yoctobuild/meta-mywork, meta-project, meta-projects, meta-test that are also in the .gitignore file and then make your own overrides to modify the yocto build and still keep up to date with the changes that I provide. See the instructions in the README file in meta-example.

Update to latest

Try to update all the submodules to the latest. Navigate to the parallella-yoctobuild folder, make sure you are on the branch that you want, and type

git submodule init
git submodule update
git submodule foreach git fetch --all
git fetch --all
git pull

If you have made local changes then these commands may not all work so check the output and take appropriate action. The first command will initialize any new submodule that have been created since the last time you took a snapshot. The second command will update all submodule. The third command is just to make sure.. it will fetch all new branches. The final command will update the parallella-yoctobuild project and move the index of all submodule to the latest working version on yoctobuild branch. If you look at the output of all the commands you will get an idea about what has changed. The fetch commands will pull in all the changes so that you can start git gui in each submodule and get an idea about what has changed on other branches.

To be safe remove the build folder (and cache) and then run prepareyoctobuild.sh to re-create the build environment, then have another go with bitbake.

rm -rf build_parallella
source prepareyoctobuild.sh

Look at the output from the bitbake command

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

Things that can go wrong with the build

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.

When you run bitbake what will happen is that all the previous build products will be checked from 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. Just build again and the second time the dependancies my all get built and the build will get further.

The dependencies are not easy to fix in this case because I have to implement more recipes for the remaining parts for the Yocto SDK. This does not stop the build completing because all the necessary elements are being built, just the Yocto SDK expects more so when I add in the depends reference the SDK build complains that I have not completed the additional recipes.

Failsafe build

Try the following

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

Clean the cache for this layer

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

Then bitbake again