@RoughBoy
@davidm71
The problem with your board is not Fast Boot/Secure Boot, since it didn’t supported this from the beginning. If it were about adding Fast Boot to an older board, it would have been understandable from Asus part. But your problem is that you have an option “PCI ROM Priority” that lets you boot from EFI drivers instead of Legacy ROM. And this is broken, with Asus already been aware of the problem and a fix in their hands. Try to explain it better and stand for your rights. They shipped a broken UEFI firmware from the beginning, so they should at least try to offer what it was promised at the time of release, nothing more. This is not about performance or Fast Boot, it is about a bug in their code that prevents you from running your board to full potential with the options Asus provided. If other OEM can fix older legacy boards for ROM space issues, why is it that Asus can’t fix an UEFI board?
@Sylar76
Thank you for the file, it has been added.
Version 1.6
- updated GM2xx to 0x2000A
- added AMD to database check. But this one will be difficult to follow. I have only started to add some GOPs and it is already grown with several types for the same version. Will think of what to keep if things get out of control.
- the temp folder will not be removed if the GOP is not in database
I know that and was very explicit in filling out the asus test report form. The fact the bios has a bug is what bothers me and that some manufacturers forget about a product not long after release. Personally I find legacy boot satisfactory but would love if they fixed their bugs.
@lordkag
Note 1: All the stuff below were done using the (now) older GOPUpd v1.5.
Note 2: To make the job slightly less consuming, I added the line “os.remove(file_dir)” whenever “GOP is not present!!!” was reported.
Today I tested GOPUpd with 10010 vBioses and these are the results:
AMD:
ALL → There was no repository at v1.5 so I have included all 263 vBIOS images which have a GOP of some sort inside. There is nothing newer than 1.58.0.0.0, only older stuff.
APPLE-UNCOMMON → These are Apple vBIOS images and of course they are different. Classic Apple.
NVIDIA:
ALL → In case I missed something at the following folders, I have included all 500 vBIOS images.
DUAL MONITOR → These are Dual Monitor vBIOS images. Included is an OEM release-note document from Nvidia. Is that the Multi-Display firmware you were looking for?
MXM → These are MXM vBIOSes, reported as unsupported. One of them is at the repository (kept for testing), the rest are new.
NOT IN DB → Images which are not at the repository, old but missing from the DB.
OTHER → A .exe update which I don’t know how to properly extract. GOPUpd does find a GOP inside but I suspect it may hold more than one. Manual hex checking is required.
UNCOMMON → A Clevo vBIOS that reports “Not GOP or GOP is not common type. Please report it!”.
UNKNOWN → Images that are GOPs but report "Unable to determine GOP type!"
PROBLEM:
A 2011 vBIOS from an AMD FirePro V5900 which causes an error. It either has an ancient AMD GOP (0.0.1.18.5) or it’s accidentally detected as having one. The latter is most probable. Either way, manual hex checking is required.
FORUM:
The 0x2000A GOP, ignore it.
vBIOS Collection 22-05-2015:
All 10004 vBIOS images from TechPowerUp, updated as of 22/05/2015. Everything below 120KB certainly do not have a GOP inside. Warning: That 30.1MB archive extracts a 881MB folder (3% compression - RAR5 256MB).
Download Link: http://www.mediafire.com/download/vcl6tj…for_Lordkag.rar
EDIT 24/05/2015:
Attached GK1xx_MXM 0x1002A GOP
GK1xx_MXM 0x1002A.rar (128 KB)
Because it’s already included at GOPUpd v1.6, no other reason. As I said at Note 1, all the above were done using the older v1.5 version of the tool.
@plutomaniac
I took some time to reply, because I wanted to get the entire collection parsed and supported. I can’t thank you enough for the collection and I will add a few more words at the end.
When doing mass searches, it is easier to add a sys.exit() right before "Do you want to update GOP…". It is also easier to place all ROMs in one folder and use XSearch with hexadecimal string F10E0000, which is 00000EF1 in little indian. Only the EFI ROM has this string.
By looking at the current database file, I would have never added AMD GOP for checking when the version is lower than 1.53.0.0.0, it is just impossible to capture them all. But now that I have a big collection of files, it seemed like a small step to do.
I have added a version display for Mac GOPs, if there is a version to be found. But I have only a few samples and the EFI is not recognized by either AMD/Nvidia tools, so it is an Apple made EFI driver, with a big chance that the structure will change between different cards and different versions.
This is only an example, not a real image, but the multi-display should look like this:
I have added GK1xx_MXM and GM1xx_MXM to the updater. With GM2xx there seems to be a single image, while GFxxx and GT21x are less likely to be found as MXM GOP.
This one is similar to the two .run files and they are packed as following:
But only one image is OK, the rest are mixed. I can’t get them properly unpacked and they don’t seem compressed, because I even tried to dump the region of the running process. Maybe they are using a packing similar to xdelta, maybe it is a packing related re-structure, I don’t know. The .run files are OK, since they have only one ROM image.
I don’t know what to think about that uncommon Clevo. It looks like a normal Nvidia GOP and it is MXM, but no tagging what so ever.
One way to determine the GOP type for Nvidia, when the ID is missing, is to inspect the first ROM image, which usually has "GXxxx board" message. That is, if they don’t mix the GOPs. I plan to add this as a hint message, when the type can not be determined.
I fixed that AMD FirePro V5900, which looks like a really old version. I don’t want to bash AMD, since they try to open source some good stuff, but they don’t have a clear set of standards. And it is not just about the version in GOPs changing to a different structure all the time, the same thing happens with microcodes and other firmwares.
Pardon me, my fair knight, but your collection is missing one file, not to mention you missed some GOPs. I refuse to accept an incomplete collection. Do you actually expect me to do some work?
Of course, this was a bad joke from my part. It had crossed my mind to get the database from techpowerup, but I would have never found the courage the get the job done. I’m afraid to ask you how you got it, I will just assume you know someone there, so I can sleep better. At first, when I saw that you mention a few hundreds AMD files and other few hundreds Nvidia files, I was wondering if my math or yours is broken. I could not find those 10004 images in the folders and was browsing the archive with WinRar using the tree view, so I managed to miss that other archive. After parsing that folder with XSearch, getting files with F10E0000 content and comparing with your folders, I got 8 extra files + 1 newly published. From those 8, one was a false positive, two were badly compressed (not even ATIFlash was able to unpack them) and 5 were regular Nvidia, nothing new.
Your collection reminded me that there is another old collection of techpowerup. After updating the database with your collection and parsing that old one, I can say he is right, they don’t publish all files. Around 75 files were not in database and by extension not present in your collection, not counting those that are already in the database. Even so, your collection is a big step forward, so you have another thank you from me. I will search HP and Lenovo for more images, maybe also MSI and Gigabyte. Asus is using a tool to retrieve the newer versions, so it is a no go, others might not publish VBIOS files or are just old versions.
Another release, version 1.7 :
- added GK1xx_MXM and GM1xx_MXM
- updated GM1xx to 0x10030
- fixed AMD version until it will be broken again
- added Mac version display. Only AMD works well, Nvidia is missing the version most of the times.
- enabled Mac GOP replacement, but the validity of the new image falls in user’s hand. Drop the compressed image as mac_gop.efirom in GOP_Files. Then check the resulting file on your own. I have only a few samples of Apple images and no intention of supporting them.
Because I was dealing with thousands of files, I wanted to automatically delete those that didn’t have a GOP inside. Unfortunately I didn’t have a searcher like XSearch that could detect HEX so I decided to modify the python script slightly to do that for me. A searcher would have made this easier indeed, especially now that I know what hex bytes to look for exactly. I have added such a feature at ME Analyzer as well which helps immensely. It scans all the files with no user intervantion and if something new is found the file stays intact, everything else is deleted on the spot. Thus, in the end I may end up with let’s say 20 "new" files from the original 1200.
Apple has this obsession to change everything, modify it and make it their own. Well after seeing custom ME firmware, I should have expected this as well I guess.
Yes I saw it at the python script but I wondered whether there was a mistake or similar with it’s detection. Better safe than sorry.
It’s an Nvidia update executable of sorts. I know it includes a lot of GOPs because the text file accompanying it mentioned around 5 different vBIOS versions for different cards. Generally those Dual-Monitor, custom Nvidia .exe files etc are all from Dell.
I will search at some point the Clevo BIOS mirror site because it also includes their updated MXM vBIOS. If it’s a pattern then maybe more investigation is required. Otherwise, I don’t know, maybe that specific file had some issue.
Oh the Sign-On message, yes I see. I’ll keep that in mind. Hopefully they don’t mix and match GOPs though (as you said)…
Nope, I wish. Thing is, if they allowed listing of more than 50 images per page I would have finished acquiring the links in 2 minutes. But, because they allowed 50 links per page of a total of 201 pages (thus 10004 images because the latest page had 4 only) it took around 45. I use a chrome extension called Linkclump which allows me to select a big list of links and automatically copy them to clipboard among other things. So for every page of the 201, I formed a box with the mouse and those 50 links were copied to the clipboard automatically. From there, I used Internet Download Manager which has a feature to automatically grab clipboard links. So the procedure was load next page, copy all 50 links, get grabbed by IDM and added to Queue. Multiply this by 201 times and bingo. The procedure afterwards of modifying the script and loading 200 files a time at GopUPD (because it doesn’t accept more, batch limitation) was a whole other "time beast".
Unfortunately, there is no way to determine when new roms are updated at the collection and where they are placed. Yes, I would for example now see 202 pages but I wouldn’t know where the new files are. It could be page 2, page 69, page 200 etc. So, this collection cannot stay up-to-date unless someone does the same thing in the future.
I’m surprised I didn’t miss more "valuable" files to be honest. Most probably those 9 extra files were deleted by my code addition because GopUPD reported the GOP not present error. Still, it’s good that you double checked.
Honestly I was surprised that GOPUpd showed such few "errors" after being tested with so many files (10000+)! You have done a great work, that’s all I have to say. 
Wow, awesome developments here since i checked last time… Newer GOP already incorporated and flashed!
It seems that when CSM is set to auto or disabled, my board can’t handle bootup with two (identical) graphics cards installed though. When turning my system on, display is initialised but nothing more happens…
I tried this with the original Asus GOP-vbios as well, same result. So i guess there’s a persistent bug somewhere.
When i enable CSM and force UEFI on my boot device and PCI-E expansion devices,all goes well. This is with a Asus Crosshair V/F-Z and 2x Asus gtx660.
If you enable CSM and force UEFI on devices, it will most likely default to Legacy when GOP is not loaded. But have you tried with only one card, can it boot then? If it works, it might be the mainboard’s UEFI firmware and a bug report to Asus could make them to fix it. Also, do you have the latest BIOS/UEFI 2201 for your mainboard?
The GOP version is pretty much updated, there is only one new update - 0x10030 - that I need to track down. I trust Nvidia would have found and fixed such a simple bug like yours by now. I know that Davidm71 had a similar issue with two cards, which was fixed with a GOP update, meaning that Nvidia did their work. So try with one card and report to Asus if it works.
I had the same problem fixed with GOP update. He should first troubleshoot with one card installed and update gop if needed.
Hi lordkag, thanks for the powerful tool. Here are the outputs from my tests.
Video card: XFX HD 7870
Shipped with this VBIOS: http://www.techpowerup.com/vgabios/12628…048-120420.html
Sadly XFX won’t update it, but I managed to add the GOP driver from a similar PowerColor model a while back. The interesting thing is that it contains an ACPI table “VFCT”, which in turn seems to represent a small part of the VBIOS and influences the cards clocks, probably among other things.
1.1) Adding the GOP driver to the original, legacy only VBIOS. The resulting MD5 hash is A5D00C8BECB8607D00EDB82BD61ED4FE.
Update EFI GOP
Drop VBIOS file on this .bat
Dumping info from = orig.rom
ID of ROM file = 1002-6818
No EFI ROM found!
No EFI ROM found or error on decompression !!!
Extracting with Python…
---------------------------------------------------------------
Processing with GOPupd…
GOP is not present!!!
Do you want to update GOP to latest available? Y for yes or N for no: Y
Fixing last-image-bit in PCI Structure of Legacy ROM!
Using AMD byte for checksum!
Fixing ID for EFI image. No checksum correction is needed.
Removing unnecessary end padding.
File “orig_updGOP.rom” with updated GOP 1.58.0.0.0 was written!
---------------------------------------------------------------
Press any key to exit…
1.2) Checking the GOP version of the new file
Update EFI GOP
Drop VBIOS file on this .bat
Dumping info from = orig_updGOP.rom
ID of ROM file = 1002-6818
Extracting with UEFIRomExtract by AndyV
Found compressed EFI ROM start at 0x58
Input size: 58280, Output size: 105128, Scratch size: 13360
---------------------------------------------------------------
Extracting with Python…
AMD GOP 1.58.0.0.0 LibBuild ---- Dated: Feb 17 2015 15:41:41
AMD_Build 156 AMD_ChangeList 1122881 GOP BIOS_IDTF 0xDEADBEEF
Most likely signed by: Microsoft Corporation UEFI CA 2011
Machine Code = x64
Checksum CRC32 = F047653C
---------------------------------------------------------------
Processing with GOPupd…
You already have the latest available GOP!
---------------------------------------------------------------
Press any key to exit…
2.1) Updating the GOP driver in a custom VBIOS (attached). The resulting hash is C36B7E06A477630DC146868E4B7DB7DC.
Update EFI GOP
Drop VBIOS file on this .bat
Dumping info from = mod.rom
ID of ROM file = 1002-6818
Extracting with UEFIRomExtract by AndyV
Found compressed EFI ROM start at 0x5c
Input size: 61348, Output size: 104632, Scratch size: 13360
---------------------------------------------------------------
Extracting with Python…
AMD GOP 1.46.0.15.32 LibBuild 2208 Dated: Feb 14 2013 14:08:53
AMD_Build 257145 AMD_ChangeList 885532 GOP BIOS_IDTF 0xD1DDFF2F
AMD GOP has tables! Customized GOP with legacy parts!!
Legacy BIOS_IDTF 0xD1DDFF2F
Most likely signed by: Microsoft Corporation UEFI CA 2011
Machine Code = x64
Checksum CRC32 = 4564C35A
---------------------------------------------------------------
Processing with GOPupd…
Latest available GOP is 1.58.0.0.0
Do you want to update GOP to 1.58.0.0.0? Y for yes or N for no: Y
Fixing ID for EFI image. No checksum correction is needed.
Removing unnecessary end padding.
File “mod_updGOP.rom” with updated GOP 1.58.0.0.0 was written!
---------------------------------------------------------------
Press any key to exit…
2.2) Checking the GOP version of the new file
Update EFI GOP
Drop VBIOS file on this .bat
Dumping info from = mod_updGOP.rom
ID of ROM file = 1002-6818
Extracting with UEFIRomExtract by AndyV
Found compressed EFI ROM start at 0x58
Input size: 58280, Output size: 105128, Scratch size: 13360
---------------------------------------------------------------
Extracting with Python…
AMD GOP 1.58.0.0.0 LibBuild ---- Dated: Feb 17 2015 15:41:41
AMD_Build 156 AMD_ChangeList 1122881 GOP BIOS_IDTF 0xDEADBEEF
Most likely signed by: Microsoft Corporation UEFI CA 2011
Machine Code = x64
Checksum CRC32 = F047653C
---------------------------------------------------------------
Processing with GOPupd…
**************************
You already have the latest available GOP!
---------------------------------------------------------------
Press any key to exit…
The files produced after the steps 1.1) and 2.1) are different, but this is due to the dirty way of fixing the checksum by changing the last byte of the legacy part, I guess.
I didn’t test the resulting VBIOS yet, as I am quite happy with the situation right now. But I will do so in a couple of days.
PS: Hopefully the abscence of screenshots doesn’t bother you too much
EDIT:
I am using the updated VBIOS without the CSM now, everything seems fine.
mod.zip (101 KB)
I got the same results and everything seems fine, there should be no issues in flashing this image. And you are right, the different hash comes from the fact that you changed the last byte, while I change the AMD checksum byte. But this has no practical importance.
The story with the legacy tables in GOP goes like this. The GOP driver needs to be signed to pass Secure Boot and to ensure no malware has been added to the code. But at the same time the GOP driver needs to load some configuration data, which can be found on the unsigned legacy ROM. To solve this breach of trust, the vendors have three solutions: 1 - copy the configuration data in GOP, which increases size, increases time in debugging, endless trouble with signing multiple images; 2 - apply an authentication to both legacy and UEFI; 3 - hash the legacy ROM and let the GOP driver authenticate it. First one is sometimes used by AMD, the third is always used by Nvidia in newer cards. I don’t know if Nvidia is hashing the entire image or just the legacy ROM, but if they hash only the legacy part and the image already has a GOP, then my script should not break the hash, since I only replace the EFI ROM, which has a compressed, untouched and signed GOP driver. If they hash the entire image, I don’t know what this will do to Secure Boot, but I haven’t seen anyone complaining about failed boot in the GPU modding forums. Probably only legacy is hashed or the hash is checked by the nvflash during flash.
Starting with version 1.53.0.0.0 AMD has abandoned this convoluted solution and is offering a universal GOP for all cards, loading the configuration data from legacy. But they don’t use any hashing method for legacy ROM, leaving the door open to any sort of modification.
For your card, I recommend to update to latest GOP if you plan on using Fast Boot or Secure Boot. Not only you will have the latest version, but you will avoid using the tables from another card, which might not be entirely good for your card.
Wait…what?!? When i launched my pc today, and the Windows 10 logo appeared,i was on my desktop only 6 seconds later… That’s less than half the time it used to be! Rubbed my eyes…rebooted…same result!
I already had the latest mainboard bios flashed,combined with the 1002D vbios GOP on both gfx cards.
Haven’t changed anything else,so it must be the newer 1002F GOP that is responsible for this. Not sure why this didn’t happen after a warm boot.
Lol… will try
-to see how CSM responds now ->edit-> same bad behaviour when turning it off
-retry 1002D GOP to see if startup -> edit-> time is decreased again. -> erratic results,sometimes system boots fast and sometimes not. Something dodgy going on. Win 10 needs 2 cold boots to accumulate.
-to run with only 1 card and see how csm responds ->edit -> This was fine, a 1 card setup does not mind if i set CSM to Auto, Enabled or disabled!
I have to add an interesting and weird discovery. I use KGB to edit my vbios’es and raise the power target of my cards.
When i’ve done a fresh flash of the cards and boot into uefi mode,there is no way to raise the power target…as if the vbioses were not modded.
When i force my PCIE devices to boot in legacy mode,i can raise the power target again. When put back in UEFI mode,i can still raise it.
But, Windows would still prefer to boot in legacy mode then… To solve this i had to disable the fast-boot feature in Windows, and re-enable it! After that, fast boot and graphics cards are power tweakable.
Final thoughts…it seems that a single card bootup/CSM disabled is about as fast as a dual card with CSM and forced UEFI… maybe the first part of system initialisation is a bit faster,but windows startup is just as fast.
I’ll still see to contact Asus and see what they have to say!
For starter, I don’t think Win 10 can be used as a reference, since it is not even RTM released, let alone having important updates. If I were you, I would test this on Win 8.1 with all updates. There are two other things to consider:
- if one card is working with CSM disabled, most likely it is an Asus bug, since the GOP is already updated. So try with Asus first.
- your different results with booting speed and power target might be determined by the way Fast Boot works. That hibernation part could prevent the system from fully updating with new conditions. So a proper full shutdown (or restart) is recommended. And since you updated the firmware, a reset to defaults is also a good way to ensure that the system has integrated all new components.
Thanks for all this! Will do some more testing with win8.
I have been emailing with Asus now…i started with clearly explaining things > they tried to give me the run around,by saying it’s Win10’s fault > responded that i had clearly stated that system wont even post with 2 gfx cards and CSM disabled,and OS does not even get a chance > now they are saying; ‘clear cmos by flipping the battery around,and leave it like that for five minutes…see if it helps’
Whut?!? I have to reverse polarity of the battery? Never heard of that before?!? Is a normal clearing procedure not good enough? I cleared it a few times already.
What do you guys think of that…do or don’t… yay or nay? Is this a dangerous thing to do?
The fact that it didn’t worked with the original GOP means that it is more than a CMOS thing. Even if we assume that the newest Nvidia GOP has fixed it, it would have kicked in when you switched between Legacy and UEFI.
Some boards have a dedicated button for clearing CMOS, or some dedicated pins that you can short. If this is not the case with your board, the regular CMOS reset can be done with just removing the battery for a few minutes. If you really want to be sure it was reset, you can use a metal piece to short the connectors that hold the battery in place (i.e. close the circuit without the battery). The board has to be shutdown, of course.
I recommend to follow these steps:
- have the latest GOP -> you already did this step
- reset BIOS to defaults, shutdown.
- reset CMOS as instructed above.
- set the system to CSM enabled and Legacy first.
- boot to Windows and run from command prompt: Shutdown /s /t 0
- set the system to CSM disabled, but no Fast Boot. See how it goes.
- set to CSM disabled and Fast Boot. See how it goes.
Also run the tests with Win 8.1, but the bug likely falls on Asus shoulders. Be sure to remind them the tests you have done, including the fact that one card has no problem booting.
Seems like Techpowerups Gpuz now reports wether or not ones gpu has uefi gop capabilities. Doesnt report much else unlike lordkags update tool.,
@lordkag
Did you know that AMD has a small tool called GopInfoX that displays info regarding the vBIOS itself and the GOP inside?
Also, I scanned a new set of vBIOS images from an OEM (you’ll know once you see the files).
This time I used your advice (F10E0000 , sys.exit() and :: at the batch’s echo) and the process was a lot smoother. Combined with the fact that GopUPD keeps any new_gop folders made the job a lot easier.
Some GOPs cannot be properly identified but the filename and foldername will show you from which card these images were extracted from.
GOP_07-06-2015.rar (4.74 MB)
I actually found this tool a couple of days ago and I remember seeing one from Nvidia also, with the name RomInfo or similar. Yes, it could be a candidate to replace the flash files. My only concern is that these tools are older than the flashers, so I don’t know if they have all the fixes. The Nvidia one definitely won’t be used, since it is much older, but for AMD GopInfoX I would have to do a comparison on a large database.
Thanks again for the new files. If it is not too much to ask, could you send me a PM with the details on how you got this collection? I’m not trying be lazy, but I would like to avoid doing the same thing i.e. skip this OEM when I will scan for VBIOS files. This is starting to be a general excuse, but now you caught me doing some maintenance on Extractor, cleaning the code, so GOPupd was left in the shadows. But I did managed to update some things and also scan HP and Lenovo. Nothing as strong and secure as an entire database parsing, just some Google searches using keywords.
Now back to the attached files:
- Gigabyte has screwed some images. If not even latest NVFlash can recognize them, then they are broken. There are 8 images that seem to have only the compressed EFI image altered, so this is not a big problem in itself, unless you use UEFI Boot. But other two are damaged in other areas, with one even having the important NPDS signature changed to N@DS, which makes them unusable even for the normal use. I wonder how they test the images before release.
- It is the first time I see a changed Nvidia GOP. And there are two of them, for 0x20007. Either this is again just one of Gigabyte’s fault (but the signature is also changed, meaning a human intervention), or it is a quick fix for one of their cards. Since the latest version is 0x2000A, this is not relevant anymore.
- I just look at AMD database and I’m amazed - what were they thinking? All this work with constantly compiling and signing EFI images for different cards, when they could have just release one EFI image, hash and sign the legacy ROM, then check this from inside EFI, which is signed on its own. At least they have come to their senses with latest GOP versions.
Another release, with the following:
- renamed the folder and bat files related to ROM info. I tried removing sys files, but AMD didn’t liked it. I hope that users won’t try to use them for flashing.
- updated GF10x to 0x1001C. Not yet as new as others, but definitely better than the old one.
- updated GK1xx to 0x10030.
- updated GK1xx_MXM to 0x10030.
- added support for Nvidia old images that had all ROMs images with 55AA sig. Not sure if these cards can actually use the GOP.
- added support for Nvidia multi-images in one container.
- added GPU hint for Nvidia card with missing GOP or unknown version. This just displays the product name, so it might not always be helpful, depending on what OEM have added there.
- added AMD GPU microcode report. I have only found it in old images and always at offset 0x1A000, which will be overlapped by the EFI ROM. So users will have to choose between GOP and microcode.
As of now, only GT21x and GF10x needs updating. I managed to find a GK1xx multi-display image, so I will add it in next version, with the hope that I will also find one GM1xx multi-display. The support for Nvidia images with old structure (= all ROMs with 55AA signature) is offered as-is, I’m not sure if those images can work with an EFI ROM. The support for multi-images in one container was added since I saw even newer images with this structure. I had to choose between breaking the container in smaller images or adding the EFI ROM after container. I went for the second option, since it is easier, safer and also used by Nvidia, according to one sample I have. I just add the EFI image after the container, then fix the last-image-bit in first ROM and last special image from container, then fix the checksum of first and last ROM from container. The AMD GPU microcode, apart from appearing in old images, it is also fixed. I tried changing its location, changing its pointer, ATIFlash seems to detect it only when it is at 0x1A000. So if someone tries to update such an image, it will most likely loose the microcode function, since it will be relocated to a higher address.
No I don’t see it as being lazy, not at all. You have many useful utilities to maintain, obviously not all at the same time. I’ve sent a pm with certain details.
AMD needs to generally step up their game. It’s not only the constant format and standard changes, if you come to think of it they haven’t released a descent desktop cpu since 2012 or something. The same could be said for most of their graphics card line. Some cards (not the very high end ones, 290,390 etc) are rebrands of rebrands (since 7xxx series). However, I do admire some of their initiatives like Mantle and FreeSync. Still, they seem to be always a step or two behind of manufacturing, technologies etc.