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
cylm has joined #asahi-dev
cylm_ has quit [Ping timeout: 480 seconds]
nsklaus has quit [Quit: WeeChat 3.8]
nsklaus has joined #asahi-dev
vivithecanine has quit [Quit: WeeChat 3.8]
nsklaus has quit [Ping timeout: 480 seconds]
stipa is now known as Guest12289
stipa has joined #asahi-dev
gabuscus has quit []
Guest12289 has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi-dev
nyx_o has joined #asahi-dev
abd has joined #asahi-dev
<marcan>
jannau: duh... right, I forgot u-boot turns on the watchdog
<marcan>
also why isn't this just built-in functionality? sigh...
eiln has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
<marcan>
either way, glad it wasn't something deeper
<marcan>
I think that means we can probably cook a release soon, after wifi/bt is fixed for t602x machines and the u-boot oslog thing
<marcan>
also, enabling turbo clocks in the DTs now that cpuidle works
<marcan>
pushed the turbo pstate stuff before I forget
drubrkletern has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
<eiln>
i should move into tree w/ the next release. was waiting on the accel config
elvishjerricco has quit [Read error: No route to host]
elvishjerricco has joined #asahi-dev
kaazoo has quit [Quit: Leaving.]
<jannau>
I was asking myself that as well. the core watchdog device has suspend/resume callbacks to stop/start its thread and ping the watchdog on suspend
<jannau>
trying to think if it's possible if specific watchdog drivers could do something better than stopping the watchdog on suspend but I can't think of anything which would work for s2idle
<jannau>
eiln: do you need information from the m1 ultra? I wanted to look into that when you asked but forgot
<eiln>
jannau: yes please! do you mind tracing trace_device(node, mode=TraceMode.SYNC) for ane0, ane1, ane2, ane3
<eiln>
and trace_device("/arm-io/error-handler", False)
compassion has quit [Ping timeout: 480 seconds]
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
drubrkletern has quit [Remote host closed the connection]
compassion has joined #asahi-dev
bps has joined #asahi-dev
elvishjerricco has quit [Read error: No route to host]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: No route to host]
bps has quit [Ping timeout: 480 seconds]
hightower2 has quit [Ping timeout: 480 seconds]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: No route to host]
cylm has quit [Ping timeout: 480 seconds]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Remote host closed the connection]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: No route to host]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Remote host closed the connection]
elvishjerricco has quit [Ping timeout: 480 seconds]
<marcan>
I can just merge the new addition and leave the old driver to rot for now, the only downside of that is it forces a config symbol change which means churn for packagers
<marcan>
Jassi did say he's "ok" with it, just seems reluctant to give a formal ack for some reason...
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
<kaazoo>
I can put a proper email address into the commit message.
<kettenis>
I was planning to merge the M2 Pro/Max stuff and the asmedia firmware loading stuff into the asahi branch soon
<marcan>
the sram thing is worrying, maybe oslog doesn't re-request its buffer and confuses us with a similar message?
<marcan>
I need to look at that but at least it works
<marcan>
but if it doesn't re-request the buffer that is bad™
<marcan>
argh I hate this handoff stuff
<marcan>
but hey, better than not working
<marcan>
either way if this needs u-boot fixes that would be on top of what you did so far so no reason to block it
<kaazoo>
I might have done it wrong, but u-boot is stil complaining about unknown oslog messages. Will post screenshot in a sec.
<marcan>
no, that's normal
<marcan>
I'm just worried about the buffer thing in linux
<marcan>
but I can look into that later
<marcan>
the way macos does it, oslog goes into a dedicated memory area, and if we're stuck with that I'm tempted to move this all to m1n1 and fix it for good there, but that doens't mean u-boot shouldn't know how to do this anyway.
<marcan>
could probably program that region into the DAPF and avoid DART handoff pain that way
<marcan>
but yeah, let me worry about that
<marcan>
I'm making assumptions here about the problem
<_jannau_>
kettenis: any updatess on your asahi,efi-system-partition support patch? I'd be happy if we could get rid of the patched distro_bootcmd
<kettenis>
_jannau_: got conflicting reactions on that one
elvishjerricco has quit [Read error: Connection reset by peer]
<marcan>
kaazoo: that's all normal
<marcan>
we don't do anything with oslog
<marcan>
we just handle the init and ignore all the messages
<marcan>
I don't particularly care how it works as long as it doesn't break
<kettenis>
kaazoo, marcan: that commit message probably needs a bit of tweaking to be acceptable upstream
<kettenis>
is it ok if I do that and keep kaazoo's s-o-b?
<marcan>
yeah, that's generally OK
<kaazoo>
let me replace the s-o-b
<kaazoo>
marcan: if we don't care about those messages, then I can also remove that print statement in u-boot
<marcan>
sigh, yeah, oslog keeps its dva alloc across restarts :(
<marcan>
sorry, this probably should go in m1n1 then, but yeah, you can remove the print statement
<marcan>
we just probably won't be invoking this codepath any more in u-boot
<marcan>
much easier to deal with this in m1n1 with the DAPF than try to handoff mappings
<marcan>
why is rtkit such pain...
<marcan>
I wonder if there is some codepath to clear this out, I should probably throw the firmware into ghidra and check before I spend time moving this to m1n1
elvishjerricco has joined #asahi-dev
<marcan>
actually I wonder if we can just... give it an SRAM address?
<marcan>
though it kind of looks like it ORs in some high bits, hmm
<marcan>
huh, but it does look like it works
<marcan>
ok, I think we're going to do that, which does in fact mean more special-casing for u-boot needed
<marcan>
(but keeps it out of m1n1)
<marcan>
kaazoo: your patch is correct as far as handling that in general, but we're going to need an extra special case based on a device tree property here
<marcan>
kettenis: I think you should land it as is and I can add the new thing on top
<marcan>
let me play around with ghidra just to make sure there isn't an easier way, if not we'll go the SRAM route
<kettenis>
thanks; I'll merge it and tweak the commit message before sending it upstream
<kaazoo>
OK, thanks
<kettenis>
argh, why did it create a merge commit for that...
<kaazoo>
Did anybody look into wifi support on j414 with 13.3 FW yet? How is wifi stuff connected? PCIe? lspci shows nothing
<marcan>
PCIe and it should show up
<jannau>
did we add the right pwren gpio to the devicetree?
<kettenis>
it shows up for on openbsd
<kettenis>
driver needs some changes; on openbsd I end up in the equivalent of brcmf_chip_sysmem_ramsize() but the code in that function is wrong
<marcan>
oh wow the MTP firmware literally has an OS_LOG segment that does *not* get put into SRAM but rather contains all the strings for the oslog entries, which themselves just have pointers to them
<marcan>
I guess this is basically "compressed logs"
<kaazoo>
kernel log says: nvme-apple 34bcc0000.nvme: RTKit: syslog message: apcie.c:428: APCIe 1 is configured as unused.
<kettenis>
the android bcm4389 driver has different code there handling two different cases and none if that matches what the asahi linux brcmfmac driver does
<jannau>
kaazoo: ignore pcie related messages from nvme-apple, nothing to do with pcie
elvishjerricco has quit [Read error: No route to host]
<kaazoo>
Is PCIe perhaps partly disabled in device tree?
<jannau>
no, it workls on the m2 pro mini. have you enabled it in your kernel config?
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi-dev
cylm has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
<povik>
will u-boot under some conditions turn off power domains?
<kettenis>
no, but it will do resets
<povik>
if explicitly invoked from a device driver, right?
<kettenis>
yes
<povik>
hm
<jannau>
povik: I saw the sio boot failures without u-boot
<povik>
yeah, me too
<povik>
this is to tie the hypothetical loose ends of an experiment i did
<jannau>
ah, I thought it was in relation to seing those only in full-os installs
<povik>
yeah, i ran the full-os install under hypervisor, skipping over u-boot, and still saw them
<povik>
before that i tried patching the in-kernel pwrstate to never turn off domains, did a bunch of reboots, and saw them too
<povik>
but that was with u-boot, so i am making sure it's safe to conclude power domains (even being transitionally turned off) are not to be blamed
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: No route to host]
benpoulson has quit [Remote host closed the connection]
benpoulson has joined #asahi-dev
elvishjerricco has joined #asahi-dev
elvishjerricco has quit [Read error: Connection reset by peer]
<kaazoo>
Anything missing for PCIe support on M2 Pro? General PCIe support is enabled.
kaazoo has quit [Quit: Leaving.]
<_jannau_>
kaazoo: missing CONFIG_PCIE_APPLE, are you building a kernel with 4k page size (ARM64_PAGE_SHIFT == 12)?
kaazoo has joined #asahi-dev
<_jannau_>
kaazoo: missing CONFIG_PCIE_APPLE, are you building a kernel with 4k page size (ARM64_PAGE_SHIFT == 12)?
hightower2 has quit [Ping timeout: 480 seconds]
kaazoo has quit [Read error: Connection reset by peer]
<j`ey>
' DMA: preallocated 4096 KiB GFP_KERNEL pool for atomic allocations' seems so
<j`ey>
(that's created with gen_pool_create(PAGE_SHIFT..)
kaazoo has joined #asahi-dev
<alyssa>
chadmed: ahahaha nice
<alyssa>
I admittedly don't understand what that commit does :)
<j`ey>
kaazoo: as jannau said, wrong PAGE_SIZE, rebuild with 16K
<kaazoo>
There is a sleep button (moon icon) on my now functional keyboard. Seems like the machine went to sleep when I pressed it while trying out all buttons, but the display driver (llvmpipe) didn't come back and the screen stayed dark. Caps-lock worked, so I guess the machine came back from sleep/idle/whatever.
<chadmed>
alyssa: it adds DSP for the desktop speaker to make it less trash
<marcan>
seriously, you might be better off starting from scratch if the base you have is such a mess of random patches and bad branches and ancient workarounds that haven't been relevant for a year+
<tobhe>
fwiw anything in scripts/asahi isn't actually in use, I should have deleted it long ago
<kaazoo>
I'm using t6020 u-boot branch. Not the one referenced in tobhe's repo
<tobhe>
these are just leftovers from when I forked the original version from pop
<marcan>
ok yeah then you should probably delete those
<tobhe>
done.
<alyssa>
chadmed: yeah, I just have zero context for what's actually happening
<alyssa>
I guess the provided .wavs are filters and all the audio is convolved with those filters?
<alyssa>
and the filters are provided as audio file (.wav) because filters are data and data are filters?
<_jannau_>
t6020 is a slightly wrong u-boot branch but it shouldn't matter as long you use it with asahi-wip and have only a single other OS install. there is no correct branch yet with t602x support
<povik>
alyssa: it's a waveform and has a sample rate and format exactly like any audio signal would have
<alyssa>
povik: yep yep yep got it :)
<chadmed>
alyssa: yup all the filters are represented as an impulse response over the input signal on that virtual sink, with the convolved output sent to the hardware
<alyssa>
seems reasonable!
<alyssa>
(I know convolutions only from image processing, since, well, yes)
<chadmed>
significantly less bandwidth here id say :P
<alyssa>
for sure
<povik>
i guess convolution kernels are images too, over in the image processing land :)
<povik>
could the SIO be getting some unexpected IRQs due to bad interaction with one of our drivers?
<marcan>
it also helps that in audio data is already signed, while typical images are unsigned :p
<alyssa>
which, frequency bands need to be adjusted to do that
<marcan>
depends on the speaker :p
<sven>
and usually also on the room unfortunately:(
<sven>
probably not an issue for those small speakers though
<marcan>
yeah but at that point you're running your own room EQ if you care :)
<marcan>
yeah
<marcan>
room EQ matters more for deep bass
<sven>
yeah, that’s pretty much what mine does
<marcan>
you can't really do room EQ for anything higher, it's always a huge mess
<marcan>
but you can at least correct the speakers
<sven>
doesn’t help that my speakers are too close to my walls as well
<kettenis>
just use headphones ;)
<sven>
I EQ those as well because their bass is a bit lacking otherwise :D
<marcan>
I put an IR on my headphones :D
<sven>
IR?
<chadmed>
impulse response
<kettenis>
at least that doesn't depend on the room ;)
<TheLink>
only manufacturer's quality variations
<chadmed>
kettenis: yeah but having a big ol component system with big ol floorstanders is just so nice
<sven>
ah, I just have some parametric filters I found somewhere for my headphones and adjusted them a bit
<chadmed>
i think the last time i eqed a set of headphones was when i had some shockingly bad corsair gaming thing that was nothing but mids
<povik>
let's see, what about the MCA IRQs?
<sven>
I have a hd600 which is pretty good except for the weak bass. much more enjoyable after bumping that up a bit
<povik>
we don't manage those, as evinced by the recent discovery that t6000 had them wrong in DT
<TheLink>
sven: I regretted that I didn't get the hd600 again after mine died -- the hd663 has much worse bass
<chadmed>
i wish they did the 600s in the lovely beige and brown they have the 580s in
<chadmed>
when i was still working front of house i had a pair of 280s i took everywhere, they were seriously good for the price
<sven>
Let’s maybe move to off topic ;)
<TheLink>
*660s
<TheLink>
sorry
<axboe>
jannau: overnight and moving to office suspend, all good on resume. not unexpected as it clearly was the watchdog, but just noting it regardless
korreckj328 has quit [Ping timeout: 480 seconds]
hightower2 has joined #asahi-dev
<_jannau_>
axboe: thanks, good to know. the watchdog issue would have hiddenany long running suspend issue
<axboe>
yep
<axboe>
also nice to pull the laptop out of the bag and it not being lukewarm!
<povik>
huh
<povik>
it really looks like it spins because of an IRQ?
<povik>
CPU_STATUS is 0x8
<povik>
then i do mon.add(0x236400000, 0x4000)
<povik>
which maybe clears it because of read sensitive registers
<povik>
then i finally get a reply in the mailbox waiting on which timed out before
<povik>
or... i am confusing myself
<povik>
we will see
<povik>
oh, i forgot after i read the read sensitive registers CPU_STATUS changes to 0xc
<povik>
which is in line with interpreting BIT(2) as IRQ_NOT_PEND
zjstraus has quit [Ping timeout: 480 seconds]
<povik>
never mind i switched what INBOX and OUTBOX means, so i don't seem to have gotten the reply
zjstraus has joined #asahi-dev
kettenis has quit [Remote host closed the connection]
kettenis has joined #asahi-dev
kaazoo has left #asahi-dev [#asahi-dev]
nyilas has quit [Remote host closed the connection]
<marcan>
povik: IIRC I did see similar behavior for IRQ_NOT_PEND when testing something like mailbox messages, the FIQ one was a guess
<marcan>
so that one is proobably right
bcrumb has joined #asahi-dev
bcrumb has quit [Quit: WeeChat 3.8]
pharonix71 has joined #asahi-dev
kaazoo has joined #asahi-dev
<kaazoo>
After hopefully correctly switching to 16K page size and enabling PCIe driver, lspci shows these Broadcom devices:
<kaazoo>
01:00.0 Network controller: Broadcom Inc. and subsidiaries Device 4434 (rev 04)
<kaazoo>
01:00.1 Network controller: Broadcom Inc. and subsidiaries Device 5f72 (rev 04)
<kaazoo>
Is brcmfmac the right driver? I wasn't loaded automatically and also doesn't detect anything when loading it manually.
<kaazoo>
Could it be that we need to add the product ID of the wifi nic to the driver's list of supported devices?
<jannau>
brcmfmac is the correct driver, adding the product id will not be enough, see waht was said earlier today on the topic
bps has quit [Ping timeout: 480 seconds]
kaazoo has left #asahi-dev [#asahi-dev]
axboe has quit [Remote host closed the connection]
Tomdownsouth has joined #asahi-dev
<marcan>
kaazoo: The new chips are not supported yet, there is a known set of things we need to implement for every new chip
axboe has joined #asahi-dev
<marcan>
IDs, SRAM offset, OTP offset, plus (hopefully zero but possibly not) firmware API changes
maximbaz has quit [Quit: Ping timeout (120 seconds)]
maximbaz has joined #asahi-dev
<jannau>
dcpext works now reliably on every second try. there has to be something which is not reset properly
gladiac has quit [Quit: k thx bye]
bps has joined #asahi-dev
benpoulson has quit [Remote host closed the connection]
Jamie has joined #asahi-dev
rhysmdnz has joined #asahi-dev
Jamie is now known as Guest12357
eiln has joined #asahi-dev
rhysmdnz has quit [Quit: Reconnecting]
rhysmdnz has joined #asahi-dev
bps has quit [Ping timeout: 480 seconds]
alyssa has joined #asahi-dev
<alyssa>
marcan: Maybe coincidental lack of luck, but I think USB regressed between gpu/rust-wip UAPI version 7 and 8
<alyssa>
I connect a USB keyboard + mouse directly to the Mini's type-A ports
<alyssa>
Previously these probed immediately on boot
<alyssa>
After bumping my kernel, they didn't work. Got to my TTY and nothing from the keyboard. The LED on my mouse lit up (so I know it was getting power) but not properly animated (so it wasn't working properly)
<alyssa>
Eventually some amount of plugging and unplugging and waiting and they both showed up and worked
<alyssa>
when unplugging, I got an error on the TTY (seemingly) so
<alyssa>
I'm not sure what gpu/rust-wip is on top of, I would be unsurprised if this is some random USB regression in linux-next unrelated to anything we do
<alyssa>
but figured I'd say something in case it's not a spurious issue
<alyssa>
let's find out if I can reproduce.
<alyssa>
yep, reproduces every boot for me
<alyssa>
type-c appears to also be affected but IDK if that's a recent regression, I don't use type-C regularly on the mini
<alyssa>
I am really hoping this is a known issue and I can revert some linux-next patch because woof
<alyssa>
not in the mood to try to bisect this, tbh.
<alyssa>
undecided whether I will revert my kernel and use uapi v7 until fixed or just suck it up and deal with it
<alyssa>
I don't want to block Lina over this, at the same time I really do kinda need my keyboard to work Lol
<alyssa>
oh geez I just reverted my kernel and now it's also broken? uh?
<alyssa>
am I losing it
<alyssa>
and now the new kernel is working?
<alyssa>
no this is the old kernel
<alyssa>
i am definitely losing it
<alyssa>
yeah, this is definitely a regression
<alyssa>
the dmesg is really interesting
<alyssa>
In the new kernel, it tries to probe my keyboard 30+ times before it finally goes through
<alyssa>
[ 12.063632] usb 3-1: new high-speed USB device number 22 using xhci_hcd
<alyssa>
[ 12.198004] usb 3-1: New USB device found, idVendor=05ac, idProduct=1006, bcdDevice=96.15
<alyssa>
[ 12.198016] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
<alyssa>
[ 12.198022] usb 3-1: Product: Keyboard Hub
<alyssa>
[ 12.198027] usb 3-1: Manufacturer: Apple, Inc.
<alyssa>
[ 12.198031] usb 3-1: SerialNumber: 000000000000
<alyssa>
The working kernel was on ec153d79a5da ("drm/asahi: Identify more Render fields & update to UAPI 10007")
<j`ey>
thats based on 6.3, not -next
<alyssa>
j`ey: I see. Well, still doesn't rule out an upstream regression...
<j`ey>
previous was based on 6.2
<alyssa>
*nod*
<j`ey>
soo yeah, a regression between those
<alyssa>
Also possibly relevant, I have my YuniKey plugged into the keyboard
<alyssa>
(i.e. the hub is actually being a hub)
<alyssa>
it's a really shitty hub, I can't even plug a mouse in, not enough power available
<alyssa>
but it's been good enough for the key
<alyssa>
I could try removing the key and rebooting, but, meh,.
<alyssa>
trying not to get nerdsniped too far from my original mission of "test Lina's changes"
<alyssa>
git log
<alyssa>
I think I'm going to merge Lina's change, but if you could look at this maybe Monday, I would appreciate
<alyssa>
in other news, glmark2-es2 -bterrain is a bit faster than it used to be
<alyssa>
not bothering to bisect way but happy to see it break the 300 barrier ^^
<alyssa>
j`ey: Do you know if we've released any 6.3 kernels to end users in Asahi?
<alyssa>
(I.e. is this "Alyssa's setup is weird and hit some weird issue becasue of it" or is it "absolutely real regression that Alyssa hit before everyone else did")
<alyssa>
(For the former, I think I might be building my kernel with clang because I don't know how Rust for Linux works. Or maybe it's gcc. Unsure ^_^)
<j`ey>
alyssa: I dont think so yet
<j`ey>
nope, 6.2 is still whats in the packages
WindowPain has quit [Read error: Connection reset by peer]
WindowPain has joined #asahi-dev
dax has joined #asahi-dev
brolin has joined #asahi-dev
kettenis has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
kettenis has joined #asahi-dev
_rudi1 has joined #asahi-dev
_rudi has quit [Ping timeout: 480 seconds]
<alyssa>
alright, hopefully we can figure it out before bumping users!
piroko has quit [Ping timeout: 480 seconds]
<jannau>
I haven't noticed any USB-A issues on the mac mini with a directly connected lenovo compact keyboard with 6.3-rc4 or 6.3 based kernels but I wouldn't have necessarily spotted issues which occur occasionally
<alyssa>
2 boots in a row
<alyssa>
I *think* this has to do with the keyboard being a hub
<alyssa>
judging by the dmesg spam
kettenis has quit [Ping timeout: 480 seconds]
brolin has joined #asahi-dev
nsklaus has quit [Quit: Zzz]
eiln has quit [Read error: Connection reset by peer]