[U-Boot-Users] Re: MIPS LE build problems

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <4304D3FD.7080107@smiths-aerospace.com> you wrote:
>
> As noted in other email in this thread, executing the above code won't 
> work.  What about simply compiling a file containing:
> 
> constant int data = 0x01234567;
> 
> objdumping the data section, and looking (grepping) to see if the data 
> section has 0x12345678 or 0x78563412?

Doesn't work as objdump will be user friendly and  always  print  the
"correct" value, i. e. 0x01234567.

But the idea is good.

The attached test script works with the tool chains available to  me.
Can others please test this, too?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Many aligators will be slain, but the swamp will remain.

-------------- next part --------------
#!/bin/sh

set -e
# make sure CROSS_COMPILE is defined
[ "${CROSS_COMPILE}" ]

# create temp directory
TMPDIR=`mktemp -d`

# and make sure it gets removed automagically
trap 'rm -fr ${TMPDIR}' 0 1 2 3 15

>${TMPDIR}/foo.c
${CROSS_COMPILE}gcc -c ${TMPDIR}/foo.c -o ${TMPDIR}/foo.o
readelf -h ${TMPDIR}/foo.o | \
sed -n 's/.*Data:.* \([^ ][^ ]*\) endian/\1/p'

exit 0

[U-Boot-Users] Re: MIPS LE build problems

[Zachary Landau]

> The attached test script works with the tool chains available to  me.
> Can others please test this, too?

You may have already test this one, but it reports "big" with m68k-elf
version 2.95.3, as it should.

-- 
Zachary P. Landau <kapheine@gmail.com>

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <a04f56da0508181611e1c6270@mail.gmail.com> you wrote:
> 
> You may have already test this one, but it reports "big" with m68k-elf
> version 2.95.3, as it should.

Thanks a lot for the feedback, and no, I don't have a m68k  toolchain
here.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We don't care.  We don't have to.  We're the Phone Company."

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> The attached test script works with the tool chains available to  me.
> Can others please test this, too?

It WORKS wit my toolchain, built with crosstool.
It reports "little" which is correct.
Excellent job!

gcc  3.3.5
binutils 2.15
glibc 2.3.5

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Leif Lindholm]

On Thu, 2005-08-18 at 23:38 +0200, Wolfgang Denk wrote:
> Doesn't work as objdump will be user friendly and  always  print  the
> "correct" value, i. e. 0x01234567.
> 
> But the idea is good.
> 
> The attached test script works with the tool chains available to  me.
> Can others please test this, too?

This works for our (home grown) toolchain.

gcc 3.2.3, binutils 2.13, mipsel-linux

regards
	/
		Leif

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1124700839.6493.4.camel@localhost> you wrote:
>
> > The attached test script works with the tool chains available to  me.
> > Can others please test this, too?
> 
> This works for our (home grown) toolchain.

Thanks for the feedback.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"We all agree on the necessity of compromise. We just can't agree  on
when it's necessary to compromise."
                - Larry Wall in  <1991Nov13.194420.28091@netlabs.com>

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> The attached test script works with the tool chains available to  me.
> Can others please test this, too?

As I said it works for me.

Please see attached cpu/mips/config.mk if it is O.K.
to include it in the official U-Boot.
It works for me, maybe others can test it to.

BR,
Matej
-------------- next part --------------
#
# (C) Copyright 2003
# Wolfgang Denk, DENX Software Engineering, <wd@denx.de>
#
# See file CREDITS for list of people who contributed to this
# project.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License as
# published by the Free Software Foundation; either version 2 of
# the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
# MA 02111-1307 USA
#

v=$(shell \
$(CROSS_COMPILE)as --version|grep "GNU assembler"|awk '{print $$3}'|awk -F . '{print $$2}')
MIPSFLAGS=$(shell \
if [ "$v" -lt "14" ]; then \
	echo "-mcpu=4kc -mabicalls"; \
else \
	echo "-march=4kc -mtune=4kc -Wa,-allow_branch_to_undefined -mabicalls"; \
fi)

# Check the default ENDIANNESS of the cross compiler
e=$(shell \
TMPDIR=`mktemp -d`; \
trap 'rm -fr ${TMPDIR}' 0 1 2 3 15; \
>$${TMPDIR}/foo.c; \
${CROSS_COMPILE}gcc -c $${TMPDIR}/foo.c -o $${TMPDIR}/foo.o; \
readelf -h $${TMPDIR}/foo.o | \
sed -n 's/.*Data:.* \([^ ][^ ]*\) endian/\1/p'; \
)

