stepan at coresystems.de
Fri Jun 19 19:33:10 CEST 2009
ron minnich wrote:
> On Fri, Jun 19, 2009 at 9:13 AM, Myles Watson<mylesgw at 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
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
> 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.
coresystems GmbH • Brahmsstr. 16 • D-79104 Freiburg i. Br.
Tel.: +49 761 7668825 • Fax: +49 761 7664613
Email: info at coresystems.de • http://www.coresystems.de/
Registergericht: Amtsgericht Freiburg • HRB 7656
Geschäftsführer: Stefan Reinauer • Ust-IdNr.: DE245674866
More information about the coreboot