Hi Ron.
For me the reason of decreasing the log level is boot time and not flash size. As we dump the log over the slow UART, a default log level of 7 or even 8 would mean several more seconds of boot time. In the past I had thought a few times about it and had the idea of separating CBMEM log from UART log with own log levels. In this scenario you can have a low level on UART which gives you boot time benefits while you can get the full log from CBMEM once you made it into the OS. I admit that in this case you will lose the needed debug information once your board will not boot, but this is a case which needs to be treated in a special way anyway.
Werner
-----Ursprüngliche Nachricht----- Von: ron minnich [mailto:rminnich@gmail.com] Gesendet: Sonntag, 10. Februar 2019 20:20 An: Zvi Vered Cc: Gregg Levine; coreboot Betreff: [coreboot] Re: 4.9: FSP debug level (0-3) Wichtigkeit: Hoch
I had a discussion once with Russ Cox, a fairly well known person in this business :-), as he was reviewing some kernel code I'd written which was chock full of
#if DEBUG
as is the custom in so many kernels.
He really disliked the style and let me know so. His point was that in many cases, cpp-based debug macros are abused. They turn off code not in the critical path, so there is not a real performance-based justification for using them. In many cases, compiling out debug code means that, most of the time, when you really needed it, it is not there -- as in this case.
Which gets to my question: why on earth are there debug builds of FSP? Why isn't debugging always on? Debug stuff should always be on IMHO. As we've discovered, a lot of UEFI debug code *won't compile any more* because people got in the habit of leaving it out. You turn on debug macros and the UEFI build fails. We can imagine a day in which it's no longer possible to build a debug FSP either.
I realize we have the same kind of "debug build' behavior in coreboot, but we only ever enabled turning the debug level down in coreboot, ca. 2001, because FLASH space was tight -- this is why we have, e.g., the MAX console log level stuff. But turning down debug prints in coreboot was always a problem for me because, as always, the one time you really needed those prints, you found they were compiled out! But don't we leave all that stuff enabled by default nowadays? That's what I recall anyway ...
If anyone from Intel is reading this ... what's the reason for debug builds of FSP vs. non-debug? That approach has not worked tremendously well in UEFI, why have it in FSP?
On Sat, Feb 9, 2019 at 11:43 AM Zvi Vered veredz72@gmail.com wrote:1FAFB2926
C0.D0: SPD not present. C1.D0: SPD not present.
oh boy. No SPD? Do you need to set up some fake SPD then?
ron _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org