New version of AT91-Bootstrap for AT91SAM92x U-Boot/Buildroot/Linux users
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)
Signature · 19 lines
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://busybox.net/lists/buildroot/attachments/20070325/e0cca06f/attachment.vcf
Ulf Samuelsson skrev:
Quoted 5 lines
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.
Signature · 9 lines
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://busybox.net/lists/buildroot/attachments/20070325/a5486c91/attachment.vcf
Quoted 4 lines · In message <[email protected]> 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
Signature · 6 lines
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
Quoted 7 lines
Quoted 3 lines
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
Quoted 4 lines · 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.
Quoted 2 lines
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.
Quoted 3 lines
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?
Quoted 1 line
It could of course be in the tools directory.
No, that would be definitely the wrong place.
Best regards,
Wolfgang Denk
Signature · 5 lines
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
Wolfgang Denk skrev:
Quoted 6 lines
Quoted 2 lines
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.
Quoted 3 lines
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".
Quoted 2 lines
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.
Quoted 6 lines
Quoted 3 lines
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.
Quoted 10 lines
Quoted 1 line
It could of course be in the tools directory.
No, that would be definitely the wrong place.
Best regards,
Wolfgang Denk
Signature · 9 lines
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
Quoted 2 lines · In message <[email protected]> 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?
Quoted 1 line
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 1 line
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.
Quoted 2 lines
The same source will cover several boards, all using chips based on ARM926EJS (At the moment).
We already support several boards this way.
Quoted 2 lines
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.
Quoted 6 lines
Quoted 2 lines
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 ;-)
Quoted 5 lines
Quoted 1 line
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?
Quoted 2 lines
The "normal" compiler recommended by Atmel, is the LinuxLink toolsets from TimeSys, which cannot compile this.
That's their problem, then.
Quoted 1 line
Quite a lot of users, also use a compiler built when making "buildroot".
And why doesn't it work in a U-Boot context?
Quoted 2 lines
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.
Quoted 7 lines
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
Signature · 5 lines
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
In reply to Wolfgang DenkHello!
Quoted 5 lines · Wolfgang Denk
Quoted 3 lines
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
Signature · 5 lines
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
Andreas Schweigstill skrev:
Quoted 6 lines
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]
Quoted 4 lines
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.
Signature · 10 lines
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
Quoted 3 lines · In message <[email protected]> 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
Signature · 5 lines
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: [email protected] 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
Quoted 8 lines
Quoted 3 lines · In message <[email protected]> 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?
Quoted 7 lines
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.
Quoted 5 lines
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
Quoted 6 lines · In message <00a001c76f77$382b4660$01c4af0a@Glamdring> you wrote:
Quoted 3 lines
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.
Quoted 8 lines
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.
Quoted 1 line
The Linux kernel is built using NWFPE, uclibc and dynamic C library.
I doubt that the Linux *kernel* really uses any of these.
Quoted 3 lines
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.
Quoted 4 lines
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?
Quoted 4 lines
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
Signature · 6 lines
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
Quoted 8 lines
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.
Quoted 1 line
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.
Quoted 9 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 4 lines
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
Quoted 5 lines · 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.
Quoted 2 lines
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?
Quoted 3 lines
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...
Quoted 2 lines
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.
Quoted 1 line
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
Signature · 6 lines
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
Quoted 9 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Quoted 6 lines
Quoted 4 lines
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...
Quoted 3 lines
Quoted 1 line
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.
Quoted 4 lines
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