Repository navigation
nvme: apple: run the T6050 ANS on bare metal - #936
Conversation
450575b to
7972517
Compare
DjDeveloperr
left a comment
DjDeveloperr
left a comment
There was a problem hiding this comment.
Works on the M5 Pro (MacBook Pro 14", J714sAP, T6050), bare metal.
Kernel: this head (7972517) merged into PR1012's base 0dd0833 together with the heads of #937–#943 and #841, RAM-booted three times through aura from the SSD Stage 2's proxy window.
- The ANS is adopted live from Stage 1's session (
apple,rtkit-handoff). nvme0n1 shows p1–p6 plus n2/n3 on every boot, and the kit keeps them read-only. The kit reserves the RAM ranges in ANS's SARTv4 slots, and there are no SART or NVMe errors. - Reads through it work: an ext4 partition mounted read-only, and a 31 MB firmware file loaded from it (the N1's, for #938).
- The M5's default boot from its internal SSD runs the same driver code (our kit's pick is identical apart from the cherry-pick line).
Merge note: this head no longer merges cleanly into current integration/aurora. apple,nvme-ans.yaml conflicts with e0b7106, which already has the T6050 then-clause (with resets: false). I kept integration's version for the test, so 5708f36 looks redundant now.
RyanTheTide
left a comment
RyanTheTide
left a comment
There was a problem hiding this comment.
This conflicts with current integration/aurora in Documentation/devicetree/bindings/nvme/apple,nvme-ans.yaml (the T6050 compatibles added in e0b7106 and later). Could you rebase it? No CI has run on this branch yet; the push after the rebase will run dt-checks and the host tests.
The T6050 (M5 Ultra) SART keeps SARTv3's entries but moves the address and size arrays, so it is not compatible with apple,t6000-sart and has no fallback. Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Erik Bourget <erik@ebourget.net>
The SART that filters the T6050 (M5 Ultra) ANS's DMA keeps SARTv3's entry format (config, page address and size, 4 KiB units) but moves the address and size arrays from 0x40/0x80 to 0x60/0xc0. Read on J775D before Linux started: the config words at 0x00+4i and seven live entries whose addresses at 0x60+4i and sizes at 0xc0+4i name ANS's MMIO and two DRAM ranges. Let the v3 ops carry the array offsets, so v3 and v4 share one implementation, and match apple,t6050-sart with the v4 offsets. There is no v3 fallback compatible: a v3 driver would read the wrong registers. Log the number of entries the boot loader left (protected) at debug level. v2 and v3 SARTs keep their offsets. Testing: on J775D, every boot since protects the seven entries the boot loader left, and ANS's NVMe runs behind it (Linux boots from and writes to its NVMe partition). Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Erik Bourget <erik@ebourget.net>
Add apple,t6050-nvme-ans2 for the M5 Ultra's ANS when Linux runs on the hardware. Its layout is T6040's, as the ADT and the registers read before Linux started show: a 64 KiB "nvme" block, a separate NVMMU and linear submission queues. The controller reports 254 queue entries (CAP.MQES 0xfd); the profile uses T6040's 64. FUA writes are not shown durable here, so the profile flushes instead (NVME_QUIRK_BROKEN_FUA). The boot loader leaves ANS's firmware running and the controller shut down (CC.EN 0, CSTS.RDY 0). The driver adopts that session, and, like every post-M4 ANS without cold_reset, never resets it through PMGR, so the profile sets reset_optional, a hardware-profile flag that takes the controller reset as optional, and the binding requires no reset for it. Every other profile still requires its reset. Testing: on J775D, every boot since 2026-10-30 adopts ANS's running firmware and enables the controller with this profile; Linux runs from its NVMe root partition (ext4) through daily builds and reboots without an NVMe error. Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Erik Bourget <erik@ebourget.net>
The boot loader leaves the T6050 ANS's firmware running with the controller disabled and, as on T8132 and T8140, adds apple,rtkit-handoff to the node so the kernel adopts that RTKit session instead of starting the co-processor again. The T6050 profile relies on that adoption. Allow the property on apple,t6050-nvme-ans2. Signed-off-by: Jeff Queisser <funkzy@users.noreply.github.com> Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Erik Bourget <erik@ebourget.net>
7972517 to
e6e2873
Compare
|
Rebased onto integration/aurora (8d98b7a), as asked in the review. The old head 7972517 is kept as What changed (
🤖 Generated with Claude Code |
|
Retested before merging on the M5 Pro (J714sAP, bare metal, SSD boot), kernel 7.3.0-m5-merge: the M5's integration kernel with this round's rebased heads in place of the old ones (every PR's own patch identical to what is merged; logs in work/m5-pr-merge-20261109). CI green. Before merging, this round (these 14 PRs, #1323 and the rebased #1254/#1306/#938/#1316/#1199) was test-merged in order onto integration/aurora f9cf6f9 with no conflicts:
🤖 Generated with Claude Code |
On T6050 the boot loader leaves the NVMe controller's (ANS) firmware running and the controller shut down, and its SART moved the address and size arrays. Neither the existing SART nor the ANS profiles handle that, so there's no internal storage.
apple,t6050-sartuses v4's (0x60/0xc0). No v3 fallback, since a v3 driver would read the wrong registers.apple,t6050-nvme-ans2, T6040's layout. It adopts the running RTKit session (apple,rtkit-handoff), never resets the controller through PMGR, and flushes instead of trusting FUA.Commits by Jeff Queisser. On J716c (MacBook Pro 16-inch, M5 Max) this runs as part of the full T6050 stack (
j716c/t6050-platform): the machine boots to userspace from NVMe with all 18 CPUs, N1 Wi-Fi up and CPU frequency scaling active. The root filesystem is on this NVMe.Created with Claude Opus 5.5 in Claude Code.