PLATFORM_LDFLAGS += $(shell \
if [ "$e" = "little" ]; then \
	echo "-EL";\
else \
	echo "-EB";\
fi)

PLATFORM_CPPFLAGS += $(MIPSFLAGS)

[U-Boot-Users] MIPS LE build problems

[Wolfgang Denk]

Dear Thomas,

I always wondered what exactly was the reason why I was not  able  to
build  the dbau1x00 targets (especially the little endian dbau1550_el
target using the ELDK toolchain). Also, I always wondered  about  the
reference to a non-exitent cpu/mips/little/liblittle.a library.

Is ther ea special reason for the current settings of  build  options
for the dbau1x00 targets?

Attached below is a patch which makes all dbau1x00 targets build fine
with the current ELDK, and I believe these settings are more  correct
than the previous ones.

If you don't protest I would like to merge this patch into the public
source tree?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Remember, there's a big difference between kneeling down and  bending
over.                                                   - Frank Zappa

-------------- next part --------------
Fix dbau1xxx (= MIPS big and little endian) build options.
Incorrect gcc options (big endian -BE switch) were used for
dbau1550_el which is a little endian build; also get rid of reference
to non-existant cpu/mips/little/liblittle.a library

---
commit 2191923072413972d8dbf3e1b2f8ce6762a85800
tree 7466fe41f385b14b572d4765f5aaadaccd8a48d2
parent 700a0c648df72f2c8e0589c0d0470b5ffd7cab7b
author Wolfgang Denk <wd@pollux.denx.de> Mon, 08 Aug 2005 23:06:32 +0200
committer Wolfgang Denk <wd@pollux.denx.de> Mon, 08 Aug 2005 23:06:32 +0200

 Makefile           |    2 +-
 cpu/mips/config.mk |   12 ++++++++++--
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -1615,7 +1615,7 @@ dbau1550_config		:	unconfig
 dbau1550_el_config	:	unconfig
 	@ >include/config.h
 	@echo "#define CONFIG_DBAU1550 1" >>include/config.h
-	@./mkconfig -a dbau1x00 mips mips dbau1x00 "" little
+	@./mkconfig -a dbau1x00 mips mips dbau1x00
 
 #########################################################################
 ## MIPS64 5Kc
diff --git a/cpu/mips/config.mk b/cpu/mips/config.mk
--- a/cpu/mips/config.mk
+++ b/cpu/mips/config.mk
@@ -24,9 +24,17 @@ v=$(shell \
 mips-linux-as --version|grep "GNU assembler"|awk '{print $$3}'|awk -F . '{print $$2}')
 MIPSFLAGS=$(shell \
 if [ "$v" -lt "14" ]; then \
-	echo "-mcpu=4kc -EB -mabicalls"; \
+	echo "-mcpu=4kc"; \
 else \
-	echo "-march=4kc -mtune=4kc -Wa,-mips_allow_branch_to_undefined -EB -mabicalls"; \
+	echo "-march=4kc -mtune=4kc -Wa,-mips_allow_branch_to_undefined"; \
 fi)
 
+ifneq (,$(findstring 4KCle,$(CROSS_COMPILE)))
+ENDIANNESS = -EL
+else
+ENDIANNESS = -EB
+endif
+
+MIPSFLAGS += $(ENDIANNESS) -mabicalls
+
 PLATFORM_CPPFLAGS += $(MIPSFLAGS)

[U-Boot-Users] Re: MIPS LE build problems

[Thomas Lange]

I have no objections against patch.

/Thomas

Wolfgang Denk wrote:

>Dear Thomas,
>
>I always wondered what exactly was the reason why I was not  able  to
>build  the dbau1x00 targets (especially the little endian dbau1550_el
>target using the ELDK toolchain). Also, I always wondered  about  the
>reference to a non-exitent cpu/mips/little/liblittle.a library.
>
>Is ther ea special reason for the current settings of  build  options
>for the dbau1x00 targets?
>
>Attached below is a patch which makes all dbau1x00 targets build fine
>with the current ELDK, and I believe these settings are more  correct
>than the previous ones.
>
>If you don't protest I would like to merge this patch into the public
>source tree?
>
>Best regards,
>
>Wolfgang Denk
>  
>

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi Wolfgang

