c-d.hailfinger.devel.2006 at gmx.net
Fri Jun 19 18:57:03 CEST 2009
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
Once we have printk in CAR for almost all CPUs, it matters even for CAR
>> However, this locking has to work when some CPUs are in CAR and others
>> are in RAM. And that's the big problem.
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
> 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
More information about the coreboot