I solved a discrete AMD GPU problem for a similar A88XM-E board, and the same solution should apply to F2A85-M since these boards are very similar. However, the extra patches (which aren't in coreboot master) are required to get it working - more info at https://review.coreboot.org/c/coreboot/+/30987/ comments.
On Sat, Oct 19, 2019 at 11:05 PM Mike Banon mikebdp2@gmail.com wrote:
Do you still have this problem? Please try obtaining a "cbmem log" and I'll try my best to help you
On Sat, Oct 12, 2019 at 8:40 PM Mike Banon mikebdp2@gmail.com wrote:
Maybe this "cbmem log" is disabled at your coreboot .config, probably this setting is at General section of menuconfig, can't check right now. Share your .config if there are problems in finding
On Sat, Oct 12, 2019 at 12:21 PM Grzegorz Bogdał bogdal.grzegorz@tutanota.com wrote:
"Table not found." Is it the output, or did I do something wrong? I'm back on the vendor BIOS right now.
Oct 12, 2019, 08:30 by mikebdp2@gmail.com:
Please could you share your coreboot boot log after applying this patch? Available with ./coreboot/util/cbmem utility
On Fri, Oct 11, 2019 at 6:11 PM Grzegorz Bogdał bogdal.grzegorz@tutanota.com wrote:
I've tried the patch from csb_patcher. I've applied only the lenovog505s_dgpu patch. Unfortunately, nothing changed.
Sep 14, 2019, 14:04 by mikebdp2@gmail.com:
Kinky, have you tried a patch mentioned in my previous message? If yes, what are the results?
On Thu, Sep 12, 2019 at 2:31 PM Kinky Nekoboi kinky_nekoboi@nekoboi.moe wrote:
Also user of said board.
For me only Nvidia GPUs work correctly.
But using an older Version from 2018, because S3 works there.
Am 10.09.19 um 11:05 schrieb Mike Banon:
Indeed, this patch -- https://review.coreboot.org/c/coreboot/+/31448 ( src/device/pci: Add support for discrete VGA initialization and OpROM loading ) -- could help, because it will create the ACPI VFCT table for discrete RX 570 GPU instead of doing this for integrated HD 8670D. You could install it conveniently and securely with the help of csb_patcher.sh script ( http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#NEWS or https://review.coreboot.org/c/coreboot/+/33509 ).
Although there will not be a VFCT for your integrated GPU, it should be working fine even without it, maybe at cost of a slightly higher power consumption. We have discovered that
" ACPI VFCT - it's a table where AMD stores the Radeon video BIOS when the system is booted up in UEFI mode." " Where the ACPI VFCT Table is missing, Power States may not work properly. "
so it seems without VFCT the integrated GPU is going to be at its' max TDP even while not loaded. For example, knowing that a total TDP of our G505S laptop's A10-5750M APU (CPU+GPU) does not exceed 35W and looking at the values for similar APUs at this table https://www.eteknix.com/amd-kaveri-a10-7850k-overclocking-analysis/7/ (all values except Intel / RAM / OC), approximately for our A10-5750M it should be
Idle | GPU load | CPU+GPU load 15.6W | 23.66W | 35W 44.5% | 67.6% | 100%
We already knew that A10-5750M is 15W at idle, but have learned that GPU adds approximately 23.66W - 15.6W = about 8W while at its' max TDP. This G505S laptop comes with a 65W PSU, so with iGPU at it max TDP -- the laptop's battery life will be smaller in about 65/(65-8) = 1.12 times. However I've never compared the consumption difference of coreboot vs UEFI, would be nice if someone could test it in practice.
Since this RX 570 discrete PCI-E card should have its' own flash chip for storing the AtomBIOS blob -- unlike our laptop's onboard discrete HD-8570M or R5-M230 -- I think in your case there should not be a need of storing the discrete GPU's AtomBIOS ROM at your coreboot BIOS in addition to the integrated one. However, if the advice above would not work, you could try extracting the discrete GPU's AtomBIOS , using either https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios or https://github.com/g505s-opensource-researcher/g505s-atombios#description | https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html instruction.
Best regards, Mike
On Mon, Sep 9, 2019 at 10:04 PM awokd via coreboot coreboot@coreboot.org wrote:
Grzegorz Bogdał:
Thank you. I'll check it out and report sometime in September whether the patches helped my case.
Please note, AFAIK they have only been tested on G505s's, so may need some modification for your platform.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi,
sorry for ignoring you previously - I had trouble with finding your message, and the more urgent things got urgent.
Also, thank you for memory and writing this message. I should have time to tinker with the BIOS sometime in February, I'll check out this solution.
Regards,brzegorz
Jan 5, 2020, 12:51 by mikebdp2@gmail.com:
I solved a discrete AMD GPU problem for a similar A88XM-E board, and the same solution should apply to F2A85-M since these boards are very similar. However, the extra patches (which aren't in coreboot master) are required to get it working - more info at https://review.coreboot.org/c/coreboot/+/30987/ comments.
On Sat, Oct 19, 2019 at 11:05 PM Mike Banon mikebdp2@gmail.com wrote:
Do you still have this problem? Please try obtaining a "cbmem log" and I'll try my best to help you
On Sat, Oct 12, 2019 at 8:40 PM Mike Banon mikebdp2@gmail.com wrote:
Maybe this "cbmem log" is disabled at your coreboot .config, probably this setting is at General section of menuconfig, can't check right now. Share your .config if there are problems in finding
On Sat, Oct 12, 2019 at 12:21 PM Grzegorz Bogdał bogdal.grzegorz@tutanota.com wrote:
"Table not found." Is it the output, or did I do something wrong? I'm back on the vendor BIOS right now.
Oct 12, 2019, 08:30 by mikebdp2@gmail.com:
Please could you share your coreboot boot log after applying this patch? Available with ./coreboot/util/cbmem utility
On Fri, Oct 11, 2019 at 6:11 PM Grzegorz Bogdał bogdal.grzegorz@tutanota.com wrote:
I've tried the patch from csb_patcher. I've applied only the lenovog505s_dgpu patch. Unfortunately, nothing changed.
Sep 14, 2019, 14:04 by mikebdp2@gmail.com:
Kinky, have you tried a patch mentioned in my previous message? If yes, what are the results?
On Thu, Sep 12, 2019 at 2:31 PM Kinky Nekoboi kinky_nekoboi@nekoboi.moe wrote:
Also user of said board.
For me only Nvidia GPUs work correctly.
But using an older Version from 2018, because S3 works there.
Am 10.09.19 um 11:05 schrieb Mike Banon:
Indeed, this patch -- https://review.coreboot.org/c/coreboot/+/31448 ( src/device/pci: Add support for discrete VGA initialization and OpROM loading ) -- could help, because it will create the ACPI VFCT table for discrete RX 570 GPU instead of doing this for integrated HD 8670D. You could install it conveniently and securely with the help of csb_patcher.sh script ( http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#NEWS or https://review.coreboot.org/c/coreboot/+/33509 ).
Although there will not be a VFCT for your integrated GPU, it should be working fine even without it, maybe at cost of a slightly higher power consumption. We have discovered that
" ACPI VFCT - it's a table where AMD stores the Radeon video BIOS when the system is booted up in UEFI mode." " Where the ACPI VFCT Table is missing, Power States may not work properly. "
so it seems without VFCT the integrated GPU is going to be at its' max TDP even while not loaded. For example, knowing that a total TDP of our G505S laptop's A10-5750M APU (CPU+GPU) does not exceed 35W and looking at the values for similar APUs at this table https://www.eteknix.com/amd-kaveri-a10-7850k-overclocking-analysis/7/ (all values except Intel / RAM / OC), approximately for our A10-5750M it should be
Idle | GPU load | CPU+GPU load 15.6W | 23.66W | 35W 44.5% | 67.6% | 100%
We already knew that A10-5750M is 15W at idle, but have learned that GPU adds approximately 23.66W - 15.6W = about 8W while at its' max TDP. This G505S laptop comes with a 65W PSU, so with iGPU at it max TDP -- the laptop's battery life will be smaller in about 65/(65-8) = 1.12 times. However I've never compared the consumption difference of coreboot vs UEFI, would be nice if someone could test it in practice.
Since this RX 570 discrete PCI-E card should have its' own flash chip for storing the AtomBIOS blob -- unlike our laptop's onboard discrete HD-8570M or R5-M230 -- I think in your case there should not be a need of storing the discrete GPU's AtomBIOS ROM at your coreboot BIOS in addition to the integrated one. However, if the advice above would not work, you could try extracting the discrete GPU's AtomBIOS , using either https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios or https://github.com/g505s-opensource-researcher/g505s-atombios#description | https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html instruction.
Best regards, Mike
On Mon, Sep 9, 2019 at 10:04 PM awokd via coreboot coreboot@coreboot.org wrote:
Grzegorz Bogdał: > Thank you. I'll check it out and report sometime in September whether the patches helped my case. Please note, AFAIK they have only been tested on G505s's, so may need some modification for your platform.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
This tiny change - just two lines of code! - should be already enough to get a discrete GPU working for you: https://review.coreboot.org/c/coreboot/+/38215 It would be nice if you could test it as soon as possible and share your feedback, to get it merged sooner.
More complicated changes seem to be required only for the difficult cases like Lenovo G505S - this laptop's discrete GPU, like the integrated, does not have its' own flash memory with AtomBIOS inside, so this AtomBIOS has to be stored inside a coreboot's CBFS and loaded on dGPU by coreboot - just like it's done for the integrated. Desktop discrete GPUs have their own flash memory with AtomBIOS inside, so this work isn't needed to get them working - just need to make sure there are no PCI resource allocation conflicts.
On Sun, Jan 5, 2020 at 3:29 PM Grzegorz Bogdał bogdal.grzegorz@tutanota.com wrote:
Hi,
sorry for ignoring you previously - I had trouble with finding your message, and the more urgent things got urgent.
Also, thank you for memory and writing this message. I should have time to tinker with the BIOS sometime in February, I'll check out this solution.
Regards, brzegorz
Jan 5, 2020, 12:51 by mikebdp2@gmail.com:
I solved a discrete AMD GPU problem for a similar A88XM-E board, and the same solution should apply to F2A85-M since these boards are very similar. However, the extra patches (which aren't in coreboot master) are required to get it working - more info at https://review.coreboot.org/c/coreboot/+/30987/ comments.
On Sat, Oct 19, 2019 at 11:05 PM Mike Banon mikebdp2@gmail.com wrote:
Do you still have this problem? Please try obtaining a "cbmem log" and I'll try my best to help you
On Sat, Oct 12, 2019 at 8:40 PM Mike Banon mikebdp2@gmail.com wrote:
Maybe this "cbmem log" is disabled at your coreboot .config, probably this setting is at General section of menuconfig, can't check right now. Share your .config if there are problems in finding
On Sat, Oct 12, 2019 at 12:21 PM Grzegorz Bogdał bogdal.grzegorz@tutanota.com wrote:
"Table not found." Is it the output, or did I do something wrong? I'm back on the vendor BIOS right now.
Oct 12, 2019, 08:30 by mikebdp2@gmail.com:
Please could you share your coreboot boot log after applying this patch? Available with ./coreboot/util/cbmem utility
On Fri, Oct 11, 2019 at 6:11 PM Grzegorz Bogdał bogdal.grzegorz@tutanota.com wrote:
I've tried the patch from csb_patcher. I've applied only the lenovog505s_dgpu patch. Unfortunately, nothing changed.
Sep 14, 2019, 14:04 by mikebdp2@gmail.com:
Kinky, have you tried a patch mentioned in my previous message? If yes, what are the results?
On Thu, Sep 12, 2019 at 2:31 PM Kinky Nekoboi kinky_nekoboi@nekoboi.moe wrote:
Also user of said board.
For me only Nvidia GPUs work correctly.
But using an older Version from 2018, because S3 works there.
Am 10.09.19 um 11:05 schrieb Mike Banon:
Indeed, this patch -- https://review.coreboot.org/c/coreboot/+/31448 ( src/device/pci: Add support for discrete VGA initialization and OpROM loading ) -- could help, because it will create the ACPI VFCT table for discrete RX 570 GPU instead of doing this for integrated HD 8670D. You could install it conveniently and securely with the help of csb_patcher.sh script ( http://dangerousprototypes.com/docs/Lenovo_G505S_hacking#NEWS or https://review.coreboot.org/c/coreboot/+/33509 ).
Although there will not be a VFCT for your integrated GPU, it should be working fine even without it, maybe at cost of a slightly higher power consumption. We have discovered that
" ACPI VFCT - it's a table where AMD stores the Radeon video BIOS when the system is booted up in UEFI mode." " Where the ACPI VFCT Table is missing, Power States may not work properly. "
so it seems without VFCT the integrated GPU is going to be at its' max TDP even while not loaded. For example, knowing that a total TDP of our G505S laptop's A10-5750M APU (CPU+GPU) does not exceed 35W and looking at the values for similar APUs at this table https://www.eteknix.com/amd-kaveri-a10-7850k-overclocking-analysis/7/ (all values except Intel / RAM / OC), approximately for our A10-5750M it should be
Idle | GPU load | CPU+GPU load 15.6W | 23.66W | 35W 44.5% | 67.6% | 100%
We already knew that A10-5750M is 15W at idle, but have learned that GPU adds approximately 23.66W - 15.6W = about 8W while at its' max TDP. This G505S laptop comes with a 65W PSU, so with iGPU at it max TDP -- the laptop's battery life will be smaller in about 65/(65-8) = 1.12 times. However I've never compared the consumption difference of coreboot vs UEFI, would be nice if someone could test it in practice.
Since this RX 570 discrete PCI-E card should have its' own flash chip for storing the AtomBIOS blob -- unlike our laptop's onboard discrete HD-8570M or R5-M230 -- I think in your case there should not be a need of storing the discrete GPU's AtomBIOS ROM at your coreboot BIOS in addition to the integrated one. However, if the advice above would not work, you could try extracting the discrete GPU's AtomBIOS , using either https://www.coreboot.org/VGA_support#How_to_retrieve_a_good_video_bios or https://github.com/g505s-opensource-researcher/g505s-atombios#description | https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html instruction.
Best regards, Mike
On Mon, Sep 9, 2019 at 10:04 PM awokd via coreboot coreboot@coreboot.org wrote:
Grzegorz Bogdał:
Thank you. I'll check it out and report sometime in September whether the patches helped my case.
Please note, AFAIK they have only been tested on G505s's, so may need some modification for your platform.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Solution for your coreboot + discrete GPU problems like
amdgpu kernel bo map failed [...] error -22 amdgpu_vram_scratch_init failed [...] error -22 fatal error in GPU initialization
It turned out that a fix like https://review.coreboot.org/c/coreboot/+/38215 ( /* Set to 0xD0 instead of 0xE0 to avoid the PCI resource allocation problems. */ InitPost->MemConfig.BottomIo = 0xD0; // at the beginning of board_BeforeInitPost function at board's OemCustomize.c ) that worked for HD6670, is not enough for a huge RX590 - which is huge in all relations, but most importantly the memory ranges!
To get RX590 working with ASUS A88XM-E, I had to decrease a BottomIo even further - to 0xC0 - and also to reduce the BLDCFG_UMA_ALLOCATION_SIZE at board's buildOpts.c from 0x2000 (512MB) to 0x1000 (256MB), - to get this extra "0xD0-0xC0"=0x10000000 room. And then it worked perfectly, at least with DRI_PRIME=1 ./Supertuxkart GPU offloading: ultra settings on integrated - 4 or 5 fps, with offloading - 60 fps. I'm sure this fix will work for your other RX 5** as well, but don't know if I should be trying to commit it to master, since it lowers the integrated GPU's shared memory.
RX590 is the most powerful AMD GPU which does not contain a Platform Security Processor aka PSP (yes, they've started adding this crap to the GPUs as well, and newer Vega / RX 5*** are all contaminated - see for yourself at freedesktop drm/amdgpu sources) . That's why it was really important to get RX590 working. So happy it was possible, thanks to you all ;-)
Best regards, Mike Banon
Great job!: )
So, A10-6800k/FX-8xxx combined with RX 590 is probably the strongest x86 desktop without PSP/ME that we'll get in this reality?
Jan 12, 2020, 14:43 by mikebdp2@gmail.com:
Solution for your coreboot + discrete GPU problems like
amdgpu kernel bo map failed [...] error -22 amdgpu_vram_scratch_init failed [...] error -22 fatal error in GPU initialization
It turned out that a fix like https://review.coreboot.org/c/coreboot/+/38215 ( /* Set to 0xD0 instead of 0xE0 to avoid the PCI resource allocation problems. */ InitPost->MemConfig.BottomIo = 0xD0; // at the beginning of board_BeforeInitPost function at board's OemCustomize.c ) that worked for HD6670, is not enough for a huge RX590 - which is huge in all relations, but most importantly the memory ranges!
To get RX590 working with ASUS A88XM-E, I had to decrease a BottomIo even further - to 0xC0 - and also to reduce the BLDCFG_UMA_ALLOCATION_SIZE at board's buildOpts.c from 0x2000 (512MB) to 0x1000 (256MB), - to get this extra "0xD0-0xC0"=0x10000000 room. And then it worked perfectly, at least with DRI_PRIME=1 ./Supertuxkart GPU offloading: ultra settings on integrated - 4 or 5 fps, with offloading - 60 fps. I'm sure this fix will work for your other RX 5** as well, but don't know if I should be trying to commit it to master, since it lowers the integrated GPU's shared memory.
RX590 is the most powerful AMD GPU which does not contain a Platform Security Processor aka PSP (yes, they've started adding this crap to the GPUs as well, and newer Vega / RX 5*** are all contaminated - see for yourself at freedesktop drm/amdgpu sources) . That's why it was really important to get RX590 working. So happy it was possible, thanks to you all ;-)
Best regards, Mike Banon
-
Grzegorz Bogdał -
Mike Banon