Patch Set 5:
What are the limitations of romstage/ramstage pair that this is trying to solve?
we can remove romstage from the scope of coreboot-lite/rampaylaod work discussion as romstage is going to stay here for sure
what we are trying to achieve is that avoid loading 1 dedicated stage (i.e ramstage here) and if we can just pull in required functionality into previous stage for booting a platform.
So far we have seen ~240ms of time saving in this approach with some known WA.
migrating to rampayload might be long pole for chrome platform but we might think about some use case for coreboot to compete with ABL, where bootloader has to be more thinner and meet certain boot time restriction.
As I noted before, you'll be pulling in almost all of the functionality from ramstage in order to get a system proper configured.
i'm also afraid of same situation but so far if i look at my POC patch for reference. From POC CL to here, i have almost ported required functionalities like MP init, AML generation into this CL.
Now next steps would be thinking about possible solutions to make dynamic BAR assignment of limited PCI resource (Input, Output and boot device) and see how do we create run time AML for peripheral devices (touch, tpm etc). In this process we might need to compile FSP call into previous stage (postcar here)
To view, visit change 34476. To unsubscribe, or for help writing mail filters, visit settings.