applications, ideas, technology, solutions

Modifying and rebuilding u-boot

I highly recommend starting with a fresh OE/Angstrom install following these directions.

NOTE: This process is not as easy as it should be because the default ‘local.conf’ includes the line:

 INHERIT += " rm_work "

which removes the source after everything has been compiled and deployed–this leads to a lot of confusion when reading posts that say the source can be found in ‘tmp/work…’ or ‘angstrom-dev/work…’.  Having previously built images will also populate your folders with a lot of stuff that is extraneous, and that’s why I recommend a fresh install.

Also, I did port over my local overlay as described here, adding ‘${OETREE}/local/recipes/*/*.bb’ to the BBFILES assigment in the ‘local.conf’ file.  I did this to include my app, not to update u-boot.  I did this before invoking any bitbake commands in the links mentioned above.

I then performed a bitbake of my own image, from my local overlay (which builds on console-image) with:

$ bitbake cmma-ptrp-image

(This could have just as easily been:

$ bitbake console-image

for a default install without a local overlay.)

This ran for a few hours and completed successfully.  Since I was then unable to find the u-boot source code  under ‘${OTREE}/angstrom-dev/work…’ (I suspect due to the default use of the rm_work task) I ran the following:

$ source ${OETREE}/source-me.txt
$ bitbake -f -c clean -b ../recipes/u-boot/
$ bitbake -f -c compile -b ../recipes/u-boot/

which forces a recompile of u-boot, leaving the source in place.  I then found the source in:


After applying my pin mux modifications in board/omap3/beagle/beagle.c (see the bottom of this post) I ran the following:

$ bitbake -f -c compile -b ../recipes/u-boot/
$ bitbake -f -c deploy -b ../recipes/u-boot/

I was then able to copy ‘u-boot-beagleboard.bin’ in ‘${OETREE}/angstrom-dev/deploy/glibc/images/beagleboard’ to my SD card.

After rebooting the beagleboard and logging in, the command:

$ cat /etc/services > /dev/ttyS0

results in a wiggly line on the scope connected to pin 15 of J5 on the beagleboard, the UART1_TX line.

1 Comment

  1. fabio's Gravatar fabio
    March 8, 2010    

    Thanks for the clear answer and useful suggestion.
    I’m not pretty sure calling twice compile does any good.
    I tested on my rev c2 Beagleboard, I only add mux definitions in #define MUX_BEAGLE_C() \ that is called at the very end of beagle.c and I see that even introducing modifications in beagle.h , bitbake complains there is nothing to do.

    So I tested

    bitbake -c clean
    bitbake -c configure u-boot_git.bin

    modify the beagle.h

    bitbake -c compile u-boot_git.bin
    bitbake -c deploy u-boot_git.bin

    now in your
    you should have a working u-boot. Now UART1, I2C2 (with external pullup), I2C3 (without pullup) and GPIO work.

    I’m trying hard on the other hand to have my spi4 working and LCD too..,

No Pings Yet

  1. Enabling UART1 on Rev C2 BeagleBoard « wh1t3’s on May 27, 2009 at 2:50 pm

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>