- Joined
- Aug 16, 2005
- Messages
- 26,381 (3.80/day)
- Location
- Alabama
System Name | RogueOne |
---|---|
Processor | Xeon W9-3495x |
Motherboard | ASUS w790E Sage SE |
Cooling | Noctua NH-U14S DX-4677 |
Memory | 128gb Gskill Zeta R5 DDR5 RDIMMs |
Video Card(s) | MSI SUPRIM Liquid X 4090 |
Storage | 1x 2TB WD SN850X | 2x 8TB GAMMIX S70 |
Display(s) | Odyssey OLED G9 (G95SC) |
Case | Thermaltake Core P3 Pro Snow |
Audio Device(s) | Moondrop S8's on schitt Modi+ & Valhalla 2 |
Power Supply | Seasonic Prime TX-1600 |
Mouse | Lamzu Atlantis mini (White) |
Keyboard | Monsgeek M3 Lavender, Akko Crystal Blues |
VR HMD | Quest 3 |
Software | Windows 11 Pro Workstation |
Benchmark Scores | I dont have time for that. |
ARC is in its infancy and I have playing with the platform since around the end of last year. I have several cards and found it curious that when I installed my older A380 the BIOS was older. After some searching I realized Intel takes a different approach to firmware updates. The updates are done during driver installation. It should be noted this FW update ONLY happens during the driver install; NOT if you are putting another intel card in IE: A card returned from RMA, or an upgrade.
Accessing the firmware and the tools was as easy as unzipping the newer drivers, or "opening file location" from task manager on older drivers with the installer running. With executable and firmware in hand I soon found that the flash tool included in the drivers could not be easily manipulated on its own. I eventually found that Intel themselves host this code as opensource in there git.
GitHub - intel/igsc: Intel graphics system controller firmware update library.
Intel graphics system controller firmware update library. - GitHub - intel/igsc: Intel graphics system controller firmware update library.
With the repo in hand I compiled the tool (Attached) and started to see what could be done. It should be noted that you CANNOT backup the BIOS using this tool (YET). However flashing may prove useful for those that like a certain driver version but want the various clock or power limit changes of a newer one.
I also made a GUI wrapper for this tool which is what we are covering. The file is attached to this post, but new versions can be downloaded from the applications update mechanism or github.
Updates to the tool can be found here:
GitHub - Solaris17/ARC-Firmware-Tool: Wrapper for IGSC
Wrapper for IGSC. Contribute to Solaris17/ARC-Firmware-Tool development by creating an account on GitHub.
You should still read through the old guide to truly understand what is happening. It is in a large spoiler.
Lets get started.
Getting Started
The firmware tool is a wrapper for IGSC the console tool used to interface with the GPUs. Intel delivers firmware during the display driver package install.
This comes with some caveats.
- Windows auto install will not update the firmware.
- Installing a new Intel GPU and using the previous installation will not update the firmware.
- Installing previous drivers will not rollback firmware (Driver installs are upgrade only)
- If the flash process times out during the driver install it will not attempt to install the firmware again.
As you can see too much can be left up in the air. As development matures and driver release cycles slow down depending on how you maintain your system you may find yourself behind on firmware.
Further; power limits and clock changes that exist in a certain firmware may not exist in a newer one as power or thermal limits are imposed.
This tool will allow you to downgrade which can be beneficial for those chasing performance or stability.
How it works
Intel unlike Nvidia or AMD does not utilize a single binary to update firmware. Instead they trigger several different firmware upgrades during driver install depending on the card and component.
This is a short definition of the fields provided by the tool:
Code:
Firmware: Main FW payload. This will have ```"_gfx_fwupdate_``` in the title; like ```dg2_gfx_fwupdate_SOC1.bin```.
Oprom (*Data*): Oprom data. This will have a ```"_d_"``` in the title; like ```dg2_d_oprom_asr770.rom```.
Oprom (*Code*): Oprom code. This will have a ```"_c_"``` in the title; like ```dg2_c_oprom.rom```.
(The Data and Code versions can differ, but they are often the same.)
FW Data / Config Data:
- FW data. This will have ```"_fwdata_"``` in the title; like ```dg2_fwdata_asrock770.bin```.
- FW Config data. This will have ```"_config"``` in the title; like ```dg2_intel_a770_config-data.bin```.
- (They utilize the same field on the flash tool.)
The sequence chosen reflects the sequence of the flash as it appears in the Intel driver flash log. While no ill has been seen from flashing out of order the sequence was kept anyway.
How do I begin?
First you need the firmware files. You can download the latest firmware zip from the flash tool.
If you are looking for a specific release you can check out the firmware matrix I compiled here:
![www.techpowerup.com](https://tpucdn.com/forums/data/assets/logo/logo-og-v1.png)
Intel ARC Firmware Compilation Matrix
Hi all. This is a section originally published in: https://www.techpowerup.com/forums/threads/guide-flashing-intel-arc-gpus.311964/ However given the work involved and the size of the table I decided to break it out. While the two topics do relate to each other closely (you should give the...
![www.techpowerup.com](https://tpucdn.com/forums/data/assets/logo/icon-192-v1.png)
Once you have your files it as simple as making sure they are put into the correct boxes using the guide above.
Intel LE card FW files are generally generically named. Such as: ```dg2_d_oprom_IBC512.rom``` (A770) or ```dg2_intel_a750_config-data.bin```
Now that you have your files lets load up in the software
You don't need to flash every firmware type. If you want to experiment and only update a specific feature you can.
![](/forums/proxy.php?image=https%3A%2F%2Fgithub.com%2FSolaris17%2FARC-Firmware-Tool%2Fblob%2Fbeta%2Fpictures%2FFlashing.gif%3Fraw%3Dtrue&hash=c95699891c627368bb035d0769e8f2e4)
The flash output will be displayed in the text box. You can scroll around to check the output or we can save the log which is next.
"Error: Failed to read." is a generic warning given when a field is empty during processing and nothing to worry about. The actual flash data is still available from all phases of the flash.
Saving the log is as simple as pressing: ```File > Save Log``` from the menu. This can also be done if just doing a hardware scan.
![](/forums/proxy.php?image=https%3A%2F%2Fgithub.com%2FSolaris17%2FARC-Firmware-Tool%2Fblob%2Fbeta%2Fpictures%2FLog-save.gif%3Fraw%3Dtrue&hash=3c7bab5b266969eb4b319e673c5c19ce)
You're Done!
You did it! That is really all there is too it!
Intel's flashing tool and protections are resilient. While it is not impossible for a bad flash to happen given that FW updates generally happen during driver install and there are many in circulation the changes are slim.
The flash tool also has methods of cross flash protection so selecting the incorrect firmware wont result in a brick.
Finally; the tool has a really robust flash failure mechanism. In the event the cards I/O doesn't respond and the flash is terminated, not only will you get it in the logs, you can always try again!
More screen shots available on github.
![](/forums/proxy.php?image=https%3A%2F%2Fgithub.com%2FSolaris17%2FARC-Firmware-Tool%2Fblob%2Fmaster%2Fpictures%2FScanning.gif%3Fraw%3Dtrue&hash=16176332f0051dfd37a806c8917aa620)
Checking Versions
Intel ARC cards come in 3 flavors. The generational code name and the silicon tier level. The silicon tier levels are defined by "EUs" or Execution Units. The VBIOS is tattoo'd with what SOC it is allowed to be flashed too. Each EU SOC Tier represents the maximum that the tier can have (Alchemist) meaning that a card with less EUs than maximum but more than the previous tier, is considered a card of the higher tier. Though there are rumors that these tiers are further defined by a wattage limit given to each.
It should be noted however, that these values were derived from an earlier branch. The current implementation still breaks the SOCs down into tiers but omits the 128,256,512 delimitator. So keep in mind this definition may change as the product stack matures and different SKUs are added.
igsc/lib/igsc_lib.c at master · intel/igsc
Intel graphics system controller firmware update library. - intel/igsc
Generational Code names:
DG1 (Pre ARC. OEM only strapped VBIOS)
DG2 (ARC)
Silicon Tiers:
SOC1 (512 EUs)
SOC2 (128 EUs)
SOC3 (256 EUs)
In our example we will be working with the main vbios. However when playing with the cards various firmware's Intel's official flash sequence (as taken from the intel driver fw flashing logs) is as follows:
- PCON
- Firmware
- OPROM
- FW data
- Config data
Lets run the check to see what kind of hardware we have on our A380.
Code:
igsc fw hwconfig
Looks like we have SOC2 which adds up. Lets check the firmware version on the device.
Code:
igsc fw version
ok so version 2.2307. Lets check the FW version of the SOC2 firmware included in yesterdays Intel ARC driver release (101.4577).
Code:
igsc fw version --image dg2_gfx_fwupdate_SOC2.bin
Looks newer at 2.2347.
Now that we have the version, lets list the parent commands each of which can be further looked into by calling "help" with the command directly.
Code:
Usage: igsc [-v] <command> <args>
igsc fw update [options] [--device <dev>] --image <image>
igsc fw version [--device <dev>] | --image <file>
igsc fw hwconfig [--check] [--device <dev> | --image <image>]
igsc iaf update [options] [--device <dev>] --image <image>
igsc iaf version [--device <dev>]
igsc oprom-data update [options] [--device <dev>] --image <image>
igsc oprom-data version [--device <dev>] | --image <file>
igsc oprom-data supported-devices --image <file>
igsc oprom-code update [options] [--device <dev>] --image <image>
igsc oprom-code version [--device <dev>] | --image <file>
igsc oprom-code supported-devices --image <file>
igsc fw-data update [options] [--device <dev>] --image <image>
igsc fw-data version [--device <dev>] | --image <file>
igsc fw-data supported-devices --image <file>
igsc list-devices [--info]
igsc image-type --image <image>
igsc ifr get-status [--device <dev>]
igsc ifr run-test [--device <dev>] --tile <tile> --test <test>
igsc ifr run-array-scan-test [--device <dev>]
igsc ifr run-mem-ppr-test [--device <dev>]
igsc ifr get-status-ext [--device <dev>]
igsc ifr count-tiles [--device <dev>]
igsc ifr get-repair-info [--device <dev>] --tile <tile>
igsc ifr version [--device <dev>]
igsc gfsp get-mem-err [--device <dev>]
igsc gfsp get-mem-ppr-status [--device <dev>]
igsc gfsp set-ecc-config [--device <dev>] --ecc-config <config>
igsc gfsp get-ecc-config [--device <dev>]
igsc gfsp get-health-ind [--device <dev>]
igsc oem version [--device <dev>]
igsc -V/--version: display version
igsc -v/--verbose: runs in verbose mode
igsc -q/--quiet: runs in quiet mode
igsc help : shows this help
igsc help <command>: shows detailed help
Flashing the BIOS
Lets say I really like how cyberpunk runs with these drivers but I want a newer bios because there are reports of an increased wattage ceiling. Lets look at what flags we can use with the command itself.
I will add (-a) for giggles but it looks like what we want is:
Code:
igsc fw update -a -f -i dg2_gfx_fwupdate_SOC2.bin
Lets give it a shot.
You can see it reads the image FW version (2.2347) and the current device FW version (2.2307) and lists the progress of the flash itself.
All done! It re-reads the device FW version after the flash and displays it. We are now at version 2.2347.
Downgrading the BIOS
What if this causes some kind of instability? Lets try to force a downgrade. We would use the same command in this case because (-a) allows for same version or lower writes to the eeprom.
Lets downgrade to a FW version from way back in driver 101.4091 feburary of 2023. These older driver releases are packed so we need to steal the firmware from the temp directory after the installer opens, by opening task manager and right clicking the process and clicking ""open file location".
Lets do what we did before. Lets read the FW version on the card. Then we will read the version of the old firmware.
We can see the device is running the new 2.2347 and the image from the drivers in feb are 2.2314 which is still newer than the original FW but its a downgrade from whats currently on the card.
Thats the firmware I want though so lets run the same command with "-a" to allow firmware downgrade.
Code:
igsc fw update -a -f -i oldfw\dg2_gfx_fwupdate_SOC2.bin
Again we see it read the device FW version. In this case the brand new 2.2347 but the FW image contains 2.2314 but with the flag it is writing the downgrade.
Done! The process completed and the final read from the device shows 2.2314!
Flashing the wrong BIOS
Now what if you mess up and attempt to write a BIOS from the wrong card? Well there are checks in place and even using the downgrade (-a) and force (-f) flags the tool will not do it.
Lets try to flash my A380 with the FW for a SOC1 (A770) card.
Code:
igsc fw update -a -f -i dg2_gfx_fwupdate_SOC1.bin
Thats a big no.
Code:
Error: The firmware image in dg2_gfx_fwupdate_SOC1.bin is incompatible with the device \\?\DISPLAY#INTC_HECI_2#7&1d10e1f9&0&UID60434#{5315db55-e7c7-4e67-b396-800a75dd6fe4}
It also doesnt work in reverse.
Finishing Up
This isn't a super straight forward guide. I thought it was prudent to include some back story. Flashing ARC is more common than people think given there odd approach to doing it during driver install. I dont think there are a ton of use cases given that I could not find any mention of dumping/saving the BIOS in there API documentation for this tool. Though it should be possible to do in linux I havent tried yet.
It should be noted this tool and Intels leap into the descrete GPU world is NEW. Looking at the commit history changes to this tool have been massive in terms of functionality; so the ability to save in the future may be possible. Changes to how flashing is even done may change with the release of battlemage. It's possible saving might never be possible on ARC without a HW tool which I have written about in my other ARC experience threads.
Most importantly, there are no guarantees that flashing will improve or make anything more stable. Much like flashing with any other brand, you do it at your own risk and there is no promise it will be better.
I will leave you with this. If it goes bad or communication becomes a problem with the card, this tool probably wont save you. Always be ready for the worst.
It should be noted, that a BIOS backup via eeprom reader cannot be read by the IGSC tool. If a flash is bad you will need to flash the backup with the eeprom reader!
![www.techpowerup.com](https://tpucdn.com/forums/data/assets/logo/logo-og-v1.png)
Guide: Flashing with a hardware programmer
Lets get physical So; you tried flashing your GPU and you didn't backup. Now you have some dude on the forum linking you a BIOS but you have no way to apply it because you don't have a spare GPU either. Well no worries friend. In this guide we are going to cover the simple procedures of...
![www.techpowerup.com](https://tpucdn.com/forums/data/assets/logo/icon-192-v1.png)
For a curated list of Intel ARC firmware please see:
![www.techpowerup.com](https://tpucdn.com/forums/data/assets/logo/logo-og-v1.png)
Intel ARC Firmware Compilation Matrix
Hi all. This is a section originally published in: https://www.techpowerup.com/forums/threads/guide-flashing-intel-arc-gpus.311964/ However given the work involved and the size of the table I decided to break it out. While the two topics do relate to each other closely (you should give the...
![www.techpowerup.com](https://tpucdn.com/forums/data/assets/logo/icon-192-v1.png)
Hope you found this useful!
Attachments
Last edited: