[U-Boot-Users] New version of AT91-BootstrapforAT91SAM92xU-Boot/Buildroot/Linux users
ulf at atmel.com
Mon Mar 26 15:07:12 CEST 2007
> 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?
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
More information about the U-Boot