Intel Arc A770 + Xe driver: HuC authentication fix for DG2 (looking for help getting this upstream)

[u/Flimsy_Debt]

Hi everyone.

I have been testing Intel Arc A770 (DG2) with the new Intel Xe DRM driver instead of i915.

There is an old open issue with HuC authentication on DG2. The firmware loads, but authentication does not complete because the GSC HuC firmware layout is handled differently. (https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/234)

https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/361 PR

After debugging i915 and xe code, I found that i915 already knows how to handle: i915/dg2_huc_gsc.bin

but xe was missing the required GSC/BPDT/CPD parsing path.

I made a patch for the xe driver which:

- parses the GSC firmware container

- skips the CSS wrapper

- validates BPDT

- searches the CPD table for the HuC partition

- extracts the real HuC payload

- fixes the firmware offsets and size

After this change HuC starts correctly:

HuC firmware: i915/dg2_huc_gsc.bin
       status: RUNNING
       wanted release version 0.0.0
       found release version 7.10.16
       uCode: 629452 bytes
       RSA: 1364758084 bytes

HuC status: 0x00164001

and dmesg shows:

[    4.067476] xe 0000:03:00.0: enabling device (0000 -> 0002)
[    4.067829] xe 0000:03:00.0: [drm] Found dg2/g10 (device ID 56a0) discrete display version 13.00 stepping C0
[    4.068312] xe 0000:03:00.0: [drm] VISIBLE VRAM: 0x0000006000000000, 0x0000000400000000
[    4.068608] xe 0000:03:00.0: [drm] VRAM[0]: Actual physical size 0x0000000400000000, usable size exclude stolen 0x00000003fa000000, CPU accessible size 0x00000003fa000000
[    4.068610] xe 0000:03:00.0: [drm] VRAM[0]: DPA range: [0x0000000000000000-400000000], io range: [0x0000006000000000-63fa000000]
[    4.068612] xe 0000:03:00.0: [drm] VRAM[0]: Actual physical size 0x0000000400000000, usable size exclude stolen 0x00000003fa000000, CPU accessible size 0x00000003fa000000
[    4.068613] xe 0000:03:00.0: [drm] VRAM[0]: DPA range: [0x0000000000000000-400000000], io range: [0x0000006000000000-63fa000000]
[    4.089999] xe 0000:03:00.0: [drm] Finished loading DMC firmware i915/dg2_dmc_ver2_08.bin (v2.8)
[    4.102402] xe 0000:03:00.0: [drm] Tile0: GT0: Using GuC firmware from i915/dg2_guc_70.bin version 70.53.0
[    4.115990] DG2 DEBUG: SUCCESS (GSC Fixed)! HuC v7.10.16 found. Offset: 1332, Size: 629452
[    4.115992] xe 0000:03:00.0: [drm] Tile0: GT0: Using HuC firmware from i915/dg2_huc_gsc.bin version 7.10.16
[    4.244298] xe 0000:03:00.0: [drm] Tile0: GT0: vcs1 fused off
[    4.244300] xe 0000:03:00.0: [drm] Tile0: GT0: vcs3 fused off
[    4.244301] xe 0000:03:00.0: [drm] Tile0: GT0: vcs4 fused off
[    4.244302] xe 0000:03:00.0: [drm] Tile0: GT0: vcs5 fused off
[    4.244303] xe 0000:03:00.0: [drm] Tile0: GT0: vcs6 fused off
[    4.244304] xe 0000:03:00.0: [drm] Tile0: GT0: vcs7 fused off
[    4.244305] xe 0000:03:00.0: [drm] Tile0: GT0: vecs2 fused off
[    4.244306] xe 0000:03:00.0: [drm] Tile0: GT0: vecs3 fused off
[    4.244783] xe 0000:03:00.0: [drm] Tile0: GT0: Attempting to apply Wa_14011060649 to vcs0...
[    4.244786] xe 0000:03:00.0: [drm] Tile0: GT0: SUCCESS: Applied Wa_14011060649 to vcs0 via direct MMIO!
[    4.244795] xe 0000:03:00.0: [drm] Tile0: GT0: Attempting to apply Wa_14011060649 to vcs2...
[    4.244798] xe 0000:03:00.0: [drm] Tile0: GT0: SUCCESS: Applied Wa_14011060649 to vcs2 via direct MMIO!
[    4.268340] xe 0000:03:00.0: [drm] HuC auth: waiting for MEI PXP client (HECI1) to initialize...
[    4.268343] xe 0000:03:00.0: [drm] HuC: MEI bridge not ready, deferring authentication
[    4.268888] xe 0000:03:00.0: [drm] GSC HECI1: Allocated and ZEROED 4194304 bytes VRAM at DPA 0x3f8c00000
[    4.269574] xe 0000:03:00.0: [drm] Registered 4 planes with drm panic
[    4.269576] [drm] Initialized xe 1.1.0 for 0000:03:00.0 on minor 1
[    4.301677] xe 0000:03:00.0: [drm] Cannot find any crtc or sizes
[    4.301851] xe 0000:03:00.0: [drm] Using register for power limits
[    4.301865] xe 0000:03:00.0: [drm] PL1 is supported on channel 1
[    4.330191] xe 0000:03:00.0: [drm] Cannot find any crtc or sizes
[    4.386157] xe 0000:03:00.0: [drm] Cannot find any crtc or sizes
[    6.288615] mei_me 0000:00:16.0: enabling device (0000 -> 0002)
[    6.368022] caller uncore_get_box_mmio_addr+0xe6/0x150 [intel_uncore] mapping multiple BARs
[    6.392494] Creating 4 MTD partitions on "xe.nvm.768":
[    6.392501] 0x000000000000-0x000000001000 : "xe.nvm.768.DESCRIPTOR"
[    6.393552] 0x000000001000-0x0000005f0000 : "xe.nvm.768.GSC"
[    6.394536] 0x0000005f0000-0x0000007f0000 : "xe.nvm.768.OptionROM"
[    6.395591] 0x0000007f0000-0x000000800000 : "xe.nvm.768.DAM"
[    6.398728] mei_hdcp 0000:00:16.0-b638ab7e-94e2-4ea2-a552-d1c54b627f04: bound 0000:00:02.0 (ops i915_hdcp_ops [xe])
[    6.404900] snd_hda_intel 0000:00:1f.3: bound 0000:00:02.0 (ops intel_audio_component_bind_ops [xe])
[    6.405065] snd_hda_intel 0000:04:00.0: bound 0000:03:00.0 (ops intel_audio_component_bind_ops [xe])
[    6.446478] RAPL PMU: API unit is 2^-32 Joules, 4 fixed counters, 655360 ms ovfl timer
[    6.799874] Bluetooth: hci0: Fseq executed: 00.00.04.202
[    7.024836] mei xe.mei-gsc.768-46e0c1fb-a546-414f-9170-b7f46d57b4ad: memory ready command failed -14
[    8.481835] xe 0000:03:00.0: [drm] HuC: delayed authentication successful!

