Attention is currently required from: Raul Rangel, Karthik Ramasubramanian, Felix Held.
2 comments:
Patchset:
Realized that step 1) is not in PSP verstage and it is done very early in bootblock. […]
Here are the tables:
There's also another call for the fingerprint MCU power, but that's self contained.
WWAN & WWAN have power signals in addition to the aux reset lines.
SD card & NVME only have aux reset. The power on is handled in hardware when power comes up, and firmware has no control over those signals.
So here's the power-on sequence for all of the devices:
If WWAN is only using USB, PCIe training on that link doesn't happen, so the device stays in USB mode.
All of the devices need to be brought up in the correct power-on sequence so that the training can occur. If someone wants to try moving that to ACPI and letting the linux kernel do all of the allocation and everything, I'd be happy to let them, but without AGESA doing the PCIe bus training, there might be a bunch of additional code that's needed in a driver that's written specifically to handle that.
File src/mainboard/google/guybrush/variants/baseboard/gpio.c:
Patch Set #3, Line 172: /* Assert all AUX reset lines */
Correction: Why do we need to do early bootblock initialization of *AUX_RESET* GPIOs only when PSP v […]
Because if PSP_Verstage is enabled, it gets done in psp_verstage instead of in early bootblock.
On board rev0, we need to enable pcie_rst early, but we want to keep all of those signals disabled because we want to keep the PCIe reset lines asserted until we're ready to do the pcie training. The way we'd prefer this to happen (though it makes no real difference) is to raise the AUX lines early and bring everything out of reset by just raising the single pcie_rst signal. We can do that with board rev2, but it will break all of the rev0 boards.
To view, visit change 57317. To unsubscribe, or for help writing mail filters, visit settings.