Building U-Boot not supported out-of-the-box on 11.0-CURRENT

[jbirch]

Naively sucking down ftp://ftp.denx.de/pub/u-boot/u-boot-2013.04.tar.bz2 and attempting to run a BeagleBone build fails on a fresh[1] install of 11.0-CURRENT (r256489).

The build fails on building U-boot, and _.uboot.build.log is littered with "gcc: not found". This makes sense, as gcc isn't around anymore -- but I've seen discussions on freebsd-arm@ that discuss how it's perfectly possible to build U-boot with Clang. The last few lines, retyped-by-hand-so-take-exactness-with-a-grain-of-salt, are...

gmake -C tools all
gcc: not found
gmake[1]: Entering directory `/root/crochet-freebsd/u-boot-2013.04/tools'
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -include /root/crochet-freebsd/u-boot-2013.04/include/libfdt_env.h -idirafter /root/crochet-freebsd/u-boot-2013.04/include -idirafter /root/crochet-freebsd/u-boot-2013.04/include2 -idirafter /root/crochet-freebsd/u-boot-2013.04/include -I /root/crochet-freebsd/u-boot-2013.04/lib/libfdt -I /root/crochet-freebsd/u-boot-2013.04/tools -DCONFIG_SYS_TEXT_BASE=0x80800000 -DUSEHOSTCC -D__KERNEL_STRICT_NAMES -pedantic  -o gen_eth_addr.o gen_ath_addr.c -c
gcc: not found
gmake [1]: *** [gen_eth_addre.0] Error 127
gmake [1]: Leaving directory `/root/crochet-freebsd/u-boot-2013.04/tools'
gmake : *** [tools] Error 2

[1] Well, fresh + gsed + gmake + git.

[jbirch]

