watchthelight labs

Offering Panther Lake (Xe3 / Arc B390) hardware for testing and development #11

open
lemlnn 2026-10-30

Hi, I've been following XeGfx for a little while now, and I was wondering if you'd be interested in having me help test and develop macOS support for my Framework Laptop 13 Pro (Intel Core Ultra X7 358H, Arc B390 Xe3 iGPU). I'm fairly new to driver development, so I might need some guidance with the more complicated parts, but I'm willing to put in the time to do so. I'm currently running EndeavourOS with the Linux xe driver, and I'd be happy to provide any logs, tests, or whatever and try to troubleshoot.

Let me know if my hardware would be useful to the project.

-lemlnn

watchthelight 2026-10-30

Hi lemlnn, yes, this would help, thank you.

One thing first so expectations are right: XeGfx today is built on i915, which stops at Meteor Lake and Arrow Lake. The Arc B390 is Xe3, and on Linux only Intel's newer xe driver handles it. Getting there is tracked in #8 and hasn't started yet, so your machine won't run XeGfx in the short term.

What helps now, from your EndeavourOS install:

  • lspci -nnk -s 00:02.0
  • sudo dmesg | grep -iE 'xe |guc|huc|gsc|dmc' (device ID, GMD_ID and the firmware versions the xe driver loads)
  • sudo cat /sys/kernel/debug/dri/0/info if debugfs is mounted

Also: does macOS boot on that Framework at all yet (OpenCore, any version)? If it does, the read-only probe in CONTRIBUTING.md (stage 2) is the next step, and that is safe to run.

Anything you send, whether it works, half works or fails, goes into the README's credits with your handle.

lemlnn 2026-10-30

Okay, here are the results:

lspci -nnk -s 00:02.0 returned
00:02.0 VGA compatible controller [0300]: Intel Corporation Panther Lake [Arc B390] [8086:b082] (rev 04)
Subsystem: Framework Computer Inc. Device [f111:000f]
Kernel driver in use: xe
Kernel modules: xe

sudo dmesg | grep -iE 'xe |guc|huc|gsc|dmc' returned
[ 3.153029] xe 0000:00:02.0: vgaarb: deactivate vga console
[ 3.153390] xe 0000:00:02.0: [drm] Running in SR-IOV PF mode
[ 3.153491] xe 0000:00:02.0: [drm] Found pantherlake (device ID b082) integrated display version 30.00 stepping B0
[ 3.165333] xe 0000:00:02.0: [drm] Finished loading DMC firmware i915/xe3lpd_dmc.bin (v2.36)
[ 3.211081] xe 0000:00:02.0: vgaarb: VGA decodes changed: olddecodes=io+mem,decodes=io:owns=io+mem
[ 3.222271] xe 0000:00:02.0: [drm] Tile0: GT0: Using GuC firmware from xe/ptl_guc_70.bin version 70.72.1
[ 3.484135] xe 0000:00:02.0: [drm] Tile0: GT0: ccs1 fused off
[ 3.484138] xe 0000:00:02.0: [drm] Tile0: GT0: ccs2 fused off
[ 3.484139] xe 0000:00:02.0: [drm] Tile0: GT0: ccs3 fused off
[ 3.505075] xe 0000:00:02.0: [drm] Tile0: GT1: Using GuC firmware from xe/ptl_guc_70.bin version 70.72.1
[ 3.509438] xe 0000:00:02.0: [drm] Tile0: GT1: Using HuC firmware from xe/ptl_huc.bin version 10.3.3
[ 3.512123] xe 0000:00:02.0: [drm] Tile0: GT1: Using GSC firmware from xe/ptl_gsc_1.bin version 105.0.2.1397
[ 3.512646] mei_gsc_proxy 0000:00:16.0-0f73db04-97ab-4125-b893-e904ad0d5464: bound 0000:00:02.0 (ops xe_gsc_proxy_component_ops [xe])
[ 3.533614] xe 0000:00:02.0: [drm] Tile0: GT1: vcs1 fused off
[ 3.533616] xe 0000:00:02.0: [drm] Tile0: GT1: vcs2 fused off
[ 3.533617] xe 0000:00:02.0: [drm] Tile0: GT1: vcs3 fused off
[ 3.533617] xe 0000:00:02.0: [drm] Tile0: GT1: vcs4 fused off
[ 3.533618] xe 0000:00:02.0: [drm] Tile0: GT1: vcs5 fused off
[ 3.533619] xe 0000:00:02.0: [drm] Tile0: GT1: vcs6 fused off
[ 3.533619] xe 0000:00:02.0: [drm] Tile0: GT1: vcs7 fused off
[ 3.533620] xe 0000:00:02.0: [drm] Tile0: GT1: vecs1 fused off
[ 3.533621] xe 0000:00:02.0: [drm] Tile0: GT1: vecs2 fused off
[ 3.533621] xe 0000:00:02.0: [drm] Tile0: GT1: vecs3 fused off
[ 3.586050] xe 0000:00:02.0: [drm] Registered 4 planes with drm panic
[ 3.586053] [drm] Initialized xe 1.1.0 for 0000:00:02.0 on minor 0
[ 3.588042] xe 0000:00:02.0: [drm] Allocated fbdev into stolen
[ 3.698316] xe 0000:00:02.0: [drm] Tile0: GT1: found GSC cv105.1.0
[ 4.642119] xe 0000:00:02.0: [drm] fb0: xedrmfb frame buffer device
[ 17.610531] xe 0000:00:02.0: [drm] Selective fetch area calculation failed in pipe A

