Current Bootchart

[Fred Chien]

Hi All,

I am Fred, a new openmoko guy here.

I have generate a bootchart to show current boot time stuffs, the
attached file is it. It show us the boot time is 2:53 totally right now,
I think we need to find way to improve it.

Also I created a project and put the "bootchart-lite" source code in the
Google Code. Everyone can download it and regenerate the bootchart for
testing.

Here is the project's link:
http://code.google.com/p/bootchart-lite/

Fred.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: bootchart.png
Type: image/png
Size: 76069 bytes
Desc: not available
Url : Loading Image...

[Fred Chien]

after collect informations, we can sum up the most important issues for
boot time:

1. initializing kernel(9 secs)
2. initializing boot splash (exquisite/exquisite-write) (8 secs)
3. udev (udev/udevd) (29 secs)
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Fred.

[Werner Almesberger]

Post by Fred Chien
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Oh, that one's really silly. The ldconfig ought to be done at package
install time, not "just in case someone forgot" at boot time.

- Werner

[Sander van Grieken]

Post by Werner Almesberger

Post by Fred Chien
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Oh, that one's really silly. The ldconfig ought to be done at package
install time, not "just in case someone forgot" at boot time.
- Werner

Maybe that could be made conditional, when mtime of the lib directories is
newer than ld.so.cache ?

grtz,
Sander

[Fred Chien]

Agree Werner. updating "ld.so.cache" at package install time is better.
And someone forgot to do it.

if /etc/ld.so.cache doesn't need to be updated, "ldconfig" will ignore
all checking by itself. The point is rootfs maintainer need to remember
to do this job to avoid taking long time at boot time.

We can save it 18 secs right now! :D

Cheers,
Fred

? ??2008-07-06 ? 10:07 +0200?Sander van Grieken ???

Post by Sander van Grieken

Post by Werner Almesberger

Post by Fred Chien
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Oh, that one's really silly. The ldconfig ought to be done at package
install time, not "just in case someone forgot" at boot time.
- Werner

Maybe that could be made conditional, when mtime of the lib directories is
newer than ld.so.cache ?
grtz,
Sander

[Marek Lindner]

Post by Fred Chien
after collect informations, we can sum up the most important issues for
1. initializing kernel(9 secs)
2. initializing boot splash (exquisite/exquisite-write) (8 secs)
3. udev (udev/udevd) (29 secs)
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Hi Fred,

you chart looks very good !
Holger can help you to make changes in the distro. Graeme had an idea about
udev.


Marek

[Marcin Juszkiewicz]

Post by Marek Lindner
you chart looks very good !

Sorry for delay on answering but I have to not agree with You Marek.

The 2:53 boot time is disaster - none of my devices takes so much time
to just boot. I probably can go outside and find new phone before that one
will stop booting :(

Take a look at recent Poky updates - we did lot of changes related to
minimize boot time. All of them gave us quite big speedup.

From what I see the Openmoko boot process has few problems:

- heavy bootsplash which block booting instead of going into background
- some things which needs to be done once are on each boot (ipkg, ldconfig,
? probably also depmod)
- use of E17 based stuff with Qtopia based stuff at same time so two heavy
? apps fight for CPU time

Even if you make X11 not starting in background (like it is in Poky) you
can have device blocked for quite long time... We wait some time to give
X11 startup more CPU time and then start other daemons. With configuration
which Openmoko use under X it probably does not give anything special (but
it is worth trying).

[Troy Benjegerdes]

Is there a way to make nightly builds of the entire distro, than
automatically boot them on some server with qemu then time it?

I know this won't match what real hardware does, but it would be nice
to have a graph of boot times and see if one build is remarkably worse
(or better) than another.

(if only I could do this stuff as my real job ;) )

Post by Marcin Juszkiewicz

Post by Marek Lindner
you chart looks very good !

