On Fri, Jun 19, 2009 at 6:15 PM, Carl-Daniel Hailfingerc-d.hailfinger.devel.2006@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) { #ifdef CONFIG_CONSOLE_BUFFER buffer_tx_byte(byte, arg); #endif #ifdef CONFIG_CONSOLE_SERIAL if (byte == '\n') { uart8250_tx_byte(TTYSx_BASE, '\r'); #ifdef CONFIG_CONSOLE_PREFIX 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, ' '); return; #endif } uart8250_tx_byte(TTYSx_BASE, byte); #endif }
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: src/console/vga_console.c src/console/logbuf_console.c src/console/uart8250_console.c src/console/btext_console.c
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 src/console/printk.c
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 :-)
ron