>> ReportStatusCode() to report debug information which coreboot prints using printk.
> can you point me to the code integrating this? I could find this identifier only in vendorcode/ headers. Is it for debugging?

I meant code calling back to the coreboot console in general for debugging. A few examples:
1) https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/northbridge/intel/sandybridge/raminit_mrc.c#153
2) https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/drivers/intel/fsp2_0/fsp_debug_event.c#20

> I thought this was kept optional--one of the many things dumped into our repo that didn't take off.
Just checked and it's enabled by default oO, but I could disable it and coreboot built.
Does anybody use this PPI "feature" in a product?

I thought the CPU PPI was enabled by default and necessary(?) on all Intel products (except xeon-sp) since Intel Icelake.
If the PPI is not provided the FSP will do the whole CPU init on its own:
/** Offset 0x06B0 - CpuMpPpi
  <b>Optional</b> pointer to the boot loader's implementation of EFI_PEI_MP_SERVICES_PPI.
  If not NULL, FSP will use the boot loader's implementation of multiprocessing.


On Wed, Aug 23, 2023 at 11:14 AM Nico Huber <nico.h@gmx.de> wrote:
Hi Arthur,

On 23.08.23 10:41, Arthur Heymans wrote:
> We already have code similar to ReportStatusCode

can you point me to the code integrating this? I could find this
identifier only in vendorcode/ headers. Is it for debugging?

> and ramstage PPI so maybe
> it's not a problem.

I thought this was kept optional--one of the many things dumped
into our repo that didn't take off. Just checked and it's enabled
by default oO, but I could disable it and coreboot built. Does
anybody use this PPI "feature" in a product?

Nico