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
kesslerdupont has quit [Ping timeout: 480 seconds]
psykose_ has quit [Remote host closed the connection]
psykose has joined #asahi-dev
kesslerdupont has joined #asahi-dev
kesslerdupont has quit []
abd has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
bps has joined #asahi-dev
bluetail has quit [Quit: The Lounge - https://thelounge.chat]
nsklaus has quit [Ping timeout: 480 seconds]
i509vcb has joined #asahi-dev
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
bps has quit [Ping timeout: 480 seconds]
<axboe> jannau: yep using xfce4, but seems like that should not be related here. pretty normal setup I think, debian testing. using the lid to suspend/resume, yep
<axboe> kernel .config was posted in case there's something there, I can also try the asahi one just in case?
<axboe> hadn't had time to further fiddle with this today :/
nsklaus has joined #asahi-dev
gabuscus has quit []
nsklaus has quit [Ping timeout: 480 seconds]
<axboe> jannau: tested without lid, same issue
nsklaus has joined #asahi-dev
chadmed_ has joined #asahi-dev
gabuscus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
<axboe> marcan: tried the "default boot into osx, boot linux and trigger it"
<axboe> didn't get anything out of osx
<axboe> used the mem > state way to suspend, and on the third suspend, screen went dark as usual, but then rebooted
<axboe> so definitely suspend related, not resume - unless the previous resume messed something up...
<axboe> also enabled always-on for basically anything I saw in that trace I posted in here
<axboe> and still triggers
<axboe> this is on top of pmgr-stuff added to the mix
<axboe> even updated mesa since I needed to do that anyway
<axboe> as far as I know I'm fully current on m1n1/u-boot/mesa
<axboe> osx shows my debian/asahi boot as 12.3 fwiw
nsklaus has joined #asahi-dev
<axboe> all of /proc/device-tree/ in case there's anything useful in there
<axboe> cat git/m1n1/build/m1n1.bin git/asahi-linux/arch/arm64/boot/dts/apple/t6001-j316c.dtb git/u-boot/u-boot-nodtb.bin
<axboe> that's my payload
nsklaus has quit [Ping timeout: 480 seconds]
ncopa has quit [Remote host closed the connection]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
bluetail has joined #asahi-dev
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
abd has quit [Remote host closed the connection]
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
<jannau> overnight suspend/resume worked as well, not surprising if the issue is triggered by suspend
nsklaus has quit [Ping timeout: 480 seconds]
<jannau> difference is kernel config and m1n1 payload. I boot kernel and initrd directly instead of u-boot
<jannau> I don't see how userspace would make a difference unless it arms the watchdog
nsklaus has joined #asahi-dev
<jannau> axboe: you want to compress the u-boot payload. unrelated to the suspend issue but if you switch to the standard chainloading setup a compressed u-boot is required to allow reading appended variables
salimterryli has quit [Quit: ZNC - https://znc.in]
nsklaus has quit [Ping timeout: 480 seconds]
salimterryli has joined #asahi-dev
<jannau> suspend doesn't seem to work at all with axboe's config (+ samsung serial)
nsklaus has joined #asahi-dev
<jannau> axboe: if you want to have wlan ready at boot instead of waiting for it a couple of minutes you need to disable CONFIG_FW_LOADER_USER_HELPER
<jannau> the ongoing wifi firmware loading appears to break suspend here
nsklaus has quit [Ping timeout: 480 seconds]
<jannau> or at least delays entering suspend
nsklaus has joined #asahi-dev
<jannau> I hit however a SError, unsure if it strictly is suspend + CONFIG_FW_LOADER_USER_HELPER in progress related or if it was something I did because it stopped after file system sync
ncopa has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
<jannau> suspend/resume is rock solid after disabling CONFIG_FW_LOADER_USER_HELPER but I'm not sure how that would explain issues after more than a few minutes of uptime
pthariensflame has joined #asahi-dev
pthariensflame has quit []
nsklaus has joined #asahi-dev
bps has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
chadmed_ has quit [Quit: Page closed]
nsklaus has joined #asahi-dev
MajorBiscuit has quit [Ping timeout: 480 seconds]
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
i509vcb has quit [Quit: Connection closed for inactivity]
<jannau> not sure that is the same issue though given that axboe used ssh
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
kaazoo has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
<kaazoo> HI, did anybody look into MTP support with FW 13.3 on j414s / M2 Pro 14" yet? U-boot complains about not being able to reserve some fdt memory regions: https://pasteboard.co/nI0QZsaCGQzJ.jpg
<kaazoo> dockchannel-hid gets loaded but MTP fails with 'rtkit-helper 2a9400000.mtp: error -ETIME: Failed to wake up coprocessor'
nsklaus has joined #asahi-dev
<_jannau_> I think nobody has looked so far at the u-boot mtp code. it works with linux as direct linux payload
<_jannau_> the kernel has at least one change which needs to be done on u-boot side as well: adjusting/fixing rtkit oslog handling
MajorBiscuit has quit [Ping timeout: 480 seconds]
MajorBiscuit has joined #asahi-dev
MajorBiscuit has quit []
nsklaus has quit [Ping timeout: 480 seconds]
<kaazoo> Yes, I guess that 'apple_rtkit_poll: unexpected endpoint 8' means oslog from https://github.com/AsahiLinux/m1n1/blob/t602x/bringup/src/rtkit.c#L27
<kaazoo> Are there any details documented about oslog messages? What should u-boot do with those? Just ack them the same way as m1n1 does?: https://github.com/AsahiLinux/m1n1/blob/t602x/bringup/src/rtkit.c#L448
<jannau> no, m1n1 doesn't use mtp, it needs to do the same as the linux driver. see 612cb2861e4c ("soc: apple: rtkit: Implement OSLog buffers properly")
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
nyilas has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
nsklaus has joined #asahi-dev
nsklaus has quit [Ping timeout: 480 seconds]
<kaazoo> jannau: OK, thanks. I will try to add that into u-boot.
nsklaus has joined #asahi-dev
Jamie has joined #asahi-dev
rhysmdnz has joined #asahi-dev
Jamie is now known as Guest12222
nsklaus has quit [Ping timeout: 480 seconds]
Guest12142 has quit [Ping timeout: 480 seconds]
rhysmdnz1 has quit [Ping timeout: 480 seconds]
bps has joined #asahi-dev
nsklaus has joined #asahi-dev
cylm has joined #asahi-dev
mkurz has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi-dev
gladiac has quit []
gladiac has joined #asahi-dev
gladiac has quit [Quit: k thx bye]
mkurz has joined #asahi-dev
<axboe> jannau: wlan is ready at boot as it is, but I killed LOADER_USER_HELPER but it doesn't change any wrt suspend/resume
<axboe> suspended twice this morning before heading to the office, just 10 second ones, and it was fine
<axboe> suspended and drove to the office, open the laptop to a rebooted state...
<axboe> jannau: what's your .config, I could give that a whirl just in case it's some weird interaction
nyilas has quit [Remote host closed the connection]
nyilas has joined #asahi-dev
nyilas has quit [Remote host closed the connection]
nyilas has joined #asahi-dev
nyilas has quit [Remote host closed the connection]
<jannau> axboe: https://www.jannau.net/asahi/suspend.config derived from your config, mostly toolchain induced changes. enabled serial for debugging
<jannau> haven't tried yet to boot through u-boot
hightower2 has joined #asahi-dev
<axboe> hmm
<axboe> yeah that's basically identical outside of adding serial
<axboe> presumably the m2 max is going to be useful soon, so might just be worth scrapping spending any time on this if it's specific to some weirdness with my setup
<axboe> I can just run the previous kernel until then
mkurz has quit [Ping timeout: 480 seconds]
cylm has quit [Ping timeout: 480 seconds]
mkurz has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
c10l has quit [Quit: Bye o/]
c10l has joined #asahi-dev
stickytoffee has quit [Read error: Connection reset by peer]
stickytoffee has joined #asahi-dev
Tomdownsouth has joined #asahi-dev
Guest12222 has quit [Ping timeout: 480 seconds]
rhysmdnz has quit [Ping timeout: 480 seconds]
<maz> oops, I may have "accidentally" ended-up with a m2 pro mini... oh well...
<j`ey> oh no
Tomdownsouth has quit [Remote host closed the connection]
<maz> j`ey: quite. I sense trouble...
<povik> ok, upping both LMB_MAX_REGIONS and LMB_RESERVED_REGIONS to 64 doesn't make the SIO reservation errors go away
<povik> ^ that's in u-boot
<povik> here are the relevant devicetree nodes: https://tpaste.us/wxa5
<povik> it complains about the four sio-firmware-data@... reserved nodes
<povik> which seem to be the only ones that fall within the span of the memory@80000000 node
<povik> and i guess moving dt_set_memory in m1n1's kboot.c behind the sio setup is all one needs to do to cut out the sio reserved regions from the memory@ node...
roxfan2 is now known as roxfan
<jannau> povik: the memory@80000000 should not cover the reserved mem
<povik> ok, that's easy then :)
<jannau> at least not in the setup we use
<povik> are the semantics of the memory@ node documented somewhere?
<jannau> but adjusting top_of_memory should take care of that
<jannau> Documentation/devicetree/bindings/reserved-memory/reserved-memory.yaml
<jannau> not sure if what I started doing for dcp is as intended/correct
<marcan> kaazoo: FYI all the t802x bringup stuff is already merged into the regular m1n1/linux branches (except the GPU stuff lina is working on), so disregard the bringup ones
<povik> ah, of course the devicetree spec itself discusses /memory
<povik> though there doesn't seem to be anything that prohibits the overlap of the /memory node and the reserved regions, the devicetree spec even has an example that's overlapping, so still not sure what the u-boot error is about
<jannau> axboe: if you're (un)lucky the suspend issue reproduces on on the m2 max. I still think it's useful to find out what causes it but can understand if you don't can/want spend time on it
<jannau> povik: I think I tested sio with u-boot after I bumped LMB_MAX_REGIONS and didn't see any errors
<povik> huh
<axboe> jannau: yeah agree, would love to know what it is, just trying to proportion the time spent on this particular issue...
<povik> jannau: i might be messing something up in the installation of a patched u-boot version (this is on a nixos install), but it's unlikely, i tried changing the font size and that took effect
<povik> on the other hand this made the errors go away
<jannau> makes sense, allocation for the display happens (if it happens) is at m1n1's init
<povik> ah, i was wondering about that, right
<jannau> I must have either overlooked the errors, didn't test it or something else
<povik> now if only we could figure out those :/
<povik> [ 2.335642] apple-sio 236400000.sio: error -ETIME: SIO did not boot
<povik> i only get them on a full-fledged OS install which makes debugging hard
<povik> jannau: do you have a .config that might be worth trying? see if i can reproduce it?
<povik> anything that's similar to the one you were getting boot failures with, if it isn't too bloated
<povik> i will see try flipping on SIO and see if i can reproduce
<povik> it doesn't seem to be a power-domain thing after all, at least the failures still occur without turning off any domains, and with resets disabled
<jannau> axboe: reproduced when booting via u-boot
<povik> \o/
<povik> happy about the other thing getting reproduced :)
hightower2 has quit [Ping timeout: 480 seconds]
<jannau> povik: config with most of the non-essential drivers (including sio) as modules. so probably close to your full-fledged OS install
<jannau> I use https://github.com/AsahiLinux/m1n1/pull/268 with a few tricks to still boot from frommy dev system
<axboe> jannau: wll then!
<marcan> jannau: now I wonder what u-boot does that somehow affects linux down the line, that's... bizarre
<marcan> it's not supposed to touch any HID stuff etc, is it? I wonder if it does anything interesting to any other sysregs...
<marcan> is this with PCIe enabled in u-boot?
<jannau> it shouldn't have PCIe enabled but linux complains about "pcie-apple 590000000.pcie: invalid resource"
<jannau> and fails to create device links for 2920a1300.spmi:pmu@f:rtc_nvmem@1400 and 2920a1300.spmi:pmu@f:legacy_nvmem@6000
<marcan> long shot: we should write an AMCC error handler driver
<marcan> real-time memory requests to stuff the CPU has cached are illegal (macOS panics if that happens)
<marcan> we've never bothered with that because it worked anyway
<marcan> but it's entirely possible something about deep idle breaks it much more badly
<jannau> PCIE_APPLE is not set in u-boot's config
<axboe> I do have it set in mine fwiw
<marcan> already getting AMCC errors on a simple boot on j314 without u-boot
<marcan> need to sleep, will look at this angle tomorrow
<marcan> pretty sure this has been broken forever and it wouldn't be surprising if deep idle makes it actually matter for real
* povik googles AMCC
<povik> ah apple memory cache controller probably
<ChaosPrincess> does anything we currently support use the "t8020" DART?
hightower2 has joined #asahi-dev
<jannau> everything we support on t8113
bps has joined #asahi-dev
<ChaosPrincess> ok, then that might be the wrong name
<ChaosPrincess> there is some weird dart with 4 io areas used for ave, ane and isp
<ChaosPrincess> is this the same as everything else?
<ChaosPrincess> dts claims its t8020
<marcan> DARTs are instanced
<marcan> you need to look at the instances stuff to figure out what the io areas are
<ChaosPrincess> whats instance
<povik> instances stuff meaning some constant register imprint in silicon?
<jannau> instance property
<povik> or ADT subnodes?
<marcan> they mushed together a pile of drivers into one and called it all dart
<marcan> then they specify what the IO areas mean in that property
<marcan> it's a horrible stupid hack
<ChaosPrincess> instance = 465041444350554441525400545241444441525400000000554d4d53534d4d5500000000 - this?
<marcan> (just like the rest of ADT)
<marcan> yes
<marcan> it's ASCII
<ChaosPrincess> wtaf
<marcan> second io area should be a regular dart
<marcan> according to that
<ChaosPrincess> are those fourccs
<marcan> they are eightccs
<marcan> well really just null-padded 8-character ascii strings
<marcan> oh more than 8 even, nice
<marcan> so just a pile of strings really
<marcan> 4byte aligned
<marcan> FPADCPUDART TRADDART UMMSSMMU
<marcan> so two DARTs of some sort and the SMMU thing we don't care about
<povik> looks like a DNA sequence :D
<jannau> misses 'G's
<ChaosPrincess> there are 'U's, its a RNA :P
<povik> ok then, you seem to know your microbiology better than me :p
<marcan> "just dump the registers and pick out the ones that look like DARTs" is my recommendation
<marcan> :p
<ChaosPrincess> and 'darts of some sort' - means those are different for each ip block?
<ChaosPrincess> *"dart per ip block"
<marcan> the DARTs should all be t8020 compatible or if not at least *very* similar
<marcan> oh also FPAD=DAPF?
<marcan> I don't know why half the things are backwards only
<marcan> this thing is cursed
<marcan> as I said, just dump the regs and eyeball it
<ChaosPrincess> whats dapf
<sven> didn’t we have this exact same discussion a week or two ago? :D
<marcan> probably :p
<marcan> I'm going to sleep, someone else can explain DAPF :D
<ChaosPrincess> easy for you to say, i have no idea whats what suposed to look like :P
<povik> 21:35 < ChaosPrincess> whats dapf
<marcan> dump a known good DART and compare? :p
<povik> ah remember myself asking the same question
<sven> DAPF is a weird filter like thing on top of dart
<sven> there’s a reg map in m1n1 iirc
<sven> tl;dr is to either ignore it or replay some property from the ADT to it and then ignore it
<jannau> try experiments/dart_dump.py $name and see if it makes sense
<ChaosPrincess> k, ty
<povik> ChaosPrincess: that instance= value you copied seems to be from dart-ave
<ChaosPrincess> it is
<povik> that node has filter-data-instance-0 and dapf.c in m1n1 will know how to set the DAPF according to that
kaazoo has left #asahi-dev [#asahi-dev]
<povik> so it will get set by dapf_init_all() probably and you don't need to care about it
<povik> though you might want to inspect the DAPF entries just to see what gets mapped
<jannau> povik: short description how I boot kernels with modules tethered https://gist.github.com/jannau/24089ca9dd93cdcbb712a95d5ef83803
<povik> jannau: thanks!
kaazoo has joined #asahi-dev
<jannau> I have the feeling it is just the watchdog, armed by u-boot, feeded by linux and not disarmed on suspend
<povik> ChaosPrincess: typically data that's shared between the application processor and the coproc will be mapped by DART, data that's for the coproc only, and the foreign mmio regions it accesses, will be mapped by DAPF
<povik> someone can correct me on that
<povik> depending on the coprocessor some mmio regions might be visible to it without mapping by DART nor DAPF
<povik> but e.g. the data section of SIO's firmware is mapped by DART
<povik> so don't take the above absolutely
<ChaosPrincess> i guess ill just see what macos does
<povik> macos will most likely set the DAPF according to that ADT property
<povik> and you should let m1n1 do the same
Jamie has joined #asahi-dev
rhysmdnz has joined #asahi-dev
Jamie is now known as Guest12262
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
<jannau> if the system stays 60 seconds in suspend without it's fixed
bps has joined #asahi-dev
A_L_I_C_E has joined #asahi-dev
A_L_I_C_E has quit [Quit: Quit]
maximbaz has quit [Quit: bye]
maximbaz has joined #asahi-dev
<axboe> jannau: sweet! I'll give it a spin
<axboe> jannau: looks good! I'll do a longer suspend later, but did 2+ min just now and it's fine
bps has quit [Ping timeout: 480 seconds]
alyssa has joined #asahi-dev
<alyssa> jannau: so, I heard $FEATURE for the gl driver is going to be released at the same time as dcpext support
<alyssa> I also heard that every time someone asks when dcpext support is done, it's delayed
<alyssa> So, since if I need more time for $FEATURE, it follows I should ask about dcpext support, right? ;-P
<ChaosPrincess> is $feature == cursed geometry shader emulation?
<alyssa> OpenGL 3.1 and OpenGL ES 3.0 and maybe OpenGL ES 3.1 too, we'll see how May goes
<alyssa> kinda depends on whether I can get funding
* alyssa whistles
<jannau> I've had hoped to get the m2 mini to light something up this weekend which is dcpext(int)UINT32_MAX support, that's of course != released
<ChaosPrincess> if you want to get funding dont whistle innocently :P go full hustle culture and promote your patreon or whatever in every post.
<alyssa> ChaosPrincess: *sweats*
<axboe> agree, you don't get what you don't ask for :)
<alyssa> :D
cylm has joined #asahi-dev
cylm_ has joined #asahi-dev
cylm has quit [Ping timeout: 480 seconds]