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
czero64 has quit [Quit: Session terminated!]
TheLink has joined #asahi
aratuk has joined #asahi
aratuk has quit [Ping timeout: 264 seconds]
ransom has joined #asahi
botoxparty[m] has joined #asahi
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
djb has quit [Ping timeout: 256 seconds]
klaus_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
hspak has quit [Ping timeout: 240 seconds]
ransom_ has joined #asahi
ransom_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
aratuk has joined #asahi
aratuk has quit [Ping timeout: 265 seconds]
<marcan>
rwhitby: this is a mac mini :) and yes, I was sending source caps, but I get the feeling something's broken
<marcan>
thanks for the trace!
<rwhitby>
I'm around if you've got any questions about it.
<marcan>
(not the NOR flash btw, connected to the M1 DFU USB device port and other miscellanea)
<rwhitby>
marcan: I've also been looking around to see if there are any off the shelf boards which could be used for PD hacking
<rwhitby>
(yeah, but eventually through all those things to the NOR flash?)
<marcan>
there are some FUSB302 breakout boards, but I skipped them because they don't quiet do what I want
<marcan>
and yeah sure, through the M1, but all ports go to the M1 in *some* way :)
<TheJollyRoger>
Go team, go!
<marcan>
just only one goes to the M1 in the DFU way
<marcan>
(the challenge is getting it to print Win!)
ransom has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<rootspring[m]>
Have u done a python crackme?
<marcan>
don't remember!
<marcan>
I've made too many of these :)
<rootspring[m]>
Yeah bc sed and asm/c/c++ are alien to me
<foxlet>
Are the plans only to support Arch for now?
<marcan>
you can install any distro you want, you'll just have to do the install/patching manually unless someone else has done it for that distro
<marcan>
(until things go through the pipeline enough to be usable, which could take a couple years)
<marcan>
(depends on the distro :))
<davidrysk[m]>
I expect people to repackage the kernel and tools for other rolling-release and bleeding-edge distros... once that point is reached
<marcan>
yeah, I fully expect someone to step up to run a ubuntu PPA or a debian repo or whatever
<marcan>
I'm just not personally planning to do it myself (until I run out of more pressing things to work on)
<artemist>
I wouldn't be surprised if Manjaro nicely packages it once it's ready
<foxlet>
I was looking at it from a maintainer perspective, but that makes sense.
<marcan>
as a project everything we're doing will be open repos and eventually upstreamed patches
<marcan>
so any distro is welcome to take our forks/patches/code at any time and package it however they want
<davidrysk[m]>
it might be a while before stuff is upstreamed to the main linux upstream though, depending on the extent of the changes
<marcan>
yes, with these things it's always a few years before pure upstream is usable, until then you use patches/forks
<foxlet>
At least in my case (Void) there's system-specific metapackages that allow for 3rd party kernel.
<artemist>
You'll need at least a 3rd party kernel, bootloader, and mesa
<marcan>
I know the distro packaging struggle, so if we have buildsystem issues in any of our own packages I'll happily take patches to make maintainers' lives easier
<davidrysk[m]>
and probably some platform tools
<marcan>
yup
<davidrysk[m]>
and you might want an apfs filesystem module for convenience
<foxlet>
I thought the only complete implementations were non-free?
<davidrysk[m]>
https://github.com/linux-apfs but stability may be a problem and it will not be a focus of this project :)
Tokamak_ has joined #asahi
<marcan>
it's easy enough to make an ext4 partition that I doubt people will have much reason to run linux on APFS, and I also don't intend to put it in our bootloader, and we can't replace the bootloader from linux for security reasons... so the only real reason to run APFS as far as I can see would be to implement SEP storage, which we might some day
<artemist>
I believe corellium has an APFS driver but it's a little legally dubious
<marcan>
that implementation is probably good enough for that
<marcan>
corellium uses *that* APFS driver
<davidrysk[m]>
artemist: corellium is distributing the one above
<marcan>
I found out the other day
<artemist>
Oh, interesting
<davidrysk[m]>
yeah ^
<marcan>
corellium's dump is terribad, it's one commit so you have no idea where anything came from
<marcan>
but at least the APFS bits we know the origin for
<marcan>
I could probably get *some* linux up and running really quickly based on that dump... but that feels like a waste of time because I'd have to go through and pick out bits and pieces and review everything *anyway* before it's clean
<marcan>
so I probably won't do that, and instead will just use it as a reference and rewrite things
<foxlet>
I guess the only real component that would be different is first-time bootstrapping from macOS. Users are kinda used to disc images.
<marcan>
I don't know why people do this
<marcan>
foxlet: yeah, it has to be a curl|sh thing or equivalent
<davidrysk[m]>
generally for anticompetitive reasons
<marcan>
some script you run from Terminal in 1TR most likely
<davidrysk[m]>
since they have to follow the letter of the GPL
<foxlet>
Offline tarball support would probably be a good idea, because I can imagine all the issues being posted about slow/broken internet.
<marcan>
well, broken internet isn't happening anyway
<marcan>
the process requires phoning home to apple at this point
<marcan>
but we can help with slow internet
<foxlet>
Yeah, the concern is more on a multi-gig userland. I don't have that problem, but it comes up fairly often.
<marcan>
yeah
<marcan>
it looks like right *now* the process is also going to require installing macOS itself first (10+GB) but I expect to find ways to make it work without that in the future
<marcan>
as in, another copy of macOS
<marcan>
hopefully it won't be that way by the time this is usable by end-users
<foxlet>
At least they can complain at Apple for that :)
<marcan>
:)
<davidrysk[m]>
Apple really rushed out the M1 Macs :)
addcninblue has quit [Ping timeout: 264 seconds]
<davidrysk[m]>
So many edge case bugs
<marcan>
yeah, they nailed the PR on the whole thing, but as you dig through you can tell this was a massively rushed project
<artemist>
They didn't even launch 10gbe with the rest. It's literally in their device tree
furkan has joined #asahi
<davidrysk[m]>
The good thing I guess is that the rough edges seem pretty much all fixable with patches
<davidrysk[m]>
And yeah they even shipped a day 0 patch (macOS 11.0.1)
<marcan>
rwhitby: ok, yeah, my problem was not controlling VBUS properly. I thought I could get away without that, clearly I can't :)
<marcan>
thankfully an arduino digital output pin is good enough a "vbus" for a mac mini that doesn't try to power anything off of that anyway
<rwhitby>
yeah, the sink won't connect without seeing vbus
<marcan>
oh I was giving it vbus
<marcan>
just manually
<rwhitby>
ah, it won't connect if vbus is there before it connects, and then it won't stay connected if vbus doesn't come soon after it connects :-)
<marcan>
but it seems it really wants to see vbus go down and back up on HARDRESET and then a SOURCE_CAP soon thereafter
<rwhitby>
yep, if the sink is USB-C connected (Rp/Rd) then it needs to see a source cap within a timeout, else it sends hard reset.
<rwhitby>
and hard reset needs at least a 0.6s VBUS at 0v
<marcan>
huh, that much eh
<marcan>
I was giving it 100ms and it seemed to be enough
<rwhitby>
yeah, sink is probably not going to care too much. tSrcRecover in the spec is min 0.66s
<rwhitby>
you need to drop vconn too, otherwise cable markers (especially active cables) can get confused
<rwhitby>
but in this case you're probably not driving vconn anyway, and don't need to if you stick to passive cables
<rwhitby>
In general, I use an interposer which has high speed lanes pass-through (rated to 40Gb/s) and control signals (CC1/CC2/VBUS/GND/SBU1/SBU2) tapped off to a side connector for monitoring or control. Unfortunately it's not commercially available.
aratuk has joined #asahi
aratuk has quit [Ping timeout: 256 seconds]
frode_oxa has joined #asahi
frode_oxa has quit [Client Quit]
frode_0xa has joined #asahi
Tokamak_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
frode_0xa has quit [Remote host closed the connection]
<marcan>
rwhitby: so it seems to be ignoring my VDM stuff when in this mode, I wonder if I need to actually negotiate the mode (when I was playing UFP I didn't have to)
<marcan>
let's see
<rwhitby>
I can test that out here too
<rwhitby>
I just need to finish doing my actual real job with the M1 mini first :-)
<marcan>
>VDM 5ACA003
<marcan>
<VDM RX SOP (2) [284F] 5AC8043 2
<marcan>
ok, so it liked that at least
<rwhitby>
that's just the normal SOP Discover Modes ?
<marcan>
yeah
<marcan>
but it ignores my DEBUG stuff
<marcan>
hm
<marcan>
wait, I have an idea
<marcan>
HAHA
<marcan>
okay
<rwhitby>
give me half an hour and I can get on a zoom or something if you want another set of eyes.
<marcan>
it works
<rwhitby>
ah, cool.
<marcan>
it's SOP'DEBUG when you're UFP, and SOP"DEBUG when you're DFP
<marcan>
:-)
<rwhitby>
ah, that explains why when i was testing it on the Intel MBP I needed to use SOP'' and it was different to your doco.
<rwhitby>
cause I was doing it as DFP
<rwhitby>
s/SOP''/SOP''DEBUG/
<marcan>
(am I weird for spelling it " in text? I know it's '' on proportional fonts but " looks so much better on a terminal :))
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan>
oh, TP5/6
<marcan>
yeah, that's helpful then
<marcan>
but not D+/D- :)
Denshi[m] has left #asahi ["User left"]
<marcan>
oh but that is passed through to microusb?
<marcan>
or am I confused?
<marcan>
ah, it is
<marcan>
yeah, then that would work as one component in the rig
klaus has joined #asahi
Necrosporus has joined #asahi
<rwhitby>
I can't tell whether you can purchase an assembled board from that site.
raster has quit [Read error: Connection reset by peer]
raster has joined #asahi
amw1 has joined #asahi
amw1 has quit [Ping timeout: 240 seconds]
<Shiz>
good progress here
ephe_meral has quit [Ping timeout: 256 seconds]
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
klaus has joined #asahi
mikewilks[m] has joined #asahi
amw1 has joined #asahi
<marcan>
rwhitby: I just discovered something interesting
<marcan>
if you put it into DFU mode via PD, PD renegotiation does not occur, and it behaves differently
<marcan>
normally, a hard shutdown (holding down power) kills PD for good
<marcan>
however, a hard shutdown from DFU mode leaves PD up
<marcan>
now I wonder if one of the mux modes it has will mux out the power button on a GPIO or something
<marcan>
I saw some modes that looked like some form of GPIO
<marcan>
if I can do that I can avoid touching any buttons :-)
justMaku has joined #asahi
<justMaku>
marcan: when do you expect another stream to happen?
<marcan>
probably quite soon
<marcan>
I'm hoping apple releases the new kmutil already]
<marcan>
lots of fun once that happens
<marcan>
but whatever happens, let's say I'll do one on thursday like last week
<justMaku>
Nice! What’s the focus on right now?
<marcan>
basically prepping things ahead of time for when I can actually start testing code
<marcan>
right now I'm looking for some crimp-on pins so I can plug a USB cable into my type C breakout to bring out the DFU USB pins (which will become my own USB interface under m1n1) :)
<marcan>
and if I find a way to map out/control the power button somehow, that will be the ideal "I don't need to touch any buttons to run a test cycle" scenario
<marcan>
though strictly speaking that's for early bring-up only, because once I have a working serial loader, I can just never update it on device and just use reboots to test, which is very fast
<j`ey>
marcan: what did you mean by "I can just never update it on device"
<marcan>
I don't have to actually go into 1TR to test new versions
<marcan>
I can just upload them over serial on every boot
<Shiz>
bitbanging kernel go brrr
<j`ey>
ah right, thanks
<opticron>
my solution to the touchless reset problem is usually to get some variety of switched outlet, the cheaper option being a reflashed sonoff S31
<opticron>
though most of the stuff I deal with definitely doesn't have an inband way to do resets like you're describing
<marcan>
opticron: I have to *hold down* the power button
<marcan>
I can already reboot via PD, the missing thing is boot into 1TR
<marcan>
[268446.363968] usb 1-4.3.1: New USB device found, idVendor=05ac, idProduct=1227, bcdDevice= 0.00
<marcan>
USB is weird. I can *never* plug in a USB A cable the right way around on the first try
<Shiz>
nobody can
<marcan>
but now I just guessed the D+/D- polarity *and* which pair was the right one
<marcan>
and got it right on the first try
<Shiz>
the connector is in a physical quantum state that only collapses once you've tried both ways
<marcan>
USB: connectors impossible to guess, bare pin headers A-OK
<j`ey>
Shiz: usually once you tried both ways and then gone back to the original way
<Shiz>
yep
<marcan>
yup
<Shiz>
reminds me when someone at my hackerspace bodged their board layout
<eta>
I want: USB over XLR4 connectors
<Shiz>
so that the usb-c plug would only work one way around
yorick has joined #asahi
<Shiz>
:)
<j`ey>
my USB C cable for my monitor only seems to work one way round
<opticron>
marcan, ah, gotcha, special mode enabling, not just system reset
<Shiz>
i still wonder why setting auto-boot to false causes boot to completely fail :p
klaus has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<Shiz>
would it be useful for me to make an NVRAM page on the wiki to document variables?
DarthCloud has quit [Remote host closed the connection]
DarthCloud has joined #asahi
raster has quit [Quit: Gettin' stinky!]
konrad__ has joined #asahi
DarthCloud has quit [Ping timeout: 240 seconds]
DarthCloud has joined #asahi
raster has joined #asahi
Tokamak has quit [Ping timeout: 240 seconds]
Tokamak has joined #asahi
djb has joined #asahi
aratuk has joined #asahi
aratuk has quit [Ping timeout: 256 seconds]
prabinspkt has joined #asahi
modwizcode has quit [Ping timeout: 272 seconds]
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 265 seconds]
roxfan2 is now known as roxfan
p02jorse has quit [Remote host closed the connection]
HoneyTubes has joined #asahi
<marcan>
ok, built some arm64 scaffolding for m1n1, pulled in some basic bits from mini, and it builds
<marcan>
dammit apple, give us that kmutil already :p
<j`ey>
:-)
<rwhitby>
marcan: those extra I2C buses are likely the PD controllers. 0x38 and 0x3f are the usual suspects for that. Since they are 3.3V, I can poke at those.