On 13.10.2008 05:30, Corey Osgood wrote:
On Sun, Oct 12, 2008 at 11:04 PM, Peter Stuge peter@stuge.se wrote:
Carl-Daniel Hailfinger wrote:
I said in the past that we shouldn't send stuff to serial before serial is set up, but my pleas have been ignored
Yes.
largely due to the fact that some hardware has working serial by default, so the problems were not seen in practice.
Not me. I ignore your plea because I think it is important for coreboot to communicate with the world very early on, and we should encourage it by making sure the port is enabled immediately.
Is there a way we can have it both ways? You, with your well-behaving hardware, can have serial immediately, and I with my misbehaving hardware, can store stage1 output in the console log buffer until it can be printed in initram?
Sure, we can make the behaviour a config option.
Look at it this way: right now, I have limited options:
- Any init that can possibly fail with a message goes in initram.
- Check from initram if stage1 init failed.
- Assume stage1 init will never have any problems.
All options suck :(
Heh. You basically want printk to buffer until ready, then flush to serial and have the buffering behaviour (yes/no) controlled by a config option. Or you could change the following sequence in arch/x86/stage1.c:stage1_main()
hardware_stage1(); // uart_init(); // initialize serial port /* Exactly from now on we can use printk to the serial port. * Celebrate this by printing a LB banner. */ console_init(); if (bist!=0) { printk(BIOS_INFO, "BIST FAILED: %08x", bist); die(""); }
to
hardware_stage1_early(); // uart_init(); // initialize serial port /* Exactly from now on we can use printk to the serial port. * Celebrate this by printing a LB banner. */ console_init(); if (bist!=0) { printk(BIOS_INFO, "BIST FAILED: %08x", bist); die(""); }hardware_stage1();
To be honest, the current code does not make that much sense. We perform lots of initialization before we even check for catastrophic processor failure (bist!=0). For example, the serengeti target enables full ROM decode in hardware_stage1() instead of relying to the call to enable_rom() much later. It would be advisable at least to get printk running first and delay everything else until after printk over serial is active. Maybe we should even check bist as first instruction of stage1_main() or in stage0.
Regards, Carl-Daniel