[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