Sorry for being late,
On 03/24/2011 01:37 AM, Daniel Schwierzeck wrote:
2011/3/23 Shinya Kuribayashi skuri...@pobox.com:
Following changes have been introduced to ld in binutils-2.16:
[...]
I'd claim that all toolchains with binutils lesser than 2.16 are not
working anymore.
[...]
I suggest
2011/3/28 Shinya Kuribayashi skuri...@pobox.com:
Sorry for being late,
No problem
On 03/24/2011 01:37 AM, Daniel Schwierzeck wrote:
2011/3/23 Shinya Kuribayashi skuri...@pobox.com:
Following changes have been introduced to ld in binutils-2.16:
[...]
I'd claim that all toolchains with
On 3/29/11 12:27 AM, Daniel Schwierzeck wrote:
Ok if we drop toolchain support for binutils lesser than 2.16 than I
can simplify the
this patch to one line because the assembler check is obsolete too:
MIPSFLAGS = $(call cc-option,-march=mips32r2)
Do you agree?
It sounds you're
2011/3/28 Shinya Kuribayashi skuri...@pobox.com:
On 3/29/11 12:27 AM, Daniel Schwierzeck wrote:
Ok if we drop toolchain support for binutils lesser than 2.16 than I
can simplify the
this patch to one line because the assembler check is obsolete too:
MIPSFLAGS = $(call
On 03/21/2011 09:42 PM, Daniel Schwierzeck wrote:
I did some researching and testing with ELDK-4.1, ELDK-4.0 and ELDK-3.1.1.
Thanks, much appreciated.
In ELDK-3.1.1 we have:
- mips_4KC-gcc (GCC) 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)
- GNU assembler 2.14 20030612
Therefore mips32r2 is already
2011/3/23 Shinya Kuribayashi skuri...@pobox.com:
On 03/21/2011 09:42 PM, Daniel Schwierzeck wrote:
I did some researching and testing with ELDK-4.1, ELDK-4.0 and ELDK-3.1.1.
Thanks, much appreciated.
In ELDK-3.1.1 we have:
- mips_4KC-gcc (GCC) 3.3.3 (DENX ELDK 3.1.1 3.3.3-9)
- GNU
Hi Shinya,
2011/3/17 Shinya Kuribayashi skuri...@pobox.com:
On 03/16/2011 11:41 PM, Daniel Schwierzeck wrote:
Is my approach with -march acceptable? This is more important to me
for supporting new SoCs with 24k and 34k CPU cores. I think its a
clean approach to use a default Mips32
On 03/16/2011 11:41 PM, Daniel Schwierzeck wrote:
Is my approach with -march acceptable? This is more important to me
for supporting new SoCs with 24k and 34k CPU cores. I think its a
clean approach to use a default Mips32 architecture optimization plus
a per CPU optimization configured in the
2011/3/17 Shinya Kuribayashi skuri...@pobox.com:
On 03/16/2011 11:41 PM, Daniel Schwierzeck wrote:
Is my approach with -march acceptable? This is more important to me
for supporting new SoCs with 24k and 34k CPU cores. I think its a
clean approach to use a default Mips32 architecture
On 3/15/11 10:20 PM, Daniel Schwierzeck wrote:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81572/focus=81735
sorry, I missed that discussion
You can find a lot more in the list archive.
Do we need this endianess flag stuff at all? Each toolchain that is
built with a specific
2011/3/16 Shinya Kuribayashi skuri...@pobox.com:
On 3/15/11 10:20 PM, Daniel Schwierzeck wrote:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/81572/focus=81735
sorry, I missed that discussion
You can find a lot more in the list archive.
ok I looked through the past discussions and
Hi Shinya,
2011/3/15 Shinya Kuribayashi skuri...@pobox.com:
On 3/15/11 6:14 AM, daniel.schwierz...@googlemail.com wrote:
Replace the current MIPSFLAGS code by cc-option macro and use
-march=mips32r2 as default optimization level for all Mips32 CPUs.
Replace the endianess determination code
The current Mips CPU config.mk code always expects a Mips 4kc
core and toolchain. This is not appropiate for other toolchains
and CPUs/SoCs.
Replace the current MIPSFLAGS code by cc-option macro and use
-march=mips32r2 as default optimization level for all Mips32 CPUs.
Replace the endianess
On 3/15/11 6:14 AM, daniel.schwierz...@googlemail.com wrote:
Replace the current MIPSFLAGS code by cc-option macro and use
-march=mips32r2 as default optimization level for all Mips32 CPUs.
Replace the endianess determination code from toolchain prefix by
a more generic one inspired by the
14 matches
Mail list logo
