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

2018-03-02 Thread 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



signature.asc
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


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

2018-03-02 Thread 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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot