[U-Boot-Users] software FP yada yada yada
Howdy,
I've got a 1.1.2 u-boot that someone else set up and configured, and it builds just fine (it doesn't run yet, but that's a different story). It builds with a 3.4.1 gcc toolchain. I'm building for ARM91RM9200DK.
When I got 1.1.4, I get the infamous message about how u-boot needs a software FP whereas my gcc is set up for hardware fp.
What I would LIKE to know is why 1.1.2 builds just fine but 1.1.4 does not.
Any light you can shed would be appreciated.
Thanks,
Matt Gessner Avidyne Corp.
In message 131AF8573CF31945B5B11E4201D3F1E142BA28@mail3.Avidyne.com you wrote:
When I got 1.1.4, I get the infamous message about how u-boot needs a software FP whereas my gcc is set up for hardware fp.
What I would LIKE to know is why 1.1.2 builds just fine but 1.1.4 does not.
There have been so many changes between 1.1.2 and 1.1.4 that it's difficult to tell which specific change causes the problem, but if you check the "make" output you can clearly see where the problem is coming from - your compiler fails to provide the required softfloat routines. Which is kind of funny, since there are not so many ARM systems with FPU around.
My recommendation is to fix the toolchain.
Best regards,
Wolfgang Denk
In message 131AF8573CF31945B5B11E4201D3F1E142BA28@mail3.Avidyne.com you wrote:
When I got 1.1.4, I get the infamous message about how u-boot needs a software FP whereas my gcc is set up for hardware fp.
What I would LIKE to know is why 1.1.2 builds just fine but 1.1.4 does not.
There have been so many changes between 1.1.2 and 1.1.4 that it's difficult to tell which specific change causes the problem, but if you check the "make" output you can clearly see where the problem is coming from - your compiler fails to provide the required softfloat routines. Which is kind of funny, since there are not so many ARM systems with FPU around.
According to the crosstool documentation at www.kegel.com:
Most combinations of gcc 3.x.x and binutils fails when you try to build a softfloat toolchain All tested combinations of gcc-4.x.x and binutils fails if softfloat is enabled. If you want to use gcc 4, you cannot build u-boot as is.
My recommendation is to fix the toolchain
IIRC, An file included by the top makefile defines CFLAGS to include -msoftfloat. Removing -msoftfloat from CFLAGS allows you to build U-boot with your normal compiler. I did that, and u-boot 1.1.4 compiled fine after that.
Personally, I think -msoftfloat should be optional. Before Wolfgang start complaining about bloat, I'd like to point out that due to segment boundaries in the AT45DB642D a total of 256 kB is av ailable for the dataflashboot, u.boot and u-boot environment and it is meaningless to save a byte here and there.
It is worth 10s of kB to be able to use a single toolchain to build u-.boot, Linux and filesystem .
Best regards,
Wolfgang Denk
--
Best Regards Ulf Samuelsson
On Thursday 12 October 2006 15:49, Ulf Samuelsson wrote:
In message 131AF8573CF31945B5B11E4201D3F1E142BA28@mail3.Avidyne.com you
wrote:
When I got 1.1.4, I get the infamous message about how u-boot needs a software FP whereas my gcc is set up for hardware fp.
What I would LIKE to know is why 1.1.2 builds just fine but 1.1.4 does not.
There have been so many changes between 1.1.2 and 1.1.4 that it's difficult to tell which specific change causes the problem, but if you check the "make" output you can clearly see where the problem is coming from - your compiler fails to provide the required softfloat routines. Which is kind of funny, since there are not so many ARM systems with FPU around.
According to the crosstool documentation at www.kegel.com:
Most combinations of gcc 3.x.x and binutils fails when you try to build a softfloat toolchain All tested combinations of gcc-4.x.x and binutils fails if softfloat is enabled. If you want to use gcc 4, you cannot build u-boot as is.
FYI, I have successfully used GCC 4.1.1 and binutils 2.16.1 to build not only a working armv5teb softfloat toolchain (with glibc 2.4 to boot), but also build and use u-boot 1.1.4 and the latest git head with no problems at all.
Granted, I built the toolchain from scratch - it takes a number of tweaks to build correctly, all of which are not in crosstool.
I did notice that the floating point routines used when u-boot is built do not come from gcc, but from the libarm routines in u-boot itself. Some FP division operations (for instance, when dividing a u32 by a float) cause the linker to barf that it's missing a lot of FP routines, but I worked around this by just using integer math (didn't care to fixup the softfloat library in libarm.)
My recommendation is to fix the toolchain
IIRC, An file included by the top makefile defines CFLAGS to include -msoftfloat. Removing -msoftfloat from CFLAGS allows you to build U-boot with your normal compiler. I did that, and u-boot 1.1.4 compiled fine after that.
Personally, I think -msoftfloat should be optional. Before Wolfgang start complaining about bloat, I'd like to point out that due to segment boundaries in the AT45DB642D a total of 256 kB is av ailable for the dataflashboot, u.boot and u-boot environment and it is meaningless to save a byte here and there.
It is worth 10s of kB to be able to use a single toolchain to build u-.boot, Linux and filesystem .
Best regards,
Wolfgang Denk
--
Best Regards Ulf Samuelsson
Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&da... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
According to the crosstool documentation at www.kegel.com:
Most combinations of gcc 3.x.x and binutils fails when you try to build a softfloat toolchain All tested combinations of gcc-4.x.x and binutils fails if softfloat is enabled. If you want to use gcc 4, you cannot build u-boot as is.
FYI, I have successfully used GCC 4.1.1 and binutils 2.16.1 to build not only a working armv5teb softfloat toolchain (with glibc 2.4 to boot), but also build and use u-boot 1.1.4 and the latest git head with no problems at all.
Granted, I built the toolchain from scratch - it takes a number of tweaks to build correctly, all of which are not in crosstool.
Is there any true benefit of using a softfloat toochain? The number of floating point operation is surely minimal in U.boot. Anyone got an idea if there is any code saving.
Best Regards Ulf Samuelsson
On Thursday 12 October 2006 16:44, Ulf Samuelsson wrote:
According to the crosstool documentation at www.kegel.com:
Most combinations of gcc 3.x.x and binutils fails when you try to build a softfloat toolchain All tested combinations of gcc-4.x.x and binutils fails if softfloat is enabled. If you want to use gcc 4, you cannot build u-boot as is.
FYI, I have successfully used GCC 4.1.1 and binutils 2.16.1 to build not only a working armv5teb softfloat toolchain (with glibc 2.4 to boot), but also build and use u-boot 1.1.4 and the latest git head with no problems at all.
Granted, I built the toolchain from scratch - it takes a number of tweaks to build correctly, all of which are not in crosstool.
Is there any true benefit of using a softfloat toochain? The number of floating point operation is surely minimal in U.boot. Anyone got an idea if there is any code saving.
Best Regards Ulf Samuelsson
It's pretty darn minimal in u-boot. If you build Linux with this toolchain however, and have a non-trivial number of floating point operations in your application code, you could end up causing a lot of processor exceptions, which get caught by the kernel and run through the FP emulator. The gist would be that userland code has to do a context switch to the kernel for every FP operation if you build with a hard-float toolchain. With a soft-float toolchain, it stays in userland, and is a bit faster and more efficient (as efficient as soft floating point can be.)
- Brent
On Thursday, October 12, 2006 1:49 PM Ulf Samuelsson wrote:
When I got 1.1.4, I get the infamous message about how u-boot needs
a
software FP whereas my gcc is set up for hardware fp.
According to the crosstool documentation at www.kegel.com:
Most combinations of gcc 3.x.x and binutils fails when you try to
build a > softfloat toolchain
I could successfully build u-boot 1.1.1 and 1.1.4 for ATMEL at91rm9200 CPU with softfloat option using following Kegel combination: gcc-3.4.5-glibc-2.3.6/arm-softfloat-linux-gnu (linux kernel and root file systems are also built and working).
However I could run only u-boot 1.1.1 and that only after change:
==== //depot/L150/uboot/u-boot-1.1.1/include/asm-arm/global_data.h#2 (text) 63a64
#ifdef GD_PTR_IN_REGISTER
64a66,68
#else #define DECLARE_GLOBAL_DATA_PTR extern volatile gd_t *gd #endif
==== //depot/L150/uboot/u-boot-1.1.1/lib_arm/board.c#3 (text) ==== 39a40
volatile gd_t *gd;
Basically, I don't put gd into the register - crosstool somehow doesn't compile it properly (I examined the assembler).
Leonid.
Dear Ulf,
in message 011f01c6ee45$0eefaba0$0d68fe51@atmel.com you wrote:
According to the crosstool documentation at www.kegel.com:
Most combinations of gcc 3.x.x and binutils fails when you try to build a softfloat toolchain All tested combinations of gcc-4.x.x and binutils fails if softfloat is enabled. If you want to use gcc 4, you cannot build u-boot as is.
This is not correct. See for example ELDK 4.0: based on GCC 4.0, based on crosstool, and works just fine :-)
It is worth 10s of kB to be able to use a single toolchain to build u-boot, Linux and filesystem
Agreed. That's how we do it with the ELDK. I don't see why this should be impossible for others.
Best regards,
Wolfgang Denk
Dear Ulf,
in message 011f01c6ee45$0eefaba0$0d68fe51@atmel.com you wrote:
According to the crosstool documentation at www.kegel.com:
Most combinations of gcc 3.x.x and binutils fails when you try to build a softfloat toolchain All tested combinations of gcc-4.x.x and binutils fails if softfloat is enabled. If you want to use gcc 4, you cannot build u-boot as is.
This is not correct. See for example ELDK 4.0: based on GCC 4.0, based on crosstool, and works just fine :-)
I quite often work with customers which has little or no experience with Linux but still wants to start using this for new embedded systems
My goal is to have a customer download a file, decompress it and type make. After that, everything needed to install a demo on a target should be ready.
I have choosen to use "buildroot" as the framework for this.
Buildroot will build the toolchain as part of the build process, so there is no need to download and install a toolchain. Avoiding extra steps like this has high value to me.
It is going to be very complicated to use buildroot with two toolchains and there is of course nothing in buildroot which installs ELDK as the toolset.
I do want to have u-boot built as part of the buildroot make process.
Since most combinations of gcc/binutils fail it is much easier to use a NWFPE version of the compiler also for U-boot.
It is worth 10s of kB to be able to use a single toolchain to build u-boot, Linux and filesystem
Agreed. That's how we do it with the ELDK. I don't see why this should be impossible for others.
Best regards,
Wolfgang Denk
Best Regards Ulf Samuelsson ulf@atmel.com Atmel Nordic AB Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavallerivägen 24, 174 58 Sundbyberg, Sweden Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29 GSM +46 (706) 22 44 57
Technical support when I am not available: AT89 C51 Applications Group: mailto:micro.hotline@nto.atmel.com AT90 AVR Applications Group: mailto:avr@atmel.com AT91 ARM Applications Group: mailto:at91support@atmel.com FPSLIC Application Group: mailto:fpslic@atmel.com Best AVR link: www.avrfreaks.net
Hi Ulf,
On Fri, Oct 13, 2006 at 06:44:07AM +0200, Ulf Samuelsson wrote:
I quite often work with customers which has little or no experience with Linux but still wants to start using this for new embedded systems
Well, I know that it's a common habit of customers out there to expect that with Linux everything works with a click, one doesn't have to learn anything, wants all the features and it shoudl be free of cost of course. Nevertheless, the knowledge has to be somewhere, and until something goes wrong there are OSS projects out there which do both - conserving the knowledge and providing a one-click solution.
My goal is to have a customer download a file, decompress it and type make. After that, everything needed to install a demo on a target should be ready.
We do similar things for our customers' OSELAS.BSP()s. Do you know PTXdist? It was heavily inspired by buildroot when it started in 2002, although had a menuconfig frontend from the beginning and recently evolved into something which is really powerful for that kind of project work.
I have choosen to use "buildroot" as the framework for this.
Buildroot will build the toolchain as part of the build process, so there is no need to download and install a toolchain. Avoiding extra steps like this has high value to me.
Well, you probably don't want to build the toolchain every time you build your rootfs. With PTXdist, building toolchains is just another "project", and "projects" are being built with "ptxdist go" once they have been defined by somebody.
It is going to be very complicated to use buildroot with two toolchains and there is of course nothing in buildroot which installs ELDK as the toolset.
IMHO there is no need for two toolchains. Do your processors have hardware floating point? If not, build everything with a softfloat toolchain. We do that all the time and it works like a charm, up to gcc-4.2 previews.
I do want to have u-boot built as part of the buildroot make process.
With PTXdist, you could simply define an u-boot packet in your project.
Since most combinations of gcc/binutils fail it is much easier to use a NWFPE version of the compiler also for U-boot.
I can imagine only one reason at this moment to use hardware floating point toolchains on ARMs without harware float units: Java. The kaffe vm has still no jit support which works with softfloat/vfp.
Robert
participants (6)
-
Brent Cook -
Leonid -
Matt Gessner -
Robert Schwebel -
Ulf Samuelsson -
Wolfgang Denk