Re: [U-Boot-Users] decrease boot time
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?
In message 528646bc05021213026ed990ce@mail.gmail.com you wrote:
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.
You can do this even without hardware support. Attached below is a trivial expect script which you can use to pipe the output of your terminal program into to get it timestamped. this is not perfect (as it timestamps on the _eond_ of each line), but does it's job in 95% of all cases. See the comment in the script for ow to use it.
In u-boot I can switch on the MMU and cache also, is this simply working by enabling the two CONFIG defines?
Nothing is ever "simply working". You have to understand what you are doing. Reading the README helps.
I cannot comment on u-boot and the cache, but in the kernel the cache is turned on before decompression. Look in
U-Boot always turns on the instruction cache; the conditions for using the data cache are processor dependent - always off on some systems (8xx) or always on on others (like 8240 for example).
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.
It is wise to first measure what you can get before making such promises :-)
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.
This depends on the baud rate, of course. 0.1 ... 0.2 seconds is what I see, too - for 115200 bps.
BTW - did you consider XIP??
It's off topic here (like most of this ;-) but for the sake of completeness: see also
http://tree.celinuxforum.org/CelfPubWiki/BootupTimeWorkingGroup and http://tree.celinuxforum.org/CelfPubWiki/TechConference2005Docs?action=Attac...
Best regards,
Wolfgang Denk
Am 2005-02-12 23:30 +0100 schrieb Wolfgang Denk:
You can do this even without hardware support. Attached below is a trivial expect script which you can use to pipe the output of your terminal program into to get it timestamped. this is not perfect (as it timestamps on the _eond_ of each line), but does it's job in 95% of all cases. See the comment in the script for ow to use it.
This idea was mentioned by Grant also, thanks for that, I did not have such a idea :) Did you forgot the attachement?
Nothing is ever "simply working". You have to understand what you are doing. Reading the README helps.
:) I will read it again.
It is wise to first measure what you can get before making such promises :-)
Yes, I agree, I will try the script thing tomorrow.
This depends on the baud rate, of course. 0.1 ... 0.2 seconds is what I see, too - for 115200 bps.
ok
BTW - did you consider XIP??
Staring a XIP Kernel lasts longer on my board, I don't know exactly why. I have the strange feeling my system does not full bursting. I see the ADV signal after every ~6 BCLKs and there should be exactly 15 more BCLKs to see, where the system should really burst. I think the CPU cancels each burst after the first valid read Datum.
Thanks for the links, I will read this stuff today.
Konsti
Heureka! You know what? The intel K§ flash devices have a flag to change polarity of the WAIT signal, which was wrong! Now I have reasonable signals on the scope!
Am 2005-02-12 23:30 +0100 schrieb Wolfgang Denk:
BTW - did you consider XIP??
Also XIP would save ~400ms know, decompressing and copying is not done and the kernel runs fast enough from flash now!
I am trying to enable xip now.
Regards, Konsti
Am 2005-02-12 14:02 -0700 schrieb Grant Likely:
Please make sure that you include the mailing list when you reply to me.
Oh sorry! I messed up List-Reply and simple Reply again in mutt. Normally I only reply to the mailing list itself :/
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.
Yes, its time now to measure all steps of the boot process exactly. The serial analyzer idea is quite good. Why isn't it mine :)
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.
Yes I see. But I don't understand the assembler code really yet. Do you mean "add r0, r3, r2, lsl #2" by line 422, where addresses above 0x10040000 (there my kernel lives) are added to cacheable area?
To u-boot prompt or to linux prompt?
To linux prompt. I heard from a sony demo where an ARM9 based system starts video encoding one second after power up. I asked in linux-arm-kernel last year and some guy mentioned that. So I thought I could reach the prompt also in one second :/
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.
No I have intel 28F128K3 sync burst Flash which contains even sized 128kB sectors only.
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
T thought also and measured and my result is the same.
Can you bump up your baud rate?
It is at 115200 now, I could bump it but I don't think it will to significant time saving due to the above reasons...
Konsti
On Sun, 13 Feb 2005 14:02:16 +0100, Konstantin Kletschke lists@ku-gbr.de wrote:
Am 2005-02-12 14:02 -0700 schrieb Grant Likely:
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.
Yes I see. But I don't understand the assembler code really yet. Do you mean "add r0, r3, r2, lsl #2" by line 422, where addresses above 0x10040000 (there my kernel lives) are added to cacheable area?
Sorry; I meant line 412. That block of code adds a cache mapping to where the PC is currently running. This means that the compressed image is cached. Note: this cache enable is for uncompressing the kernel; the caches are reconfigured inside the kernel itself.
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
T thought also and measured and my result is the same.
???
Cheers, g.
participants (3)
-
Grant Likely -
Konstantin Kletschke -
Wolfgang Denk