login
Search
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.
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.
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
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
Hi Fred, you chart looks very good ! Holger can help you to make changes in the distro. Graeme had an idea about udev. Marek
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).
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 ;) ) -- -------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@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
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----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-----
i think so - jffs2 and flash IO. our flash is abysmally slow. i am amazed how -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
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
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=3Deth0 htcTarget=3D0xc7f46000,
dev=3D0xc74b0000 (0), ar=3D0xc74b04a0
[ 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
=E6=96=BC =E4=BA=8C=EF=BC=8C2008-07-08 =E6=96=BC 20:42 +1000=EF=BC=8CCarste=
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhzmpsACgkQOjLpvpq7dMrBcwCdGe4Im5ZcEh0tQXgmIK0N3lQv SXsAnj3AV8coKHCBkRtBlreZkkP47qnX =CbRH -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhznlQACgkQOjLpvpq7dMqhTgCfdIySICWFWGUydEM1OuVGtDEi uLcAn2zeJuqVc+dvTChAGllTf4UfEoTy =XAgt -----END PGP SIGNATURE-----
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhzpv0ACgkQOjLpvpq7dMpVNACdGTUm9FlostH/fMbqFWOKKqUM nmkAn3K35OQEmNLzCTs8l8Ge+oqk0OAD =4g7x -----END PGP SIGNATURE-----
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. -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----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-----
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 -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
Huh ? Last time I checked, we very much did. It's the menu you get when 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
On Tue, 8 Jul 2008 18:44:48 -0300 Werner Almesberger <werner@openmoko.org> 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). -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
On Tue, Jul 8, 2008 at 4:13 PM, The Rasterman Carsten Haitzler Amen bother! Sometimes people seem to forget that this is, afterall, an embedded platform. Marcelo
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Tue, 08 Jul 2008 18:45:33 +0100 Andy Green <andy@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 ...
every freerunner i have seen except 1 when you power button displays a splash 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 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 -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
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 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
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 you'll be booting a lot if you travel on planes. -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
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)
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).
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 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 Mike (mwester)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEUEARECAAYFAkh3L7IACgkQOjLpvpq7dMry9wCgio32AkZvFpCQpSoD9+JLFhmC ekYAmKLc+OoGZjZp4NH5mGIUvk3U0CI= =3Rjr -----END PGP SIGNATURE-----
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
I could be wrong, but IIRC FSO is powering the modem down if you shut it down from console. gsm0710muxd is issuing AT@POFF once you SIGTERM it.
That 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
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
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...
Yes. Some people are concerned that the GSM subsystem may surreptitiously communicate even if commanded off. The only way to make sure that this Yes, that's what any normal phone does anyway :) - Werner
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, Mike (mwester)
it=20 The amp is supposed to be inactive by default, as long as no signal is comi= ng=20 in to drive it. Think of it as an active audio box that's "always=20 on"(standby) and activates whenever a signal comes in. Oscillators (transmitter) are forced powered down. So there should be no issues here. /j
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkh3LcMACgkQOjLpvpq7dMqefwCaAjYN8f2MEoHbrtzU2XC7yZ4Z MgcAn2Dt0khDqyhz1szDfumEeQU4A0IG =kFqZ -----END PGP SIGNATURE-----
Can (2) and (3) run at the same time? -- Alexey Feldgendler <alexey@feldgendler.ru> [ICQ: 115226275] http://feldgendler.livejournal.com
I tested running udev init in background and total boot time remained unchanged. It is obviously resource limited. Graeme
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
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
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
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
already talked about that in the meeting we had - that you found how to nuke 10 -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
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 ... :) -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
We should consider one of the alternatives to jffs2. The jury is still out on yaffs2 and ubifs is now in mainline.
On Tue, 8 Jul 2008 14:35:13 +0200 "Michael 'Mickey' Lauer" 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? -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said: | On Tue, 8 Jul 2008 14:35:13 +0200 "Michael 'Mickey' Lauer" | <mickey@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 -----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-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhzdzgACgkQOjLpvpq7dMqaFACfdfLvUIrLdKopHRhenSsa6GC5 u4kAn3JH2kDfvR1kmX3rJa39MvfbaY0m =1+mm -----END PGP SIGNATURE-----
yaffs2 is not compressing files at all. On the 02 with its 256MB flash, I'd be interested to see how it performs.
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
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhzfaUACgkQOjLpvpq7dMoI/ACeJaXrVE8VldTU0USPiXl6FwBE Q+MAn10ZTNW6USPqPXGWN2fSxxKGuI/A =5BFD -----END PGP SIGNATURE-----
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
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.
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
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. -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----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-----
oooh. no no. i was more thinking of what is out there we already have and what 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 -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
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
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@lists.openmoko.org [mailto:openmoko-devel-bounces@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@lists.openmoko.org Subject: Re: flash On Tue, 08 Jul 2008 15:03:00 +0100 Andy Green <andy@openmoko.com> 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. -- Carsten Haitzler (The Rasterman) <raster@openmoko.org>
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 -- Ross Burton mail: ross@burtonini.com jabber: ross@burtonini.com www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
