Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
On Sunday 20 February 2011 01:25 AM, Wolfgang Denk wrote: Dear Raghuveer Murthy, In message1298042212-12260-1-git-send-email-raghuveer.mur...@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 Murthyraghuveer.mur...@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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Albert ARIBAUD albert.arib...@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 Murthyraghuveer.mur...@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. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Alexander Holler hol...@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. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Albert ARIBAUD albert.arib...@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. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Le 19/02/2011 15:34, Måns Rullgård a écrit : Albert ARIBAUDalbert.arib...@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, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Albert ARIBAUD albert.arib...@free.fr writes: Le 19/02/2011 15:34, Måns Rullgård a écrit : Albert ARIBAUDalbert.arib...@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. -- Måns Rullgård m...@mansr.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=, In message yw1x7hcw5f6w@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Life would be so much easier if we could just look at the source code. -- Dave Olson ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Albert ARIBAUD, In message 4d5fcaca.1060...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Teenagers are people who express a burning desire to be different by dressing exactly alike. There are some strings. They're just not attached. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Alexander Holler, In message 4d5fce64.8030...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de NOTE: The Most Fundamental Particles in This Product Are Held Together by a Gluing Force About Which Little is Currently Known and Whose Adhesive Power Can Therefore Not Be Permanently Guaranteed. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear =?iso-8859-1?Q?M=E5ns_Rullg=E5rd?=, In message yw1xy65c3xfi@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say I told you so when it doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Alexander Holler, In message 4d5fe485.5030...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The day-to-day travails of the IBM programmer are so amusing to most of us who are fortunate enough never to have been one - like watching Charlie Chaplin trying to cook a shoe. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Raghuveer Murthy, In message 1298042212-12260-1-git-send-email-raghuveer.mur...@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.mur...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Speculation is always more interesting than facts. - Terry Pratchett, _Making_Money_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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.mur...@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(-) 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 -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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 Murthyraghuveer.mur...@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, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC][PATCH] ARMV7: Patch to fix hard float build issues
Dear Raghuveer Murthy, In message 1298042212-12260-1-git-send-email-raghuveer.mur...@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 -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. - Doug Gwyn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
