[U-Boot-Users] New version of AT91-BootstrapforAT91SAM92xU-Boot/Buildroot/Linux users

[Ulf Samuelsson <ulf@atmel.com>]

>> 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