[U-Boot-Users] U-Boot-NG ?

Ulf Samuelsson ulf at atmel.com
Thu Jul 5 00:25:04 CEST 2007


> in message <20070704184312.GI25364 at pengutronix.de> you wrote:
>>
[snip]
> 
>> We agree on the fact that it is a pretty good feature to have early
>> debugging, even before anything else works. It's just that, at the
>> moment, it has the implication that the whole inner mechanics of u-boot
>> cannot follow a simple device model, as proposed by our v2 code.
> 
> I wouldn't go as far as to say that. Maybe if  the  one-size-fits-all
> approach  does not work (at least not without hurting), then there is
> still potential for a _compatible_  second  approach?  Who  says  the
> "first  step"  *must*  be  as  small  as  4  kB,  and  *must* be in a
> separately linked image, and *must* not link higher  level  functions
> from  the  "real"  U-Boot?  Maybe  both is possible, so everybody can
> select the config he likes and be happy?
> 
> The thing is that there are many requirements which are pretty
> complicated and sometimes contradicting:
> 
> - systems booting from NAND or dataflash etc. may require a very small
>  primary bootstrap loader
> - systems with very limited resources may need a primary bootstrap
>  loader that unpacks the compressed U-Boot image
> - dynamic switching of the console device may require early access to
>  the device tree
> - allowing for a configurable console baudrate or for software-
>  adjustable CPU clock rates may require early access to the
>  environment
> etc. etc.
> 


Size can be one of the more important parameters.
The AT91SAM9260 BootROM loads the bootstrap into internal SRAM,
and this is limited to 4 kB.

If I look through the code, I see that this contains a lot of AT91 specific
stuff, and not so much generic stuff.

The bootstrap should avoid loading a non working image.
In the AT91 bootstrap the exception vector table is disassembled
and only if 7 out of 8 vectors contain branch/jump instructions,
is the image considered valid.

This is not going to work on a non-arm target.

Personally I do not see a need to reconfigure the BAUD rate for AT91 at least.
The bootrom will set the BAUD rate to 115,200 and you will not be able
to program the device over the serial port if you do not support this baud rate
in your host. If you do, there is no reason not to use 1152000.

Do we really want to have a common bootstrap source code base, 
or do we just define what the bootstrap needs to do before U-Boot is loaded
into SDRAM?


Best Regards
Ulf Samuelsson





More information about the U-Boot mailing list