Current Bootchart / breaking SD boot

Carsten Haitzler (The Rasterman) raster at
Wed Jul 9 12:58:15 CEST 2008

On Wed, 09 Jul 2008 07:54:00 +0100 Andy Green <andy at> babbled:

> Hash: SHA1
> Somebody in the thread at some point said:
> | On Tue, 08 Jul 2008 18:45:33 +0100 Andy Green <andy at> babbled:
> |
> | Somebody in the thread at some point said:
> |
> | |> Otherwise sounds fine to make it a module.  You can't use NFS rootfs on
> | |> it AFAIK due to needing association sorted out first, that was the only
> | |> reason I could think to keep it in monolithic kernel for normal use.
> | |
> | | imho everything we can make a module - should be. sd card drivers,
> all fs
> | | handling other than jffs2, sysfs and procfs, wifi, etc. etc.
> | |
> | | yes - you can't  boot the sd kernel off sd card then with rootfs
> | there, but
> | | root on sd is not something our production systems need. we can
> change the
> | | packaging to build 2 kernels, 1 modular, 1 monolithic for kernel devs to
> | | quickly test things with.
> |
> | That doesn't make any sense, SD card boot is really valuable and even
> | appears in the U-Boot menu, what's the point of breaking it?  SD Card
> | boot is very nice for customers and definitely not some weird low level
> | thing.
> |
> |> 1. we dont ship with that uboot menu - or we shouldnt be. the uboot
> env i know
> |> we ship waits 3 seconds then just boots.
> Wrong.

every freerunner i have seen except 1 when you power button displays a splash
then 3 seconds later just boots. it does not, by default, display the boot menu.

> |> 2. if users really want it they can use the monolithic kernel. thats
> why i said
> |> we build different images. one that is streamlined for fast boot -
> everything is
> |> a module where we can manage it to avoid having to wait for things
> like sdio
> |> init, wlan init etc. before even starting to run userspace init.
> Did you see the last bootchart?  Is everyone focused on the 6 seconds
> possible flab in kernel and kneecapping the device therefore because of
> the sheer impossibility of doing anything else about the other two
> minutes bringing userspace stuff up?

yes - i did. say both of them. our kernel takes as long to just start init as
my motorola rokr e6 (also linux using qt embedded) takes to boot all the
way to the gui. that alone says to me "my god we have a lot of fat to cut in
the kernel). just putting everything in a monolithic kernel is a huge reason
for this.

of course we will look at the rest of userspace, but that doesn't mean we
should just ignore the kernel.

> |> 3. why is it nice? seriously how may customers do u expect to boot
> off sd card.
> |> i have in fact never booted off sd card for example. i know some
> people do -
> |> like you, thus provide images for them that can do it - for the rest,
> move sd
> |> to a module.
> I guess I failed to check if you did it before I started doing it months
> ago and found it was nice.  I explained a very strong reason --->

i know you do it. this is one of the reasons our production systems will never
improve - you never feel the pain of them as you always are doing something
different. if you had to suffer from the same boot time as the rest of us every
day... many times a day, you'd be thinking differently about the sdio driver
built into the kernel - along with everything else. i'm just trying to point
out that we should be optimising for the production use-case, not for a
debug/kernel hacker mode. if we can get sdio up in much less time, then it's
not much of a harm to still be there.

> | For example, customers can choose to give community builds a test run
> | like that without nuking the NAND with it.  Of course it should not be
> | broken in normal builds.
> |
> | -Andy
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora -
> iEYEARECAAYFAkh0YIIACgkQOjLpvpq7dMrfFQCeNrdl1Q5LmmQDj2xKNm6GX6x7
> bwMAmwXcjUOzEkX4AjiNA6qB4VGKcWJc
> =NYWy

Carsten Haitzler (The Rasterman) <raster at>

More information about the openmoko-devel mailing list