[U-Boot-Users] New version of AT91-Bootstrap for AT91SAM92xU-Boot/Buildroot/Linux users
Wolfgang Denk
wd at denx.de
Mon Mar 26 02:01:00 CEST 2007
In message <4606F35B.70603 at 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.
More information about the U-Boot
mailing list