coreboot_apc woes

[Patrick Georgi]

Hi,

Seems that I messed up the conversion of the coreboot_apc stuff over to
kconfig. Short version: It doesn't build, and we never noticed.

It affects amd/serengeti_cheetah and supermicro/h8dme, the other two APC
boards in newconfig lost that flag on transition
(amd/serengeti_cheetah_fam10 and iwill/dk8_htx), where amd/s_c_fam10
doesn't really support that mode anyway.

So there are at most three boards that require this feature (which seems
to be about distributing ram training across the CPUs). I'm not sure how
much time is saved by that (it doesn't do RAM clearing for ECC in the
AP-local code, as far as I can see!), and it would be a rather large
special mode in the build system for three boards (though that could
probably be expanded to 'all K8 boards')

Where to go from here, shall we fix it, or drop it?

Patrick

[Myles Watson]

> So there are at most three boards that require this feature (which seems
> to be about distributing ram training across the CPUs). I'm not sure how
> much time is saved by that (it doesn't do RAM clearing for ECC in the
> AP-local code, as far as I can see!), and it would be a rather large
> special mode in the build system for three boards (though that could
> probably be expanded to 'all K8 boards')

Having it be an option is nice.  I wouldn't expand it to all K8/fam10 until
it's been tested on a few more boxes.
> Where to go from here, shall we fix it, or drop it?

Besides complicating the build system, how much work is it to fix?  My vote
would be to fix it, since it worked in newconfig.

Thanks,
Myles

[Stefan Reinauer]

On 2/26/10 12:05 AM, Myles Watson wrote:
> Besides complicating the build system, how much work is it to fix?  My vote
> would be to fix it, since it worked in newconfig.

How much time did it actually safe us?

I'm not sure the AP handling on K8/FAM10 ever "worked" reliably... we
had some reports of PCI access race conditions for example.
Then there is the output locking problem in romstage that hasn't really
been fixed.

So, there is more than one reason not to keep the other CPUs doing stuff
before RAM is up.. Dropping this facility will certainly increase
reliability of coreboot significantly.

Just fixing it up so it works as well as it did before is easy.

Fixing it in the sense of the word is a lot more work and I'd love to
see if it's worth it. i945 does a similar thing like DQS (called rcven)
and it  takes a few ms at best. Sure, milli seconds are evil and slow,
but if we have to do decent inter-cpu-locking in romstage, it sure won't
fly either, just get a whole lot more complicated.

So... who knows actual numbers...?

[ron minnich]

I'd like to hear Marc Jones comment on the value of this feature.

My impression was that it has little value.

ron

[Myles Watson]

On Thu, Feb 25, 2010 at 4:14 PM, ron minnich  wrote:
> I'd like to hear Marc Jones comment on the value of this feature.
>
> My impression was that it has little value.

I must be confusing it with another feature.

Myles

[Marc Jones]

On Thu, Feb 25, 2010 at 4:14 PM, ron minnich  wrote:
> I'd like to hear Marc Jones comment on the value of this feature.
>
> My impression was that it has little value.

It has been a long time since I have looked at this too and my focus
was really on the Fam10 stuff. IIRC the feature isn't used in the
normal build of Serengeti_Cheetah. It apc_auto isn't built in if
failover is used. With failover, HT reset, and memory init, it got
extremely complicated (error prone) with this path and it didn't save
that much time. Did those other platforms really use it or was it just
an option left in?

What does Ward's K8 platforms use?

Marc