Modify U-Boot?

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.

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!

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

Alright sounds good.

Any idea how to uncompress the kernel?

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.. :slight_smile: 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

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.

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.

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

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