Attention is currently required from: Bora Guvendik, Zhixing Ma, Anil Kumar K, Hannah Williams, Cliff Huang, Tarun Tuli, Nico Huber, Michał Żygowski, Subrata Banik, Paul Menzel, Arthur Heymans, Swift Geek (Sebastian Grzywna).
Jérémy Compostella has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/70299 )
Change subject: soc/intel/common/block: Add Intel VGA early graphics support ......................................................................
Patch Set 33:
(1 comment)
File src/soc/intel/common/block/graphics/early_graphics.c:
https://review.coreboot.org/c/coreboot/+/70299/comment/c4916860_8f06c9ba PS23, Line 32: : /* : * Graphics MMIO device configuration may have been corrupted since it : * has been initialized. The execution of a binary block such as FSP may : * indeed have reset the PCI BAR0 address of the graphic device. : */ : early_graphics_soc_device_init();
@Jeremy can we reach out to someone on the Kernel side and see if there may be any unintended side-e […]
I performed a quick analysis of the impact on the kernel PCI enumeration and IGD resource allocation.
First, since we recently added a guard on `MAINBOARD_USE_LIBGFXINIT` in `graphics/graphics.c`, the Linux kernel re-allocation only occurs if `libgfxinit` is enabled for both romstage and ramstage and of course, if we keep using this `0xfa000000` MMIO range.
Second, the re-allocation happens during the Linux kernel PCI resource allocation / sanity check.
Here is the diff between a regular boot and a boot with 0000:02.00 BAR0 set to `0xfa000000`.
@@ -272,14 +272,14 @@ pci_bus 0000:00: root bus resource [bus 00-ff] pci 0000:00:00.0: [8086:a708] type 00 class 0x060000 pci 0000:00:02.0: [8086:a7a1] type 00 class 0x030000 -pci 0000:00:02.0: reg 0x10: [mem 0x81000000-0x81ffffff 64bit] +pci 0000:00:02.0: reg 0x10: [mem 0xfa000000-0xfaffffff 64bit] pci 0000:00:02.0: reg 0x18: [mem 0x90000000-0x9fffffff 64bit pref] pci 0000:00:02.0: reg 0x20: [io 0x1000-0x103f] pci 0000:00:02.0: DMAR: Skip IOMMU disabling for graphics pci 0000:00:04.0: [8086:a71d] type 00 class 0x118000 pci 0000:00:04.0: reg 0x10: [mem 0x80780000-0x8079ffff 64bit] pci 0000:00:05.0: [8086:a75d] type 00 class 0x048000 -pci 0000:00:05.0: reg 0x10: [mem 0x82000000-0x82ffffff 64bit] +pci 0000:00:05.0: reg 0x10: [mem 0x81000000-0x81ffffff 64bit] pci 0000:00:05.0: enabling Extended Tags pci 0000:00:07.0: [8086:a76e] type 01 class 0x060400 pci 0000:00:07.0: PME# supported from D0 D3hot D3cold @@ -346,7 +346,7 @@ pci 0000:00:1f.5: reg 0x10: [mem 0xfe010000-0xfe010fff] pci 0000:00:07.0: PCI bridge to [bus 01-2b] pci 0000:00:07.0: bridge window [io 0x2000-0x3fff] -pci 0000:00:07.0: bridge window [mem 0x83000000-0x8f1fffff] +pci 0000:00:07.0: bridge window [mem 0x82000000-0x8e1fffff] pci 0000:00:07.0: bridge window [mem 0x47fc00000-0x49bbfffff 64bit pref] pci 0000:00:07.1: PCI bridge to [bus 2c-56] pci 0000:00:07.1: bridge window [io 0x4000-0x5fff] @@ -391,6 +391,7 @@ Advanced Linux Sound Architecture Driver Initialized. PCI: Using ACPI for IRQ routing PCI: pci_cache_line_size set to 64 bytes +pci 0000:00:02.0: can't claim BAR 0 [mem 0xfa000000-0xfaffffff 64bit]: no compatible bridge window pci 0000:00:1f.5: can't claim BAR 0 [mem 0xfe010000-0xfe010fff]: address conflict with 0000:00:14.2 [mem 0xfe010000-0xfe013fff 64bit] e820: reserve RAM buffer [mem 0x7675c000-0x77ffffff] e820: reserve RAM buffer [mem 0x47fc00000-0x47fffffff] @@ -434,6 +435,7 @@ NET: Registered protocol family 1 pci 0000:00:1c.0: bridge window [io 0x1000-0x0fff] to [bus 82] add_size 1000 pci 0000:00:1c.0: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 82] add_size 200000 add_align 100000 +pci 0000:00:02.0: BAR 0: assigned [mem 0x4d4000000-0x4d4ffffff 64bit] pci 0000:00:1c.0: BAR 9: assigned [mem 0x4d3c00000-0x4d3dfffff 64bit pref] pci 0000:00:08.0: BAR 0: assigned [mem 0x4d3e00000-0x4d3e00fff 64bit] pci 0000:00:19.0: BAR 0: assigned [mem 0x4d3e01000-0x4d3e01fff 64bit]
The assigned PCI 0000:02.00 BAR 0 is not in the expected ranges list for PCI Bus 0 and therefore it is released and the Linux Kerne PCI ressource allocator and a another range is being assigned. This happens way before the device/driver association process and therefor before the i915 driver is probed.
Therefore, the only remaining questions is : Would Alder Lake IGD (gen 12) works well with BAR 0 (Gttmmadr) address above the 4GB ? (like `0x4d4000000`) ?
In my opinion the question should be why wouldn't it work ? :) Anyway, I submitted the question to a graphics expert.
Note that if you have concern we could use a MMIO range in the more generic 32 bits hole (`0x80400000-0xbfffffff`). We could even use the same address than the PEIM driver uses by default (`0xaf000000`).