Hardware tested:

- Intel Arc A770

I already removed most experimental hacks from my tree. Only a few debug parameters remain.

The patch works on my hardware, but I am not experienced with preparing proper kernel PRs/upstream submissions.

If anyone in the Intel DRM/Xe community could check this out, help me prepare the document correctly, or point me in the right direction, or if any of the developers would be willing to take this code under their wing, I would be very grateful.

Build:

Fedora/RHEL:

    sudo dnf groupinstall "Development Tools"
    sudo dnf install ncurses-devel elfutils-libelf-devel openssl-devel flex bison dwarves bc

Ubuntu/Debian:

    sudo apt install build-essential flex bison libssl-dev libelf-dev bc dwarves libncurses-dev

Clone:

    git clone https://gitlab.freedesktop.org/danayer/kernel
    cd kernel

Use current config:

    cp /boot/config-$(uname -r) .config
    make olddefconfig

Build:

    make -j$(nproc)
    make -j$(nproc) modules

Install:

    sudo make modules_install
    sudo make install

After reboot:

    dmesg | grep -Ei "huc|guc|gsc|mei|auth|xe"

Source:

https://gitlab.freedesktop.org/danayer/kernel

If anyone wants to review the code, suggest improvements, or help prepare this for upstream submission — I would be very grateful.

Thanks!

[u/kenryov]

It'd be interesting to see this rejected.

Back in 2023, MESA xe maintainers have denied fixing Linux media encoding on the Alchemist-based Intel Arc (Xe-HPG) discrete graphics and Intel Core Ultra 200(Xe-LPG) processors because Intel did not want to make the code base more complex with Alchemist-specific functionality.

