I have a Gigabyte GTX 770 4GB (WF3X OC Rev 2) @ FW368.81 and despite GPU-Z showing my card as UEFI-capable (“UEFI” Checkbox checked) I couldn’t install Win7 (Ultimate, x64, SP1 - Setup-DVD launched from UEFI-BIOS) with CSM turned off - I always get an error message, telling me that either my system or some component is not fully UEFI-compatible. So I had to keep CSM turned on in order to install Win7.
Now, do I need to install a GOP Driver or not? I found User reports on Google complaining GPU-Z shows their card as UEFI-capable while it is actually not (AMD Radeon Fury, for example) - they had to additionally install a GOP Driver in order to get their card truly working…
So far for now…
AZ
@gupsterg
I believe I was in debt with a response for your generous tests. I tried in the first two days to crack either the CRC or the hash, failed miserably, then I postponed the project for some side projects I have (one of them being HP and Toshiba encrypted BIOS images, which ironically it was easier to crack), then personal life came in the way.
What can be deduced from your tests is that Hash comes first and only for a portion of the Legacy image, then CRC for most of the Legacy image, then 8-bit checksum for the entire Legacy image.
CRC is most likely used as internal integrity check, probably during boot, which would explain the use of a faster CRC and the correction during flashing. It has zero use for us, maybe just a nice bonus if we can crack it. For the hash, I’m seeing yet another reference <here>, but this hash cracking seems to be more elusive than a state secret. What I did found, eventually, is that RBE had some findings. I don’t know if it was really tested, but they offered a hash bypass for some cards, in Additional features -> Method 1 - Hash. By doing some tests, it appears they were using just these sections:
50h -> 93h = 44h bytes
ATOMBIOS -> ATOMBIOS + 28h = 29h bytes
FirmwareInfo - > FirmwareInfo + 4Fh = 50h bytes
It is obvious that things have changed and at the very least the PCI Structure is included. It is also obvious that they didn’t knew too much, seeing how they also included the CRC field, which is why I questioned if it was ever tested. But this shows that only specific regions are protected, not all the ATOM Tables. Inspecting the driver could be more useful than disassembling the GOP, but that thing is a monster and I would need a dump from a BSOD related to signature check. I have done some steps on the GOP and I believe I have found a way to patch this check.
Either this is the hash check or it is for COPP protected content, but I doubt COPP would kick in that soon. To test it, use either Test1 or Test2 (if Test1 fails) to replace the file in GOPupd -> #GOP_Files, update one of your custom ROMs with this patched GOP. The test must be done with CSM=OFF (to activate UEFI and hash check), Fast Boot = ON/OFF (don’t think it matters) and Secure Boot = OFF (since I modified the GOP and invalidated its signature). If it works, a similar patch can be done for the driver. If and ONLY if the above works, I would need a copy of atikmdag.sys from someone with an RX480. Otherwise this is just wishful thinking, it is impossible to obtain something from this monster kernel driver, based on Code errors from Device Manager. Just an example, this driver contains some SMU firmwares, among other things:
Lastly, since you have posted MemoryInfo in your threads, you should consider using the updated dll and drivers from GPUTweak. From a quick look, the info is obtained through them, MemoryInfo.exe only does some interpretation of the data. If there are issues, I could look into them, but I can’t make any promises for a quick reply.
AMD_Sig_Check.rar (116 KB)
@zir_blazer
First of all, I would need a copy of your original VBIOS, for some tests. I can think of three reasons why it happened:
- the hash check is also present on older cards, but doesn’t include the PCI structure and you can safely use GOPupd, but no other mods like microcode relocation. However, I seem to remember that you said you already used RBE on that VBIOS? Do you remember what you modified with RBE?
- the unusual size tricks QEMU and it only loads a partial image.
- the GPU microcode is actually loaded this time and it causes an error for your boot environment.
The only difference between old working image and the newer one is the relocation of microcode and an updated pointer for that microcode. That is, the first image points to a region where there is no microcode and no microcode is loaded, while the second image is patched to point to the new offset of the microcode, thus the microcode should be loaded. Please upload a copy of your VBIOS which you intend to use and I will upload tests for each of the above 3 reasons of failing: one image with an older GOP that still fits the microcode at the original offset, one image that is rounded to 256KB, one image that points to a different microcode offset, but no microcode will be found at that offset.
@docspace
Thank you for the new GOP. Will be present in the next release, along with proper credits.
@Camp_Anaconda
If it already had an EFI, the size shouldn’t be a problem, as the difference is not enough to “spill” over chip space. On top of that, the replacing of an existing EFI image is a lot easier than inserting one on a non-UEFI image. You should be safe with updating.
@AbsoluteZero
The GOP is only a part of the solution. You need an EFI driver for every bootable device, which includes Lan, AHCI/RAID, GPU, NVMe, plus the usage of GPT for your drive. Without a link to your mainboard it is hard to offer assistance.
The original VBIOS that came with my Radeon 5770 is on the VGA Bios Collection, here: https://www.techpowerup.com/vgabios/7787…770-1024-100519
My modded VBIOS is the one I uploaded on my first Post, here: AMD and Nvidia GOP update (No requests, DIY) (17)
It has been like 5 years ago that I did it so I don’t remember the details, but I entirely modified the PowerPlay tables to underclock/undervolt the card and also modified the Fan Curve so it ramps from 40% Fan Speed at a much higher temperature to keep noise down, but also gets to full speed faster. Not sure if I did any other modification besides those, nor if whatever RBE version I used 5 years ago would produce an identical binary that if I try to mod it with a more modern one.
If I recall correctly, I tested both the original VBIOS and my modded VBIOS with updGOP 1.9.3 and they both worked, while I only tested my modded VBIOS with 1.9.5 since I assumed that the modded one always works. If you want to be on the safe side and discard any potential issues with the RBE tool, you may want to upload your test versions for both the original VBIOS and my modded VBIOS. I can test them all in one go the next time I reboot, with host reboots between test to discard warm reboot issues in the VM, which can screw results. If you really need, I can also test flashing with one of your special 128 KiB VBIOS and not providing QEMU a romfile at all, or better yet, testing if my Motherboard Firmware can boot with it or not (I’m currently using the Intel IGP for the host, the Radeon is untouched until QEMU launchs the VM), but testing native results will be a bit more involving that merely providing QEMU with different ROM files since it would require multiple flashings.
Also, it could be useful if you get another guy to try to reproduce issues with another model of the series where the microcode relocation applies. My results should apply for 5750, 5770, 6750 and 6770 since they’re all Junipers.
@lordkag
Many thanks for your time and modified GOP, I appreciate it a lot 
.
I’m not a miner but know a person who is heavily involved in mining, I will ask him to ask on mining forum if there is an app for cracking ati bios. I don’t think there is, otherwise I would not be getting requests on OCN by him to help solve “signature issue” for miners with RX 480.
Thank you for the tip on MemoryInfo 
I will update it and see if it improves compatibility for RX 480 owners. As the bios signature is a bigger issue for those owners at present I won’t be too fussed about MemoryInfo and will not ask you to spend your time on it .
I added the GOP from folder Test1 to GOPupd and then updated a custom non UEFI ROM I use 24/7. I can report it PASSES testing (SB = OFF FB = On CSM = Off) mobo posts and enters UEFI 
. If I enable SB then mobo will show this on-screen. As Windows 7 UEFI will not load up with CSM Off I’m gonna install Windows 10 and see what goes on , if your Test1 GOP passes Win 10 OS load test I will get some other Fiji owners on OCN to test and report back to me.
Here is a Zip, it contains my Custom Non UEFI ROM (custom.rom), that updated with stock GOP and the test1 GOP.
*** edit ***
Did fresh install of Win 10 (SB = OFF FB = On CSM = Off) using custom rom with test1 GOP and all successfully installed (System information > Bios mode: UEFI ).
@zir_blazer
Here are some tests to figure out the problem with microcode relocation. Test them like you did with GOPupd 1.9.3, using your modded VBIOS and QEMU - there is no need to use original VBIOS or flashing, considering the old image worked either way. Here is the content:
- Image1.rom is the same image produced with GOPupd 1.9.5, but padded to 256KB. This will show if QEMU truncated the image in any way.
- Image2.rom is the same image produced with GOPupd 1.9.5, but the microcode is replaced with padding. This will test if the hash check is responsible for your black screen. Depending on the result, it will also test if the microcode is responsible.
- Image3.rom is produced with GOPupd 1.9.5, but the GOP is much older and smaller, leaving the microcode at the same offset and the signature intact. This will test if the microcode is responsible.
- Image4.rom is produced with GOPupd 1.9.5, but the GOP is patched to ignore the hash check. This will test if the hash was responsible, once and for all.
Please report the result of each image.
AMD_MC_Tests.rar (385 KB)
@gupsterg
Thank you again for the tests and the extensive report. Secure Boot is expected to fail, since any change to the EFI driver will invalidate its digital signature (different than the AMD one and publicly known and verifiable). However, the error message is more useless than if it was absent, I would have expected something like “Secure Boot has failed” or “XYZ driver failed signature check”, not this confusing report, which would rather point to hardware incompatibility.
Given this success, I should be able to patch the driver for Polaris users, as long as I have some volunteers. I would need two things from them: a copy of their current atikmdag.sys; a minimum experience in changing system settings. The first one is critical, as I don’t have the time, nor the fastest internet connection, nor the desire to download countless driver packages to match every user configuration. The second one is important for a smooth interaction, as the user needs to disable driver signature enforcement, reboot to safe mode and replace their original atikmdag.sys with the patched one, then boot in normal mode. It is important to keep the driver signature disabled for the entire time of using the patched driver. If the patching is successful and AMD takes its time in removing the hash check, there is the possibility of delegating a trustworthy user in signing the modified drivers, similar to what Fernando is offering in <this thread>.
No need to thank me , I have given nothing to this forum and feel humbled by the help given . I really do appreciate your time and providing solution which is working great for me on Fiji ROM . I have another OCN member starting testing on his system as well. I will definitely donate to the forum a small token of appreciation and urge others using your solution to as well. I think your UEFI/GOP will also work on Hawaii where I had issue on custom ROM with CSM = Off, as I no longer own a Hawaii card I will be seeing if another is willing to test it.
I have posted in the OCN Polaris bios mod thread regarding your offer of help, as soon as I have a member willing to be part of this venture I will guide them here. Perhaps it will be best if then a separate thread is started for that by yourself or the Polaris owner seeking help, as would think I have already created deviation in subject matter of thread. My apologies to members and host of site.
@gupsterg
I don’t think there is a problem in posting about this AMD signature in this thread. After all, there is no point in offering a modded VBIOS if it can’t be used. Having said that, it would have been better for the concerned Polaris users to come here and express their desire for testing, instead of using you as a relay. You have already done the most important test, now it’s just porting that change to drivers. I am starting to think that I am cursed or something, for every time I see a group of users complaining about a limitation and I find a workaround for it, there is hardly anyone interested in testing my patches. The last time it happened with <a patched BUpdater>, although there isn’t a week passing by without someone asking for exactly this sort of solution.
Hopefully, this time it will be different, as I already saw <a volunteer on OCN>. Since I am the one offering a solution for their problem and not the other way around, it is advisable for the discussion to take place on this thread. The patched driver for the user <generaleramon> is attached. It must be tested like this:
- disable driver signature enforcement. There are guides all over the web, one example being <this one>. The permanent solution is required, for as long as the patched driver is used. Reboot and make sure the Test Mode message is present in lower right corner.
- reboot in safe mode and replace original atikmdag.sys with the patched one.
- boot in normal mode and flash any custom VBIOS.
- reboot and test driver loading.
- report the result.
There are several hashing functions in this driver, some of them being used for COPP content. I might not have found the responsible one in the first try. If this is the case, testers should be armed with patience, as this isn’t a walk in the park.
atikmdag.rar (6.29 MB)
Today I finally beat my lazyness and tested your Images.
TL;DR version: image3.rom works as intended, produces same results as the working one made with 1.9.3. 1, 2 and 4 does not work, they behave the same as my 1.9.5 one. image3.rom, being 128 KiB in size, would also be an interesing candidate for flashing.
Ultra long extended edition:
I shut down my Xen 4.5 VM with the Radeon 5770 using Secondary VGA Passthrough (The ROM doesn’t get loaded at all, the Catalyst Drivers initializes it during Windows boot splash screen) and used the Linux reboot command to reboot the system. Booting with my test Arch Linux install with QEMU, which is in the same state as when I made the other tests some months ago, I fired up the test VM (Which has Windows 10 installed) using image1.rom, and it worked since it shows the OVMF splash screen then boots Windows 10. Shut down the VM, rebooted, tested with each ROM, and all them worked. That looked suspicious… so I decided to try also with the original 1.9.5 image. Guess what, it worked too. I decided to install the Catalyst Crimson Edition 16.2.1 Beta during that last test and reboot to check if GPU-Z was displaying correct info about Power States, and all seemed good. At that point I was a bit confused, so I figured out that those warm reboot tests were all flawed, as my main W10 install tainted the Radeon.
For my next tests I decided to do a host power off/on cycle between each image, since it seems that results could dramatically changed depending if my Radeon was successfully initialized previously. I started with the 1.9.5 image. As expected, it didn’t worked… at first. When I start the VM, around 3 seconds after doing so, which is when the OVMF splash screen should appear, I see that the Monitor stops flashing the red light from standby for like two seconds, then starts flashing in Standby again. This is what happened previously. However, when I decided to test what happened if I left it for a while, found that after around 30 seconds, the Monitor turns on, the status light gets solid red, and I see that the title from the QEMU windows changes to [Paused].
What happens at that point is depended on if Windows 10 was intending to do a normal boot, or if it wanted to enter Recovery Mode. If it wanted to do a normal boot, I see a severely glitched screen, and if I manually unpause QEMU, I see a Windows 10 blue screen mentioning a error that requires rebooting and blaming an ati-something-.sys Driver, but as that point is noticeable that the Radeon seems to be working, since its a normal screen, not a glitchy one. Performing a VM reboot suddently gets everything working, it shows the OVMF splash screen, and Windows 10 boots as expected (Either normal mode or recovery mode, depending if I passed the failed boot attempts threshold). If instead it wanted to boot into recovery mode, I see a black screen while paused, and if I unpause, I see a screen with blue background but with absolutely glitched text. Again, forcing QEMU to quit the VM and starting it again, produces working results. This behavior happens also with image1, 2 and 4, which the very first time fails to boot with a glitchy screen, then starts working as intended after rebooting the VM. image3.rom worked as the 1.9.3 version used to, from the first boot with no issues or workarounds required.
I later tracked down that the reason why I was able to workaround booting with the faulty images during these tests, was because I installed the Radeon Drivers. While the first time Windows 10 BSODs, the Drivers initialize the Radeon enough for the ROM to somehow work at the next VM reboots. This only happens if the Drivers are installed.
My next batch of tests included loading only the OVMF Firmware and not including the LVM partition with Windows 10. My original 1.9.5 ROM, and images 1, 2 and 4, produced the same results. Basically, is as the previous one, but without the Monitor turning on after 30 seconds, and no chance to workaround them since there are no Drivers that can initialize the card during late boot. These were the same results that I reported initially about 1.9.5. image3.rom worked.
My final tests were performed with OVMF and the Windows 10 partition attached, but I used the AMD Clean Uninstall utility to remove any trace of the Drivers. The results were identical to the previous one, only 1.9.3 and image3.rom worked, with the others the Monitor didn’t turned on nor QEMU decided to pause the VM by itself.
Basically, it seems that the Microcode is reponsible, but not sure why. Could it be that Microcode relocation requires more that a Pointer change? Since image4 seems to discard hash check issues, could it be possible that the Microcode contains something like, a self-reference Pointer that has an absolute location inside the ROM instead of being a relative offset?
@lordkag
My miner friend has tested your patched atikmdag.sys and all good in preliminary testing . The community there will most definitely be using your patched file.
OCN member yet to report back on testing but just going to notify members there of successful testing and perhaps others will come forward .
Many thanks for your help .
*** edit ***
OCN member matty50racer has also used your patched atikmdag.sys successfully, his post.
OCN member generaleramon has also used your patched atikmdag.sys successfully, his post.
My System Specs:
Motherboard: ASUS Z87-K (C2 Stepping) @ BIOS 1402
CPU: Intel Core i7 4771 (Quad-Core, HT enabled, 3.5GHz @ 3.7GHz by Turbo-OC)
RAM: 16GB (DDR3-1600, Dual Channel, XMP enabled)
SSD: Samsung SSD 840 Pro 128GB @ latest Firmware (RAPID Mode enabled, Over-Provisioning enabled) [GPT-Mode]
HDD: Samsung HD501LJ 500GB [GPT-Mode]
GPU: Gigabyte GTX 770 4GB @ FW 368.81 (WF3X OC Rev. 2.0)
Sound Card: Creative X-Fi Titanium PCIe @ latest Driver
Here is a detailed description of my Mobo (Specs included in the Manual):
Z87-K PDF-Manual
I hope this info is enough
AZ
@zir_blazer
While I was expecting some drops of light to shred through this mesmerizing mess, your tests got me even more confused than before. Based on Image1 and Image4, we can rule out any size issues. From Image4 we can discard hash check, as the patch was already tested by several users (in both GOP and drivers). Image3 tells us that the microcode in itself is not responsible, as it should get loaded and initialized properly with this image. The only remaining option is that the pointer change affects the image in a bad way. I know I located the proper pointer, as AMD has used 0x1A000, 0x1B800, 0x1C000 through the years and they are all referenced at [MCuC - 8] offset (first MCuC appearance). It could be as you said, that the microcode has some hard-coded values based on its intended location. Or that AMD has some other pointers or lengths related to microcode loading. Or simply that AMD has screwed up yet again. I just can’t understand why Image2 would fail, as the microcode is removed and simply has no function anymore. In a sense, Image2 is the same as the one produced with GOPupd 1.9.3, with the microcode pointer referring to a region different than the microcode actual location, as if there is no microcode at all. Why would the simple act of changing the microcode pointer produce a bad image, if there is no microcode involved? I can think of one reason alone, that AMD hasn’t added any safety checks regarding the microcode loading, or that they hard-coded that offset somewhere. Will need to give a second look for this microcode blunder, but I doubt I can fix AMD’s broken stuff.
This means that I have to add an option for those with cards “affected” by microcode presence, to let them select between removing the microcode (latest GOP is used, microcode pointer stays intact, image size stays below 128KB) and using an older GOP that keeps microcode presence and location. Then I have to add an option for selecting between original and patched GOP, for those with black screens when CSM = Off. More of these AMD “gifts” and my automated solution will turn into an interrogation. And when you think that AMD started with one GOP and a simple structure Legacy + EFIROM, as opposed to Nvidia using more than a dozen of GOPs and a complicated structure with special images and extended headers.
Y U DO DIS, AMD?
@AbsoluteZero
Your board should support CSM = Off, but there have been reports about older Asus boards being picky (read broken implementation). However, you still haven’t clarified the point of your graphic card having a GOP or not. Everything is in the first two posts, a simple test should have given you more than enough informations, a flash with an updated GOP should have concluded if the problem is in the graphic card or in the mainboard. I enjoy helping others in their problems, but I overly despise dragging the informations from them and I absolutely hate doing all the work for them.
@gupsterg
That is some good news! One thing I haven't added (more like implied), is that mixing drivers is a bad decision. For that reason, I have <uploaded patches> for all current released drivers and systems. If anyone uses an older driver (although I doubt Polaris is supported by them), it should attach its atikmdag.sys, along with driver version. Although I mentioned about the possibility of signing the drivers, this doesn't seem to be achievable. For starter, kernel drivers needed to be signed by MS (according to <this> and <this>) on any recent OS. Then comes the <Win10 requirement>, for every kernel driver to be signed by MS, with minor exceptions.
For anyone else interested, I have added a donation link in the second post. There are no strings attached to it, only offered as a different choice for those interested in offering their gratitude and support. There should be no concerns about GOPupd converting into a paid tool or any other variation of pay-for-use, the same thing remaining true for any of my other tools and offered help. I would also like to acknowledge the fact that GOPupd has received plenty of support from the community, it would be despicable of me to expect any form of payment.
@lordkag Very interesting work, thanks!
Have tested the patched files for Win7 x64 without success, tried both the 16.7.3 and 16.8.2 patches with corresponding drivers.
atikmdag.sys replaced in safe mode and AMD display drivers do not load on restart, despite windows showing as in test mode.
Tried both bcdedit commands and the F8 disable signature enforcement option, same result.
Device manager lists them as RX480 but gives the following error for each card:
This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)
Drivers load normally when replaced with backup copy of 16.8.2’s atikmdag (posted here http://www.filedropper.com/atikmdag
This is all still with default BIOS on pair of RX480 (figured I’d get the driver side ready before I did any editing)
I think I’m missing something. For image3 I suppose that you did the same as the other guy with a 5770 to make it fit in 128 KiB. In your next Post you also mentioned that "nothing was relocated", so I suppose that the Microcode was not touched at all. I also remember that you said that 1.9.3 produced images that were "not perfect since the microcode is not at the expected offset", but I don’t recall reading what changes you made to the Microcode before 1.9.4. I thought that 1.9.3 and image3 had the Microcode at the same place, so that is why I was thinking that its location could be hardcoded. But if 1.9.3 did changes to it, then my theory becomes rather invalid…
Considering that there doesn’t seem to be a lot of users with my card, I don’t really think that all the overengineering effort is justified if its only for this reason. Mine seems to be an edge case, which is already solved since the two working ROMs are more than enough (One for flashing, and an alternative one for QEMU). You may want to document this as a "possible know issue" and provide a link to download the older 1.9.3, or if you want to unify everything for the next version, merely not performing the Microcode relocation mod for these cards. An enhancement will be including the smaller GOP to be able to output a 128 KiB ROM for flashing out of the box, which is the only thing 1.9.3 lacked. With that, I expect that any other 57xx/67xx user that discovers your tool will be happy enough, as they will be fully covered.
Since you mentioned the CSM = Off thing, I think that is worth to mention that the test were performed using the EFI-only version of OVMF (The UEFI Firmware for the VM). OVMF can also be compiled with SeaBIOS as the CSM module, and there was another EFI-only version that added SMM emulation to use Secure Boot (But I don’t know if you have to manually add the required certificates). I didn’t tested with these.
The thing that I’m not satisfied with is that I believe that there is not enough proof that the Microcode relocation is broken at all. My results could be wrong since my setup is rather uncommon, with an old card that required specific workarounds for the ROM size contrains, with a RBE modded VBIOS, and, most important of all, with QEMU + OVMF involved, plus my Sapphire Flex model were know as "special editions" since they had more video outputs than the regular versions of the 5770s (And I recall from the overclocking community that sometimes a modded BIOS could break the extra video output or so). If someone else with a Juniper (Or at least other 5xxx series card) would confirm my findings, I would be more confident that my testing methodology works. Otherwise, you will be spending time trying to figure out what is wrong when maybe the issue is on my side.
Something that I can certainly state is that testing ROMs with QEMU is MUCH EASIER than flashing, for as long that you know some tricks I discovered on the fly like power off/on the system between runs. If you can think of other test that could be performed to be absolutely sure that QEMU + OVMF are as good as if you flashed the card and POSTed natively, I will happily run them (Like edge cases like a ridiculous big ROM file, or arbitrarily sized). QEMU makes for a much more convenient testing enviroment, since you don’t need to physically remove the card on every failed flash to set the BIOS to boot using the IGP. It would be quite useful to make sure it works as a perfect testing enviroment.
Hi this is what i not understand in "- if your VBIOS comes from a dump, you must remove the end padding, so that the flasher doesn’t complain about the big size of the file."
how do i do that to fit the 128Kb limit?This is for this Card ASUS EAH5770/2DIS/1GD5/V2 Attached is the Original and the Gop Updated take a look.
ASUS-EAH577.ROM.zip (47.6 KB)
ASUS-EAH577_updGOP.ROM.zip (106 KB)
@lordkag
Thank you for more atikmdag.sys , asder00 has had his atikmdag.sys signed privately, link to post. matty50racer has found a tool which creates unverified certificate for atikmdag.sys, which works when windows is in TESTSIGNING mode, link to tool.
@447711
The patch in itself is confirmed to work, as proven by several users. More than that, there are no structural changes between Win7/Win8.1/Win10 x64 drivers and respectively Win7/Win8.1/Win10 x86 drivers, with the only difference being that Win10 drivers also have an embedded signature, besides the digital signature provided by the Cxxxxxxx.cat file. I can see only two options:
- you replaced with the wrong file, so please confirm if the hash matches to the patched driver from Win7 -> x64 folder.
- Win7 needs a different approach in disabling the signature enforcement. Being on Win7, you can use the tool DSEO linked by Gupsterg. I know I also used it at the time of testing unsigned drivers.
For the second case please follow the threads linked by Gupsterg in <this post>. You should be able to find a suitable solution in them. I’m sorry if I can’t offer a detailed solution for every case, but this is intentional:
- I only dealt with disabling signature enforcement a few times in the past, hardly remember the exact steps I did. Most definitely I didn’t covered all the cases at the time, just a user-mode driver on Win7 x64.
- Frankly, the patch was offered as a favour for the kind folks from OCN, like Gupsterg, The Stilt and all others involved in AMD VBIOS modding. It wasn’t my intention to provide a full-fledge tutorial, just the solution. I don’t even have the hardware to test most of the stuff I write or patch, I’m still on my trusty 5+ years old laptop.
@zir_blazer
You’ve guessed it well, this was the reason of my confusion. Before 1.9.5, any present microcode was relocated because the GOP is simply too large to keep it at the same offset, but the pointer was unchanged. This meant that the microcode couldn’t be found by the loader, as if there wasn’t a microcode at all. So we have the image from GOPupd 1.9.3 that has the original pointer, the microcode is relocated and thus impossible to be loaded, but the image still works; then we have Image2, which changes the pointer, the microcode is removed and thus impossible to be loaded, but the image doesn’t work; then we have the image from GOPupd 1.9.5 that changes the pointer, the microcode is relocated to that offset and thus available to be loaded, but the image doesn’t work. It goes against any logic and the only possible explanation is that the pointer is hard-coded in the hardware or in the VBIOS/GOP/driver. For this reason, I have to offer two options for cards with microcode: one option for those that want the latest GOP and don’t need the microcode, another option for those that want or need to keep the microcode - older and smaller GOP is required. I wanted to offer the third option for users like you, that are not constrained by the limited chip size, and offer them latest GOP and microcode at the same time, but apparently AMD disagrees.
@gsowner
That was intended only for those that want to do it by hand, otherwise everything is handled by GOPupd. For your specific case, you need what I explained to zir_blazer above. Please wait a few days until I provide either a modded VBIOS for you or an updated GOPupd that does everything automatically.
@gupsterg
Thanks for reminding of that tool. I was reluctant to add it in the first post because I knew it was Win7 only, but I think the best possible solution for all OSes is to disable signature enforcement from command prompt with BCDEDIT and to self sign the driver with DSEO.
Ok im waiting since tuesday for your answer i have tried everything to make it work, please make me a uefi bios i will donate to this site.
Thanks lordkag for fils and your work!
U just tried to replace patched wile on Win764 and enabled test mode. Now after every reboot Driver loads and Test mode is enabled.
All i need now is to try some bioses 