| Message ID | 1298042212-12260-1-git-send-email-raghuveer.murthy@ti.com |
|---|---|
| State | Rejected |
| Headers | show |
Le 18/02/2011 16:16, Raghuveer Murthy a écrit : > U-boot built for MeeGo on PandaBoard, with compiler option > -mfloat-abi=hard, caused a build break. Please refer to the bug id: > > http://bugs.meego.com/show_bug.cgi?id=13140 Is this the official U-Boot? Why is it still at 2010.09 ? > Removing the -msoft-float options in the config.mk files, allowed it > to be built for both armv7hl and armv7el compilers on MeeGo > > Please refer to the below link for more details: > http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal > > Signed-off-by: Raghuveer Murthy<raghuveer.murthy@ti.com> I would like to know which board of mainline U-boot is affected by the issue and how I can reproduce it on u-boot[-arm]/master. However, I can already tell that this 'bug' can only occur upon a mix of object files compiled with -msoft-float and -mhard-float; which means some files were compiled with -mhard-float; and this should not happen at all, since U-Boot should not use any floats at all, so: - either some files in the case reported were compiled voluntarily with hard-float, and this is not a generally supported use case of U-Boot; - or they were compiled without any float option and the toolchain defaulted to hard-float, which may be a meego but is no reason in itself for U-Boot to adapt to it. My feeling at the moment is that U-Boot should keep -msoft-float, to be sure that any float code present in the code base, if it has to be, will run regardless of hw floating point capabilities, because U-Boot binaries should make the least possible assumptions on the hardware they are running on. Now, CPUs/SoCs/boards that know they have a floating point unit may justly want to replace -msoft-float with -mhard-float everywhere throughout U-Boot; I would welcome a patch that allows U-Boot to default to soft float while allowing CPUs/SoCs/boards to override it for hard float. In no case, however, should -msoft-float be *removed*: that would make float support in U-Boot implicit and dependent on the toolchain in use, and I think U-Boot float support should always be explicit and not depend on the toolchain. Amicalement,
Hello, Am 18.02.2011 18:01, schrieb Albert ARIBAUD: > In no case, however, should -msoft-float be *removed*: that would make > float support in U-Boot implicit and dependent on the toolchain in use, > and I think U-Boot float support should always be explicit and not > depend on the toolchain. Beeing no friend of cross-compiling I would prefer to use the default of the toolchain and I don't see any problem with that. Regards, Alexander
Dear Raghuveer Murthy, In message <1298042212-12260-1-git-send-email-raghuveer.murthy@ti.com> you wrote: > U-boot built for MeeGo on PandaBoard, with compiler option > -mfloat-abi=hard, caused a build break. Please refer to the bug id: Well, isn't this a typical "Don't do that then!" situation? (Cf. http://www.jargon.net/jargonfile/d/Dontdothatthen.html) If this compiler option causes problems (which is IMHO not a surpise at all), then why are you using it? None of the U-Boot build rules contain any such option. Best regards, Wolfgang Denk
Albert ARIBAUD <albert.aribaud@free.fr> writes: > Le 18/02/2011 16:16, Raghuveer Murthy a écrit : >> U-boot built for MeeGo on PandaBoard, with compiler option >> -mfloat-abi=hard, caused a build break. Please refer to the bug id: >> >> http://bugs.meego.com/show_bug.cgi?id=13140 > > Is this the official U-Boot? Why is it still at 2010.09 ? > >> Removing the -msoft-float options in the config.mk files, allowed it >> to be built for both armv7hl and armv7el compilers on MeeGo >> >> Please refer to the below link for more details: >> http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal >> >> Signed-off-by: Raghuveer Murthy<raghuveer.murthy@ti.com> > > I would like to know which board of mainline U-boot is affected by the > issue and how I can reproduce it on u-boot[-arm]/master. I saw this for a while when building for Beagle. It no longer occurs with mainline u-boot. I can't say which commit fixed it. > However, I can already tell that this 'bug' can only occur upon a mix of > object files compiled with -msoft-float and -mhard-float; which means > some files were compiled with -mhard-float; and this should not happen > at all, since U-Boot should not use any floats at all, so: The problem was that something from libgcc got pulled in, probably an integer division or similar. > - either some files in the case reported were compiled voluntarily with > hard-float, and this is not a generally supported use case of U-Boot; > > - or they were compiled without any float option and the toolchain > defaulted to hard-float, which may be a meego but is no reason in itself > for U-Boot to adapt to it. In my case, it was the latter cause. > My feeling at the moment is that U-Boot should keep -msoft-float, to be > sure that any float code present in the code base, if it has to be, will > run regardless of hw floating point capabilities, because U-Boot > binaries should make the least possible assumptions on the hardware they > are running on. > > Now, CPUs/SoCs/boards that know they have a floating point unit may > justly want to replace -msoft-float with -mhard-float everywhere > throughout U-Boot; I would welcome a patch that allows U-Boot to default > to soft float while allowing CPUs/SoCs/boards to override it for hard float. > > In no case, however, should -msoft-float be *removed*: that would make > float support in U-Boot implicit and dependent on the toolchain in use, > and I think U-Boot float support should always be explicit and not > depend on the toolchain. There is no reason for supporting hardware floating-point in u-boot. If floating-point is used at all, and I can't think of a place where it is, it is not relevant to performance. The added complexity of supporting a hardware FPU is not worth it, in my opinion.
Hello, Am 19.02.2011 12:19, schrieb Måns Rullgård: >> In no case, however, should -msoft-float be *removed*: that would make >> float support in U-Boot implicit and dependent on the toolchain in use, >> and I think U-Boot float support should always be explicit and not >> depend on the toolchain. > > There is no reason for supporting hardware floating-point in u-boot. If > floating-point is used at all, and I can't think of a place where it is, > it is not relevant to performance. The added complexity of supporting a > hardware FPU is not worth it, in my opinion. I still don't understand this discussion. Floats aren't used in u-boot, so why should it make a difference if -msoft-float will be removed? I know there was one bug which linked in something wrong from glibc, but if that flag isn't needed than it shouldn't make a difference at all if -msoft-float or -mhard-float is used. So whats the reasoning to use -msoft-float as it is currently done? To confuse people? ;) Regards, Alexander
Alexander Holler <holler@ahsoftware.de> writes: > Hello, > > Am 19.02.2011 12:19, schrieb Måns Rullgård: > >>> In no case, however, should -msoft-float be *removed*: that would make >>> float support in U-Boot implicit and dependent on the toolchain in use, >>> and I think U-Boot float support should always be explicit and not >>> depend on the toolchain. >> >> There is no reason for supporting hardware floating-point in u-boot. If >> floating-point is used at all, and I can't think of a place where it is, >> it is not relevant to performance. The added complexity of supporting a >> hardware FPU is not worth it, in my opinion. > > I still don't understand this discussion. Floats aren't used in u-boot, > so why should it make a difference if -msoft-float will be removed? I > know there was one bug which linked in something wrong from glibc, but > if that flag isn't needed than it shouldn't make a difference at all if > -msoft-float or -mhard-float is used. The linker refuses to combine objects with different calling conventions, and those tags are set based only on compiler flags, not what code the file actually contains. Some version of u-boot with some versions of gcc erroneously pull in something from libgcc, which will fail if libgcc and u-boot used different ABI flags. The real error here is that of linking in libgcc in the first place, not the ABI flags. > So whats the reasoning to use -msoft-float as it is currently done? To > confuse people? ;) I guess it's there to make sure no floating-point instructions make it into u-boot, even though floats are not used in the code. Perhaps someone was paranoid.
Le 19/02/2011 14:25, Måns Rullgård a écrit : >> So whats the reasoning to use -msoft-float as it is currently done? To >> confuse people? ;) > > I guess it's there to make sure no floating-point instructions make it > into u-boot, even though floats are not used in the code. Perhaps > someone was paranoid. I think also that there is no choice but to have a float option for ARM C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with the 'soft' calling conventions), because the C compiler does not allow 'no floats', and anyway the C language *requires* to have some sort of float support. Actually if you don't specify any float option, the C toolchain will choose one, which is just the same in the end: *some* float option is chosen. And since some option must be chosen, I prefer that U-Boot make the explicit decision, and choose soft float for the reasons I already exposed. Amicalement,
Am 19.02.2011 14:51, schrieb Albert ARIBAUD: > Le 19/02/2011 14:25, Måns Rullgård a écrit : > >>> So whats the reasoning to use -msoft-float as it is currently done? To >>> confuse people? ;) >> >> I guess it's there to make sure no floating-point instructions make it >> into u-boot, even though floats are not used in the code. Perhaps >> someone was paranoid. > > I think also that there is no choice but to have a float option for ARM > C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with > the 'soft' calling conventions), because the C compiler does not allow > 'no floats', and anyway the C language *requires* to have some sort of > float support. As it is on every platform. > Actually if you don't specify any float option, the C toolchain will > choose one, which is just the same in the end: *some* float option is > chosen. Every compiler has dozens of options which are set to a default value. > And since some option must be chosen, I prefer that U-Boot make the > explicit decision, and choose soft float for the reasons I already exposed. I don't see any reason to explicitly set an option for something which isn't used, but I know of many reasons to avoid such. ;) Regards, Alexander
Le 19/02/2011 15:06, Alexander Holler a écrit : > Am 19.02.2011 14:51, schrieb Albert ARIBAUD: >> Le 19/02/2011 14:25, Måns Rullgård a écrit : >> >>>> So whats the reasoning to use -msoft-float as it is currently done? To >>>> confuse people? ;) >>> >>> I guess it's there to make sure no floating-point instructions make it >>> into u-boot, even though floats are not used in the code. Perhaps >>> someone was paranoid. >> >> I think also that there is no choice but to have a float option for ARM >> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with >> the 'soft' calling conventions), because the C compiler does not allow >> 'no floats', and anyway the C language *requires* to have some sort of >> float support. > > As it is on every platform. Indeed. >> Actually if you don't specify any float option, the C toolchain will >> choose one, which is just the same in the end: *some* float option is >> chosen. > > Every compiler has dozens of options which are set to a default value. Granted. But not all of them relate to hardware which may or may not be available. >> And since some option must be chosen, I prefer that U-Boot make the >> explicit decision, and choose soft float for the reasons I already >> exposed. > > I don't see any reason to explicitly set an option for something which > isn't used, but I know of many reasons to avoid such. ;) At least there is one reason for having -msoft-float even though no floating point should be used in U-Boot : it helps catching cases where some code in U-Boot tries to use hard float. :) Think of it as choosing the least dangerous of Charybdis and Scylla, while trying our best not to get near any of the two. > Regards, > > Alexander Amicalement,
Albert ARIBAUD <albert.aribaud@free.fr> writes: > Le 19/02/2011 15:06, Alexander Holler a écrit : >> Am 19.02.2011 14:51, schrieb Albert ARIBAUD: >>> Le 19/02/2011 14:25, Måns Rullgård a écrit : >>> >>>>> So whats the reasoning to use -msoft-float as it is currently done? To >>>>> confuse people? ;) >>>> >>>> I guess it's there to make sure no floating-point instructions make it >>>> into u-boot, even though floats are not used in the code. Perhaps >>>> someone was paranoid. >>> >>> I think also that there is no choice but to have a float option for ARM >>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with >>> the 'soft' calling conventions), because the C compiler does not allow >>> 'no floats', and anyway the C language *requires* to have some sort of >>> float support. >> >> As it is on every platform. > > Indeed. > >>> Actually if you don't specify any float option, the C toolchain will >>> choose one, which is just the same in the end: *some* float option is >>> chosen. >> >> Every compiler has dozens of options which are set to a default value. > > Granted. But not all of them relate to hardware which may or may not be > available. > >>> And since some option must be chosen, I prefer that U-Boot make the >>> explicit decision, and choose soft float for the reasons I already >>> exposed. >> >> I don't see any reason to explicitly set an option for something which >> isn't used, but I know of many reasons to avoid such. ;) > > At least there is one reason for having -msoft-float even though no > floating point should be used in U-Boot : it helps catching cases where > some code in U-Boot tries to use hard float. :) There is one further complication here. If the compiler was built with -mfpu=neon as default, it might emit neon instructions for pure integer code. For the purpose of this discussion, such instructions should still be regarded as floating-point since they are tied to the VFP. Such code generation is disabled by -msoft-float.
Am 19.02.2011 15:27, schrieb Albert ARIBAUD: > Le 19/02/2011 15:06, Alexander Holler a écrit : >> Am 19.02.2011 14:51, schrieb Albert ARIBAUD: >>> Le 19/02/2011 14:25, Måns Rullgård a écrit : >>> >>>>> So whats the reasoning to use -msoft-float as it is currently done? To >>>>> confuse people? ;) >> I don't see any reason to explicitly set an option for something which >> isn't used, but I know of many reasons to avoid such. ;) > > At least there is one reason for having -msoft-float even though no > floating point should be used in U-Boot : it helps catching cases where > some code in U-Boot tries to use hard float. :) > > Think of it as choosing the least dangerous of Charybdis and Scylla, > while trying our best not to get near any of the two. Hmm, I could argue exactly the oposite. When using -msoft-float you won't find (unwanted) usages of float on any platform. To follow your argument, hard-floats should be enabled (if possible), so the usage of floats would lead to an error (at least on platforms without support for that). ;) Regards, Alexander
Le 19/02/2011 15:34, Måns Rullgård a écrit : > Albert ARIBAUD<albert.aribaud@free.fr> writes: > >> Le 19/02/2011 15:06, Alexander Holler a écrit : >>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD: >>>> Le 19/02/2011 14:25, Måns Rullgård a écrit : >>>> >>>>>> So whats the reasoning to use -msoft-float as it is currently done? To >>>>>> confuse people? ;) >>>>> >>>>> I guess it's there to make sure no floating-point instructions make it >>>>> into u-boot, even though floats are not used in the code. Perhaps >>>>> someone was paranoid. >>>> >>>> I think also that there is no choice but to have a float option for ARM >>>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with >>>> the 'soft' calling conventions), because the C compiler does not allow >>>> 'no floats', and anyway the C language *requires* to have some sort of >>>> float support. >>> >>> As it is on every platform. >> >> Indeed. >> >>>> Actually if you don't specify any float option, the C toolchain will >>>> choose one, which is just the same in the end: *some* float option is >>>> chosen. >>> >>> Every compiler has dozens of options which are set to a default value. >> >> Granted. But not all of them relate to hardware which may or may not be >> available. >> >>>> And since some option must be chosen, I prefer that U-Boot make the >>>> explicit decision, and choose soft float for the reasons I already >>>> exposed. >>> >>> I don't see any reason to explicitly set an option for something which >>> isn't used, but I know of many reasons to avoid such. ;) >> >> At least there is one reason for having -msoft-float even though no >> floating point should be used in U-Boot : it helps catching cases where >> some code in U-Boot tries to use hard float. :) > > There is one further complication here. If the compiler was built with > -mfpu=neon as default, it might emit neon instructions for pure integer > code. For the purpose of this discussion, such instructions should > still be regarded as floating-point since they are tied to the VFP. > Such code generation is disabled by -msoft-float. Thanks for indicating this. If I paraphrase this correctly, some toochains would generate floating instructions for integer if both -mfloat-abi=hard and -fmpu=neon were specified or were the default. I don't see this as a worrying matter though, because I suspect that toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and target cpus that have hw floating point capabilities, where such float instructions would cause no problem. And it is not as if the C code used floats. Besides, so far I have seen no complaint that -msoft-float disabling -mfpu=neon causes any problem with U-Boot, so I suspect no board requires it now. Amicalement,
Hello, Am 19.02.2011 16:32, schrieb Albert ARIBAUD: > Granted :) -- the best option would be to have "-float-abi=none", but > that does not exist, and I prefer to be sure that if some poor soul puts > floating point code in U-Boot then at least it is going to work for all > platforms, so I'll keep -msoft-float in here. Hmm, but as we've seen, that doesn't work for all platforms because you can't mix softfloat and hardfloat. So using softfloat breaks building on (default-) hardfloat platforms if some poor soul puts floating point code in (which requires hardfloat-libraries too). So I still think going with the default option would be the right way to go. ;) Regards, Alexander
Am 19.02.2011 16:40, schrieb Alexander Holler: > Hello, > > Am 19.02.2011 16:32, schrieb Albert ARIBAUD: > >> Granted :) -- the best option would be to have "-float-abi=none", but >> that does not exist, and I prefer to be sure that if some poor soul puts >> floating point code in U-Boot then at least it is going to work for all >> platforms, so I'll keep -msoft-float in here. > > Hmm, but as we've seen, that doesn't work for all platforms because you > can't mix softfloat and hardfloat. So using softfloat breaks building on > (default-) hardfloat platforms if some poor soul puts floating point > code in (which requires hardfloat-libraries too). > > So I still think going with the default option would be the right way to > go. ;) Btw, while we are there, is there any reason, besides being carefull, why u-boot for arm is compiled with -march=armv5(te) by default? I'm just curious if there are some reasons for not using march=amrv7a for armv7 platforms and don't want to start a discussion about removing that default. I've seen some comments about armv5, e.g. in arch/arm/cpu/armv7/omap3/cache.S, but I'm missing the knowledge to understand them. Regards, Alexander
Le 19/02/2011 16:59, Alexander Holler a écrit : > Am 19.02.2011 16:40, schrieb Alexander Holler: >> Hello, >> >> Am 19.02.2011 16:32, schrieb Albert ARIBAUD: >> >>> Granted :) -- the best option would be to have "-float-abi=none", but >>> that does not exist, and I prefer to be sure that if some poor soul puts >>> floating point code in U-Boot then at least it is going to work for all >>> platforms, so I'll keep -msoft-float in here. >> >> Hmm, but as we've seen, that doesn't work for all platforms because you >> can't mix softfloat and hardfloat. So using softfloat breaks building on >> (default-) hardfloat platforms if some poor soul puts floating point >> code in (which requires hardfloat-libraries too). You're missing the fact that floating point code is a no-no in U-Boot. We're not talking about the best option to support floating-point code in U-Boot, but the best option to catch the use of floating point. However, as I've said, I would be fine with someone submitting a patch that makes -mfloat-abi=xxx and -mfpu=yyy available as configuration options so that a board maintainer who feels the irresistible urge to have hard float support can have it *for performance improvement only* (as in the case Måns described about integer code being performed with float instructions), not for explicit use of floats or doubles in the code. Note that with such a scheme, a board (or SoC, or [vendor-specific] cpu) maintainer could even override the float default and decide to leave it blank so that the toolchain default is used, if they so want. The only things that won't be an option if such a patch is submitted are that i) the default config setting for float must be soft-float, and ii) a doc/README.arm-float must be added to reflect how the option works and what the risks are of soft and hard float, and that >> So I still think going with the default option would be the right way to >> go. ;) > > > Btw, while we are there, is there any reason, besides being carefull, > why u-boot for arm is compiled with -march=armv5(te) by default? > > I'm just curious if there are some reasons for not using march=amrv7a > for armv7 platforms and don't want to start a discussion about removing > that default. > > I've seen some comments about armv5, e.g. in > arch/arm/cpu/armv7/omap3/cache.S, but I'm missing the knowledge to > understand them. IIRC the conclusion was that U-Boot does not need armv7 specific instructions and besides, not all toolchains frequently used with U-Boot have v7 support -- especially the toolchain coming with ELDK 4.2. > Regards, > > Alexander Amicalement,
Albert ARIBAUD <albert.aribaud@free.fr> writes: > Le 19/02/2011 15:34, Måns Rullgård a écrit : >> Albert ARIBAUD<albert.aribaud@free.fr> writes: >> >>> Le 19/02/2011 15:06, Alexander Holler a écrit : >>>> Am 19.02.2011 14:51, schrieb Albert ARIBAUD: >>>>> Le 19/02/2011 14:25, Måns Rullgård a écrit : >>>>> >>>>>>> So whats the reasoning to use -msoft-float as it is currently done? To >>>>>>> confuse people? ;) >>>>>> >>>>>> I guess it's there to make sure no floating-point instructions make it >>>>>> into u-boot, even though floats are not used in the code. Perhaps >>>>>> someone was paranoid. >>>>> >>>>> I think also that there is no choice but to have a float option for ARM >>>>> C, either 'soft' or 'hard' (or 'softfp', actually, which is 'hard' with >>>>> the 'soft' calling conventions), because the C compiler does not allow >>>>> 'no floats', and anyway the C language *requires* to have some sort of >>>>> float support. >>>> >>>> As it is on every platform. >>> >>> Indeed. >>> >>>>> Actually if you don't specify any float option, the C toolchain will >>>>> choose one, which is just the same in the end: *some* float option is >>>>> chosen. >>>> >>>> Every compiler has dozens of options which are set to a default value. >>> >>> Granted. But not all of them relate to hardware which may or may not be >>> available. >>> >>>>> And since some option must be chosen, I prefer that U-Boot make the >>>>> explicit decision, and choose soft float for the reasons I already >>>>> exposed. >>>> >>>> I don't see any reason to explicitly set an option for something which >>>> isn't used, but I know of many reasons to avoid such. ;) >>> >>> At least there is one reason for having -msoft-float even though no >>> floating point should be used in U-Boot : it helps catching cases where >>> some code in U-Boot tries to use hard float. :) >> >> There is one further complication here. If the compiler was built with >> -mfpu=neon as default, it might emit neon instructions for pure integer >> code. For the purpose of this discussion, such instructions should >> still be regarded as floating-point since they are tied to the VFP. >> Such code generation is disabled by -msoft-float. > > Thanks for indicating this. If I paraphrase this correctly, some > toochains would generate floating instructions for integer if both > -mfloat-abi=hard and -fmpu=neon were specified or were the default. -mfloat-abi of hard or softfp both allow neon instruction to be emitted. > I don't see this as a worrying matter though, because I suspect that > toolchains that have -mfpu=neon will have -mfloat-abi=hard as well and > target cpus that have hw floating point capabilities, where such float > instructions would cause no problem. The issue is not one of hardware availability. Using the VFP/NEON unit at all requires additional support beyond simply using the instructions. Firstly, the coprocessor must be enabled, which although a trivial operation does add complexity and maintenance burden. Secondly, any code run in an interrupt context must be somehow arranged to be free of VFP/NEON code, or the VFP context must be saved and restored around interrupt handlers. The latter is a bad idea since it significantly slows interrupt handling. This leaves us with the former option, and if some code must be VFP-free, that requirement might as well be extended to all code with no additional burden. The simplest way to make sure no VFP or NEON instructions are used is to pass -msoft-float to the compiler. Since linking to libgcc is an error in u-boot, ABI compatibility with it is of no concern. To summarise, I think using -msoft-float is good. Supporting floating-point in u-boot is more trouble than it's worth, and -msoft-float is an easy way to make sure the code is clean.
Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=, In message <yw1x7hcw5f6w.fsf@unicorn.mansr.com> you wrote: > > > So whats the reasoning to use -msoft-float as it is currently done? To > > confuse people? ;) > > I guess it's there to make sure no floating-point instructions make it > into u-boot, even though floats are not used in the code. Perhaps > someone was paranoid. No. There are pretty good reasons to use -msoft-float. On some systems certain versions of GCC will optimize certain operations (usually corresponding to 8 byte memory copy things) by using FP registers. -msoft-float prevents that. Best regards, Wolfgang Denk
Dear Albert ARIBAUD, In message <4D5FCACA.1060606@free.fr> you wrote: > > And since some option must be chosen, I prefer that U-Boot make the > explicit decision, and choose soft float for the reasons I already exposed. I explained this several times before. There are good reasons to have -msoft-float. If the tool chain has problems by not providing soft-float libgcc routines, the user can always use the U-Boot provided library functions. Best regards, Wolfgang Denk
Dear Alexander Holler, In message <4D5FCE64.8030901@ahsoftware.de> you wrote: > > I don't see any reason to explicitly set an option for something which > isn't used, but I know of many reasons to avoid such. ;) Read my previous messages, and/or the archives. There _are_ good reasons that -msoft-float is used. Best regards, Wolfgang Denk
Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=, In message <yw1xy65c3xfi.fsf@unicorn.mansr.com> you wrote: > > There is one further complication here. If the compiler was built with > -mfpu=3Dneon as default, it might emit neon instructions for pure integer > code. For the purpose of this discussion, such instructions should > still be regarded as floating-point since they are tied to the VFP. > Such code generation is disabled by -msoft-float. Right. May we now just agree that "-msoft-float" is a matter of fact and mandatory in U-Boot. Thanks. Best regards, Wolfgang Denk
Dear Alexander Holler, In message <4D5FE485.5030007@ahsoftware.de> you wrote: > > Hmm, but as we've seen, that doesn't work for all platforms because you > can't mix softfloat and hardfloat. So using softfloat breaks building on > (default-) hardfloat platforms if some poor soul puts floating point > code in (which requires hardfloat-libraries too). A Perfect Tool Chain (TM) should provide all the needed libgcc support. If it fails to do that, then U-Boot provides all the needed library functions, you just have to use them. Best regards, Wolfgang Denk
Dear Alexander Holler, In message <4D5FE8F0.1020607@ahsoftware.de> you wrote: > > Btw, while we are there, is there any reason, besides being carefull, > why u-boot for arm is compiled with -march=armv5(te) by default? Because that's the lowest ARM instruction set version supported widely across available tool chains. > I'm just curious if there are some reasons for not using march=amrv7a > for armv7 platforms and don't want to start a discussion about removing > that default. Well, a major reason for not doing this is that "amrv7a" is a typo :-P Other reasons are for example explained in doc/README.omap3 or doc/README.s5pc1xx Best regards, Wolfgang Denk
Dear Raghuveer Murthy, In message <1298042212-12260-1-git-send-email-raghuveer.murthy@ti.com> you wrote: > U-boot built for MeeGo on PandaBoard, with compiler option > -mfloat-abi=hard, caused a build break. Please refer to the bug id: > > http://bugs.meego.com/show_bug.cgi?id=13140 > > Removing the -msoft-float options in the config.mk files, allowed it > to be built for both armv7hl and armv7el compilers on MeeGo > > Please refer to the below link for more details: > http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal > > Signed-off-by: Raghuveer Murthy <raghuveer.murthy@ti.com> > --- > arch/arm/cpu/armv7/config.mk | 2 +- > arch/arm/cpu/armv7/omap-common/config.mk | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) After we had just another round of these discussions I thing we have again found an agreement that there are good reasons for using -msoft-float. I hereby reject your patch. If you have problems with your tool chain, please feel free to use the U-Boot provided libgcc functions instead (by providing USE_PRIVATE_LIBGCC=yes on the command line) or even your private libgcc code (by providing USE_PRIVATE_LIBGCC=directory_with_your_lib on the command line). Or fix your tool chain so it provides a soft-float version of the needed library routines, too. Best regards, Wolfgang Denk
Hello, Am 19.02.2011 18:48, schrieb Albert ARIBAUD: > You're missing the fact that floating point code is a no-no in U-Boot. > We're not talking about the best option to support floating-point code > in U-Boot, but the best option to catch the use of floating point. Please don't turn the words in my mouth. Anyway, I now know why -msoft-float is used. Regards, Alexander
On Sunday 20 February 2011 01:25 AM, Wolfgang Denk wrote: > Dear Raghuveer Murthy, > > In message<1298042212-12260-1-git-send-email-raghuveer.murthy@ti.com> you wrote: >> U-boot built for MeeGo on PandaBoard, with compiler option >> -mfloat-abi=hard, caused a build break. Please refer to the bug id: >> >> http://bugs.meego.com/show_bug.cgi?id=13140 >> >> Removing the -msoft-float options in the config.mk files, allowed it >> to be built for both armv7hl and armv7el compilers on MeeGo >> >> Please refer to the below link for more details: >> http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal >> >> Signed-off-by: Raghuveer Murthy<raghuveer.murthy@ti.com> >> --- >> arch/arm/cpu/armv7/config.mk | 2 +- >> arch/arm/cpu/armv7/omap-common/config.mk | 2 +- >> 2 files changed, 2 insertions(+), 2 deletions(-) > > After we had just another round of these discussions I thing we have > again found an agreement that there are good reasons for using > -msoft-float. > > I hereby reject your patch. > > If you have problems with your tool chain, please feel free to use > the U-Boot provided libgcc functions instead (by providing > USE_PRIVATE_LIBGCC=yes on the command line) or even your private > libgcc code (by providing USE_PRIVATE_LIBGCC=directory_with_your_lib > on the command line). > > Or fix your tool chain so it provides a soft-float version of the > needed library routines, too. > > Best regards, > > Wolfgang Denk > Acknowledge the comments. Thanks for you time. Regards, Raghuveer
diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk index 49ac9c7..07f92a8 100644 --- a/arch/arm/cpu/armv7/config.mk +++ b/arch/arm/cpu/armv7/config.mk @@ -20,7 +20,7 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # -PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float +PLATFORM_RELFLAGS += -fno-common -ffixed-r8 # Make ARMv5 to allow more compilers to work, even though its v7a. PLATFORM_CPPFLAGS += -march=armv5 diff --git a/arch/arm/cpu/armv7/omap-common/config.mk b/arch/arm/cpu/armv7/omap-common/config.mk index 49ac9c7..07f92a8 100644 --- a/arch/arm/cpu/armv7/omap-common/config.mk +++ b/arch/arm/cpu/armv7/omap-common/config.mk @@ -20,7 +20,7 @@ # Foundation, Inc., 59 Temple Place, Suite 330, Boston, # MA 02111-1307 USA # -PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float +PLATFORM_RELFLAGS += -fno-common -ffixed-r8 # Make ARMv5 to allow more compilers to work, even though its v7a. PLATFORM_CPPFLAGS += -march=armv5
U-boot built for MeeGo on PandaBoard, with compiler option -mfloat-abi=hard, caused a build break. Please refer to the bug id: http://bugs.meego.com/show_bug.cgi?id=13140 Removing the -msoft-float options in the config.mk files, allowed it to be built for both armv7hl and armv7el compilers on MeeGo Please refer to the below link for more details: http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal Signed-off-by: Raghuveer Murthy <raghuveer.murthy@ti.com> --- arch/arm/cpu/armv7/config.mk | 2 +- arch/arm/cpu/armv7/omap-common/config.mk | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)