Re: [coreboot] [RFC] Always include coreboot banner in console independent of log level

[Paul Menzel]

Dear Martin, dear Julius,

Am Freitag, den 24.02.2017, 16:41 -0700 schrieb Martin Roth:
> My argument is that if nothing at all is shown, its difficult to know if
> that's because nothing needs to be shown, or because the console is busted.

That was my original motivation too. The image for QEMU with log level
WARNING, didn’t print anything to the console, so I didn’t know if QEMU
was called incorrectly, or if there was another problem with the build.
> Maybe we break up the banner, and don't print both romstage and
> ramstage banners, but just the romstage banner.  I'd say that just printing
> the coreboot version should be sufficient, especially since the build date
> is based on the commit id:
>
> So at loglevel 0, we get:
>   coreboot-4.5-1079-g613350897d

But can’t the version for romstage and ramstage differ? (Though very
unlikely.)
> At loglevel 5 (or whatever) we get the additional text:

With the current definitions, it should be log level 6 (INFO). 5
(NOTICE) is “Normal but significant conditions.”, while 6 (INFO) is
“Informational messages.”. (No idea how “significant” condition is
defined.)
> coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage
> starting...

Julius, do you have any measurements, how much time printing 100
characters over the serial console would take?

Also, does that really matter for production systems? What log level
are they normally shipped with?

Thanks,

Paul

[RFC] Always include coreboot banner in console independent of log level

[Julius Werner]

> > coreboot-4.5-1079-g613350897d Fri Feb 24 14:59:42 UTC 2017 romstage
> > starting...
>
> Julius, do you have any measurements, how much time printing 100
> characters over the serial console would take?

Back of the envelope calculation for normal 115200 baud says

1000ms * 100 chars * 9 bits per char (with parity) / 115200 bps = 8ms

Certainly not the end of the world, but I just don't like unnecessary
inefficiency even if it's small. I also feel like it should be a reasonable
use case to say "I want *only* warnings/errors" (e.g. so you can pipe them
directly into some firmware error log or something), but maybe that's just
me.
> Also, does that really matter for production systems? What log level
> are they normally shipped with?

If you're talking about Chrome OS production systems, we just set BIOS_SPEW
but disable the UART,  so from that point I don't care either way.