[U-Boot-Users] MIPS LE build problems
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
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
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
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
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
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)
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
In message 1123653934.29961.11.camel@localhost.localdomain you wrote:
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
Applied, thanks for pointing out.
Best regards,
Wolfgang Denk
participants (6)
-
Andrew Dyer -
Jerry Van Baren -
Matej Kupljen -
Thomas Lange -
Udi Finkelstein -
Wolfgang Denk