ron minnich has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/32667 )
Change subject: {arch, console, drivers, include, lib, soc}: Add new features in postcar ......................................................................
Patch Set 8:
Patch Set 8:
As for Aaron's concerns about postcar bloat: Maybe it's more future proof to strip down ramstage (and make all its features available à la carte)? I guess the main issue there is that full blown pci resource allocation is one of the big ticket items to avoid, and without that, everything else falls apart as well, so maybe not much is gained by going that way?
I think stripping down ramstage might work someday, but we need to know what we need to know first, in terms of what a minimal ramstage is; all while the ramstage continues to grow. Plus, no matter how you cut it, a stripped down ramstage is still something you have to load, vs. a slightly bigger postcar.
I'd like to try this experiment, though maybe not with this approach.
I liked Patrick's idea of "ENV_LAST_STAGE", which is then set by various checks in rules.h. I'm not a big fan of rules_skip_ramstage.h, since now people have two places to look; is there some compelling reason that makes this new file required? I think you could condition CONFIG_SKIP_RAMSTAGE on x86 maybe, and then the test on architecture in rules_skip_ramstage.h is not needed?
coreboot has traditionally tried to be friendly to experiment, and I think this is one case where it makes sense. I don't see the point of denying the ability of people to run without a ramstage if that's what they need. It's fine if people don't like it or want to use it; I don't see why we would deny this type of change to those people who want to use it. Further, subrata has shown, by measurement, that it provides a significant improvement in boot times.