[coreboot] More SeaBIOS timings

Kevin O'Connor kevin at koconnor.net
Tue Dec 22 02:34:37 CET 2009

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

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


More information about the coreboot mailing list