Patch Set 5:

Patch Set 5:
> <- snip ->
>
> It seems you've identified a feature you want to add that reduces PCI enumeration and init costs (or speed up the current approach). That's a way different direction than trying to recreate ramstage on a piecemeal basis. Given what you are indicating that seems like the better approach.

I believe you are referring to reduced feature ramstage (without introducing RAMPAYLOAD concept) ?

correct

FWIW, putting CAR teardown on the front of ramstage would get rid of the extra stage load. That was my point.

yes, for sure we will save postcar loading time. as postcar by default is smaller in size hence saving won't be that much as compare to ramstage but i totally agree here.

It gets amortized when it's included in a single program, though. The smaller code size the other piece of your goal (as noted below).

<- snip ->

Again, this is another goal: reduce size of ramstage. Great. Where's the analysis with the break down of code size? And why aren't we targeting ways to reduce that directly in ramstage?

We are planning to present those data in OSFC hopefully :) . originally i have done this POC to gather those number in boot time saving, spi flash saving etc. Without running a POC, it might not helpful to have. And if you see the RAMPAYLOAD patch series, i haven't introduced any new piece that exclusive for RAMPAYLOAD activity. I was just organizing the current code to reduce POC code size.

Sure, but I still stand that we don't need this RAMPAYLOAD if we attack the problems directly in ramstage.

yes Aaron, RAMPAYLOAD would be an additional step which might take a step back for now, till the time we fixes PCI BAR allocation issue for limited pci device programmatically as you have mentioned above, I might need some help there.

View Change

To view, visit change 34476. To unsubscribe, or for help writing mail filters, visit settings.