marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
amw1 has quit [Ping timeout: 256 seconds]
aratuk has joined #asahi
Bublik has quit [Remote host closed the connection]
aratuk has quit [Ping timeout: 265 seconds]
Bublik has joined #asahi
amw1 has joined #asahi
Bublik has quit [Ping timeout: 256 seconds]
amw1 has quit [Ping timeout: 240 seconds]
<rwhitby>
today I'm going to get the pre and post external boot partition layouts for marcan, and test installation to 128GB USBA flash stick for whoever was asking about that yesterday
Bublik has joined #asahi
Bublik has quit [Ping timeout: 260 seconds]
Bublik has joined #asahi
amw1 has joined #asahi
amw1 has quit [Ping timeout: 256 seconds]
<davidrysk[m]>
it appears that during DFU, macOS sets the passwords of the setup user account _mbsetupuser uniquely which are then used for initial setup... I don't think anyone's dug into how this process works
<davidrysk[m]>
(thanks rwhitby for doing some tests)
Bublik has quit [Ping timeout: 264 seconds]
amw1 has joined #asahi
Bublik has joined #asahi
<rwhitby>
now testing whether you can boot from a setup external disk when the internal disk has been freshly DFU's and not gone through initial setup yet
<rwhitby>
interesting. I'm pretty sure I had the external disk set to reduced security and then DFU'd only the internal disk. I have now booted successfully from the external disk (while the internal disk is freshly DFU'd and no gone through initial setup) and the external disk seems to be set back to full security.
<davidrysk[m]>
I think it's likely that they are
<davidrysk[m]>
if they are, we can read /etc/kcpassword, extract the _mbsetupuser password, "decrypt" it, and then use that for bputil
amw1 has quit [Ping timeout: 240 seconds]
<davidrysk[m]>
<rwhitby "interesting. I'm pretty sure I "> hm, I wonder if DFU resets the SEP state in some way
<davidrysk[m]>
(e.g. breaking all signatures)
<rwhitby>
I'm going to check the external disk state in 1TR and then go through the whole process again to confirn what I saw.
<davidrysk[m]>
rwhitby: does that change if you boot (2) once?
<rwhitby>
(2) has already been booted many times
<davidrysk[m]>
after DFU?
<rwhitby>
(including just before I did this, yes)
<davidrysk[m]>
grr, interesting
<davidrysk[m]>
we're basically mapping out all the edge cases that Apple didn't test
<davidrysk[m]>
which means we probably should be writing them up to report to Apple as bugs
<davidrysk[m]>
does bputil let you set full/reduced/permissive security on that installation?
Bublik has joined #asahi
<rwhitby>
it did before I DFU'd the internal disk, and the external disk was disconnected during the DFU
<rwhitby>
going to go through this again from scratch, installing to a USBA flash stick external this time, then reducing it's security, then DFUing the internal drive and seeing what the security on the external drive ends up as.
Bublik has quit [Ping timeout: 246 seconds]
Bublik has joined #asahi
<rwhitby>
installation to USBA 126GB Sandisk Ultra seems to be proceeding fine. Didn't have a 64GB handy to test whether that would be big enough.
<rwhitby>
s/126GB/128GB/
jamadazi has quit [Ping timeout: 260 seconds]
Bublik has quit [Ping timeout: 246 seconds]
Bublik has joined #asahi
mark21 has joined #asahi
amw1 has joined #asahi
Bublik has quit [Ping timeout: 264 seconds]
mark21 has quit [Quit: Connection closed]
amw1 has quit [Ping timeout: 240 seconds]
czero64 has joined #asahi
Bublik has joined #asahi
amw1 has joined #asahi
dibas has quit [Ping timeout: 260 seconds]
mrksz has quit [Ping timeout: 264 seconds]
amw1 has quit [Ping timeout: 246 seconds]
czero64 has quit [Ping timeout: 256 seconds]
<davidrysk[m]>
rwhitby: nice
amw1 has joined #asahi
shuffle2 has quit [Quit: WeeChat 2.9]
amw1 has quit [Ping timeout: 240 seconds]
<Shiz>
rwhitby: this makes complete sense, the policies are stored on the internal disk after all
<Shiz>
no policies to display if they've been wiped
<rwhitby>
is there an easy way to fingerprint the internal disk before and after changing the security on an external disk to see the difference?
<Shiz>
I'd expect the iSCPreboot partition to change and not much else
<Shiz>
(where the policy is stored)
<Shiz>
what are you looking to know :p
Bublik has quit [Ping timeout: 256 seconds]
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rwhitby>
marcan asked me to take an internal disk partition map before and after booting an external drive. I didn't see any new partitions or volumes.
<rwhitby>
so next step is to compare iSCPreboot before and after
<Shiz>
ah right, /me more awake now
<Shiz>
yeah so comparing the internal & external policies would be interesting
<Shiz>
as well as the Preboot partition of the internal macOS install
<Shiz>
(note that they contain your ECID and such)
<rwhitby>
my ECID is already public :-)
<rwhitby>
but point taken, thanks.
amw1 has joined #asahi
Bublik has joined #asahi
amw1 has quit [Ping timeout: 260 seconds]
amw1 has joined #asahi
amw1 has quit [Ping timeout: 246 seconds]
mrksz has joined #asahi
<rwhitby>
USBA external flash stick install stuck at 2 minutes remaining for some time now. will cancel and try it again tonight. last message from osinstallersetupd in the last was 15 minutes ago marking 93.9%
<rwhitby>
s/in the last/in the log/
dibas has joined #asahi
dibas has joined #asahi
<rwhitby>
so back to external disk security. Boot to 1TR, set Security Policy on external disk to Reduced+kext using the Startup Security Utility.
<rwhitby>
(this is with a freshly DFU'd internal disk still)
<rwhitby>
"Recovery is trying to change system settings. No administrator was found." Unable to change security settings.
<rwhitby>
FYI: scp from 1TR to another machine works well for transferring information
<rwhitby>
(thx davidrysk[m] for the tip)
<davidrysk[m]>
rwhitby: can you look for a /etc/kcpassword file on the macOS partition of a fresh DFU'd Mac?
<rwhitby>
yep, will do so after I finish initial setup of this internal disk, then reducing the external disk security, then DFUing internal disk again
<brentr123[m]>
This might sounda kinda dumb, but can we just back 1tr so we can do whatever tf we want to it
<brentr123[m]>
*hack
<Shiz>
no
<Shiz>
it's signed and only runs signed code
<Shiz>
if it was hackable it would lose its entire purpose as a controlled environment for more privileged SEP access
amw1 has joined #asahi
<Shiz>
not saying 1TR is flawless, but you bet if you exploited a vuln in 1TR to run unsigned code apple would have it patched before you can blink :p
<Shiz>
so it's an unstable strategy to begin with
<Shiz>
rwhitby: but how are you booting to 1TR if the internal disk is wiped
<Shiz>
or is this post-revival
<rwhitby>
I think many people involved in this project are well past playing cat and mouse with vendors
<rwhitby>
Shiz: oh, I haven't wiped anything yet, I've only been doing DFU full restores.
<rwhitby>
so 1TR is always there for what I'm doing at the moment. I do intend to do a full wipe at some stage to really test the DFU
amw1 has quit [Ping timeout: 246 seconds]
<rwhitby>
interesting. I went through internal disk initial macOS setup, and then back into 1TR and I still can set security on external disk
<rwhitby>
s/still can/still can't/
<rwhitby>
hmm, now trying to set boot from external disk as startup disk in 1TR and it asks for admin password
<davidrysk[m]>
It's better to figure out what functionality is missing from 1TR and asking Apple to add it
<rwhitby>
but setting reduced security on external disk with bputil on command line is fine (it asks for password)
<rwhitby>
Reduced Security enabled (smb0): 1
<rwhitby>
so external disk is clearly marked as reduced security in 1TR
<rwhitby>
But boot that external drive and look in System Information->Hardware->Controller says Secure Boot: Full Security
<rwhitby>
so that's inconsistent with what 1TR reported
amw1 has joined #asahi
amw1 has quit [Ping timeout: 240 seconds]
<rwhitby>
gonna DFU and wipe external disk and start again fresh
<rwhitby>
davidrysk[m]: I now have a freshly DFU'd internal drive and a freshly installed external drive. What information do you want before I start testing the security setting stickiness again?
<davidrysk[m]>
can you look if there is a file called /etc/kcpassword on the macOS partition?
<davidrysk[m]>
9
<davidrysk[m]>
(don't send me the contents)
amw1 has quit [Ping timeout: 246 seconds]
<rwhitby>
davidrysk[m]: there is no /etc/kcpasswd in 1TR on the DFU'd internal drive, nor in the internal OS drive after DFU but before initial setup.
<davidrysk[m]>
huh, then I sure wonder where the OS is getting the autologin password for initial setup
<rwhitby>
First test: can you boot an external drive before the internal drive has gone through initial setup (i.e. when there's no administrator password set anywhere)
<rwhitby>
weird: bputil -d reports info for the external drive, but not the internal drive
<rwhitby>
bputil -d then select internal drive installation reports "Could not detect whether selected local policy was BAA signed. Failed to obtain values from the current local policy."
<rwhitby>
bputil -d then select external drive shows the normal current local policy details
<rwhitby>
Removing external drive to ensure the mapping is correct confirms that internal drive cannot detect the local policy. Note that neither the internal or external drive have gone through initial macOS setup yet. Internal drive is fresh DFU restore and external drive is fresh macOS reinstall.
amw1 has joined #asahi
amw1 has quit [Ping timeout: 256 seconds]
porky has joined #asahi
<rwhitby>
Startup Security Utility is unable to modify either internal or external disk.
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hspak has quit [Quit: Ping timeout (120 seconds)]
hspak has joined #asahi
<rwhitby>
(bputil can't set either as well, since we don't know the password for _mbsetupuser)
Tokamak has quit [Remote host closed the connection]
Tokamak has joined #asahi
<rwhitby>
Confirmed ability to boot and run initial macOS setup on external drive even when internal drive has not yet gone through initial macOS setup.
<marcan>
this is how it is supposed to work I believe; you need a user on the drive to use bputil
<rwhitby>
So now I have a user on the external drive, but not on the internal drive. Let's see what 1TR can do with that ...
Tokamak has quit [Ping timeout: 264 seconds]
<rwhitby>
Next test: 1TR with only internal drive and external drive disconnected - still can't do anything with bputil as expected, so adding a user to the external drive didn't create a user on the internal drive.
amw1 has joined #asahi
<rwhitby>
marcan: what's strange is that bputil -d was able to display the policy for the external drive before the external drive had a user, but couldn't do the same for the internal drive
<marcan>
was the internal drive ever booted?
<marcan>
(and the external drive?)
Tokamak has joined #asahi
<rwhitby>
internal drive has not gone through initial setup. external drive has.
<rwhitby>
actually, that was the case even when neither had gone through initial setup
<rwhitby>
and both wanted _mpsetupuser credentials to change security.
<rwhitby>
but that was good enough to display the external, but not to display the internal.
amw1 has quit [Ping timeout: 264 seconds]
<rwhitby>
Next interesting thing: internal is fresh DFU restore, not gone through initial setup, so has no admin user. external has gone through initial setup, has a known admin username and password (verified by logging into external drive using that). back into 1TR and bputil does not accept the external drive's username and password as valid.
<marcan>
yeah I saw that coming
<marcan>
pretty sure that's a bug
<rwhitby>
"Failed to create ACM context with provided username and password"
<marcan>
booting "foreign" OSes like that is kind of broken
<marcan>
(and by DFU restoring you made it foreign)
<marcan>
there should be other problems with that external OS
<rwhitby>
So the next test is to see what happens if I go through initial setup on the internal OS, does that repair things for the external drive?
<marcan>
unlikely
<rwhitby>
So that would mean the external drive is not useable on another machine?
<rwhitby>
An installation of macOS on an external drive is tied to the host on which it was created, and becomes invalid if that host is restored?
<marcan>
right now, yeah
<marcan>
I assume they intend for this to work at some point
<marcan>
but right now it's kinda broken
<marcan>
if they fix it though, we can take advantage of that support in principle for our install flow
<rwhitby>
yeah, that's why I was testing it
mrksz has quit [Ping timeout: 240 seconds]
<rwhitby>
Logged into internal disk and did initial setup, so it now has an admin user. Back to 1TR. bputil -d can now display internal disk, but can no longer display external disk (where as this was reversed previously before the internal drive went through initial setup).
amw1 has joined #asahi
<rwhitby>
bputil can change internal drive but still does not accept valid password for external drive.
mrksz has joined #asahi
<rwhitby>
And now booting the external drive asks for an admin password, whereas it did not previously.
<rwhitby>
which indicates that it wants to write something to the internal disk
amw1 has quit [Ping timeout: 260 seconds]
<rwhitby>
bputil mounts disk3s3 when changing security, so it's likely writing there?
<rwhitby>
disk3s3 is the Recovery volume
<rwhitby>
is there a way to identify which volume is having files modified in it selecting the external disk for boot (and needing to enter admin password to do so) ?
<rwhitby>
BTW, "df" also shows the volumes hidden in 1TR by diskutil
<rwhitby>
Here's the test I did: run "df" before selecting another boot disk. scp that file to safety. select another boot disk. hold power in during the restart to get back to 1TR. run "df" again, and compare with before
<rwhitby>
I see an extra inode in iSCPreboot. xarts, Hardware, Preboot all have the same number of inodes as before.
<rwhitby>
So, another DFU restore and this time I'll capture the full contents of iSCPreboot before and after.
amw1 has joined #asahi
amw1 has quit [Ping timeout: 240 seconds]
<marcan>
iSCPreboot should have one file per boot policy (you can see the files, the paths are really obvious)
<marcan>
but other than that there should be some kind of blatant copying of stuff (iBoot etc) into *somewhere* on SSD when you boot from an external disk
addcninblue has joined #asahi
ransom has joined #asahi
justMaku has quit [Remote host closed the connection]
q3k|m has quit [Remote host closed the connection]
amw1 has joined #asahi
Empus has joined #asahi
amw1 has quit [Ping timeout: 264 seconds]
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amw1 has joined #asahi
amw1 has quit [Ping timeout: 256 seconds]
<rwhitby>
Looks like iSCPreboot is the place. New UUID directory inside there for the external disk
<rwhitby>
another DFU restore and this time I'll tarball before and after (should have done that from the start)
Tokamak has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rwhitby>
and I'll use dummy username and password so I can share the tarballs with those who can make use of them
amw1 has joined #asahi
amw1 has quit [Ping timeout: 260 seconds]
klaus_ has joined #asahi
addcninblue has quit [Ping timeout: 240 seconds]
addcninblue has joined #asahi
amw1 has joined #asahi
amw1 has quit [Ping timeout: 246 seconds]
aratuk has joined #asahi
aratuk has quit [Ping timeout: 264 seconds]
<rwhitby>
Yep, looks like enough stuff to boot the external drive is cached in iSCPreboot/<UUID>/boot ...
jaXvi has joined #asahi
addcninblue has quit [Ping timeout: 260 seconds]
raster has joined #asahi
<marcan>
cool
<marcan>
so this actually tells us something more: if we wanted a linux-only machine with the minimum garbage, we could probably just copy our boot files to iSCPreboot and ditch the entire second APFS container
<marcan>
it also tells us exactly what files are needed by iBoot - just the boot subdirectory
<marcan>
everything else is needed only by the graphical boot picker in 1TR and other tooling
<marcan>
so now there's one more thing to investigate that I'm curious about: where is the currently selected boot volume stored?
<marcan>
is it flags in the localpolicy files, or something higher level?
<rwhitby>
there was an "active" flag file in there
<rwhitby>
ok, I'm going to install on a flash stick, and then I can investigate how the current boot target is chosen by comparing iscPreboot with different targets selected
<rwhitby>
(and test this USBA not working rumour at the same time)
<rwhitby>
it's interesting that a complete macOS restore via DFU is much much faster than the "reinstall macOS" option in the recovery chooser
* rwhitby
bbl ~2h
amw1 has joined #asahi
lewurm has joined #asahi
<Shiz>
marcan: as per SW:Boot, localpolicy is selected *after* the boot volume is chosen
<Shiz>
because the boot volume vgid is part of the localpolicy path
<Shiz>
:p
<Shiz>
my guess is 'nvram, somehow'
<Shiz>
oh right, by flags you mean it'd iterate over every file?
<Shiz>
I don't think so, it does get the current local policy hash from the SEP without vgid input
<Shiz>
it might just iterate all directories looking for the local policy file with that hash
<Shiz>
there was some opaque iboot-related blob in nvram that i wonder is related
<marcan>
btw, has anyone noticed stuff connected to their USB A ports dying?
<marcan>
I've had my keyboard stop working on macos until a reboot several times now
<marcan>
(on the mini)
<marcan>
no log entries on connect/disconnect
<robinp>
I had issues with my Apple A1243 keyboard - I now have it connected via a USB3 dock and its been fine
<robinp>
it wouldn't get power (i.e. caps lock wouldn't turn on and off)
<Shiz>
no issues here yet
<marcan>
robinp: that's not no power, keyboard do not toggle LEDs autonomously
<marcan>
my ThinkPad keyboard doesn't even turn on its power LED until it enumerates
<marcan>
so probably the same issue I have
<marcan>
PSA: we have added some sections to the copyright/re policy at: https://alx.sh/re
<marcan>
1) we are banning GPU userspace stack binary reverse engineering, because it doesn't seem like that will be necessary, and therefore the risks are not worth it
<marcan>
2) we're treating possibly-RE'd code (i.e. anything that deals with undocumented apple hardware/formats) as if it were license-incompatible, because effectively we cannot trust that it is *policy*-compatible
<marcan>
you can use it, you can look at it, but you can't combine it with our own repos/merge the code
<marcan>
I do no expect this to be a significant limitation, exceptions will be asessed on a case by case basis
<marcan>
(not stated, but obviously if you come across that looks like it is *obvious* decompilation/disassembly output, that is as good as looking at the binaries and that part of the policy applies, i.e. stop looking at it; this deals with code that isn't *obviously* decompiled but could plausibly be the product of such due to circumstances)
<CDFH>
Thanks for that, especially the paragraph labelled important in the second to last section
<marcan>
we've had that since the beginning (though we just removed #asahi-gpu from that list given 1) above)
<CDFH>
Makes sense :) just want to be sure I'm in the clear and that clears it up I think
amw1 has quit [Ping timeout: 256 seconds]
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #asahi
<rwhitby>
Looks like there is indeed an issue installing to a flash stick. It seems to complete (the last 1% takes forever), but when it restarts to boot the flash stick it says "The versin of macOS on the selected disk needs to be reinstalled."
<rwhitby>
And trying to select the flash stick as the startup disk results in "Unable to set startup disk" (SDErrorDomain error 104)
<Shiz>
do we know where nvram comes from/is stored in the m1?
<Shiz>
for iphones it's in the NOR apparently
<davidrysk[m]>
we don't... we can use the nvram command to read/write it
<davidrysk[m]>
on Intel Macs it's in the same chip as the EFI (which is a serial EEPROM/flash)
<davidrysk[m]>
there is a `boot-info-payload` key in the nvram
<davidrysk[m]>
before posting nvram dumps — note that they contain wifi network data
<davidrysk[m]>
so you may want to redact that for your privacy
<Shiz>
yah, I alluded to that key above :p
<Shiz>
it seems to be high-entropy binary tho
<Shiz>
there's also a boot-volume nvram variable, but i'm not sure if that's *set* or *used* by iBoot
<Shiz>
if it's only used, that might be how iBoot decides which volume to boot form
<Shiz>
--setBoot Set the system to boot off the specified partition. This is implemented in a platform-specific manner. On Open Firmware-based systems, the boot-device variable is modified. On EFI-
<Shiz>
based systems, the efi-boot-device variable is changed. This is not supported on Apple Silicon based systems.
<Shiz>
hmm.
klaus_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Shiz>
okay, figured out the structure
<Shiz>
boot-volume is in the format <efi-partition-type-uuid>:<partition-uuid>:<volume-group-uuid>
<Shiz>
ecept the partition UUID is mangled and the first 3 components are byteswapped?
HeN has quit [Quit: Connection closed for inactivity]
Tokamak has joined #asahi
<Shiz>
okay, setting nvram auto-boot to false gives you a nice "cant boot, visit apple.com/restore" prompt on boot :)
<Shiz>
can still boot into 1TR
<davidrysk[m]>
there has to be some way they set it for repairs
lothwen has joined #asahi
<Shiz>
also, fun fact, you can't write to boot-volume, even from 1TR
<Shiz>
maybe something special needs to be done?
jamadazi has quit [Quit: WeeChat 3.0]
klaus_ has joined #asahi
aratuk has joined #asahi
<Shiz>
ah, the nvram is inside the NOR according ot the device tree
<Shiz>
that, firmware and syscfg
<Shiz>
so right now my guess is stage1 iboot reads boot-volume from nvram and goes from there
aratuk has quit [Ping timeout: 264 seconds]
ransom has joined #asahi
frode_0xa has joined #asahi
ransom_ has joined #asahi
ransom has quit [Ping timeout: 272 seconds]
<marcan>
yeah, that would make sense
ransom has joined #asahi
modwizcode has joined #asahi
ransom_ has quit [Ping timeout: 256 seconds]
mogeryy has joined #asahi
mogery has quit [Ping timeout: 260 seconds]
plainbits has joined #asahi
addcninblue has joined #asahi
lothwen has quit [Quit: Leaving]
frode_0xa has quit [Quit: leaving]
plainbits has quit [Quit: Bye!]
HeN has joined #asahi
aratuk has joined #asahi
aratuk has quit [Ping timeout: 256 seconds]
ephe_meral has quit [Ping timeout: 240 seconds]
tiagom has joined #asahi
djb has joined #asahi
ky0ko has joined #asahi
saaam has quit [Remote host closed the connection]
tiagom has quit [Quit: tiagom]
tiagom has joined #asahi
HoneyTubes has quit [Read error: Connection reset by peer]
HoneyTubes has joined #asahi
AgentPurple[m] has joined #asahi
ephe_meral has joined #asahi
ephe_meral has quit [Ping timeout: 272 seconds]
HoneyTubes has quit [Quit: Quit]
nyx_o has joined #asahi
mogeryy has quit [Quit: Leaving]
wolf511[m] has joined #asahi
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #asahi
<eta>
Shiz: apple.com/restore doesn't go anywhere
<Shiz>
i typed the url from the top of my head, it was possibly not exactly that
<Shiz>
i wonder what's up with xnu's latest version number
<Shiz>
xnu-7195.50.7.100.1
<Shiz>
5 components?
<j`ey>
i assume it;s just random
<j`ey>
to annoy us :P
djb has quit [Ping timeout: 256 seconds]
<marcan>
rwhitby: so I just realized I'm an idiot
<marcan>
of course the PD link / serial stuff goes down on reboot
<marcan>
I've been playing UFP all along
<marcan>
I should've been playing DFP
<marcan>
this thing's a *device* until the OS decides it's time to turn on all the dual role negotiation machinery
<marcan>
(e.g. DFU mode needs to work, so the Mac needs to default to UFP when the main CPU is not up yet)
<marcan>
I can confirm there's something alive when I switch to DFP role, though right now all I'm seeing is HARDRESETs
<marcan>
rwhitby: I need to get some sleep, but if you have some time, can you try putting it into DFU mode (power it down, unplug it, hold down the power button and plug it in; LED should be orange) and seeing if it'll negotiate a PD contract with another Mac / a source / something, and get me a trace?
aratuk has joined #asahi
djb has joined #asahi
aratuk has quit [Ping timeout: 240 seconds]
guillaume_ has joined #asahi
guillaume_ has quit [Client Quit]
tiagom has quit [Quit: tiagom]
<rwhitby>
marcan: yes, for dead battery support reasons a macbook will always be a sink/UFP in this type of situation.
<rwhitby>
marcan: I assume you just want a simple PD contract trace so you can fake being a DFP/source with vdmtool?
<rwhitby>
Note that there are timing constraints that need to be met, otherwise you'll end up with hard reset loops. A source needs to send source caps within a certain time or else the sink will hard reset it. If a sink responds with GoodCRC to a source caps, then it needs to send a request within a certain time or else the source will hard reset it. Getting to a stable contract requires both these conditions being met or else you'll end up in a hard
<rwhitby>
reset loop.
<rwhitby>
This is never an issue when you have a PD controller at each end. But if you're doing this with a bare PHY and vdmtool driving it, then vdmtool will need to do this stuff.
<rwhitby>
marcan: see PM for trace upload
<rwhitby>
A M1 Mini in DFU mode will negotiate a full PD contract on both ports. On the DFU port it will stop before entering an alternate mode, and does not advertise TBT3 support. On the other port, it will enter Thunderbolt mode but not engage in LSTX/RX side band data path negotiation.