Repository navigation
drm/asahi: M5: InitData for the macOS 27.2 and 27.3 firmware (G17S bring-up on J716s) - #1173
Draft
rolotrealanis98 wants to merge 10 commits into
Draft
rolotrealanis98 wants to merge 10 commits into
rolotrealanis98 wants to merge 10 commits into
Conversation
This was referenced Nov 8, 2026
DjDeveloperr
force-pushed
the
funkzy/t6050-gpu-on-integration
branch
from
November 8, 2026 17:11
b1615e3 to
0dd0833
Compare
Merged
RyanTheTide
reviewed
Nov 10, 2026
RyanTheTide
left a comment
RyanTheTide
left a comment
Contributor
There was a problem hiding this comment.
- Rebase onto the current head of
funkzy/t6050-gpu-on-integration(0dd0833). That drops the 13 older base commits, which the branch now carries in rewritten form. Your 13 commits (27cd9cd..34f2f5b) replay onto it without conflicts. drivers/gpu/drm/asahi/g17/fw/m5/initdata.rshas comments that cite kernel-extension and firmware code: virtual addresses in the0xfffffe00...range,__TEXT,__constlocations and quoted instruction sequences. They sit atM5_26B123_STATUS_CONFIG_BANDS,M5_26B123_STATUS_CONFIG_INSERTED,M5_26B123_INITDATA_VERSION_WORD,ABI_ALLOCATION_SIZES_26B123_M5,M5_GPU_TIMEOUT_SECONDS,m5_forced_idle_timeout_ms,M5_26B123_POLICY_CONTROLLER_WORDSandM5_26B123_POLICY_CONTROLLER_WORDS_G17D. This tree can't carry them. Please remove every code-address and instruction reference. Derive each layout and value from what the running system shows (for example, InitData captured from the machine under macOS 27.2/27.3), and describe each field by its meaning and that observation.- The policy controller words are values read out of the kernel extension's code (for example, the 900/1600 pair and the 2500 entry), not observed InitData contents. Please replace them with values taken from captured InitData for the board, and name the fields.
…cannot build
From macOS 27.2 on, the M5 GPU firmware expects a different InitData
graph than the 26A428 (27.0) one the M5 path builds:
- the root version word gains bit 46 (0x0c8e_0339_8728_04c0 ->
0x0c8e_4339_8728_04c0), in 27.2 and 27.3 alike;
- the power policy grows from 0x126b0 to 0x12728 bytes and the status
config from 0x780 to 0x790, in 27.2 and 27.3 alike;
- 27.3 beta 1 alone inserts a HW data word at 0x2720.
These layouts are not yet confirmed from captured InitData of a
running macOS; the later commits of this series say which parts a
running firmware has accepted.
Name the layouts a build needs (Variant::m5_layouts) and give the 27.2
firmware its own variant, V26B123_M5: the 26A428 M5 protocol with the
26B123 layouts. Until the M5 graph builds them, Gpu::new() refuses such
a build right after identifying it, before anything is written to the
GPU, instead of handing it a graph it would reject ("Host and FW
Interface is mismatched") or misread.
Every M5 build in the tree today is 26A428 and names
M5Layouts::V26A428, so nothing changes for the M5 Max and M5 Ultra.
Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com>
Assisted-by: LLM Claude
…uilds The M5 Pro admits only the 27.0 (26A428) G17S build. Pin the 27.2 (26B123) and 27.3 beta 1 (26C5035r) G17S builds of both roles as well, measured the way fwid defines a build (the SHA-256 of the primary's then the secondary's TEXT with the entropy records, the two header load fields and the two boot-argument sections of each role zeroed): 27.3 beta 1 (26C5035r) b5537c8f06bd...66763600 27.2 (26B123) 2b4613c62a8a...913f0fd9 The images are the G17S (FW Build variant a010) primary and secondary GFX firmware of the public Mac17,8 IPSW for 27.2 and of the 27.3 beta 1 restore bundle (im4p SHA-256 ae7f35b1... and da8ff3fb...). The offsets come from each image's Mach-O load commands: text at 0x50000 + 0x54000, DATA 0x184000 as on the M5 Max, the _rtk_tunables and _rtk_patchbay sections per role. 27.2 needs an entry of its own although its interface matches 27.3's: its primary entropy record sits at 0x49ea4, 27.3's at 0x49eac. Each image header still carries its load fields at 0x224/0x23c (zero in the file, the patchbay's offset and size at 0x22c/0x230, as in 26A428). The 27.0 entry is the one the base already pins: this digest procedure gives the same digest for it, and reproduces the two pinned 26A428 digests of the M5 Max (G17C) and M5 Ultra (G17D). 27.0 runs the 26A428 graph. 27.2 and, for now, 27.3 name V26B123_M5, whose layouts the M5 graph does not build yet, so they are identified and then refused before any GPU write; 27.3 gets its own variant once its HW data is built. The fwid KUnit tests cover the new builds. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
The M5 GPU firmware of macOS 27.2 (26B123) is expected to find a different root version word than 27.0 (26A428): 0x0c8e_4339_8728_04c0 where 27.0 has 0x0c8e_0339_8728_04c0, only bit 46 differs. Its allocation size table differs from 26A428's (ABI_ALLOCATION_SIZES_26A428_M5) in two entries only: index 4, power policy: 0x126b0 -> 0x12728 index 13, status config: 0x780 -> 0x790 The packed layouts derived from it move accordingly: in the shared cluster everything after the policy moves by 0x80 (views 3 and 4, the BRN table and repeated region, the twelve DM rings, both main configs and control rings); in the private cluster everything after the status config moves by 0x40 (both role sets with status A, the secondary control state, secondary extra 1 and the policy state). Both clusters keep their page-rounded sizes (0x34000 and 0x178000), so the fixed windows of the M5 graph still hold them. The HW data of 26B123 is 26A428's. The version word, the sizes and the HW data layout of 26B123 are not yet confirmed from captured InitData. Describe one firmware build's InitData layout as an M5Layout (its size table, the packed clusters derived from it, and how its HW data moves relative to the 26A428 encoding), add M5_LAYOUT_26A428 and M5_LAYOUT_26B123, and a RootProfile J714G17S26B123 that writes the new version word and takes its offsets from the 26B123 layout. build_m5() now takes the firmware build's Variant and builds the profile its M5Layouts names. Gpu::new() keeps refusing every build but 26A428 until the 26B123 power policy and status config are laid out as well (later in this series), so no firmware is handed a partly converted graph. The 26A428 encodings are unchanged: the HW data of every board, the private cluster, the bundle policy, both roots and both main configs encode to the same bytes as before. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
The M5 firmware of macOS 27.3 beta 1 (26C5035r) takes the 26B123 version word and allocation sizes, but its HW data is not 26B123's: one u32 is inserted at 0x2720 and every later field moves by 4 (the kick-shared pointer from 0x27dc to 0x27e0, the last moved word from 0x2846 to 0x284a; everything below 0x2720 is as before). The version word does not tell the two builds apart; only the firmware identity does. The new word is the time the GPU may take to reach a forced idle after a sleep request, in ms; 0 disables the wait. The value written, 5000, is 5 s times 1000. The layout, the meaning of the word and the value are not yet confirmed from captured InitData. Describe the move with the layout bands the HW data already uses (M5_26C5035_HW_DATA_BANDS: 0..0x2720 stays, 0x2720..0x284c moves by 4; the four bytes it drops past 0x284c are zero in the 26A428 encoding), apply them after the 26A428 encoding and write the word, and find the kick-shared pointer and the enabled-core words through them. Add RootProfile J714G17S26C5035, M5Layouts::V26C5035 and its Variant V26C5035_M5, and have the 27.3 (26C5035r) G17S build of the M5 Pro name it instead of V26B123_M5. The fwid KUnit test that checks each M5 Pro build's layouts follows. The encoded 26C5035r HW data of every board equals the 26A428 encoding below 0x2720, has 5000 at 0x2720 and carries the 26A428 bytes 0x2720..0x284c at 0x2724. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
The 26B123 M5 firmware takes a 0x12728-byte power policy instead of
0x126b0 (allocation size table entry 4); 27.3 beta 1 (26C5035r) has
the same layout. Five inserts, as bands in 26A428 offsets, move the
words above them:
[0x0000, 0x4910) +0
[0x4910, 0x491c) +0x10 two u64 words; the three controller input
words at 0x4910 (3500/1000/3000 in the J714
defaults) move to 0x4920
[0x491c, 0x49b8) +0x14 a controller input word at 0x492c
[0x49b8, 0x4a98) +0x18 4 bytes between 0x494c and 0x49b8 that the
M5 encoders do not write
[0x4a98, 0x12668) +0x30 0x18 bytes between 0x4a00 and 0x4a98 that
they do not write either
[0x12668, 0x126b0) +0x78 the table at +0x122f0 grows from 37 to 40
24-byte entries
The state and AON PTD pointers move to 0x8284 and 0x11a4c. The 26B123
policy may use words of its own at 0x94e4..0x954c, in space the M5
encoders do not write in 26A428; they stay zero here.
The policy controller input words the 26B123 policy carries beyond the
26A428 ones are 0x492c = 5000 and 0x4a14 = 1600 (26A428 0x49fc, 500 in
the J714 defaults) for the core types 0x18/0x19, and for the G17D core
type 0x1a 0x4920 = 2500, 0x4928 = 800, 0x492c = 1100, 0x49e4 = 0 and
0x4a14 = 1600. These values and the bands above are not yet confirmed
from captured InitData; they are what a capture session has to check.
Add M5PolicyMap with the 26A428 identity map and the 26B123 map, chosen
from the build's M5Layouts (every layout but 26A428 takes the 26B123
map), and relayout_m5_policy(), which moves the bands of the policy the
26A428 encoders wrote in place, highest first, zeroes the inserts and,
where the board's controller defaults were applied, writes the 26B123
controller words for its core type. For 26A428 it changes nothing.
Not run on hardware: the controller words (they are written only where
the board's controller defaults apply, and no run of this layout has
had them) and the G17D (J775D) words on 26B123; no 27.2+ M5 Max or
M5 Ultra firmware is identified yet.
Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com>
Assisted-by: LLM Claude
The M5 graph's policy encoders (encode_m5_bundle_policy() and the boards' controller defaults) write the 26A428 layout. Keep the build's policy map in InitData, set through set_m5_policy_layouts() from the identified firmware's M5Layouts, and lay the policy out for it in build_m5() once the controller defaults have run: the 26B123 layout moves every word above 0x4910 and adds the 26B123 controller words where the board's defaults applied. The maximum-power word read for region C (0xa18) does not move. The relayout stays within the build's own policy allocation: a policy larger than the space before block_68 of the shared layout is refused. The diagnostic policy read is bounded by the build's policy size. The map defaults to 26A428, so the 26A428 graph is unchanged. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
The 26B123 M5 firmware takes a 0x790-byte status config instead of 0x780 (allocation size table entry 13); 27.3 beta 1 (26C5035r) has the same layout. Everything up to +0x5b4 keeps its offset. From +0x5b4 the object holds two controller blocks, at +0x5b4 and +0x610, of 0x5c bytes each. 26B123 inserts two words into each block, an override slot at block +0x28 and its value at block +0x58, so a block grows to 0x64 bytes, and everything after the second block moves by 0x10: the link word and pointer (0x774/0x778 -> 0x784/0x788) and the submission history (0x73c/0x74c/0x750 -> 0x74c/0x75c/0x760). As bands in 26A428 offsets: [0, 0x5dc) +0, [0x5dc, 0x608) +4, [0x608, 0x638) +8, [0x638, 0x664) +0xc, [0x664, 0x780) +0x10. The new words are 0x5dc and 0x640 (override slots, zero-filled) and 0x60c (5000) and 0x670 (0), the values. The layout and these values are not yet confirmed from captured InitData. Add M5StatusConfigMap with the 26A428 identity map and the 26B123 map, encode the primary status-B span through it, and read the submission history through the map the graph was built with. The 26A428 status config is unchanged: the map path writes the same 0x780 bytes as write_relocated_words() with COMMON26_STATUS_CONFIG_BANDS. The 26A428 words the driver writes from 0x5a4 are not changed here; the 26B123 map moves them like every other word. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
Give RootProfile the status-config map of its M5 graph and have build_m5() pick the profile before it encodes the private cluster, so the status-B span, the link word and pointer and the submission-history reader all follow the profile's layout. Every existing profile keeps the 26A428 map, so the graph is unchanged. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
…3 profiles The 26B123 (macOS 27.2) firmware takes the 0x790-byte status config: two words more in each controller block and the tail, link word and submission history 0x10 higher. Return M5_26B123_STATUS_CONFIG for the 26B123 root profile, and for the 26C5035 (macOS 27.3 beta 1) profile, whose status config is the same as 26B123's. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
…e firmware build build_m5() now selects the power-policy map from the same M5 layouts the root profile comes from, so a 26B123 or 26C5035 firmware gets its policy laid out to 0x12728 bytes and its 0x790-byte status config in the same graph. The policy and status-config sizes of 26B123 are entries 4 and 13 of its allocation size table, and a compile-time check holds every M5 build's policy and status-config maps to its own size table, with the policy at the offset the controller defaults write it. The controller defaults keep writing the 26A428 policy, which the relayout then moves; name that slice once. The private cluster encoder takes the root profile and derives both the cluster layout and the status-config map from it, which leaves the 26A428-only status-B wrapper without callers. With every 27.2+ layout in place, Gpu::new() now refuses only a build that names no M5 layouts, so the M5 Pro's 27.2 (26B123) and 27.3 beta 1 (26C5035r) builds run their graphs. 26A428 builds, the only ones the M5 Max and M5 Ultra identify, take the identity maps and build the same bytes as before this series. The 27.2+ layouts and values of this series are not yet confirmed from captured InitData; the comments say which. What has been observed is the following. An earlier revision of this series, with J716s board tables and a native-address mailbox compatible that are not part of this one, ran on a J716s (16-inch M5 Pro) with the 27.3 beta 1 boot firmware, a device tree that describes the GPU and a loader that hands it over (none of them part of this series): aurora 2300000000.gpu: GPU firmware: 27.3 (26C5035r), G17S aurora 2300000000.gpu: RTKit: Initializing (protocol version 12) aurora 2300000000.gpu: M5 primary initdata acknowledged aurora 2300000000.gpu: M5 secondary initdata acknowledged aurora 2300000000.gpu: M5 firmware opening records retired [drm] Initialized aurora 1.0.0 for 2300000000.gpu on minor 1 with no coprocessor crash, SError, DART or UAT fault for the minutes the system ran, and later through a 25-minute desktop session on the GPU with no GPU errors. That shows the firmware accepting a graph built from these layouts; it does not confirm any single value. Not exercised: the 27.2 firmware on hardware, the forced-idle sleep path, the policy controller words (that board wrote no controller defaults), the M5 Max and M5 Ultra on 27.2+. Signed-off-by: Rolando Trevino <rolotrealanis@gmail.com> Assisted-by: LLM Claude
rolotrealanis98
force-pushed
the
pr/m5-gpu-27.2
branch
from
November 10, 2026 12:01
34f2f5b to
d8ca53c
Compare
Contributor
Author
|
Updated (head d8ca53c, ten commits).
What the running system has shown so far is only that the firmware takes the graph as a whole: an earlier revision of this series, with the J716s tables, ran the 27.3 beta 1 firmware on the J716s (both InitData acknowledged, opening records retired, a 25-minute desktop session without a GPU error). This revision has not run on hardware, and the 27.2 firmware has not run at all. Build: all ten commits, |
RyanTheTide
changed the base branch from
funkzy/t6050-gpu-on-integration
to
integration/aurora
November 10, 2026 12:23
DjDeveloperr
left a comment
DjDeveloperr
left a comment
Contributor
There was a problem hiding this comment.
Codex (GPT-6.1 Sol), reviewing on @DjDeveloperr’s behalf.
The current description and maintainer discussion still leave firmware provenance open: the 27.2/27.3 InitData has not been captured, multiple policy/controller constants remain explicitly inferred or 'not yet confirmed', and the author says merge should wait for those captures. A working J716s session does not establish that the full admitted firmware/table variants match observed data. Please keep this unmerged until the observed capture/provenance gate is met (or narrow to a separately proven profile), with exact current-source build/boot validation. I will not treat a website Working/Partial label as a substitute for this evidence.
This was referenced Nov 11, 2026
rolotrealanis98
marked this pull request as draft
November 12, 2026 01:50
Contributor
Author
|
Converted to draft. I still have no InitData captured from macOS 27.2 or 27.3, so the provenance point stands as it was. The branch also conflicts with the per-build layout ( |
sithglan
pushed a commit
to sithglan/aurora-linux
that referenced
this pull request
Nov 12, 2026
…14/K116 Applies on top of aurora-silicon/linux PR aurora-silicon#1173. The 16-inch M5 Pro OLED (K116s, Mac17,12) restores from UniversalMac_27.2_26B8125_Restore.ipsw, not from the 26B123 image of the Mac17,8 that aurora-silicon#1173 pins. Its Firmware/agx/armfw_g17x.im4p and armfw1_g17x.im4p carry a010 (G17S) images whose LC_UUIDs are the uuid of the K116s ADT's iop-gfx-nub and iop-gfx1-nub (8A2891FC-D479-37E8-895D- 71B4D88ECB51, 58FF964E-F74B-31C2-8179-3837D6ADA9C2), so this is what iBoot loads. TEXT 0x50000 + 0x54000, DATA 0x184000, the GKTS/ECAP records and the _rtk_tunables/_rtk_patchbay sections at 26B123's offsets, but the fwid digest differs: 26B8125 G17S af68d034a3f006b43dab661b825f12598cb86e4d2a0e3844f14fa5059f38f6cb 26B123 G17S 2b4613c62a8a007f22a94101702c9ac6c4e90f2e123f3b36fbe6ffea913f0fd9 (check_fwid.py's algorithm.) Without this entry the driver refuses the K116s firmware before any GPU write. It names V26B123_M5: the AGX kext of the 26B8125 kernelcache builds root version word 0x0c8e_4339_8728_04c0 and its u64[24] allocation size table is ABI_ALLOCATION_SIZES_26B123_M5 entry for entry (HW data 0x2850, policy 0x12728, status config 0x790), and both firmware roles build the same version word. The interior offsets of the policy and the status config were not compared against 26B123's and no 27.2 firmware has run this graph on hardware. Signed-off-by: Jens Axboe <axboe@kernel.dk>
sithglan
pushed a commit
to sithglan/aurora-linux
that referenced
this pull request
Nov 12, 2026
…14/K116 Applies on top of aurora-silicon/linux PR aurora-silicon#1173 (patches-1173/0001..0010). The 16-inch M5 Pro OLED (K116s, Mac17,12) restores from UniversalMac_27.2_26B8125_Restore.ipsw, not from the 26B123 image of the Mac17,8 that aurora-silicon#1173 pins. Its Firmware/agx/armfw_g17x.im4p and armfw1_g17x.im4p carry a010 (G17S) images whose LC_UUIDs are the uuid of the K116s ADT's iop-gfx-nub and iop-gfx1-nub (8A2891FC-D479-37E8-895D- 71B4D88ECB51, 58FF964E-F74B-31C2-8179-3837D6ADA9C2), so this is what iBoot loads. TEXT 0x50000 + 0x54000, DATA 0x184000, the GKTS/ECAP records and the _rtk_tunables/_rtk_patchbay sections at 26B123's offsets, but the fwid digest differs: 26B8125 G17S af68d034a3f006b43dab661b825f12598cb86e4d2a0e3844f14fa5059f38f6cb 26B123 G17S 2b4613c62a8a007f22a94101702c9ac6c4e90f2e123f3b36fbe6ffea913f0fd9 (~/new-mac/gpu/tools/fwid.py, check_fwid.py's algorithm.) Without this entry the driver refuses the K116s firmware before any GPU write. It names V26B123_M5: the AGX kext of the 26B8125 kernelcache builds root version word 0x0c8e_4339_8728_04c0 and its u64[24] allocation size table is ABI_ALLOCATION_SIZES_26B123_M5 entry for entry (HW data 0x2850, policy 0x12728, status config 0x790), and both firmware roles build the same version word (~/new-mac/gpu/tools/verword.py, verword2.py). The interior offsets of the policy and the status config were not compared against 26B123's and no 27.2 firmware has run this graph on hardware. Signed-off-by: Jens Axboe <axboe@kernel.dk>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this is
Stacked on #1012 (base:
funkzy/t6050-gpu-on-integrationat b1615e3), so the diff shows only these 13 commits. It lets the M5 GPU driver build the InitData graph that the macOS 27.2 (26B123) and 27.3 beta 1 (26C5035r) GPU firmware checks, and runs the M5 Pro (G17S) on bare metal with J716s tables. On a J716s with 27.3 beta 1 firmware, both InitData are acknowledged and the DRM device registers.The problem
M5NoBareMetalTables) and admitted no firmware image (Firmware::Identified(&[])).Method
Every offset and constant comes from Apple's binaries, and each commit names the instruction or table address it was read from:
armfw_g17x.im4p,armfw1_g17x.im4p, variant a010): its accesses to the same objects, compared function by function;Scripts check each claim against those inputs and against the driver source, compiled with rustc outside the kernel (see Checks). They print only offsets, constants and digests.
Layout changes
27.2 and 27.3 share the version word, so only the firmware identity (fwid) tells them apart. That is why there are two variants,
V26B123_M5andV26C5035_M5. The runtime structures (submission, rings, events, buffer manager) did not change from 27.0 to 27.2 or 27.3. 27.2 adds a command type (0x14, UMA sync node, never emitted by the driver) and recovery reason 5, and 27.3 adds reason 6. Neither is used here.Commits
Variant::m5_layouts,V26B123_M5).M5NoBareMetalTablesgoes.apple,t6050-native-ascwrap-v6: the GPU mailboxes at the native wrapper/VBAR addresses m1n1 leaves in place.M5Layout, version word, shared and private cluster offsets.27.0 is unchanged
For 26A428 builds (the only ones the M5 Max and M5 Ultra identify), every map is the identity, and the graph is byte-identical to #1012's:
check_layout.pycompilesg17/fw/m5/initdata.rsbefore and after with rustc. It compares the HW data of every board (J714, J716C, J716S, J775D), the private cluster, the bundle policy, both roots and both main configs.verify_policy.pychecks the 26A428 policy byte for byte after the relayout, for J714, J716C and J775D.rustcheck.pychecks that the 26A428 status config (0x780 bytes) is the same aswrite_relocated_words()withCOMMON26_STATUS_CONFIG_BANDS.Hardware result (J716s, 27.3 beta 1 firmware)
Kernel: our J716s tree (integration/aurora plus the T6050 board PRs) with #1012 merged and this series on top. The GPU code that ran is these 13 commits. The only later change is the fwid KUnit test that commit 7 now updates. The device tree describes the GPU, and m1n1 hands the GPU over (both out of tree). One boot, unattended:
/dev/dri/renderD128present, power domains gfx/afr/gpx on, no deferred devices.What is inferred, not measured
os_version[27,3,0].secondary_root_offset0x40000, crash buffers infw-data, and the Ultra's UAT quirks. The G17S GXF code is the G17C image's except for one call's displacement. The GXF section grew from 0x4f40 to 0x50a0 bytes in 27.2, so the UAT quirks are unverified on 27.2+ for every board. The hardware run above exercised initialization only.controller_defaults/calibration: None. No controller configuration has been measured on a J716s part, so the firmware keeps its own power budget. The 27.2 controller words (0x492c, 0x4a14) are not written on J716s. That matches what drm/asahi, drm/apple: M5 GPU and firmware-27 display on integration/aurora #1012 does for 27.0.waitForGPUTimeoutSecondsdefault (5) times 1000. This comes from the kext's defaults, not read from a running macOS. The 27.3 kext also reads a newgpu-fa-idle-toleranceproperty, which is not modelled.Not covered
6648ece7e8c6b7b82844368f0e075a2180a08ca35feed0b6e3f548710d4ddb8154c528199710711b27119bd06db016ecee4232ff1a0b6ed8025a6146646e3b03543f7cf9bda372d9bc24b34013b05854409eced9f8019334f509ce6472c9e912f33b3f64960973d73942abf5794ec9d765313f1cef63bd38537b06d2f8c61f36DRM_ASAHI=y). It gave no warnings beyond the existing ones.g17/fw/m5/initdata.rsonly.dtbs_checknot run (no dt-schema here).Checks
The scripts and their outputs are in rolotrealanis98/m5pro-linux
contrib/validated/aurora/prs/gpu-27.2/checks/. The README there lists the inputs. All pass on this branch's head:check_layout.py <tree> <5th commit>rustcheck.py <initdata.rs> <dir>verify_policy.py <initdata.rs> <dir>verify_statuscfg.py --kext0/--kext2/--fw0/--fw2 ...check_fwid.py <hw/t6050.rs>check_board.py,check_mailbox.pyg17-firmware-selection-tests.py, andg17-telemetry-integration-tests.pywith all 10 mutations killed. The asahi-m4 suite gives the same results as on drm/asahi, drm/apple: M5 GPU and firmware-27 display on integration/aurora #1012's head; this macOS host can't build 6 of its tests.checkpatch.pl --strict: 0 errors, 0 warnings, 0 checks on all 13 patches..rustfmt.toml): 13 added lines are not rustfmt-clean, all ing17/fw/m5/initdata.rs(5) andg17/initdata/m5.rs(8). They follow the style around them. Neither file was rustfmt-clean before, and the series lowers rustfmt's change count in both (329 -> 317 and 73 -> 71).Questions
funkzy/t6050-gpu-on-integrationright? Or would you rather fold this into drm/asahi, drm/apple: M5 GPU and firmware-27 display on integration/aurora #1012, or retarget it to integration/aurora once drm/asahi, drm/apple: M5 GPU and firmware-27 display on integration/aurora #1012 merges?V26B123_M5/V26C5035_M5? Or should they wait until someone boots them?COMMON26_STATUS_CONFIG_BANDSwrites from 0x5a4 sit 0x4c below where the 27.0 M5 kext stores them (0x5f0..0x604). Those bands look measured on G18G's 0x6d0-byte object.apple,t6050-native-ascwrap-v6) the right way to describe the native layout? Or should the existing T6050 provider accept either layout?check_layout.pyandrustcheck.pyneed only the tree and rustc. Would you like them astools/asahihost tests inrun-host-tests.py, with controls? The others need Apple's kernelcache, firmware and an ADT, so they would stay out of tree.