ChanServ 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-offtopic | Keep things on topic | Logs: https://alx.sh/l/asahi
bisko has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
quarkyalice has joined #asahi
<hell__>
hablerentand[m]: most likely unrelated, but: judging by the timestamp of the `random: crng init done` log line, looks like your machine is short on entropy
quarkyalice has quit [Ping timeout: 480 seconds]
quarkyalice__ has joined #asahi
alicela1n has quit [Quit: Reconnecting]
alicela1n has joined #asahi
akemin_dayo has quit [Ping timeout: 480 seconds]
akemin_dayo has joined #asahi
Namidairo has quit [Ping timeout: 480 seconds]
aleasto has joined #asahi
bisko has joined #asahi
Namidairo has joined #asahi
Namidairo has quit []
Namidairo has joined #asahi
hashcheck has joined #asahi
yuyichao_ has quit [Ping timeout: 480 seconds]
<alyssa>
hell__: I noticed that on mine as well
<alyssa>
amw: That looks normal?
<alyssa>
When I tried, I wasn't getting feedback from the keyboard at the console directly
<alyssa>
but I was when the shell finally came up
<alyssa>
Incidentally, init=/bin/sh was broken for me, didn't investigate why. assuming it was spamming UART instead of onscreen
<alyssa>
`rw root=/dev/sda2 rootwait rootfstype=ext4` is to boot off usb, you'll need to adjust for your own partition alayout. in my case /dev/sda1 contains a kernel for a chromebook ;)
<alyssa>
`net.ifnames=0` works around broken systemd behavior
<alyssa>
notice I'm not specifying init=, I'm using the default systemd for debin
<pipcet[m]>
you're not using an initrd at all?
<alyssa>
no
<alyssa>
When I use Debian-built kernels I use the Debian initrd since things break otherwise, when I build my own kernel I don't use an initrd since I inevitably screw it up when rebuilding
<alyssa>
This does preclude FDE on the kernels I build myself ..
<marcan>
alyssa: if you enable CONFIG_RANDOM_TRUST_BOOTLOADER, it'll start up with enough entropy
<marcan>
m1n1 passes through the seed from iBoot
<alyssa>
marcan: what do u do if u dont trust iFoot
<sven>
(and to see [ 4.520198] apple-mailbox 23e400000.mbox: syslog message: apComms.cpp:372: SMC HID Event: 01 01 01 whenever you press the power button :D)
<pipcet[m]>
you get different messages if you hold it for a while, IIRC :-)
<pipcet[m]>
I've been meaning to write code for the lid switch (which works the same way on the MBP)
<sven>
one of the two ANS endpoints is called "smc" fwiw. still no clue what it does though
<alyssa>
sven: nice nice
<alyssa>
sven: sudden motion controller no wait
<alyssa>
system management coprocessor er
<alyssa>
actual answer in the wiki
<sven>
no, i mean
<sven>
there's SMC
<pipcet[m]>
the ANS has an SMC endpoint?!
<sven>
yeah, that
<sven>
it's at least called smc
<sven>
i dunno what it does though
<alyssa>
sven: could just be an interrupt line from the SMC?
<pipcet[m]>
(possibly it's for the SMC when it needs to talk to ANS without involving the AP?)
<sven>
alyssa: let me rephrase, the ANS has one mailbox channel called "smc"
<sven>
or maybe it needs to relay message to the SMC but can't talk to it directly?
<sven>
who know. i haven't seen any traffic on it
<pipcet[m]>
have you tried setting your device on fire? It might be for high temperature conditions!
<alyssa>
pipcet[m]: No, it's for sudden motion
<alyssa>
sven: Try dropping your device from 10m
<pipcet[m]>
set it on fire AND drop it on the floor
<sven>
i wrote the code, you get to test it ;p
<alyssa>
pipcet[m]: Good idea, thanks for volunteering
<pipcet[m]>
I've, uh, "tested" high temperature conditions by forgetting I was compiling stuff and putting my MBP back in the bag...
tbodt has quit [Ping timeout: 480 seconds]
<sven>
0x20 is called "ans2" and 0x21 is called "smc". no traffic on either of them when tracing under the hv yet
<pipcet[m]>
alyssa: sudden motion is just 0g detection, right? You're paying for my space trip.
<sven>
ugh. and ofc there's new merge conflics for the nvme platform split :(
Z750 has quit [Ping timeout: 480 seconds]
Simonx22 has quit [Ping timeout: 480 seconds]
tbodt has joined #asahi
Z750 has joined #asahi
jackhill has quit [Ping timeout: 480 seconds]
jackhill has joined #asahi
Andalu30 has joined #asahi
<pipcet[m]>
I suppose no one's done any work towards making the HV trace LDNP, LDADDL, etc.?
<sven>
what are those?
<pipcet[m]>
weird memory accesses that are probably never used for MMIO space, but are used for DMA memory
<sven>
oh, arm64 instructions. i thought they were dt nodes :D
<pipcet[m]>
sven: you've got a mini, right? How many SMC keys do you have?
<sven>
no idea
<pipcet[m]>
probably not relevant yet, but there are just too many of those...
<sven>
fwiw, i just get the SMC syslog messages so far
<sven>
so i can't send commands yet without writing more code
<pipcet[m]>
that is awesome, though!
<sven>
yeah, it's slowly getting there :)
<sven>
the code still has some rough edges that i'm not totally happy with but it seems to work for both ANS and SMC
<sven>
(and probably the others rtkit-based coprocessors as well)
<pipcet[m]>
which ones are rtkit-based? SIO, DCP, AOP?
<sven>
possibly everything except for the SEP
<pipcet[m]>
that would be wonderful, at some point we're going to figure out how to make that thing produce audio :-)
<sven>
grep -lr RTKit /System/Volumes/Preboot/*/boot/*/usr/standalone/firmware/FUD/ results in SIO, ISP, AVE, DCP, AOP, ANE, GFX, DCP2 (???) and PMP
<sven>
and ANS is missing there for some reason, but that's RTKit too
<alyssa>
sven: what about AVD?
<sven>
🤷♂️
<sven>
|- compatible:
<sven>
| avd,t8103
<sven>
looks like something special
<alyssa>
rtkit wasn't special enough?
<sven>
maybe it's just a special flavor of rtkit ;)
Orsira has joined #asahi
Orsira has quit [Remote host closed the connection]
tomtastic_ has quit [Remote host closed the connection]
<marcan>
sven: I do think ASCs can talk to each other's mailboxes somehow
<marcan>
so maybe it has to do with that, yeah
<marcan>
multiple readers won't work, but multiple writers would
<sven>
hm, true
<marcan>
so perhaps there is a variant protocol for ASC-to-ASC where they each write to each other's mailbox only in the input direction
<marcan>
that would require setting up an endpoint to just receive replies
<marcan>
(random-ass guess)
tomtastic has joined #asahi
<sven>
could be :)
<marcan>
alyssa: avd is not a copro
<marcan>
it's pure hardware as far as I saw
<sven>
all i know is that there's no data on either of those two endpoints when running mac os
<marcan>
there's no firmware for it
<marcan>
ave *is* a copro
<marcan>
DCP2 is dcpext
<marcan>
and yes the firmware is a copy
<marcan>
(there's two DCPs, one for internal panel, one for DP/TB attached)
<ave>
(wow, I have an unfortunate name :p)
<marcan>
sven: ANS is missing because it would be loaded from the iBoot1 blob and, unlike most everything else, actually has a stable ABI
<marcan>
so it doesn't have to match macOS versions, so not part of iBoot2 blobs
<marcan>
ave: whoops :)
<sven>
ah, makes sense
<marcan>
one thing I'm curious about is how they do DCP handover from iBoot1
<marcan>
they have to
<marcan>
so that thing must have a way of at least doing glitchess firmware reloads for iBoot framebuffer states
<sven>
SMC is weird btw., it exposes shared memory over the MMIO bus (with the nonposted requirements and everything)
<marcan>
I think I saw some of that
<marcan>
there's also the whole error reporting thing, right?
<marcan>
syslog goes to like three places
<sven>
i've only seen syslog to a buffer inside that shared memory thing
<sven>
but i also haven't talked to SMC yet except for the common rtkit stuff
<marcan>
one is that, one is uart, and I think it can sometimes go to SPI too?
<ave>
marcan, nah dw!
<ave>
I'll just mute notifs here
<sven>
oh, could be
<alyssa>
ave: you're pure hardware!
<alyssa>
no wait you're a coprocessor
<sven>
looks like the ANS firmware has a "smc_to_ans" string. so maybe it actually talks to the smc directly
<alyssa>
marcan: by the way, do we know if the firmwares are signed?
<alyssa>
and if not is there a way for eg m1n1 to load patched firmware (or would we have to futz with the preboot partition and break dual boot)
<sven>
i don't think those coprocessors have a bootrom, but we might not be able to reset them
<sven>
but i'm sure that iboot verifies their signature before loading them
<alyssa>
i did notice XNU loads AGX firmware specially.
<marcan>
alyssa: the firmwares are signed at the package level
<marcan>
they are not verified by the copros themselves
quarkyalice has joined #asahi
<marcan>
but we can't change them on disk
<marcan>
I think the intent is that iBoot locks them in RAM, so we're not supposed to be able to modify them
<marcan>
but I can't claim to have tried
<marcan>
alyssa: XNU does not load AGX firmware as far as I know
<marcan>
where do you see that?
<marcan>
it's on the preload list
<marcan>
(unless by "load" you mean "launch")
<sven>
it has _code_ to load these firmware, but i think that's dead code
<marcan>
yeah that
<marcan>
there's lots of such dead code
<marcan>
obviously they *used* to load firmwares in drivers
<marcan>
there's also a whole display driver that *doesn't* use DCP
<marcan>
but that's not how it's done on M1
<sven>
fwiw, i haven't been able to reset the ANS, even though there's code in some kext that allegedly does just that
<sven>
i think that's just leftovers as well
<marcan>
I do hope I can reset DCP, because I sure expect to crash and confuse it often
<sven>
(or maybe there's a bit somewhere to disable resetting them, who knows)
<sven>
yeah... i've done that to ANS
<sven>
it's not great :D
<marcan>
then again the m1n1 boot cycle is ~7 seconds which isn't *that* bad
<marcan>
ANS... I'd be more scared of
<marcan>
OTOH the flash on the other end is still PCIe, and possibly NVMe?
<sven>
unless you actively try to crash it it's kinda hard
<marcan>
if so at least you shouldn't be able to damage it too badly.... hopefully
<marcan>
anyway, /me -> sleep
<marcan>
yesterday and today have been, uh, days of unexpected things :(
<marcan>
(I'll let alyssa vouch :p)
<marcan>
hope I can stream tomorrow
<sven>
i've only managed to crash it by doing what mac os calls "sending a NMI" (makes sense :D), by sending invalid commands (who wouldn't panic there?!) and by telling to switch to a power state it's already in
<alyssa>
marcan: has had two days of unexpected things
<alyssa>
still not vouching unless i wake up to a dcp client tomorrrow ;P
<marcan>
:<
<alyssa>
😇
<Ariadne>
you guys are honestly killing this though
<alyssa>
Ariadne: i hope not, i'm nonviolent
<Ariadne>
i meant figuratively
<Ariadne>
:)
<alyssa>
😉
roxfan has joined #asahi
<pipcet[m]>
when macOS crashes hard enough (or I enter the hypervisor), the clickpad on the MBP stops clicking. It's the weirdest thing.
quarkyalice has quit [Ping timeout: 480 seconds]
<alyssa>
pipcet[m]: like the home button on new iphones?
<pipcet[m]>
does it do that too? what horrible kind of witchcraft is this?
<alyssa>
pipcet[m]: haptic feedback controlled in software so the user can configure the clickiness
roxfan2 has quit [Ping timeout: 480 seconds]
<pipcet[m]>
oh, I see. that might mean I'm not definitely insane yet :-)
reillyeon has quit [Remote host closed the connection]
reillyeon has joined #asahi
<alyssa>
🙂
quarkyalice has joined #asahi
quarkyalice has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi
Orsira has joined #asahi
Andalu30 has quit [Remote host closed the connection]
kit_ty_kate1 has quit [Quit: WeeChat 2.9]
Orsira has quit [Remote host closed the connection]
<sven>
marcan: i think you may be right with that iop communication theory
<sven>
from what i can tell ANS receives messages on endpoint 0x20 but replies to them using a different mechanism on endpoint 0x21
aleasto has quit [Remote host closed the connection]
<sven>
aaaand nvme is back. this time with less hacks :)
<alyssa>
:D
<pipcet[m]>
sven: so much for things getting there "slowly" :-)
<sven>
it's still a hack. and getting this upstream will take a while :)
<alyssa>
sven: let me know who to P/FW/AN
<sven>
😂
<sven>
first i need to clean up the quirks/fixes required to the nvme core. and then i'll have to figure out with arnd how to submit this
<alyssa>
lmgtfy.com/?q=git+send-email
<sven>
very helpful :P
<alyssa>
😋
MTecknology has joined #asahi
<MTecknology>
I'm struggling to follow a lot of what I'm reading. Is Asahi Linux intended to be strictly developer-focused (deal with the nitty gritty stuff), with distros being responsible for making installation easy for users?
<alyssa>
In the long term, we want linux on apple silicon to be "boring"
<alyssa>
(so install linux on your mac like you would on any x86 PC)
<alyssa>
In the medium term. marcan has talked about maintaining an arch linux arm downstream with all the M1 patches
<MTecknology>
ah, that would be nifty
<alyssa>
In the short term, asahi is just a bunch of patches to linux and mesa, installing the full system is left as an exercise.
<alyssa>
Personally I've been running debian from a manual debootstrap (i.e. no debian-installer) for years since arm64 is hard
<MTecknology>
I got my first ever mac device today. I'm still trying to wade through the documentation and figure out what's even sane.
<alyssa>
pipcet[m]: is the only one of us running M1 linux as a daily driver AFAIK
<alyssa>
but we talked about it today, and they're sane, so 😃
<MTecknology>
TIL an alarming number of people think virtualizing (parallels) means "bare metal"
<MTecknology>
I'm a Debian Dev... our sanity is questionable
<MTecknology>
(at best)
<alyssa>
:D
<MTecknology>
My actual main driver is a laptop, so I can handle a bit of risk on my desktop (which /was/ a razer laptop stuffed into a large desktop case and filled with fans).
<MTecknology>
I'm failing to find anything about debootstrap on mac. Are you describing a gentoo-style install from a live cd?
<pipcet[m]>
hi! my debootstrap stuff is currently broken, I'm afraid, if you're looking at that. You can install debian from it, I'm pretty sure.
<alyssa>
....Wait, right now I'm playing music from the m1 and compiling code on the chromebook. this seems horribly backwards, I really need to daily drive asahi :p
<MTecknology>
This is going to be a strange effort just to have a quieter gaming system. :P
<pipcet[m]>
it is backwards, I'm using the M1 for everything but music since I can't figure out how to get audio working :-)
<alyssa>
pipcet[m]: currently booting macOS
<alyssa>
what's wrong with audio?
<alyssa>
I mean. Obviously need to r/e the SoC sound stuff and write a driver. But in the mean time, type-C to 3.5 mm adaptors are like $10 at bestbuy
<MTecknology>
To start playing with this, do I need to follow all of the dev docs so that I can replicate it here?
<pipcet[m]>
so I'll just keep the power in one type-C port, the serial console for debugging in the other, and use the third one for audio? :-)
<alyssa>
pipcet[m]: Exactly!
<alyssa>
Don't forget the fourth one for a USB hub if you're running mainline without pci patches
<pipcet[m]>
and UART on the fifth?
<alyssa>
Nod
<alyssa>
Oh and you'll need the sixth for m1n1
<pipcet[m]>
mtecknology: you mean the bputil/csrutil/kmutil stuff, or setting up a dual-boot environment?