Re: [coreboot] Update on G505S (dGPU init success)
Hi there HJK,
> I have issues with my gmail account
Could use coreboot mailing list archive to make sure you haven't
missed any messages:
https://mail.coreboot.org/mailman/listinfo/coreboot
> But for the iGPU variants a small code within CB to patch the pci ids of the
> iGPU vbios
> would be even better to save space.
Maybe its' possible to do quite easily thanks to " map_oprom_vendev "
function which it is being used at ./coreboot/src/device/pci_rom.c -
line 34 :
struct rom_header *pci_rom_probe(struct device *dev)
{
struct rom_header *rom_header;
struct pci_data *rom_data;
/* If it's in FLASH, then don't check device for ROM. */
rom_header = cbfs_boot_map_optionrom(dev->vendor, dev->device);
u32 vendev = (dev->vendor << 16) | dev->device;
u32 mapped_vendev;
mapped_vendev = map_oprom_vendev(vendev);
...
./coreboot/src/northbridge/amd/agesa/family15tn/northbridge.c - line 961
/*
* Change the vendor / device IDs to match the generic VBIOS header. *
*/
u32 map_oprom_vendev(u32 vendev)
{
u32 new_vendev = vendev;
switch(vendev) {
...
case 0x10029903:/* AMD Radeon HD 7640G (Trinity) */
...
case 0x1002990B:/* AMD Radeon HD 8650G (Richland) */
...
case 0x1002990D:/* AMD Radeon HD 8550G (Richland) */
...
if I understood it correctly, you could make something like this
case 0x1002990D:/* AMD Radeon HD 8550G (Richland) */
new_vendev = 0x1002990B;
break;
, the same for 0x1002990B, and you could keep the same
pci1002,990b.rom (containing A10-5750M/HD8650G IDs) for all three GPUs
*1*) Could you please test this ^^^ theory? ( I only have A10-5750M so
couldn't verify it by myself )
However, even if this works, we need to really make sure - and then to
prove - that indeed A10-5750M/HD8650G AtomBIOS ROM is 100% compatible
with e.g. A8-5550M/HD8550G.
> I don't remember having issues using the same file (with different pci ids)
> for the different APUs.
Perhaps that's not enough, ideally we need to get more proof to raise
its' chances of merging :
*2*) Could you please provide a full AtomDis disassembly for the
"dirty" (fully initialized) ROM for A8-5550M/HD8550G ?
(pci1002,990d.rom) - we need to get ./atomdis pci1002,990d.rom F >
output.txt and compare it with atomdis for pci1002,990b.rom to see
what are the differences and - if there are any - are they acceptable?
If you don't have it you may need to temporarily go back to UEFI to
extract it from UEFI / running system
> I used cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin from platomav git
You could use my patches from this page for convenience:
http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#Unofficial_coreboot_patches
They could conveniently and securely (with SHA-256 verification) patch
the freshly cloned coreboot with the latest microcodes for 15h and
16h.
> I checked HP, Lenovo and other vendors' bios updates, but only found version
> 1119 within the bios files
It seems that only a few AMD 15h / 16h computers are getting the BIOS
updates with an updated microcode. I have a list of these computers
and I'm checking their official downloads page for new BIOSes once in
a while ( Windows / Win10 should be selected ). During last time of
checking one of these computers (with 111F microcode inside their
BIOS) had 10th April 2018 update date. Now its latest BIOS is 19th
August 2018, I've downloaded it, unpacked then checked its' ROM with
MC Extractor - and it still has this 600111F microcode inside, so not
recalled. Could tell more information privately.
> Yes, the latest microcode for AMD Fam15h hasn't been pushed to the
> linux-firmware git
> (or actually it was pushed and then the same day was withdrawn)
Indeed it has never been pushed officially, otherwise I'd have seen it
in this commit history for amd-ucode:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/amd-ucode
> I attach my cbmem and linux kernel logs for your reference.
Thank you very much, will be checking them soon
Best regards,
Mike Banon
On Tue, Nov 13, 2018 at 10:49 AM eftername Förname wrote:
>
> Hi Mike,
>
> I have issues with my gmail account, so I can only reply now:
>
> As for the vbios patching: for historic reasons, when I made those vbios
> files (I use dirty, meaning already
> initialized files), I was under the impression, that the IO address should
> be changed to the IO address what CB
> assigns to the cards. It might not be relevant any more, but the stock bios
> assigns IO address 0x4000 to the iGPU
> and 0x3000 to the dGPU, while CB assigns 0x3000 to the iGPU and 0x1000 to
> the dGPU...
> Also, the stock bios patches the stored,clean,uninitialized vbios files by
> changing the PCI IDs, Subsystem IDs and
> many other Atombios tables to get eg. output on the screen (otherwise it is
> only bl
Re: [coreboot] Update on G505S (dGPU init success)
Hi, Here are some additional details, but before I answer I share some preconceptions I had along the way: - after some initial tries I thought, that the stock BIOS sets up the configuration in a special way for the iGPU and gDPU (PCI adress BARs, IO addresses etc) to get those working therefore, I tried to achieve a very similar setup using CB - the problem is that the stock BIOS patches the raw VBIOS/Oprom files during execution - which Coreboot doesn't do. (ref: https://www.coreboot.org/Board:lenovo/x60/Installation) - when I started "hacking" months ago I got similar linux kernel panics like you got when pci bus 02.0 was enabled. I assumed there was a pci allocation problem behind (one additional pci device with big pci resource requirement), also I assumed (maybe wrongly), that pci BAR addresses for the dGPU - and also UMA memory - need to be below the first 4 GB of memory - for the dGPU to work. (details below) - some of these preconceptions might not need to be considered any more, but so far I haven't made attempts to exclude any of these. By sharing this, I hope more people can help us cleaning the unnecessary stuff... On Sat, Nov 3, 2018 at 8:13 PM Mike Banon wrote: > 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? > When CB boots the iGPU gets IO address 0x3000 and dGPU gets address 0x1000 from the resource allocator. Since CB doesn't patches the VBIOS files, I had to do this manually. Giving it a thought now, this might not be required any more (to mod the VBIOS), because 1. this was not the problem the dGPU didn't init, 2. if I'm not mistaken normally Oprom execution should do this, right? Offset for IO address for iGPU is @ 0x1A4 (2 bytes), for dGPU @ 0x218. You can use radeon-bios-decode to check the result, and use atomcrc.exe to show the new checksum (@offset 0x21) - to be corrected with hexedit. I have multiple variants of APUs, the iGPU pci device ID need to match within VBIOS (offset 0x1b8 for pci id (4 bytes)). additional remark: you can also set the subsystem ID @ 0x1a6 (4 bytes). 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? > This is not required for graphics, but hybernation support needs that CB writes data to the SPI chip. You can see if SPI writes succeed or not in CB console log. I have multiple g505s boards - each with different SPI chips and my EON chip ID was not listed in CB SPI eon.c 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 > Well, this is an interesting topic and I admit, that I don't fully understand all the details, so my phrasing below might not be too "academic"... Moreover, pls. check my preconceptions, and note the fact that pci 02.0 has to be enabled in CB to be able to fill the VFCT for the dGPU. In the stock BIOS iGPU gets BAR address @0xd000. But iGPU UMA size=768M, therefore I assume iGPU also occupies +2x256M UMA memory starting from 0xb000. If you check the stock BIOS it is located in the 0x9xxx range, whereas in CB - depending on the pci resource allocator provided ranges, the AGESA stipulations and the UMA size - from normally end of the 0xb range. The problem is that it seems in AGESA Top of low memory (TOM) is always 0xe000 (set by the BSP through msr register), this is used by CB to calculate the relative offsets. In a g505s without dGPU pci addre
Re: [coreboot] Update on G505S (dGPU init success)
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 0xd from CBFS > (..check_initialized..) Why this specific 0xd 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 > 0xd=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 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 :04:00.0: Invalid PCI ROM header signature: expecting > 0xaa55, got 0x). This was true whether using
Re: [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. Nice hacking! I know Mike Banon was working with some others on this too, hopefully you were able to compare notes. Any benefits to G505s owners who don't have the secondary GPU? -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Update on G505S (dGPU init success)
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 :04:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0x). 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 @0xd000 and the dGPU has also 256M from 0xe000 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 0xd 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 0xd=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: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
