Hi, I'm trying to get a mainline 6.6.16 stable tree to work on a custom board, based around a PHYTEC AM57x phyCORE kit SoM. The board was originally running a 4.19.79 based vendor kernel (PHYTEC tree[0] plus a few of patches from the board vendor). From the device tree sources, I guess current mainline supports the SoC, but not this specific SoM? So far, I tossed out as much unrelated cruft as possible from the vendor patch set, without breaking the existing config, and then tried to port over what was left of the device tree changes. That would be pretty much only *additional* dtsi files for the SoM, board and a dts file for the board. The SoC specific stuff, clock configuration, etc... AFAICT all stem from mainline dra7*/omap4/omap5 dtsi files that are directly or indirectly included. With PCIe (and the bb2d GPU) disabled, the resulting kernel and device tree boot. UART, i2c, eMMC, network appear to be working. If I re-enable PCIe, the system completely freezes during boot. printk debugging narrowed this down to the probe function of the driver, drivers/pci/controller/dwc/pci-dra7xx.c:799, inside the first readl(), where the driver attempts to access PCIECTRL_DRA7XX_CONF_DEVICE_CMD From the boot log, the PCIe PHYs appear to probe and initialize successfully, well before probing PCIe is attempted. I suspect maybe some clock or power dependencies might be missing? But as said, the SoC specific configuration is pretty much as-is from the mainline tree. The board specific dtsi file only enables the PCIe RC node (defined in dra7.dtsi) and assigning a GPIO pin. From what I can tell, other boards using the same SoC follow a similar pattern (e.g. looking at the beagle-x15 device tree source for comparison). Is there some known issue regarding this SoM, PCIe controller, or most likely, something obvious that I am missing? Any pointers what I should be looking into? Thanks, David [0] https://stash.phytec.com/projects/PUB/repos/linux-phytec-ti/browse?at=refs%2Fheads%2Fv4.19.79-phy
