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 28:
(1 comment)
File src/soc/intel/common/block/graphics/early_graphics.c:
https://review.coreboot.org/c/coreboot/+/70299/comment/714fefd3_031fb3c6 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();
Subrata/I chatted offline and we're both good with Angels suggested route.
If coreboot uses `0xfa000000`, Linux has to reallocate. In this case, it reallocates at `0x4d4000000` (beyong the 4GB boundary). I have not noticed any side-effect but it most likely disrupted the PCI enumeration process.
localhost ~ # hexdump /sys/devices/pci0000:00/0000:00:02.0/config 0000000 8086 a7a1 0407 0010 0004 0300 0010 0000 0000010 0004 d400 0004 0000 000c 9000 0000 0000 0000020 1001 0000 0000 0000 0000 0000 8086 a7a1
If coreboot uses `0x85000000` (GOP default), Linux keeps it (I guess the same applies to my originally suggested `0x81000000`.
localhost ~ # hexdump /sys/devices/pci0000:00/0000:00:02.0/config 0000000 8086 a7a1 0407 0010 0004 0300 0010 0000 0000010 0004 8500 0000 0000 000c 9000 0000 0000 0000020 1001 0000 0000 0000 0000 0000 8086 a7a1
Even if coreboot uses `0xaf000000` (GOP MMIO address to not be confused with `0xfa000000`), Linux keeps it.
localhost ~ # hexdump /sys/devices/pci0000:00/0000:00:02.0/config 0000000 8086 a7a1 0407 0010 0004 0300 0010 0000 0000010 0004 af00 0000 0000 000c 9000 0000 0000 0000020 1001 0000 0000 0000 0000 0000 8086 a7a1
So technically the Linux kernel recovers with Subrata's address but as I suspected this one a bit more problematic and lead the kernel to have to re-allocate another range. I believe that using a most likely to conflict range (and short) while we also use it in ramstage does not make sense and my original suggestion seems more appropriate.
The idea of using a temporary address only stands if it only applies to romstage and is not hardcoded in a Kconfig which is something we can do once we have romstage initialized global variable support. As of today, with a the static MMIO driver we should allocate a fixed range less likely to conflict and via Kconfig.