[coreboot] Update on G505S (dGPU init success)

[Mike Banon]

Dear HJK,

My sincere huge congratulations to you for your incredible
breakthrough! :-) As you could see from
http://mail.coreboot.org/pipermail/coreboot/2018-November/087679.html
- I got stuck after loading both iGPU and dGPU OpROMs at kernel panic
and thought its' only because of a broken PCI config. But after
reading your good experience, it seems there were some other problems
as well which you've successfully solved. Please could you clarify
some details :
1)
> 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
1a) Please confirm that you've modified the IO addresses as following:
APU iGPU (integrated GPU) = 0x3000
dGPU (discrete GPU) = 0x1000
1b) Why these exact "IO address" values? How you came up with them,
and why not any different addresses?
1c) At what address offsets (in relation to the beginnings of VBIOS
files) these "IO address" values are situated?
1d) To what value you've changed the PCI device ID in APU iGPU VBIOS,
and why this change is necessary?
2)
> I had to add my SPI chip driver for EN25QH32=0x7016 to CB
Why it was needed? My G505S also has this EN25QH32 chip and I never
had to add any SPI chip drivers - this chip always "just worked" at
coreboot. If this is indeed required (e.g. for the successful graphics
initialization), where to get this SPI chip driver and how to add it?
3)
> I enabled pci 00:02.0 for dGPU in devicetree.cb → according to the CB logs this causes pci resource allocation problems
Do you still have any part of this log, for the reference? I don't
remember any resource allocation problems in 8 level CB logs
4)
> 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)
Why OpROM exec is not needed for dGPU device? And what would happen if
I will execute it there? (would it break the things, or just no
difference)
5)
> I modified pci_rom.c, so the VBIOS of the dGPU is copied to 0xd0000 from CBFS (..check_initialized..)
Why this specific 0xd0000 address has been selected? Or it has been
automatically chosen by coreboot when it wanted to load this OpROM to
dGPU ?
6)
> 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)
Why this should be done for dGPU only? (not for APU iGPU or any other devices)

7) I would like to refine your "hacks" and commit them to coreboot,
while giving a full credit to you of course. But, if I would start
doing it from scratch according to your instructions, there is always
a chance that I'd misunderstand or forget something (or you forgot to
mention some small but important technicality) and as result my
attempt to reproduce your success could be problematic. It would be
ideal if you could share:
A*) your successful coreboot.rom (I'd like to check its' PCI state out
of curiosity)
B*) your coreboot's .config file for the reference purposes
C*) upload your whole coreboot directory to some convenient place,
either to GitHub or just archive it as .tar.gz (maybe as a multipart
archive if it ends up too big) and upload it to some hosting website;
or maybe even create a .torrent out of it and host it temporarily -
whatever is most convenient to you.

Hopefully you could share this stuff and I will be able to reproduce
your results, initially "AS-IS" - but then I will try my best to
refine it to the acceptable code quality (so that it could be
officially accepted to coreboot) while checking from time to time if
it is still working after my gradual changes. Hope to hear any news
from you soon

Best regards,
Mike Banon
On Sat, Nov 3, 2018 at 8:42 PM Hans Jürgen Kitter
<hansjurgenj789 at gmail.com> 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).
> 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
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot