[coreboot] Update on G505S (dGPU init success)

[Hans Jürgen Kitter]

 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).
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).

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.

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 as payload
   - 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 CB -
   linux kernel provided (0x1000) address
   - both prepared VBIOSes were put into CBFS
   - 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).
   - main payload Seabios (compiled as elf separately)
   - I had to add my SPI chip driver for EN25QH32=0x7016 to CB
   - 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.
   - 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).
   - 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 VFCT fill is done from the previously prepared
      0xd0000=PCI_RAM_IMAGE_START address)

Remark1: there could be one ACPI VFCT table containing both VBIOSes
present, but the APU GPU VBIOS is fully working via Oprom exec only.
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.
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,
HJK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20181103/26a4eace/attachment.html>