From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ulf Samuelsson Date: Mon, 26 Mar 2007 18:29:07 +0200 Subject: [U-Boot-Users] New version of AT91-BootstrapforAT91SAM92xU-Boot/Buildroot/Linux users References: <20070326143501.7D72D35261B@atlas.denx.de> Message-ID: <000401c76fc4$0b23fed0$2501a8c0@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de >> 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. > > All understood. And I asked if it was possible to integrate it like > NAND boot support for other boards is directly supported within > U-Boot. > It is, but right now, I am integrating it in buildroot as a separate project. >> 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. > > You think it's a lot of effort? Just adding at91-bootstrap as is, without integrating with code could be very little effort. On the other hand, I tried recently to merge two files into one, and then split the merged file into two parts. That was a much simpler effort that cost me a lot of time. After 50 emails, nothing happened. You get burned by that... Making it share common source files with u_boot is a lot bigger effort, which I am not prepared to take on right now. > >> 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. > > What a pitty... I think a lot more people would appreciate a decent AT91 support in U-boot. This is really lacking... >> Would a patch which simply removed the -msoftfloat be acceptable? > > Why should we remove it when no FP is used? Why should it be there. If there is no floating point in U-Boot, why should U-Boot have an opinion on how the toolchain handles floating point. If you do not have "-msoftfloat" in the ARM specific directories, how will that hurt a U-Boot developer? I doubt it will generate more code... It is just a nuiscance at the moment. > I think this is primarily a toolchain issue, and the tools should be > fixed. But of course there may be buggy code in the ARM port that > triggers the use of FP instructions - then this should be located and > cleaned up, too. No, I don't think so, I believe the ARM gcc has an option, determined when you create the compiler to either generate * soft floating point, or * NWFPE floating point emulation Once you have a NWFPE toolchain, then it will balk at beeing supplied "-msoftfloat". The proposed patch will ONLY affect files under cpu/arm920t and cpu/arm926ejs, and will not affect other architecture. Best Regards Ulf Samuelsson