On Fri, Jun 19, 2009 at 10:49 AM, Stefan Reinauerstepan@coresystems.de wrote:
ron minnich wrote:
yes, that is why I did that struct-based stack in my v3 SMP startup.
So, which problem does this solve, the pre-ram locking or the post-ram locking?
it solves the problem of the fact that many people find the v2 smp startup code unreadable.
- the pre-ram locking can't be done with a stack, because the cache
between CPUs is not always necessarily in the same state.
well, that may be true on intel stuff. The AMD startup (at least as I understand it) depends on the BSP memory being functional enough to provide the APs with a stack.
-the post-ram code does not need it, works quite nicely already.
actually, this is only partially true. It is still possible for a malfunctioning AP to lock the BSP out. It's just not something we've seen much of.
This approach scares me... it doesn't solve the one case but makes the other case much more complex.
Please explain... I must be getting something wrong.
The struct-based stack is a direct copy of the v2 startup. Rather than using lots of fiddly offsets onto a memory area, it provides a struct which contains variables and a stack. The variables are shared between the AP and the BSP. It is a more C-like way to do it. Once I did it I realized that the on-stack variables could be used as a communications path from the AP to the BSP, most important one being a POST variable that could be set by the AP and monitored by the BSP. This is a bit better than what we have in v2, where we get one bit back from the AP which tells us "done" or "not done". No real progress indication is available. At some point, the BSP times out the AP, but there is no error code. Plus, the way in which the shared variable is set up in v2 is not very straightforward.
Anyway, I'm OK if we want to stick with what we have, but if we start hearing more about busting locks, then let's reexamine our assumptions.
ron