[coreboot] locking...

[Carl-Daniel Hailfinger]

On 19.06.2009 18:13, Myles Watson wrote:
>> as we move into the multicore world, messages get harder and harder to
>> read when they are interspersed byte-wise. I propose to add optional
>> locking to printk.
>>     
> This should only matter for the time during RAM, right?  Is it a larger
> issue?
>   

Once we have printk in CAR for almost all CPUs, it matters even for CAR
stage.


>> However, this locking has to work when some CPUs are in CAR and others
>> are in RAM. And that's the big problem.
>>     
> Yuck.
>   

At least that's what I believe can happen on K8 and later platforms.


>> AFAICS we can't simply use atomic normal memory acceses since the CPUs
>> in CAR won't see that. Atomic register modifications are not possible
>> across processors AFAICS.
>> The only idea I have is abusing some MMIO chipset/CPU space which is
>> usable as scratch space. In theory, that should work. But do CPUs or
>> chipsets have such MMIO areas?
>>     
> They do.  It's hard to know if someone is already (ab)using them, though.
>   

Well, a quick (or not so quick) coreboot code search should help find
out if the areas in question are already used. Do you know of an example
fur such a MMIO area for the K8 with 690/SB600? That would help me
implement a proof of concept.


>> Of course, I'm aware that locking (if possible at all) will be highly
>> CPU/chipset dependent, but even if we can make locking work on only a
>> subset of platforms, it is still a lot better than nothing.
>>     
> Are you thinking of putting it in the ops of the cpu device?  I guess that
> only works after CAR.
>   

Actually, I'd use it as a function outside the device tree inside CPU
and/or chipset code. The device tree is available too late to be useful
here.


> 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.
>   

Except for the problem Ward is seeing right now. For that, we really
want the AP messages. And preferably they should be readable (not
intertwined).

Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/