qmastery16 Posted June 29, 2017 Share Posted June 29, 2017 Good day! I have Lenovo G505S laptop with integrated + discrete graphics: HD 8650G integrated GPU (part of A10-5750M APU) and R5 M230 discrete GPU "AMD Dual Graphics" feature is currently disabled, so these two GPUs are not "merged to one" and are separately detected by Windows 7 x86_64 SP1. This setup is very similar to dampflokfreund's : After following your great advice from ^ this thread ( choose "Wake GPUs up at AIDA64 startup" at AIDA64 Preferences / Stability ) AIDA64 separately detects my integrated and discrete GPU, - and outputs this advanced technical information for discrete GPU : AMD Radeon R5 M230 Series (Sun) BIOS Version - 015.041.000.000 BIOS Date - 11/28/2013 ... Part Number - BR45149.002 PCI Device 1002-6665 / 17AA-3804 (Rev 00) ... Bus Type PCI Express 2.0 x8 @ 3.0 x63 This information above which is marked bold - Video BIOS version, build date, and also Part Number, - is a part of any AMD Video BIOS at its' beginning. By seeing that AIDA64 successfully obtains this information, I am confident that AIDA64 could read the rest of AMD Video BIOS and dump it to a file However, when I right click at bottom panel and then go to " Video Debug ---> Video BIOS Dump " - there is a problem: Expected behaviour: AIDA64 already knows that there are two separate GPUs in my system. It asks for which GPU I would like to save a Video BIOS Dump file, and only then asks me about its' location Observed behaviour: despite knowing that there are two separate GPUs in my system, AIDA64 does not ask for which GPU I would like to save a video dump. Instead, AIDA64 instantly asks for dump file location, and after looking at its' size as well as contents - I could see that it only contains Video BIOS for integrated graphics card, probably because integrated GPU was the first at GPU list Proposed solution: Please add the opportunity to choose and dump Video BIOS for any available graphics card that can be seen at Display ---> GPU list Quote Link to comment Share on other sites More sharing options...
Fiery Posted July 3, 2017 Share Posted July 3, 2017 1) The video BIOS dump is not an official feature of AIDA64. It's only a debug tool that we use to aid hunting and fixing bugs. 2) The video BIOS dump feature is supposed to enumerate all available GPUs. Whenever it can find a GPU with flash BIOS readout, it will save the flash BIOS content into a .ROM file. It may or may not work with multi-GPU systems as well as with mixed graphics systems though. Whenever the flash BIOS cannot be accessed, AIDA64 tries to read the classic video BIOS region (at C0000h memory address) and saves it to a .DMP file. 3) Saving flash BIOS for non-primary GPUs is disabled when ULPS is active. 4) Saving flash BIOS for chipset integrated GPUs is not possible, since their flash image is not available for 3rd party applications via classic GPU flash BIOS interrogation. 1 Quote Link to comment Share on other sites More sharing options...
qmastery16 Posted July 3, 2017 Author Share Posted July 3, 2017 Thank you very much for your reply, Fiery! 2) when AIDA64 successfully finds two or more GPUs with flash BIOS readout, - will it try to save the flash BIOS contents into one or more .ROM files for all these GPUs? Or AIDA64 will save the contents only for one of these GPUs and will instantly exit "vbios dump" function without even trying to dump the video BIOS files for the rest of successfully found GPUs? Please could you check it? 4) in my situation AIDA64 successfully dumps flash BIOS for chipset integrated GPU ( HD 8650G ), but looks like it does not even try to dump the discrete R5 M230 flash BIOS - - despite that it successfully shows BIOS date and information which are a part of AMD Video BIOS header, so it should be able to read the rest of this Video BIOS as well Please could you comment this behaviour? It would be ideal to add a small submenu which allows the user to try to dump a video BIOS for a specific GPU. This small improvement, which would take just about 5-10 minutes of your time, will be very helpful for debuggingP.S. as a software programmer I'd have gladly contributed it but sadly AIDA64 is closed source software Quote Link to comment Share on other sites More sharing options...
Fiery Posted July 5, 2017 Share Posted July 5, 2017 2) AIDA64 saves a separate .ROM file for all GPUs in the system, as long as those GPUs support flash BIOS readout, and ULPS doesn't stand between AIDA64 and the flash BIOSes When no flash BIOS readout is possible, it will revert back to the classic video BIOS region dumping (into a .DMP file) 4) I suppose in this particular case ULPS may be the issue. IMHO there's no need to select the GPU, since AIDA64 would try to save all BIOSes for all GPUs, whenever it's possible. And when it's not possible, by selecting the GPU you wouldn't get the .ROM file anyway either. Quote Link to comment Share on other sites More sharing options...
qmastery16 Posted July 5, 2017 Author Share Posted July 5, 2017 I am not sure if ULPS is a problem, because "Wake GPUs up at AIDA64 startup" is enabled so the GPUs should have left the low power state. Probably its just harder to extract VGABIOS from laptops and another approach is required... Thank you very much for your detailed reply, Fiery. The last thing which I don't understand: if AIDA64 can't extract VGABIOS from R5 M230 card, please tell - how and from where AIDA64 gets this information below? Quote AMD Radeon R5 M230 Series (Sun) BIOS Version - 015.041.000.000 BIOS Date - 11/28/2013 ... Part Number - BR45149.002 PCI Device 1002-6665 / 17AA-3804 (Rev 00) ... Bus Type PCI Express 2.0 x8 @ 3.0 x63 This information above which is marked bold - Video BIOS version, build date, and also Part Number, - is a part of any AMD Video BIOS at its' beginning. AIDA64 successfully gets this info and shows it at GPU menu Your answer to this question may help me to advance in research, and I promise to share all the findings with you in case of success Quote Link to comment Share on other sites More sharing options...
Fiery Posted July 6, 2017 Share Posted July 6, 2017 ULPS has little to do with the current sleep or awake state of a certain GPU. Even when ULPS is enabled, and AIDA64 wakes the GPUs, it will still not query the non-primary GPU (or GPUs) for video BIOS readout. And that's because ULPS is very agressive: it can put the non-primary GPU to sleep anytime, even half-way reading the flash BIOS for example. And when that happens, a system lockup is likely to happen AIDA64 detects the marked information using ADL (AMD proprietary API) calls. http://developer.amd.com/display-library-adl-sdk/ 1 Quote Link to comment Share on other sites More sharing options...
qmastery16 Posted July 7, 2017 Author Share Posted July 7, 2017 On 7/6/2017 at 4:23 PM, Fiery said: ULPS has little to do with the current sleep or awake state of a certain GPU. Even when ULPS is enabled, and AIDA64 wakes the GPUs, it will still not query the non-primary GPU (or GPUs) for video BIOS readout. And that's because ULPS is very agressive: it can put the non-primary GPU to sleep anytime, even half-way reading the flash BIOS for example. And when that happens, a system lockup is likely to happen AIDA64 detects the marked information using ADL (AMD proprietary API) calls. http://developer.amd.com/display-library-adl-sdk/ Dear friend, thank you very much for this information! After a lot of researching I found this wonderful freeware tool: " Belkasoft Live RAM Capturer is a tiny free forensic tool that allows to reliably extract the entire contents of computer’s volatile memory – even if protected by an active anti-debugging or anti-dumping system " https://belkasoft.com/ram-capturer - Indeed this forensic software is dumping more than just RAM! My laptop has 16 GB RAM - 16384 MB ( 0x400000000 bytes ) but these dumps are 0x42F000000 bytes, 17136 MB. Then I just searched through this dump for BR45149.002 (discrete GPU Video BIOS part number) and have found two full copies of this ROM after 0x42D000000 offset: copies at 0x42D305020 and 0x42E40DCD0 offsets. I know how AtomBIOS starts ( 0x55 0xaa ) as well as how it ends ( a lot of 0xFF's and aligned to 0x200 or maybe 0x100 ), so it became obvious that the size is 32768 bytes ( 0x8000 ) and from what offset I should start copying it to get ROM ! Of course there is a lot of manual work with this method, but so far its the only method that has worked for me Good luck and happy hacking! Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.