I've completed another round of improvements and timings on my epia-cn machine. From power-on to grub serial menu is now 750ms. For comparison, the same equipment with the factory bios takes 9.9s. (To be fair though, I needed to remove the 2.5s boot menu delay in SeaBIOS to get to 750ms.)
More background info is available in the thread at:
http://www.coreboot.org/pipermail/coreboot/2009-December/054561.html
A breakdown of the 750ms reveals:
* cpu appears to start running around 350ms
* smbus power stabilizes around 400ms
* 20ms to program ddr ram controller
* 15ms to uncompress coreboot_ram (note flash access wasn't a factor - see below)
* 10ms to run coreboot_ram
* 35ms to read and uncompress seabios from flash
* 40ms to read and uncompress via vga rom from flash
* 200ms to run via vga option rom and turn on vga
* 10ms for remaining hardware init (the hardware init runs in parallel with the 240ms for vga option rom - the 10ms is what remains after vga finishes).
* 10ms time spent in grub (and in grub reads from disk)
Changes since last time:
* I'm using a SATA SSD (OCZ Vertex 30G) to store grub (and the OS). This device doesn't seem to require a "spin up" delay.
* I've enhanced SeaBIOS to support ATA bus mastering DMA. I'll send a patch out separately with the details. This dramatically increases the speed of disk reads.
* I've commented out the calls to wbinvd() in coreboot's mtrr cache_disable logic - those calls are expensive and the code seems to work without it.
* While waiting for the smbus to power stabilize, I added reads to the flash to seed the cache with the bootblock and coreboot_ram. This eliminates the costly flash read time for that code.
Also interesting is adding a gPXE rom (rtl8169) only added 50ms to the total SeaBIOS boot time (I set gPXE's BANNER_TIMEOUT to 0).
-Kevin
What's interesting about your 750ms is that it meets the requirement I saw at a FOSDEM talk that the boot time needed for an auto computer was 800ms, so that users could see blinky lights in less than one second. You're showing very impressive performance here for an x86.
You've also raised the bar again for proprietary bios -- they've been pretty boastful lately of hitting the 5 second or so mark, and you're showing we're still way faster. Plus, most of the time, we've found the proprietary BIOS vendors are being very creative in their timing claims :-)
Really great work!
ron
This looks like it was an interesting task. I had some questions and comments from previous fast-POST exercises:
On Mon, Dec 21, 2009 at 12:44 AM, Kevin O'Connor kevin@koconnor.net wrote:
- cpu appears to start running around 350ms
Do you have a scope at all?. The only way to know this number for sure would be to put a scope on the reset wire and the rs-232 to see how long the power sequence takes.
- smbus power stabilizes around 400ms
I don't understand this. SMBus power is 3.3V, and I don't know why a platform would be executing code before 3.3V is stable. The ATX is turning on 3.3, 5, and 12 *first*, then the various regulators, including the core regulator, come on after that. There should be various hardware voltage monitors keeping things in reset until all the voltages are up. Am I not understanding something? What exactly do you mean by "smbus power stabilizes"?
- I've commented out the calls to wbinvd() in coreboot's mtrr
cache_disable logic - those calls are expensive and the code seems to work without it.
You removed *all* of them? You might just be getting lucky, that is a bit dangerous.
Just a note: PCI has a specified time called Trhfa which is the time from reset going high to the first allowable configuration access. It is specified as 2^25 clocks, which is 1 second for 33MHz PCI and 500ms for 66MHz PCI. You have to heed that if you want to generically support random PCI plugin cards. If you are making fixed-configuration concessions, then you can do it as fast as your particular hardware allows.
On Mon, Dec 21, 2009 at 10:29:54AM -0500, Tom Sylla wrote:
This looks like it was an interesting task. I had some questions and comments from previous fast-POST exercises:
On Mon, Dec 21, 2009 at 12:44 AM, Kevin O'Connor kevin@koconnor.net wrote:
- cpu appears to start running around 350ms
Do you have a scope at all?. The only way to know this number for sure would be to put a scope on the reset wire and the rs-232 to see how long the power sequence takes.
I don't have a scope. The boot doesn't start until I release the power button, and when I do that this machine seems to write a null byte to the serial port. All my timing reports are deltas from this furst null byte. I can't perceive any timing difference between my releasing the button and the null showing up on the screen.
In any case, my main emphasis is on the software, so if the actual hardware init is a few ms more, it doesn't really matter that much to me.
- smbus power stabilizes around 400ms
I don't understand this. SMBus power is 3.3V, and I don't know why a platform would be executing code before 3.3V is stable. The ATX is turning on 3.3, 5, and 12 *first*, then the various regulators, including the core regulator, come on after that. There should be various hardware voltage monitors keeping things in reset until all the voltages are up. Am I not understanding something? What exactly do you mean by "smbus power stabilizes"?
It's a vt8237r thing - basically I need to add:
--- src/southbridge/via/vt8237r/vt8237r_early_smbus.c (revision 4967) +++ src/southbridge/via/vt8237r/vt8237r_early_smbus.c (working copy) @@ -147,6 +147,9 @@ die("Power management controller not found\r\n"); }
+ while (!(pci_read_config8(dev, 0x82) & (1<<6))) + ; + /* * 7 = SMBus Clock from RTC 32.768KHz * 5 = Internal PLL reset from susp
or the smbus access is unreliable. Rudolf pointed this out to me. I believe the smbus_fixup() code later in the same file is an attempt to workaround this same issue.
- I've commented out the calls to wbinvd() in coreboot's mtrr
cache_disable logic - those calls are expensive and the code seems to work without it.
You removed *all* of them? You might just be getting lucky, that is a bit dangerous.
I removed the ones around the mtrr loading. I'm not sure why adding mtrrs requires a cache flush - I need to research this further. If anyone does know, let me know.
Just a note: PCI has a specified time called Trhfa which is the time from reset going high to the first allowable configuration access. It is specified as 2^25 clocks, which is 1 second for 33MHz PCI and 500ms for 66MHz PCI. You have to heed that if you want to generically support random PCI plugin cards. If you are making fixed-configuration concessions, then you can do it as fast as your particular hardware allows.
Interesting. This machine didn't have anything in its pci slot.
-Kevin
It's a vt8237r thing - basically I need to add:
It is PSON gating. RTC Power Well registers must be avoided to access until the gating is complete. SMBus happen to be power well register ;)
Kevin, I think we need some fix with the timeout maybe? Definetely for the AT PSU. They need to manually finish some power sequencing.
Rudolf
-
Kevin O'Connor -
ron minnich -
Rudolf Marek -
Tom Sylla