]From: Kevin O'Connor ]On Wed, Oct 13, 2010 at 06:43:21PM -0400, Corey Osgood wrote: ]> On Wed, Oct 13, 2010 at 6:15 PM, Nasa nasa01@comcast.net wrote: ]> > I have read a little about payloads and noted that SeaBIOS would ]> > be the easiest way to go... However (this being important for the ]> > flash chip), I didn't see anything about the benefits of putting a ]> > linux kernel as a payload. I did read from the FAQ that most ]> > chips aren't large enough to have the kernel added as a ]> > payload. If my goal is the fastest boot time possible, while ]> > still supporting the basic system, would going to a Linux payload ]> > be the way to go? If so, what size flash chip should I get? ]> ]> Most likely, you won't be able to find a flash chip large enough to ]> support a full-fledged linux kernel for a payload. It's been done ]> (like here: http://youtu.be/nuzRsXKm_NQ ), and would probably be the ]> fastest way to go, but you would have to give up a lot of kernel ]> features in order to get the kernel down to small enough of a size. If ]> you're going with a linux payload though, I'd look at FILO rather then ]> SeaBIOS, just because you don't need the legacy BIOS features that ]> SeaBIOS implements. ] ]SeaBIOS boots much faster than filo. The time to initialize the ]legacy BIOS interface is on the order of microseconds so it doesn't ]have any real impact on boot time. On the other hand, SeaBIOS has ]several optimizations that filo lacks (eg, parallel hardware init, ATA ]DMA, EHCI USB). ] ]In my tests, the fastest way I could boot my machine was to use ]SeaBIOS and launch linux from an SSD. The SSD I tried (OCZ) had no ]detectable "spin up" delay, and could transfer over 100MB per second. ]The built-in flash, on the other hand, could only read at 1MB per ]second. (So, for a 2MB linux flash image there could be a 2s load ]delay - compare to 50K seabios flash image and 2MB Linux SSD image at ]~100ms load delay.) ] ]There is a tool in the SeaBIOS repo (tools/readserial.py) that can ]generate timings from normal serial debug output. It can be used with ]SeaBIOS, Linux, and FILO. I encourage anyone interested in boot times ]to run tests and compare the results. ] ]-Kevin
I have worked on boot time reduction in the past, and have collected timings for AC power off to a DOS prompt. This measurement can be automated by reading the acpi pmtimer from a DOS autoexec utility. The BIOS I used for one project is a stripped down AMI legacy BIOS. The BIOS is stripped of unneeded features, yet still complete enough to boot Win7. With USB turned off, a 5400 rpm 2.5 inch sata drive, and a hacked vbios, the power on to DOS boot time runs around 800 ms. USB adds as much as a couple hundred ms as I remember. An Intel x25-e SSD drive removes 200 ms. The fastest booting system from tier 1 commercial notebook vendor is significantly below 3 seconds. This one uses UEFI BIOS. A well tuned Insyde UEFI BIOS boots in around 3.5 seconds. Apple's UEFI is probably among the fastest, though I have never tested one.
For coreboot+seabios, I get a power on to DOS boot time of around 2.7 seconds. This is with USB enabled and a 5400 rpm sata drive. While 2.7 seconds is good, there is probably room for improvement. I would like to see a bigger coreboot advantage over UEFI. All of these numbers are for AMD hardware with family 10h processors.
You are right about bios flash chip performance. While it is improving, it is a bottleneck and reads from the bios flash chip should be avoided. As I remember from tests I did, the slowest is an EC ckip that reads a parallel flash and then emulates an LPC flash. This could be read at about 700 KB/s. A directly connected LPC flash chip reads at about 1.4 MB/s. Current generation AMD systems can read from SPI flash at about 3 MB/s. Future generations will be faster, though no match for a hard drive.
Thanks, Scott