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 [email protected].
To post to this group, send email to [email protected].
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.
