Hi All, 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). I can now use the DRI_PRIME env. variable to offload rendering to the dGPU. In Qubes as far as I know - the dom0 X driver can only provide 2D acceleration to the AppVMs, also the dGPU seems slower than the APU GPU (glxgears in its original window size: ca. 1500 vs. ca. 2500 fps), but it is still better to use the dedicated 2GB Ram of the dGPU...
One remark: SI_support is not enabled by default in the amdgpu module in the latest stock 4.14-74 dom0 kernel, therefore you will have to create a custom kernel with this feature enabled, if you intended to use the radeon module for the APU GPU (no amdgpu support...) and the newer amdgpu for the dGPU. 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 only present). Trying to init the dGPU device through Oprom initialization failed all my attempts. This was true whether using Coreboot+GRUB or using Coreboot+Seabios, regardless of kernel version 4.x. 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. Solution in more details: CB 4.8 latest, with SB latest 1.11.2 I modified the IO address & the pci device ID in APU GPU Vbios file (even though IO address change to 0x3000 might not required). I modified the IO address in the dGPU VBIOS files to the actual Coreboot/kernel provided (0x1000) address both prepared VBIOSes were put into CBFS for Coreboot config: std g505s build, but both run oprom & load oprom was enabled (native mode), also display was FB 1024x768 16.8M color 8:8:8, legacy VGA → this provides console output even if eg. GRUB is the payload). Main payload Seabios (compiled as elf separately) I had to add my SPI chip driver for EN25QH32=0x7016 to CB I patched CB with 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. I enabled pci 00:02.0 for dGPU in devicetree → this causes pci resource allocation problems, because the 256M address window of the dGPU conficts with the APU GPU VRAM memory window (originally 512M). Solution: 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 (0x10000000). So now the APU GPU has 256 M @0xd0000000 and the dGPU has 256M from 0xe0000000. → there could be other solutions, but I’m not expert in rearranging the memory layout used by CB 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). I modified pci_rom.c, ◦ so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..) ◦ and pci_rom_write_acpi_tables only run for PCI_CLASS_DEVICE_OTHER → dGPU (ACPI fill is done from the previously prepared 0xd0000 address) Remark1: there could be one VFCT table with both VBIOSes present, but the APU GPU VBIOS is fully working via Oprom exec only (there are kernel warnings) Remark2: in the stock 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. vga_switcheroo to work under Ubuntu in stock BIOS. For CB currently only offloading seems to work... Well, I’m not a coding expert, 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, HJK -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/49cf1b59-c4b2-47c0-85fc-5e05115448ae%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.