[U-Boot-Users] decrease boot time

[Grant Likely]

On Fri, 11 Feb 2005 23:30:35 +0100, Konstantin Kletschke
<lists at ku-gbr.de> wrote:
> 
> Hi Folks!
> 
> I am trying to improve boot time of my linux system on my motorola i.MX
> system as much as possible. Therefore I tried to omit the copying and
> decompressing the linux kernel image ba using XIP, but the code runs
> slower in the (slower) flash and boot time increased.

Where are your bottlenecks?  What is your target boot time?

> 
> I wonder how to make use of sync burst mode with u-boot in conjunction
> eith linux. Today I switched on CFG_CMD_CACHE (I use u-boot-1.1.1) but I
> wonder if u-boot knows that it should cache the area above 0x10000000.
> 
> Hm... I think the way the linux kernel starts itself is not making use
> of any implementation of burst mode of the flash device. It copies a
> small amount of bytes and decompresses them.
> Could it be possible to make use of burst mode by copying the compressed
> image into RAM by u-boot (i.e. bursting) and start the kernel in RAM
> then? The decompressing and copying would be faster then...

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)

However, since the cache is enabled at this point, won't your chip
perform a burst read to fill each dcache line regardless of the fact
that you'll be reading only one byte at a time?  (I may be talking out
of my butt here; I'm not familiar with the i.MX chips)

> 
> How do I disable serial support in u-boot? My u-boot is currently 60k
> big, in my opinion a simple bootloader which does something like
> memsetup and starting kernel afterwards should not be much bigger than
> 10k. Or is that wrong?
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.

If boot time is that critical, you specify the boot parameters in the
kernel .config and write an assembly boot routine that only
initialized SDRAM, initializes registers to a sane state and jumps to
the kernel.  That could probably be done in one assembler routine at
<1K.

Of course, you would lose any ability to load new code on the board
without a debugger.  It all depends on what features you need.  :-)

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
safe to assume that you've got a 'boot loader' flash device with a
small first (~16k)?  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.

Cheers,
g.