<chadmed>
povik: just as a test, have you a way of identifying which channels are which physical speakers in the device? if so, it might be worth setting up a stereo loopback sink, upmixing that to 6 channels, then playing with JACK or something to feed each channel into a DSP chain consisting of a bandpass filter and EQ and then outputting that to each channel in the speaker array
<chadmed>
just so we can get an idea of settings and such to create a profile/FIR for it so this all happens automagically
<chadmed>
i think this is better than just presenting it to ALSA as a stereo device, it gives us (and the user) far more control over the sound profile
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
riker77_ has joined #asahi-dev
riker77 has quit [Ping timeout: 480 seconds]
riker77_ is now known as riker77
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
user982492 has joined #asahi-dev
pfdub[m] has joined #asahi-dev
phiologe has joined #asahi-dev
amarioguy has quit [Ping timeout: 480 seconds]
<pfdub[m]>
Hey There, new here and wanting to help with checking notes and creating documentation. I currently have a MacMini M1, know a bit about networking, good but rusty at Java, haven't programmed C in a while. Here to soak up things. Probably waiting to I get a new MacMini M1 to try and install(maybe I'll dip my toe in before that). How do I get permissions to see earlier messages so I can see what is going on?
PhilippvK has quit [Ping timeout: 480 seconds]
<chadmed>
the logs are public, links in the channel topic/header for every asahi channel :)
<pfdub[m]>
Ok. Just realized that I can change which date I am viewing. Thank You!
kov has quit [Quit: Coyote finally caught me]
kov has joined #asahi-dev
csileeeeeeeeeeeeeeeeeeeeeeeeoe has joined #asahi-dev
psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
<chadmed>
povik: what do i have to do to get alsa to see the sound card on a j314s? ive build your asahi-snd-wip branch and built a new m1n1 payload with the dt from there, the modules load on boot but alsa says theres no sound cards
<marcan>
alyssa: that codepath only runs on the mac mini
<marcan>
(specifically, only if it detects an iPhone 5 sized framebuffer)
<marcan>
chadmed: the upmixing story is down to userspace; povik is working on the kernel side right now
<marcan>
as I said that'd be best done through ALSA plug-ins and configs
<marcan>
kettenis: I don't think the EQ is done in the codecs, because otherwise iBoot wouldn't need 6ch audio files for the boot chime, they could just load the same configs
<chadmed>
yeah i was just referring to the part where he suggested presenting it as a stereo device to userspace rather than exposing all the channels and letting userspace decide what to do with them in configuration, which is what i was about to have a play with now
<marcan>
that iBoot has pre-baked EQ'd audio strongly suggests that part is software
<marcan>
chadmed: he said he'd support *both*
<marcan>
so that naive 2ch mode will still do something sane
<marcan>
which is a reasonable fallback
<chadmed>
ah righto yeah i understand now, misread that message :s
<marcan>
ok, going to grab lunch and then wrap up the chainloading thing (and implement the packaging/etc) so we can ship this and not be worried about DTB updates being cumbersome :)
hizon has joined #asahi-dev
csileeeeeeeeeeeeeeeeeeeeeeeeoe has quit [Remote host closed the connection]
the_lanetly_052__ has joined #asahi-dev
gladiac has joined #asahi-dev
<povik>
chadmed: yes, we know which channel is which speaker
<povik>
there's a way to export filter characteristics from macos using the hypervisor
<povik>
i will do that before i start constructing something in userspace
<povik>
or would be good to have it before anyone starts doing it... :)
<povik>
chadmed: hmm, weird the device didn't show up when you built from asahi-snd-wip. send me a dmesg in PM please
<povik>
although it probably will missing kernel options
<povik>
there's a different speaker driver on j314
<chadmed>
nah i figured it out, apple-admac wasnt loading automatically so i just added it to modules.load.d
<povik>
that got you two-channel device, right?
<chadmed>
now it detects, but ive been trying to get to the bottom of the nightcore problem
<chadmed>
nightcore is a genre of music where they take a sped up song and chop and screw it, i was referring to how everything is sped up and chipmunk-y
<povik>
ha
<povik>
21:52 < povik> why is my music sped up?!
<chadmed>
i had a play with the clock multiplier in the dt but that just made things explode
<povik>
i had to change the NCO clkref again
<povik>
which is weird and i will have to investigate that
<povik>
chadmed: i will put up a branch for people to test that won't be chipmunk-y
<povik>
wait for that please
<chadmed>
sure thing
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
bluerise has quit [Quit: brb]
<marcan>
povik: don't worry about the DTs any more btw, chainloading is coming.
<j`ey>
marcan: making progress?
<marcan>
going to stream in a bit
<marcan>
I did a bit of rust cleanup earlier, need to incorporate your alloc fix too
<marcan>
but really all that's left is the chainloading function (which is just porting python -> C)
<marcan>
this means we probably won't have to have existing alpha release users ever re-1TR at *all*
<marcan>
it should cover all future magic we add including full PSCI/sleep/etc; something would have to go very wrong for a top-level m1n1 change to be required
<marcan>
so they're going to get all the updates with a simple pacman -Syu
<j`ey>
neat
<marcan>
it also means we can afford minor DT compat breaks in the non-upstream branches without too much fuss, since we can ~guarantee people will upgrade in lockstep
<marcan>
obviously I wouldn't want anything that actually breaks boot majorly, at least not without a transition period
<marcan>
but stuff like non-critical peripherals, sure
<marcan>
it'll be good to have guinea pigs for our code before it gets upstreamed :-)
<povik>
starting to learn the finer points of writing a linux driver...
<povik>
also, that together with the power domain fixes explains the "pwrstate change failed" message people have reported when compiling to modules earlier
<povik>
it's all coming together :)
<marcan>
module/dep handling is... interesting
<marcan>
a bunch of refcounting issues still in asahi, unloading certain modules in the wrong order explodes :-)
<marcan>
I fixed a bunch of the device table issues the other day
<marcan>
yes, I know about that one, already repro'd
<marcan>
it's on my list
<marcan>
also lol, I just looked at the NVRAM data format and had a hunch
<marcan>
... it's just CHRP NVRAM
<marcan>
good old powerpc format
<j`ey>
ah, I thought you repro'd when the link didnt come up
<marcan>
oh, yeah, I didn't repro it coming up and still not working
<marcan>
but I did see that issue
<marcan>
just... not much I can do unless I happen to hit it
<marcan>
but hopefully increased delays/timeouts will fix it
<marcan>
we'll see
<jannau>
marcan: alpha release users should update through 1tr once we add signature checks (unless you plan to implement that now as well)
<marcan>
secureboot only makes sense if you encrypt your rootfs (and ideally hashtree sign it too), which we aren't doing
<marcan>
so an end-user ready secureboot option will come much later and will probably involve a full reinstall from our POV; users who want to roll their own transition of course can do that and upgrade from 1TR at that point
<marcan>
my goal with secureboot is to make it *possible* and engineer things such that we can support it; but I think the majority of users don't care, and those who do will probably want to roll their own tweaks anyway
<marcan>
building transparent secureboot for the masses is a much harder problem, which is why it's cool that Apple is doing it :-)
<marcan>
but that's a long-shot goal for us as far as I'm concerned
<marcan>
and none of this really makes much sense without SEP support too, to aid in the crypto and take advantage of some of Apple's own engineering
<marcan>
so, all much further in the future, probably by which point we'll want to have not just m1n1 upgrades but stub firmware upgrades implemented too
<rkjnsn>
Personally, I'll be happy just to have everything through Grub (and configuration) verified. Since I keep my kernel and rootfs on an encrypted partition unlocked by Grub, that should be enough to make offline attacks difficult.
<marcan>
for now, you should probably just enable FileVault in macOS and set up u-boot/grub to disable the console
<marcan>
that won't verify things, but will disable any way to take over the machine without a full wipe or disassembling it, in principle
<marcan>
since enabling FileVault gates 1TR behind an authentication step
<marcan>
so you couldn't use it to take over stuff stored in the ESP even without signatures
<marcan>
given the hardware security of these machines, and that AIUI all NVMe data should be encrypted at rest by the controller anyway, just that alone should be rather strong security
<rkjnsn>
Good to know. I was thinking I had to worry about target disk mode, but it looks like the Apple Silicon require entering recovery (and thus authenticating) to enable it, instead of using a key combination?
<marcan>
yup
<marcan>
there's no target disk mode per se
<marcan>
recovery mode just sets up a SAMBA share over USB networking or something
<rkjnsn>
That's kind of annoying, though. When I've used target disk mode in the past, it was because the system was too dead to even boot recovery..
<jannau>
my expectation was that we can support UEFI secure boot via u-boot and have not to do much else to satiesfy standard distro's secure boot needs
<rkjnsn>
Ah. Fun…
<marcan>
if you lose recovery you need to DFU restore
<marcan>
you can use the "revive" option if you just borked system recovery, and that should leave your OS partition intact, though honestly you'd have to try pretty hard to break that too
<marcan>
there are probably cases where that fails and requires a full wipe though, no idea what happens if e.g. the GPT is mangled
<marcan>
jannau: UEFI secure boot requires key provisioning, but we don't have sane EFI variable storage to store that
<marcan>
and certainly no *secure* EFI variable storage
<marcan>
so at the very least we'll have to provision distro keys in top-level m1n1, and distros will have to ship a signed m1n1+u-boot second stage that then contains the hardcoded UEFI secure boot keys they use for the rest of the story
<rkjnsn>
m1n1 SEP driver? 😛 (I have no idea if that would actually work.)
<marcan>
problem is I think the SEP wants xARTS storage for a lot of stuff
<marcan>
and that's in APFS
<marcan>
which would mean m1n1 APFS driver
<marcan>
and... no.
<rkjnsn>
Ah, that's right.
<marcan>
there's a lot of hard bootstrapping problems to this whole secureboot thing
<marcan>
like how do you do distro installs? from USB? that means if you're already doing secureboot then, you have a chain break in the USB boot mechanism
<marcan>
how do you do recovery if something goes wrong?
<marcan>
UEFI secure boot/TPM/etc systems aren't... exactly a good inspiration to go by, seeing as the entire x86 secureboot ecosystem is kind of a joke in various ways
<marcan>
so yeah, ultimately, in the short term this is going to be a power user thing for people who really care and don't mind e.g. going through 1TR for every secureboot transition they want to make
<marcan>
in the long term, we'll see, once more pieces of the puzzle fall together
<marcan>
and either way distros are going to have to cooperate and take on a bunch of the engineering/integration if they want to make it easy for *their* users
<marcan>
no real way around that
<marcan>
e.g. one way to solve the bootstrapping issue might be to have a signed recovery kernel/initramfs option (stored in the ESP) that can launch e.g. online or USB recovery, but only after authenticating against SEP
<marcan>
we could work on building a generic version of something like that, but making it end-user-proof would definitely be a distro's domain
<marcan>
and probably also doesn't do module signing so you'd want to build your own kernel with that anyway
<kettenis>
linaro folks are working on UEFI secure boot support in U-Boot but it heavily relies on having a TPM of some sorts
<kettenis>
I think the idea is to have some sore of fTPM running in secure EL2 if there is no hardware TPM
<kettenis>
but that won't work on these machines isn't it?
<rkjnsn>
So, SEP doesn't access the SSD directly, but asks the OS to do so on its behalf (and then verifies the data the OS gives it back is legit), right? Could U-Boot do something similar for EFI vars, where it gives the OS a signed blob to store for it that it can read on the next boot?
<marcan>
that might work, but it's a bit dodgy and you still need a "machine key" provisioned on first install somehow
<marcan>
kettenis: right
<marcan>
the TPM here is the SEP
<marcan>
rkjnsn: the problem with those approaches is anti-rollback
<marcan>
which the SEP has via secure storage
<marcan>
ultimately, if we want to do this properly, the only real way is to use the SEP, which means either having "static" secureboot all the way to Linux (and SEP + APFS there), or sticking APFS+SEP support into u-boot too
<marcan>
note that we don't need full APFS support, just enough to find the single fixed-size file present in a specific volume, and replace blocks in it
<marcan>
so it might not be too crazy to actually implement
<marcan>
it's also possible readonly is good enough for u-boot?
<marcan>
which would probably be much simpler
<marcan>
honestly, given Apple apparently already have two extra NVMe namespaces for some magic stuff, I don't know why they didn't just stick xARTS there and had to use APFS...
MajorBiscuit has joined #asahi-dev
hizon has quit [Remote host closed the connection]
kloenk has quit [Remote host closed the connection]
amarioguy has quit [Ping timeout: 480 seconds]
<marcan>
kettenis: new installer UEFI only option now does chainloading, and also should be setting /chosen/efi-partition to the ESP PARTUUID
<marcan>
ideally we'd use that for u-boot to pick an ESP
<kettenis>
marcan: that probably needs to become u-boot,efi-partition or asahi,efi-partition
<kettenis>
not sure what the best way to handle that in u-boot is
<kettenis>
one possibility would be to generate Boot0000 and BootOrder variables from that and have the built-in U-Boot efi bootmgr code handle the boot
<kettenis>
janneau had a script-based hack, but one of the u-boot maintainers is pushing a patchset to replace those with a different implementation in C
<_jannau_>
the script based hack could be extended to read this from the fdt, setting EFI Boot variables look cleaner but we still have the problem that a random ESP with extlinux.conf could prevent the EFI boot
Telvana2 has joined #asahi-dev
<kettenis>
it would, unless we disable that functionality
<kettenis>
but that probably would make some people here unhappy
Telvana has quit [Ping timeout: 480 seconds]
<_jannau_>
yes, the sane thing would be to disable distro boot but there were people wanting to use extlinux
<FireFox317>
marcan, just a heads up but the currently pushed installer at mrcn.st/alxsh isnt working. I know there might be some bugs in the kernel as you said in the stream, but thats okay for me. See the following pastebin: https://pastebin.com/d6HDzJzR
<FireFox317>
I guess you didnt update the installer_data.json file maybe?
<j`ey>
firefox317: not pushed to github yet
<FireFox317>
j`ey, i know, but he said that he did push it to the link. I get the new python code through the link
<j`ey>
firefox317: that code gets the file from github
<FireFox317>
j`ey, aha, thanks. yeah that is the issue then, but fixing it can wait :) im not in a hurry, just super excited xd
<marcan>
ah yeah, fixed, sorry
<j`ey>
Oh I see, UEFI uses uefi-only.zip now
alyssa has left #asahi-dev [#asahi-dev]
amarioguy has quit [Ping timeout: 480 seconds]
MajorBiscuit has quit [Quit: WeeChat 3.4]
amarioguy has joined #asahi-dev
the_lanetly_052__ has quit [Ping timeout: 480 seconds]
user982492 has joined #asahi-dev
<marcan>
maz: aic2v3 sent!
___nick___ has joined #asahi-dev
<marcan>
also pushed a new installer to fix a nvme boot surprise leftover in the 1st-stage m1n1 (which was breaking nvme on linux when booted without u-boot and with a m1n1 chainload attempt along the way :))
amarioguy has quit [Ping timeout: 480 seconds]
csileeeeeeeeeeeeeeeeeeeeeeeeoe has joined #asahi-dev
kaferka has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kaferka has quit [Read error: Connection reset by peer]
___nick___ has quit []
___nick___ has joined #asahi-dev
user982492 has joined #asahi-dev
<jannau>
why would allocating the shadow framebuffer (23M) break dcp after a chainload. the rest of m1n1's fb code is disabled
___nick___ has quit [Ping timeout: 480 seconds]
<Glanzmann>
jannau: When I boot, I get the following error message, but I assume it is unrelated? [ 2.212786] simple-framebuffer be2120000.framebuffer: [drm] could not acquire memory region [mem 0xbe2120000-0xbe30bffff flags 0x200]
<jannau>
yes that is unrelated. is that an error? does the display work?
<Glanzmann>
jannau: Yes, it works perfectly.
tanty has quit []
tanty has joined #asahi-dev
tanty has quit []
tanty has joined #asahi-dev
user982492 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
amarioguy has joined #asahi-dev
csileeeeeeeeeeeeeeeeeeeeeeeeoe has quit [Remote host closed the connection]