u-boot stable repository/branch - which one is recommended for which boards?

Recent posts here led me to believe that it is important to have u-boot
properly configuring the board in order for DSS support in Linux (via
omapfb) to function with the S-Video port. So I've been trying to
verify that I am building the same u-boot as the C4/Bx validation
images. That u-boot (and kernel) bring up the color bars on the TV
connected to S-Video on my BeagleBoard.

But I've had no luck finding a matching u-boot source. My trials are
documented on the BeagleBox issue tracker:

In summary:

Tonight I tried a variety of branches from both the gitorious and
denx.de repositories. A few booted back to the console login but none
provided any better DSS support. Results are in the issue tracker.

It appears that gitorious.org has two repositories related to the


Both have an omap3-dev-usb branch, with a last commit ID of
3f6a11d8a37f11bef4611345b3d3fe38cc086a17. The branch and commit are
referenced by the validation images for C4/Bx
however the validation images only mention gitorious.org/beagleboard.
Both appear to be the same repository, however, since the log for the
branch/commit ID is the same. Neither build successfully. I did:

git clone git://gitorious.org/beagleboard-validation/u-boot.git gitdir
cd gitdir
git checkout 3f6a11d8a37f11bef4611345b3d3fe38cc086a17

(Substitute beagleboard/mainline.git for
beagleboard-validation/u-boot.git as well.)

And cross compiled with a Crosstools-NG based cross toolchain. The
errors are:
arm-unknown-linux-uclibcgnueabi-gcc -g -Os -fno-strict-aliasing
-fno-common -ffixed-r8 -msoft-float -fno-strict-aliasing -fno-common
-ffixed-r8 -msoft-float -D__KERNEL__ -DTEXT_BASE=0x80e80000
-I/home/mjhammel/src/ximba/bb/bld/uboot-git/include -fno-builtin
-ffreestanding -nostdinc
-isystem /home/mjhammel/src/ximba/bb/bld/crosstool-ng-1.8.2.bld/install/bin/../lib/gcc/arm-unknown-linux-uclibcgnueabi/4.4.3/include -pipe -DCONFIG_ARM -D__ARM__ -march=armv5 -mno-thumb-interwork -march=armv5 -mno-thumb-interwork -Wall -Wstrict-prototypes -fno-stack-protector -c -o board.o board.c
board.c:126: error: inline function 'coloured_LED_init' cannot be
declared weak
board.c:128: error: inline function 'red_LED_on' cannot be declared weak
board.c:130: error: inline function 'red_LED_off' cannot be declared
board.c:132: error: inline function 'green_LED_on' cannot be declared
board.c:134: error: inline function 'green_LED_off' cannot be declared
board.c:136: error: inline function 'yellow_LED_on' cannot be declared
board.c:138: error: inline function 'yellow_LED_off' cannot be declared

The denx.de repository is used by both the Free Electrons guide to
bringing up the BeagleBoard and the current Angstrom build
(recipes/u-boot/u-boot-git.bb). There is also the sakoman.net repository
referenced by u-boot-omap3beagleboard_1.1.4.bb and u-boot-omap3_git.bb
in Angstrom. I didn't try those.

So which repository and which branch/commit ID are recommended for each
board rev? At least from the point of view of reproducing the
validation images.

BTW, depending on which bootloader (that actually built and booted) you
trust, I either have an Ax/Bx or a C4 board. I got it in September from
Sparkfun. The box it came in says C4.

Found a fix to get this to compile. See

I'm using gcc 4.4.3 which doesn't like the mixture of "inline" with
"weak". The attached patch against the validation branch fixes the
build with 4.4.3. I'm not near the board so can't test if the binary
boots correctly or not.

I would suspect that the validation images are built with a gcc 4.2.x
release based on this issue so I might have to switch to that compiler
in Crosstool-NG.

0001-arm-gcc4.4.patch (2.17 KB)

The binary booted and the color bars are displayed immediately upon
u-boot launching. That's a step forward. Looks like my u-boot build is
at least compatible with the validation image now.

But the kernel still doesn't see any omapfb displays. So I have some
more work to do in the kernel config. Now I'm merging the kernel's
validation-20100805 branch omap3_beagle_defconfig configuration with
mine. Let's see where that takes me.