Very nice!
It sounds to this newb as if it's hacky as hell, but it's nice to finally
know what the problem was! Have you also dropped a line to the coreboot
mailing list?
Even though I ordered a dGPU G505s I got shipped one without, so sadly I
can't add this to the ifixit I plan to finish this winter. (hey, what's
this giant void in my laptop!?)
Hopefully when this gets upstreamed it'll "just work" like it does on the
factory bios though.
If it proves to enhance performance enough I might consider a board-swap.
(anyone know how to get minecraft to use crossfire on this thing? :P)
Thanks,
-Matthew Bradley
On Thu, Nov 1, 2018 at 1:39 PM <[email protected]> wrote:
> 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 a topic in the
> Google Groups "qubes-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/qubes-users/ALUPDysiaEc/unsubscribe.
> To unsubscribe from this group and all its topics, 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.
>
--
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/CAOEb0vZ3X_vDpkKRHo1MZ9oMFb%2B0O6WnRvtwWH1GTMcfi9_Bkg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