sudo cat /sys/kernel/debug/dri/0/info returned
graphics_verx100 3000
media_verx100 3000
stepping G:B0 M:B0 B:**
is_dgfx no
platform 12
subplatform 0
devid 0xb082
revid 4
tile_count 1
vm_max_level 4
force_execlist no
has_flat_ccs yes
has_usm yes
skip_guc_pc no
multi_lrc_engine_classes vcs vecs
gt0 force wake 5
gt0 engines rcs0 bcs0 bcs8 ccs0
gt0 multi_queue_engine_classes none
gt1 force wake 4
gt1 engines vcs0 vecs0 gsccs0
gt1 multi_queue_engine_classes none

I'm pretty sure Framework ships with InsydeH2O UEFI firmware by default so I still gotta attempt Opencore in a bit, and also here's my system info if you need it

Image
lemlnn 2026-10-31

Okay, so I'm currently working on opencore, but it's going to be a bit difficult because of how little information is out there for a relatively new CPU generation, stuck on EXITBS, it might take me a bit.

watchthelight 2026-10-31

Thanks for the dmesg, that's everything I wanted from Linux.

On EXITBS: my Arrow Lake laptop froze at exactly EXITBS:START, with no kernel text, on my first ten boot attempts. None of the Booter quirks fixed it (ProvideCurrentCpuInfo, SetupVirtualMap off, ForceExitBootServices, DevirtualiseMmio off). The cause was the ACPI APIC table (MADT). The firmware lists every CPU only as an x2APIC entry (type 9), and XNU counts CPUs only from classic Local APIC entries (type 0). So it finds zero CPUs and dies before the console exists.

The fix was to dump the firmware's APIC table, rewrite it with x2apic_to_lapic.py, and in OpenCore delete the original (ACPI > Delete, TableSignature APIC) and add the converted one. The next wall after that was a "Non-monotonic time" panic, which CpuTscSync fixed.

To check whether you're hitting the same thing, run this from Linux: sudo cat /sys/firmware/acpi/tables/APIC | xxd | head -20. If the entries after the 44-byte header (from offset 0x2c) start with 09 (type 9) and there are no 00 entries, it's the same problem. The script needs every x2APIC ID below 0xFF, which should be true on a laptop.

Reply on GitHub