<Namidairo>
the threshold for when lfs is mandated there is high anyway, >100mb size on individual files
<bastilian>
Hm. I tried the macvdmtool, but I can't seem to be able to get the target to boot into serial, it just boots normally as far as I can see.
<vafanlignarde>
bastilian: see #asahi about 5h30m ago. there's no serial output by default.
<bastilian>
Ah, i missed that part.
<vafanlignarde>
i tried 'macvdmtool serial' with actions 0x206 and 0x304 on an MBA'18 where i had done 'csrutil enable --without nvram;nvram boot-args="-v debug=0x8 serial=1 serialbaud=115200"' (recovery os). nothing showed up on my m1's debug-console. figured it could be worth a try at least. :)
<davidrysk[m]>
vup2: I played with it a little on a MBP '19, the key is wrong
<davidrysk[m]>
unlock key derivation rather
<vafanlignarde>
(https://git.io/JtEHe has a short list of what VDM get action list and actions info report on the apple devices I have)
<vafanlignarde>
davidrysk[m]: sorry for the confusion. i actually ran macvdmtool on the m1 (which was connected to the MBA'18 via cable). but that's interesting, does that mean that it might be possible to get macvdmtool running on non-m1 hardware too?
<davidrysk[m]>
vafanlignarde: I think it might be possible to get it running on T2 hardware. Not sure with what features, and not sure about T1
<davidrysk[m]>
vafanlignarde: when running on the M1, it does successfully reboot the T2 machine
<davidrysk[m]>
vafanlignarde: how are you extracting those actions?
<vafanlignarde>
davidrysk[m]: sounds cool. the reboot action just powers off my MBP'17 and MBA'18 (not sure if they're T1 or T2; neither have touchbar).
<vafanlignarde>
davidrysk[m]: https://git.io/JtBD7 (essentially asahilinux/vdmtool but for an USB-PD trigger device which had an FUSB302 onboard and for which an OSS firmware existed)
<davidrysk[m]>
oh nice. (I don't have a FUSB302)
<vafanlignarde>
i've looked around but I haven't found anything that comes with both an FUSB302 and the Type-C D+/- or SBU1/2 pins broken out.. but at least those USB-PD triggers and type-c breakout boards are easy (albeit slow) to source
rafaelmartins has quit [Ping timeout: 256 seconds]
rafaelmartins has joined #asahi-dev
KindOne has quit [Ping timeout: 272 seconds]
<davidrysk[m]>
yeah I think that's what marcan was wanting to make
<amw>
bastilian: Add image to SW:Linux page - from my github repository - seemed simplest
<vafanlignarde>
davidrysk[m]: returning zero from GetUnlockKey() makes the code print "Unlocking: OK". not sure if that means it does succeed in unlocking it or not.. it however fails to both enter and exit 'DBMa' mode on the MacbookAir8,1. I also tried using the board IDs from https://www.theiphonewiki.com/wiki/T8012 as unlock keys with no success.
<davidrysk[m]>
vafanlignarde: I'll have to mess around with it some more.
<davidrysk[m]>
Turns out I have only one data-capable USB-C cable handy :/
<marcan>
amw: I don't think we want to use git-lfs here
<marcan>
m1n1/kernel builds are what github releases are for
<marcan>
vafanlignarde: I think you might be able to get serial *for the T2* on those macs this way
<marcan>
not for the intel :)
<marcan>
wrong serial port :p
<marcan>
vafanlignarde: zero is locked
<marcan>
if you make the key zero it'll "succeed" in not-unlocking
<marcan>
the code kind of assumes you're trying to actually unlock the thing, not re-lock it :)
<marcan>
try 'CST1'
<davidrysk[m]>
CST1 seems to unlock it once I swap it (char deviceName[5] = "1TSC";)
<davidrysk[m]>
DBMa mode does not seem to work
<marcan>
yeah, I heard that might not work
qyousef has quit [Ping timeout: 256 seconds]
<marcan>
from M1 source to T2 target, you can also try changing the target action to 0x301 (0x1840306 -> 0x1840301 in DoSerial, just the first instance)
<marcan>
we don't know what 301 is, but it smelled like it could be another serial
<marcan>
there is also 303, which is on *both* ports on those. worth trying that one on both ports probably
<davidrysk[m]>
"source" is the machine running macvdmtool?
<marcan>
yes
<davidrysk[m]>
I'm trying T2 source -> M1 target
<marcan>
you might need to undo the old actions first if the "exit conflicting modes" feature gets confused (0x2040306 = unmap)
<davidrysk[m]>
(since I'm more interested in messing with the M1)
<marcan>
yeah I'm talking to vafanlignarde
qyousef has joined #asahi-dev
<davidrysk[m]>
ahh alright
<davidrysk[m]>
sorry :)
<marcan>
yeah sorry, I was replying to two people at once :)
qyousef has quit [Ping timeout: 240 seconds]
qyousef has joined #asahi-dev
dibas has joined #asahi-dev
dibas has joined #asahi-dev
Namidairo has quit [Read error: Connection reset by peer]
Namidairo has joined #asahi-dev
odmir has quit [Remote host closed the connection]
odmir has joined #asahi-dev
odmir has quit [Ping timeout: 240 seconds]
dibas has quit [Remote host closed the connection]
dibas has joined #asahi-dev
dibas has joined #asahi-dev
odmir has joined #asahi-dev
odmir has quit [Ping timeout: 258 seconds]
acelogic has quit [Remote host closed the connection]
acelogic has joined #asahi-dev
awordnot has quit [Ping timeout: 256 seconds]
odmir has joined #asahi-dev
odmir has quit [Ping timeout: 240 seconds]
awordnot has joined #asahi-dev
<amw>
marcan: Just sent you an email about latest m1n1 proxyclient change causing qemu serial port loading failures
acelogic has quit [Remote host closed the connection]
<marcan>
amw: try increasing the uart.timeout = 0.15
<marcan>
I tried to keep that short because otherwise it makes script startup slow and for real hardware it should be enough
<amw>
marcan: I switched the one in the try from 0.15 back to 3 and it seems reliable now
VinDuv has joined #asahi-dev
<amw>
marcan: I dropped it back to 1 and it worked 5 times out of 5
<amw>
marcan: I changed it down to .6 and the first two attempts fail then worked for several in a row
<amw>
More tests had it work 4 times in a row and then fail with proxy.UartCMDError: Reply command mismatch: Expected 0x01aa55ff, got 0x00aa55ff
<amw>
So some where between .6 and 1 for uart.timeout in the try?
<marcan>
seems like qemu is just slow somehow?
<marcan>
maybe the serial/tty code in qemu has some kind of timeout condition?
<amw>
.8 gave 2 failures in about 10+ tries (2 in a row so perhaps one failure led to the next...)
<marcan>
it smells like somewhere along the way there is a polling loop
<amw>
Just got 10 out of 10 at .8 from a fresh qemu start up... Yep better let modcodewiz know
odmir has joined #asahi-dev
odmir has quit [Ping timeout: 240 seconds]
VinDuv has quit [Quit: Leaving.]
amw has quit [Ping timeout: 240 seconds]
sumoon[m] has left #asahi-dev ["User left"]
jn__ has quit [Ping timeout: 272 seconds]
jn__ has joined #asahi-dev
amw has joined #asahi-dev
amw has quit [Quit: WeeChat 2.3]
zkrx has quit [Ping timeout: 240 seconds]
amw has joined #asahi-dev
KindOne has joined #asahi-dev
Mary_ has quit [Quit: Bye!]
zkrx has joined #asahi-dev
Mary_ has joined #asahi-dev
amw has quit [Quit: WeeChat 2.3]
amw has joined #asahi-dev
<vafanlignarde>
marcan: i see, thanks for the clarification. +1 on what davidrysk[m] wrote, return '1TSC' in GetUnlockKey() works on olders Macs (MacBookAir8,1; MacBookPro14,1; iMac19,1), DBMa does not.
<marcan>
yeah, so not very useful without DBMa...
amw has quit [Ping timeout: 258 seconds]
TomJepp has quit [Ping timeout: 272 seconds]
TomJepp has joined #asahi-dev
<bastilian>
Is there a document somewhere describing how to install m1n1? I assume it is, compiling it and configure it as boot via kmutil, or is there more to it?
zkrx has quit [Ping timeout: 256 seconds]
zkrx has joined #asahi-dev
<Glanzmann>
bastilian: If you find it, let me know. I ordered a mac mini m1 in order to try vdmtool. Look forward to try it out.
<bastilian>
Glanzmann: sure. I'm gonna dig into later after work. I guess it should be just that, and probably "blessing" the compiled mach file, but there might be more to it.
<Glanzmann>
I assume so. Same instructions as with corelliumhq but with the m1n1.
<Glanzmann>
It would also be super interesting to have a kernel tree with the correlliumhq drivers. I have not tried them, but according to their twitter post they have most of the essential hardware running (ssd, touchpad, keyboard, network card, wifi).
<j`ey>
Glanzmann: they have their kernel tree on github?
acelogic has joined #asahi-dev
<_jannau_>
https://github.com/corellium/linux-m1 kernel is not compatible with m1ni but requires preloader-m1. works self compiled on a mac mini (my last update was a week ago though)
<Glanzmann>
j`ey: I thought they're no publishing the drivers, don't they?
<Glanzmann>
now*
<j`ey>
Glanzmann: yes, and you can view the source on github ^
<Glanzmann>
So maybe we can do a kernel that is compatible with m1n1 and has all the drivers.
<Glanzmann>
Probably marcan will do that anyway.
<j`ey>
dont think he's interested in their tree/kernel
<marcan>
bastilian: I'm writing something
<bastilian>
marcan: WOOHOOO! Thank you!
<marcan>
I mentioned this on -re already, but the corellium kernel is developed via binary reverse engineering, which means I will not merge anything from it blindly; it needs to be audited since they are not open about their development process and they have not earned my confidence
<marcan>
bbl, got some errands to deal with
odmir has joined #asahi-dev
<modwizcode>
amw: yes I forgot to mention that I have local timeout adjustments (although the linux loader didn't need adjustments). Tbh the adjustments aren't needed at all now that I enable the FIFO by default in qemu and fixed it from being totally broken.
KindOne has quit [Ping timeout: 256 seconds]
<modwizcode>
I'm surprised you had to fuss with it but it's possible I never tested again with the current timeouts, and if it didn't work I'd just rerun the commands
odmir has quit [Remote host closed the connection]
odmir has joined #asahi-dev
<Bluerise>
marcan: how do I change the usb debug command to use a different pinset? 840306 is SBU1/2?
<Bluerise>
Yeah, I saw that, but I didn't see any text telling me which bit is which pinset
<marcan>
1<<pinset
<marcan>
caveat emptor: if you're thinking of using this for serial, note that standard cables crossover SBU1/2 but not D+/D-
<marcan>
so direct serial will only ever work with SBU1/2
<Bluerise>
I have a breakout... but SBU1/2 don't work depending on the orientation of the cable... I'm testing it with ... uhm... you know, connection tester
<marcan>
the orientation of the cable is compensated for on the mac side, but presumably not on your board side
<marcan>
orientation again swaps SBU1/2
<Bluerise>
Well, what I tried was: connecting two breakout boards to the same cable
<Bluerise>
and check if sbu1 on one breakout board connects to sbu2 on the other
<Bluerise>
*sbu1
<marcan>
then yes, flipping either side will flip the connection
<Bluerise>
yeah, but the weird thing is when I flipped it, I only got SBU1 connected, but SBU2 connected nowhere
<marcan>
and the other way you got both?
<Bluerise>
yup
<marcan>
then a cable or connector is dodgy
<Bluerise>
it was a 30-40 euro cable from belkin :P
<Bluerise>
will have a look.
<marcan>
*40* euro cable?
<marcan>
what is it, thunderbolt++?
<davidrysk[m]>
modwizcode: would be worth mentioning which port Apple says is the dfu port since it differs
<Bluerise>
marcan: yes
<Bluerise>
the more expensive, the better, right? ;)
acelogic has quit [Remote host closed the connection]
acelogic has joined #asahi-dev
<davidrysk[m]>
Bluerise: it's complicated :P
<davidrysk[m]>
some of the more expensive thunderbolt cables are active and we don't want that :p
<Bluerise>
Ah, right.
<Bluerise>
Yeah, I have two dumb ones here that should work as well
<Bluerise>
at least I'm rather sure they are dumb, because my employer wouldn't buy good ones :D
<davidrysk[m]>
just make sure they're data and not power-only
<davidrysk[m]>
most of my usbc cables are power-only :(
<Bluerise>
Nah, those have data
<davidrysk[m]>
was trying to do data migration and was frustrated by it heh
<Bluerise>
I once had someone on a discord who went through three power-only microUSB cables
<Bluerise>
the fourth cable he found finally had data. until then he blamed the hw :)
<Bluerise>
hm
<Bluerise>
so either a) 1.8v serial can't read 1.2v serial data
<Bluerise>
b) I already shot my serial port
<Bluerise>
c) the data lines aren't connect properly
<Bluerise>
d) the pinmuxing doesn't fit
<Bluerise>
e) my voltage divider doesn't work he
<Bluerise>
marcan: when I use cu on /dev/tty.debug-console I get "couldn't enable hardwar eflow control"
<Bluerise>
that's why you use picocom?
<Bluerise>
anything special I need to do to make picocom work?
<marcan>
I've only ever used picocom, no idea about anything else
<marcan>
but you don't want hardware flow control
<modwizcode>
marcan: speaking of picocom what omap and imap do you use for that? I always get weird newlines when I throw picocom on the pty for qemu
<Bluerise>
I'm booting a copy of m1n1 you gave me... nothing :(
<Bluerise>
Putting target into serial mode... OK
<Bluerise>
Putting local end into serial mode... OK
<Bluerise>
Exiting DBMa mode... OK
jamadazi has joined #asahi-dev
<marcan>
Bluerise: do the reset serial thing if you want to see debug output
<marcan>
otherwise the timing will be messed up, you will either enable serial after the startup messages are already sent, or before a reset that breaks it
<marcan>
this is with two M1s?
<Bluerise>
m1 air and m1 mini
<Bluerise>
should i see prints frim iboot?
<marcan>
no
<marcan>
just m1n1
<marcan>
make sure you are connecting on the DFU ports
<Bluerise>
ah
<Bluerise>
that works.
<Bluerise>
I see, m1n1 prints something and then goes into proxy mode
<marcan>
yes
<Bluerise>
so there's no prompt, ok
<marcan>
correct
<marcan>
it will reacts to proxy messages
<marcan>
but ignore everything else
<marcan>
there is no CLI for humans, for that you have shell.py :p
<Bluerise>
at least I know I'm still getting output
<Bluerise>
good sign ;)
<marcan>
for the proxyclient, get python3.9 from homebrew
<marcan>
something about readline history is broken in the macos 3.8
<marcan>
then pip3.9 install --user pyserial construct
<Bluerise>
I wonder if my FTDI isn't well enough to recv on 1.2V
<Bluerise>
set to 1.8V, but,.. hm
vimal has quit [Remote host closed the connection]
KindOne has joined #asahi-dev
VinDuv has joined #asahi-dev
taziden has quit [Ping timeout: 272 seconds]
taziden has joined #asahi-dev
<Bluerise>
marcan, kettenis: ok, one reason is that the HW I got cannot cope with 1.2V
<Bluerise>
I'm testing the voltage divider circuit with the mUART + that 1.8V serial I bought
<Bluerise>
if I use the mUART to send 1.8V TX through the voltage divier, the 1.8V serial can't read it
<Bluerise>
if I use the 1.8V serial to send to the mUART, the mUART can read it
<davidrysk[m]>
fwiw I've found homebrew to be full of bugs on M1; if you have it in /usr/local that's the Rosetta version. I switched back to MacPorts.
<Bluerise>
so I guess I have something to send back to Amazon...
<Bluerise>
davidrysk[m]: heh, yes, so far they told everyone to use the rosetta version
<Bluerise>
I'm using the native one
<davidrysk[m]>
I tried it, but it has way more bugs than MacPorts
<davidrysk[m]>
I had both installed for a time but I got tired of dealing with the bugs and just ditched it
zkrx has quit [Ping timeout: 240 seconds]
<marcan>
I'm just using the rosetta version, no issues so far
<marcan>
I just alias x86=arch -x86_64
<marcan>
x86 brew install foo etc
zkrx has joined #asahi-dev
mxw39 has joined #asahi-dev
vimal has joined #asahi-dev
<Bluerise>
marcan: have a solution for the uart. the "bad" 1.8V uart provides 1.8V as reference to the mUART. mUART does TX/RX. That works well
<marcan>
lol
<Bluerise>
unfortunately I only have one uart, but since I have two M1s I'll just ship that muart to kettenis
<Bluerise>
yeah, one usb2serial to provide 1.8V, the other one to do the work lol
<jn__>
with two M1s — is macvdmtool an option?
<j`ey>
jn__: ounds like kettenis doesnt have 2, so theyre getting the muart!
<jn__>
ah, i missed that part of the conversation
<Bluerise>
Yeah, exactly. I have one that I ordered to replace my 12" Macbook, that I use with OSX