[coreboot] locking...

ron minnich rminnich at gmail.com
Sat Jun 20 06:30:28 CEST 2009

On Fri, Jun 19, 2009 at 6:15 PM, Carl-Daniel
Hailfinger<c-d.hailfinger.devel.2006 at gmx.net> wrote:

> v3 uses a hack which does not depend on the device tree at all.
> Basically, if you add a console driver to the output list in Kconfig, it
> will be called always. I need to dig up my patches to postpone/discard
> output before driver init.

v2 does not depend on the device tree at all. It depends on linker
sets, specifically the linker set for console_drivers.

V3 -- I am not sure I understand you. printk in v3 calls
console_tx_byte, which does this:

void console_tx_byte(unsigned char byte, void *arg)
        buffer_tx_byte(byte, arg);
        if (byte == '\n') {
                uart8250_tx_byte(TTYSx_BASE, '\r');
                uart8250_tx_byte(TTYSx_BASE, '\n');
                uart8250_tx_byte(TTYSx_BASE, '(');
                uart8250_tx_byte(TTYSx_BASE, 'C');
                uart8250_tx_byte(TTYSx_BASE, 'B');
                uart8250_tx_byte(TTYSx_BASE, ')');
                uart8250_tx_byte(TTYSx_BASE, ' ');
        uart8250_tx_byte(TTYSx_BASE, byte);

The only choices I know if in v3 are serail console and buffer
console. How do we add others? Form what I can tell, by adding
code. Is there something in there I am not aware of?

> coreboot-v3/lib/console.c:console_tx_byte() is the code I'm talking
> about. Maybe not the greatest code in the world, but without any RAM
> dependencies.

Because it does not allow the addition of new consoles via linker sets
as we do in v2. And it doesn't do locks. It's not smp-safe.

I am not opposed to getting rid of the v2 linker set approach for
consoles. I think it would simplify life quite a bit. But let's
take this a little slowly. I'd rather we get (e.g.) all of cbfs
working before we take on more surgery.

There are four console drivers available in v2:

I wonder how many people even know it works this way? Or what
__console means :-)

> I advocate the compile once, use everywhere stance of v3.

But we need to face some facts here. v3 does not have the range of
capability of v2. There is much that v2 does that v3 does not. it's
not always a fair comparison for v3 to say "we are so much better"
given that v2 can say "we support way more hardware" :-)

BTW, I mis-spoke: all the various printks do end upcalling do_printk.
But it's a DIFFERENT printk for ROM and RAM code. ROM code calls the
arch-dependent printk. RAM code calls the arch-independent printk in

The src/console/printk.c absolutely depends on linker sets, presence
of RAM, spin_locks, and so on, as it calls
src/console/console.c::console_tx_byte, which tests the initialized
variable and uses console_drivers.

Again, I have no problem with changing this, at a later time, when we
can think it through a bit more. But the RAM code arguably does what
we want now -- SMP-safe printing. So let's get back to Ward's problem


More information about the coreboot mailing list