<marcan>
(writing some website docs now, will get back to hardware in a bit)
<rwhitby>
marcan: Re: 0x012: Bit24: "Persist through soft reset. This doesn't seem to work on M1 Macs (the PD controller reboots when the system reboots)." - I think that's referring to a USB-PD Soft Reset rather than a system reboot (or am I misreading what you've written there?).
<rwhitby>
marcan: are you familiar with the MIPI Narrow Interface for Debug and Test (MIPI NIDnT) https://www.mipi.org/specifications/nidnt ? It contains a structured VDM protocol for remapping debug pins on a Type-C connector. At first glance it doesn't seem to match here, but I'm wondering if any of the concepts have been reused, so thought you might be interested if you haven't seen it before.
<rwhitby>
In other news, it seems my 16" MacBook Pro has the same PD controller (CD3217B12) as the M1. So I will document it as well and see if they match.
<marcan>
rwhitby: that came from the t8021 guys, and they said it works on the Intel ones maybe? but I'm not sure tbh
<marcan>
I am not familiar with the MIPI thing, thanks, I'll take a look :)
<marcan>
keep in mind those controllers have a flashed firmware that overrides ROM methods, but I *think* Apple uses the same exact firmware for all Intel macs and probably the M1 ones too? only the parameter area varies for each Intel one
<marcan>
for machines with the same chip I mean
<marcan>
I have the flash area decompiled, but it only overrides some hookable ROM functions, so it's hard to see the overall code flow, you only get what they added/redid
<rwhitby>
The PD controller firmware should be in an external SPI flash if it's the same as the regular TI devices. The TBT controller usually shares the flash.
<marcan>
rwhitby: the PD controller firmware on those TI devices is actually an internal OTP/ROM thing; the external SPI flash only loads *overrides* for the internal ROM code
<marcan>
TI's documentation is horrible on this whole thing, but that's how it actually works
<rwhitby>
I see. Hmm.
<marcan>
basically the SPI code gets loaded at a (hieously unaligned) SRAM offset, called, and it overrides function pointer table entries that the ROM uses. The ROM has thunks that call through those pointers to itself (initially), and the SRAM code has more thunks that call back into the ROM functions.
<marcan>
it's not hard to dump the ROM, you can use SWD on the chip pins or just flash some firmware that dumps the ROM out, but I haven't bothered to go there yet
<marcan>
(if we need to I will)
<rwhitby>
Hmm, it seems the information for a certain actionId is different on different devices.
<marcan>
I think that might include things like what pins it can be muxed on
<rwhitby>
although the data there looks "rotated"
<marcan>
they use 16-bit tokens, so that looks like 0x385,0x103 for the first, and 0x103,0x501,0x385 for the second
<marcan>
so the only difference is the second adds 0x501
<marcan>
(it's a set)
<rwhitby>
gotcha
<rwhitby>
the same actionId on different ports of the same device seemed to return the same data (for a limited subset I looked at)
<marcan>
are these devices running the same firmware? (same OSX version)
<rwhitby>
both are Big Sur, but I just realised the 14,1 is a minor version behind, so I'll update it and see if it changes things.
<rwhitby>
Will also check the TBT firmware version in the system report after I update it.
<marcan>
14,2 or 14,1?
<rwhitby>
sorry, 14,2 the 2017 alpine ridge one
<rwhitby>
it was on OSX 11.0.1 whereas the 15,2 is on OSX 11.1
<marcan>
I think there were significant changes there, yeah
<marcan>
the firmware grew several kilobytes
<marcan>
dammit mac codenames are so annoying to relate
<marcan>
this ACE2 firmware speaks of "A127X" but A1278 is a 2010 macbook which *definitely* wasn't using ACE2
<rwhitby>
looking at TBT firmware versions, the Titan Ridge 16" 16,1 is at 55.3 (but it's still running OSX 10.15.17 cause I've got things that need to be updated for Big Sur), the Titan Ridge 13" 15,2 is at 47.4 (OSX 11.1) and the Alpine Ridge 13" 14,2 is at 41.4 (OSX 11.1)
<marcan>
can you get the board IDs?
<marcan>
ioreg -l | grep -i board-id
<marcan>
those will point me to the right firmware
<rwhitby>
14,2 response to actionId 0x205 is unchanged after updating to OSX 11.1, so remains different to 15,2 response.
<marcan>
15,2/Mac-827FB448E656EC26 is ACE1, so is 14,2/Mac-CAD6701F7CEA0921. 16,1/Mac-E1008331FDC96864 is ACE2.
<marcan>
so only the 16,1 has the same chip as the M1s
<marcan>
ACE1 seems to have a somewhat different firmware approach (config area is different)
<marcan>
but still, let's see
<rwhitby>
Hmm, the 14,2 is "expendable" to me, the 15,2 is important and the 16,1 is my main laptop. I was hoping to be able to experiment on the 14,2 first so I don't damage the others :-)
<marcan>
the ACE1 ones outright say TPS65983 in the firmware, so I'm pretty sure CD3215C00 == TPS65983 with different OTP/ROM code
<rwhitby>
I have 65982 and 65987 dev boards, but no 65983
<rwhitby>
marcan: the CD3217B12 on the M1 and 16,1 doesn't happen to correspond to the TPS65987 does it?
<rwhitby>
Marcan probably already knows all this, but for the benefit of others, this document describes the "patch bundles" in the external SPI flash for the PD controller: https://www.ti.com/lit/an/slvae21a/slvae21a.pdf
<marcan>
we don't know about that one, but it well might
<rwhitby>
The TPS65987 EVM I have is somewhat expendable, so could be use for experimentation.
<marcan>
do you have a sample firmware for it?
<marcan>
actually just look at the first word
<marcan>
00000000 02 00 e0 ac is what the apple ones have :-)
<rwhitby>
All my test clips are at the office, so I'll need to dump this SPI flash tomorrow.
<Necrosporus>
rwhitby, so you got some intel macs with T1 or T2? Or some M1 too?
<rwhitby>
Intel Macs only at the moment. alpine ridge and titan ridge used for TBT3 interoperability testing
<Necrosporus>
I don't know those letters
<rwhitby>
Thunderbolt 3
<Necrosporus>
And I don't know what those ridges are either
<Necrosporus>
rwhitby, do you have a regular PC with GNU/Linux?
<Necrosporus>
And USB port
<rwhitby>
Yep. Why do you ask?
<Necrosporus>
Because marcan did post log of linux dmesg when a macmini was connected by USB-A to USB-C cable
<Necrosporus>
So I was wondering if intel macs report different USB id or same
<Necrosporus>
usb 2-4: New USB device found, idVendor=05ac, idProduct=1901, bcdDevice= 9.01
<Necrosporus>
That's from mac mini M1 ^^
<Necrosporus>
rwhitby, I have tried to connect my OrangePi4 board via USB typeC (it's only device I have with TypeC port except external HDD case) it wasn't visible as a device
<rwhitby>
oh, I can get that from the PD Discover Identity. 15,2 is PID 0x166F and BCD 16.0 14,2 is PID 0x1669 and BCD 5.9 16,1 is PID 0x1670 and BCD 20.4.6
<rwhitby>
Necrosporus: the ridges are the TBT controller chip code names
marcan has quit [Quit: Now where's my screwdriver...]
maximus64 has joined #asahi-re
Shiz has joined #asahi-re
gruetzkopf has joined #asahi-re
Raqbit has joined #asahi-re
GaveUp has joined #asahi-re
josiahmendes[m] has joined #asahi-re
jn__ has joined #asahi-re
Fanfwe has joined #asahi-re
austriancoder has joined #asahi-re
DrWhax has joined #asahi-re
flokk has joined #asahi-re
Yuzu has joined #asahi-re
DarthCloud has joined #asahi-re
titanous has joined #asahi-re
x56 has joined #asahi-re
jld has joined #asahi-re
nufflee[m] has joined #asahi-re
konstanter has joined #asahi-re
marcan has joined #asahi-re
sven has joined #asahi-re
chuskywalker has joined #asahi-re
akemin_dayo has joined #asahi-re
nkaretnikov has joined #asahi-re
nemith has joined #asahi-re
flokk has quit [Quit: Leaving]
pg12 has joined #asahi-re
marcan has quit [Ping timeout: 246 seconds]
sven has quit [Read error: Connection reset by peer]
marcan has joined #asahi-re
<davidrysk[m]>
Apple places firmware in /usr/standalone/firmware on macOS
<davidrysk[m]>
I'm not sure if that is merely a staging repository, though
m42uko has joined #asahi-re
sven has joined #asahi-re
<davidrysk[m]>
and also in /usr/share/firmware/wifi
<davidrysk[m]>
err, /usr/share/firmware
<davidrysk[m]>
the wifi device appears to be a BCM4378, which does have firmware, as there is a kext called com.apple.driver.BCMWLANFirmware4378.Hashstore.
mogery has joined #asahi-re
<davidrysk[m]>
yeah I think it's likely that brcm firmware will be needed
prusnak has joined #asahi-re
pdrew has joined #asahi-re
<davidrysk[m]>
Looking at the kexts in general I see a handful of firmware related ones, but I can't tell how many are actually loading firmware. A bunch are loaded though.
Bluerise has joined #asahi-re
<Bluerise>
I figure the BCM4378 should be just another FullMAC, so it'll definitely need firmware. That said, the firmware interface probably doesn't differ a lot from the regular Broadcom FullMACs. At least that's my hope.
<Bluerise>
There's not a lot to gain in changing the interface anyway. All that p2p stuff is already supported by the normal Broadcom FullMACs.
<Bluerise>
oh nice, it's all there.
<davidrysk[m]>
Where do we stand regarding the BCM4375, which I would expect it to be derived from?
<Bluerise>
firmware, clm blob, nvram. unencrypted, just laying there. the hardest part is figuring out which file to use.
<Bluerise>
So, once we find out which file's to use, OpenBSD's bwfm(4) probably works out of the box, and I'm sure Linux' brcmfmac will work as well.
<davidrysk[m]>
Tangential to this, one of the main annoyances I've run into is lackluster Linux support for bcm4360, which is widely used in routers and older Macs
<davidrysk[m]>
From the bits and pieces that we know about that chip, it's built of hacks upon hacks
Necrosporus has quit [Read error: Connection reset by peer]
Necrosporus_ has joined #asahi-re
<davidrysk[m]>
okay I think it's highly likely that the only firmware blob that will be needed is the bcm one.
<davidrysk[m]>
I see most of the others that are managed by kexts present in the Preboot volume
dgb has joined #asahi-re
<artemist>
That might fit in linux-firmware if we can find another source for it
crabbedhaloablut has joined #asahi-re
bostjan has joined #asahi-re
mogery has quit [Read error: Connection reset by peer]
Simonx22 has joined #asahi-re
HeN has joined #asahi-re
stemnic has joined #asahi-re
jabamin has joined #asahi-re
bostjan has quit [Quit: Leaving]
linkmauve has joined #asahi-re
bostjan has joined #asahi-re
<bostjan>
gpu
<davidrysk[m]>
artemist: it might be difficult to find another source... hm