[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92x U-Boot/Buildroot/Linux users

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92x U-Boot/Buildroot/Linux users

[Ulf Samuelsson]

I have done some modification of AT91-Bootstrap and this
version is now available at www.at91.com in the
"AT91 Buildroot" project. Also put a patch there,
which is a merger of AVR32/AT91 patches for Linux-2.6.20.4

The merged patch was generated by patching 2.6.20.4 with the
* maxim.org.za/at91_26.html
* AVR32 patches from avr32linux.org
* Experimental patches from www.at91.com
The main conflict was in the driver/spi/atmel_spi.c.

AT91-Bootstrap or similar is needed if you want to load U-Boot
from Dataflash or NAND flash.  Note that this is an
unofficial version, and is not supported by Atmel.

The major change I have done is to add a few subroutines
to allow the at91-bootstrap to build without a C library.
(memset,memcpy,udiv) - udiv() is an unsigned version of div()

Previous versions had to be built using a statically linked
C library, making it unfriendly to buildroot, as well as
to the "supported" TimeSys gcc compilers.

If you use this version, You should be able to be built by any
gcc compiler including those found at www.timesys.com and
the compilers generated by buildroot.

The Makefile has undergone drastic changes to allow easy use.

Instead of walking down a directory tree and make
the file at the bootom of the tree,
you configure AT91-Bootstrap before use

----------------------------------------------------------
$ make at91sam9260ek_defconfig
$ make

should be enough to build the (default) dataflash version
for at91sam9260.

----------------------------------------------------------
$ make MEMORY=NANDFLASH at91sam9260ek_defconfig
$ make

should build the NAND flash version

----------------------------------------------------------
at91-bootstrap supports

at9sam9260ek	dataflash and NAND flash
at9sam9261ek	dataflash and NAND flash
at9sam9263ek	dataflash

----------------------------------------------------------
If you want a toolchain that builds at91-bootstrap you can do

$ make toolchain	# downloads buildroot and builds gcc
$ source gcc-2.4.6-uclibc.sh
$ make at91sam9260ek_defconfig
$ make

This will take some time though (1-2 hours)...

----------------------------------------------------------
./MAKEALL

will download buildroot and build a gcc-3.4.6/binutils 2.16.1
toolchain and continue to build all version of at91-bootstrap.

Has only been tested to run under Linux (OpenSuse 10.1)


-- 
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:
AT90 AVR Applications Group: mailto:avr at atmel.com
AT91 ARM Applications Group: mailto:at91support at atmel.com
links: www.avrfreaks.net; www.at91.com; avr32linux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070325/e0cca06f/attachment.vcf 

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92x U-Boot/Buildroot/Linux users

[Ulf Samuelsson]

Ulf Samuelsson skrev:
> I have done some modification of AT91-Bootstrap and this
> version is now available at www.at91.com in the
> "AT91 Buildroot" project. Also put a patch there,
> which is a merger of AVR32/AT91 patches for Linux-2.6.20.4
> 

FYI: YOu have to select "PRODUCTS"->"SAM9261" or similar
to find the project.
It is not visible on the "PROJECTS" list for some reason.

-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070325/a5486c91/attachment.vcf 

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92x U-Boot/Buildroot/Linux users

[Wolfgang Denk]

In message <460698B9.6030801@atmel.com> you wrote:
>
> I have done some modification of AT91-Bootstrap and this
> version is now available at www.at91.com in the
> "AT91 Buildroot" project. Also put a patch there,

I'm not sure why you are posting this here.

If this is in any way related to U-Boot, please follow the rules as
laid down in http://www.denx.de/wiki/UBoot/Patches

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
So we follow our wandering paths, and the very darkness acts  as  our
guide and our doubts serve to reassure us. - Jean-Pierre de Caussade,
eighteenth-century Jesuit priest

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users

[Ulf Samuelsson]

>> I have done some modification of AT91-Bootstrap and this
>> version is now available at www.at91.com in the
>> "AT91 Buildroot" project. Also put a patch there,
> I'm not sure why you are posting this here.
>
> If this is in any way related to U-Boot, please follow the rules as
> laid down in http://www.denx.de/wiki/UBoot/Patches

It is not part of U-Boot, but is definitely related.
It is a utility which resided in the first sector(s) of a dataflash or NAND 
flash.
At reset, the AT91 bootROM loads this into internal SRAM and jump to the
beginning of the SRAM, starting executing at91-bootstrap.

At91-bootstrap configures the DRAM memory and a few other things
and then loads U-Boot from data/NAND flash to SDRAM
and starts executing U-Boot.
Reason for not putting this inside the U-Boot is that due to H/W
restrictions (internal SRAM size), the max size of the program is 4 kB.

There is a lot of AT91/U-Boot users, having
problems with having to have a special compiler
for this little application, so I thought they would be interested.

It could of course be in the tools directory.



Best Regards
Ulf Samuelsson

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users

[Wolfgang Denk]

In message <012f01c76f20$a7225470$01c4af0a@Glamdring> you wrote:
>
> At91-bootstrap configures the DRAM memory and a few other things
> and then loads U-Boot from data/NAND flash to SDRAM
> and starts executing U-Boot.

...in other words the normal bootstrap loaer code as used with other
NAND boting systems, too.

> Reason for not putting this inside the U-Boot is that due to H/W
> restrictions (internal SRAM size), the max size of the program is 4 kB.

I'm sorry, but I cannot understand this argument. Because the code is
so small you cannot put it into the U-Boot tree? That makes no sense
to me.

To code used for NAND booting for example on PPC 4xx systems has size
limitations, too, but we keep this all in nand_spl/

Maybe you could merge your code into this common infrastructure, too?
Please feel free to discuss details with the NAND custodian.

> There is a lot of AT91/U-Boot users, having
> problems with having to have a special compiler
> for this little application, so I thought they would be interested.

Why do you need a special compiler?

> It could of course be in the tools directory.

No, that would be definitely the wrong place.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Anyone who doesn't believe in miracles is not a realist.
                                                   - David Ben Gurion

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users

[Ulf Samuelsson]

Wolfgang Denk skrev:
>> Reason for not putting this inside the U-Boot is that due to H/W
>> restrictions (internal SRAM size), the max size of the program is 4 kB.
> 
> I'm sorry, but I cannot understand this argument. Because the code is
> so small you cannot put it into the U-Boot tree? That makes no sense
> to me.

It can be put in the u-boot tree, but it needs to be a separate binary
OR
someone needs to figure out how to make a multi-image binary
out of u-boot, and fit the complete at91-bootstrap functionality
into the first 4 kB AND make sure that multi-image binary starts with
a valid ARM exception table in the first 32 bytes of the binary (this is
how the presence of the at91-bootstrap is detected by the AT91 bootROM)

All in all, I think it may be a lot easier to keep it as a separate binary.

> 
> To code used for NAND booting for example on PPC 4xx systems has size
> limitations, too, but we keep this all in nand_spl/

Where would you suggest it should be?
Don't forget that the code supports dataflash as well.
The same source will cover several boards, all using
chips based on ARM926EJS (At the moment).
There is a variant for the AT91RM9200 using I2C EEPROM
but it is not using the same code base.
Maybe in the future, AVR32 chips will use the same code.

Maybe "board/atmel/at91-bootstrap" is a good location.
Maybe a completely new directory "boot/atmel/at91-bootstrap".


> Maybe you could merge your code into this common infrastructure, too?
> Please feel free to discuss details with the NAND custodian.

Yes, but there are other things which has priority, like
adding existing patches for the SAM926x chips/boards.
Pls note, that there is no room for bloating this specific code.


>> There is a lot of AT91/U-Boot users, having
>> problems with having to have a special compiler
>> for this little application, so I thought they would be interested.
> 
> Why do you need a special compiler?
> 

Because the guys writing the original package did not include
memset, memcpy, div routines, and thus needs to link with the C library.
The C compiler used, must have a statically linked C-library.

The "normal" compiler recommended by Atmel, is the LinuxLink
toolsets from TimeSys, which cannot compile this.
Quite a lot of users, also use a compiler built when making "buildroot".

For this purpose I consider everything else "special"
I am not implying that having a static C library is esoteric in itself.

My goal is to have a single toolset which can build the complete
functionality of a Linux Board.
This can be the compilers above, ELDK or whatever.

The TimeSys compilers cannot build U-Boot as well, since -msoftfloat is
hard-coded. I have this as a configuration item in my private u-boot
so I can use a "normal" compiler.


>> It could of course be in the tools directory.
> 
> No, that would be definitely the wrong place.
> 


> Best regards,
> 
> Wolfgang Denk
> 


-- 
Best Regards,
Ulf Samuelsson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 313 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070326/97614e79/attachment.vcf 

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users

[Wolfgang Denk]

In message <4606F35B.70603@atmel.com> you wrote:
>
> It can be put in the u-boot tree, but it needs to be a separate binary

Did you have a look how this is handled in other  architectures,  for
example PPC?

> All in all, I think it may be a lot easier to keep it as a separate binary.

OK.

But this is unrelated to my original question.

> > To code used for NAND booting for example on PPC 4xx systems has size
> > limitations, too, but we keep this all in nand_spl/
> 
> Where would you suggest it should be?

I just did that.

> Don't forget that the code supports dataflash as well.

Either we accept that nand_spl/ will then be a  slight  misnomer,  or
you come up with a more sutable name when you add your code.

> The same source will cover several boards, all using
> chips based on ARM926EJS (At the moment).

We already support several boards this way.

> Maybe "board/atmel/at91-bootstrap" is a good location.
> Maybe a completely new directory "boot/atmel/at91-bootstrap".

No,  I  disagree.  There  will  be  areas  of  similar  code   across
architectures;  if really needed, a new nand_spl/cpu/ direcotry would
make more sense to me than distributing the code  across  the  board/
ana^H^H^Hhierarchy.

> > Maybe you could merge your code into this common infrastructure, too?
> > Please feel free to discuss details with the NAND custodian.
> 
> Yes, but there are other things which has priority, like
> adding existing patches for the SAM926x chips/boards.
> Pls note, that there is no room for bloating this specific code.

Fine. Just don't add bloat to your code, then ;-)

> > Why do you need a special compiler?
> 
> Because the guys writing the original package did not include
> memset, memcpy, div routines, and thus needs to link with the C library.
> The C compiler used, must have a statically linked C-library.

I cannot parse that. U-Boot and/or the GCC compiler will provide  all
such required functions. What exactly is the problem?

> The "normal" compiler recommended by Atmel, is the LinuxLink
> toolsets from TimeSys, which cannot compile this.

That's their problem, then.

> Quite a lot of users, also use a compiler built when making "buildroot".

And why doesn't it work in a U-Boot context?

> For this purpose I consider everything else "special"
> I am not implying that having a static C library is esoteric in itself.

I don't understand what you mean.

You see, U-Boot is self contained. Any correctly configured and some-
what decent version of GCC should be able  to  build  U-Boot  without
problems.  Your code should be able to fit into this environment too,
if what you listed above whas the only problem.

> My goal is to have a single toolset which can build the complete
> functionality of a Linux Board.
> This can be the compilers above, ELDK or whatever.
> 
> The TimeSys compilers cannot build U-Boot as well, since -msoftfloat is
> hard-coded. I have this as a configuration item in my private u-boot
> so I can use a "normal" compiler.

Maybe this is something that TS could fix? In other words, a SEP?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Experience is what causes a person to make new  mistakes  instead  of
old ones.

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users

[Andreas Schweigstill]

Hello!

Wolfgang Denk schrieb:
>> There is a lot of AT91/U-Boot users, having
>> problems with having to have a special compiler
>> for this little application, so I thought they would be interested.
> 
> Why do you need a special compiler?

The primary bootloader code from Atmel can only be compiled with ARM
ADS/RVDS but can't be compiled with GCC because of incompatible
assembler parts and linker symbols. There is some port for GCC but it
(http://www.teest.com/) but that is not supported officially by Atmel
and it uses g++ to compiler "pseudo-C++". And for proper function the
omitted bss initialization has to be added... I have done a conversion
to proper C code and also lots of enhancements but these will be
published when the final product will be released.

With best regards
Andreas Schweigstill

-- 
Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra?e 116, D-24118 Kiel, Germany
Phone: (+49) 431 5606-435, Fax: (+49) 431 5606-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users

[Ulf Samuelsson]

Andreas Schweigstill skrev:

> The primary bootloader code from Atmel can only be compiled with ARM
> ADS/RVDS but can't be compiled with GCC because of incompatible
> assembler parts and linker symbols. There is some port for GCC but it
> (http://www.teest.com/) but that is not supported officially by Atmel
> and it uses g++ to compiler "pseudo-C++". And for proper function the
> omitted bss initialization has to be added...
[snip]
> 
> With best regards
> Andreas Schweigstill
> 

Not completely true,
For the AT91RM9200, the dataflashboot was built for ARM ADS
and the same for boot.bin/loader.bin used to handle parallel flash
memories.

Someone ported dataflashboot.bin to gcc and put it on the www.at91.com
and I have used that for my "dataflashboot-1.05.bin" which compiles by gcc.

For the AT91SAM926xEK you use at91-bootstrap and it is recommended that
you compile this by a gcc using newlib from www.gnuarm.com.

Since I am using buildroot, I want everything to compile using uclibc,
NWFPE and a dynamic C library.
softfloat is nice, but there are very few gcc compiler versions which
supports it for ARM.


-- 
Best Regards,
Ulf Samuelsson

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ulf.vcf
Type: text/x-vcard
Size: 301 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070326/b254f420/attachment.vcf 

[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users

[Wolfgang Denk]

In message <4606F5D2.4060005@atmel.com> you wrote:
>
> Since I am using buildroot, I want everything to compile using uclibc,
> NWFPE and a dynamic C library.

Please correct me if I'm wrong, but we are talking about a < 4kB
standalone NAND / dataflash bootstrap loader here, right?

I don't think you use *any* of NWFPE or uclibc specific code in it,
nor any "dynamic C library". 


Requiring to use "uclibc, NWFPE and a dynamic C library" for  such  a
piece of code seems fundamentally broken to me.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Hegel was right when he said that we learn from history that man  can
never learn anything from history.              - George Bernard Shaw

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

[Ulf Samuelsson]

> In message <4606F5D2.4060005@atmel.com> you wrote:
>>
>> Since I am using buildroot, I want everything to compile using uclibc,
>> NWFPE and a dynamic C library.
>
> Please correct me if I'm wrong, but we are talking about a < 4kB
> standalone NAND / dataflash bootstrap loader here, right?
>
> I don't think you use *any* of NWFPE or uclibc specific code in it,
> nor any "dynamic C library".
>
>
> Requiring to use "uclibc, NWFPE and a dynamic C library" for  such  a
> piece of code seems fundamentally broken to me.
>

The requirement is not that at91-bootstrap must use this.
The requirement is that it is *able* to be built by this.


I am using buildroot with extensions, and my requirement is that
I want to have one single package, which can as output generate

* Single Cross Compiler able to build all things below
* Standalone NAND/Dataflash bootloader
* U-Boot
* Linux Kernel
* Root File System

The Linux kernel is built using NWFPE, uclibc and dynamic C library.
Thus I need to be able to use the same toolchain for the rest to fulfil the 
goal.

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 .

The new at91-bootstrap, with those routines can be built
* using NWFPE or softfloat - did not matter in the old version either
* static or dynamic c  library - old version HAD to have a static library
* cross-compiler compiled for uclibc, glibc or newlib

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.

Due to dataflash sector boundaries, the natural size for U-Boot + Loader is
256 kB or less. I did not check the effect on U-Boot code size
due to NWFPE enabled, but there should be little or none FPU code
in U-Boot.

It is more important to me to have a single toolchain, and it will be
Linux needs which determines the toolchain.

> Best regards,
>
> Wolfgang Denk
>
> -- 


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 

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

[Wolfgang Denk]

In message <00a001c76f77$382b4660$01c4af0a@Glamdring> you wrote:
>
> > Requiring to use "uclibc, NWFPE and a dynamic C library" for  such  a
> > piece of code seems fundamentally broken to me.
> 
> The requirement is not that at91-bootstrap must use this.
> The requirement is that it is *able* to be built by this.

If you don't use feature F it should not get in your  way.  The  fact
that  I  have  installed  certain libraries here and there should not
matter as long as your linker step / script does not  pick  up  these
libs.

> I am using buildroot with extensions, and my requirement is that
> I want to have one single package, which can as output generate
> 
> * Single Cross Compiler able to build all things below
> * Standalone NAND/Dataflash bootloader
> * U-Boot
> * Linux Kernel
> * Root File System

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.

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

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

> Due to dataflash sector boundaries, the natural size for U-Boot + Loader is
> 256 kB or less. I did not check the effect on U-Boot code size
> due to NWFPE enabled, but there should be little or none FPU code
> in U-Boot.

Consider any code that uses FP to be broken.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Life is a process, not a principle, a mystery  to  be  lived,  not  a
problem to be solved. - Gerard Straub, television producer and author
(stolen from Frank Herbert??)

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

[Ulf Samuelsson]

> 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 

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

[Wolfgang Denk]

In message <012301c76fa8$4f613cf0$01c4af0a@Glamdring> you wrote:
>
> 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 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?

> 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 do not see why U-Boot should require a softfloat compiler
> when no floating point is used though!

I'm not sure that htis is  indeed  the  case.  I  just  said  that  I
consider the use of FP code in U-Boot a bug.

> Would a patch which simply removed the -msoftfloat be acceptable?

Why should we remove it when no FP is used?

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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk
Office:  Kirchenstr. 5,       D-82194 Groebenzell,            Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
...computer hardware progress is so fast. No other  technology  since
civilization  began  has seen six orders of magnitude in performance-
price gain in 30 years.                             - Fred Brooks, Jr.

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

[Ulf Samuelsson]

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