[U-Boot-Users] decrease boot time

[Grant Likely <glikely@gmail.com>]

On Sat, 12 Feb 2005 21:05:03 +0100, Konstantin Kletschke
<lists@ku-gbr.de> wrote:
> Am 2005-02-11 16:28 -0700 schrieb Grant Likely:

Please make sure that you include the mailing list when you reply to me.

> 
> > Where are your bottlenecks?  What is your target boot time?
> 
> I think the bottlenecks are the copying routines of kernel and u-boot.
> I need to enable full caching and burst support to make this as fast as
> possible. The Flash device is only 16Bit wide.

You think?  If possible; I would get some hard numbers on your boot
sequence and find out for sure.  You could use a serial protocol
analyser to attach timestamps to the boot logs.  Make sure you're
optimizing the right things.

> 
> > Another option would be to modify the linux boot routine for your
> > purposes.  Look in arch/arm/boot/head.S and arch/arm/boot/misc.c at
> > decompress_kernel().  At this point the caches are on, so you don't
> > need to worry about instruction fetch time for the decompress routine.
> >  You could copy do the copy before the call to decompress_kernel().
> > (Not exactly standard; but an option)
> 
> When the ICache and DCache is switched on at this time already there can
> hardly be any improvement done. I thought the cache is switched on after
> relocating into the RAM. But does the kernel instruct the MMU and Cache
> to cache the Flash Adress area above 0x10000000?
> In my opinion both have to be told to do and I do this in my Flash mtd
> map file via ioremap.cached AFAIK.
> In u-boot I can switch on the MMU and cache also, is this simply working
> by enabling the two CONFIG defines?
I cannot comment on u-boot and the cache, but in the kernel the cache
is turned on before decompression.  Look in
arch/arm/boot/compressed/head.S.  You will see a branch to cache_on at
line 287 before decompress_kernel at line 310.  (2.6.10)  According to
the comment on line 422 the page tables are setup for wherever the
compressed image is; including if it is in FLASH.

> > If all you want is to setup SDRAM and jump into the kernel then u-boot
> > is overkill.  It is all the support for loading images and debugging
> > that makes u-boot useful.  Plus, u-boot handles passing information
> > about the board and boot parameters to the kernel.
> 
> I agree fully. But for now our customer is upset about the 3 seconds to
> boot prompt and we promised him to boot in one second.
To u-boot prompt or to linux prompt?

> Of course it would be better in this case to choose another bootloader
> for that purpose, but I need this stuff running yesterday, so I thought
> stripping here and there a bit is done in a shorter time...
> 
> > If boot time is that critical, you specify the boot parameters in the
> > kernel .config and write an assembly boot routine that only
> 
> Brrr. I am chicken-hearted to do that, I probably will need a week or so
> to implement such a thing.

Well; get out your machete and hack away at u-boot mercilessly; but it
shouldn't be necessary.  Find out exactly where your bottle necks are
and target those areas.
> 
> > Question: Why do you want to disable serial support?  To reduce boot
> > time, to reduce space, or some other reason?  If it's space, is it
> 
> I want to reduce space (less copying time).
> 
> > safe to assume that you've got a 'boot loader' flash device with a
> > small first (~16k)?
> 
> What do you mean by that?
I mean that some flash devices have some small sectors at the
beginning specifically to hold the boot loader.  If you were trying to
save space I wondered if you were trying to fit into a small sector. 
This is often done when FLASH space is at an extreme premium.
> 
> > If it is to reduce time; is serial output really
> > making a significant difference in the boot time?  I would suspect
> > initialization activities would be chewing up a larger percentage of
> > the time.
> 
> Well, I tried the console parameter "quiet" of linux to figure out how
> exepensive in time the console output really is. Booting lastst 2.8s
> instead of 3.1s than. So it is not much, but a bit, since initialing of
> the serial stuff would be omitted.

Linux can spew a lot of log messages; I suspect your time difference
would be more bounded by the baud rate of the port rather than the
serial device driver itself.  U-boot on the other had is quite a bit
quieter.  Disabling serial will not gain you much.  You could simply
replace some or all of the strings with empty quotes in the u-boot
source but I'd be surprised if it was worth it.

Can you bump up your baud rate?