ChanServ changed the topic of #asahi to: Asahi Linux: porting Linux to Apple Silicon macs | General project discussion | GitHub: | Wiki: | Topics: #asahi-dev #asahi-re #asahi-gpu #asahi-offtopic | Keep things on topic | Logs:
kettenis_ has joined #asahi
kettenis has quit [Ping timeout: 480 seconds]
yuyichao_ has joined #asahi
phiologe has joined #asahi
PhilippvK has quit [Ping timeout: 480 seconds]
<amw> hablerentand[m]: I just uploaded a photo of my console kernel messages with the USB keyboard plugged in through a USB Type-C=>A 4 port hub
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> amw: My config is
<alyssa> Booted as:
<alyssa> M1N1DEVICE=/dev/ttyACM0 python3 proxyclient/tools/ --bootargs="net.ifnames=0 rw root=/dev/sda2 rootwait rootfstype=ext4" ~/foo/Image.gz ~/foo/t8103-j274.dtb
<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
<alyssa> /s
<marcan> :p
yuyichao_ has joined #asahi
hashcheck has quit [Quit: Textual IRC Client:]
* alyssa should get to "work"
bradfier_ has joined #asahi
bradfier has quit [Remote host closed the connection]
yuyichao_ has quit [Ping timeout: 480 seconds]
<sven> not happy yet, but it's a start. this should be enough to bring up ANS at least
<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 :-)
<sven> in the syslog? let me try!
<sven> [ 131.139246] apple-mailbox 23e400000.mbox: syslog message: apComms.cpp:372: SMC HID Event: 01 fe 01
<sven> hah :)
<pipcet[m]> cool!
<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]
bsandro has left #asahi [#asahi]
<sven> [ 0.402106] apple-mailbox 277400000.mbox: syslog message: cmd.c:5414: boot mode normal
<sven> [ 0.421379] nvme0n1: p1 p2 p3 p4 p5 p6
<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
<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?