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
brolin has quit [Ping timeout: 480 seconds]
Guest12331 has quit []
vx has joined #asahi
vx is now known as Guest12368
martinr1 has quit [Ping timeout: 480 seconds]
martinr1 has joined #asahi
Zopolis4_ has quit []
jamespmo_ has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
jamespmorgan has quit [Ping timeout: 480 seconds]
julio7359 has joined #asahi
brolin has joined #asahi
martinr1 has joined #asahi
possiblemeatball has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
Brainium has quit [Quit: Konversation terminated!]
martinr1 has joined #asahi
julio7359 has quit [Ping timeout: 480 seconds]
martinr1 has quit [Ping timeout: 480 seconds]
elvishjerricco has joined #asahi
elvishjerricco has quit [Read error: Connection reset by peer]
brolin has quit [Ping timeout: 480 seconds]
brolin has joined #asahi
julio7359 has joined #asahi
gabuscus has quit []
martinr1 has joined #asahi
elvishjerricco has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi
gabuscus has joined #asahi
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi
elvishjerricco has quit [Read error: Connection reset by peer]
rvalue has joined #asahi
_rudi1 is now known as _rudi
elvishjerricco has joined #asahi
julio7359 has quit [Ping timeout: 480 seconds]
martinr1 has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
brolin has quit [Ping timeout: 480 seconds]
elvishjerricco has quit [Read error: Connection reset by peer]
julio7359 has joined #asahi
brolin has joined #asahi
elvishjerricco has joined #asahi
martinr1 has joined #asahi
elvishjerricco has quit [Read error: Connection reset by peer]
elvishjerricco has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
martinr1 has joined #asahi
marvin24_ has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
marvin24 has quit [Ping timeout: 480 seconds]
possiblemeatball has quit [Quit: Quit]
brolin has quit [Ping timeout: 480 seconds]
martinr1 has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
Tolik2000 has joined #asahi
Tolik2000 has quit [Remote host closed the connection]
martinr1 has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
Tolik2000 has joined #asahi
<Tolik2000>
Hello everybody
<Tolik2000>
How protected the hardware is? I mostly mean pstate and power domain stuff, and also SPI flash chip with boot data. Can we play around safely with what is enabled in DT? Is there some protection that only allows access to the NVRAM partition, blocking access to other parts of the NOR chip? Also, can it be harmful if cpu or gpu pstate data is modified in DT? We weren't able to determine where those were used for. Can DT mods be used to over/under-clock/vo
<Tolik2000>
Is /dev/mtd0 the nvram partition, or the whole chip?
<Tolik2000>
By power domain stuff I mean both bad power curves and pstates as well as sequencing and other stuff with turning it on off
<Tolik2000>
I heard SMC manages power, throttle etc. But then why do we have to use those power curves and fp math for GPU?
martinr1 has joined #asahi
<marcan>
Tolik2000: yes, only the nvram partition is exposed in the DT
<marcan>
CPU pstate data is informative only, it is not used by the driver
<Tolik2000>
It means /dev/mtd0 doesn't contain other data like iboot config stuff?
<marcan>
GPU pstate data is passed to the firmware but it is unclear whether that actually sets the voltage/frequency or is only used for power estimation and pstate control
<marcan>
so "we don't know, mess with it at your own risk"
<Tolik2000>
So the cpu opp-microvolt and opp-microwatt is to calculate estimated power for, e.g. EAS to work? Got it
greguu has joined #asahi
<marcan>
CPU pstates shouldn't even have those properties right now?
<Tolik2000>
Maybe only in experimental eas branches?
<marcan>
though we will add at least microwatt for EAS
<marcan>
yeah
<marcan>
microvolt isn't even constant
<marcan>
voltages are calibrated per-device
<marcan>
the GPU data is replaced with ADT data in m1n1
Zopolis4_ has joined #asahi
<marcan>
so the values in the template DT don't even matter
<marcan>
(just the OPP count)
<Tolik2000>
Got it, thanks
<Tolik2000>
And common PD stuff should be safe to turn on/off since critical stuff is on direct SMC control? I mean for kernel infrastructure and driver testing / experimenting
<marcan>
we've screwed things up like that in the past (also clobbering all GPIO registers) and nobody has destroyed any hardware yet
<marcan>
worst case the thing just locks up or reboots
<Tolik2000>
Well, I know some ways of rebooting easily. ACIO is my faw
<Tolik2000>
C* fav lol
<marcan>
I'd be more worried about the GPU stuff since it's a ton of tables and we just don't know how critical it is (lina has been very careful to get the data the same as macOS or almost)
<marcan>
but outside of that yeah, I don't think you can break anything
<marcan>
SMC has a watchdog, if you crash it it reboots your machine within 30 seconds
<Tolik2000>
It's runtime computed from ADT props?
<marcan>
yes, and leakage fuses and other stuff
<marcan>
it's complicated
<marcan>
and the power estimates aren't 1:1 with macOS but it's close enough
<marcan>
(and the formulas macOS uses there don't seem to be very well behaved either)
<Tolik2000>
Great job!
<marcan>
but there's other tables and stuff unrelated to that max power estimate thing which is basically 1:1 identical to macOS as far as I know
<marcan>
within 1 LSB tolerance
<Tolik2000>
I've seen the broken curve on one of the Lina's streams
<marcan>
yeah that one's a WTF
<marcan>
tells me that one estimate doesn't really matter :p
<marcan>
but some of the other stuff might, nobody knows what half of those numbers do
<marcan>
so best get it the same as macos
<Tolik2000>
Glad to know that this hw is not only mighty, but also rock solid, at least while speakers an
<Tolik2000>
*are muted
<marcan>
tbh considering how pstates are handled for everything else by init in iBoot and locked as far as I know, I actually expect the GPU to be the same
<marcan>
so you probably can't actually overclock/overvolt it by messing with those tables either
<marcan>
and it's probably just for fancypants power estimates in the firmware
<marcan>
but that's just a guess
<Tolik2000>
I believe speakersafetyd is first in class thing not tied to android?
<marcan>
yeah
<marcan>
android stuff is typically done in firmware anyway, at least partially
<marcan>
though I've seen some of the code that shuttles IV data between the DSP firmware and the hardware in android
<marcan>
(when I was researching this stuff)
martinr1 has quit [Ping timeout: 480 seconds]
<Tolik2000>
Well, GPU driver is to be trusted for those configs, it gets 100x the robustness thanks to Rust, so should make initdata decent anyway
<Tolik2000>
Okay, thanks for the great explanation of these cool machines!
<marcan>
I plan to help set up a CI at some point for this
<marcan>
should get lina to write an initdata comparison test for it
<marcan>
then we can automatically test that kernel versions keep correct initdata across all supported firmware/device combinations
<Tolik2000>
Just unit test? Or integration on hardware?
<marcan>
actual hardware
<marcan>
like have known good macOS initdata dumps, run the linux kernel on the hypervisor, dump initdata and compare
<Tolik2000>
Oh cool
<marcan>
I need to figure out if I'm repurposing some of the machines I have or buying dedicated CI machines :p
<marcan>
will come along with some major home server revamp I have planned for the next few months
<Tolik2000>
Your security and robustness principles are as good to be taught to any teamlead
<marcan>
:)
<marcan>
last thing I want is to destroy users' hardware
<Tolik2000>
Yeah. I remember some macos update required DFUing machines which had had their main board replaced. What was QA doing lol
<marcan>
oh we actually have that problem
<marcan>
the 12.3 we ship by default on M1 series is that version
<marcan>
but since it's only a OS install, you don't need DFU to fix it
<marcan>
I have 12.3.1 in expert mode for the like 2-3 users who have hit this
<Tolik2000>
But DFU path helps a lot since MacBook can be flashed without special tooling
<marcan>
never bothered to promote it to default because we'll probably switch to 13.3 soon for everything
<marcan>
yeah
<Tolik2000>
Have they broke system-wide or only asahi is unbootable?
<Tolik2000>
Got it
<marcan>
it's just the asahi os firmware so it just bootloops after the first reboot on install, but you can just let it eventually give up and it'll go into recovery
<Tolik2000>
How would 13.3 help older devices? Less maintenance burden, or some nice bug fixes?
<marcan>
newer features probably, alyssa wants some GPU stuff she thinks needs newer firmware
<Tolik2000>
What was the problem? iBoot bug?
<marcan>
yeah
<marcan>
re gpu, unclear yet which is why I probably won't ship 13.3 coincident with the M2 Pro/Max release for older devices
<marcan>
but eventually it should be supported across the board
<Tolik2000>
M2X is planned right after you get time to add WiFi/BT support?
<marcan>
yeah
<marcan>
there's also the risk that apple actually stops hosting old IPSWs for some reason which would really suck, or that they stop signing older OSes for security reasons
<marcan>
so it's best not to get stuck on one firmware version for older devices even if we don't strictly need to upgrade
<marcan>
no reason to upgrade frequently but every now and then, yeah
<Tolik2000>
Cool job on M2X, they're mostly ready in a month after you got time to work in that direction
<marcan>
yeah, it's usually about a month of actual time for new devices, sometimes less
<Tolik2000>
Well, and they likely fix bugs in GPU/DCP as well
<marcan>
the Mac Minis are still a problem but I hope sven and jannau figure out the display stuff
<Tolik2000>
And at that moment other external displays should be available as well?
<Tolik2000>
Cool
<marcan>
I mean no display works on the new Minis
<marcan>
because of the change in the primary display controller
<marcan>
so we'll release M2X for laptops only at first unless that gets fixed really soon
<Tolik2000>
Laptops have main DCP unmuxed, thus impossible to reroute to thunderbolt?
<marcan>
but it'll be available in expert mode for people who want to use them as headless servers and don't mind hacking around the boot process to work around not having an obvious console
<marcan>
the hardware should support muxing, but iBoot initializes it and it's unclear whether DCP firmware allows re-routing, and either way it means our existing code works
<marcan>
it's just that isn't initialized on the new desktops
<marcan>
and it's even still unclear whether we can even init that with the iBoot protocol any more, or whether we need to go and implement full DCP in m1n1
<marcan>
which would kinda suck
<marcan>
but we'll find out when that gets fixed on the Linux driver and we try to backport it to m1n1
<marcan>
crossing my fingers that in the end we only need to implement one or two EPIC/AFK endpoints and not the main dcpep
<Tolik2000>
Any chances basic m1 and m2 could reuse their dcp as a dcpext?
<Tolik2000>
Like using 2 screens in clamshell mode
<Tolik2000>
Or dcp internal doesn't have displayport encoder?
Tolik2000 has quit [Remote host closed the connection]
<marcan>
m1, not as far as I know
<marcan>
m2 if the firmware supports itr
<marcan>
as far as we know m1 does not have the main DCP crossbared into the other ports
<marcan>
m2 does
<marcan>
but that still depends on the main DCP firmware being happy with the concept of having its internal screen replaced with an external port at runtime
<marcan>
personally I wouldn't consider it viable until macOS implements it
<marcan>
since if that works at all, not having it be a codepath tested in macOS is a sure fire way for explosions and bugs
<marcan>
DCP does a *lot* more things for internal panels so switching between that and ext mode is a major firmware state change
Tolik2000 has joined #asahi
<Tolik2000>
What can go wrong?
jamespmorgan has joined #asahi
<marcan>
I mean it does things like handle the backlight, including brokering storing backlight staging data (on some eeprom I think, I don't think the OS is involved)
<Tolik2000>
Like persistent harm or so
<marcan>
I'm worried about screwing up the persistent backlight aging stuff on the 14"/16" machines since that could cause aging effects over very long periods of time that are impossible to test
<marcan>
anyway, we'll see
martinr1 has joined #asahi
<Tolik2000>
MiniLED has some housekeeping inside the DCP?
<Tolik2000>
Yes, then better follow macOS way
<jannau>
I don't have high hopes for dptx + dcp_iboot on m2/m2 pro minis as long as apple doesn't init displays in iboot for the desktop systems
<Tolik2000>
But currently it should be fine, no time it asks OS to save stash data? All done inside DCP itself.
<Tolik2000>
&?
jamespmo_ has quit [Ping timeout: 480 seconds]
mexpr has quit [Remote host closed the connection]
<Tolik2000>
I mean is enabling dcp beneficial on M1 Pro or M2 Pro 14"? It should manage backlight properly at the current driver state? Does it also fully match traces under HV?
mexpr has joined #asahi
<marcan>
yes, I'm not aware of the OS being involved and it wouldn't make sense since you can have multiple macOS installs
<marcan>
but it does complain if you pause it for too long under the HV (both macOS and Linux)
sjg has quit [Read error: Connection reset by peer]
msteffen has quit [Read error: Connection reset by peer]
loops has quit [Read error: Connection reset by peer]
Illya has quit [Read error: Connection reset by peer]
sjg has joined #asahi
Nezteb has quit [Read error: Connection reset by peer]
pipppero has quit [Read error: Connection reset by peer]
risk has quit [Read error: Connection reset by peer]
jbowen has quit [Write error: connection closed]
Nezteb has joined #asahi
pipppero has joined #asahi
msteffen has joined #asahi
loops has joined #asahi
joshtaylor has quit [Read error: Connection reset by peer]
risk has joined #asahi
joshtaylor has joined #asahi
Illya has joined #asahi
jbowen has joined #asahi
<marcan>
actually on startup too, so it's possible this isn't being handled properly for non-dcp framebuffer mode in current non edge kernels
<Tolik2000>
I like how these machines are smart even though they don't have SMM firmware on the main cpu
<marcan>
but DCP is going to be promoted to default real soon now anyway
martinr1 has quit [Ping timeout: 480 seconds]
<Tolik2000>
SMC basically prevents any power/heat damage etc. DCP abstracts so much stuff inside. Great thing they're generous on those small AArch64 coprocessors
<Tolik2000>
What does complain? DCP oslog or so?
<Tolik2000>
What kind of interaction it needs from OS? Swaps? Should be buggy, but still fine on x11?
<marcan>
dcp syslog
<marcan>
and I'm actually not sure, might just be callbacks? I don't remember those warnings under x11...
<marcan>
you wouldn't expect absence of swaps to cause that
<Tolik2000>
Alright. So basically checks if kernel acks callbacks maybe
<marcan>
so maybe it just gets stuck sending random callbacks to the OS and if callback processing stops that stalls the backlight housekeeping
julio7359 has quit [Ping timeout: 480 seconds]
<Tolik2000>
Nice thing it complains if caused to glitch. No way to miss erroneous behavior
Tolik2000 has quit [Remote host closed the connection]
<jannau>
I don't remember seeing random dcp callbacks when tracing X11 but I would expect it to complain if you stopped the AP in an ongoing swap
cylm_ has joined #asahi
<sven>
marcan: i have no Mac Mini with the typec hdmi mess display, that’s all on jannau :>
martinr1 has joined #asahi
<jannau>
if type-c/atc weren't such a mess we could start with dp-altmode support
<jannau>
13.3 (maybe earlier and I missed it) changes the dptx interface in an incompatible way. there's a DPTX_APCALL_GET_MAX_LANE_COUNT inserted before get_active_lane_count
martinr1 has quit [Ping timeout: 480 seconds]
<jannau>
if that is already in 13.2 it would explain dptx not working in m1n1 on the m2 mini
<sven>
ugh
Tolik2000 has joined #asahi
<Tolik2000>
Oh, another question from the perspective of hw stuff. Is SMART data reported with smartctl preserved after DFU wipe and restore?
<Tolik2000>
It's interesting where the internal use region of the NVMe controller resides. Is it in one of the flash chips, or on-die within the SoC?
<Tolik2000>
I've seen some videos of people repairing M1 ssd with iPhone NAND chips, but no smartctl data in those
<Tolik2000>
I do think somebody has DFUed machines frequently for installer tests
<Tolik2000>
would be interesting to know how SMART changes during restore cycle
<Tolik2000>
it __is__ able of repairing NVMe service zone (or writing it from scratch into an empty supported NAND chip), but shouldn't wipe it while doing restore. Sure it doesn't touch that on revive
rhysmdnz has quit [Quit: Bridge terminating on SIGTERM]
Guest12357 has quit [Quit: Bridge terminating on SIGTERM]
Jamie has joined #asahi
rhysmdnz has joined #asahi
Jamie is now known as Guest12394
martinr1 has joined #asahi
cylm_ has quit [Ping timeout: 480 seconds]
martinr1 has quit [Ping timeout: 480 seconds]
martinr1 has joined #asahi
giskard has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
martinr1 has joined #asahi
marvin24 has joined #asahi
guillaume_g has joined #asahi
drubrkletern has quit [Remote host closed the connection]
marvin24_ has quit [Ping timeout: 480 seconds]
bps has joined #asahi
martinr1 has quit [Ping timeout: 480 seconds]
Zopolis4_ has quit []
nsklaus has joined #asahi
martinr1 has joined #asahi
mattgirv has quit [Ping timeout: 480 seconds]
martinr1 has quit [Ping timeout: 480 seconds]
martinr1 has joined #asahi
<tsujp>
is it possible to start krfb from the commandline? trying to connect via tigervnc wont work (prompts for a password but no password I enter works)
<tsujp>
I have set a password in ~/.config/krfbrc
tinstew has quit [Ping timeout: 480 seconds]
hightower3 has joined #asahi
hightower2 has quit [Ping timeout: 480 seconds]
tinstew has joined #asahi
tinstew has quit [Ping timeout: 480 seconds]
<tsujp>
Is it possible to do armhf on asahi currently?
<chadmed>
no the cores do not implement A32
<tsujp>
I assume my only chance at simulating a 32bit environment is to use something like FEX-emu then?
<j`ey>
qemu if you want 32-bit arm
<tsujp>
How does one change the page size of the kernel currently? Lina did a change to get it to 4K but I don't know what she did
<j`ey>
you have to rebuild the kernel
<jannau>
and you will lose PCIe devices (wlan, bt, sd card reader, usb-a ports, ethernet) until proper 4k support is ready
<jannau>
you can use a vm with 4k kernel though
maz has quit [Ping timeout: 480 seconds]
gordonfreeman has joined #asahi
gordonfreeman has quit [Remote host closed the connection]
VinDuv has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
VinDuv has joined #asahi
cafebabe has quit [Quit: Connection closed for inactivity]
<marcan>
Tolik2000: no idea whether SMART data survives DFU restore but there is no mutable nonvolatile memory within the SoC (or any other modern SoC, the process does not allow it). the data must be in the NAND chips.
cylm_ has joined #asahi
tinstew has quit [Ping timeout: 480 seconds]
balrog has quit [Quit: Bye]
jbowen has quit []
jbowen has joined #asahi
patwid has joined #asahi
balrog has joined #asahi
tinstew has joined #asahi
<patwid>
i have difficulty finding info whether hdmi audio works on the mac mini m1?
gordonfreeman has joined #asahi
<patwid>
have been searching on the official wiki feature support page and via google in general
<ChaosPrincess>
it doesnt, but there are wip patches for that
<_jannau_>
it is under development, works but is not integrated
<patwid>
thank you for claryfing!
gladiac has quit [Quit: k thx bye]
Agua has quit [Ping timeout: 480 seconds]
leahcl has quit [Remote host closed the connection]
leahcl has joined #asahi
unicordian has quit [Read error: Connection reset by peer]