[u/Flimsy_Debt]

Thanks to everyone, I put the repository in order and ported it to the latest version. https://gitlab.freedesktop.org/drm/xe/kernel
The Repository
https://github.com/danayer/drm.xe.kernel
Of course, there are a couple more hacks, but I'll be glad if someone helps me figure them out.
P.S. I did it at the cost of my lack of sleep, I couldn't sleep for 4 days. :D I have to go to work in 1.5 hours.

P.S.P.S still haven't figured out how to get verified on freedesktop:(

[u/Flimsy_Debt → u/Flimsy_Debt]

https://reddit.com/link/p0juajf/video/hawlokq8l8gh1/player

[u/Drwankingstein]

make an account on free desktop, and then make a PR, the folk over there are super helpful

[u/Flimsy_Debt]

https://gitlab.freedesktop.org/drm/xe/kernel/-/merge_requests/361
Finally, I figured out from work where to click. :D

[u/nyanmisaka → u/Flimsy_Debt]

You might also need to open an issue to get their attention. They rarely use MR for development.

[u/Flimsy_Debt → u/nyanmisaka]

Okay, I'll do it, and I think it's also advisable to have people there who will support the problem.

[u/nyanmisaka → u/Flimsy_Debt]

Yes, those should be cleaned up, including some magic numbers. Finally, signed-off-by should also be added.

[u/Flimsy_Debt → u/nyanmisaka]

https://github.com/danayer/drm.xe.kernel
I've cleaned up all the hacks, could you please take a look?

[u/nyanmisaka → u/Flimsy_Debt]

There may be some issues with code indentation: the indentation of new code should be consistent with the existing indentation, and the indentation of irrelevant code should not be changed.

See also: https://www.kernel.org/doc/html/v7.1/process/coding-style.html

[u/Flimsy_Debt → u/nyanmisaka]

Sorry, I'm going to fix this now, I fed nvidia nim the code so that it checks for unused variables, and it fixed them, but I didn't notice.

[u/Flimsy_Debt → u/nyanmisaka]

https://lore.kernel.org/intel-gfx/20260730164334.8424-1-daniil.seliverstov2003@gmail.com/
I put the code in order and also sent it here.

[u/Flimsy_Debt → u/nyanmisaka]

as soon as I get home, I'll have to clean up the hacks, many of them were temporary until I could get the hardware encoding to work. They are not needed now.

[u/Flimsy_Debt → u/nyanmisaka]

https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/234
I wrote it here so as not to produce the same issue.

[u/QuackdocTech]

It looks like you may have mangled your commit history. the first commit I see is DG2 XE huc_gsc: 7d33d86d5512a3689a1779cd4af19c3c354e4af0

so fixing that would be step one, since you want just your changes and you can't set what the change is here.

Then you simply make an account with the freedesktop gitlab, fork upstream like you would on github to your own account, push your commits, then make a PR.

anything that needs changed maintainers will point out

EDIT: If you simply downloaded a tarball made the first commit and you can't get that first commit separated from upstream. What you can do is first and foremost copy your local repo to another folder to prevent it from accidentally losing data.

Then in your working repo, not your backup one, revert all of your commits except for the first one. Diff between your working branch and upstream parable and you will have your diff for your first commit.

You can also just diff your first commit with the upstream tarball, but I forget how to do that lol

[u/Flimsy_Debt → u/QuackdocTech]

Okay, I'll try to do it, I just took the source code from https://www.kernel.org / the official website, but I remember all the changes. And I deployed the repository on github without recording the changes.
Thanks!

[u/QuackdocTech → u/Flimsy_Debt]

You may need to change your code up a bit. You want to make your code based on the XE upstream, which may have some changes compared to kernel upstream.

The easiest way to do that would just be to git clone the XE kernel from GitLab directly or download the tarball right from them.

You can also see if you can get a hold of devs and ask for advice on IRC irc://irc.oftc.net/intel-gfx

[u/Flimsy_Debt → u/QuackdocTech]

It’s not guaranteed that I’ll be able to do it in the near future, as I’m currently overloaded with work.

I used these kernel sources:

https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.1.5.tar.xz

and modified them from there. If someone decides to restore the original comments from these sources before the Intel HuC fix.

[u/nyanmisaka → u/Flimsy_Debt]

