How are the production BBB images built?


I’ve been getting familiar with the BBB, Angstrom, OpenEmbedded, Yocto etc, and while its all still pretty new I was able, using the Angstrom page,, to build the console images.

I was wondering if the steps to build the production BBB images were documented anywhere? I was hoping to use these steps to bridge the gap between the output of ‘bitbake console-image’ which appears to be some rootfs compressed files and .ubi images, to a .img file that I can write onto and boot off of a microsd card.


Yocto has some documentation on their site, and Derek Molloy ( from youtube ) has build steps on his blog as well. There is other scattered information on the web that I have found, but nothing that I have found that is usable. That is, I’ve tried using these instructions, but they’re either incomplete, or just flat out broken.

Either way, I’ve yet to get a working build, but after a week of calling no joy, I just decided to move to Debian since this is what I am mostly familiar with anyhow.

Oh, and right ! Crashcourse has a tutorial too that looked promising. But very little explanation from what I remember. Exact steps are fine for short term building, but personally I prefer understanding too . . . YMMV.

Ahh. I’ve considered Debian/Ubuntu as well but Angstrom/OpenEmbedded/Yocto seems a lot more suitable for embedded images where the size of the whole rootfs is critical.

I’m thinking Koen may reply with his list of commands or a script that he uses. I was surprised that it wasn’t on any of the circuitco bbb pages yet but maybe it can be in the future.


heh ... i have plenty of tutorials on my site, but you're right, i
don't explain how those shipping images are created since i don't
know. if someone figures it out, i'll be happy to add a page.

  i really need to reorganize all those pages one of these days ...


The img.* creating script is in the git repo:


@Robert P. J. Day

I meant no slight. I think its great you put information on the web. I maintain a blog myself mostly revolving around Robert C Nelsons builds( how to neboot etc), and know it is not easy to test, and write all this up.

I love it though, and think its a great way for me to contribute back.

Ahh that looks like good info.

Is there a script for putting the image onto the sd card to run directly? I can see that the might be able to be modified to do so but wasn’t sure if there was a script for creating those images, mentioned as “unofficial” on the wiki, ?


Anyone? Koen? I was wondering how the bootable sd images are created…


I’ve done a fair number of searches and a ton of reading. I haven’t seen anything on Yocto about creating BBB images, how to format/configure the microsd card etc. That stuff seems specific to the BBB (or the AM3xx series processors perhaps).


Anyone? Koen? I was wondering how the bootable sd images are created...

with the '' script in the same directory as the '' script.

Intuitively that makes sense because the sd card plugged into a PC appears the same way the emmc would on the BBB when booted off of the microsd with the emmc programming image. Right?


at the risk of flogging this a bit more, i'm going to flog this a
bit more. i have a genuine need to know precisely how the contents of
the shipping BBBs came to be.

  if i want to, say, teach an embedded linux or device driver course
off of BBBs, it's entirely possible that there won't be any access to
the serial port so students will have to make do with what they get
after the BBB boots and they can SSH into it.

  a basic exercise would be, of course, to write, compile and load a
simple module, for which the student would need the relevant part of
the kernel source to compile against, so i need to be able to point
said student at such a kernel source tree that matches exactly the
kernel running on the BBB.

  i don't need the mechanics of how the flasher works, i can see how
that works. i need the recipe for the underlying components that are
being flashed.

  i am assuming, of course, that the components were built with some
invocation of OE/yocto and the relevant layers and, on my BBB, i can
see the contents of /etc/dogtag:

  "Cloud9 GNOME Image 2013.06.20"

so i'm assuming the build would involve pulling in the
meta-beagleboard(?) layer, and doing a bitbake for that image, at
which point i could simply wander down into the "work" directory and
pull out the precise, fully-patched kernel source that was used for
the build. does that make sense? so all i really need is the OE
configuration that was used to build the components, right?


It's all in the SRM, but for people too lazy to read that:

  Read and follow the steps outlined there.

i am moderately familiar with the BBB SRM, and the word "angstrom"
appears nowhere in it.


Ah, it seems that section 9 of the BB SRM didn't make it into the BBB SRM. Either way, just follow the instructions on the angstrom site, there's no difference between BBW and BBB images.

gaaaaaah ... i am not interested in the general philosophy of how to
build angstrom, that's *not* the question on the table. the question
is, which *particular* configuration of angstrom is the one that
matches what is currently shipping on the BBB?

  i've spent some time setting up a nice, convenient OE build
environment on my dev host, where i have numerous layers i've checked
out, and tarballs i've stashed in a local mirror and so on, so it's
incredibly easy for me to do a build if i have the following

* the contents of the bblayers.conf file
* the MACHINE setting in local.conf
* the name of the image to "bitbake"

  that's it, that's all i need. so does that information exist that
will let me reproduce what's on a shipping BBB or doesn't it? it's a
simple question.


this is a truly pointless discussion.


The one I linked above. There is only one configuration of angstrom per release and the above matches the release that ships with the bones.


I followed those instructions and, although I had selected the yocto 2013 release, I ended up with the component files in the deploy/ directory but as rootfs and ubi files, not card images.

The information yesterday about the and other scripts has helped informationaly, I think I’ll be able to build a sd card image today using those steps, but at this point it seems like a multi step process after following the angstrom build steps.


actually, that's what i would have expected ... the primary purpose
of OE/yocto is to build the fundamental images or objects, not so much
to create the final bootable SD card image based on them, since some
people might not want an SD card, they might be, say, trying to
populate a TFTP or NFS server with those images.