>Hi,
>
>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.
>
>Any help is greatly appreciated!
--
Brett Kuehner
b...@pobox.com
http://www.bvk.nu
Regards,
Nishanth Menon
>Alright sounds good.
>
>Any idea how to uncompress the kernel?
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.
Brett
when you build uImage, it also builds Image (uncompressed)
(arch/arm/boot), u-boot supports uncompressed image.
Regards,
-Ragha
>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..
> >
> > Regards,
> > Nishanth Menon
--
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..
Regards,
Nishanth Menon
Ref:
[1] http://www.celinux.org/elc08_presentations/TI_OMAP3430_Linux_PM_reference.ppt
[2] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git
-> see pm branch
just saw [1] - looks like the support might be broken at the moment..
Regards,
Nishanth Menon
http://marc.info/?t=124101327100001&r=1&w=2