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