Guide: Flashing Intel ARC GPUs

Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Solaris17

Administrator
Staff member
Joined
May 13, 2023
Messages
13
1690948945996.png

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.


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:


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.
  • 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 lets take a look at the firmware matrix I have assembled. You can access it here:


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.

Flashing.gif


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.

Log-save.gif



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.

Scanning.gif



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.

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.


Generational Code names:

DG1 (Pre ARC. OEM only strapped VBIOS)
DG2 (ARC)

Silicon Tiers:

SOC1 (512 EUs)
SOC2 (128 EUs)
SOC3 (256 EUs)

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.

Check versions (1).png


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.

flash command functions (2).png


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.

flashing (3).png


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.

flashing done (4).png


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.

flash downgrade (5).png


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.

flash downgrade in progress (6).png


Done! The process completed and the final read from the device shows 2.2314!


flash downgrade done (7).png


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

flash soc 1 attempt (8).png


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!


For a curated list of Intel ARC firmware please see:


Hope you found this useful!
 

Attachments

Last edited:
Back
Top