On Fri, 11 Feb 2005 23:30:35 +0100, Konstantin Kletschke lists@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.