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
m42uko has joined #asahi-dev
m42uko_ has quit [Ping timeout: 480 seconds]
roxfan has quit [Remote host closed the connection]
<Tramtrist>
ah i see.. ya thats very useful chadmed :)
roxfan has joined #asahi-dev
<marcan>
Tramtrist: I get applecare for machines I actually intend to use daily/travel with
<marcan>
desktops and machines that are just base model test devices, no
<marcan>
eiln: you don't want raw frames, phone/web cameras these days do a stupid amount of processing on raw sensor data. raw frames will *suck*. we need to take advantage of the blob.
<marcan>
I'm not interested in reinventing the ISP stack and ending up with crappier results than macos
<j`ey>
currently the only use is getting an rng inside m1n1 for kaslr
<sid-linux>
j`ey: thank you for your prompt reply (as usual :-) )
erso has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
erso has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
erso has quit [Ping timeout: 480 seconds]
rootbeerdan has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
erso has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
nsklaus has joined #asahi-dev
mikelee has joined #asahi-dev
erso has quit [Ping timeout: 480 seconds]
mikelee has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
pbsds has joined #asahi-dev
mikelee has joined #asahi-dev
erso has quit [Ping timeout: 480 seconds]
mikelee has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-dev
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
erso has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
erso has quit [Ping timeout: 480 seconds]
erso has joined #asahi-dev
roxfan2 has joined #asahi-dev
cylm has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
jeisom has quit [Quit: Leaving]
stipa has joined #asahi-dev
jeisom has joined #asahi-dev
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
jeisom has quit [Remote host closed the connection]
jeisom has joined #asahi-dev
nsklaus has quit [Quit: WeeChat 4.1.0-dev]
nsklaus has joined #asahi-dev
mikelee has joined #asahi-dev
jeisom_ has joined #asahi-dev
jeisom has quit [Read error: No route to host]
mikelee has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
jeisom_ has quit [Remote host closed the connection]
jeisom has joined #asahi-dev
<sven>
yay, looks like usb is stable again
<sven>
now lets see about that weird bit that flips when xnu runs but didn’t with my old code
<sven>
also, usb3 followed by a mode switch to usb3+DP doesn’t require a dwc3 reset anymore \o/
<jannau>
completely unrelated: the intel 2.5 gb network chip which didn't work in my thunderbolt dock works as random PCIe card in a razor core x (thunderbolt 3 gpu case) (using the same code)
<sven>
😵💫
<sven>
there are still some issues with pcie power management over tbt but I first want to get this new tipd/usb3 part ready
<sven>
and the whole pcie hotplug issues ofc
<jannau>
yeah! on the the unneeded reset. I guess it's on the HW a side effect of not supporting usb3.2 gen 2x2 or whatever the 2 lane mode is called today
<sven>
I think so. Iirc xnu used to do that additional reset but at some point they also stopped doing it
<sven>
or maybe I just misremember the first part :D
<sven>
but essentially I can switch the atcphy mode without going through a full reset and everything still works
<jannau>
no worries about pcie/tbt, that was just a quick tests for new HW
<sven>
what I might end up doing is just always setting up usb3+DP anyway for the current hw
<sven>
I also think I know how dp tunneling works now so that’s next after usb3/tipd
<jannau>
split usb3 and DP seems to be sane default and is good up to 4k60 (8bpp, rgb 4:4:4, no compression) which should cover most displays and many dp-altmode usb-c displays will have an usb hub
mikelee has joined #asahi-dev
<jannau>
sven: dcp is mostly still the same hardcoded hacks regarding phy and mux?
<sven>
yeah, but I have some vague plans how to improve that
<sven>
but I first want to make sure dp tunneling works similar to DP altmode
<sven>
I think crossbar needs some work on t6000 for dual output though
<jannau>
don't or talk to me first, I'm working on that to at least allow in principle dynamic switching
midou has quit [Ping timeout: 480 seconds]
<sven>
but that can come later
<sven>
sure
<sven>
what I definitely want to change is that oob hpd notification to include the current state
<sven>
the only reason the current one doesn’t have that because it was built for intel and the drm side can actually read the current state from somewhere
<sven>
I also have some vague ideas about how to model this in the DT that we should also discuss at some point
<jannau>
current plan is to have "fake" (as in not backed by HW) displayport controllers which control the phy and mux
<sven>
but I think DP tunneling and ideally also multi output should work first because there might still be some nasty surprises lurking
<jannau>
dcp connects via ports/graph to those dp controller but I'm unsure how dp-tunneling fits into that
<sven>
if it works the way I expect it to I have some very vague idea, I’m about to head out but I can dump my thoughts later
<jannau>
I hope we can shove into the dp controller as well altough the second dcp dp out will be a strange fit
<sven>
but essentially for DP tunneling we’ll have a “dpin” phy that will also trigger the HPD notification
zachole has joined #asahi-dev
<jannau>
this tries to copy the drm/kms device model which is a terrible fit for DCP
<sven>
“this”?
<sven>
Dpin is a real phy-like thing that needs some setup fwiw
<sven>
so we’ll very likely need a phy node for that
<jannau>
"this" == my draft device tree model and the sub drivers I'm writing
<sven>
dunno if my vague idea is any better there :/
<sven>
ugh, I’m already running late. I’ll ping you later
amarioguy has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
jeisom has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
midou has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
nsklaus has quit [Quit: brb]
nsklaus has joined #asahi-dev
roxfan has joined #asahi-dev
sid-linux has quit [Quit: User exited]
roxfan2 has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
nsklaus has quit [Quit: brb]
nsklaus has joined #asahi-dev
roxfan2 has joined #asahi-dev
roxfan has quit [Ping timeout: 480 seconds]
eiln has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
roxfan has joined #asahi-dev
roxfan2 has quit [Ping timeout: 480 seconds]
sid-linux has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
<eiln>
marcan: makes sense. and if i can figure out one "ioctl", the 400 others should be relatively straightforward
<eiln>
i'm worried calls like CISP_CMD_CH_AE_BIAS_EXPOSURE_SET aren't one-time, static params though (unlike, say, CISP_CMD_CH_COLOR_CAL_DATA_SET)
<eiln>
oh well, i've gotta figure out CISP_CMD_START first
<sid-linux>
question regarding m1n1 adt. When the stage 1 m1n1 overwrites itself with the stage 2 m1n1, the chainloaded m1n1 still has access to the adt.
<sid-linux>
How is that possible -- how is the adt still available ?
<sid-linux>
according to my calculations ADT would be at something like 0x802_B30_000
<sid-linux>
but I would have thought that we treat the memory as "fresh" when m1n1 stage 2 restarts
<ChaosPrincess>
the memory is still there, stage 2 is loaded at such an address that it does not overwrite the adt or other things you need to preserve
<jannau>
as fresh as it is after iboot ran. the adt is in the bootargs and remains at it's location
<jannau>
other things like the SEP firmware is copied
<sid-linux>
max bootargs size is 16K. However devtree size is 0x5C00 or ~376K
<sid-linux>
so while the pointer to the adt is in bootargs, it has to lie outside it
<sid-linux>
if you look at chainload_image() in m1n1 src/chainload.c , there is a copying of SEPFW but no copying of the adt
<sven>
isn’t the memory layout something like (bootargs)(adt)(m1n1)(sepfw)?
<sid-linux>
wow -- very useful. thanks ChaosPrincess
jeisom has quit [Ping timeout: 480 seconds]
mikelee has joined #asahi-dev
<sid-linux>
(figured it out also. adt is never overwritten by m1n1 and it lies at a lower address to _base where m1n1 is loaded)
<sid-linux>
*never overwritten by m1n1 as part of the chainloading to the stage 2 m1n1
roxfan2 has joined #asahi-dev
roxfan2 has quit [Remote host closed the connection]
roxfan has quit [Ping timeout: 480 seconds]
roxfan has joined #asahi-dev
roxfan has quit [Remote host closed the connection]
mikelee has quit [Ping timeout: 480 seconds]
adryzz has joined #asahi-dev
Lena has quit [Read error: Connection reset by peer]
roxfan has joined #asahi-dev
rootbeerdan has joined #asahi-dev
mikelee has joined #asahi-dev
mikelee has quit [Ping timeout: 480 seconds]
<sid-linux>
does iboot add SEP Firmware in stage 1 boot ? Or does Asahi Linux package the SEP firmware with m1n1 stage 1 during installation of Asahi Linux?
<sid-linux>
in other words who adds the SEF Firmware to the memory during stage 1?
<sid-linux>
i guess it must be iboot because SEPFW appears in the ADT