I've been working over the last two weeks to try to speed up my boot
process as much as possible and I've got it down to about 20 secs.
However, the part that takes the most time seems to be U-Boot and
actually getting the kernel to start loading.
I've done the following:
Rev C2 board, loaded everything into NAND Flash (u-boot and kernel and
console-image angstrom file system). I've also removed most of the
links from Rc#.d.
Is it possible to speed up u-boot or optimize it all? I really have no
idea where to start or how to speed up my system anymore, but I think
it is possible.
I've tried recompiling the kernel and removing some of the stuff we
don't need (bluetooth, wimax, etc), but then my USB webcam will not
load (Logitech Quickcam). I've even tried reinstalling video2linux2,
uvc video, usbvideo, and ffmpeg to try to get my camera to work, but
I'm still missing something. The camera works fine with the full blown
Koen image.
Ideally, for my project, I need to boot the BB as fast as possible and
start ffmpeg (a shell script I've created has all the proper
variables), record video, and be able to login (if needed at the
time). However, my boot time is still fairly slow and when I try to
optimize it then my webcam doesn't work.
>I've been working over the last two weeks to try to speed up my boot >process as much as possible and I've got it down to about 20 secs. >However, the part that takes the most time seems to be U-Boot and >actually getting the kernel to start loading.
You might be able to have an uncompressed kernel, if it fits on the board. That might speed things up a bit. Other than that, you might try putting the kernel and filesystem back on the SD card, which I think someone mentioned is faster than the internal NAND.
I have a pretty stripped-down system (a shell and some utilities and not much else), and it probably takes 20 seconds to start up. I'm not sure you are going to do a whole lot better than that without serious kernel hacking. Why is it important to shave a few seconds off the startup time?
>I've done the following: >Rev C2 board, loaded everything into NAND Flash (u-boot and kernel and >console-image angstrom file system). I've also removed most of the >links from Rc#.d.
>Is it possible to speed up u-boot or optimize it all? I really have no >idea where to start or how to speed up my system anymore, but I think >it is possible.
>I've tried recompiling the kernel and removing some of the stuff we >don't need (bluetooth, wimax, etc), but then my USB webcam will not >load (Logitech Quickcam). I've even tried reinstalling video2linux2, >uvc video, usbvideo, and ffmpeg to try to get my camera to work, but >I'm still missing something. The camera works fine with the full blown >Koen image.
>Ideally, for my project, I need to boot the BB as fast as possible and >start ffmpeg (a shell script I've created has all the proper >variables), record video, and be able to login (if needed at the >time). However, my boot time is still fairly slow and when I try to >optimize it then my webcam doesn't work.
My project is a remote video camera that we are turning on and off by
booting the BB from a cold start each time. The whole system is
triggered by an external magnetic sensor that gives the BB power. Once
the system boots, ffmpeg starts recording video. So we want to start
recording as fast a possible and from what I've heard sleep mode isn't
really an option yet on the BB? Maybe I'm wrong?
On May 6, 7:04 pm, Brett Kuehner <b...@pobox.com> wrote:
> >I've been working over the last two weeks to try to speed up my boot
> >process as much as possible and I've got it down to about 20 secs.
> >However, the part that takes the most time seems to be U-Boot and
> >actually getting the kernel to start loading.
> You might be able to have an uncompressed kernel, if it fits on the
> board. That might speed things up a bit. Other than that, you might
> try putting the kernel and filesystem back on the SD card, which I
> think someone mentioned is faster than the internal NAND.
> I have a pretty stripped-down system (a shell and some utilities and
> not much else), and it probably takes 20 seconds to start up. I'm not
> sure you are going to do a whole lot better than that without serious
> kernel hacking. Why is it important to shave a few seconds off the
> startup time?
> Brett
> >I've done the following:
> >Rev C2 board, loaded everything into NAND Flash (u-boot and kernel and
> >console-image angstrom file system). I've also removed most of the
> >links from Rc#.d.
> >Is it possible to speed up u-boot or optimize it all? I really have no
> >idea where to start or how to speed up my system anymore, but I think
> >it is possible.
> >I've tried recompiling the kernel and removing some of the stuff we
> >don't need (bluetooth, wimax, etc), but then my USB webcam will not
> >load (Logitech Quickcam). I've even tried reinstalling video2linux2,
> >uvc video, usbvideo, and ffmpeg to try to get my camera to work, but
> >I'm still missing something. The camera works fine with the full blown
> >Koen image.
> >Ideally, for my project, I need to boot the BB as fast as possible and
> >start ffmpeg (a shell script I've created has all the proper
> >variables), record video, and be able to login (if needed at the
> >time). However, my boot time is still fairly slow and when I try to
> >optimize it then my webcam doesn't work.
On Wed, May 6, 2009 at 7:09 PM, Xander85 <alex.behr...@ng-cc.com> wrote: > My project is a remote video camera that we are turning on and off by > booting the BB from a cold start each time. The whole system is > triggered by an external magnetic sensor that gives the BB power. Once > the system boots, ffmpeg starts recording video. So we want to start > recording as fast a possible and from what I've heard sleep mode isn't > really an option yet on the BB? Maybe I'm wrong?
Go to OFF mode and wake back up -> you might want to look at linux-omap PM branch and discuss on linux-omap mailing list for details, but cold boot is pretty slow in such cases, off mode will reduce omap will be hardly sipping any power when you are in off mode.. :) and going to OFF mode is as simple as an echo command to /sys/power/state file. just cat the file to look at supported options..
The only branch available under /sys/power/state shown is "mem". I'm
not sure if this is normal or because we're running the console-image.
Does anyone else know if there are other states than "mem"? I've tried
this and it doesn't seem to work. I couldn't get it to wake back up
easily. But, I'm a newbie to this so any help would be awesome.
On May 6, 7:13 pm, Nishanth Menon <menon.nisha...@gmail.com> wrote:
> On Wed, May 6, 2009 at 7:09 PM, Xander85 <alex.behr...@ng-cc.com> wrote:
> > My project is a remote video camera that we are turning on and off by
> > booting the BB from a cold start each time. The whole system is
> > triggered by an external magnetic sensor that gives the BB power. Once
> > the system boots, ffmpeg starts recording video. So we want to start
> > recording as fast a possible and from what I've heard sleep mode isn't
> > really an option yet on the BB? Maybe I'm wrong?
> Go to OFF mode and wake back up -> you might want to look at
> linux-omap PM branch and discuss on linux-omap mailing list for
> details, but cold boot is pretty slow in such cases, off mode will
> reduce omap will be hardly sipping any power when you are in off
> mode.. :) and going to OFF mode is as simple as an echo command to
> /sys/power/state file. just cat the file to look at supported
> options..
I'm not even sure it is possible, but I would look at the uboot docs and see if they say uboot is capable of loading an uncompressed kernel image, and if it has any pointers to uncompressing a uImage file (or making a uImage that is not compressed in the first place).
>My project is a remote video camera that we are turning on and off by >booting the BB from a cold start each time. The whole system is >triggered by an external magnetic sensor that gives the BB power. Once >the system boots, ffmpeg starts recording video. So we want to start >recording as fast a possible and from what I've heard sleep mode isn't >really an option yet on the BB? Maybe I'm wrong?
I know a bunch of work has been going on in the area of omap kernel power management, but I don't know if any of it is ready for general use. But I don't think the board pulls a lot of power when idling, so if you stop your app when it isn't needed, you might be able to get decent life out of it.
>The only branch available under /sys/power/state shown is "mem". I'm >not sure if this is normal or because we're running the console-image.
By "branch", I believe Nishanth meant a kernel source branch in git (a branch in git is a set of code modifications from some baseline "standard" kernel). So if you got that particular kernel source and built and installed it, you would have the additional power-management capabilities, but you may lose some other features you have and/or see some things change.
>Does anyone else know if there are other states than "mem"? I've tried >this and it doesn't seem to work. I couldn't get it to wake back up >easily. But, I'm a newbie to this so any help would be awesome.
>On May 6, 7:13 pm, Nishanth Menon <menon.nisha...@gmail.com> wrote: > > On Wed, May 6, 2009 at 7:09 PM, Xander85 <alex.behr...@ng-cc.com> wrote: > > > My project is a remote video camera that we are turning on and off by > > > booting the BB from a cold start each time. The whole system is > > > triggered by an external magnetic sensor that gives the BB power. Once > > > the system boots, ffmpeg starts recording video. So we want to start > > > recording as fast a possible and from what I've heard sleep mode isn't > > > really an option yet on the BB? Maybe I'm wrong?
> > Go to OFF mode and wake back up -> you might want to look at > > linux-omap PM branch and discuss on linux-omap mailing list for > > details, but cold boot is pretty slow in such cases, off mode will > > reduce omap will be hardly sipping any power when you are in off > > mode.. :) and going to OFF mode is as simple as an echo command to > > /sys/power/state file. just cat the file to look at supported > > options..
On Wed, May 6, 2009 at 7:19 PM, Xander85 <alex.behr...@ng-cc.com> wrote:
> The only branch available under /sys/power/state shown is "mem". I'm
Ok, I meant kevin's PM branch [2]
> not sure if this is normal or because we're running the console-image.
> Does anyone else know if there are other states than "mem"? I've tried > this and it doesn't seem to work. I couldn't get it to wake back up > easily. But, I'm a newbie to this so any help would be awesome.
mem -> I think this should be retention.. see[1] for a nice presentation about OMAP power management. Even though the ppt was created with kernels from omapzoom.org, the concepts similar to these should hold good for linux-omap kernel also.
Disclaimer: Richard's ppt might be a little indepth at times, so here is my attempt to simplify it here: OMAP is made of multiple small parts inside it (peripherals) - each peripheral can be individually shut off or switched on as need be. in fact OMAP could also be used like a car gear, if you need higher processing power, switch to a different "operating point". each operating point is a set of voltage and frequencies that each peripheral functions -> usually the main peripherals of interest from a speed perspective are ARM and DSP, but like a car, when you speed up, you will consume more power..
Since omap is also made up of various peripherals, you can switch off many of these peripherals when not in use, in fact you can have many levels of "switch off" -> retention and off modes are general terms for which I cannot think of exact equivalents in real world except, maybe - hibernation and suspend in a PC.. in off mode, OMAP is essentially down consuming pretty few uWatts of power or less, but the SDRAM contents are retained - so when you wake back up from off mode, you can "restore" your state precisely where you left it in a matter of few uSec or so.. retention you shut lesser parts of OMAP off, so when you wakeup, you would wakeup even faster (compared to offmode), yet you wont incur the cost of keeping OMAP running continously..
Summary: time to wakeup: retention<offmode<<<<<cold boot power consumption: complete power off <offmode <retention<<<<OMAP running.
There are lots of tweaking you can do ofcourse.. I unfortunately have only a rough idea about how it all works :(.. Many folks in this list can correct/add to what I said..
On Wed, May 6, 2009 at 7:19 PM, Xander85 <alex.behr...@ng-cc.com> wrote: > Does anyone else know if there are other states than "mem"? I've tried > this and it doesn't seem to work. I couldn't get it to wake back up > easily. But, I'm a newbie to this so any help would be awesome.
just saw [1] - looks like the support might be broken at the moment..
|
