The Yocto Project is an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of the hardware architecture.
OpenBMC uses the Yocto tools to manage configuration and creation of BMC images.
There are two main use-cases for Yocto in OpenBMC:
- Building from master or existing tags
- Developing changes for submission to master
The first is the easy case, and largely involves picking the system
configuration to build before invoking bitbake. Examples for
Palmetto and
Zaius are in the
cheatsheet.
The second case can be helped with Yocto's devtool. After running
. openbmc-env, a tool called devtool will be in your path, and can be
applied in several ways.
If you have an existing source tree you'd like to integrate, running
devtool modify -n ${PACKAGE} ${SRCTREE} first creates a new Yocto layer in
your build directory where devtool stores recipe modifications. It then
constructs a .bbappend for the package recipe and uses the
externalsource class to replace the download, fetch, and patch steps with
no-ops. The result is that when you build the package, it will use the local
source directory as is. Keep in mind that the package recipe may not perform a
clean and depending on what you are doing, you may need to run ${PACKAGE}
build system's clean command in ${SRCTREE} to clear any built objects. Also
if you change the source, you may need to run
bitbake -c cleansstate ${PACKAGE} to clear BitBake's caches.
Alternatively, if you don't already have a local source tree but would still
like to modify the package, invoking devtool modify ${PACKAGE} will handle
the fetch, unpack and patch phases for you and drop a source tree into your
default workspace location.
When you are all done, run devtool reset ${PACKAGE} to remove the .bbappend
from the devtool Yocto layer.
Further information on devtool can be found in the Yocto Mega Manual.
There are a lot of examples of working with BitBake out there. The recipe example from OpenEmbedded is a great one and the premise of this OpenBMC tailored section.
So you wrote some code. You've been scp'ing the compiled binary on to the OpenBMC system for a while and you know there is a better way. Have it built as part of your flash image.
Run the devtool command to add your repo to the workspace. In my example I have a repo out on GitHub that contains my code.
devtool add welcome https://github.com/causten/hello.git
Now edit the bb file it created for you. You can just use vim but
devtool can also edit the recipe devtool edit-recipe welcome without
having to type the complete path.
Add/Modify these lines.
do_install () {
install -m 0755 -d ${D}${bindir} ${D}${datadir}/welcome
install -m 0644 ${S}/hello ${D}${bindir}
install -m 0644 ${S}/README.md ${D}${datadir}/welcome/
}
The install directives create directories and then copies the files into them.
Now BitBake will pick them up from the traditional /usr/bin and
/usr/shared/doc/hello/README.md.
The Final Step is to tell BitBake that you need the welcome recipe
vim conf/local.conf
IMAGE_INSTALL_append = " welcome"
That's it, recompile and boot your system, the binary hello will be in
/usr/bin and the README.md will be in /usr/shared/doc/welcome.
Sure you could flash and boot your system to see if your file made it, but there
is a faster way. The rootfs directory down in the depths of the build/tmp
path is the staging area where files are placed to be packaged.
In my example to check if README.md was going to be added just do...
ls build/tmp/work/${MACHINE}-openbmc-linux-gnueabi/obmc-phosphor-image/1.0-r0/rootfs/usr/share/welcome/README.md
NXP wrote a few examples of useful commands with BitBake that find the file too
bitbake -g obmc-phosphor-image && cat pn-depends.dot |grep welcome