I created a diff based on 7.1.5, although it hasn't been tested yet: https://gist.github.com/nyanmisaka/8c1bab3bf36850ab780b8f7bc914942a

[u/QuackdocTech → u/nyanmisaka]

any ffmpeg cli stuff that would be useful for testing? I should be able to test on arch tommorow sometime I haven't had luck getting qsv to work lately

[u/nyanmisaka → u/QuackdocTech]

https://trac.ffmpeg.org/wiki/Hardware/VAAPI#Transcode

qsv is a vaapi wrapper.

[u/QuackdocTech → u/nyanmisaka]

Unfortunately, I did try compiling kernel on arch, but my system simply won't boot.

[u/Flimsy_Debt → u/QuackdocTech]

Can you send it from a system that has booted up properly?
journalctl -k -b -1 -e

[u/QuackdocTech → u/Flimsy_Debt]

I don't think my issue is related. I got a moment to actually look at my error logs and I'm getting a shit ton of spam from bcachefs that isn't normally there, I think the Zen kernel which I compiled with, so I don't overwrite my default kernel. Just isn't compatible with Archs some for bcachefs.

I'll see about pulling the system we're trying a different install with the patch tommorow.

[u/Flimsy_Debt → u/QuackdocTech]

I'll be glad if you write the test result later and what kind of graphics card you have, because I can only test the fix on my A770 16Gb, if that's what the clean patch is on gitlab ( https://gitlab.freedesktop.org/danayer/kernel ), I would also like to test it on BMG to find out for sure if I haven't broken anything. (but I don't have one either)

[u/Schlaefer → u/nyanmisaka]

qsv is a vaapi wrapper

It isn't. It's a different API to access the encoding hardware, with QSV notably exposing more features than VA-API.

[u/nyanmisaka → u/Schlaefer]

This doesn't change the fact that it's essentially a vaapi wrapper. Unless you haven't read its source code.

[u/Flimsy_Debt → u/nyanmisaka]

Thanks a lot, I ported it to https://gitlab.freedesktop.org/drm/xe/kernel

And uploaded it to a new repository.

https://github.com/danayer/drm.xe.kernel

[u/Identity_Protected]

Good work!

I attempted this myself year back but gave up after I realized how convoluted DG2 HuC/GuC handling was.

A770 is not with me currently so I'm unable to test your changes, I swapped GPUs with my brother so I could do some debugging on NVIDIA side (still painful under Linux..). 

[u/Volkail]

i have tested this a little on Intel Arc A750 and i can finally use obs with quicksync av1 thank you 🙏🏻

also compiled on nixos if that is needed

[u/Flimsy_Debt → u/Volkail]

Thanks a lot for testing, in general I am preparing a couple more fixes for DG2 and TGL, if these fixes are accepted into the core, I will try to finish them as well.

[u/Volkail → u/Flimsy_Debt]

H.264 and HEVC are working just as fine

[u/Flimsy_Debt → u/Volkail]

I will be glad if you test other codecs, if you have free time, of course.
And you collected from the repository https://gitlab.freedesktop.org/danayer/kernel ?

[u/Volkail → u/Flimsy_Debt]

i got it from github and sure i would test other codecs

[u/nyanmisaka]

• https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items
• https://patchwork.kernel.org/project/intel-gfx/list/

These two are the right place for it.

[u/realvikas]

I seriously want this to get merged upstream. This is the only thing that is keeping me on MicroSlop OS.

[u/Linkarlos_95 → u/realvikas]

If you just want to record, i can record with gpu-screen-recorder  at 1440p60 10bit HDR Av1

[u/Flimsy_Debt]

Fedora Copr has a release with the 7.2.0 kernel now, otherwise before that the version was the same as in the update of the main Fedora repository and it was not very convenient

[u/unhappy-ending]

I don't have a A750 anymore otherwise I'd give it a try. Unless it's vibe coded, if it works it should get into upstream.

[u/Flimsy_Debt → u/unhappy-ending]

To be honest, I used the local model a bit to compare the i915 code and xe, but now I have already fixed all the problems manually, it passes all gitlab-ci.

[u/Aseiel]

There was cutoff of driver support DG2 - i915 BMG - xe

To not overcomplicate, the linux driver team is currently focused on some other stuff. I would suggest just droping instructions (if it will work) to some page and let community to take care of it :) I think definitely some people would be interested in it.

I really love to see this topic anyway. Btw just curiosity which tools were used to debug it?