Patch Set 4:

Is this work related to ENV_PAYLOAD_LOADER introduction?

YES

Is this work replacement to ENV_PAYLOAD_LOADER introduction?

NO

We had introduced ENV_PAYLOAD_LOADER with an idea that ramstage might not be mandatory stage for all platform hence we could also just boot to payload from postcar (if exist after romstage) directly.

What it saves ?

1. Entire boot state machine programming with more than what might required to boot a platform
2. Minimum programming hence save boot time and spi size
3. We have created 3 major bucket out of that exercise
    A Minimum programming to have system pick payload and boot to OS
    B Required ASL/ACPI table to make platform device functional
    C Entire PCI enumeration because all payload are not self sufficient like linuxboot. Incase depthcharge, we expected to provide PCI devices with required resources for depthcharge to use

Now, while coming to solution space, we have seen than 3-C might be equally frustrating/opportunistic for !ENV_PAYLOAD_LOADER case as well, where why BIOS/coreboot to do entire PCI enumeration rather we should handle "minimum/mandatory" PCI device enumeration required to boot the platform via payload.

Aaron has an idea to pause ENV_PAYLOAD_LOADER activity and spent some time to create configurable ramstage where we could achieve all 3-A/B/C goal.

This CL is intended to achieve 3-C where we can decide to mark "mandatory" PCI devices for platform so that we can save boot time and eventually the idea would be create new API rather using PCI_SCAN_BUS to do minimum stuffs as well (TODO)

View Change

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