[coreboot-gerrit] Change in coreboot[master]: [WIP]Allow to build romstage sources inside the bootblock

[Aaron Durbin (Code Review)]

Attention is currently required from: Arthur Heymans, Raul Rangel, Furquan Shaikh, Philipp Hug, ron minnich, Stefan Reinauer, Angel Pons, Subrata Banik, Julius Werner, Andrey Petrov, Patrick Rudolph, Piotr Król, Jason Glenesk, Michał Żygowski, Martin Roth, Marshall Dawson, Ron Minnich, Felix Held.
Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/55068 )

Change subject: [WIP]Allow to build romstage sources inside the bootblock
......................................................................

Patch Set 4:

(1 comment)

Patchset:

PS4:
> > Could you please elaborate on what diligence was done in the analysis w.r.t. semantics of existing code? I know we've built a lot of infrastructure around ENV_x, etc. This change obviously allows previously mutually exclusive settings to coexist.
>
> So version 1 of this path did the same without touching rules.h. You end up needing a lot of 'ENV_ROMSTAGE || ENV_BOOTBLOCK && !CONFIG(SEPARATE_ROMSTAGE)' in the code which makes maintaining it a lot harder. As you generally want to take the paths romstage took in bootblock, like init cbmem, run ramstage/postcar , ... this seemed like a good idea.
>
> There are places where this is weird or where things might break, a few I could think of:
> ASAS is only initialized inside the romstage entry stub
> the Kconfig flag NO_BOOTBLOCK_CONSOLE or !BOOTBLOCK_CONSOLE possibly breaks things as console is likely not optional in romstage.
>
> I don't have a strong opinion on redefining ENV_ROMSTAGE, but it looks to me as the easiest way to achieve this setup.

I was thinking of similar stanzas like this: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src...

While the cbmem hooks don't necessarily apply here as problematic, I was thinking there are other places where there's if/else assuming mutual exclusion for the ENV_* macros.

I wasn't suggesting a change to the approach. I wanted to hear about what was uncovered in the existing code base w.r.t. implicit assumptions.