I was not able to install gcc via `pkg install' because of a checksum issue on gmp.

I will attempt to install sysutils/u-boot-beaglebone-eabi from the ports tree (which pulls in gcc down the line), but this will require growing my virtual disk and cleaning up some old world builds for amd64 as gcc is massive.

[jbirch]

As expected, with gcc around everything builds fine and U-boot is totally functional on the resultant image.

If Clang can build U-boot (can it?) is there a way we can take gcc out of the equation bu surreptitiously sliding Clang in underneath it?

[kientzle]

On Nov 3, 2013, at 5:34 AM, jbirch notifications@github.com wrote:

As expected, with gcc around everything builds fine and U-boot is totally functional on the resultant image.

If Clang can build U-boot (can it?) is there a way we can take gcc out of the equation bu surreptitiously sliding Clang in underneath it?

It has been a while since I tried building U-Boot with clang.
If I remember correctly, U-Boot relies on some GCC options
for controlling register usage that clang did not support at that
time. I don’t know if that has changed.

That’s why the u-boot-beaglebone-eabi port relies on a GCC
cross-compiler port.

Tim

[jbirch]

Makes sense -- I recall reading about the same funky business with U-Boot. I've noticed some movement (starting at http://lists.denx.de/pipermail/u-boot/2013-August/160605.html) about removing this funky register business -- when this is done, do you envision U-boot compilation transitioning to Clang, or is Crochet focusing on the path of "use the board-specific port to compile U-boot if necessary"?

[kientzle]

On Nov 3, 2013, at 2:59 PM, jbirch notifications@github.com wrote:

Makes sense -- I recall reading about the same funky business with U-Boot. I've noticed some movement (starting at http://lists.denx.de/pipermail/u-boot/2013-August/160605.html) about removing this funky register business -- when this is done, do you envision U-boot compilation transitioning to Clang, or is Crochet focusing on the path of "use the board-specific port to compile U-boot if necessary”?

I would like for “mature" board definitions in Crochet
to use ports to obtain boot bits. That’s what I’m trying
to work out with the u-boot-beaglebone-eabi port.
But there are still some issues with that approach
and I’ve not had time to diagnose and fix them.

I expect there will always be some Crochet board
definitions that build boot loaders directly and others
that include binary boot blobs.

Tim

[ocochard]

On a 10.0 with the gcc-4.6.4 installed, I've got the same error message for building u-boot-rpi:
gmake[1]: gcc: Command not found
I've fixed my problem with creating a symlink:
ln -s /usr/local/bin/gcc46 /usr/local/bin/gcc

[teverett]

I've submitted patch #30 with a change to uboot.sh to check for gcc

[kientzle]

On Nov 17, 2013, at 9:49 AM, Olivier Cochard-Labbé notifications@github.com wrote:

On a 10.0 with the gcc-4.6.4 installed, I've got the same error message for building u-boot-rpi:
gmake[1]: gcc: Command not found
I've fixed my problem with creating a symlink:
ln -s /usr/local/bin/gcc46 /usr/local/bin/gcc

U-Boot doesn't actually require gcc for the parts that run on the build host.

But they mis-spell 'cc' as 'gcc'.

A better fix is to add HOSTCC=cc to the U-Boot build commands so it will use 'cc' for the parts that are build for the build host.

It does require a version of GCC for the cross-compiler.

Tim

[lattera]

Looks like I'm having this issue now. This ugly patch I'm working on gets us one step closer to building U-Boot on 11-CURRENT for Raspberry Pi: http://ix.io/brp. Maybe we need some sort of smart detection of which compiler to use.

[kientzle]

I believe HOSTCC=gcc in your patch is not necessary. HOSTCC sets the compiler used for the host tools that run on the host machine. Those parts do not require gcc.

But the U-Boot loader itself may still require GCC (clang has recently added some of the specific GCC options that U-Boot was using, but I don't know if anyone has done serious testing to see if it really works).

Some discussion on the freebsd-arm mailing list pointed out that to build GCC-based XDEV tools, you now need to use this command:

sudo make -C /usr/src XDEV=arm XDEV_ARCH=armv6 WITH_GCC=1 xddv

Please try rebuilding the xdev tools using this command and let us know.

[lattera]

Getting closer. I also had to specify WITHOUT_CLANG_IS_CC=1 when building xdev. U-Boot is getting closer to compiling. I'm getting a different set of errors. The log is pasted here: http://ix.io/bE4

[pauldokas]

It's not a fix, but kicking off another build right after the first one fails results in a successful build of u-boot. Here's the relevant portion of the u-boot build.log from the second build:

....
gmake[2]: Entering directory /usr/home/dokas/src/crochet-freebsd/u-boot-rpi/tools/kernel-doc' cc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -pedantic -o docproc docproc.c docproc.c:182:58: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void adddep2(char * file, char * line) { line = line; adddep(file); } ~~~~ ^ ~~~~ docproc.c:183:46: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void noaction(char * line) { line = line; } ~~~~ ^ ~~~~ docproc.c:184:58: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void noaction2(char * file, char * line) { file = file; line = line; } ~~~~ ^ ~~~~ docproc.c:184:71: warning: explicitly assigning a variable of type 'char *' to itself [-Wself-assign] static void noaction2(char * file, char * line) { file = file; line = line; } ~~~~ ^ ~~~~ 4 warnings generated. strip docproc gmake[2]: Leaving directory/usr/home/dokas/src/crochet-freebsd/u-boot-rpi/tools/kernel-doc'
......

The first build failed when it could not find gcc. It appears that HOSTCC is cc for the second build but gcc for the first.

[lattera]

Tried it again. It doesn't work for me.

[kientzle]

On Apr 12, 2014, at 8:33 AM, Shawn Webb notifications@github.com wrote:

Getting closer. I also had to specify WITHOUT_CLANG_IS_CC=1 when building xdev. U-Boot is getting closer to compiling. I'm getting a different set of errors. The log is pasted here: http://ix.io/bE4

I reproduced this over the weekend. (Dug an old laptop out
of the closet, installed FreeBSD-CURRENT, redid everything
from scratch.)

Haven't made much progress on a fix yet, but I'll keep digging...

Tim

[smithwinston]

FWIW: I have been able to build u-boot both 2013.04 and master with Clang against 11-CURRENT. However, as of yesterday, master started to fail with the following error. Reverting to 2014.04 (I need Patrick Kelsey's patches) seems to resolve the issue.

I've been building for the BBB using Patrick's BBB-multi-install-config.sh script.

u-boot-master build errors as of today 4/18/2014. Looks like it's picking up the wrong sha256.h header file (/usr/include/sha256.h vs uboot-master/include/sha256.h).

  CHK     include/config/uboot.release
  CHK     include/generated/version_autogenerated.h
  CHK     include/generated/timestamp_autogenerated.h
  UPD     include/generated/timestamp_autogenerated.h
  HOSTCC  tools/dumpimage.o
  HOSTCC  tools/image-fit.o
In file included from tools/image-fit.c:1:
/usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:887:3:
warning: implicit declaration of function 'sha256_csum_wd' is invalid
in C99 [-Wimplicit-function-declaration]
                sha256_csum_wd((unsigned char *)data, data_len,
                ^
/usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:888:35:
error: use of undeclared identifier 'CHUNKSZ_SHA256'
                               (unsigned char *)value, CHUNKSZ_SHA256);
                                                       ^
/usr/home/winston/Work/crochet-freebsd/u-boot-master/tools/../common/image-fit.c:889:16:
error: use of undeclared identifier 'SHA256_SUM_LEN'
                *value_len = SHA256_SUM_LEN;
                             ^
1 warning and 2 errors generated.
gmake[1]: *** [tools/image-fit.o] Error 1
gmake: *** [tools] Error 2