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