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