> >Attached below is a patch which makes all dbau1x00 targets build fine
> >with the current ELDK, and I believe these settings are more  correct
> >than the previous ones.

Can I see the patch also, please?
I am porting U-Boot on dbau1200 and would like to contribute it to the
public source tree. Currently it boots and it can download the kernel
over the ethernet. Will try with the PCMCIA and other hardware later.
Oh, and it is little endian. 

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Thomas Lange]

The patch was attached to Wolfgangs message.

/Thomas

Matej Kupljen wrote:

>Hi Wolfgang
>
>  
>
>>>Attached below is a patch which makes all dbau1x00 targets build fine
>>>with the current ELDK, and I believe these settings are more  correct
>>>than the previous ones.
>>>      
>>>
>
>Can I see the patch also, please?
>I am porting U-Boot on dbau1200 and would like to contribute it to the
>public source tree. Currently it boots and it can download the kernel
>over the ethernet. Will try with the PCMCIA and other hardware later.
>Oh, and it is little endian. 
>
>BR,
>Matej
>
>  
>

[U-Boot-Users] Re: MIPS LE build problems

[Thomas Lange]

It seems that Wolfgangs original message got lost somewhere.

I have attached the patch.

/Thomas

Matej Kupljen wrote:

>Hi Wolfgang
>
>  
>
>>>Attached below is a patch which makes all dbau1x00 targets build fine
>>>with the current ELDK, and I believe these settings are more  correct
>>>than the previous ones.
>>>      
>>>
>
>Can I see the patch also, please?
>I am porting U-Boot on dbau1200 and would like to contribute it to the
>public source tree. Currently it boots and it can download the kernel
>over the ethernet. Will try with the PCMCIA and other hardware later.
>Oh, and it is little endian. 
>
>BR,
>Matej
>
>  
>

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch
Url: http://lists.denx.de/pipermail/u-boot/attachments/20050810/7dc92556/attachment.txt 

[U-Boot-Users] Re: MIPS LE build problems

[Andrew Dyer]

On 8/9/05, Thomas Lange <thomas@corelatus.se> wrote:
> It seems that Wolfgangs original message got lost somewhere.
> 
> I have attached the patch.
> 
> /Thomas

I think the board linker scripts also need to be modified to
work with either big or little endian toolchains like below.  The third
argument to OUTPUT_FORMAT is only used for explicitly little endian
compilation.

--- /home/adyer/Projects/u-boot/board/dbau1x00/u-boot.lds      
2005-07-25 20:11:54.000000000 -0500
+++ u-boot.lds  2005-07-10 18:17:44.000000000 -0500
@@ -22,9 +22,9 @@
  */

 /*
-OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-bigmips")
+OUTPUT_FORMAT("elf32-bigmips", "elf32-bigmips", "elf32-littlemips")
 */
-OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradbigmips")
+OUTPUT_FORMAT("elf32-tradbigmips", "elf32-tradbigmips", "elf32-tradlittlemips")
 OUTPUT_ARCH(mips)
 ENTRY(_start)
 SECTIONS