Sorry for delay on answering but I have to not agree with You Marek.
The 2:53 boot time is disaster - none of my devices takes so much time
to just boot. I probably can go outside and find new phone before that one
will stop booting :(
Take a look at recent Poky updates - we did lot of changes related to
minimize boot time. All of them gave us quite big speedup.
- heavy bootsplash which block booting instead of going into background
- some things which needs to be done once are on each boot (ipkg, ldconfig,
? probably also depmod)
- use of E17 based stuff with Qtopia based stuff at same time so two heavy
? apps fight for CPU time
Even if you make X11 not starting in background (like it is in Poky) you
can have device blocked for quite long time... We wait some time to give
X11 startup more CPU time and then start other daemons. With configuration
which Openmoko use under X it probably does not give anything special (but
it is worth trying).

--
--------------------------------------------------------------------------
Troy Benjegerdes 'da hozer' hozer at hozed.org

Somone asked me why I work on this free (http://www.gnu.org/philosophy/)
software stuff and not get a real job. Charles Shultz had the best answer:

"Why do musicians compose symphonies and poets write poems? They do it
because life wouldn't have any meaning for them if they didn't. That's why
I draw cartoons. It's my life." -- Charles Shultz

[Marek Lindner]

Post by Marcin Juszkiewicz

Post by Marek Lindner
you chart looks very good !

Sorry for delay on answering but I have to not agree with You Marek.

Well, I think you misinterpreted my sentence. It certainly does not mean that
the boot time is perfect. That is why Fred is working on it.
All good optimisations start with a decent analysis of the current state
_before_ you start doing something, hence my congratulations.

Your ideas and/or patches are highly welcome. I'm sure that Fred will consider
all contributions seriously.


Marek

[Marek Lindner]

Post by Fred Chien
after collect informations, we can sum up the most important issues for
1. initializing kernel(9 secs)
2. initializing boot splash (exquisite/exquisite-write) (8 secs)
3. udev (udev/udevd) (29 secs)
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Hi Fred,

you chart looks very good !
Holger can help you to make changes in the distro. Graeme had an idea about
udev.


Marek

[Andy Green]

Somebody in the thread at some point said:
| after collect informations, we can sum up the most important issues for
| boot time:

Hey bootchart is really good step to understand and measure the real
issues, nice work.

| 1. initializing kernel(9 secs)

What actually does that, JFFS2 mount? I use ext2 on SD card, there is
no 9 second delay there.

| 2. initializing boot splash (exquisite/exquisite-write) (8 secs)
| 3. udev (udev/udevd) (29 secs)

mdev on busybox is possible replacement.

| 4. updating dynamic library cache will waste a lot of time (ldconfig)
| (18secs)

I already mentioned this some weeks ago, I took it out on the DM2 boot
here and it makes a big difference. And most of the time, it is doing
nothing at all.

- -Andy

[Carsten Haitzler (The Rasterman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| after collect informations, we can sum up the most important issues for
Hey bootchart is really good step to understand and measure the real
issues, nice work.
| 1. initializing kernel(9 secs)
What actually does that, JFFS2 mount? I use ext2 on SD card, there is
no 9 second delay there.

i think so - jffs2 and flash IO. our flash is abysmally slow. i am amazed how
slow it is... is there something perhaps wrong with how we drive it?

| 2. initializing boot splash (exquisite/exquisite-write) (8 secs)
| 3. udev (udev/udevd) (29 secs)
mdev on busybox is possible replacement.
| 4. updating dynamic library cache will waste a lot of time (ldconfig)
| (18secs)
I already mentioned this some weeks ago, I took it out on the DM2 boot
here and it makes a big difference. And most of the time, it is doing
nothing at all.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhwkHAACgkQOjLpvpq7dMo6dwCeIV/lmzHaXavthGsQpXMBsdSK
wd0AnjLL1AKtOHiAebdrbJ2psC5cXtO1
=4+Ya
-----END PGP SIGNATURE-----

[Fred Chien]

Hi All,

The kernel issue is under study right now. I got some boot informations
from "demsg", please check the attached file. we can see the kernel is
doing for what at boot time.

here are some interesting places for kernel at boot time:

1. Mount filesystem needs 3.6secs:

[ 3.265000] CRCFAIL 0x1a3f

Post by Carsten Haitzler (The Rasterman)

[ 3.265000] Current Request Command:5, ARG:0x00000000

flags: 0x0008

Post by Carsten Haitzler (The Rasterman)

[ 6.805000] VFS: Mounted root (jffs2 filesystem).

[ 6.805000] Freeing init memory: 124K
[ 6.935000] CRCFAIL 0x1a3f

2. Framebuffer and console stuffs need 0.5 sec:
[ 1.010000] SMEDIA Glamo frame buffer driver (C) 2007 Openmoko, Inc.
[ 1.610000] Console: switching to colour frame buffer device 80x58

3. sdio_wlan needs 1 sec or ?:
[ 7.010000] sdio_wlan 00:01: driver attached
[ 7.010000] sdio_wlan 00:01: SDIO device, IDs SD_0001 (active)
[ 8.090000] Unsupported configuration opcode: 3
[ 8.090000] Unsupported configuration opcode: 5

4. ar6000 needs 1 sec or?
[ 8.225000] ar6000_avail: name=eth0 htcTarget=0xc7f46000,
dev=0xc74b0000 (0), ar=0xc74b04a0
[ 9.205000] PM: Removing info for No Bus:vcs1
[ 9.210000] PM: Removing info for No Bus:vcsa1
[ 9.215000] PM: Removing info for No Bus:vcs1
[ 9.215000] PM: Removing info for No Bus:vcsa1
[ 9.305000] PM: Removing info for No Bus:vcs1
[ 9.310000] PM: Removing info for No Bus:vcsa1
[ 9.315000] PM: Removing info for No Bus:vcs1
[ 9.315000] PM: Removing info for No Bus:vcsa1
[ 9.320000] PM: Removing info for No Bus:vcs1
[ 9.325000] PM: Removing info for No Bus:vcsa1

Cheers,
Fred

? ??2008-07-08 ? 20:42 +1000?Carsten Haitzler ???

Post by Carsten Haitzler (The Rasterman)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| after collect informations, we can sum up the most important issues for
Hey bootchart is really good step to understand and measure the real
issues, nice work.
| 1. initializing kernel(9 secs)
What actually does that, JFFS2 mount? I use ext2 on SD card, there is
no 9 second delay there.

i think so - jffs2 and flash IO. our flash is abysmally slow. i am amazed how
slow it is... is there something perhaps wrong with how we drive it?

| 2. initializing boot splash (exquisite/exquisite-write) (8 secs)
| 3. udev (udev/udevd) (29 secs)
mdev on busybox is possible replacement.
| 4. updating dynamic library cache will waste a lot of time (ldconfig)
| (18secs)
I already mentioned this some weeks ago, I took it out on the DM2 boot
here and it makes a big difference. And most of the time, it is doing
nothing at all.
- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhwkHAACgkQOjLpvpq7dMo6dwCeIV/lmzHaXavthGsQpXMBsdSK
wd0AnjLL1AKtOHiAebdrbJ2psC5cXtO1
=4+Ya
-----END PGP SIGNATURE-----

-------------- next part --------------
A non-text attachment was scrubbed...
Name: boot.log
Type: text/x-log
Size: 15607 bytes
Desc: not available
Url : http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20080709/96b2186b/attachment.bin

[Andy Green]

Somebody in the thread at some point said:
| Hi All,
|
| The kernel issue is under study right now. I got some boot informations
| from "demsg", please check the attached file. we can see the kernel is
| doing for what at boot time.
|
| here are some interesting places for kernel at boot time:
|
| 1. Mount filesystem needs 3.6secs:
|
| [ 3.265000] CRCFAIL 0x1a3f
| >> [ 3.265000] Current Request Command:5, ARG:0x00000000
| flags: 0x0008
| >> [ 6.805000] VFS: Mounted root (jffs2 filesystem).
| [ 6.805000] Freeing init memory: 124K
| [ 6.935000] CRCFAIL 0x1a3f

That's not completely insane for 256MB jffs2 filesystem, but if we can
improve it that'd be nice.

| 2. Framebuffer and console stuffs need 0.5 sec:
| [ 1.010000] SMEDIA Glamo frame buffer driver (C) 2007 Openmoko, Inc.
| [ 1.610000] Console: switching to colour frame buffer device 80x58

OK, it spins waiting for PLLs, but that isn't 500ms of spinning, I guess
it can be improved a little and we find msleeps and so on that can maybe
be reduced.

| 3. sdio_wlan needs 1 sec or ?:
| [ 7.010000] sdio_wlan 00:01: driver attached
| [ 7.010000] sdio_wlan 00:01: SDIO device, IDs SD_0001 (active)
| [ 8.090000] Unsupported configuration opcode: 3
| [ 8.090000] Unsupported configuration opcode: 5

| 4. ar6000 needs 1 sec or?
| [ 8.225000] ar6000_avail: name=eth0 htcTarget=0xc7f46000,
| dev=0xc74b0000 (0), ar=0xc74b04a0

ar6000 is the WLAN too, I am not sure this all stalls the boot (bad) or
is happening async (good). Considering it does some nice things in the
whole time it doesn't sound so awful, despite we can give it a shave.

- -Andy

[Marek Lindner]

Post by Fred Chien
4. ar6000 needs 1 sec or?

Both are part of the wifi driver. Currently I'm wokring on that and I think we
will make it a module and not load it at boot time. Holger mentionned a SD
card problem we might run into. Any other objections ?

Marek

[Andy Green]

Somebody in the thread at some point said:
| On Wednesday, 9. July 2008 00:40:25 Fred Chien wrote:
|> 3. sdio_wlan needs 1 sec or ?:
|> 4. ar6000 needs 1 sec or?
|
| Both are part of the wifi driver. Currently I'm wokring on that and I
think we
| will make it a module and not load it at boot time. Holger mentionned
a SD
| card problem we might run into. Any other objections ?

What's the SD card issue?

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.

- -Andy

[Marek Lindner]

Post by Andy Green
What's the SD card issue?
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.

For the full details Holger should comment here but it was something like that
we need the kernel module to run to detect a SD card insert action. I'm not
100% sure about it.

Marek

[Andy Green]

Somebody in the thread at some point said:
| On Wednesday, 9. July 2008 01:05:31 Andy Green wrote:
|> What's the SD card issue?
|>
|> 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.
|
| For the full details Holger should comment here but it was something
like that
| we need the kernel module to run to detect a SD card insert action.
I'm not
| 100% sure about it.

OK I don't think it makes us trouble for Glamo side where actual SD card
is sitting. We do not detect SD insertion there anyway.

But there is some funny pnp stuff in the WLAN to do with "insertion"
event of WLAN somehow from cold, it can be something about that... maybe
the PNP bits need to be in kernel. Definitely worth trying anyway and
see if it blows up.

- -Andy

[Carsten Haitzler (The Rasterman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
|> 4. ar6000 needs 1 sec or?
|
| Both are part of the wifi driver. Currently I'm wokring on that and I
think we
| will make it a module and not load it at boot time. Holger mentionned
a SD
| card problem we might run into. Any other objections ?
What's the SD card issue?
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.

[Andy Green]

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.

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

[Carsten Haitzler (The Rasterman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
|> 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.
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.
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.

remember i said to build DIFFERENT images. one i suggested was
"monolithic" (everything there as we have it now) and another where everything
we can put into a module is one. that does include sdio...

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhzp70ACgkQOjLpvpq7dMqVDACfYlUVyEWcrRsCrbcPIIiaqNEh
yugAoJNgK5fD9ItFZPl5qO5oIcL9vZSw
=7YDc
-----END PGP SIGNATURE-----

[Werner Almesberger]

Post by Carsten Haitzler (The Rasterman)
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.

Huh ? Last time I checked, we very much did. It's the menu you get when
you press and hold POWER and then press and hold AUX.

Post by Carsten Haitzler (The Rasterman)
remember i said to build DIFFERENT images.

Being able to have different images for different purposes is nice,
but we have to be careful about having just too many different ways
to run the system. Otherwise, it gets hard to reproduce problems
that other people are seeing, slowing down problem resolution or
even preventing it.

- Werner

[Carsten Haitzler (The Rasterman)]

On Tue, 8 Jul 2008 18:44:48 -0300 Werner Almesberger <werner at openmoko.org>

Post by Werner Almesberger

Post by Carsten Haitzler (The Rasterman)
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.

Huh ? Last time I checked, we very much did. It's the menu you get when
you press and hold POWER and then press and hold AUX.

i mean the one where u just press power. it boots. no menu by default.

Post by Werner Almesberger

Post by Carsten Haitzler (The Rasterman)
remember i said to build DIFFERENT images.

Being able to have different images for different purposes is nice,
but we have to be careful about having just too many different ways
to run the system. Otherwise, it gets hard to reproduce problems
that other people are seeing, slowing down problem resolution or
even preventing it.

sure. the other solution is we end up with a slower kernel boot than we need
because of a "just in case someone wants to try this out and happens to know to
press both buttons at once to boot off an sd card they specially prepared for
this". if we want to product a product - which is what we are meant to do, not
just an endless development toy that has all thew wires poking out, we need to
sacrifice some things. this is one thing where we either decide the feature is
so important we will live with the slowdown on kernel boot, we invest lots of
effort to make it faster on kernel boot (so it has no actual impact), or we
remove it for production kernels (dev, debug, hacker etc. kernels can keep it).

at least that's how i see it. we are aiming to produce a slick product. we need
to take the training wheels off sooner or later (and for those not confident in
the product u can put them back on again). if we can get rootfs on sd for "no
(real) boot slowdown" i'm all for it! if it costs nothing - keep it, but it
costs something non-insignificant (or now it is not significant as a lot of
other things are bad, but it will be significant once enough has been optimised
out).

[Marcelo]

On Tue, Jul 8, 2008 at 4:13 PM, The Rasterman Carsten Haitzler

Post by Carsten Haitzler (The Rasterman)
at least that's how i see it. we are aiming to produce a slick
product. we need to take the training wheels off sooner or later (and
for those not confident in the product u can put them back on again).
if we can get rootfs on sd for "no (real) boot slowdown" i'm all for
it! if it costs nothing - keep it, but it costs something
non-insignificant (or now it is not significant as a lot of other
things are bad, but it will be significant once enough has been
optimised out).

Amen bother!

Sometimes people seem to forget that this is, afterall, an embedded
platform.

Marcelo

[Andy Green]

Somebody in the thread at some point said:
| On Tue, 08 Jul 2008 18:45:33 +0100 Andy Green <andy at openmoko.com> 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.

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

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

| 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

[Carsten Haitzler (The Rasterman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
|
|
| |> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkh0YIIACgkQOjLpvpq7dMrfFQCeNrdl1Q5LmmQDj2xKNm6GX6x7
bwMAmwXcjUOzEkX4AjiNA6qB4VGKcWJc
=NYWy
-----END PGP SIGNATURE-----

[Sander van Grieken]

Post by Carsten Haitzler (The Rasterman)

Post by Andy Green
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.

If breaking boot from SD support only gains us 6 seconds I'd vote no.

Post by Carsten Haitzler (The Rasterman)
of course we will look at the rest of userspace, but that doesn't mean we
should just ignore the kernel.

I dont know the motorola rokr but a large part of the speed increase is
probably because a lot of the base services and the GUI are thrown into one
large statically linked binary, a static /dev, no dbus.. (correct me if I'm
wrong)

Post by Carsten Haitzler (The Rasterman)

Post by Andy Green
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.

A 'normal' user will probably seldom reboot. I assume most of the time they
will suspend/resume, So is boot time really such a big issue?

grtz,
Sander

[Carsten Haitzler (The Rasterman)]

Post by Sander van Grieken
If breaking boot from SD support only gains us 6 seconds I'd vote no.

Post by Carsten Haitzler (The Rasterman)
of course we will look at the rest of userspace, but that doesn't mean we
should just ignore the kernel.

I dont know the motorola rokr but a large part of the speed increase is
probably because a lot of the base services and the GUI are thrown into one
large statically linked binary, a static /dev, no dbus.. (correct me if I'm
wrong)

yes. it likely does.. but it manage a kernel AND userspace boot in less time
than our kernel just gets to starting init. on a significantly lower-end piece
of hardware too. pretty embarrassing.

Post by Sander van Grieken

Post by Carsten Haitzler (The Rasterman)

Post by Andy Green
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.

A 'normal' user will probably seldom reboot. I assume most of the time they
will suspend/resume, So is boot time really such a big issue?

you'll be booting a lot if you travel on planes.

[Mike (mwester)]

Post by Carsten Haitzler (The Rasterman)
you'll be booting a lot if you travel on planes.

And pulling the battery out too (no current user-space images of which I
am aware actually power down the GSM, so if you aren't pulling out the
battery, you're not in "airplane mode"!!)

Mike (mwester)

[Marcelo]

Post by Mike (mwester)
And pulling the battery out too (no current user-space images of which
I am aware actually power down the GSM, so if you aren't pulling out
the battery, you're not in "airplane mode"!!)

Most consumer electronics in this category don't really power down,
even if you press the physical "power off" button. A tiny bit of the
system is still running to do miscellaneous stuff. ARM9 processors
like the one in the OpenMoko have a sleep mode that freezes the system
state, but it's otherwise "on".

I have always wondered about the real reason behind asking people to
turn off phones during take off and landing. Recently I heard that
it's actually only one of the cases that matters, I think it was
landing. Once I forgot that I had dropped my phone in my backpack even
before leaving out for the airport and I realised this only when I
arrived at my final destination. I wondered how often that kind of
thing happens to people all over the world.

Marcelo

[Thomas Gstädtner]

Post by Marcelo

Post by Mike (mwester)
And pulling the battery out too (no current user-space images of which
I am aware actually power down the GSM, so if you aren't pulling out
the battery, you're not in "airplane mode"!!)

Most consumer electronics in this category don't really power down,
even if you press the physical "power off" button. A tiny bit of the
system is still running to do miscellaneous stuff. ARM9 processors
like the one in the OpenMoko have a sleep mode that freezes the system
state, but it's otherwise "on".
I have always wondered about the real reason behind asking people to
turn off phones during take off and landing. Recently I heard that
it's actually only one of the cases that matters, I think it was
landing. Once I forgot that I had dropped my phone in my backpack even
before leaving out for the airport and I realised this only when I
arrived at my final destination. I wondered how often that kind of
thing happens to people all over the world.
Marcelo

The first airlines already published studies, that they see no problems
with cellphones.
I don't think there will be any case where a cellphone could in any way
disturb plane electronics.
Only a matter of time till they are allowed on every plane (even it's
pretty useless without in-plane coverage).

[Mike (mwester)]

Post by Marcelo

Post by Mike (mwester)
And pulling the battery out too (no current user-space images of which
I am aware actually power down the GSM, so if you aren't pulling out
the battery, you're not in "airplane mode"!!)

Most consumer electronics in this category don't really power down,
even if you press the physical "power off" button. A tiny bit of the
system is still running to do miscellaneous stuff. ARM9 processors
like the one in the OpenMoko have a sleep mode that freezes the system
state, but it's otherwise "on".

I must step in and correct a possible misconception here -- you are
correct, but it is important to note that in the case of cell phones,
powering off DOES put the GSM into a "safe" mode, where the GSM is
either completely without power, or is in a state where it has the RF
section shut down.

My commentary is not about the small amount of power used by devices in
the "off" state, rather it is about the fact that the GSM on the GTA01
and GTA02 is left in a fully-operational, completely up-and-running
state, even when you have shut down the Linux kernel and the PCF606xx
PMU chip has otherwise shut down the power to all other components in
the phone.

The troubles this might make for the unaware user range from the trivial
and very probable draining of the battery when the phone is supposedly
off, to the improbable and not-so-trivial.

Post by Marcelo
I have always wondered about the real reason behind asking people to
turn off phones during take off and landing. Recently I heard that
it's actually only one of the cases that matters, I think it was
landing. Once I forgot that I had dropped my phone in my backpack even
before leaving out for the airport and I realised this only when I
arrived at my final destination. I wondered how often that kind of
thing happens to people all over the world.

I'm not interested in starting an argument over the validity of the
rules. They are as they are, and we -- er, I guess I mean the
user-space application software developers since we've already had the
discussion about this being hardware or kernel -- we need to at least
ensure that the phone is capable of following those rules. Whether you
do, or not, is up to you.

I'll also point out that this is not limited to airplanes, my travels
have taken me to places with large signs advising that one is entering a
"blast zone" and cell phones are to be turned off... Again, if a user
chooses to comply or not is up to them, but at least they shouldn't be
left believing that they complied by powering off the phone when in fact
the GSM is merrily conversing with the nearest tower all by itself...

Post by Marcelo
Marcelo

Mike (mwester)

[Andy Green]

Somebody in the thread at some point said:

| My commentary is not about the small amount of power used by devices in
| the "off" state, rather it is about the fact that the GSM on the GTA01
| and GTA02 is left in a fully-operational, completely up-and-running
| state, even when you have shut down the Linux kernel and the PCF606xx
| PMU chip has otherwise shut down the power to all other components in
| the phone.
|
| The troubles this might make for the unaware user range from the trivial
| and very probable draining of the battery when the phone is supposedly
| off, to the improbable and not-so-trivial.

On GTA01 IIRC and certainly 02 there is a) what claims to be some kind
of logical on / off switch in the form of an NPN transistor that goes
into the GSM chipset, and b) the GSM logic side has switched power
itself that can be on and off.

The RF power amp is connected directly to battery because of the high
current it wants, the enable for it should be always disabled when GSM
logic side is unpowered... I seem to recall Allen has checked this.

GSM side is a bit funny because it has pretty direct access to battery
but if logic gets both told to be "off" and then depowered on shutdown
as it presumably should then it should be OK AFAIK.

- -Andy

[Werner Almesberger]

Post by Andy Green
On GTA01 IIRC and certainly 02 there is a) what claims to be some kind
of logical on / off switch in the form of an NPN transistor that goes
into the GSM chipset,

This is quite literally the "on" button of the GSM subsystem. That
chipset is designed to be an entire feature phone, so you wouldn't
have that additional MCU. In this sort of standalone configuration,
PWON (which is where our NPN connects) would just be wired to the
phone's power button.

- Werner

[Michael 'Mickey' Lauer]

Post by Mike (mwester)

Post by Carsten Haitzler (The Rasterman)
you'll be booting a lot if you travel on planes.

And pulling the battery out too (no current user-space images of which I
am aware actually power down the GSM, so if you aren't pulling out the
battery, you're not in "airplane mode"!!)

I could be wrong, but IIRC FSO is powering the modem down if you shut it down
from console. gsm0710muxd is issuing AT at POFF once you SIGTERM it.

[Werner Almesberger]

Post by Michael 'Mickey' Lauer
I could be wrong, but IIRC FSO is powering the modem down if you shut it down
from console. gsm0710muxd is issuing AT at POFF once you SIGTERM it.

That AT at POFF doesn't cut power to the modem. Instead, it tells the
modem to "power down", i.e., to enter its own standby mode, from
which it can be awakened by "pressing" the modem's "on" button.
(That "button" is in fact a transistor controlled by MODEM_ON line
which connect to the CPU's GPB7.)

What does cut power to most of the GSM chipset is the GSM_ON line
which connects to the PMU's GPIO2.

Alas, the modem's RF amplifier is not controlled by this (it doesn't
like anything to get between it and the battery), so the GSM
subsystem cannot be entirely cut off.

- Werner

[Joe Pfeiffer]

Post by Werner Almesberger

Post by Michael 'Mickey' Lauer
I could be wrong, but IIRC FSO is powering the modem down if you shut it down
from console. gsm0710muxd is issuing AT at POFF once you SIGTERM it.

That AT at POFF doesn't cut power to the modem. Instead, it tells the
modem to "power down", i.e., to enter its own standby mode, from
which it can be awakened by "pressing" the modem's "on" button.
(That "button" is in fact a transistor controlled by MODEM_ON line
which connect to the CPU's GPB7.)
What does cut power to most of the GSM chipset is the GSM_ON line
which connects to the PMU's GPIO2.
Alas, the modem's RF amplifier is not controlled by this (it doesn't
like anything to get between it and the battery), so the GSM
subsystem cannot be entirely cut off.

I'm confused -- do you mean there is no way to turn off the modem's RF
amp? What do other phones using it do to comply with airplane
regulations?

[Werner Almesberger]

Post by Joe Pfeiffer
I'm confused -- do you mean there is no way to turn off the modem's RF
amp? What do other phones using it do to comply with airplane
regulations?

The RF amplifier has an input called TX_ENABLE, which is connected to
TSPACT09 of the GSM baseband processor, so the GSM chipset can tell it
whether to transmit or not.

- Werner

[Joe Pfeiffer]

Post by Werner Almesberger

Post by Joe Pfeiffer
I'm confused -- do you mean there is no way to turn off the modem's RF
amp? What do other phones using it do to comply with airplane
regulations?

The RF amplifier has an input called TX_ENABLE, which is connected to
TSPACT09 of the GSM baseband processor, so the GSM chipset can tell it
whether to transmit or not.

So, in your previous post

Post by Werner Almesberger
That AT at POFF doesn't cut power to the modem. Instead, it tells the
modem to "power down", i.e., to enter its own standby mode, from
which it can be awakened by "pressing" the modem's "on" button.
(That "button" is in fact a transistor controlled by MODEM_ON line
which connect to the CPU's GPB7.)

Are you drawing a distinction between 'turning the modem off'
vs. telling the transmitter not to transmit? In the context of
airplane rules, the latter ought to be just as good...

[Werner Almesberger]

Post by Joe Pfeiffer
Are you drawing a distinction between 'turning the modem off'
vs. telling the transmitter not to transmit?

Yes. Some people are concerned that the GSM subsystem may surreptitiously
communicate even if commanded off. The only way to make sure that this
doesn't happen is to cut power to the GSM subsystem.

Post by Joe Pfeiffer
In the context of airplane rules, the latter ought to be just as good...

Yes, that's what any normal phone does anyway :)

- Werner

[Mike (mwester)]

Post by Werner Almesberger

Post by Joe Pfeiffer
Are you drawing a distinction between 'turning the modem off'
vs. telling the transmitter not to transmit?

Yes. Some people are concerned that the GSM subsystem may surreptitiously
communicate even if commanded off. The only way to make sure that this
doesn't happen is to cut power to the GSM subsystem.

Well, that may be what *SOME* people are concerned about; just to be
clear my concern is not that, it is that at present neither the image
pre-installed on the phone, nor the current ASU image issue the command
to turn off the GSM -- so it will continue to transmit even when Linux
has shutdown, and the host ARM CPU has been powered off.

I'd be much less concerned if all the software distros that can be
flashed to the phone, or at least if the one that ships pre-installed,
actually shut down the GSM when the phone is turned off.

Post by Werner Almesberger

Post by Joe Pfeiffer
In the context of airplane rules, the latter ought to be just as good...

Yes, that's what any normal phone does anyway :)
- Werner

Mike (mwester)

[Joerg Reisenweber]

Post by Joe Pfeiffer

Post by Werner Almesberger

Post by Michael 'Mickey' Lauer
I could be wrong, but IIRC FSO is powering the modem down if you shut it down
from console. gsm0710muxd is issuing AT at POFF once you SIGTERM it.

That AT at POFF doesn't cut power to the modem. Instead, it tells the
modem to "power down", i.e., to enter its own standby mode, from
which it can be awakened by "pressing" the modem's "on" button.
(That "button" is in fact a transistor controlled by MODEM_ON line
which connect to the CPU's GPB7.)
What does cut power to most of the GSM chipset is the GSM_ON line
which connects to the PMU's GPIO2.
Alas, the modem's RF amplifier is not controlled by this (it doesn't
like anything to get between it and the battery), so the GSM
subsystem cannot be entirely cut off.

I'm confused -- do you mean there is no way to turn off the modem's RF
amp? What do other phones using it do to comply with airplane
regulations?

The amp is supposed to be inactive by default, as long as no signal is coming
in to drive it. Think of it as an active audio box that's "always
on"(standby) and activates whenever a signal comes in.
Oscillators (transmitter) are forced powered down.
So there should be no issues here.

/j


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://lists.openmoko.org/pipermail/openmoko-devel/attachments/20080710/7dd6a0d1/attachment.pgp

[Mike (mwester)]

Post by Michael 'Mickey' Lauer

Post by Mike (mwester)

Post by Carsten Haitzler (The Rasterman)
you'll be booting a lot if you travel on planes.

And pulling the battery out too (no current user-space images of which I
am aware actually power down the GSM, so if you aren't pulling out the
battery, you're not in "airplane mode"!!)

I could be wrong, but IIRC FSO is powering the modem down if you shut it down
from console. gsm0710muxd is issuing AT at POFF once you SIGTERM it.

:) Yet another huge plus for FSO -- that's great news!
Thanks!

Mike (mwester)

[M. Dietrich]

Post by Mike (mwester)

Post by Michael 'Mickey' Lauer

Post by Mike (mwester)

Post by Carsten Haitzler (The Rasterman)
you'll be booting a lot if you travel on planes.

And pulling the battery out too (no current user-space images of which I
am aware actually power down the GSM, so if you aren't pulling out the
battery, you're not in "airplane mode"!!)

I could be wrong, but IIRC FSO is powering the modem down if you shut it down
from console. gsm0710muxd is issuing AT at POFF once you SIGTERM it.

:) Yet another huge plus for FSO -- that's great news!
Thanks!

just for the record: the muxer was developed as part of the pyneo
software stack. it can be used with the fso daemons or even libgsmd.

michael

[Andy Green]

Somebody in the thread at some point said:

| If breaking boot from SD support only gains us 6 seconds I'd vote no.

I can boot from SD into a shell in < 5 seconds from starting Linux, how
is removing it gaining us 6 seconds? MCI probing and so on is
asynchronous to the boot action and does not stall it.

Anyway this isn't happening I am told, so no worries.

- -Andy

[Alexey Feldgendler]

Post by Fred Chien
after collect informations, we can sum up the most important issues for
1. initializing kernel(9 secs)
2. initializing boot splash (exquisite/exquisite-write) (8 secs)
3. udev (udev/udevd) (29 secs)
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Can (2) and (3) run at the same time?

[Graeme Gregory]

Post by Alexey Feldgendler

Post by Fred Chien
after collect informations, we can sum up the most important issues for
1. initializing kernel(9 secs)
2. initializing boot splash (exquisite/exquisite-write) (8 secs)
3. udev (udev/udevd) (29 secs)
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

Can (2) and (3) run at the same time?

I tested running udev init in background and total boot time remained
unchanged. It is obviously resource limited.

Graeme

[Dr. H. Nikolaus Schaller]

Post by Graeme Gregory

Post by Alexey Feldgendler

Post by Fred Chien
after collect informations, we can sum up the most important
issues for
1. initializing kernel(9 secs)
2. initializing boot splash (exquisite/exquisite-write) (8 secs)
3. udev (udev/udevd) (29 secs)
4. updating dynamic library cache will waste a lot of time
(ldconfig)
(18secs)

Can (2) and (3) run at the same time?

I tested running udev init in background and total boot time remained
unchanged. It is obviously resource limited.

As far as I understood the documentation it serializes events from
hotplug. So each hotplugged device has to wait for its predecessor.

But what is hotplugged in the OM during boot? It looks like boot
initialization is treated as hot-plugging. Appears to be similar to
ldconfig which has a cache that does NOT need updates on boot.

* the first idea I have is to preinitialize devices by copying some
files so that hotplug/udev hasn't to do so much work (i.e. taking a
snapshot of the important files AFTER udev did run once, and provide
that snapshot as part of the rootfs)
* or, if that does not work, only hotplug those devices that are
essential for booting and postpone other until the GUI is running.

Since I am not a kernel specialist, I have no idea whether that works...

Nikolaus

[Graeme Gregory]

Post by Dr. H. Nikolaus Schaller
As far as I understood the documentation it serializes events from
hotplug. So each hotplugged device has to wait for its predecessor.
But what is hotplugged in the OM during boot? It looks like boot
initialization is treated as hot-plugging. Appears to be similar to
ldconfig which has a cache that does NOT need updates on boot.
* the first idea I have is to preinitialize devices by copying some
files so that hotplug/udev hasn't to do so much work (i.e. taking a
snapshot of the important files AFTER udev did run once, and provide
that snapshot as part of the rootfs)
* or, if that does not work, only hotplug those devices that are
essential for booting and postpone other until the GUI is running.
Since I am not a kernel specialist, I have no idea whether that works...

No-one reads my mails :-(

I already did all this work.

pre-initing udev with static devices saves 10s on boot time.

Using mdev -s to pre-init also saves 10s on boot time.

I prefer to use mdev as at least we dont need to play funny tricks to
get the SD card to work on boot.

Graeme

[Dr. H. Nikolaus Schaller]

Post by Graeme Gregory

Post by Dr. H. Nikolaus Schaller
As far as I understood the documentation it serializes events from
hotplug. So each hotplugged device has to wait for its predecessor.
But what is hotplugged in the OM during boot? It looks like boot
initialization is treated as hot-plugging. Appears to be similar to
ldconfig which has a cache that does NOT need updates on boot.
* the first idea I have is to preinitialize devices by copying some
files so that hotplug/udev hasn't to do so much work (i.e. taking a
snapshot of the important files AFTER udev did run once, and provide
that snapshot as part of the rootfs)
* or, if that does not work, only hotplug those devices that are
essential for booting and postpone other until the GUI is running.
Since I am not a kernel specialist, I have no idea whether that works...

No-one reads my mails :-(

Sorry - I read only most mails :-)

Post by Graeme Gregory
I already did all this work.
pre-initing udev with static devices saves 10s on boot time.
Using mdev -s to pre-init also saves 10s on boot time.
I prefer to use mdev as at least we dont need to play funny tricks to
get the SD card to work on boot.
Graeme

Great!

Nikolaus

[Wolfgang Spraul]

Graeme,

Post by Graeme Gregory
I already did all this work.
pre-initing udev with static devices saves 10s on boot time.
Using mdev -s to pre-init also saves 10s on boot time.

Is this improvement in the daily build images we can download from
buildhost?
Wolfgang

Post by Graeme Gregory

Post by Dr. H. Nikolaus Schaller
As far as I understood the documentation it serializes events from
hotplug. So each hotplugged device has to wait for its predecessor.
But what is hotplugged in the OM during boot? It looks like boot
initialization is treated as hot-plugging. Appears to be similar to
ldconfig which has a cache that does NOT need updates on boot.
* the first idea I have is to preinitialize devices by copying some
files so that hotplug/udev hasn't to do so much work (i.e. taking a
snapshot of the important files AFTER udev did run once, and provide
that snapshot as part of the rootfs)
* or, if that does not work, only hotplug those devices that are
essential for booting and postpone other until the GUI is running.
Since I am not a kernel specialist, I have no idea whether that works...

No-one reads my mails :-(
I already did all this work.
pre-initing udev with static devices saves 10s on boot time.
Using mdev -s to pre-init also saves 10s on boot time.
I prefer to use mdev as at least we dont need to play funny tricks to
get the SD card to work on boot.
Graeme

[Graeme Gregory]

Post by Wolfgang Spraul
Graeme,

Post by Graeme Gregory
I already did all this work.
pre-initing udev with static devices saves 10s on boot time.
Using mdev -s to pre-init also saves 10s on boot time.

Is this improvement in the daily build images we can download from
buildhost?
Wolfgang

No, I need to change quite a few programs and scripts before it can
go live.

mdev does not construct /dev in the same way as udev. At the moment we
assume udev through the whole system.

Graeme

[Wolfgang Spraul]

Graeme,
OK understood. Do you plan to integrate this soon?
Or pass on to Fred who is working on the same problem. If your stuff
is not in, then one way or the other Fred will recreate it.
Wolfgang

Post by Graeme Gregory

Post by Wolfgang Spraul
Graeme,

Post by Graeme Gregory
I already did all this work.
pre-initing udev with static devices saves 10s on boot time.
Using mdev -s to pre-init also saves 10s on boot time.

Is this improvement in the daily build images we can download from
buildhost?
Wolfgang

No, I need to change quite a few programs and scripts before it can
go live.
mdev does not construct /dev in the same way as udev. At the moment we
assume udev through the whole system.
Graeme

[Carsten Haitzler (The Rasterman)]

Post by Graeme Gregory

Post by Dr. H. Nikolaus Schaller
As far as I understood the documentation it serializes events from
hotplug. So each hotplugged device has to wait for its predecessor.
But what is hotplugged in the OM during boot? It looks like boot
initialization is treated as hot-plugging. Appears to be similar to
ldconfig which has a cache that does NOT need updates on boot.
* the first idea I have is to preinitialize devices by copying some
files so that hotplug/udev hasn't to do so much work (i.e. taking a
snapshot of the important files AFTER udev did run once, and provide
that snapshot as part of the rootfs)
* or, if that does not work, only hotplug those devices that are
essential for booting and postpone other until the GUI is running.
Since I am not a kernel specialist, I have no idea whether that works...

No-one reads my mails :-(
I already did all this work.
pre-initing udev with static devices saves 10s on boot time.

already talked about that in the meeting we had - that you found how to nuke 10
secs with mdev... :)

Post by Graeme Gregory
Using mdev -s to pre-init also saves 10s on boot time.
I prefer to use mdev as at least we dont need to play funny tricks to
get the SD card to work on boot.
Graeme

[Carsten Haitzler (The Rasterman)]

Post by Fred Chien
after collect informations, we can sum up the most important issues for
1. initializing kernel(9 secs)
2. initializing boot splash (exquisite/exquisite-write) (8 secs)
3. udev (udev/udevd) (29 secs)
4. updating dynamic library cache will waste a lot of time (ldconfig)
(18secs)

exquisite-write doesn't look right to me. it should not be sitting there for 8
seconds - i think this is the sum of exquisite-write being called many times
during boot (it is called to connect and write some update info to exquisite),
so i suspect that part of the chart is wrong. exquisite itself there seems
mostly to eat cpu, but for a very long time... it' be nice to know at which
point there exquisite actually DISPLAYS something (is all that cpu just
loading shared libraries, initial startup and parsing of theme files etc.) i
wonder if that initial exquisite-write is also the -wait (that waits for
exqusitie to come up). every 0.1 seconds it checks to see if it can connect.
this shouldnt use much cpu at all - or any worth talking about as all it does
is attempt to open a unix socket to connect to...

overall i suspect most of the time is chewed up in decompressing multiple times
(IO) jffs2 decompressing then eet/edje decompressing again itself.

which brings me back to... we need a way to avoid jffs2 compression for some
types of files. eg: *.jpg, *.png, *.gif, *.edj, *.mp3 ... :)

[Michael 'Mickey' Lauer]

Post by Carsten Haitzler (The Rasterman)
which brings me back to... we need a way to avoid jffs2 compression for
some types of files. eg: *.jpg, *.png, *.gif, *.edj, *.mp3 ... :)

We should consider one of the alternatives to jffs2. The jury is still out on
yaffs2 and ubifs is now in mainline.

[Carsten Haitzler (The Rasterman)]

On Tue, 8 Jul 2008 14:35:13 +0200 "Michael 'Mickey' Lauer"

Post by Michael 'Mickey' Lauer

Post by Carsten Haitzler (The Rasterman)
which brings me back to... we need a way to avoid jffs2 compression for
some types of files. eg: *.jpg, *.png, *.gif, *.edj, *.mp3 ... :)

We should consider one of the alternatives to jffs2. The jury is still out on
yaffs2 and ubifs is now in mainline.

definitely. i'm no expert here... so.. what do people say? jffs2 works .. but
does have performance issues. it needs the ability to be able to be taught to
not compress some kinds of files. do we have anything of the sort out there?

[Andy Green]

Somebody in the thread at some point said:
| On Tue, 8 Jul 2008 14:35:13 +0200 "Michael 'Mickey' Lauer"
| <mickey at vanille-media.de> babbled:
|
|> Am Dienstag 08 Juli 2008 12:45:12 schrieb Carsten Haitzler:
|>> which brings me back to... we need a way to avoid jffs2 compression for
|>> some types of files. eg: *.jpg, *.png, *.gif, *.edj, *.mp3 ... :)
|> We should consider one of the alternatives to jffs2. The jury is
still out on
|> yaffs2 and ubifs is now in mainline.
|
| definitely. i'm no expert here... so.. what do people say? jffs2 works
.. but
| does have performance issues. it needs the ability to be able to be
taught to
| not compress some kinds of files. do we have anything of the sort out
there?

Jffs2 is just a symptom of writing direct to raw NAND... we don't need
to deal with these unusual formats when our storage is SD Card. In that
future, we use the very well characterized ext2 or ext3.

- -Andy

[Michael 'Mickey' Lauer]

Post by Andy Green
Jffs2 is just a symptom of writing direct to raw NAND... we don't need
to deal with these unusual formats when our storage is SD Card. In that
future, we use the very well characterized ext2 or ext3.

Yes, but until then there may be a nice speedup waiting for all existing
customers.

[Andy Green]

Somebody in the thread at some point said:
| Am Dienstag 08 Juli 2008 16:03:00 schrieb Andy Green:
|> Jffs2 is just a symptom of writing direct to raw NAND... we don't need
|> to deal with these unusual formats when our storage is SD Card. In that
|> future, we use the very well characterized ext2 or ext3.
|
| Yes, but until then there may be a nice speedup waiting for all existing
| customers.

It's unclear where that problem comes from, I guess I would be
suspicious first about this offline generation of jjfs2 image, compare
it to unpacking tar into empty actual mtd.

- -Andy

[Michael 'Mickey' Lauer]

Post by Andy Green
|> Jffs2 is just a symptom of writing direct to raw NAND... we don't need
|> to deal with these unusual formats when our storage is SD Card. In that
|> future, we use the very well characterized ext2 or ext3.
|
| Yes, but until then there may be a nice speedup waiting for all existing
| customers.
It's unclear where that problem comes from, I guess I would be
suspicious first about this offline generation of jjfs2 image, compare
it to unpacking tar into empty actual mtd.

yaffs2 is not compressing files at all. On the 02 with its 256MB flash, I'd be
interested to see how it performs.

[Werner Almesberger]

Post by Andy Green
It's unclear where that problem comes from,

The ECC might be a major factor in this. It's turned off because
software and hardware disagree on the ECC algorithm, causing images
DFU'ed onto the device to produce ECC errors.

- Werner

[Andy Green]

Somebody in the thread at some point said:
| Andy Green wrote:
|> It's unclear where that problem comes from,
|
| The ECC might be a major factor in this. It's turned off because
| software and hardware disagree on the ECC algorithm, causing images
| DFU'ed onto the device to produce ECC errors.

Is this because U-Boot (active at DFU time) doesn't use hw ECC then?
Otherwise it would all come out in the wash?

- -Andy

[Werner Almesberger]

Post by Andy Green
Is this because U-Boot (active at DFU time) doesn't use hw ECC then?
Otherwise it would all come out in the wash?

Yup. Or, alternatively, we could try to make u-boot use the same
algorithm in software. Not sure what's easier to do.

Matt, you figured that one out when we had the same problem a while
ago on HXD8. Do you remember whether this was solved or if we just
worked around it by using the kernel (and not u-boot) to write the
rootfs ?

- Werner

[matt_hsu]

Post by Werner Almesberger

Post by Andy Green
Is this because U-Boot (active at DFU time) doesn't use hw ECC then?
Otherwise it would all come out in the wash?

Yup. Or, alternatively, we could try to make u-boot use the same
algorithm in software. Not sure what's easier to do.
Matt, you figured that one out when we had the same problem a while
ago on HXD8. Do you remember whether this was solved or if we just
worked around it by using the kernel (and not u-boot) to write the
rootfs ?

Well, we just write the rootfs via mtd utility at kernel layer.
And DFU did not do hw ECC handling at U-boot. You will see countless ECC
errors if you enable hw ECC logic for kernel and program the rootfs via
u-boot.

Matt

Post by Werner Almesberger
- Werner

[Werner Almesberger]

Post by matt_hsu
And DFU did not do hw ECC handling at U-boot. You will see countless ECC
errors if you enable hw ECC logic for kernel and program the rootfs via
u-boot.

Okay, that's what I thought. Thanks !

So ECC isn't ready for prime time yet. A long time ago, when we were
also looking into boot time improvments, I briefly enabled hardware
ECC in the kernel, but then people started reporting stray JFFS2
errors, but I couldn't find any flaw in the kernel, so I disabled it
again.

We didn't find out that this was an interaction between u-boot and
the kernel until much later.

- Werner

[Carsten Haitzler (The Rasterman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| On Tue, 8 Jul 2008 14:35:13 +0200 "Michael 'Mickey' Lauer"
|
|>> which brings me back to... we need a way to avoid jffs2 compression for
|>> some types of files. eg: *.jpg, *.png, *.gif, *.edj, *.mp3 ... :)
|> We should consider one of the alternatives to jffs2. The jury is
still out on
|> yaffs2 and ubifs is now in mainline.
|
| definitely. i'm no expert here... so.. what do people say? jffs2 works
.. but
| does have performance issues. it needs the ability to be able to be
taught to
| not compress some kinds of files. do we have anything of the sort out
there?
Jffs2 is just a symptom of writing direct to raw NAND... we don't need
to deal with these unusual formats when our storage is SD Card. In that
future, we use the very well characterized ext2 or ext3.

but that doesn't help- as such we have our OS on "on-chip" flash. that's where
it is. it's nastily slow (2mb/sec read rates is what i clocked on the mtdblock
devices themselves, so bypassing jffs2 overhead). am i wrong i suspecting our
flash SHOULD be much faster? (like 5-10x faster)? this is for freerunner.
future devices is... another matter :)

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhzc44ACgkQOjLpvpq7dMqvnQCfTS85sDbNc952KW1qvyXbF6EQ
JgQAnig0wv29uOyl4PWjhP6yDphKH9Rc
=l9bc
-----END PGP SIGNATURE-----

[Andy Green]

Somebody in the thread at some point said:

| Jffs2 is just a symptom of writing direct to raw NAND... we don't need
| to deal with these unusual formats when our storage is SD Card. In that
| future, we use the very well characterized ext2 or ext3.
|
|> but that doesn't help- as such we have our OS on "on-chip" flash.
that's where
|> it is. it's nastily slow (2mb/sec read rates is what i clocked on the
mtdblock
|> devices themselves, so bypassing jffs2 overhead). am i wrong i
suspecting our
|> flash SHOULD be much faster? (like 5-10x faster)? this is for freerunner.
|> future devices is... another matter :)

Well we can boot SD on GTA02. But I really mean it's not obvious we
should make a big investment into a new raw mtd filesystem given where
we are headed.

Practically, there's likely something wrong with how we use jffs2 from
cradle to grave and we probably get a better result looking at that.

- -Andy

[Carsten Haitzler (The Rasterman)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| Jffs2 is just a symptom of writing direct to raw NAND... we don't need
| to deal with these unusual formats when our storage is SD Card. In that
| future, we use the very well characterized ext2 or ext3.
|
|> but that doesn't help- as such we have our OS on "on-chip" flash.
that's where
|> it is. it's nastily slow (2mb/sec read rates is what i clocked on the
mtdblock
|> devices themselves, so bypassing jffs2 overhead). am i wrong i
suspecting our
|> flash SHOULD be much faster? (like 5-10x faster)? this is for freerunner.
|> future devices is... another matter :)
Well we can boot SD on GTA02. But I really mean it's not obvious we
should make a big investment into a new raw mtd filesystem given where
we are headed.

oooh. no no. i was more thinking of what is out there we already have and what
we can do to it with fairly minimal work to improve it. no big investment.

Practically, there's likely something wrong with how we use jffs2 from
cradle to grave and we probably get a better result looking at that.

sure - but i get 2mb/sec of the /dev/mtdblock... devices (using dd). that is
pre-jffs2 so we have also raw mtd device slowness... is 2mb/sec expected from
our 2442?

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhzgIcACgkQOjLpvpq7dMq+6QCfWp0Hf3NFFxt8Sf6+doDo4NuC
NvEAn2npNiSKqI1m5YnYXIr4p4i076oY
=ZQ7q
-----END PGP SIGNATURE-----

[Jay Vaughan]

Post by Andy Green
Well we can boot SD on GTA02. But I really mean it's not obvious we
should make a big investment into a new raw mtd filesystem given where
we are headed.

i favour a 'distribution policy' approach whereby the SD card is the
primary means of booting the OS, and onboard nonvolatile RAM is made
available for -user space applications- to be used to maintain longer-
term consistent data, with a subset of it allocated of course for
rescue and rudiments.



;
--
Jay Vaughan

[Crane, Matthew]

Is it possibly a problem with too many wait states on the flash? Has
anybody actually tweaked it to the point of failure?

Matt

-----Original Message-----
From: openmoko-devel-bounces at lists.openmoko.org
[mailto:openmoko-devel-bounces at lists.openmoko.org] On Behalf Of Carsten
Haitzler (The Rasterman)
Sent: Tuesday, July 08, 2008 10:49 AM
To: Andy Green
Cc: Michael 'Mickey' Lauer; openmoko-devel at lists.openmoko.org
Subject: Re: flash


On Tue, 08 Jul 2008 15:03:00 +0100 Andy Green <andy at openmoko.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
| On Tue, 8 Jul 2008 14:35:13 +0200 "Michael 'Mickey' Lauer"
|
|>> which brings me back to... we need a way to avoid jffs2

compression for

|>> some types of files. eg: *.jpg, *.png, *.gif, *.edj, *.mp3 ... :)
|> We should consider one of the alternatives to jffs2. The jury is
still out on
|> yaffs2 and ubifs is now in mainline.
|
| definitely. i'm no expert here... so.. what do people say? jffs2 works
.. but
| does have performance issues. it needs the ability to be able to be
taught to
| not compress some kinds of files. do we have anything of the sort out
there?
Jffs2 is just a symptom of writing direct to raw NAND... we don't need
to deal with these unusual formats when our storage is SD Card. In that
future, we use the very well characterized ext2 or ext3.

but that doesn't help- as such we have our OS on "on-chip" flash. that's
where
it is. it's nastily slow (2mb/sec read rates is what i clocked on the
mtdblock
devices themselves, so bypassing jffs2 overhead). am i wrong i
suspecting our
flash SHOULD be much faster? (like 5-10x faster)? this is for
freerunner.
future devices is... another matter :)

- -Andy
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkhzc44ACgkQOjLpvpq7dMqvnQCfTS85sDbNc952KW1qvyXbF6EQ
JgQAnig0wv29uOyl4PWjhP6yDphKH9Rc
=l9bc
-----END PGP SIGNATURE-----

[Ross Burton]

Post by Fred Chien
Also I created a project and put the "bootchart-lite" source code in the
Google Code. Everyone can download it and regenerate the bootchart for
testing.
http://code.google.com/p/bootchart-lite/

There is already a "embedded" bootchart clone on google code:

http://code.google.com/p/ubootchart/

I suggest that you look at merging any of your interesting features into
ubootchart, instead of starting an identical clone.

Ross