ron minnich wrote:
On Fri, Jun 19, 2009 at 9:13 AM, Myles Watsonmylesgw@gmail.com wrote:
Another option would be to only let the BSP print messages by default. That would clean up most people's logs most of the time.
yes, that is why I did that struct-based stack in my v3 SMP startup. The struct formed the base of the AP stack.
This sounds dangerous.. a stack is never "struct"ured.
We could put a simple print buffer in there and require that the BSP print out AP boot messages.
This is complexity from hell. Why not a decent locking mechanism. Plus, reducing the incredible amounts of useless output coreboot produces even at DEBUG level.
This would be a bit better than trying to resolve this locking issue.
Why? I disagree. Because we still need locking and inter cpu communication in order to print a string.
Do we really want to re-implement IPC and shared memory in coreboot? I hear we are becoming a kernel.
I never got this done, I only got the "AP post code"
v2 has / used to have working locking code since it was first ported to opteron. It may be that it broke while adding 5 more printks but it is there somewhere.
We have made a decision that the BSP is always assumed to work. Any strategy should be build around this assumption, and the further assumption that we ought to contain the AP so that it can not prevent the BSP from doing its job.
Making the BSP poll for the APs (which is what we would do if we need to check the APs shared memory) basically renders the BSP unusable to do stuff while waiting for the APs.
With simple locking, everything can run in parallel, and only serial output needs to get synced. Which is what we actually want.
Stefan