Home ›

Reducing OS Boot Times for In-Car Computer Applications, Part III

Oct 26, 2004  By Damien Stolarz
 in
The final installment in this series--did they meet their goal of a five-second boot?
Conclusion

We did not get the five-second boot we were hoping for. Several of the reasons were specific to the EPIA board we used. The on-board EPIA video presented a problem, too, because its own video BIOS was part of the computer BIOS. Had it been a separate video card, its initialization could have been skipped altogether, leaving it for X to do when it launched. Similarly, if we had been using a more conventional sound card, such as an old SoundBlaster, we could have had sound much earlier in the boot process, around ten seconds.

The exercise did illustrate many useful things, however. It gave us a precise breakdown of where time was being lost, and it did give us a lower threshold--around ten seconds--in which we know we can get sound and video out to the user, given the right motherboard and hardware. And this is from a cold boot, pressing the power switch.

Although we never did get the video to display, even after X was booted, good news on this front came as this article was being completed. An implementation of FreeBIOS for the EPIA-M2 board has been completed by Nick Barker, and it seems to solve not only the video problems but a longstanding difficulty of booting directly from the CF slot on these boards. With further work, we could get our applications down to this new theoretical ten-second minimum.

But there are other ways to reduce the boot time for an in-car computer. To conclude, I'll list a few of the options we haven't covered yet.

  • Obvious methods include brute force--using faster processors and hardware.

  • Booting off of solid state serial-ATA hard drives, such as M-Systems' Fast Flash Disk (FFD) 2.5" Ultra ATA or BitMicro's E-Disk.

  • Hibernation, saving the memory state to hard disk and then restoring it on boot, is an excellent tool. But as memory sizes grow, the speed of this solution decreases.

  • Emulating the PalmPilot: install a second battery in the car, using a voltage isolator, and run the computer all the time. It will sleep and boot up in seconds when you wake it up.

  • Schedule your computer. Using the BIOS wake-up feature in some computers, set it to wake up a few minutes before you normally go to your car in the morning. By doing so, it will be booted fully before you even get to your car.

  • One reader of the last article suggested making the computer start booting not when you turn the key but as soon as you open the car door. An improvement to this technique is to boot as soon as the user unlocks the door with the remote keyless entry.

As general-purpose computers find their way into cars in greater and greater numbers, people will keep hammering away at boot times.

Resources

"Reducing OS Boot Times for In-Car Computer Applications, Part II"

"Reducing OS Boot Times for In-Car Computer Applications, Part I"

Damien Stolarz is an inventor, writer and engineer with years of experience making different kinds of computers talk to one another. He is the CEO of CarBot, Inc., an in-car computer company, and Robotarmy Corp., a hardware and software development house.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

LinuxBIOS on EPIA V8000

Bryan Rittmeyer's picture
Submitted by Bryan Rittmeyer (not verified) on Sun, 10/30/2005 - 03:28.

Here are some aditional notes for LinuxBIOS on the older EPIA V8000:

- Use LinuxBIOSv1. LinuxBIOSv2 is still pre-alpha.

- You can in theory use many different PLCC32 flash ICs. I am using
an AT49F040A-55JI (512kB) from DigiKey ($1.68 qty 1) in place of the
SST39F020A (256kB) VIA installed. The AT49F040A required some minor
hacking inside flash_and_burn/

- If you do use a 512kB flash device, set PAYLOAD_SIZE to 458752,
VGABIOS_START to 0xfff80000, and ZKERNEL_START to 0xfff90000.

- You MUST edit src/northbridge/via/vt8601/raminit.inc to configure
the DRAM (specifically "DIMM_PC133" and "DIMM_CL2"). If these
options are incorrect, LinuxBIOS will freeze immediately after the
initial banner.

- raminit.inc hints that you must set the FSB jumpers to 133 MHz.
Fortunately that is not the case. The V8000 runs LinuxBIOS fine at
66MHz (which reduces heat output enough to safely disconnect the CPU
fan)

- See HOWTO/EPIA for VGA BIOS support on the V8000. The extraction
procedure differs from the newer EPIA-M.

- You will probably need "ideN=noprobe" on the Linux kernel command
line to prevent IDE probe delays.

- If you need the parallel port, add "parport_init_mode=spp" on the
kernel command line to enable it.

- CONFIG_COMPRESS is responsible for the huge 3+ second delay after
"Copying LinuxBIOS to ram" and before "Jumping to LinuxBIOS". The
decompression is extremely slow, and is unnecessary, as LinuxBIOS
easily fits in the 64KB area without it.

Add "option CONFIG_COMPRESS=0" to the LinuxBIOS config file and
it will disable compression in favor of a fast, plain memory copy.
With this option, LinuxBIOS transfers control to Linux 2-3 seconds
after power on (even at 66MHz FSB with VGA enabled)!

FILO?

Anonymous's picture
Submitted by Anonymous (not verified) on Fri, 09/30/2005 - 23:41.

Don't you mean LILO? :P

I'm a computer engineer, and

Anonymous's picture
Submitted by Anonymous (not verified) on Fri, 12/31/2004 - 04:14.

I'm a computer engineer, and I would strongly advise against hot-swapping BIOS flash chips. It might work, but you risk frying your motherboard sooner or later.

bios flashing device

Anonymous's picture
Submitted by Anonymous (not verified) on Sun, 11/21/2004 - 12:06.

There's a device called an
"IOSS RD1" that will simplify the flashing of a bios
that allows you to switch bioses without having to pull
chips on a live system.

Might be easier than the process you describe.

I've never tried it so I don't know if it works or not.

search google on "ioss rd1" or look at

http://www.ioss.com.tw/web/English/RD1BIOSSavior.html

linux oracle

joe's picture
Submitted by joe (not verified) on Fri, 11/05/2004 - 10:02.

if we have Linux, which database between oracle and mysql will work better

Re: Reducing OS Boot Times for In-Car Computer Applications, Par

Anonymous's picture
Submitted by Anonymous on Wed, 10/27/2004 - 02:00.

Something is wrong with your linuxBIOS setup. I'm the maintainer of the Intel 440bx port for LinuxBIOS V1. I've got 2 different 440BX boards with 400Mhz Celerons that get to your 9 second mark in under a second.

Oh and FYI. The proper name of LinuxBIOS is indeed LinuxBIOS. Not FreeBIOS. FreeBIOS is the project that LinuxBIOS came from. The reason its still in CVS as freebios is historcial and that its a real PITA to change the CVS setup.

0.0
0.333
0.334 LinuxBIOS-1.0.0 Sat Aug 21 14:48:58 PDT 2004 starting...

Here's the first clue something is wrong. The only thing that LB does between reset and this message is enable the RAM. Taking 300mS to turn on your RAM is _WAY_ slow.

3.492 Copying LinuxBIOS to ram.
6.292 Jumping to LinuxBIOS.

2.8 seconds to copy the code into RAM?! Thats crazy. You need to subscribe up to the LinuxBIOS mailing list and post your time stamped serial log there and ask for help to get your settings correct. Something is very hosed.

Richard Smith
rsmith@bitworks.com

CE Linux Forum work in bootup time reduction

tbird20d's picture
Submitted by tbird20d (not verified) on Tue, 10/26/2004 - 02:00.

You may want to check out the work that has been done by the
CE Linux Forum on bootup time reduction. I presented a paper
at the 2004 Ottawa Linux Symposium, listing some techniques
for bootup time reduction.

These resources are available at:

http://tree.celinuxforum.org/pubwiki/moin.cgi/BootupTimeResources

White Paper
More Resources
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
More Resources
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions