[U-Boot] Building for MIPS on OSX with OpenWRT toolchain

[U-Boot] Building for MIPS on OSX with OpenWRT toolchain

[Ward Willats]

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, so

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- qemu_mipsel_defconfig
  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 HOSTCC:

  ./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 ?

Thanks

-- Ward

[U-Boot] Building for MIPS on OSX with OpenWRT toolchain

[Daniel Schwierzeck]

Hi Ward,

On 02.03.2018 01:02, Ward Willats wrote:
> 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, so
> 
> 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- qemu_mipsel_defconfig
>   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 HOSTCC:
> 
>   ./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?

Looks like a corner-case bug with LLVM. I think on a Linux system with HOST GCC the header guard "#ifndef _ASM_BYTEORDER_H" prevents arch/mips/include/asm/byteorder.h from being pre-processed by the host compiler. Maybe with LLVM _ASM_BYTEORDER_H is never defined by not having another byteorder.h in the include chain.

> 
> 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 ?
> 
> Thanks
> 
> -- Ward
> 

-- 
- Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180302/bedb1e92/attachment.sig>