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:rminn...@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 <vered...@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-le...@coreboot.org _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
