ChanServ changed the topic of #asahi-dev to: Asahi Linux: porting Linux to Apple Silicon macs | General development | GitHub: https://alx.sh/g | Wiki: https://alx.sh/w | Logs: https://alx.sh/l/asahi-dev
user982492 has joined #asahi-dev
yuyichao has joined #asahi-dev
alexstore06 has joined #asahi-dev
bps has quit [Remote host closed the connection]
alexstor_ has quit [Ping timeout: 480 seconds]
StupidYui has quit [Ping timeout: 480 seconds]
StupidYui has joined #asahi-dev
<marcan> this is bringing back memories of the Xbox (original) gamepads...
<marcan> (those were HID-without-the-descriptor)
<krbtgt> HIDeous!
phiologe has joined #asahi-dev
PhilippvK has quit [Ping timeout: 480 seconds]
alexstore06 has quit [Remote host closed the connection]
alexstore06 has joined #asahi-dev
alexstore06 has quit [Ping timeout: 480 seconds]
alexstore06 has joined #asahi-dev
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
rohin2 has joined #asahi-dev
rkt has left #asahi-dev [#asahi-dev]
alexstore06 has quit [Ping timeout: 480 seconds]
alexstore06 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
rohin2 has quit [Ping timeout: 480 seconds]
alexstore06 has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
alexstore06 has joined #asahi-dev
jeffmiw has quit [Ping timeout: 480 seconds]
<marcan> sven: I looked a bit at DAPF: https://mrcn.st/p/sxJQcz7k
<marcan> it's pretty dumb, the only thing I don't really understand is that mode field
<marcan> I also found the DAPF lockbit
<marcan> https://mrcn.st/p/aAl2q6jA this seems to be the actual translation logic
<marcan> so basically the DAPF always behaves like it has an implicit allow of the bottom 4GiB at the end (but this can be overridden with a USE_DART=0 entry, and since the bottom 4G on these SoCs always faults AIUI, that means you can disable that entire range)
<marcan> and then, if USE_DART=1 (or it's the implicit allow), then resolution continues through the DART if enabled, otherwise it falls through to passthrough if allowed, otherwise it gets dropped
<marcan> you can technically do wonky things with DAPF; you could have a range go 1:1 to physmem for reads and to DART for writes, which means you could have memory that points somewhere different for reads and writes...
<marcan> (wonder how that interacts with caches... my guess is not well...)
aleasto has joined #asahi-dev
aleasto has quit []
aleasto has joined #asahi-dev
<rkjnsn[m]> hid_apple is also used for the internal keyboard on my 2015 MBP.
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
<kettenis> yes, the
<kettenis> yes, it looks like it will handle the quirk for the Fn key in the HID on the M1 macbook
<kettenis> the whole thing makes sense since the keyboard is just the same as for the last generations of intel laptops
<kettenis> and some of those supported the keyboard over usb
alexstor_ has joined #asahi-dev
<kettenis> those machines probably just had a microcontroller in front of the SPU bus
<j_ey> kettenis: does openbsd support any older intel macs?
<marcan> kettenis: s/microcontroller/T2/
<marcan> the T2 has a virtual USB Host controller thing going (which is its own snafu to support)
<marcan> and it exposes the keyboard over that; internally I'm sure it's the same exact SPI thing behind the T2
<marcan> meanwhile, lol Kali Linux are apparently listing their AArch64 ISO images as "Apple M1" ?!
<marcan> no wonder some people are confused
<marcan> (AFAICT the only use for those is doing VM installs, and maaybe some bare metal platforms, but definitely not the M1)
alexstore06 has quit [Ping timeout: 480 seconds]
<j_ey> o_O
<marcan> kettenis: do you have a one-line TL;DR on what u-boot repo/build I should be looking at? it's about time I start looking into bundling that in the installer...
<marcan> thanks :)
<marcan> I've also been wondering about how we should handle EFI partitions
<j_ey> apple_m1_defconfig
<marcan> we have a bit of a nested OS problem; in principle, you could have multiple m1n1 installs each wrapping one OS, which would mean a separate EFI partition. This might become particularly important once we start using the SEP, to provide strong isolation between different OSes (otherwise they would at the very least end up sharing user databases and such)
<marcan> so I'm wondering if we should have some magic to be able to have multiple EFI partitions and tell u-boot which one to use, perhaps as a m1n1 arg built into it at install time, or perhaps via automagic search based on partition order (since the ADT tells us what APFS volume group UUID we booted from, we could search for that and look for the subsequent EFI partition)
<marcan> though that adds even more pitfalls since you can in principle have multiple installs per APFS container (though we don't currently support that)
<marcan> so maybe it makes more sense to either hardcode the EFI partition UUID in m1n1 at install time, or to just have a flag file in the EFI partitions saying what VGID they belong to, so they can be scanned for
<marcan> (of course distro installers may be very confused by multiple EFI partitions, but what can you do about that...)
<marcan> (evil hack: have u-boot change the partition IDs to only mark the current one as a real EFI partition...)
<marcan> apple deals with this by putting everything in their EFI-partition-equivalent (Preboot) under a folder named after the VGUUID of the OS in question...
<marcan> in principle it's desirable to let users boot different m1n1-based OSes from the Apple boot picker, not just due to the SEP stuff but also because it's more user friendly than nested bootloaders and also supports accessibility
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<marcan> hm, the GPT partition name field fits an ASCII UUID *exactly*. maybe that's the easiest way to bind them to a VGUUID.
<marcan> (could also take the dashes out and go with EFI:<uuid> or something)
<j_ey> whichever is the cleanest, and hopefully doesnt involve hardcoding things in m1n1 or u-boot
<marcan> well, "hardcoding" can be done via the vars mechanism I added
<marcan> i.e. just cat stuff into the binary
<marcan> (for those who missed it: for run_guest and such, you can now append "boot-args=foo bar baz" as newline-terminated ASCII to m1n1.macho to set the linux bootargs statically)
<j_ey> oh, yeah, neat, thats not so bad
alexstor_ has quit [Ping timeout: 480 seconds]
d4ve has quit [Remote host closed the connection]
d4ve has joined #asahi-dev
gabuscus_ has quit [Read error: Connection reset by peer]
gabuscus has joined #asahi-dev
robinp_ has joined #asahi-dev
robinp has quit [Ping timeout: 480 seconds]
<kettenis> marcan: looks like I didn't push the compatible changes for the power domains yet
<kettenis> but otherwise, yes, it should just be a matter of:
<kettenis> make apple_m1_defconfig
<kettenis> make mrproper
<kettenis> make
<kettenis> erh, probably:
<kettenis> make mrproper
<kettenis> make apple_m1_defconfig
<kettenis> make
<kettenis> then use u-boot-nodtb.bin as the payload
<kettenis> (it currently errors out after building that so that isn't a problem)
d4ve has quit [Remote host closed the connection]
d4ve has joined #asahi-dev
d4ve has quit [Remote host closed the connection]
d4ve has joined #asahi-dev
gladiac has quit [Read error: No route to host]
gladiac has joined #asahi-dev
<marcan> cool :)
jacoxon has joined #asahi-dev
alexstore06 has joined #asahi-dev
boardwalk9 has joined #asahi-dev
boardwalk has quit [Ping timeout: 480 seconds]
boardwalk9 is now known as boardwalk
jacoxon has quit []
jacoxon has joined #asahi-dev
jacoxon has quit []
jacoxon has joined #asahi-dev
jacoxon has quit []
alexstore06 has quit [Ping timeout: 480 seconds]
alexstore06 has joined #asahi-dev
alexstor_ has joined #asahi-dev
alexstore06 has quit [Ping timeout: 480 seconds]
alexstor_ has quit [Remote host closed the connection]
al3xtjames3 has joined #asahi-dev
al3xtjames has quit [Read error: Connection reset by peer]
al3xtjames3 is now known as al3xtjames
jacoxon has joined #asahi-dev
<kettenis> marcan: UEFI allows multiple ESPs
<marcan> heh, didn't know that
<marcan> do linux installers/etc handle it though?
<kettenis> Within a single ESP the standard suggests that bootloaders should live in a directory with a vendor-specific name
<kettenis> not sure how linux distros handle that, but I do believe they use their own directory
<marcan> yeah, but if there are multiple ESPs, how do they pick?
<marcan> I can see that getting very confusing
<kettenis> but in the end if you want truly separate installs, you'll have to have separate variable stores
<maz> debian creates a 'debian' directory, for example.
<marcan> we don't even have a variable store right now, do we? :)
<marcan> we'd have to do something to put that in the ESP or s
* alyssa still chainloads her kernels over USB 😅
<marcan> alyssa: yes, tell that to end users :p
<kettenis> for something resembling secure boot the variable store needs to be"secure"
* maz trying to move over to u-boot...
<kettenis> I suspect that would involve interaction with the SEP somehow?
<marcan> kettenis: eh, we can just add SEP support to u-boot and sign it with machine-derived keys
<marcan> ;p
<alyssa> marcan: what are those? 🙃
<kettenis> EFI variables are used for boot options and each boot options indicates a full device path that includes the partition GUID if I'm not mistaken
<kettenis> but in the end I think we want to try to stick to a single ESP per disk
<kettenis> I have no particular interest in secure boot stuff, so I'll leave anu y-boot support for that to someone who does ;)
<kettenis> s/y-boot/u-boot/
<marcan> I care about that eventually, but not right now
<kettenis> maz: there may be handoff issues where u-boot leaves hardware in a state unexpected by the OS
<kettenis> I can teach u-boot to clean things up when ExitBootServices() gets called
<kettenis> but right now that would break OpenBSD
<maz> kettenis: yup, that's one of the reasons why I want to have a look.
yuyichao has quit [Ping timeout: 480 seconds]
<maz> there was at least a report yesterday of PCIe needing some additional love and care to issue a PERST#.
jacoxon has quit []
jacoxon has joined #asahi-dev
<kettenis> I suppose I should figure out how one builds a Linux kernel these days...
jacoxon has quit []
jacoxon has joined #asahi-dev
<kettenis> ok, pushed the changes that align the power domain bindings with marcan's
<kettenis> also includes some nodes for spi and keyboard
<j_ey> interrupts-extended?
<j_ey> oh, that is a standard thing..
<alyssa> maz: btw, what's the story with rescanning on link up interrupts?
<alyssa> when I tried adding the obvious 1 line patch it didn't work but what's obvious to me is likely completely wrong here :)
<alyssa> (and I figure if you omitted it, it was nontrivial for some reason? I guess the 3 ports on one root is unusual and might need more surgery on the subsystem so rescanning one port doesn't disrupt the others?)
<maz> alyssa: you need to go and tell the core to perform the rescan. effectively, we need to treat that as a hotplug.
<alyssa> nod
<maz> I was thinking of injecting a PCIe hotplug event, but I need to try and see how that work. which means I need to look into the wifi ugliness...
<alyssa> I have a patch to bring up the wifi, at least up to getting a link up interrupt
<alyssa> and you don't need the brcmfmac patches just to get wifi on the lspci ofc
<maz> kettenis: I'm installing openbsd in a guest for the first time. surprisingly painless so far!
<kettenis> j_ey: yes, it's useful for a single interrupt with a non-default parent
<kettenis> maz: our take on a user-friendly installer is that you just press enter ;)
<maz> alyssa: right. I'll have a look next week if I have a bit of time ($work is ultra busy atm).
<alyssa> sure
<alyssa> the top 3 patches on mu-one/linux:rfkill should get you link up interrupts anyway
<maz> kettenis: ACPI didn't quite work, but switching to a DT instead gave me a working guest (on the M1, btw..)
<alyssa> IIRC disabling wifi was broken (link down would come, but then wouldn't get another link up ever again. Need someone to go kext dumpsterdiving,)
<alyssa> but it should be enough to exercise the pcie driver
<maz> alyssa: good stuff. I guess that in order of priority, I have booting from u-boot, wifi, and PMU. fun... ;-)
<alyssa> :))
<alyssa> I do feel pretty firmly the Right way to deal with wifi is to just teach pcie-apple hotplug and have a mandatory rfkill driver managing the SMC gpio
<kettenis> but I'm not convinced ;)
<alyssa> as opposed to hacking in rfkill details into the pcie driver like the corellium driver did
<alyssa> You need an rfkill driver /anyway/, and the rfkill core does an enable on boot if that's the appropriate policy /anyway/, so this really has nothing to do with PCIe
yuyichao has joined #asahi-dev
<kettenis> most rfkill implementations don't power down the entire wifi device though
<maz> this is PCIe, so hotplug is more or less baked in the root port. rfkill should be fundamentally independent.
<kettenis> is rfkill still a thing?
<kettenis> it used to be that hardware did have a real physical switch or at least a physical switch toggled by a GPIO
<kettenis> but that doesn't seem to be the case anymore
<kettenis> just need a way to tell the hardware to stop transmitting
aleasto has quit [Quit: Konversation terminated!]
aleasto has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
<maz> kettenis: does openbsd have support for GICv3 ITS? it says "virtio33[0]: couldn't establish msix interrupt", and falls back to INTx instead...
aleasto has joined #asahi-dev
jacoxon has quit []
<kettenis> should be there, but support might be incomplete
<kettenis> the whole GICv3 spec is a bit baroque if you ask me...
<maz> baroque doesn't quite describe it. more like a sick, twisted fsck.
<kettenis> I was trying to be nice ;)
<maz> you should have seen the engineering spec!
<maz> you can't be nice to the GICv3 spec. you just want to burn it.
* kettenis lights a match
<maz> (800 pages, will keep you warm for a while...)
<jn> 800 pages for an interrupt controller, whew
<j_ey> maz: are you using qemu?
jbowen has joined #asahi-dev
<maz> j_ey: as the VMM? yes.
<j_ey> (ignore that, the issue im seeing is TCG only I think)
<maz> jn: it's not really an interrupt controller. it is the CPU, the OS, and more. what you call the CPU is just a toy on the side.. :D
<maz> just like emacs is the real operating system.
jbowen has quit []
jacoxon has joined #asahi-dev
jacoxon has quit []
jacoxon has joined #asahi-dev
jacoxon has quit []
alexstore06 has joined #asahi-dev
alexstore06 has quit [Remote host closed the connection]
alexstore06 has joined #asahi-dev
alexstore06 has quit [Ping timeout: 480 seconds]
alexstore06 has joined #asahi-dev
alexstore06 has quit [Remote host closed the connection]
alexstore06 has joined #asahi-dev
alexstore06 has quit []
blzd has quit [Remote host closed the connection]
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
robinp_ has quit [Ping timeout: 480 seconds]
X-Scale` has joined #asahi-dev
X-Scale has quit [Ping timeout: 480 seconds]
<mjg59>
___nick___ has joined #asahi-dev
___nick___ has quit []
___nick___ has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
user982492 has joined #asahi-dev
blzd has joined #asahi-dev
jacoxon has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
roxfan has joined #asahi-dev
roxfan2 has quit [Ping timeout: 480 seconds]
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
skipwich has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
jacoxon has quit []
jacoxon has joined #asahi-dev
blzd has joined #asahi-dev
jacoxon has quit []
jacoxon has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
X-Scale has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
blzd has joined #asahi-dev
X-Scale` has quit [Ping timeout: 480 seconds]
blzd has quit [Read error: Connection reset by peer]
user982492 has joined #asahi-dev
blzd has joined #asahi-dev
blzd has quit [Read error: Connection reset by peer]
blzd has joined #asahi-dev
m6wiq has joined #asahi-dev
jeffmiw has joined #asahi-dev
rohin has joined #asahi-dev
<blzd> /win 3
m6wiq1 has joined #asahi-dev
m6wiq1 has quit []
m6wiq has quit [Ping timeout: 480 seconds]
___nick___ has quit [Ping timeout: 480 seconds]
jeffmiw has quit [Ping timeout: 480 seconds]
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
alexstore06 has joined #asahi-dev
alexstor_ has joined #asahi-dev
alexstore06 has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
aleasto has quit [Quit: Konversation terminated!]
alexstor_ has quit [Remote host closed the connection]
yuyichao_ has joined #asahi-dev
alexstore06 has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
prohin[m] has joined #asahi-dev
yuyichao has joined #asahi-dev
yuyichao_ has quit [Read error: No route to host]
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
jacoxon has quit []
Chinese_soup has joined #asahi-dev
yuyichao has joined #asahi-dev
yuyichao_ has quit [Read error: No route to host]
yuyichao_ has joined #asahi-dev
yuyichao has quit [Ping timeout: 480 seconds]
yuyichao_ has quit [Ping timeout: 480 seconds]
alexstore06 has quit [Remote host closed the connection]
alexstore06 has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
thunfisch has quit [Ping timeout: 480 seconds]
robinp has joined #asahi-dev
prohin[m] is now known as rohin[m]
thunfisch has joined #asahi-dev