Greetings from California:

I am a poor sinner trying to build u-boot from source on Max OSX. Forgive me.

I have a custom MIPS board with a u-boot from a 3rd-party vendor and we'd like 
to replace it. The board is MIPS-based and runs OpenWRT/LEDE.

So...I grabbed the u-boot git repo, stuck it on a case-sensitive filesystem, 
set up environment variables to allow the OpwenWRT MIPS cross compiler to work, 
wrote a "hello world" program in the u-boot root directory and cross compiled 
in on the command line without problem, and then turned my attention to u-boot.

Thought it would be good to see if I could get something running in QEMU first, 

Did this:

  make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- distclean
  make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux- 
  make  -j1 V=1 ARCH=mips CROSS_COMPILE=mipsel-openwrt-linux-

The first target it tries to build is "tools" using the HOSTCC (x86 LLVM from 
xcode, masquerading as gcc). It gets as far as AIS Image then poops out because 
it tries to use the MIPS version of byteorder.h, even though it compiling with 

  ./arch/mips/include/asm/byteorder.h:70:4: error: "MIPS, but neither 
__MIPSEB__, nor __MIPSEL__???"
  #  error "MIPS, but neither __MIPSEB__, nor __MIPSEL__???"

Is the system expecting a native/host byteorder.h to be present when using 
HOSTCC that is to be discovered before the compiler drops into arch/mips? If 
so, how does that work? Or is this a corner-case bug?

If I set CROSS_BUILD_TOOLS=1, obviously this problem goes away.

OR, if I use defconfig (sandbox) to get everything all x86-ish and compile with 

  make -j1 V=1 tools

...then it compiles the tools just fine (well, it can't find openssl headers, 
and doesn't seem to pay attention to KCFLAGS= when I try to tell it where they 
are, but that's a different problem).

Anyway, before I start hacking make files and what-not, thought I'd check in 
and see if the gurus had any thoughts ?


-- Ward

U-Boot mailing list

Reply via email to