[U-Boot-Users] decrease boot time

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

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.

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...

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?
I tried to disable serial support but several functions in common/
(serial_get* for example) are calling functions in
cpu/arm920t/imx_serial.c. Do I have to "#ifdef" any occurences of these
functions?

REgards, Konsti


-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Grant Likely]

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.

[U-Boot-Users] decrease boot time

[Wolfgang Denk]

In message <20050211223035.GA10412@ku-gbr.de> you wrote:
> 
> 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

Are you sure that this is where you spend a significant part of  your
boot  time?  I  guess you did run some analysis on which steps of the
boot procedure take how long etc.???

> I wonder how to make use of sync burst mode with u-boot in conjunction

What makes you think that this would solve a problem?

> 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?

Your assumption may be of for "a simple bootloader", but then  U-Boot
is not such a beast.

Also, which problem do you try to solve? Boot time? Image size?

What makes you think that disabling the serial  console  would  solve
either of these problems? [If these actually are problems.]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is a time in the tides of men, Which, taken at its flood, leads
on to success. On the other hand, don't count on it.   - T. K. Lawson

[U-Boot-Users] decrease boot time

[Grant Likely]

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?

[U-Boot-Users] decrease boot time

[Wolfgang Denk]

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=AttachFile&do=get&target=BTWG-Discussion-Plenary2005.pdf



Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"Life sucks, but it's better than the alternative."
- Peter da Silva

[U-Boot-Users] decrease boot time

[Wolfgang Denk]

In message <20050212223026.42454C1430@atlas.denx.de> I wrote:
>
> 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

Here comes the missing attachment...

> 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.

I mean: ..._end_ of each line 

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Real computer scientists don't comment their  code.  The  identifiers
are so long they can't afford the disk space.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: time_log
Type: application/octet-stream
Size: 1428 bytes
Desc: time_log
Url : http://lists.denx.de/pipermail/u-boot/attachments/20050212/b8c05abb/attachment.obj 

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

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

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

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

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

Am 2005-02-12 23:30 +0100 schrieb Wolfgang Denk:

> Do you have console output enabled? If yes,  then  you  can  (1)  get
> pretty reliable timings very easily by just time-stamping the console
> output (even with external tools as you read it rom the serial port),
> and (2) save a LOT of time by disabling it :-)

Yes, I will try that.

> OK - then I recommend to _increase_ teh image size by NOT compressing
> the Linux kernel. This way we get the  fastest  boot  times  on  most
> systems. Also, turn of checksum verification (setenv verify no).

Argh, "setenv verify no" !
Ah, I turned off 

        if (verify) {
                puts ("   Verifying Checksum ... ");
                if (crc32 (0, (char *)data, len) != ntohl(hdr->ih_dcrc)) {
                        printf ("Bad Data CRC\n");
                        SHOW_BOOT_PROGRESS (-3);
                        return 1;
                } 
                puts ("OK\n");
        }

instead and I think this also disables the checksum verification when 
normal booting...

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

Am 2005-02-12 23:52 +0100 schrieb Wolfgang Denk:

> Here comes the missing attachment...

Eheee :) I foret taht also _every_ time :p

> I mean: ..._end_ of each line 

All right!

Konsti



-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

Am 2005-02-12 23:30 +0100 schrieb Wolfgang Denk:

> OK - then I recommend to _increase_ teh image size by NOT compressing
> the Linux kernel. This way we get the  fastest  boot  times  on  most
> systems. Also, turn of checksum verification (setenv verify no).

I forgot this:

What Image should I intend to boot with u-boot?
Wait, the mkImage prog is run with Image instead of zImage, right?
I tried this already a couple of weeks ago, but did not solve problems.
The "Image"? What has to be enabled in u-boot so it gets along with this
type of image?

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Wolfgang Denk]

In message <20050213133143.GC13453@synertronixx3> you wrote:
> 
> Argh, "setenv verify no" !
> Ah, I turned off 
> 
>         if (verify) {

Why modifyiong the code when all youneed to do is set an  environment
variable. Didn't you wonder where the "verify" variable is being set?

> instead and I think this also disables the checksum verification when 
> normal booting...

Yes, it does, but you cannot change behaviour to compare and measure...

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 22 - 24,  Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

[U-Boot-Users] decrease boot time

[Wolfgang Denk]

In message <20050213133833.GE13453@synertronixx3> you wrote:
> 
> What Image should I intend to boot with u-boot?

The output file of your invocation of the "mkimage" command.

> Wait, the mkImage prog is run with Image instead of zImage, right?

If you mean that (1) gzip Image >foo and foo == zImage  and  (2)  you
pass  the  option "-C none" when calling mkimage - then the answer is
yes.

> I tried this already a couple of weeks ago, but did not solve problems.

It did not solve which problems ? ;-)

