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

[Ulf Samuelsson <ulf@atmel.com>]

> 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