Repository navigation
drm/asahi: g17: T6040 (M4 Pro) GPU, #408 with review follow-ups (GPU disabled on J616s) - #420
Merged
Merged
Conversation
A single-instance G17 firmware (the M4 Pro runs both roles on one coprocessor) has no secondary kernel root. Make secondary_root_offset an Option<u64>: the pagetables region then only needs the primary root, mirror_secondary_root() does nothing, and the TTBAT context-1 kernel alias is installed for every PublishedRoots firmware, since activate_render_context needs it. T8140 keeps Some(0x40000) and behaves as before. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The M4 Pro firmware runs both G17 roles on one coprocessor. Prepare the runtime for such a target; T8140 keeps two instances and behaves as before. - Firmware.secondary is an Option<Coprocessor>, created only when the configuration names a secondary root; boot, init, POWER_ON_DONE, the opening-retire wait, stop and drop skip it when absent. - event::Transport::roles(): event, trace and statistics service and the idle recheck cover only the instances that exist. - Config::recovery_slot_keys (T8140: SLOT_KEYS) replaces the hard-coded physical address; None leaves recovery to the firmware's own blame. - Config::gpu_generation is reported to userspace (T8140: G17). - The pm_metrics client VA comes from the target's configuration instead of hw::t8140::CONFIG in user_aliases and render preparation. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
G17 firmware builds that share the interface version still differ in a few queue rules. Name them in a fw::Variant that each SoC's Config points at, instead of hard-coding the A18 Pro firmware's (26A428) choices: - qid_floor: the first QID the host may use; queue admission and the UAPI queue limit follow the render pairs it leaves; - pointers: where the item-ring producer and the recovery target live in a queue's pointer block; - mmio_pair_registration: whether render pairs are registered through the MMIO queue ports; - mcache: whether render kick entries may name an MCache table; - few_primitives and ray_traversal: whether those render and compute features are offered and accepted. The variant reaches the queue-ID table, the compute and render graphs, command validation and the feature report through the structures that already carry per-device state. T8140 uses V26A428, which keeps every value it had, so its behaviour does not change. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The initialization builder names hw::t8140 for the register windows, the reserved register-map slots, the performance-table configuration and the operating-point count. Move these references into Config so a second G17 SoC can supply its own tables, and make the crash log placement an enum (CrashBuffers::Fixed) that a SoC whose firmware places its own crash log can extend. T8140 passes its existing tables; nothing changes for it. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The performance tables of the hardware data have sixteen voltage lanes per state. The A18 Pro lists one voltage per operating point, which the host broadcasts to every lane of table A and stores in lane 0 of table B. GPUs with several clusters have one voltage per cluster, listed as one opp-microvolt cell per cluster (as the T6031 device tree already does). Read every cell, and store cluster n's voltage in lane n of both tables, leaving the other lanes zero. A single cell keeps the current broadcast, so the T8140 tables are unchanged. All operating points must have the same number of cells. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
A register-map slot of the hardware data can describe several instances of a block: the firmware finds instance n at va + n * size, and the entry's total size covers all of them while its element size is that of one instance. On SoCs with several memory controllers or AFR blocks the instances are not contiguous in physical memory. Give RegisterWindow an instance count and a physical stride, map each instance separately, and fill total_size and element_size from them. Every T8140 window has one instance, so its register map and mappings are unchanged. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The A18 Pro firmware acknowledges the initialization root with an INITDATA_ACK message and expects POWER_ON_DONE once both coprocessors are initialized. Other firmware builds acknowledge by setting word +0x14 of the primary status A to 1 and send no message. Add fw::variant::InitAck and Variant::power_on_done. With InitAck::Status the host polls status A for up to 3 s after handing over the primary root, failing early if the firmware crashes; the opening-record wait that follows is unchanged. POWER_ON_DONE is sent only where the variant asks for it. V26A428 keeps the message and POWER_ON_DONE, so T8140 is unchanged. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The UAT code reaches the firmware's root and kernel-window tables
through struct page, so it requires the pagetables region to be part
of the kernel's memory map; it refuses a root in no-map memory ("DT
using no-map?"). On the M4 Pro the boot loader reserves the UAT ranges
as no-map regions outside /memory, and the firmware also builds tables
in the l2-pagetables region.
Add mmu::UatQuirks::reserved_tables: the pagetables and l2-pagetables
regions are mapped write-back once (pgtable::ReservedTables), and every
table access goes through with_table(), which uses that mapping for a
page in either region and struct page otherwise. The CPU's cached lines
of both regions are cleaned and invalidated after the firmware booted,
so the host reads what the firmware wrote.
This is a temporary path: once the boot loader adds the UAT ranges to
/memory, as m1n1 does, the regions lose no-map and this commit can be
reverted. T8140 and the older GPUs use UatQuirks::DEFAULT and are
unchanged.
Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com>
Assisted-by: LLM
The M4 Pro GPU has only ever run with the UAT policy the Gravity Linux G16 driver uses for it: every page-table and context-table change is written back (dc cvac), TLB ranges are invalidated one page at a time, the handoff page carries only the host header (current slot 0xffff_ffff, the lock never taken) and GPU-only client mappings are stored as AP 0 with the access in PXN/UXN. Whether the M4 Pro needs any of this has not been tested; the A18 Pro needs none of it. Add one UatQuirks field per setting, so a SoC can stay on the policy it was tested with and each setting can be moved to the A18 Pro's value on its own after a test: - clean_tables: clean every page-table change to the point of coherency, with the page-table cleaning the G16 backend already uses (clean_poc, no longer limited to G16), and also the handoff page and each context-table slot after it changes; - page_tlbi: invalidate page by page (vae1os), or the whole ASID above 2048 pages, instead of rvae1os; - handoff_lock and handoff_slot: whether the legacy handoff lock is taken and the current slot written at initialization; - native_gpu_permissions: the AP 0 form for GPU-only mappings of client and kernel-lower tables, on map and on reprotect. The root clean of clean_poc goes through the reserved-table mapping, so it also covers a firmware root in no-map memory. UatQuirks::DEFAULT keeps the A18 Pro policy, so T8140, the older GPUs and the adopted G15/G16 UAT are unchanged. Based on findings by Gravity Linux (Cody Ho, Niklas Sheth). Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The M4 Pro (T6040) GPU coprocessor is an ASCWrap v6 like the A18 Pro's: the ADT node /arm-io/gfx-asc is compatible with iop,ascwrap-v6, its wrapper is 0x88000 bytes with the ASC mailbox at +0x8000, and its vector-base register follows the same layout. Unlike the A18 Pro it runs a single firmware instance, with the GFX role. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The ASCWrap v6 provider accepts only the T8140's GPU coprocessor windows. The M4 Pro (T6040) GPU coprocessor is the same block with one firmware role, GFX, at wrapper 0x28a600000 and vector base 0x28a050000 (ADT /arm-io/gfx-asc). Replace the hard-coded T8140 checks with a role table per compatible: each role has its name, its firmware role and its fixed CPU-physical windows, which the probe validates as before. Add the apple,t6040-ascwrap-v6 compatible with its single role. T8140 keeps its two roles at the same addresses. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The M4 Pro (T6040) GPU is described like the A18 Pro's: an asc and an sgx register range, its GPU power domain and an operating-point table with one voltage per cluster. It has a single GFX coprocessor mailbox, operating-point tables for its CS and AFR clock domains (apple,cs-opp and apple,afr-opp, the names the older Apple GPUs' device trees use), and two more memory regions than the A18 Pro: fw-data, the loaded firmware's data segment, where the firmware places its crash log, and l2-pagetables, where the firmware builds the page tables of its kernel window. The boot loader may report the macOS version whose boot firmware loaded the GPU firmware in apple,firmware-version, which identifies the firmware build. The memory-region lists differ per compatible, so move them into the per-compatible branches; the existing compatibles keep the same regions and names. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The M4 Pro runs the macOS 26.6 GPU firmware (25G83, mBoot-18000.161.10). It has the A18 Pro firmware's interface version and the same initialization objects, with these differences: - One coprocessor carries both roles: one main configuration with the secondary-only words (0x300 = 4, the power-configuration pointer), a zeroed page at unk_18, 0x32c and 0x344 zero, and one merged root naming status B, the power state and the configuration. - The cluster is 0xd4000 bytes: status B at 0x10000 is 0xf180 bytes long, status A follows it, and the power state is its own page, of which only the fast-die target and release temperatures are set. - The hardware data (HwData25G83) is the A18 Pro's up to 0x2554 with 8 bytes inserted before 0x2570 and 4 more before 0x2614, so the completion rings move to 0x2620 and the QoS pointer to 0x26b8. It has the CS and AFR performance tables at 0x1a48 and 0x1b90 and carries one voltage lane per cluster. - The power configuration (PowerConfig25G83) is at bundle +0x5380 and has two blocks fewer than the A18 Pro's; the auxiliary data and an AON temperature-source table follow it. - Region C has other values, now RegionCConfig in Config (T8140 keeps its values). - The five views and the firmware area are separate pages. fw::variant::InitGraph selects the graph. The 25G83 contents are constants except for the operating points (the device tree's GPU, CS and AFR tables), the core count, three pointers and a random word. They were derived by evaluating, for the J616s, the hardware-data, region C and power encoders that Gravity Linux (Niklas Sheth, Cody Ho) wrote for this firmware, which the M4 Pro has run with since; no code of theirs is carried. At boot the built hardware data, power configuration and region C are hashed (FNV-1a, without the runtime words) and compared with the hashes of the encoders' output, and the GPU is not started if they differ. The leakage coefficients in the power configuration are this unit's values. They are not in the ADT, and whether they are per SoC or per device is not known; they stay a driver constant until that is. Where the 25G83 graph deviates from the A18 Pro's is only known from that setup; every value is the one that runs today. Based on findings by Gravity Linux (Cody Ho, Niklas Sheth). Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The 25G83 firmware expects two commands in a render pair's item rings that the A18 Pro firmware does not take: - InitBufferManager (tag 5) before the first tiling descriptor that uses a buffer manager, naming its UAT context, buffer slot, PB state and tiling stamp; - FragmentBarrier (tag 4) before every fragment descriptor, waiting for the paired tiling stamp in addition to the kick-entry dependency. Add Variant::lead_commands. With it, render publication writes these commands after each stage's QueueConfig record in its configuration slot and publishes them as the first item of the stage, and the buffer manager remembers that it was initialized once a tiling pass with InitBufferManager was published. V26A428 has no lead commands. Based on findings by Gravity Linux (Cody Ho, Niklas Sheth). Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The 25G83 firmware takes render descriptors with other register programs, and the M4 Pro's two clusters of ten cores change the buffers whose layout follows the core layout. Firmware-build data (Variant::programs, RegisterPrograms::V25G83): - Tiling array of 83 entries (checkpoints 81/83/83, free-list slot index 79): the A18 Pro's without 0x1748 and 0x1740, with the twelve tiler parameter sub-buffer registers and 0x10131 = 0x88. - Main fragment array of 91 entries (checkpoints 87/88/88, slot index 84): with 0x160b8 = 0 after the tile state and 0x160a8 = 0x20 before the closing 0x16068. - Both drop the SCS enable 0x017d9 unless the stage has shader-context scratch; a stage with it carries 0x017d9 = 1 as on the A18 Pro, and the counts and indices after it move by one. - Tile-state base 0x36011 instead of 0x3717f: with the A18 Pro's bits a fragment pass more than 80 tiles wide and with more than 4096 tiles never completes, which includes every full-screen pass on the 3456x2234 panel. - The TPC object also holds the seven tiler parameter sub-buffers the tiling registers name. Core-layout data: - The deflake buffer's sub-buffers follow each cluster's control words: +0x20/+0x2a0 with one cluster, +0xa0/+0x820 with two, where the viewport words at +0x900 would land in the third sub-buffer and are not written (render::Deflake). - The compute operand-state buffer holds two banks of three records per core and one tail per cluster: 0x44000 bytes with banks of 0x1e000 at a stride of 0x1e400 for two clusters of ten cores (compute::OperandState). Only the measured layouts are accepted. V26A428 and one cluster keep the A18 Pro's programs and buffers. The 25G83 register lists come from the register programs that the Gravity Linux G16 driver (Niklas Sheth, Cody Ho) runs on the M4 Pro; the code is new. Based on findings by Gravity Linux (Cody Ho, Niklas Sheth). Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
Add the M4 Pro GPU to the G17 runtime. Its firmware (25G83) runs on one ASCWrap v6 coprocessor with the GFX role, which the mailbox provider starts and stops; the GPU power domains are ordinary PMGR domains. The ID registers report one die of two clusters with ten cores each, family 0xa, variant 3, revision B1. - hw/t6040.rs: the configuration, the 25 register windows (the memory controller and AFR slots with four instances each), the performance table configuration and region C. - fw::variant::V25G83: QIDs from 32, the producer at pointer block +0x50 without a recovery target, no MMIO render-pair registration, no MCache, lead commands, the 25G83 register programs and initialization graph, acknowledgment in status A and no POWER_ON_DONE. Few-primitives renders hang this firmware and a stalled ray traversal wedges the GPU without a recovery, so neither is offered nor accepted. - CrashBuffers::FirmwareData: the firmware asks for its crash log at a physical address inside its data segment (the fw-data reserved region); the driver maps that range and RTKit echoes the request. - Config::adopt_root_entries and Config::fabric_bridge: the M4 Pro borrows the firmware root as the firmware left it and writes neither the fabric bridge nor the gating register, as it has always run. - The UABI reports the GPU as G16, which userspace drives it as. - The firmware build is identified, not inferred from the SoC: Config::firmware (fw::variant::Firmware) lists the builds a SoC supports by the macOS version whose boot firmware loaded them, which the boot loader reports in apple,firmware-version on the GPU node (as m1n1 writes it). The T6040 accepts macOS 26.6.2 (iBoot mBoot-18000.161.10, the 25G83 firmware) and refuses anything else before touching the GPU, naming what it found; the build it accepts is logged. The T8140 keeps its single unidentified build. Where the values differ from the A18 Pro's they are the ones the M4 Pro runs with today. The UAT quirks other than the no-map tables, the root adoption, the bridge and gating, the MMIO registration and POWER_ON_DONE were never tested the A18 Pro's way on this chip, and each stays a separate setting until it is. Based on findings by Gravity Linux (Cody Ho, Niklas Sheth). Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
Describe the M4 Pro GPU as the A18 Pro's is described: - pmgr_gfx: the PMGR block of the GPU power domains (ADT pmgr devices AFR 0x181 at +0x100 and GFX 0x182 at +0x110 with parent AFR), laid out as on the T6031. Both are always on: the GPU firmware keeps running and does not survive GFX going off. GPX (0x180 at +0x0) is left alone, as the boot loader leaves it on and nothing uses it. - gfx_mbox: the ASCWrap v6 coprocessor mailbox with the GFX role (ADT gfx-asc), its send-empty and receive-not-empty interrupts. - gpu: the asc and sgx ranges, the mailbox and the GFX power domain. - The PMP's GPU report entry (pmp_gfx) gets the GFX domain as its parent, as on the T8140. On the J616s the GPU firmware runs from boot on, with GFX always on, so the board claims pmp_gfx always-on: the PMP sees the GPU on whenever it is powered. Without the GPU node the entry stays unclaimed (the PMP crash of a claim with nothing powering the GPU, fixed by commit c4722f3). On the J616s, add its sixteen operating points in performance-state order with one opp-microvolt cell per cluster (ADT /arm-io/sgx perf-states and perf-states1), the eight of its CS and AFR clock domains (cs-perf-states, afr-perf-states), and the memory the boot loader reserves for the GPU firmware: its data segment (fw-data), where it places its crash log, and the UAT ranges (ttbs, pagetables, l2-pagetables, handoff). The operating points are binned per device: these are this unit's values until the boot loader fills them in. The UAT ranges are no-map until the boot loader adds them to /memory. Binding: apple,agx-t6040 and apple,t6040-ascwrap-v6, earlier in this series. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
Bring in the J616s USB-C ports (#403). Its Type-C nodes and this series' GPU nodes were added at the same place in t6040-j616s.dts; both are kept. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The boot loader finds the GPU node through the gpu alias, as m1n1's dt_set_gpu() does on every other Apple SoC (t600x, t602x, t603x, t8103, t8112, t8122, t8132, t8140 all have it). Without it a loader cannot fill in apple,firmware-version on the T6040 GPU node, and the driver refuses the GPU unless the device tree carries the property itself. Fixes: 92d0217 ("arm64: dts: apple: t6040: Add the GPU") Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
Commit 20e5164 ("drm/asahi: g17: add the T6040 (M4 Pro)") maps the crash log that the 25G83 firmware places in its data segment the way Gravity Linux's M4 GPU driver maps its crash buffer (CrashBuffer and BootOps::shmem_map in drivers/gpu/drm/asahi/g16.rs, written by Cody Ho). It looks up the same reserved region by name, applies the same bounds checks against it and maps it write-back the same way. The code derives from Gravity Linux commit bd25d19 ("drm/asahi: add asynchronous M4 GPU prototype driver"), which is GPL-2.0-only, so it cannot stay in g17/mod.rs, which is GPL-2.0-only OR MIT. Move the mapping into g17/data_segment.rs under GPL-2.0-only, with a header that credits Cody Ho and Gravity Linux and links the original commit. The behaviour is unchanged. Originally-by: Cody Ho <codyho@stanford.edu> Link: GravityLinux/linux@bd25d19 Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The operand-state and deflake buffer layouts were chosen from the cluster and core counts the GPU reports at probe, so the A18 Pro kept its layouts only as long as it reported one cluster. Name them in the SoC's Config instead. The T8140 gets the layouts it has always used, with no new check. The T6040 names the layouts measured on the 20-core M4 Pro and the counts they were measured on, and a GPU that reports other counts is refused at probe, as before. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The performance tables take each operating point's voltages from one cell for the whole GPU or one cell per cluster, but nothing checked that a table with several cells has one per cluster. A table with another count filled the lanes of clusters the GPU does not have, or left some of its clusters at zero volts. Refuse the GPU's operating points unless they have one cell or as many cells as the GPU reports clusters. The A18 Pro's table has one cell and is accepted as before. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
PointerBlock::word() took any offset other than 0x50 as the word at 0x40, so a pointer layout naming another offset would silently move the producer or the recovery target to the wrong word. Accept only the two host words and fail otherwise, and check the layouts of both firmware variants at build time, so that a wrong layout cannot be built at all. The words written for the existing layouts are unchanged. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
write_leads() narrowed the fragment descriptor's 64-bit object ID to 32 bits before FragmentBarrier::new() widened it again into the barrier's 64-bit field, which would truncate any ID above 32 bits. Pass the ID through as it is. The IDs come from 32-bit counters today, so the bytes written do not change. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Two comments named internals of Apple's userspace GPU driver to explain where the 25G83 fragment barrier and the tiler parameter block sizes come from. State what the code does instead. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
PAGE_TLBI is a global static that Uat::new() sets from the SoC's UAT quirks, because the TLB invalidation helpers take no UAT. Say so, and say that it assumes one GPU per system, as every supported system has. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…rsion apple,firmware-version is a macOS version (major, minor, patch), and the G17 driver only accepts it with exactly three cells. The binding only limited it to at most three. Require three. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The J616s GPU node carries the operating points and reserved regions of one unit, and the GPU firmware's per-unit values are not filled in from the ADT yet. Another unit needs 5 to 15 mV more in most states, and other units place the regions elsewhere. Keep the GPU disabled until a boot loader fills these in. The GPU's companions follow it. gfx_mbox stays disabled, and the board no longer claims pmp_gfx always-on, because telling the PMP the GPU is on with no GPU driver crashes the PMP firmware right after it starts. ps_afr and ps_gfx are no longer always-on in the SoC file either, so a disabled GPU's power states are not forced on. A board that enables the GPU makes them always on again, and the operating-point tables and reserved regions stay in place for that. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Resolve the t6040-j616s.dts conflict with #412: keep the MagSafe controller comment and the disabled GPU node. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…ssion test This series makes Pool::new() take the number of queues, and #413 added a KUnit case that still calls it without one. Pass MAX_EXECUTION_CONTEXTS like the other admission tests. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
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.
jgoyvaerts' #408 (T6040 GPU on the G17 backend) with our review follow-ups, merged together. #408 itself now conflicts with integration/aurora (t6040-j616s.dts, after #412), so this branch carries his 19 commits unchanged plus our commits and two merges of integration/aurora.
Our follow-ups
CrashBuffer/shmem_mapin g16.rs: Cody Ho's "drm/asahi: add asynchronous M4 GPU prototype driver" (bd25d19), committed by Niklas Sheth, whose file note says it is adapted from his linux-m4-integration prototype. It moves out of the dual-licensed g17/mod.rs into its own GPL-2.0-only file, g17/data_segment.rs. That file credits Cody Ho and Niklas Sheth and links the commit (Originally-by + Link in the commit).Tested
Not done here: running the J616s GPU itself. That needs per-chip values and comes as a separate change. Also left for later: reusing the G16 TEXT hash check, taking leakage from the DT, a checked
with_tableborrow, sharing the 25G83 identity with G16, and mapping fw-data once.Supersedes #408 (merged through this PR, with jgoyvaerts' commits as they are). Thanks Jonathan.
🤖 Generated with Claude Code