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
crabbedhaloablut has quit [Read error: Connection reset by peer]
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #asahi-dev
Wormn has quit [Remote host closed the connection]
cylm has joined #asahi-dev
TellowKrinkle has quit [Remote host closed the connection]
TellowKrinkle has joined #asahi-dev
tristan2_ has joined #asahi-dev
tristan2 has quit [Ping timeout: 480 seconds]
midou has joined #asahi-dev
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi-dev
wille-io has quit [Quit: Ping timeout (120 seconds)]
wille-io has joined #asahi-dev
lena6 has joined #asahi-dev
lena6 has quit [Ping timeout: 480 seconds]
<jonmasters>
hi folks, I would like to take a look at the wip thunderbolt support - is there a good branch to be looking at?
<jonmasters>
(this is NOT for an eGPU, this is to try some simple PCIe devices for fun in an enclosure)
i509vcb has quit [Quit: Connection closed for inactivity]
systwi has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
systwi_ has quit [Ping timeout: 480 seconds]
systwi_ has joined #asahi-dev
systwi has quit [Ping timeout: 480 seconds]
AnuthaDev has joined #asahi-dev
slp has joined #asahi-dev
<jonmasters>
I found the USB4 DART patches from March but I assume I also need corresponding updated DTBs for those...anyone got a pointer to where I can find the bits? I assume I'll need to patch an m1n1 too
<janneg>
jonmasters: see atcphy-20230219, nothing else is public since public WIP branches unfortunately result in user support per private emails
<janneg>
canonical source of the DTBs is the kernel tree which are appended to m1n1 as payload and are filled with information on the system
<janneg>
hotplug in that branch is not reliable, you might need to connect/disconnect a few times
<janneg>
necessary thunderbolt device tree changes might be only hooked up for the m1 mac mini
<janneg>
I've seen some weird PCIe issues with that branch. a samsung evo 980 nvme did not work at all, an intel 2.5GB nic in a HP usb4 hub did not deliver IRQs
<janneg>
jonmasters: ah, I see, you're already in contact with sven on mastodon
<sven>
hah, I was just going to suggest he could talk to you :)
<sven>
my brain doesn’t fully work yet so feel free to take over :)
<janneg>
sure, go back to relax and recover
dcow has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
dcow has joined #asahi-dev
pounce has quit [Remote host closed the connection]
pounce has joined #asahi-dev
<lina>
eiln, janneg: Pushed a bunch of fixes and refactoring to my branch again, but I didn't get around to looking at t8112... I think there are still weird races and things like that around startup/shutdown.
espo has joined #asahi-dev
hightower2 has joined #asahi-dev
<lina>
I'm running gstreamer in a random kill loop now to see if I can find any weird races. So far one thing I am seeing is DART translation faults after shutdown, and also I think the suspend thing doesn't work in some cleanup paths?
<lina>
Basically error/early abort handling needs work I think
<lina>
This is what I'm running now: while true; do timeout -k 1 -s 9 $((1+RANDOM%3)).$(printf %03d $((RANDOM%1000))) gst-launch-1.0 v4l2src ! 'video/x-raw,width=720,height=1280' ! videoconvert ! fakesink; done
<lina>
I also fixed vertical video in ffmpeg ^^ (sent them the patch)
<janneg>
lina: I'll rebase my t8112 branch but probably won't do anything else
<lina>
OK ^^
dcow has quit [Ping timeout: 480 seconds]
<janneg>
I'll test t6001 with 13.5 as well, need do new install for that
<leio>
fwiw, if you want your gstreamer pipeline to exit more cleanly for this after a random amount of time/frames, v4l2src has num-buffers property to which you could give a random number of frames to let through as well and then end-of-stream and exit
<lina>
The point is actually letting it exit uncleanly ^^
<lina>
I want to hit the weird error handling corner cases, not just clean exit
<leio>
aight
<leio>
was too eager to try to help, as gst is an area I at least know :)
dcow has joined #asahi-dev
jeisom has joined #asahi-dev
lena6 has joined #asahi-dev
dcow has quit [Ping timeout: 480 seconds]
lena6 has quit [Read error: Connection reset by peer]
hightower2 has quit [Ping timeout: 480 seconds]
hightower2 has joined #asahi-dev
dcow has joined #asahi-dev
dcow has quit [Remote host closed the connection]
dcow has joined #asahi-dev
hightower2 has quit [Read error: Connection reset by peer]
espo has quit [Quit: WeeChat 4.0.5]
espo has joined #asahi-dev
hightower2 has joined #asahi-dev
wontons has joined #asahi-dev
wontons has quit []
jeisom has quit [Quit: Leaving]
jeisom has joined #asahi-dev
<lina>
eiln: I'm running into a rare pmgr issue where the main isp_sys domain refuses to power on with bit 0x800 set, and setting bit 0x1000 fixes/resets it. I'll try to figure out what that means... I think it's one of the ones you used?
hightower2 has quit [Read error: Connection reset by peer]
hightower2 has joined #asahi-dev
hightower2 has quit [Remote host closed the connection]
hightower2 has joined #asahi-dev
amarioguy2 has quit [Remote host closed the connection]
amarioguy has joined #asahi-dev
<lina>
Pushed some pmgr-related stuff, hope it improves the Âcorner cases...
hightower2 has quit [Read error: Connection reset by peer]
hightower2 has joined #asahi-dev
qyliss has quit [Remote host closed the connection]
qyliss has joined #asahi-dev
i509vcb has joined #asahi-dev
jeisom has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-dev
slp has quit [Ping timeout: 480 seconds]
<lina>
The recovery stuff I tried to add doesn't work... it gets the PS going, but then random CPUs get wedged immediately after that ;;
<lina>
I think there is something weird that happens when you kill -9 the app using the camera. Shutdown fails, but I see the same VB2 callbacks getting called...
<lina>
Aaaaa we're using wait_event_interruptible_timeout() for commands ;;
<lina>
So on signals all that breaks...
hightower2 has quit [Read error: Connection reset by peer]
<lina>
OK, looks much cleaner now ^^
jacksonchen666 has joined #asahi-dev
<lina>
I'm going to leave it all night starting/killing captures while looping some ffmpeg compiles, if nothing goes horribly wrong I think we're good ^^
<lina>
Actually removed it now anyway, in a fixup
<lina>
I should sleep ^^
jacksonchen666 has quit [Ping timeout: 480 seconds]
lawrence has quit [Ping timeout: 480 seconds]
lawrence has joined #asahi-dev
xcpy0 has quit [Read error: Connection reset by peer]
xcpy0 has joined #asahi-dev
stipa is now known as Guest1676
Guest1676 has quit [Read error: Connection reset by peer]
stipa has joined #asahi-dev
arekmx has joined #asahi-dev
arekm has quit [Read error: Connection reset by peer]
slp has joined #asahi-dev
wille-io has quit [Read error: Connection reset by peer]
wille-io has joined #asahi-dev
_dhewg has joined #asahi-dev
dhewg has quit [Read error: Connection reset by peer]
_dhewg is now known as dhewg
<jonmasters>
hey thanks janneg and sven
<jonmasters>
I'll take a look at that branch. The right workflow is to take a dtb and rebuild m1n1 right? there's a flow to chainload an m1n1...is that what you usually do to test, or do you replace the original m1n1?
hightower2 has joined #asahi-dev
hightower3 has joined #asahi-dev
hightower2 has quit [Read error: Connection reset by peer]
<j`ey>
jonmasters: replacing stage1 m1n1 means going via recoveryOS, so you want to just replace stage2
<marcan>
I/most of us just load kernels/devicetrees over USB
<jonmasters>
is that what patches the dtbs in this stack?
<jonmasters>
ah ok
<jonmasters>
I've seen that page before - will take a look
<marcan>
look for the backdoor proxy mode section to enable USB loading (with a timeout so it defaults to normal boot), no need to replace anything
<jonmasters>
marcan: when the dtbs are patched, that's the stage2/uboot doing it?
<marcan>
that's my workflow these days, install normally, enable that (can even be done during the install step2 part, in a new terminal tab)
<marcan>
yes, stage2 handles runtime dtb changes
<marcan>
stage1's only job is to load stage2
<jonmasters>
cool cool
tenkuu has joined #asahi-dev
<marcan>
I've been moving more minor init stuff from stage1 to stage2 since it's safer/more flexible that way over time, in principle stage1 should do the minimum possible to load stage2 or enable USB mode
<jonmasters>
yeah
<jonmasters>
ok, I'll use another M1 with the USB load method - probably weekend at this point
<marcan>
with the backdoor mode stage1 breaks into USB mode and then you can just chainload m1n1 (for updates) and linux.py a kernel, or use the hypervisor, or whatever
<marcan>
the other machine can be any arbitrary computer fwiw
<j`ey>
jonmasters: it doesnt need to be another M1
<jonmasters>
I'm seeing a possible relaxed memory issue with a certain driver on another Arm platform and wanted to see if it showed up with the most relaxed of them all - reason I am tinkering with thunderbolt :)
<marcan>
ha
<jonmasters>
:)
<jonmasters>
also, I'm totally blown away with the progress here, it's outrageous
<marcan>
:)
<jonmasters>
I will never underestimate you ever again ;)
<marcan>
:D
<marcan>
jonmasters: FWIW page isn't fully up to date, but you always want to chainload a new m1n1 before hypervisor or linux.py to make sure you use your up to date tree, not whatever stage1 is
<marcan>
my usual recipe for testing kernels bare metal is (in m1n1/proxyclient): make -C .. && python tools/chainload.py -r ../build/m1n1.bin && tools/linux.py <...>/arch/arm64/boot/Image.gz <...>/arch/arm64/boot/dts/apple/t8112-j413.dtb <...>/initramfs.cpio.gz -b 'debug rootwait root=/dev/nvme0n1p6 rootflags=subvol=root'
maz has quit [Ping timeout: 480 seconds]
<marcan>
for hypervisor: make -C .. && tools/run_guest_kernel.sh <path to linux build tree root> 'debug rootwait root=/dev/nvme0n1p6 rootflags=subvol=root' <...>/initramfs.cpio.gz
<marcan>
(tools/run_guest_kernel.sh will do the chainload itself)
maz has joined #asahi-dev
<jonmasters>
cool cool
<jonmasters>
I've been reading through your wiki a bit and do plan to dive into the m1n1 from first principles when I've got some time, it's a great project for learning AS innards
<jonmasters>
but for now, chainload and playing this weekend
<marcan>
yeah, it's a nice toolset to hack on pretty much all the hardware :)
<jonmasters>
:)
<marcan>
the backdoor proxy mode will break boot when any of the two TTY devices are opened, so when I'm using it I just have a tools/picocom-sec.sh running in another terminal which will trigger the proxy, and also become the hypervisor vUART if you use that
<marcan>
(see udev/80-m1n1.rules for the rules to set up the /dev nodes properly)
<jonmasters>
ah ok
<jonmasters>
and any generic Linux box can be the other end, ok
<marcan>
yeah
<marcan>
it's just USB
<jonmasters>
so just a USB-C->C cable and a dell XPS ok
<marcan>
yup
<marcan>
low level serial stuff and remote hard reboots are possible with another Mac or custom hardware, but not at all required
<jonmasters>
great, that's my desk down in my lab already :)
<jonmasters>
I'm seeing maz in a couple weeks and he's bringing one of his toys for me
<marcan>
(if you use the hypervisor you can always ^C and `reboot` as long as it doesn't get into a really bad wedge state)
<marcan>
nice
<jonmasters>
I haven't picked up an M2 mini yet (NV2)
<jonmasters>
but I will etc.
<marcan>
:)
<jonmasters>
:)
<janneg>
any computer with an aarch64 (cross-)compiler
<jonmasters>
sure
<jonmasters>
that's great
<marcan>
I've heard rumors that some Apple people use m1n1 with a macOS host because it's better than their own tooling ;)
<jonmasters>
I've heard similar
<espo>
janneg: sry forgot to tell you earlier, tried the bluetooth fixes and it works perfectly ( even for none logitech products ). I have a custom build keyboard which also went to a connect yes/no loop before. Applied your patch and now it connect just fine.
<marcan>
cool, I'll merge the bluetooth stuff (and a bunch of kernel backlog I have) soon
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
Guest1620 has quit [Quit: Bridge terminating on SIGTERM]
<espo>
i can also try a logitech keyboard ( let me search for it should be laying somewhere ) then i can also test it with an actual logitech product
<espo>
yep working as well paired an logitech mx keys.
Jamie has joined #asahi-dev
Jamie is now known as Guest1682
rhysmdnz has joined #asahi-dev
jacksonchen666 has joined #asahi-dev
jacksonchen666 has quit []
hightower3 has quit [Read error: Connection reset by peer]
espo has quit [Quit: WeeChat 4.0.5]
espo has joined #asahi-dev
flom84 has joined #asahi-dev
Cyrinux9474 has quit []
Cyrinux9474 has joined #asahi-dev
<janneg>
lina: t8112 / fw 13.5 works after rebase onto isp/t602x-v2
<janneg>
and adapting to the pmgr changes
hightower2 has joined #asahi-dev
<janneg>
sometimes. still seing crashes. recovery after crashes works but if it doesn't crash again might result in broken colors, cyan/magenta tinted
tenkuu has quit [Read error: Connection reset by peer]
jeisom has quit [Ping timeout: 480 seconds]
tenkuu has joined #asahi-dev
tenkuu has quit [Read error: Connection reset by peer]
tenkuu has joined #asahi-dev
tenkuu has quit [Read error: Connection reset by peer]
tenkuu has joined #asahi-dev
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
kidplayer_666 has joined #asahi-dev
AnuthaDev has quit [Remote host closed the connection]
AnuthaDev has joined #asahi-dev
AnuthaDev has joined #asahi-dev
kidplayer_666 has quit []
kidplayer_666 has joined #asahi-dev
AnuthaDev has quit [Quit: AnuthaDev]
kidplayer_666_ has joined #asahi-dev
kidplayer_666_ has quit [Remote host closed the connection]
nela has quit [Quit: bye!]
nela has joined #asahi-dev
kidplayer_666_ has joined #asahi-dev
kidplayer_666 has quit [Ping timeout: 480 seconds]
kidplayer_666_ has quit [Read error: Connection reset by peer]
kidplayer_666_ has joined #asahi-dev
kidplayer_666_ has quit [Remote host closed the connection]
kidplayer_666_ has joined #asahi-dev
kidplayer_666_ has quit [Remote host closed the connection]
kidplayer_666_ has joined #asahi-dev
lena6 has joined #asahi-dev
kidplayer_666_ has quit [Read error: Connection reset by peer]
kidplayer_666_ has joined #asahi-dev
kidplayer_666_ has quit [Remote host closed the connection]
kidplayer_666_ has joined #asahi-dev
kidplayer_666_ has quit [Read error: Connection reset by peer]
flom84 has quit [Ping timeout: 480 seconds]
cylm has quit [Ping timeout: 480 seconds]
jeisom has joined #asahi-dev
i509vcb has quit [Quit: Connection closed for inactivity]
loki_val has quit []
eiln has joined #asahi-dev
<eiln>
lina: thanks for the fixes, studying them
<eiln>
I am wary of indexing "bt_surf" by strings though. "MISC" is everything they couldn't be bothered to name, and I'm surprised 0xc000 is a filter. maybe we can narrow it down by tracking state? also we shouldn't need to vmap every surface now
<eiln>
janneg: cyan/magenta tinted? uh oh. that doesn't sound like the grey/grainy + rainbow spec err I used to get, mine was a filter graph ordering err
eiln has quit [Quit: WeeChat 4.0.4]
<janneg>
eiln: looked like an exposure filter, mostly cyan with brighter spots in magenta
<janneg>
I suspect the crashes are power-domain related