> The "Image"? What has to be enabled in u-boot so it gets along with this
> type of image?

Nothing has to be added or enabled. Everything is there ready  to  be
used.

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 22 - 24,  Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The marvels of today's modern technology include the development of a
soda can, when discarded will last forever ... and a $7,000 car which
when properly cared for will rust out in two or three years.

[U-Boot-Users] decrease boot time

[Grant Likely]

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.

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

Am 2005-02-13 16:20 +0100 schrieb Wolfgang Denk:

> If you mean that (1) gzip Image >foo and foo == zImage  and  (2)  you
> pass  the  option "-C none" when calling mkimage - then the answer is
> yes.

OK, I will have to look at this and inspect Makefiles.

> 
> > I tried this already a couple of weeks ago, but did not solve problems.
> 
> It did not solve which problems ? ;-)

*errr* _I_ did not solve problems booting uncompressed kernel images,
this time I will get it.

> Nothing has to be added or enabled. Everything is there ready  to  be
> used.

I actually remember wondering over the "if (verify)" but did not have
time to find out the name of the config option :/

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

Am 2005-02-12 23:52 +0100 schrieb Wolfgang Denk:

> Here comes the missing attachment...

This works well enough, thank you very much.
Output is at http://ludenkalle.de/boottime.txt

There are some delays I have in mind to optimize if possible:

0.082 Err:   serial  
0.213 Hit any key to stop autoboot:  0

0.233    Entry Point:  08008000  
0.442 OK  

0.445 Starting kernel ...  
0.445   
0.939 Linux v[...]

This is compressed kernelimage, lets see how an uncompressed behaves...

Regards, Konsti



-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Wolfgang Denk]

In message <20050214121117.GB13736@synertronixx3> you wrote:
> 
> I actually remember wondering over the "if (verify)" but did not have
> time to find out the name of the config option :/

It's not a config option, it's an environment variable,  so  you  can
adjust it at run-time as needed. And it's even documented - see
http://www.denx.de/twiki/bin/view/DULG/UBootEnvVariables

Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 22 - 24,  Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Your csh still thinks true is false. Write to your vendor  today  and
tell them that next year Configure ought to "rm /bin/csh" unless they
fix  their blasted shell. :-)
                 - Larry Wall in Configure from the perl distribution

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

Am 2005-02-14 13:26 +0100 schrieb Konstantin Kletschke:

> This works well enough, thank you very much.
> Output is at http://ludenkalle.de/boottime.txt

This is booting uncompressed kernel:

http://ludenkalle.de/boottime_uc.txt

> 0.082 Err:   serial  
> 0.213 Hit any key to stop autoboot:  0

What is happening here?

> 0.233    Entry Point:  08008000  
> 0.442 OK  

And here? Is the "OK" the last thing u-boot says?
When "Starting kernel ......." comes, is the image copyed already and the dots
visualize decompressing?

> 0.445   
> 0.939 Linux v[...]

This looks better now:

0.233    Entry Point:  08008000  
0.674 OK  
0.674   
0.676 Starting kernel ...  
0.676   
0.690 Linux version 2.6.10-rc2 


Regards, Konstantin Kletschke

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

[U-Boot-Users] decrease boot time

[Wolfgang Denk]

In message <20050214134140.GA24678@synertronixx3> you wrote:
> 
> > 0.082 Err:   serial  
> > 0.213 Hit any key to stop autoboot:  0
> 
> What is happening here?
> 
> > 0.233    Entry Point:  08008000  
> > 0.442 OK  

Loading the image to RAM. Checksum verification?

> And here? Is the "OK" the last thing u-boot says?

No. The "OK" gets printed after successful checksum verification.

> When "Starting kernel ......." comes, is the image copyed already and the dots
> visualize decompressing?

Yes. And this is the last message you'll see from U-Boot.

BTW: You can easily find this out yourself by reading the source code
- "lib_arm/armlinux.c" is just a few lines of code.


Best regards,

Wolfgang Denk

-- 
See us @ Embedded World, Nuremberg, Feb 22 - 24,  Hall 10.0 Booth 310
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I have often regretted my speech, never my silence.

[U-Boot-Users] decrease boot time

[Konstantin Kletschke]

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

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF