On Wed, Dec 24, 2008 at 5:20 AM, Corey Osgood <corey.osgood@gmail.com> wrote:

On Wed, Dec 24, 2008 at 5:09 AM, ron minnich <rminnich@gmail.com> wrote:

On Wed, Dec 24, 2008 at 12:14 AM, Corey Osgood <corey.osgood@gmail.com> wrote:

> *phew* I was worried that was how v3 was always going to run. As for those
> times Ron, stage0 takes <1 second, initram is ~5 seconds,

the initram seems way too long. But that stage 2 tells me you have
some real problems with your dram setup.

It could have been less, timing output from a serial port with a stopwatch isn't very exact. I don't think there's anything wrong with the dram setup, I ran memtest86 overnight without any errors.

I know nothing about this part. I wonder if you could dump your mtrr
settings and let us see them.

Sure, what point do you want them from? End of stage1?

Here's a boot log that dumps them right after serial comes up, again just before disable_car(), and once more before loading stage2. After that mtrrs aren't touched until stage 2 phase 6 AFAIK. I wish I knew more about this stuff, I should probably make some time to read those Intel x86 programming guides.

Alright, it was ridiculously simple. I added #defines for XIP_ROM_SIZE/BASE in stage0.S like core2 has, and now it boots MUCH MUCH faster, until it gets into phase6_init and does the MTRR init that I brought in from v2, after that it slows back down. I'll send a patch to set that properly and to fix it in core2 (currently hardcoded to a 1MB rom) soonish. Is the proper solution to the MTRR problem to teach that mtrr_init() not to mess up the caching MTRR, to set the caching back up after init, or just to not bother with the late init?