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

[Ulf Samuelsson <ulf@atmel.com>]

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