From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Date: Sat, 12 Feb 2005 14:02:41 -0700 Subject: [U-Boot-Users] decrease boot time In-Reply-To: <20050212200503.GA11316@ku-gbr.de> References: <20050211223035.GA10412@ku-gbr.de> <528646bc05021115281ab37f30@mail.gmail.com> <20050212200503.GA11316@ku-gbr.de> Message-ID: <528646bc05021213026ed990ce@mail.gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Sat, 12 Feb 2005 21:05:03 +0100, Konstantin Kletschke 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?