marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | "Does XXX work yet?": https://alx.sh/fs | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-alt #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
Guest3132 has quit [Ping timeout: 480 seconds]
aratuk has quit [Remote host closed the connection]
aratuk has joined #asahi
nafod has quit [Read error: Connection reset by peer]
nafod has joined #asahi
aratuk has quit []
rayanamukami3 has quit [Ping timeout: 480 seconds]
akspecs_ has quit [Remote host closed the connection]
akspecs has joined #asahi
rayanamukami3 has joined #asahi
zef_ has joined #asahi
zef has quit [Ping timeout: 480 seconds]
rayanamukami3 has quit [Ping timeout: 480 seconds]
rayanamukami3 has joined #asahi
julio7359 has quit [Ping timeout: 480 seconds]
kesslerd has quit [Remote host closed the connection]
julio7359 has joined #asahi
Zopolis4 has joined #asahi
wintp has quit [Quit: Connection closed for inactivity]
thansen has quit [Read error: Connection reset by peer]
Lazlo has quit [Quit: ZNC 1.9.x-git-251-64da93f7 - https://znc.in]
thansen has joined #asahi
thansen has quit [Read error: Connection reset by peer]
<sven>
mort_: I don’t know much about the idle code but from those LKML threads it seems to me that the issue is on the core code
<sven>
*in
<mort_>
sven: the issue that it doesn't work without a cpuidle driver is in the core code, I'm looking at maybe being able to use the cpuidle-arm driver on the M1
<chadmed>
cpuidle-arm relies on calling into firmware to handle psci doesnt it?
<chadmed>
like isnt that the whole problem
thelounge98 has joined #asahi
<mort_>
chadmed: yes, but it gets those idle states from the devicetree: and it has a hard coded wfi idle state that doesn't rely on psci. If there was a way to tell it to activate, but not give it any idle states other than the default wfi one, I don't see any reason why it wouldn't work
<mort_>
I made a kernel like that yesterday but I must've messed up building it somehow, everything worked including sddm except that plasma failed to start due to a bunch of Qt errors..
<mort_>
so I didn't get to test whether the idle thing actually worked or not before going to sleep
<chadmed>
right right so your plan is to just hack in a path where it keeps the core in WFI if theres no psci interface available?
kettenis_ is now known as kettenis
thansen has joined #asahi
<mort_>
well, just remove the code which says, "if there was no additional idle states in the devicetree, don't activate the driver"
<mort_>
then if that was ever to be upstreamed I suppose we'd need to add another devicetree thing which lets you opt in to using the cpuidle-arm driver despite not having additional idle states, as it is it would try to activate on any system if the aforementioned check is removed
DarkShadow44 has joined #asahi
thansen has quit [Read error: Connection reset by peer]
thansen has joined #asahi
<chadmed>
if idle-states has binding documentation you could propose just adding "wfi" as a valid value or somethign
<chadmed>
then have the driver probe based on that
<chadmed>
that way you dont need to introduce any _new_ checks per se
<chadmed>
just "go to this code if the idle state is wfi"
<chadmed>
its easier for us to add stuff to our devicetrees that we maintain than it is to get totally new bindings and mechanisms upstreamed
commandoline has joined #asahi
<mort_>
the issue is, at the moment, all devices with additional psci devices get wfi for free, it's not listed in the devicetree anywhere; and all the logic to add idle states from the devicetree are highly psci specific and the function has psci in the name
commandoline has quit []
<mort_>
I don't see a clean way to make that code add a wfi idle state without possibly breaking existing devicetrees or at least making kinda semantically weird changes to make psci code card about wfi
commandoline has joined #asahi
<mort_>
the logic is pretty much, "Here's the set of PSCI idle states", not "Here's the list of idle states, this one and that one happens to use PSCI"
<sven>
I’d really just hack it for now since the proper solution is sone psci-like conduit anyway
<sven>
*some
<mort_>
Hmm. Thinking about it from an upstream perspective: one approach would lead to a generic arm cpuidle driver which at least makes WFI idle work on non-PSCI devices, and then non-PSCI devices could add their own hardware specific cpuidle driver as they get to that point. The other approach leads to the one psci driver being the only option on arm,
<mort_>
so non-PSCI devices don't even get WFI idle until they have made a hack to make their hardware look like it supports PSCI to the rest of the kernel
<mort_>
I won't argue against the second approach since I don't know enough about it, but it feels a bit weird
<mort_>
maybe Apple's power management stuff is PSCI-like enough that tapering over the differences makes sense
<j`ey_>
there isn't power management stuff!
<mort_>
does macOS also just use WFI?
<j`ey_>
well I mean the macOS kernel must do the stuff, for PSCI it's firmware that does it, PSCI just does a hvc/smc
<j`ey_>
but there's no higher exception level, since m1 only supports up to EL2
as400 has quit [Remote host closed the connection]
as400 has joined #asahi
thansen has quit [Ping timeout: 480 seconds]
<mort_>
turns out plasma fails to start when installing an edge kernel from an h modified Asahi pkgbuild as well, that's odd. Does anyone know what exact PKGBUILDs commit the current edge kernel was built from?
<mort_>
maybe it breaks because my cbindgen is too new? There was a warning about that but I assumed cbindgen would at least be backwards compatible
nyilas has quit [Remote host closed the connection]
<chadmed>
try using bindgen-cli not cbindgen
<chadmed>
theyre actually different things afaict
<chadmed>
did you install the corresponding mesa package too?
<chadmed>
the uapi is not stable and the kernel tags usually only work with one or two mesa commits before it breaks again
<mort_>
I mean, I have a mess and a kernel which work together from the repos, I would expect that if I compile my own identical kernel from the exact same kernel source code it would work with the mesa from the repos
<mort_>
the only explanation I can think of is that the kernel isn't actually identical because of bindgen version differences or other toolchain differences
<chadmed>
for the latest released tag you should be using rust 1.62 and the bindgen-cli crate
<chadmed>
which will install bindgen into your cargo env
<chadmed>
rust tooling can be super annoying, especially since kernel rust hasnt really settled yet
<mort_>
so far I've used bindgen from the repos
<mort_>
and yeah, I've done some rust development and the tooling is always kind of a pain.. especially since everyone seems to be using nightly features so you need a nightly rustc but not one that's too new so that the nightly feature has changed
<mort_>
I hope the language eventually matures, to the point that there are few breaking changes, no reason to use nightly features, and no more essential tooling and libraries on a 0.x version
hightower2 has joined #asahi
<mort_>
chadmed: hmm I need to install bindgen-cli 0.56.0 I'm guessing (since that's what the warning says is expected), but on the only versions on crates.io are 0.61-0.64?
<mort_>
I suppose I'm grabbing the source for 0.56 from github and installing from there
Zeroine has joined #asahi
ciggi has quit [Ping timeout: 480 seconds]
<mort_>
regarding speaker safety: we already have mechanisms in the kernel for making things happen when the process using a hardware device exits. For example, if a process opens a v4l2 device, calls IOCTL_STREAMON on it, and then crashes, the driver automatically cleans up and stops streaming frames from the device. If there was some SAFEMODE_ON and
<mort_>
SAFEMODE_OFF pair of ioctls, presumably the macaudio driver could automatically run SAFEMODE_OFF when the process which called SAFEMODE_ON exits?
<mort_>
(sorry, I was just reading about the fail safe thing in speakersafetyd's readme)
<mort_>
err and I accidentally swapped SAFEMODE_ON and SAFEMODE_OFF a few times, hopefully the meaning came through
<chadmed>
chadmed: 0.61 works fine, 0.64 hard deprecated a flag the kernel folks still use so thats a no no
<chadmed>
mort_: err sorry meant to ping you not myself :P
<mort_>
haha :p
<mort_>
interesting that 0.64 didn't straight up error then, huh
<chadmed>
also re speaker safety we need something that the daemon can kinda poll while its not streaming since the idea is for the codec to go into safety mode (a special hardware register mode) when the deamon doesnt kick the driver
<chadmed>
we cant just keep a stream to the pcm open all the time since we need to be able to change sample rate etc
<chadmed>
and also that would be wasteful as the daemon would be constantly doing operations on a zeroed buffer
<chadmed>
waste of cycles
<chadmed>
the daemon needs to be able to stop all that and just keep kicking the driver
<mort_>
is it to protect against the daemon crashing, or is it also supposed to protect against the daemon freezing somehow?
<chadmed>
the driver should kick the codecs into safe mode upon any condition where it cannot be satisfied that userspace is guaranteeing safety
<chadmed>
this process should be transparent to userspace entirely as the safe mode register does not smush the DVC register or any other setting we expose to userspace
<mort_>
it has to be either told from the userspace that userspace isn't doing its job, or have some other mechanism to detect that userspace isn't doing its job; the proposed "ping" approach would let the driver automatically detect when the userspace daemon has crashed or frozen somehow, right? Since the driver would no longer be getting pings
<chadmed>
yeah exactly, the driver should go "huh havent heard from userspace in a while it probably died" and put the codecs into safe mode
<chadmed>
ideally id like there to be a module parameter to suppress this behaviour because i want to run without the daemon myself (to dogfood userspace dsp safety and easily run tests on new devices without patching the kernel)
<mort_>
what I'm thinking would be possible is: represent the speakers as a device (/dev/macspkr?), speakersafetyd opens that device and gets an fd, calls MACAUDIO_SAFETYOFF on it, that makes macaudio set the speakers in the not-safe mote, and then if either the daemon calls MACAUDIO_SAFETYON *or* the fd is closed (because the process crashed or
<mort_>
something), the macaudio driver sets the speakers in the safe mode
<chadmed>
isnt that just an ioctl with extra steps?
<mort_>
MACAUDIO_SAFETYON and MACAUDIO_SAFETYOFF would be ioctls :p
<chadmed>
yeah that makes sense
<mort_>
that would mimick the VIDIOC_STREAMON + VIDIOC_STREAMOFF/exit-the-process-to-streamoff behavior of video4linux, and would catch the case where the daemon crashes (but not the case where the daemon freezes)
<chadmed>
would the driver have to poll for the file descriptor
<mort_>
I think Linux has mechanisms for letting you do arbitrary cleanup stuff when a device fd closes?
<mort_>
I assume video4linux drivers don't poll in order to do cleanup when a process which has called VIDIOC_STREAMON exits
<mort_>
I sadly only have experience from the userspace side of video4linux (and some printk debugging on the kernel side) so I don't know the details
<chadmed>
i looked into v4l when i first started tracing avd months and months ago and wanted to cry
<mort_>
haha
<chadmed>
the lack of avd support should be all you need to know how that endeavour ended
<mort_>
ok this is really weird, I compiled the kernel from the linux-asahi pkgbuild, from that "linux-asahi: bump to 6.1.asahi2-2" commit, with bindgen 0.56 and rustc 1.62, and qt is still sad
<chadmed>
run asahi-diagnose and paste it somewhere and link here
<chadmed>
same with whatever qt errors youre getting
<mort_>
https://p.mort.coffee/Iqs here's the journalctl log, look near the end for all the qt errors when trying to log in to the plasma wayland session from sddm
<chadmed>
can you try dbus-run-session startplasma-wayland from a tty?
<mort_>
I think the log ended up with a bunch of boots, not just the current, I suppose I should've said journalctl -b 0 rather than just journalctl or something. Not that it matters
<chadmed>
you didnt build DRM_ASAHI
<chadmed>
or if you did its not loaded
<mort_>
hmm the config.edge has CONFIG_DRM_ASAHI=m
<chadmed>
try modprobing it i guess
<chadmed>
somethings funky though
<chadmed>
maybe your device trees need updating with the ones from the kernel tag youre building
<mort_>
the kernel tag I'm building is the same as the one from the repos as far as I can tell
<mort_>
chadmed: what's the drm driver? appledrm is listed in lsmod
<chadmed>
thats the dcp driver
<chadmed>
the gpu driver is just called asahi
<chadmed>
DRM_ASAHI is its kconfig switch
<mort_>
if I install linux-asahi-edge from the repos, /lib/modules/6.1.0-asahi-2-2-edge-ARCH does indeed contain an asahi.ko.zst; if I install my own linux-asahi-edge-6.1.asahi2-2-aarch64.pkg.tar.gz, there is no asahi.ko.zst in /lib/modules/6.1.0-asahi-2-2-edge-ARCH, so you're definitely on to something
<mort_>
no mention of DRM_ASAHI in /proc/config.gz on my own build; not even a '# CONFIG_DRM_ASAHI is not set' comment
cy8aer has quit [Remote host closed the connection]
cy8aer has joined #asahi
maanil_ has joined #asahi
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
bisko has joined #asahi
c10l has quit [Quit: Bye o/]
Zopolis4 has quit []
balrog has quit [Remote host closed the connection]
maanil_ has quit [Quit: Page closed]
maanil has joined #asahi
maanil has quit []
ciggi has joined #asahi
maanil[m]_ has joined #asahi
maanil[m]_ has quit []
Mali has joined #asahi
<Mali>
Hi all, I am tempted by the compilation benchmarks of ARM silicon, and willing to get a macbook to run Asahi on in.
<Mali>
The issue is I need to be able to cross compile embedded ARM targets with that
<Mali>
In short, need to be able to setup a dev environment for Rust and embedded targets
<j`ey_>
mali: shouldnt be any issue with that
<Mali>
I checked Rust Embedded channels but thos who saw it have no idea
<Mali>
thanks j`ey
<Mali>
I recently saw someone's post about the fact that for dev use cases Asahi is pretty mature
<mort_>
the only issues you're gonna encounter from a development standpoint is that not everything might work with ARM Linux, for example Yocto has some issues with using ARM Linux as a build machine (but toolchains generally support ARM Linux build machines no problem)
delsol has joined #asahi
<Mali>
@mort_ I always thought of yocto to be a distro for RPi
<jannau>
vendor provided toolchains are probably x86_64 only
<mort_>
yocto is a system to build your own Linux distro, you can use it to make a distro which works on the raspberry pi but you can also use it for all kinds of other embedded Linux use cases
<mort_>
at the company I work use Yocto to build the system images we put on our embedded Linux products
<Mali>
@mort_ I see that now.
<Mali>
@jannau Just checked, and yes it seems that most people use Rosetta to ru them on ARM Macs
<Mali>
@mort_ Now I use community maintained HALs from Rust Embedded WG
<Mali>
But, well, not entirely sure that will continue to be so.
<Mali>
But, I presume with more effort, one can setup a dev environment with GCC or LLVM or similar.
possiblemeatball has joined #asahi
<Mali>
The build speeds are really tempting.
<mort_>
mali: what you could do is to set up some arm linux virtual machine with qemu or something, and see if you're able to set up a dev environment which does what you need
<Mali>
Ah ha.
<Mali>
Is there a pointer that you can give for that
<Mali>
If you have
<Mali>
Let me try QEMU, I always thought of that in terms of low level emulator
<Mali>
For Thumb2 or similiar
<Mali>
but evidently it can virtualize a wholes system
<Mali>
thanks
kesslerd has joined #asahi
<mort_>
Are you familiar with Docker or Podman? I *think * you should be able to basically just say: podman run --platform linux/arm64 -it ubuntu:22.04
<mort_>
that might be the easiest approach
<Mali>
This is disappointing but my current machine is a Windows
<mort_>
it will start a qemu virtual machine and handle that part for you
<Mali>
I also design the hardware
<mort_>
ah
<Mali>
and I use Altium
<Mali>
But there are Win binaries
<Mali>
I will give that a try
<mort_>
using software development tools on Windows is easier than using hardware design tools on Linux sadly, so I get you
kesslerd has quit [Quit: Konversation terminated!]
<Mali>
Well, yes. but I see that KiCAD is really good.
<Mali>
But, I am library-locked.
<mort_>
oh you're doing the CAD not the PCB design
<Mali>
Both, I thought KiCAD also did both
<Mali>
By the way, which is the Apple ARM silicon
<Mali>
aarch64?
<mort_>
ah you're right, KiCAD has a built-in EDA tool. I've only used it for CAD
<Mali>
there is also aarch64w
<mort_>
apple silicon is aarch64 (I have never heard of aarch64w and google doesn't seem to know about it either?)
<Mali>
They have Python scripting, sometimes there comes a plugin that even I am jealous, having paid like 6k to Altium
<Mali>
`qemu-system-x86_64 -machine help`
<Mali>
gives me a list of targets but apple is not explicitly there
<j`ey_>
you need qemu-system-aarch64, and the m1/apple wont be on that list
<j`ey_>
it doesnt emulate the m1, but you could use the 'virt' machine to try get a setup working, and that's likely to work on the m1 too
kesslerd has joined #asahi
<mort_>
as long as you've verified that the toolchain works on some aarch64 machine it'll work on the m1 mac as well
<mort_>
err, I suppose there's a possibility for the page size thing to be an issue?
<mort_>
you'll have a high confidence that it will work on the m1 as well
<Mali>
perfect thak you all
<Mali>
*thank
iaguis has joined #asahi
<iaguis>
Retr0id: thanks for your fixup script for widevine, works like a charm!
balrog has joined #asahi
delsol has quit [Remote host closed the connection]
bisko has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<jannau>
mort_: see what the PKGBUILD does to generate the config:
<jannau>
you don't need to replicate the rest of the pkgbuild if you want to build just your own edge kernel
<jannau>
also make sure that you can build rust with `make rustavailable`
<mort_>
right now I'm trying to just get a kernel build to work at all, so I'm starting with the one that's as close as possible to the existing linux-asahi-edge I have installed
<mort_>
I wonder if it was just that I hadn't properly cleaned out the build directory after building with bindgen 0.64 earlier...
Mali has quit [Ping timeout: 480 seconds]
Bey0ndB1nary has joined #asahi
chipxxx has joined #asahi
chipxxx has quit [Remote host closed the connection]
chipxxx has joined #asahi
bluetail9 has quit [Ping timeout: 480 seconds]
ladyTel has joined #asahi
maria has quit [Ping timeout: 480 seconds]
gladiac has joined #asahi
ladyTel has quit [Quit: Konversation terminated!]
ciggi_ has joined #asahi
ciggi has quit [Ping timeout: 480 seconds]
ciggi_ has quit [Ping timeout: 480 seconds]
Bey0ndB1nary has quit []
Fischmiep has joined #asahi
delsol has joined #asahi
Major_Biscuit has quit [Ping timeout: 480 seconds]
ciggi has joined #asahi
bluetail9 has joined #asahi
maria has joined #asahi
zshrc has joined #asahi
zshrc has quit [Ping timeout: 480 seconds]
delsol has quit [Remote host closed the connection]
zshrc has joined #asahi
delsol has joined #asahi
zshrc is now known as Guest6969
zshrc has joined #asahi
delsol has quit [Remote host closed the connection]
Guest6969 has quit [Ping timeout: 480 seconds]
zshrc has quit [Quit: leaving]
gladiac has quit [Quit: k thx bye]
___nick___ has joined #asahi
bluetail94 has joined #asahi
___nick___ has quit []
___nick___ has joined #asahi
guillaume_g has quit []
___nick___ has quit []
bluetail9 has quit [Ping timeout: 480 seconds]
___nick___ has joined #asahi
delsol has joined #asahi
i509vcb has quit [Quit: Connection closed for inactivity]
delsol has quit [Read error: Connection reset by peer]
i509vcb has joined #asahi
delsol has joined #asahi
Mali has joined #asahi
delsol has quit [Remote host closed the connection]
Zopolis4 has joined #asahi
giskard has joined #asahi
giskard has quit []
delsol has joined #asahi
iaguis has quit [Quit: leaving]
possiblemeatball has quit [Quit: Quit]
D-Spirits has joined #asahi
possiblemeatball has joined #asahi
Metroid has quit [Quit: See you Space Cowboy]
___nick___ has quit [Ping timeout: 480 seconds]
Metroid has joined #asahi
thansen has joined #asahi
roxfan2 has joined #asahi
roxfan has quit [Ping timeout: 480 seconds]
<i509vcb>
I assume the firmware or something provides enough info to set the proper "iso_layout" but it has not been implemented or handled yet?
<jannau>
i509vcb: yes, the information should be available but it a little bit scathered
bluetail94 has quit []
artemist has quit [Quit: artemist]
artemist has joined #asahi
delsol has quit [Remote host closed the connection]
delsol has joined #asahi
Droop has quit []
D-Spirits has quit [Quit: D-Spirits]
Droop has joined #asahi
delsol has quit [Ping timeout: 480 seconds]
<mort_>
I see what y'all mean with packaging issues... I just tried to install bear (the make compile_commands.json tool), but the package from the alarm repos is linked against libspdlog.so.1 and libfmt.so.8 even though the repos provide packages with libspdlog.so.1.11 and libfmt.so.9 files
malte has joined #asahi
c10l has joined #asahi
<ayke_>
mali: if most of the work you do is programming (not hardware design), you could perhaps use MacOS for the hardware parts? Closed source software (like Altium) is unlikely to support aarch64-linux but if it supports macOS then you could do the hardware design parts in there.
malte has quit [Ping timeout: 480 seconds]
<Mali>
@ayke_ thank you for the help. Unfortunately Altium is Win only, but I already have a machine for that, and it is capable enough.
<Mali>
My issue is the rust compilation times, I realized that I procrastinate a lot while long builds (:
<ayke_>
Ah, well if it's open source then I'm like 90% sure it'll work just fine. It's closed source software that can be a problem.
<Mali>
It is proprietary unfortunately.
<ayke_>
I mean the Rust parts
<Mali>
ah yes, I guess so
<mort_>
I don't remember the numbers exactly but my desktop with a monster r9 5950x is not *that* much faster than my m1 pro laptop at compiling rust
<Mali>
I am not sure if arm toolchain is open
<mort_>
I mean it's faster but significantly less than 2x faster iirc
<Mali>
Yes, that is why I am interested.
<mort_>
a whole lot of rust compilation is limited in core count, which means the 5950x's core and power advantage doesn't come in to play as much as one might expect
<Mali>
I am coparenting, therefore a laptop is welcome
<Mali>
And M2 benchmarks are really impressive. I have a gen7 intel machine now. It takes ages
<mort_>
M2 is significantly less well supported than M1 for the moment
<ayke_>
If all else fails, you could run Windows software in a Windows ARM64 VM (under MacOS, at least until Windows ARM64 runs in KVM). At least in theory you should be able to run x86 software that way.
<mort_>
heh I don't expect the software to work with arm windows
<j`ey_>
mort_: m2 is well supported
<mort_>
or do you mean using windows's rosetta-style thing
<ayke_>
Yes exactly
<ayke_>
That's probably still a lot faster than QEMU.
<mort_>
j`ey_: right, I was thinking about M2 pro/max
<Mali>
I have read somewhere that M2 was in essence not so different
<Mali>
Ah this is good info
<Mali>
So M2 is supported
<ayke_>
M2, but not M2 pro/max
<Mali>
well, but M2 Pro is in the backlog
<ayke_>
Yeah I don't expect it to take very long
<ayke_>
mali: when I switched to a MacBook that was a 10x performance increase (not exaggerating). It's certainly more productive to have a fast system.