m0dm0d

branding / technology / typography / production / visual experiments / 3D art / AI & workflow exploration

[Ryan Weddle @ryan_w]

Woohoo! Finally had first compute test succeed on my RDNA2 bring up fork of @__tinygrad__ on mac! 🎉

Now for testing and clean-up:
https://t.co/EpT2Jrwv1u

FYI @m0dm0d

[m0dm0d @m0dm0d]

@ryan_w @__tinygrad__ TB4 path needed:
BAR0 IOMMU registration (custom dext, SIP disabled)
alloc_sysmem for msg1 (TB-specific PSP fix)
HDP flush for RDNA2 (NBIO v2_3 remap)
Boot allocator overlap fix
SDMA root cause: address class bug (VA vs GTT)
SDMA — still WIP for me!

[m0dm0d @m0dm0d]

🎉 RDNA2 on Apple Silicon — both paths working!
@ryan_w (OCuLink): Tensor.arange(16) → [0..15] ✅
Me (TB4/eGPU): Tensor([1,2,3]) → [1 2 3] ✅
RX 6900 XT + M4 Mac Mini
I made huge progress today with Ryan's fork + my TB4/IOMMU fixes. My SDMA still TODO 🔧 @__tinygrad__

[m0dm0d @m0dm0d]

Following @ryan_w 's lead — running @AnthropicAI Claude + @OpenAI ChatGPT Pro 'extended thinking' as reverse engineering collaborators in the loop.
Genuinely useful combination for live debugging + deep firmware analysis (with my tiny brain & hitting keys in between)!

[m0dm0d @m0dm0d]

Some more RDNA2 reverse engineering on Apple M4 via tinygrad 🔧 Today's findings:
→ alloc_sysmem for PSP msg1 buffer appears key on Thunderbolt path
→ BAR0 IOMMU registration in custom dext reducing DART crashes
→ C2PMSG_81 + C2PMSG_64 behaviour suggests SOS may be executing

[m0dm0d @m0dm0d]

Still hitting ring_create rejection (0x8000FFFF) — suspecting Apple's Alpine Ridge TB controller could be a blocker

OCuLink hardware ordered. Testing a direct PCIe path tomorrow 🤞

[m0dm0d @m0dm0d]

@ryan_w @Jimster4801 @__tinygrad__ C2PMSG_39 came from AMDRadeonX6000.kext — glad it's useful! ... But you've just given me an idea... to boot up the imac with the 6900 XT attached and try to extract some further info from there.

[m0dm0d @m0dm0d]

@ryan_w @Jimster4801 @__tinygrad__ That's exactly where we're stuck — SOS silent, C2PMSG_39 = 0x0 for 60s. SYS_DRV not in our sos_fw keys [1, 4, 3]. How did you extract it from the v1_3 array? Happy to share my patch diff and compare notes. I'll get into that and DM

[m0dm0d @m0dm0d]

@ryan_w @Jimster4801 @__tinygrad__ out of interest, what's your setup and how far in have you got?

[m0dm0d @m0dm0d]

@ryan_w @Jimster4801 @__tinygrad__ I've hit a wall today - quite a few areas to explore... BAR0=~0x108ecc000 (dynamic), PSP uses privileged physical mode, bypasses GPU page tables. flush_hdp() is a silent, SOS binary has GlobalPlatform TEE strings — device identity checks that might silently fail.

[m0dm0d @m0dm0d]

@__tinygrad__ And SOS binary has GlobalPlatform TEE strings — device identity checks that might silently fail... A little bit stuck now.

[m0dm0d @m0dm0d]

More RDNA2 findings today exploring @__tinygrad__ BAR0=~0x108ecc000 (dynamic) vs mc_base=0x8000000000 — two different views of the same VRAM. PSP uses privileged physical mode, bypasses GPU page tables. flush_hdp() is a silent no-op on RDNA2 — register doesn't exist.

[m0dm0d @m0dm0d]

@__tinygrad__ PSP bootloader wakes ✅ KDB loads ✅ SOS delivered ✅ C2PMSG_39 completely silent — SOS never executes. 60s, nothing.
Advised via discord MC addresses stay on-GPU — so not a DART issue. Address format now confirmed correct. Hardware eliminated. Just stuck on RDNA2 SOS won't fire.

[m0dm0d @m0dm0d]

Spent a little time on RDNA2 eGPU support in @__tinygrad__ on Apple Silicon (M4 Mac Mini + RX 6900 XT via Thunderbolt 4).

Big breakthrough: the PSP bootloader IS now waking on cold boot. C2PMSG_35 = 0x80000000 ✅

Not cracked it yet, have faith Claude will get me there! 🧵1/3

[m0dm0d @m0dm0d]

@__tinygrad__ Stuck at _ring_create — GPU DMA to VRAM MC addresses crossing the TB link hits Apple DART IOMMU with no mapping. Most likely need @__tinygrad__ input on VRAM aperture registration.
Progress. 🔴

[m0dm0d @m0dm0d]

@__tinygrad__ still going... RDNA2 (RX 6900 XT) running via Thunderbolt on Apple Silicon using Tinygrad + TinyGPU.
Today: PSP bootloader waking ✅ KDB loading ✅ SOS firmware alive (C2PMSG_81 = 0xffffffff) ✅

[m0dm0d @m0dm0d]

@__tinygrad__ Tomorrow’s exploration…

How do you hand a Thunderbolt eGPU a memory address it can actually read from on Apple Silicon?

The PSP bootloader is alive. It's listening. We just need to point it somewhere it's allowed to look. 👀

[m0dm0d @m0dm0d]

@__tinygrad__ Current blocker: Apple Silicon IOMMU. Bootloader
Accepts the firmware address, tries to DMA from it, Mac locks up hard.
Memory isn't mapped for PCIe access. Next: investigate how @__tinygrad__ 's USB path handles this differently. alloc_sysmem vs palloc. 3/3

[m0dm0d @m0dm0d]

@__tinygrad__ Pulled AMD's macOS kext from an iMac running 12.4 — last OS / official RDNA2 eGPU support.

Disassembled AMDRadeonX6000.kext / found queryBootLoaderPostCode() pointing to C2PMSG_39 — previously unread.

Fixed a double-KDB firmware send bug / silently hanging the bootloader. 2/3

[m0dm0d @m0dm0d]

@__tinygrad__ Update: past the interrupt controller registers. GPU fully seen and initialised — all 5 firmware files loading. Now hitting PSP bootloader timeout, the last real barrier. RDNA2 init sequence differs from RDNA3. Any pointers on the PSP boot sequence for Navi21?