The test that decides which endianess to build is not going to work for
toolchains other than Denx ones, lots of them have prefixes that don't
include 4KCle (they may not build u-boot very well, but that's another issue)

I would suggest doing it by config name and putting ENDIANNESS in
config.mk something like so (untested):

dbau1550_config \
dbau1550_el_config	:	unconfig
	@ >include/config.h
	@[ -z "$(findstring _el,$@)" ] || \
		{ echo "ENDIANNESS = little" >>include/config.mk ; \
		  echo "little endian" ; \
		}
	@echo "#define CONFIG_DBAU1550 1" >>include/config.h
	@./mkconfig -a dbau1x00 mips mips dbau1x00

and test for endianness in cpu/mips/config.mk and do the right thing.


-- 
Hardware, n.:
        The parts of a computer system that can be kicked.

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> I think the board linker scripts also need to be modified to
> work with either big or little endian toolchains like below.  The third
> argument to OUTPUT_FORMAT is only used for explicitly little endian
> compilation.

Correct. I'll try it.

> The test that decides which endianess to build is not going to work for
> toolchains other than Denx ones, lots of them have prefixes that don't
> include 4KCle (they may not build u-boot very well, but that's another issue)

I agree.

> I would suggest doing it by config name and putting ENDIANNESS in
> config.mk something like so (untested):
> 
> dbau1550_config \
> dbau1550_el_config	:	unconfig
> 	@ >include/config.h
> 	@[ -z "$(findstring _el,$@)" ] || \
> 		{ echo "ENDIANNESS = little" >>include/config.mk ; \
> 		  echo "little endian" ; \
> 		}
> 	@echo "#define CONFIG_DBAU1550 1" >>include/config.h
> 	@./mkconfig -a dbau1x00 mips mips dbau1x00
> 
> and test for endianness in cpu/mips/config.mk and do the right thing.

I'll test it.

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <c166aa9f0508091623642cef58@mail.gmail.com> you wrote:
>
> I think the board linker scripts also need to be modified to
> work with either big or little endian toolchains like below.  The third
> argument to OUTPUT_FORMAT is only used for explicitly little endian
> compilation.

Thanks for pointing out. I was only able to compile the code, not  to
actually run it.

> The test that decides which endianess to build is not going to work for
> toolchains other than Denx ones, lots of them have prefixes that don't
> include 4KCle (they may not build u-boot very well, but that's another issue)

I am aware of this problem. This is one of the reasons why I  started
this discussion - I need input from users of other tool chains here.

> I would suggest doing it by config name and putting ENDIANNESS in
> config.mk something like so (untested):

I disagree. This is IMHO not a good idea.  I  think  the  tool  chain
should  "know" which endian mode it is. I don;t ike the ide to encode
this in a build target name:

> dbau1550_config \
> dbau1550_el_config	:	unconfig

Why do we need two build targets at all? I think there should be just
one "dbau1550" target, and your setting of  CROSS_COMPILE  determines
if this is a little or a big endian build.

Comments?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A verbal contract isn't worth the paper it's written on.
                                                    -- Samuel Goldwyn

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> > I think the board linker scripts also need to be modified to
> > work with either big or little endian toolchains like below.  The third
> > argument to OUTPUT_FORMAT is only used for explicitly little endian
> > compilation.
> 
> Thanks for pointing out. I was only able to compile the code, not  to
> actually run it.

I am running little endian on DBAU1200.

> > I would suggest doing it by config name and putting ENDIANNESS in
> > config.mk something like so (untested):
> 
> I disagree. This is IMHO not a good idea.  I  think  the  tool  chain
> should  "know" which endian mode it is. I don;t ike the ide to encode
> this in a build target name:

How can we determine that?

> > dbau1550_config \
> > dbau1550_el_config	:	unconfig
> 
> Why do we need two build targets at all? I think there should be just
> one "dbau1550" target, and your setting of  CROSS_COMPILE  determines
> if this is a little or a big endian build.

CROSS_COMPILE could be set to anything. It could be:
- mipsel-linux
- 4kc_le-linux
- mips-little-linux
- ...
Is this true?

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1123657263.29961.17.camel@localhost.localdomain> you wrote:
> 
> > > I would suggest doing it by config name and putting ENDIANNESS in
> > > config.mk something like so (untested):
> > 
> > I disagree. This is IMHO not a good idea.  I  think  the  tool  chain
> > should  "know" which endian mode it is. I don;t ike the ide to encode
> > this in a build target name:
> 
> How can we determine that?

Why do we have to? The only one who needs this type of information is
the toolchain, and it knows.

> CROSS_COMPILE could be set to anything. It could be:
> - mipsel-linux
> - 4kc_le-linux
> - mips-little-linux
> - ...
> Is this true?

Yes.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I'd rather be led to hell than managed to heaven.

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> > How can we determine that?
> 
> Why do we have to? The only one who needs this type of information is
> the toolchain, and it knows.

Correct. :-)

So, if (for example) if you would like to build the LE version:
# CROSS_COMPILE=mipsel-linux-gcc make dbau1200_config
# make

and BE:
# CROSS_COMPILE=mips-linux-gcc make dbau1200_config
# make

But, this way you need two toolchains :-(

How about if you would specify the endianness when you do a config.
Like:
# CROSS_COMPILE=mipsel-linux-gcc ENDIANNESS=LE make dbau1200_config
# make

Comments?

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1123659794.29961.22.camel@localhost.localdomain> you wrote:
>
> So, if (for example) if you would like to build the LE version:
> # CROSS_COMPILE=mipsel-linux-gcc make dbau1200_config
> # make
> 
> and BE:
> # CROSS_COMPILE=mips-linux-gcc make dbau1200_config
> # make

Right. This iis what I think should work.

> But, this way you need two toolchains :-(

Two - or one that can be called using different names (like the  ELDK
does).

> How about if you would specify the endianness when you do a config.
> Like:
> # CROSS_COMPILE=mipsel-linux-gcc ENDIANNESS=LE make dbau1200_config
> # make

No, this seems even worse to me.

Ummm... How is this handled in the Linux kernel?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mandrell: "You know what I think?"
Doctor:   "Ah, ah that's a catch question. With a brain your size you
          don't think, right?"
                - Dr. Who

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> > But, this way you need two toolchains :-(
> 
> Two - or one that can be called using different names (like the  ELDK
> does).

Different names?
What about default endianness?

This is in the mipsel-linux-gcc -dumpspecs:
*multilib_defaults:
EL mips1 mabi=32

And in the mips-linux-gcc -dumpspecs:
*multilib_defaults:
EB mips1 mabi=32

> Ummm... How is this handled in the Linux kernel?

In .config:
CONFIG_CPU_LITTLE_ENDIAN=y
or
CONFIG_CPU_BIG_ENDIAN=y

Actually, when you're building toolchains for MIPS with crosstool, the
difference between the mipsel(EL) and mips(BE) is in kernel config file,
which sets the endianness for the toolchain.

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1123665206.29961.31.camel@localhost.localdomain> you wrote:
> 
> > Two - or one that can be called using different names (like the  ELDK
> > does).
> 
> Different names?

Like that:

-> ls -l /opt/eldk/usr/bin/mips*gcc
-rwxr-xr-x  1 root root 81896 Mar  6 20:12 /opt/eldk/usr/bin/mips-linux-gcc
lrwxrwxrwx  1 root root    14 Mar 12 19:28 /opt/eldk/usr/bin/mips_4KC-gcc -> mips-linux-gcc
lrwxrwxrwx  1 root root    14 Mar 12 19:28 /opt/eldk/usr/bin/mips_4KCle-gcc -> mips-linux-gcc

> What about default endianness?

mips_4KC-gcc is big endian, mips_4KCle-gcc is little endian.

> This is in the mipsel-linux-gcc -dumpspecs:
> *multilib_defaults:
> EL mips1 mabi=32
> 
> And in the mips-linux-gcc -dumpspecs:
> *multilib_defaults:
> EB mips1 mabi=32

The ELDK has

	*multilib_defaults:
	EB mips1 mabi=32

for both, but  mips_4KC-gcc  passes  -DMIPSEB  -D_MIPSEB  as  default
options while mips_4KCle-gcc passes -D_MIPSEL -D__MIPSEL -D__MIPSEL__
-DMIPSEL


> > Ummm... How is this handled in the Linux kernel?
> 
> In .config:
> CONFIG_CPU_LITTLE_ENDIAN=y
> or
> CONFIG_CPU_BIG_ENDIAN=y
> 
> Actually, when you're building toolchains for MIPS with crosstool, the
> difference between the mipsel(EL) and mips(BE) is in kernel config file,
> which sets the endianness for the toolchain.

Seems completely the wrong way round to me... I don't want  a  random
kernel tree to determine if my tool chain is BE or LE. Grrghh..

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone who isn't confused here doesn't really know what's going on.

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> Why do we have to? The only one who needs this type of information is
> the toolchain, and it knows.

I tested this with two toolchains, BE and LE and Wolfgang is right that
the toolchain knows what endianness should be. Well this is partly true,
because this is know to gcc (look at the -dumpspecs) but not to the
linker, because in the linker script for the board
(board/xxx/u-boot.lds) you tell the linker what is the default
endianness (OUTPUT_FORMAT(default, big, little)).

I think we need to tell the linker what endianness it should use if
we are using little endian build, because the default is set to
big. Or we can use two linker scripts.

Did I miss something, or is this correct?

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1124262461.16175.22.camel@localhost.localdomain> you wrote:
> 
> I tested this with two toolchains, BE and LE and Wolfgang is right that
> the toolchain knows what endianness should be. Well this is partly true,
> because this is know to gcc (look at the -dumpspecs) but not to the
> linker, because in the linker script for the board
> endianness (OUTPUT_FORMAT(default, big, little)).

So is there a clever way to "ask" gcc which endianess it's using? 
I tried to come up with one but failed so far...

> Did I miss something, or is this correct?

I think rhis is correct.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
People with narrow minds usually have broad tongues.

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> So is there a clever way to "ask" gcc which endianess it's using? 
> I tried to come up with one but failed so far...

You do something similar in the cpu/mips/config.mk where the version
of assembler is checked and then appropriate flags are chosen.
How about something like:
# ${CROSS_COMPILE}gcc -dumpspecs

And check what is written under the *multilib_defaults, if it is
EL or EB.

In my case (little endian):
*multilib_defaults:
EL mips1 mabi=32

And then add to LDFLAGS either -EL or -EB.

I am not a awk/sed/grep expert. :-(
Maybe someone else who knows the tools can do that?

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1124267094.16175.30.camel@localhost.localdomain> you wrote:
> 
> How about something like:
> # ${CROSS_COMPILE}gcc -dumpspecs

Doesn't work for me.

> In my case (little endian):
> *multilib_defaults:
> EL mips1 mabi=32

-> export CROSS_COMPILE=mips_4KC-
-> mips_4KC-gcc -dumpspecs
...
*multilib_defaults:
EB mips1 mabi=32

-> export CROSS_COMPILE=mips_4KCle-
-> mips_4KCle-gcc -dumpspecs
...
*multilib_defaults:
EB mips1 mabi=32

But mips_4KCle-gcc _does_ build LE code just fine ...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Never call a man a fool.  Borrow from him.

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> > How about something like:
> > # ${CROSS_COMPILE}gcc -dumpspecs
> 
> Doesn't work for me.

Yes, you need to export the CROSS_COMPILE.

> > In my case (little endian):
> > *multilib_defaults:
> > EL mips1 mabi=32
> 
> -> export CROSS_COMPILE=mips_4KC-
> -> mips_4KC-gcc -dumpspecs
> ...
> *multilib_defaults:
> EB mips1 mabi=32
> 
> -> export CROSS_COMPILE=mips_4KCle-
> -> mips_4KCle-gcc -dumpspecs
> ...
> *multilib_defaults:
> EB mips1 mabi=32
> 
> But mips_4KCle-gcc _does_ build LE code just fine ...

I checked previous messages and you said you have the same compiler
and with different names of the links that points to it.
/opt/eldk/usr/bin/mips_4KC-gcc -> mips-linux-gcc
/opt/eldk/usr/bin/mips_4KCle-gcc -> mips-linux-gcc

Where do you configure the options that this two "different" compilers
use? DMIPSEB  -D_MIPSEB for mips_4KC-gcc or -D_MIPSEL -D__MIPSEL
-D__MIPSEL__ -DMIPSEL for mips_4KCle-gcc?

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1124346699.11376.9.camel@localhost.localdomain> you wrote:
> 
> Yes, you need to export the CROSS_COMPILE.

Of course I did. See the examples I posted.

> I checked previous messages and you said you have the same compiler
> and with different names of the links that points to it.
> /opt/eldk/usr/bin/mips_4KC-gcc -> mips-linux-gcc
> /opt/eldk/usr/bin/mips_4KCle-gcc -> mips-linux-gcc

Right.

> Where do you configure the options that this two "different" compilers
> use? DMIPSEB  -D_MIPSEB for mips_4KC-gcc or -D_MIPSEL -D__MIPSEL
> -D__MIPSEL__ -DMIPSEL for mips_4KCle-gcc?

The gcc compiler driver reads and evaluates (1) the name under  which
the  binary  was  called  and  (2)  the  content of the CROSS_COMPILE
environment variable.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Behind every great man, there is a woman -- urging him on.
	-- Harry Mudd, "I, Mudd", stardate 4513.3

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> Of course I did. See the examples I posted.

Yes, sorry for that. :-(

> The gcc compiler driver reads and evaluates (1) the name under  which
> the  binary  was  called  and  (2)  the  content of the CROSS_COMPILE
> environment variable.

Aha, thanks for the explanation.

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> So is there a clever way to "ask" gcc which endianess it's using? 
> I tried to come up with one but failed so far...

I am searching how to do that.
How about if the config.mk runs a little test program, like
configure does?

For example:

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char **argv)
{
	unsigned int data = 0x01234567;
	char *ptr = (char *)&data;
	if (ptr[0] == 0x01 && ptr[1] == 0x23 && ptr[2] == 0x45 && ptr[3] == 0x67)
		printf("big\n");
	else if (ptr[3] == 0x01 && ptr[2] == 0x23 && ptr[1] == 0x45 && ptr[0] == 0x67)
		printf("little\n");
	else
		printf("unknown\n");
	return 0;
}

And then check the output of this program and decides to pass the -EL or -EB 
to LDFLAGS.

Oh, do you know why I have to use the:
 -Wa,-allow_branch_to_undefined
instead of:
 -Wa,-mips_allow_branch_to_undefined
even though (I guess) I use the same patch as you do?

And why don't you accept the patch that eliminates this patch to
binutils?

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1124354577.13487.4.camel@localhost.localdomain> you wrote:
> 
> How about if the config.mk runs a little test program, like
> configure does?

If you want to _run_ the test  program  you  have  to  use  the  host
compiler,  which  is  not  interesting.  And  when  you use the cross
compiler which you want to test then you cannot run the test  program
on the development host.

> Oh, do you know why I have to use the:
>  -Wa,-allow_branch_to_undefined
> instead of:
>  -Wa,-mips_allow_branch_to_undefined
> even though (I guess) I use the same patch as you do?

Probably because it's a slightly different version of the patch.  See
the eldk_build build module on our CVS server:
cross_rpms/binutils/SOURCES/binutils-2.14.0-mips-asm-undefbranch.patch
target_rpms/binutils/SOURCES/binutils-2.14.0-mips-asm-undefbranch.patch

> And why don't you accept the patch that eliminates this patch to
> binutils?

Ummm.. which patch are you referring to?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Uncertain fortune is thoroughly mastered by the equity of the  calcu-
lation.                                               - Blaise Pascal

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> > How about if the config.mk runs a little test program, like
> > configure does?
> 
> If you want to _run_ the test  program  you  have  to  use  the  host
> compiler,  which  is  not  interesting.  And  when  you use the cross
> compiler which you want to test then you cannot run the test  program
> on the development host.

Right!
My BIG mistake. Still searching and checking :-(

> Probably because it's a slightly different version of the patch.  See
> the eldk_build build module on our CVS server:
> cross_rpms/binutils/SOURCES/binutils-2.14.0-mips-asm-undefbranch.patch
> target_rpms/binutils/SOURCES/binutils-2.14.0-mips-asm-undefbranch.patch

O.K. I'll check that.

> > And why don't you accept the patch that eliminates this patch to
> > binutils?
> 
> Ummm.. which patch are you referring to?

See the mail on this mailing list:
                              From: 
Eugene Surovegin <ebs@ebshome.net>
                           Subject: 
Re: [U-Boot-Users] MIPS build
environment
Date: 30. Jan 1:20 AM

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Udi Finkelstein]

Matej Kupljen wrote:

>Hi
>
>  
>
>>>How about if the config.mk runs a little test program, like
>>>configure does?
>>>      
>>>
>>If you want to _run_ the test  program  you  have  to  use  the  host
>>compiler,  which  is  not  interesting.  And  when  you use the cross
>>compiler which you want to test then you cannot run the test  program
>>on the development host.
>>    
>>
>
>Right!
>My BIG mistake. Still searching and checking :-(
>  
>
You can try http://www.scratchbox.org/

This should allow you to use autoconf style configuration (./configure) 
on embedded targets and cross compilation environment by either running 
the configuration script under a QEmu simulated environment, or by an 
actual target board connected to the host.

Udi

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <4304E779.3000400@udif.com> you wrote:
>
> You can try http://www.scratchbox.org/

We can, but we won't.

> This should allow you to use autoconf style configuration (./configure) 
> on embedded targets and cross compilation environment by either running 
> the configuration script under a QEmu simulated environment, or by an 
> actual target board connected to the host.

Maybe. But you don't seriously suggest to make this a requirement  to
be able to build U-Boot???

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How does a project get to be a year late?      ... One day at a time.

[U-Boot-Users] Re: MIPS LE build problems

[Udi Finkelstein]

Wolfgang Denk wrote:

>In message <4304E779.3000400@udif.com> you wrote:
>  
>
>>You can try http://www.scratchbox.org/
>>    
>>
>
>We can, but we won't.
>
>  
>
>>This should allow you to use autoconf style configuration (./configure) 
>>on embedded targets and cross compilation environment by either running 
>>the configuration script under a QEmu simulated environment, or by an 
>>actual target board connected to the host.
>>    
>>
>
>Maybe. But you don't seriously suggest to make this a requirement  to
>be able to build U-Boot???
>  
>
I'm not suggesting anything. I'm merely pointing out the availability of 
an interesting technical solution to a problem encountered here.

>Best regards,
>
>Wolfgang Denk
>
>  
>
Udi

[U-Boot-Users] Re: MIPS LE build problems

[Wolfgang Denk]

In message <1124356104.13487.12.camel@localhost.localdomain> you wrote:
> 
> > Ummm.. which patch are you referring to?
> 
> See the mail on this mailing list:
>                               From: 
> Eugene Surovegin <ebs@ebshome.net>
>                            Subject: 
> Re: [U-Boot-Users] MIPS build
> environment
> Date: 30. Jan 1:20 AM

Can you please provide an URL? I can't find a patch from this time in
my archive.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Things that try to look like things often do look  more  like  things
than things. Well-known fact.       - Terry Pratchett, _Wyrd Sisters_

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> Can you please provide an URL? I can't find a patch from this time in
> my archive.

http://sourceforge.net/mailarchive/message.php?msg_id=10690757

BR,
Matej

[U-Boot-Users] Re: MIPS LE build problems

[Jerry Van Baren]

Matej Kupljen wrote:
> Hi
> 
> 
>>So is there a clever way to "ask" gcc which endianess it's using? 
>>I tried to come up with one but failed so far...
> 
> 
> I am searching how to do that.
> How about if the config.mk runs a little test program, like
> configure does?
> 
> For example:
> 
> #include <stdio.h>
> #include <stdlib.h>
> int main(int argc, char **argv)
> {
> 	unsigned int data = 0x01234567;
> 	char *ptr = (char *)&data;
> 	if (ptr[0] == 0x01 && ptr[1] == 0x23 && ptr[2] == 0x45 && ptr[3] == 0x67)
> 		printf("big\n");
> 	else if (ptr[3] == 0x01 && ptr[2] == 0x23 && ptr[1] == 0x45 && ptr[0] == 0x67)
> 		printf("little\n");
> 	else
> 		printf("unknown\n");
> 	return 0;
> }
> 
> And then check the output of this program and decides to pass the -EL or -EB 
> to LDFLAGS.
> 
> Oh, do you know why I have to use the:
>  -Wa,-allow_branch_to_undefined
> instead of:
>  -Wa,-mips_allow_branch_to_undefined
> even though (I guess) I use the same patch as you do?
> 
> And why don't you accept the patch that eliminates this patch to
> binutils?
> 
> BR,
> Matej

As noted in other email in this thread, executing the above code won't 
work.  What about simply compiling a file containing:

constant int data = 0x01234567;

objdumping the data section, and looking (grepping) to see if the data 
section has 0x12345678 or 0x78563412?

Speculating ignorantly...
gvb

[U-Boot-Users] Re: MIPS LE build problems

[Matej Kupljen]

Hi

> I have attached the patch.

Thanks.
Few comments, though.
I use my own toolchain, built with the crosstool and a few patches.
binutils: 2.15
gcc: 3.3.5
glibc: 2.3.5

>  #########################################################################
>  ## MIPS64 5Kc
> diff --git a/cpu/mips/config.mk b/cpu/mips/config.mk
> --- a/cpu/mips/config.mk
> +++ b/cpu/mips/config.mk
> @@ -24,9 +24,17 @@ v=$(shell \
>  mips-linux-as --version|grep "GNU assembler"|awk '{print $$3}'|awk -F . '{print $$2}')

Should this be, like:
$(CROSS_COMPILE)as --version|grep "GNU assembler"|awk '{print $$3}'|awk
-F . '{print $$2}')

Because my compiler is: mipsel-linux-gcc


>  MIPSFLAGS=$(shell \
>  if [ "$v" -lt "14" ]; then \
> -	echo "-mcpu=4kc -EB -mabicalls"; \
> +	echo "-mcpu=4kc"; \
>  else \
> -	echo "-march=4kc -mtune=4kc -Wa,-mips_allow_branch_to_undefined -EB -mabicalls"; \
> +	echo "-march=4kc -mtune=4kc -Wa,-mips_allow_branch_to_undefined"; \
>  fi)

The -mips_allow_branch_to_undefined does not work for me :-)
I used this patch:
http://sources.redhat.com/ml/binutils/2004-04/msg00476.html
And I have to use -allow_branch_to_undefined.
Anybody knows why?

BR,
Matej