ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | Non-development talk: #asahi | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
swaggie has joined #asahi-dev
nate8_ has joined #asahi-dev
nate8 has quit [Ping timeout: 480 seconds]
swaggie has quit [Ping timeout: 480 seconds]
swaggie has joined #asahi-dev
amarioguy has quit [Remote host closed the connection]
<nicolas17>
I discovered that InstallAssistant.pkg contains the non-delta OTA update zip and the SFR zip, without any further compression
<nicolas17>
with xdelta3 I can create a 15MB(!) delta that turns <(cat sfr.zip ota.zip) into an InstallAssistant.pkg... and Apple doesn't delete those zips from their CDN in a hurry
<nicolas17>
so I can hoard installassistants efficiently
whomst has joined #asahi-dev
swaggie has quit []
nicolas17 has quit [Quit: Konversation terminated!]
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
nate8_ has quit []
nate8 has joined #asahi-dev
bpye5 has joined #asahi-dev
bpye has quit [Ping timeout: 480 seconds]
bpye5 is now known as bpye
<sven>
maybe I should've compiled the kernel with pcie hotplug support if I wanted pcie hotplug for that chained adapter to work :D
qdot has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
<jannau>
I would have assumed thunderbolt depends on that
<maz>
huh, how did it work the first place?
<sven>
i have to do the hotplug for the root ports manually anyway
<sven>
it's just anything below the root ports that uses the normal pcie hotplug
<maz>
I would have hoped that the same mechanism would work :-/
<sven>
maybe I can remove the open-coded hotplug from apple-pcie now that I compiled it with pcie hotplug support, let me try that
<sven>
but I at least need to reset the tunnel on link down/tunnel error
<sven>
nope, doesn't work because the root port claims that it doesn't support hotplug
<maz>
interesting. yet it has interrupts to signal link-up/down... i guess they settled on a hack rather than supporting the full HP spec...
<sven>
yeah :/
<sven>
maybe there's a way to get it to somehow use the normal pciehp but that's something for the pci mailing list once I'm happy with the rest
<maz>
oh, absolutely. There is hardly a case for HP without getting the rest of TB in shape.
<sven>
yup. the biggest mystery is why switching between my apple and startech adapter breaks the TB NHI (and/or figure out a way to just completely reset that NHI). once that's done there's really just busywork left
<maz>
reset the NHI? and all that time you were claiming that it was way better than dwc3... ;-)
<sven>
:D
<sven>
I still have hope that this adapter switch thing is just something dumb I do ;)
<maz>
the curse is the connector, I swear.
<sven>
yup
<sven>
this adapter switch also increases the probe time to something like 20-30seconds from maybe 5 seconds so there's clearly something that's very broken
<sven>
+on macOS
zzywysm_ has joined #asahi-dev
zzywysm has quit [Ping timeout: 480 seconds]
whomst has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
leitao has joined #asahi-dev
<jannau>
the m2 mac mini comes with macOS 13.0
<mkurz_>
jannau: you got yours already?
<jannau>
yes. build is 22A8380 compared to 22A380 of the public 13.0 release
<sven>
just how many machines do you have at this point? :D
<kettenis_>
total? or just Apple Silicon machines? ;)
* jannau
counts: 5
Ry_Darcy has joined #asahi-dev
<Ry_Darcy>
@Jannau any ideas when the Device Tree will be ready for the M2 Mini?
<jannau>
Ry_Darcy: a couple of days maybe, first we need make everything works. display is currently completely broken
<j`ey>
jannau: even the m1n1 iboot thing?
<j`ey>
thing = iboot protocol that m1 mini uses for display
<jannau>
yes, at least broken dart stream ID for dcp. maybe vm-base and potentially we have init the display crossbar and the dp2hdmi converter
<jannau>
if we're unlucky we have to do the dp-altmode setup with the dptx EP
<Ry_Darcy>
@Jannau OK. Thanks for the information.
<Ry_Darcy>
@Jannau last question, are there any caveats with the installer for the M2 Mini, or is it too early to ask?
<jannau>
the installer needs needs to adapted for new machines. we need 13.2 support, wifi/bt FW extraction for the new machines and fixed m1n1 and kernel with devicetrees for the new machines
<Ry_Darcy>
@Jannau Thank you. A bit involved then I see.
amarioguy has joined #asahi-dev
Ry_Darcy has quit [Quit: Page closed]
<kettenis_>
u-boot will probably need changes for the M2 Pro/Max
<kettenis_>
I should get my M2 Pro mini in about two weeks if Apple's prediction is right
<sven>
well... looks like the unreliability is just some kind of race
<sven>
if I add a msleep(1000) before telling the NHI about the new cable it seems reliable now. I bet this just needs to be synchronized against something in atcphy
minecrell has quit [Read error: Connection timed out]
minecrell has joined #asahi-dev
S1 has joined #asahi-dev
S1 has quit []
S1 has joined #asahi-dev
nate8 has quit [Read error: Connection reset by peer]
nate8 has joined #asahi-dev
chadmed_ has joined #asahi-dev
S1 has left #asahi-dev [#asahi-dev]
rowanG337 has joined #asahi-dev
<rowanG337>
@Jannau @Marcan I have been following asahi linux since the start now and I feel it's at about the level I can switch to it. So I ordered my first macbook. One thing that is interesting to me is that the screens can do 1000 nits sustained. But OSX limits it to ~500 nits in non-hdr content. There are apps for OSX which unlock the non-hdr brightness and allows users to go to 1000 nits. Are you open to including this feature in
<rowanG337>
the DCP driver (possibly with a sysfs switch)? Once I have received my mac and have some free time I'd want to look at that myself.
<rowanG337>
The primary reason I want this is to make using the laptop outside more bearable. I have a 500 nits screen laptop now and it's often really dim when outside on a bright day.
<marcan>
rowanG337: we'd have to figure out how to enable it and whether it is safe to enable long term
<marcan>
the current driver cannot support it as the conversion table only goes to 510
<jannau>
rowanG337: that is certainly not a priority for us but I guess it will become obvious how to do that once we support HDR itself
<marcan>
jannau: do you know if it's just cranking up the DAC output or something separate?
<jannau>
I haven't looked into it but I've seen macos setting more bools in the field I identified as enable flag
<marcan>
either way I'm not sure we want to enable an aging-relevant feature that Apple doesn't, so if we do this would probably end up being a module parameter and not something enabled by default
<jannau>
it's probably not totally unsafe since I think dcp has direct access to the display temp sensors
<marcan>
I mean, I don't expect it to be outright unsafe but it will age the backlight faster, that's just physics
<rowanG337>
It will definitely age the BL faster.
<rowanG337>
But It should be within Apple margin
<rowanG337>
since HDR output can do 1000 nits sustained
<marcan>
yeah but they probably don't spec the laptops to be playing HDR content 24x7
<marcan>
nevermind HDR content that is on the upper half of the range
<marcan>
so still, should probably be a non-default toggle
<jannau>
the HDR display seems not to be designed in California. the m2 pro/max specs say the max brightness works only up to 25°C
<rowanG337>
I wouldn't go past the 1000 nits sustained apple rates the display at. I think the display can do 1600 nits on parts of the display.
<jannau>
safe in the sense it will not destroy the backlight immediately
<rowanG337>
OSX also will lower the brightness automatically if it overheats
<rowanG337>
at least that is what I can read online in the apple docs itself.
<rowanG337>
I haven't tried it myself
<rowanG337>
I'm hoping actually that it's not OSX doing it but some kind of mcu connected to the display
<jannau>
I think dcp lowers the brightness and not macOS. otherwise it would not safe to enble
<j`ey>
(where DCP = some kind of mcu)
<rowanG337>
yeah sorry I don't have a clear mental model how everything fits together yet
<kettenis_>
jannau: LOL
bcrumb has joined #asahi-dev
<jannau>
sigh, that were a lot of assumptions in the dart and vram init code which became invalid on m2
<jannau>
dcp_iboot works finally but of course no display is detected
chadmed_ has quit [Ping timeout: 480 seconds]
leitao has quit [Remote host closed the connection]
leitao has joined #asahi-dev
<povik>
how come this wasn't fixed when the other m2 devices were being brought up?
<j`ey>
they all have internal displays
<kettenis_>
I wonder if (and hope that) the serial port will work
<maz>
it'd better work!
<j`ey>
Im assuming it is if jannau is using it?
<jannau>
and the internal displays are setup by iboot
<maz>
I'm >that< close to send the design to the fab...
<jannau>
I'm mostly using usb serial but reset via vdmtool works in principle but I had reset it already twice via power button
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
WhyNotHugo has left #asahi-dev [#asahi-dev]
bcrumb_ has joined #asahi-dev
bcrumb has quit [Ping timeout: 480 seconds]
nicolas17 has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]
Deewiant has quit [Remote host closed the connection]
<nicolas17>
the datahoader/archivist in me kinda wants a firmware dump of 22A8380 (tarball of /System?) since there's no download of it,
<jannau>
it was a reference to "designed in California == rain,freezing temperatures are not expected"
<nicolas17>
yep
<jannau>
kettenis_: serial works and and I would expect it work on m1 pro/max as well
<jannau>
hdmi out will probably take longer. it seems to require at least scm and display crossbar support in m1n1
linuxgemini6 has joined #asahi-dev
<j`ey>
scm?
linuxgemini has quit [Read error: Connection reset by peer]
nepeat_ has joined #asahi-dev
<jannau>
smc
<sven>
ugh.. let's hope it at least doesn't require that DPTX dance
nepeat has quit [Ping timeout: 480 seconds]
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
<sven>
also, turns out that locking the thunderbolt mutex when calling deep into the thunderbolt subsystem is a very good idea🙃
Cyrinux has quit []
Cyrinux has joined #asahi-dev
bcrumb_ has quit [Quit: WeeChat 3.8]
WindowPa- has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Ping timeout: 480 seconds]
WindowPain has quit [Ping timeout: 480 seconds]
rowanG337 has quit [Quit: Leaving]
bcrumb has joined #asahi-dev
<jannau>
sven: do you understand how the dp switch is programmed? I miss the equivalent of atc?-dpxbar for the dp2hdmi converter
<jannau>
have you looked at {ufp,dfp}-endpoints in display-crossbar0?
<sven>
iirc the ufp/dfp endpoints are just the dcpext and the atcphys
<sven>
I don’t remember looking at „dp-switch“
<jannau>
there is no overall dp-switch. atc?-dpxbar are either parts of the switch or interact with the switch
Cyrinux has quit [Remote host closed the connection]
<jannau>
maybe it's just "function-force-dpfu" in dp2hdmi-gpio
hertz has joined #asahi-dev
thasti has quit [Remote host closed the connection]
bcrumb has quit [Quit: WeeChat 3.8]
thasti has joined #asahi-dev
bcrumb has joined #asahi-dev
hertz has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bcrumb has quit [Quit: WeeChat 3.8]
qdot has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sven>
oh this is just great, acio seems to put its crashlog into MMIO somewhere like SMC. the only message I get when it dies is four digits assert number that was triggered :/
<sven>
(e.g. assert_id=1271)
<sven>
the setbuffer requests are also strange. for the crashlog e.g. it asks [cpu4] [M3Tracer@/arm-io/acio-cpu1] RECV: 0010400010009c00:0020350000000001 | OUTCNT=0x2, INCNT=0x0, OUTPTR=0x3, INPTR=0x5, EP=0x1
<sven>
and then macos replies with [cpu4] [M3Tracer@/arm-io/acio-cpu1] SEND: 0010400501089c00:0000000000000001 | EP=0x1
<sven>
no idea how 010009c00 turns into 501089c00
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
WindowPain has joined #asahi-dev
WindowPa- has quit [Ping timeout: 480 seconds]
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
roxfan has joined #asahi-dev
kensan has quit [Remote host closed the connection]
kensan has joined #asahi-dev
___nick___ has quit [Ping timeout: 480 seconds]
jluthra has quit [Remote host closed the connection]
jluthra has joined #asahi-dev
seeeath has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
seeeath has joined #asahi-dev
Cyrinux has joined #asahi-dev
leitao has joined #asahi-dev
leitao has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mkurz_ has quit [Ping timeout: 480 seconds]
nate8 has quit [Quit: Leaving]
<jannau>
no luck so far with the hdmi out. only a dumb replay of the macOS dptx-phy trace.
<jannau>
still unclear what replaces atc-dpxbar for the dp2hdmi out, maybe it's just the default routing
<jannau>
could be of course the missing dptx DCP EP
<sven>
just realized the weird crashlog address translation is essentially segment-ranges
<sven>
still no idea why it occasionally still dies even on the first connection though
mkurz has joined #asahi-dev
nicolas17 has quit [Quit: Konversation terminated!]