marcan changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-stream #asahi-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
yuyichao has quit [Ping timeout: 480 seconds]
amw has joined #asahi
psykose has joined #asahi
psykose has quit [Remote host closed the connection]
psykose has joined #asahi
nctcf^ has quit [Ping timeout: 480 seconds]
darkapex1 has joined #asahi
darkapex has quit [Ping timeout: 480 seconds]
littledust3403[m] has joined #asahi
<marcan>
I bet it just takes a while to boot after a reset...
phiologe has joined #asahi
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
kov has quit [Quit: Coyote finally caught me]
c10l8 has joined #asahi
c10l has quit [Ping timeout: 480 seconds]
palmer_ has joined #asahi
palmer_ has quit [Remote host closed the connection]
crabbedhaloablut has joined #asahi
loki_val has quit [Ping timeout: 480 seconds]
loki_val has joined #asahi
crabbedhaloablut has quit [Ping timeout: 480 seconds]
marvin24_ has joined #asahi
marvin24 has quit [Ping timeout: 480 seconds]
cth451_desktop has quit [Remote host closed the connection]
kajiryoji has quit [Ping timeout: 480 seconds]
chamomile has quit [Ping timeout: 480 seconds]
squags_ has quit [Ping timeout: 480 seconds]
squags has joined #asahi
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi
squags has quit [Ping timeout: 480 seconds]
cth451_desktop has joined #asahi
squags has joined #asahi
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi
sailorek1234 has joined #asahi
<aead>
Once everything is merged and well supported, how well is Linux expected to be able to handle the heterogenous cores in the M1 / M1 Max? Does the scheduler have good support for "big.little"?
<aead>
It seems to me the answer could be one of three things: it's good at knowing which threads belong on the big and little cores; or, it's aware of the difference in compute capacity and just schedules all threads proportionally to each core's rough performance; or it doesn't do much special
bgb has joined #asahi
<aead>
(I Googled a little before asking it _seems_ like 2 might be the answer based on a paper about teaching CFS how to treat cores proportionally, but concrete info seems kinda thin)
<sorear>
remember that big.LITTLE has been a reality for Android for years and that's in the upstream kernel
<aead>
yeah but I'm curious how smart the scheduler is really. It seems like Apple does a great job of putting the "right" threads on each core because it exposes an API for userspace to tell the kernel what the QoS of the process is
<aead>
which, if that does exist on Linux now (not sure?) it's unlikely anything would make use of it anyway
<aead>
it seems it'd have to pull some really clever tricks to do the same thing just based on pure heuristics
<aead>
(and smartphone SoC manufacturers are notorious for not upstreaming their device-specific tweaks, AFAIK)
<BlitzWorks>
lwn has some good articles on what it does and does not do
<aead>
oh I'll restrict my search to lwn. good point!
<BlitzWorks>
try looking for the 'sched' schedule policy
<kode54>
I mean, macOS also tends to want to shove background/idle threads onto the LITTLE cores so they use less power overall
<kode54>
while it also tends to put interactive tasks and foreground apps on the big ones
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
bgb has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi
<FireFox317>
can anyone here run the release version of macos 12.0.1 kernel under the hypervisor? it gets stuck in the beginning of the boot process for me
<FireFox317>
so apparantly something is removed from the adt and macos doesnt like that
<j_ey>
I didnt think m1n1 changed the adt though..
<_jannau_>
are you booting from the right startup disk? i.e. the one which has mac os 12.0.1 installed?
<FireFox317>
_jannau_, oh that might be it
<FireFox317>
the startup disk is set to the one that has m1n1 installed
yuyichao has joined #asahi
as400 has joined #asahi
<as400>
jannau: I have a question - keyboard patches are not included in your PKGBUILD. Am I right ?
<j_ey>
as400: yes
<FireFox317>
_jannau_, nope same panic. Previously I could just set the startup disk to the m1n1 partition and still boot macos under the hypervisor.
<as400>
May I ask why ?
<FireFox317>
The panic message suggests that something is missing in the adt
<FireFox317>
hmm, does each partition/os install have a different adt? then it may be using the old adt from 11.something to boot 12.0.1
<_jannau_>
as400: preliminary policy for patches to be included is either in asahilinux/linux or submitted to a linux mailing list and I didn't had time for more yet
<_jannau_>
firefox317: I think since macos 12 each install uses and probably requires a matching last stage iboot. hence my question about the startup disk
<j_ey>
as400: you can quite easily cherry pick them if you want to
<as400>
j_ey: thx. I will as soon as my mbp arrives.
<FireFox317>
_jannau_, ah okay. But i cant set the startup disk to the macos install and still boot m1n1 to run the hypervisor right? so i think my only option is to update the firmware on the m1n1 partition to 12.0.1 right?
squags has quit [Read error: Connection timed out]
<_jannau_>
firefox317: I'm not sure that anything except using m1n1 as custom boot object on the mac os install you want to virtualize is going to work
squags has joined #asahi
<_jannau_>
you can probably modify the ADT or boot args to tell the kernel which partition is the system partition
<FireFox317>
_jannau_, but you cant install m1n1 on the same partition as the mac os install right? I think apple designed it in a way that each os install has its own firmware version, and thus adt version
<FireFox317>
they are on the same disk (nvme), but not the same partition
<_jannau_>
you can configure m1n1 as custom boot object on every mac os install / volume group. That's different from the asahi installer use case. The installer is designed for a separate linux install
<FireFox317>
_jannau_, aha okay that makes sense. I had m1n1 installed on a seperate partition
<FireFox317>
_jannau_, is it documented somewhere how to install m1n1 on the same mac os install?
gabuscus_ has quit [Read error: Connection reset by peer]
gabuscus has joined #asahi
gabuscus has quit [Ping timeout: 480 seconds]
gabuscus has joined #asahi
bgb_ has joined #asahi
bgb has quit [Ping timeout: 480 seconds]
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi
<FireFox317>
_jannau_, wait, so from macos 12 m1n1 has to be in the same container for the hypervisor to work? I just updated m1n1 with the installer (in a seperate container), but it still fails to boot
<FireFox317>
macos is now panicking with: 'rootvp not authenticated after mounting @bsd_init.c:961'
<as400>
did anyone get kyboard to work on mbp m1pro ?
<mps>
as400: what is 'mbp m1pro', old one from previous year or new model
<mps>
I'm lost in their naming scheme
<_jannau_>
as400: yes, it should work on the 14/16 inch macbook pros. you need to add the SPI node to t6001.dtsi
darkapex2 has joined #asahi
<as400>
mps: Macbook Pro M1 Pro 2021
<as400>
jannau: do you have this node somewhere around ?
<as400>
I'm absolutely not comfortable with dtb stuff
<mps>
as400: aha, thanks (have to find 'market' name for one I have)
<mps>
I don't know details but because keyboard works maybe these patches could be sent to kernel ML
<kettenis>
marcan will undoubtly tell you they need cleaning up (and I'd agree with him)
<j_ey>
I agree!
<j_ey>
I have a new SPI driver, just not pushed anywhere yet
<_jannau_>
I started looking into adding a spi hid transport
<as400>
Does the touchpad also work ? Or some other property has to be added ?
<j_ey>
touchpad should work
nctcf^ has joined #asahi
<j_ey>
_jannau_: oh cool
<sven>
would be nice to get a spi driver on the ML at some point
<kettenis>
it may make sense to add the min/max coordinates for the touchpad in the device tree
<kettenis>
since it seems those vary between models
<kettenis>
and msybe properties describibg the keyboard layout/language
<j_ey>
sven: Ive been delaying it since I felt like some more understanding of the hw could be good. but maybe its not that important
<mps>
as400: in my build touchpad is detected and work with evtest but not with xorg or consolation (daemon which uses libinput on consoles for handling pointing devices)
<sven>
j_ey: as long as there’s no obscure magic or similar weird things it might be good enough. Did you write that driver from scratch?
<sven>
it should be fairly simple since the HW probably doesn’t even do DMA
<_jannau_>
I think apple does spi dma through sio
<sven>
yes
squags has quit [Ping timeout: 480 seconds]
<sven>
but I still suspect that SIO just uses a busy loop then
<mps>
probably I didn't refactored patches correctly
<j_ey>
sven: i used the register defs and stufd from corellium
<kettenis>
that might actually be a legacy from how this worked in the T2
<kettenis>
I don't think there is a point in making it more complicated than necessary
<sven>
agreed
<FireFox317>
_jannau_, so i can just reduce the security of my main macos partition and then use kmutil to make it boot m1n1? without actually overwriting the actual macos kernel
<sven>
imho just start with a simple driver that doesn’t do DMA and only add that later if it makes sense
<j_ey>
sven: i think i sent you the driver, you can see its quite simple. its just some of the register bits that felt a bit weird
<sven>
hmmm… I might’ve forgotten about that. sorry :(
<kettenis>
since that saves me renaming things in the OpenBSD driver ;)
<kettenis>
the CLKCFG and CLKIDLE bits are maybe a bit questionable
<sven>
i think for clk_prepare_enable the same comment i got for my watchdogv1 applies. technically you should only disable the clock after devm has unregistered the spi controller so you should use devm_add_action_or_reset or however it's called
<sven>
in practise it just doesn't matter because the clock is just a dumb constant frequency clock anyway
squags has quit [Ping timeout: 480 seconds]
<sven>
and yeah, i agree with kettenis that CLKCFG and CLKIDLE sound weird
<sven>
REG_AVAIL_TXFIFO as well because it seems to do available = FIFO_SIZE - REG_AVAIL_TXFIFO
<kettenis>
the "AVAIL" register actually contains the FIFO levels
<kettenis>
maybe the register needs a better name
<sven>
yeah
squags has joined #asahi
squags has quit [Ping timeout: 480 seconds]
squags has joined #asahi
<sven>
j_ey: so REG_AVAIL just contains the fifo levels and the max value it takes is 0x10 here
<sven>
that should explain the FIFO_SIZE
kov has joined #asahi
<sven>
BIT(4) in there might be something like tx_fifo_full
bingoChecker has joined #asahi
bgb_ has quit [Read error: Connection reset by peer]
bgb_ has joined #asahi
ianlienfa[m] has joined #asahi
<as400>
jannau: could you loan me your .config ?
<marcan>
mps: see this is why we don't send corellium drivers to the kernel ML
<marcan>
because they are mostly wrong :p
<marcan>
(those weird defs came from there)
<marcan>
we're not going for "it works" here, we're going for maintainability and correctness, and that means doing things right
artemist has quit [Ping timeout: 480 seconds]
<marcan>
j_ey: also, do you think you can implement runtime-pm in that spi driver? that'd be another good test case for the pmgr stuff, and it should be easy to add (and does not add a hard dependency in either direction)
<j_ey>
marcan: I can take a look. im not exactly sure what runtime-pm does.. (im assuming turn stuff off if its idle?)
<marcan>
yes, suspend the device when it is idle. it's what tells pmgr to turn it off.
<_jannau_>
as400: I have no config with enabled keyboard. you need APPLESPI and the config the spi driver introduces
<marcan>
j_ey: look at the patch to add runtime-pm to the samsung driver for an example; also there's a good chance some other SPI driver has it too
<marcan>
the important thing is MMIO will be inaccessible while suspended, so you need to make sure to always resume it before doing anything
<sven>
j_ey: oh, and unless you enjoy hearing maz rant again: _relaxed everywhere :D
<marcan>
that too :p
<mps>
marcan: yes, I understand your stance on this because I'm one who always (nearly) insist on correctness first but sometimes ... I'm impatient
<marcan>
unfortunately being impatient doesn't make things go faster :(
<mps>
yes, I agree. and had my fingers 'in fire' whenever I was impatient
artemist has joined #asahi
<mps>
in last decade I had to work in financial applications field and my knowledge on hacking hardware vanished (mostly) so I can't help with making some drivers and fixes, just could test what all you make
<maz>
sven: I like that I don't have to say anything anymore. the _relaxed police is now doing its job! :D
<marcan>
:D
<marcan>
maz: btw, did you see that the PERST patches apparently break 10G NICs? my guess is it just takes longer to initialize after PERST...
<maz>
marcan: where was that reported? 100ms is quite a long time, but I wonder if it could be that the 100us delay before releasing #PERST is too short.
<marcan>
here, see cth451_desktop's last message
<marcan>
unfortunately there's no dmesg of the failed case
<marcan>
(people, please provide logs!)
<maz>
could also be that the DT hasn't been updated to take care of the polarity.
<maz>
and please report things over email. I'm not scanning this channel looking for problems!
<kettenis>
difficult to diagnose problems when people combine random trees with random DTs
bgb has joined #asahi
bgb_ has quit [Read error: Connection reset by peer]
<as400>
jannau: I have them enabled but it restarts config on me. Is this how it's supposed to be using your PKGBUILD ? I'm cross compiling - not sure if it makes any difference.
<FireFox317>
marcan, how did you find out that the AVD needs firmware? I'm trying to trace the device, but i'm not seeing the firmware getting copied
<sven>
if it's the same co-proc like the others it'll just put the firmware somewhere in RAM and write a pointer to some configuration register
bgb_ has joined #asahi
<FireFox317>
sven, hmm yeah that makes sense. The ADT also states that a DART is used, so maybe that's why i dont see the writes?
<sven>
the wires are to RAM, that's why you don't see them
<sven>
*writes
<sven>
it'll just map the firmware using the DART then
sailorek1234 has quit []
<FireFox317>
sven, oh ofcourse. I think it makes more sense now
<sven>
i'd expect it to write a pointer to the first 0x8000 bytes of the MMIO region (i.e. the region just before the mailbox interface)
bgb has quit [Ping timeout: 480 seconds]
<j_ey>
sven: yes i have relaxed now! :D
<as400>
kov: it's ok now - thx. Which model do you have ?
<kov>
as400, I have the Air, waiting for a Pro 14" Max to be delivered
<as400>
How long does MBA go on battery on Linux ?
<kov>
not sure, haven't measured that yet, I don't think it'd be representative at this point anyway
aleasto has joined #asahi
<as400>
yes, you're probably right. But it would be nice starting point if somebody measured it and then we could compare it after few months.
<marcan>
sven: I'm not even sure if AVD has the same mailbox though
<marcan>
it's not an ASC style thing as far as I could tell
<sven>
oh, hrm. true
<marcan>
it's just a random M3 core they threw into that IP block
<sven>
hrm, might be more similar to the thunderbolt co-proc mailbox then
<sven>
that one's at least called "M3"
<marcan>
or just custom
<marcan>
it's not an m3wrap
<marcan>
it's just "there happens to be an m3 inside avd"
<sven>
hrm, okay. probably custom then
<marcan>
firefox317: I was poking around ioreg to find out what codecs/levels it supports, and I found a firmware-size property and that set all the alarms ringing
<marcan>
I looked at the kext and it has the firmware embedded (a whole bunch actually, for different IP core versions)
<FireFox317>
yep presumably supports ADS HEVC AVC and H264
<as400>
I'm trying to compile kernel with keyboard support for t6001 but it seems I'm missing "pinctrl_nub" node. Anyone knows how to define it ?
nctcf^ has quit [Remote host closed the connection]
<kettenis>
should use apple,t6000-pinctrl instead of apple,t8103-pinctrl
<as400>
jannau: thx - you're the saviour.
<as400>
kettenis: thx - I was going to ask this question
<_jannau_>
the hw decoder support vp9 as well
<_jannau_>
kettenis: not that it makes a practical difference. t600x support still PoC and needs cleanup
<kettenis>
sure
<kettenis>
the driver matches on apple,pinctrl
bgb has joined #asahi
bgb_ has quit [Ping timeout: 480 seconds]
<marcan>
firefox317: AVC is H264 and I don't think it supports Adaptive DNA Storage...
<marcan>
it supports AVC, HEVC, and VP9
<marcan>
though apple calls VP9 some weirdo internal codename I forget all throughout their driver stack, because I guess it was secret or they're allergic to calling it VP9 or something?