Aaron Durbin has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/34476 )
Change subject: Rampayload: Attempt to boot coreboot without ramstage ......................................................................
Patch Set 5:
Patch Set 5:
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
So are we packing in memory training and other things into this new stage. i.e. combine romstage and ramstage? From a high level, that's how I read what you are attempting, but there's lots of weird details there so I don't think that's happening. I still think we're doing romstge -> newstage -> kernel
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.
Can you quantify where the savings is coming from? We should have an idea what is the source of the savings because we could focus on improving that aspect in ramstage.
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)
I think it'd be instructive to do a side by side comparison of our "traditional" boot flow along w/ the actions/details each stage is performing against your target boot flow. There are high level semantics that are needed to be employed. e.g. CAR tear down for a clean program environment, etc. Those building blocks would ideally be able to be moved around to form different boot flows. However, I think we should understand the current limitations and see if we can improve those before going down a more complicated solution. e.g. do you save time by tearing down CAR in ramstage itself? i.e. prologue of tearing down CAR is in first part of ramstage.