I'd like to add another option: software suspend (aka hibernate); see this page for details.
So ive got some stuff bookmarked about booting linux fast and i just thought i'd share, i know some of this has been posted before
http://www.linuxbios.org/ < replacing the usual bios with a linux one
http://www.bootchart.org/ < kind of like bootvis for windows without the automated optimisation
Reducing OS Boot Times for In-Car Computer Applications:
Parallelize Linux system services to improve boot speed:
Signature: [==||========] 20% complete
Signature: [==||========] 20% complete
I'd also like to mention another means of making it "boot" faster, particularly for the car enviroment. Lets say you have a super cool carputer with Network, GPS, and an SQL database for your library. If these devices aren't needed immediately, then you can take them out of your rc scripts and start them AFTER the player has started. This way you will be up and playing music while your waiting for everything else to be fully functional. Sort of like Parallelizing I suppose.
Definitely.Originally Posted by TheLlama
The IBM developer article mentioned above goes into, among other things, getting "the important stuff" out of the way first, then loading subsequent procs that depend on said stuff.
The article specifically talks about Linux boot procedures, but the same can apply to running apps - it a small leap to put your audio player on that list of "important stuff."
Llama is right. We use a custom kernel and we've compiled almost everything as modules.
We load our UI first (from a custom startup script) and we then insert the modules in a sequential fashion. We're using tinylogin (compiled for ARM7) for to automatically login as root on the box. We also re-wrote the startup scripts from scratch. We're on LFS 5.1; so we're not using any off-the-shelf distro. We wrote our own.
As for tweaking your kernel - there are TONs of ways to accelerate it's startup time. One way is to use XIP (eXecute In Place) directly from Flash. The kernel is uncompressed in flash and loads into ram in a 1 to 1 basis. The net result is that the kernel doesn't need to decompress and it loads about 1100ms faster. You can't do this on x86 architecture because of hardware limitations (ahem 640k limit; thanks Bill!). Here's a list of some great kernel tweaks:
Apply a preset "loops per jiffie" patch
Apply a patch for eliminating IDE probing; You can preset your IDE data after the kernel enumerates the device for the first time. Subsequent boots never have to probe again.
Remove all the "printk()'s" from the kernel source. This eliminates all the startup text, but you can still debug via serial.
We've had NUMEROUS people ask for a copy of the distro. Here's our standard reply: Our distro is not for x86 computers. It won't work on an EPIA or anything like that. We're on an embedded BIOS-less platform. As such, we can't provide you with a CD-Distro for your carptuer. Sorry!
By tweaking the hell out of our kernel, we're down to about a 5 second boot. That's power-on to prompt. Our app loads in about 2-3 seconds. A cold-start boot takes roughly 8 seconds from power to UI.
We have hardware suspend and we can resume from that in about 2500ms.
Sorry for the super long post - I just wanted to provide as much info as possible.
Thanks cbergeron, that was a very informative post. I'm familiar with jiffies as I had to use them for my VFD timing. However, what do you mean by a preset "loops per jiffie" patch? Sounds like you have some good things going with your embedded ARM board. I am currently using an advantec half-sbx board (667mhz eden). When I finish my player I will evalutate the resource load and get a more watered down board. Check your PMs.
I'm currently running Linux 2.6.8 (Gentoo distro) on an AMD64.
I'll prolly upgrade to 2.6.10 in the next day or so.