aratuk has quit [Remote host closed the connection]
ceph3us has quit [Ping timeout: 245 seconds]
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
<rwhitby>
https://mrcn.st/p/YjUy8ROY - I see the CD3217 USB-PD controller in there as i2c0 with the expected I2C addresses of 0x38 and 0x3F for the two ports.
<rwhitby>
Should be able to talk the TI host interface protocol through that I2C bus.
<davidrysk[m]>
I don't see a CD3217 on the MBP
<davidrysk[m]>
nvm I do :)
<rwhitby>
we think it may be the same as the TPS65987, so I expect the same host interface will work to talk to it
<marcan>
puhitaku: that was already the plan, shhh, don't spoil it
<marcan>
rwhitby: keep in mind the TPS65987 has a different package (which I noticed yesterday), so I'm not so sure any more
<marcan>
could just be a package difference but that feels odd
<marcan>
so it could also be an actual apple custom part
<marcan>
but probably based on the same platform, assuming that's ace2
<marcan>
anyway, off to sleep :)
<marcan>
I started writing a hardware wiki page at some point and apparently screwed up and closed the tab
<Shiz>
aw
<Shiz>
i've been looking at how bputil and the Preboot partition interact
<marcan>
bputil does.... lots of things
<marcan>
run it with debugging
jrmuizel[m] has joined #asahi-re
<Shiz>
i already got to the point that most of the cool stuff is in libbootpolicy.dylib
<Shiz>
which is in a dyld shared cache
<Shiz>
hence the big sur remark ^ above :p
<marcan>
right :)
<Shiz>
i might submit it to that repo but it's honestly as much as a hackjob as the pre-big sur extractor
<Shiz>
just modified apple sources to build on non-internal SDKs
<Shiz>
(by that repo i mean the one for the other pre-big sur extractor, fwiw)
<Shiz>
anyway, at least it's fairly obvious that the actual img4 files are in <preboot>/$VolID/boot/$NextStageHash (as per variables output by bputil) :p
<marcan>
yeah
<marcan>
ideally I want to find some way of dual booting without too much fuss
<marcan>
one warning, not sure if you saw this earlier: shrinking the macos partition and creating a linux partition after that breaks recovery (but not macos!)
<marcan>
deleting the linux partition (leaving free space) fixes it
<Shiz>
ouch, fun
<marcan>
the APFS partitions seem to have some references to partition numbers for recovery/etc judging by diskutil output
<marcan>
but it's all really unclear
<Shiz>
might take a peek later
<Shiz>
something that stood out to me from bputil was
<Shiz>
CustomKC or fuOS Image4 hash (coih): absent
<Shiz>
wonder what fuOS is
<marcan>
same
<marcan>
I saw that
<marcan>
anyway, nn :)
<Shiz>
sleep tight!
<Shiz>
I do appreciate how bputil states "It should only be used to understand how the security of Apple Silicon Macs works." :eyes:
<davidrysk[m]>
marcan: what if you relocate the recovery partition to be immediately after the macOS partition?
<davidrysk[m]>
and put the Linux partition after the recovery partition
<sven>
hrm, i remember reading somewhere that fuOS = fully untrusted OS but i can't find it anymore
<davidrysk[m]>
That's also concerning because it might mean you need a minimal macOS partition for recovery to work
<davidrysk[m]>
or an empty partition in that slot
<davidrysk[m]>
someone who has two Macs and is willing to potentially brick (and need to DFU) their M1 Mac could try
bear24rw has quit [Remote host closed the connection]
bear24rw has joined #asahi-re
stormclad has joined #asahi-re
bear24rw has quit [Remote host closed the connection]
diz3y has joined #asahi-re
diz3y_ has quit [Ping timeout: 264 seconds]
bear24rw has joined #asahi-re
<Shiz>
libbootpolicy.dylib seems to have some necessary functions to enroll custom stuff