From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Mon, 26 Mar 2007 15:07:12 +0200 Subject: [U-Boot-Users] New version of AT91-BootstrapforAT91SAM92xU-Boot/Buildroot/Linux users References: <20070326114224.AF67D353C9A@atlas.denx.de> Message-ID: <012301c76fa8$4f613cf0$01c4af0a@Glamdring> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > As meantioned a couple times before, U-Boot is self-contained, i. e. > it does not use any libraries from your development system, except > for those needed and provided by the C compiler. And if the compiler > is sane, there should never be a coflict. > >> The Linux kernel is built using NWFPE, uclibc and dynamic C library. > > I doubt that the Linux *kernel* really uses any of these. All right, sloppy..., the Linux File System, uses this. > >> Not including the C library routines memset, memcpy and div >> *forces* you to use the C library, and you cant have a dynamic loaded >> library in 4 kB, so it has to be static and thus it fails . > > You continue to repeat that argument, and I continue to not being > able to understand it. U-Boot *does* provide all these functions, so > why don't you just use these? We don't need no external C libraries. > I advertised the new AT91-Bootstrap on the list because AT91 u-boot users are probably interested. That does not mean that AT91-Bootstrap has any code sharing with U-boot. It is a self contained package. I used the C - library memory routines from the C compiler which should be equivalent to the U-boot stuff and wrote my own unsigned division routines similar to div_t div(...) - just for fun; If and when at91-bootstrap is provided as a patch to the main u-boot tree, *then* it makes sense to think about merging code , not before. It is a very simple function, and now when it exists, putting a lot of work to merge with U-boot is maybe not cost-effective. Meanwhile, I have plenty of stuff to do, including trying to get AT91SAM926x patches into the main tree so don't expect any at91-bootstrap patch soon. >> The NWFPE issue is with U-Boot. >> U-Boot cannot compile, since it has -msoftfloat hard-wired >> and this is really not neccessary. By removing the -msoftfloat >> you can compile using a NWFPE enabled compiler. > > Why doesn't your NWFPE enabled compiler support this option? Have no clue, and not a lot of time to spend out figuring out why. Removing -msoftfloat from U-boot seems to fix my problem so that is what I am doing. I do not see why U-Boot should require a softfloat compiler when no floating point is used though! Would a patch which simply removed the -msoftfloat be acceptable? Best Regards Ulf Samuelsson ulf at 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 at nto.atmel.com AT90 AVR Applications Group: mailto:avr at atmel.com AT91 ARM Applications Group: mailto:at91support at atmel.com FPSLIC Application Group: mailto:fpslic at atmel.com Best AVR link: www.avrfreaks.net