<div dir="ltr"><div dir="ltr"> Hi All,
<br>
<br><div>I thought that I share with the G505S+Coreboot (+QubesOS) users that I 
finally managed to enable and use the dGPUs on the G505S boards.  When 
mentioning boards, I mean, that both variants  with its respective 
VBIOSes: dGPU=1002,6663 (ATI HD 8570M, Sun-Pro) and the dGPU=1002,6665 
(ATI R5 M230, Jet-Pro) are working under Ubuntu Linux or Qubes 4.0 (no 
Windows testing was done or planned).</div><div>DRI_PRIME=1 seem to work, I use the radeon driver for the APU GPU (A10-5750m) and amdgpu for the dGPU. I'm currently investigating how to get the most out of this setup in Qubes (HW accel 2D in AppVMs).</div><br>Problem statement: the dGPU was not initiated correctly and was not 
enabled by the radeon or amdgpu kernel module, VFCT header was 
corrupt/truncated (effectively was not corrupt, but only VFCT for the 
APU/iGPU was present). Trying to init the dGPU device through Oprom
 initialization failed all my attempts (radeon 0000:04:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x0000). This was true whether using 
Coreboot+GRUB or using Coreboot+Seabios, regardless of kernel version 
4.x.
<br>
<br>Solution in short: Modify Coreboot, that the VFCT table is only 
created for the dGPU so it can be used by either the radeon or amdgpu 
KMS driver.
<br>
<br>Solution in more details: 
<br><ul><li>CB 4.8 latest, with SB latest 1.11.2 as payload<br></li><li>I modified the IO address & the PCI device ID in APU GPU 
VBIOS file (even though IO address change to 0x3000 might not required).</li><li>I modified the IO address in the dGPU VBIOS files to the actual CB - linux kernel provided (0x1000) address</li><li>both prepared VBIOSes were put into CBFS</li><li>Coreboot config: std. g505s build, but both run oprom & 
load oprom was enabled (native mode), also display was set to FB, 1024x768 16.8M
 color 8:8:8, legacy VGA → this provides console output even if eg. GRUB
 is the payload).</li><li>main payload Seabios (compiled as elf separately)</li><li>I had to add my SPI chip driver for EN25QH32=0x7016 to CB</li><li>I used version 0600111F AMD Fam 15h microcode (even 
though this was later recalled by AMD to n-1 version 06001119). 
 Nevertheless, Spectre V2 RSB and IBPB mitigations are thus enabled.</li><li>I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs this causes pci 
resource allocation problems, because the 256M address window of the 
dGPU conficts with the APU GPU VRAM UMA memory window (originally 512M). 
 Solution (not really professional, but I gave up understanding the whole AGESA and CB PCI allocation mechanism): I decreased the UMA size in buildopts.c to 256M (0x1000) and 
patched amd_mtrr.c, function setup_bsp_ramtop, to bring TOM down by 256M. So now the APU GPU has an 256M PCI address window @0xd0000000 and the dGPU 
has also 256M from 0xe0000000 without eventual resource conflict (there's an initial allocation warning for pci:00:01.0 in linux log though).</li><li>I modified pci_device.c, function pci_dev_init to only enable 
pci_rom_probe and pci_rom load for the dGPU pci device (no oprom exec 
needed for PCI_CLASS_DISPLAY_OTHER).</li><li>I modified pci_rom.c,</li><ul><li>so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..)</li><li>and pci_rom_write_acpi_tables only run for 
PCI_CLASS_DEVICE_OTHER → dGPU (ACPI VFCT fill is done from the previously 
prepared 0xd0000=PCI_RAM_IMAGE_START address)<br></li></ul></ul>Remark1: there could be one ACPI VFCT table containing both VBIOSes present, 
but the APU GPU VBIOS is fully working via Oprom exec only.
<br>Remark2: in the stock v3 bios additional ACPI tables are present (SSDT,
 DSDT) which contain VGA related methods and descriptions therefore, the
 VFCT table itself (in EFI mode) is a lot smaller ca. 20K (vs. 65k). 
 These additional ACPI extentions allow eg. the vga_switcheroo to work under
 Ubuntu in stock BIOS.  WIth CB currently only offloading (DRI...) seems to 
work.  And as I checked I will need to understand the whole ACPI concept before I can migrate the relevant ACPI tables from the stock BIOS to CB for the switching to work.  Also, it seems, that TurboCore (PowerNow?) is not currently enabled entirely in CB --> also implemented via ACPI tables in stock BIOS.</div><div dir="ltr">Well, I’m not a coding expert (just a G505S enthusiast), this is the reason I didn’t include 
patches. My goal was to describe a working solution, and someone with 
proper coding skills and the possibility to submit official patches for 
CB can get this committed. 
<br>
<br>BR,
<br>HJK
</div></div>