All of lore.kernel.org
 help / color / mirror / Atom feed
From: r.schwebel@pengutronix.de (Robert Schwebel)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM Machine SoC I/O setup and PAD initialization code
Date: Mon, 26 Jul 2010 08:56:11 +0200	[thread overview]
Message-ID: <20100726065611.GR20855@pengutronix.de> (raw)
In-Reply-To: <AANLkTin=uThThNaUxCP4qEJjO2TYMzpHfmZ6jLokQxCD@mail.gmail.com>

On Mon, Jul 26, 2010 at 10:37:20AM +0900, Magnus Damm wrote:
> On Sat, Jul 24, 2010 at 6:03 AM, Robert Schwebel
> <r.schwebel@pengutronix.de> wrote:
> > kexec is a good idea only in theory. Last time we tried it, it
> > needed something like 6 s additional boot time. Inacceptable - we
> > bring Qt based GUI systems into the application in 6 s, and
> > automotive systems into userspace in 336 ms. Not to mention that the
> > first kernel needs to be brought up as well.
>
> I disagree with your "in theory only" stamp on kexec. I've used kexec
> for rebooting and crash dumping on i386, x86_64, ia64, ARM and SH.

That's a good usecase, I agree.

> The two presentations pointed out earlier in this thread clearly show
> how to build kexec based boot loaders which boot in one second. The
> overhead of kexec itself is almost nothing. I'm sure you can discuss
> the details of the kexec implementation with Eric Biederman if you'd
> like.

We'll re-do the tests, in order to measure some hard facts. It may turn
out that we have learned more things since we made the last numbers :)

> That aside, the 6 s number looks familiar from earlier Barebox
> presentations that I've eyed through before. When did you test it? Do
> you remember what platform and which kernel version? Are you using a
> full Gnome desktop in your boot loader? =)

On MX35 we boot a naked kernel into a custom /sbin/init application in
336 ms with barebox, starting the measurement at the first assembler
instruction which can be influenced in software.

I think it's a question of what you want to have. The 6 s boot is with:

- Barebox from NAND
- booting the kernel from NAND
- kernel config with everything built in which is needed in the system
- init based userspace
- dbus + some related services
- Qt
- system based on ipkg packages

and it is measured up to the point where the qt application is fully
operational.

> From my point of view it always makes sense to optimize the kernel
> boot up time. This because it will improve the start up time of your
> final kernel _and_ your boot loader as well if you use kexec.

Seconded. What can be done in the kernel should be done in the kernel.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2010-07-26  6:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21  8:29 ARM Machine SoC I/O setup and PAD initialization code David Jander
2010-07-21  8:47 ` Russell King - ARM Linux
2010-07-22  2:32   ` Simon Horman
2010-07-22  7:20     ` Russell King - ARM Linux
2010-07-22  7:29       ` Simon Horman
2010-07-22  8:38         ` Magnus Damm
2010-07-22  8:49           ` Eric Miao
2010-07-22  9:01             ` Magnus Damm
2010-07-22  9:02             ` Russell King - ARM Linux
2010-07-22  8:46         ` Russell King - ARM Linux
2010-07-22  9:14           ` Simon Horman
2010-07-24 21:36         ` Grant Likely
2010-07-22  8:16       ` Magnus Damm
2010-07-22 12:10         ` David Jander
2010-07-22 12:35           ` Russell King - ARM Linux
2010-07-22 12:56           ` Mark Brown
2010-07-22 13:31             ` David Jander
2010-07-22 13:54               ` Russell King - ARM Linux
2010-07-23 10:35                 ` David Jander
2010-07-23 13:02                   ` Russell King - ARM Linux
2010-07-22 14:20               ` Mark Brown
2010-07-23 10:18                 ` David Jander
2010-07-23 12:57                   ` Russell King - ARM Linux
2010-07-23 14:17                   ` Mark Brown
2010-07-23 18:38                     ` david at protonic.nl
2010-07-23 19:59                       ` Jason McMullan
2010-07-23 21:03                       ` Robert Schwebel
2010-07-26  1:37                         ` Magnus Damm
2010-07-26  6:56                           ` Robert Schwebel [this message]
2010-07-24 18:50                       ` Mark Brown
2010-07-22 15:00               ` Nicolas Pitre
2010-07-23 10:31                 ` David Jander
2010-07-22 13:41           ` Rob Herring
2010-07-22 21:20 ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100726065611.GR20855@pengutronix.de \
    --to=r.schwebel@pengutronix.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.