On Tue, 25 Jan 2011 23:22:34 -0600
Kumar Gala wrote:
>
> On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote:
>
> > Dear Scott Wood,
> >
> > In message <20110125143740.2e1f2...@udp111988uds.am.freescale.net> you
> > wrote:
> >>
> >> Do you have a simpler way to do this? Note that for any board
On Jan 25, 2011, at 3:13 PM, Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20110125143740.2e1f2...@udp111988uds.am.freescale.net> you wrote:
>>
>> Do you have a simpler way to do this? Note that for any board that
>
> e009cde powerpc: Fix FPU post related link warnings
>
> ?
>
>
Dear Scott Wood,
In message <20110125143740.2e1f2...@udp111988uds.am.freescale.net> you wrote:
>
> Do you have a simpler way to do this? Note that for any board that
e009cde powerpc: Fix FPU post related link warnings
?
> > given the fact that there are
> > no intentions to work with floatin
On Tue, 25 Jan 2011 21:19:19 +0100
Wolfgang Denk wrote:
> Dear Scott Wood,
>
> In message <20110125140547.2825f...@udp111988uds.am.freescale.net> you wrote:
> >
> > On cores that have FP (at least those that support the FPU POST, and
> > which are currently having problems), use hard float, enab
Dear Scott Wood,
In message <20110125140547.2825f...@udp111988uds.am.freescale.net> you wrote:
>
> On cores that have FP (at least those that support the FPU POST, and
> which are currently having problems), use hard float, enable
> MSR[FP] or equivalent, and let GCC use FP for various tasks if it
On Tue, 25 Jan 2011 11:49:53 -0600
Kumar Gala wrote:
>
> On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:
>
> > Kumar Gala wrote:
> >> Actually we've dealt with this already:
> >>
> >> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
> >> Author: Yuri Tikhonov
> >> Date: Sat Dec 20 14:54:21 2
Wolfgang Denk wrote:
> But we also do not have any need for FP operations either. It would
> just add to the complexity (and to the memory foot print, especially
> on systems without FPU where we would have to provide soft-float
> libraries, plus eventually variantes for SPEv1 and SPEvv2 and
> what
Dear Timur Tabi,
In message <4d3f1d25.4070...@freescale.com> you wrote:
>
> I think you misunderstand. I'm not saying that we should use FP instructions
> in
> U-Boot. I'm saying that since we *don't* use FP instructions in U-Boot, we
> can
> just turn on hard-float and avoid any incompatibili
Dear Timur Tabi,
In message <4d3f16c7.7040...@freescale.com> you wrote:
>
> But when will gcc generate FP instructions? If we compile with soft-float,
> will
> it link in an FP library and use it?
GCC will (in addition to the obvious case of operations of FP data
types) generate FP instructions
Dear Timur Tabi,
In message <4d3f1674.10...@freescale.com> you wrote:
>
> Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have
> that problem.
But we also do not have any need for FP operations either. It would
just add to the complexity (and to the memory foot print, espe
Kumar Gala wrote:
> * still have to deal with cores that dont have FP
But when will gcc generate FP instructions? If we compile with soft-float, will
it link in an FP library and use it?
My point is that compiling with soft-float doesn't make much more sense than
compiling with hard-float, since
Wolfgang Denk wrote:
> Why doesn't the Linux kernel use floating point instructions?
Because dealing with FP in a multi-tasking OS is messy. U-Boot doesn't have
that problem.
--
Timur Tabi
Linux kernel developer at Freescale
___
U-Boot mailing list
U
Dear Timur Tabi,
In message <4d3efcf2.4060...@freescale.com> you wrote:
>
> Why don't we compile all of U-Boot with hard float by default? What's wrong
> with using floating point instructions in U-Boot?
We don't need it.
Why doesn't the Linux kernel use floating point instructions?
Best regar
On Jan 25, 2011, at 10:40 AM, Timur Tabi wrote:
> Kumar Gala wrote:
>> Actually we've dealt with this already:
>>
>> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
>> Author: Yuri Tikhonov
>> Date: Sat Dec 20 14:54:21 2008 +0300
>>
>>FPU POST: fix warnings when building with 2.18 binuti
Kumar Gala wrote:
> Actually we've dealt with this already:
>
> commit ce82ff05388b5ddafdf6082ef0776cce72c40b1c
> Author: Yuri Tikhonov
> Date: Sat Dec 20 14:54:21 2008 +0300
>
> FPU POST: fix warnings when building with 2.18 binutils
Why don't we compile all of U-Boot with hard float by
On Jan 25, 2011, at 12:36 AM, Wolfgang Denk wrote:
> Dear Kumar Gala,
>
> In message <356989c7-fa92-46d5-9fb6-5f9332ecb...@kernel.crashing.org> you
> wrote:
>>
>> The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
>>
>> CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-fl
Dear Kumar Gala,
In message <356989c7-fa92-46d5-9fb6-5f9332ecb...@kernel.crashing.org> you wrote:
>
> The issue is that the code under post/lib_powerpc/fpu/* is compiled with:
>
> CFLAGS := $(shell echo $(CFLAGS) | sed s/-msoft-float//)
> CFLAGS += -mhard-float -fkeep-inline-functions
>
> We ne
On Jan 24, 2011, at 2:54 PM, Timur Tabi wrote:
> On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier
> wrote:
>> NOTE: This does not include the actual patch as it is too large for the
>> mailing list (418 kB).
>>
>> Before this commit, weak symbols were not overridden by non-weak symbols
>> fo
On Mon, Nov 8, 2010 at 4:04 PM, Sebastien Carlier
wrote:
> NOTE: This does not include the actual patch as it is too large for the
> mailing list (418 kB).
>
> Before this commit, weak symbols were not overridden by non-weak symbols
> found in archive libraries
> when linking with recent version
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> This commit changes all Makefiles to use partial linking (ld -r) instead of
> creating library archives, which forces all symbols to participate in
> linking, allowing non-weak symbols to override weak symbols as intended.
> This app
Dear Mike Frysinger,
Am 10.11.2010 07:57, schrieb Mike Frysinger:
> On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> the config.mk looks weird:
> +cmd_link_o_target = $(if $(strip $1),\
> + $(LD) -r -o $@ $1 ,\
> + rm -f $@; $(AR) rcs $@ )
On Monday, November 08, 2010 17:04:32 Sebastien Carlier wrote:
> This commit changes all Makefiles to use partial linking (ld -r) instead of
> creating library archives, which forces all symbols to participate in
> linking, allowing non-weak symbols to override weak symbols as intended.
> This app
On 11/08/2010 11:04 PM, Sebastien Carlier wrote:
> NOTE: This does not include the actual patch as it is too large for the
> mailing list (418 kB).
Your patch applies fine to i.MX branch - boards compile clean, tested on
a MX.51 board.
Tested-by: Stefano Babic
Best regards,
Stefano Babic
--
On 09/11/10 09:04, Sebastien Carlier wrote:
> NOTE: This does not include the actual patch as it is too large for the
> mailing list (418 kB).
> Signed-off-by: Sebastien Carlier
Patch applies with zero errors or warnings to my x86 branch, builds clean,
runs and, as a bonus, allows me to move th
Sebastian,
drivers/qe already has an object called "qe.o" ... renaming "qe.a" to
"qe.o" doesn't work.
I'd suggest to build libqe.o and also adapt Toplevel Makefile accordingly.
I also don't understand why ftd.c is not depending on CONFIG_QE.
That's another question ... but leads to error having
Dear Sebastien Carlier,
Am 08.11.2010 um 23:04 schrieb Sebastien Carlier:
> NOTE: This does not include the actual patch as it is too large for the
> mailing list (418 kB).
>
> Before this commit, weak symbols were not overridden by non-weak symbols
> found in archive libraries
> when linking
On Mon, Nov 8, 2010 at 11:10 PM, Graeme Russ wrote:
> On Tue, Nov 9, 2010 at 9:04 AM, Sebastien Carlier
> wrote:
>> NOTE: This does not include the actual patch as it is too large for the
>> mailing list (418 kB).
>>
>
> A link to the matching patch would have been nice :)
Ah, yes, I was wonder
On Tue, Nov 9, 2010 at 9:04 AM, Sebastien Carlier
wrote:
> NOTE: This does not include the actual patch as it is too large for the
> mailing list (418 kB).
>
A link to the matching patch would have been nice :)
Regards,
Graeme
___
U-Boot mailing list
NOTE: This does not include the actual patch as it is too large for the mailing
list (418 kB).
Before this commit, weak symbols were not overridden by non-weak symbols found
in archive libraries
when linking with recent versions of binutils. As stated in the System V ABI,
"the link editor does
29 matches
Mail list logo
