psykose has quit [Remote host closed the connection]
psykose has joined #asahi-dev
<austriancoder>
Hi. I should soon get my hands on an M1 and I am interested if someone started to look at audio on the Air? I have some re experience and might want to help out.
ar has quit [Ping timeout: 480 seconds]
nepeat has quit [Ping timeout: 480 seconds]
nepeat has joined #asahi-dev
tylo1 has joined #asahi-dev
tylo1 has quit [Ping timeout: 480 seconds]
<j_ey>
austriancoder: povik is looking at audio
<j_ey>
austriancoder: they started writing a linux driver
ar has joined #asahi-dev
<austriancoder>
j_ey: okay.. thanks.. I think I will find an area to hack on
<povik>
nitpick: seems it complains about the wrong property
<povik>
logs gpio-ranges is missing, not apple,npins
<povik>
(had to look up in code why i made the pinctrl driver unhappy)
<j_ey>
ah, ty
<j_ey>
I forgot to clean that bit up, I set npins to 512 too, which is a thing i leftover by accident
<j_ey>
the v2 was a bit rushed, wanted to get it out before I went away and lost access to the m1 for a week
<povik>
i also get a strange compile error, that probably has to do with my setup
<povik>
> /include/linux/compiler_types.h:322:38: error: call to ‘__compiletime_assert_370’ declared with attribute error: FIELD_PREP: value too large for the field
<povik>
triggered on line 297 from apple_gpio_gpio_irq_unmask
<povik>
the compiler gets confused about the constancy of the field value as i understand it
<povik>
see no fault in the code itself
<j_ey>
uhh
<povik>
i replaced it with equivalent shift-and-mask expression, but would like to know how to make it go away properly
<j_ey>
what compiler?
<j_ey>
#define REG_GPIOx_MODE_MASK GENMASK(3, 1) and irqtype is u32....
<povik>
gcc version 9.3.0 (GCC)
<povik>
something nixos gave me for cross-compiling
<povik>
could be they have some strange patches
<povik>
also i cherrypicked on top of maz's tree, which is on top of v5.15-rc3
<povik>
can try to build your tree verbatim and report back
<j_ey>
Im confused now, how can that be a compile time check... it has FIELD_PREP(REG_GPIOx_MODE_MASK, irqtype), where irqtype is runtime
<j_ey>
I wonder if your gcc has a broken '__builtin_constant_p'
<j_ey>
(looking at __BF_FIELD_CHECK in include/linux/bitfield.h)
<povik>
i also wonder
<povik>
it's strange it hasnt triggered anywhere else, if i patch that that particular expression it builds
<povik>
maybe we are just unlucky
<j_ey>
povik: can you try: BUILD_BUG_ON(__builtin_constant_p(irqtype));
<j_ey>
line 290 or so
<povik>
sure, building
<povik>
and it goes through
* j_ey
confused
<povik>
if i put the FIELD_PREP back it compiles with the BUG_ON :D
<povik>
this is now a certified compiler bug as i see it
<j_ey>
wat
<povik>
yeah, if there's the BUG_ON above the line with FIELD_PREP, it compiles
<alyssa>
the Corellium wi-fi patch gets a lot less scary if you hit the backspace button a bunch
<alyssa>
(I split it up into separate commits, and dropped the useless commits, and now it's a lot smaller.)
nico_32 has quit [Ping timeout: 480 seconds]
nico_32 has joined #asahi-dev
<alyssa>
Okay, I am not sure where that code came from. But it didn't make sense on the surface, made less sense after thinking about it, and then wifi still works fine after dropping the commit.
<alyssa>
marcan: I see your point.
<alyssa>
MAC address code needs a full rewrite, but that's ok
<marcan>
I'm not saying I don't like their code out of NIH syndrome, you know :p
<alyssa>
marcan: giggle.
<alyssa>
`of_get_mac_address` this is handy :')
<marcan>
:')
<alyssa>
but errrr where does this OF node come from
<alyssa>
it's a pcie device
<marcan>
you add it
<marcan>
based on pcie port
<marcan>
see how the ethernet mac gets set
<marcan>
it's a child of the pcie bus node
<alyssa>
yeah that's what I was looking for. lots of abstractions to chew through but yes
<marcan>
there's the whole alias dance to set the mac
<marcan>
m1n1 already does that (thanks to the patch by kettenis)
<alyssa>
👍
<marcan>
you just need to set up the right pointer
<alyssa>
the Corellium code ultimately pipes that into an nvram field for the broadcom chip
<marcan>
yeah, I guess it gets presented as a "fake" nvram to the firmware?
<alyssa>
Not sure if this dance is necessary and not sure I want to find out without a Faraday cage :-p
<marcan>
it's all kinda weird
<marcan>
well, you do need the MAC, but maybe there's an easier way since after all linux can change the mac...
<alyssa>
Maybe? If it is necessary, I'd like to know why the other broadcom chips don't need it
<alyssa>
or, better question - how do mac addrs usually get set with upstream brcmfmac
<marcan>
this is Apple doing system personalization their own way
<marcan>
remember these things are unbrickable?
<alyssa>
Nod
<marcan>
so the mac has to come from sysconfig data
<marcan>
(which it pulls from the calls home during DFU restore)
<marcan>
so it can't just be in some EEPROM since that'd add more state
<marcan>
(which is how wifi cards would normally do it)
<alyssa>
so this is a legitimate hardware/firmware difference and not "macOS does it so Corellium does it so we do it"?
aleasto has quit [Quit: Konversation terminated!]
<marcan>
hence this dance to forward the MAC from the ADT to nvram
<marcan>
now the *way* this is being done... I don't know if it's the only/correct way
aleasto has joined #asahi-dev
<marcan>
it stands to reason that since Linux can just outright set the MAC via standard APIs, there might be a way to do it like that without having to add the whole nvram mess
<alyssa>
though we'd still want to respect the one forwarded from the ADT, no?
<alyssa>
maz has a commit to do it for Ethernet, and that was a DT-only change and tg3 just 'magically' worked I think
<marcan>
yes, but what I mean is maybe instead of sticking it in nvram you can just call set_mac() on driver startup
<marcan>
or whatever the api for that is
<marcan>
and that might avoid you a bunch of nvram munging code or whatever
<alyssa>
ack. I think there will still be some nvram munging but a heck of a lot less than corellium has.
aleasto has quit [Remote host closed the connection]
<marcan>
and yeah, looking at tg3 to see if it has any special code for this
<marcan>
it might not need it, maybe this is in core stuff already
aleasto has joined #asahi-dev
<marcan>
ah, eth_platform_get_mac_address
<marcan>
tg3 has that
<marcan>
alyssa: so yes, the driver needs to support it
<marcan>
(that calls of_get_mac_address)
<marcan>
alyssa: see brcmf_c_preinit_dcmds that *gets* the MAC address from the device on startup
<marcan>
with an analogous API to what brcmf_netdev_set_mac_address uses to set it
<marcan>
that sounds like a prime place to call eth_platform_get_mac_address and do a *set* instead if that is available
aleasto has quit [Remote host closed the connection]
<marcan>
and then no need to mess with nvram
<marcan>
(plus it works for all brcmfmac devices then, forever)
aleasto has joined #asahi-dev
<alyssa>
alright..
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
<marcan>
btw, it should be the installer's job to pull the firmware out of osx and into somewhere useful
<marcan>
any ideas? I guess if nowhere else it should go in the FAT32 EFI partition I will (eventually) be setting up
aleasto has quit [Remote host closed the connection]
aleasto has joined #asahi-dev
aleasto has quit []
<alyssa>
FAT is probably the only reasonable answer
<alyssa>
since macOS won't write ext4 and Linux won't read APFS
<alyssa>
There /is/ a somewhat invovled dance required to /find/ which firmware your hw actually needs, though
<alyssa>
t2linux's wiki gives a magic incantation to run in ioreg with wifi enabled.
<alyssa>
I assume you'll be able to do better in the installer but meh
aleasto has joined #asahi-dev
<sven>
don't all m1 machines just have the same chipset?
<sven>
the t2 people probably need support a few generations of macbooks
<sven>
*need to
<jeh[m]>
All M1 chipsets are same atm (one graphics core disabled on some models iirc)
<sven>
yes, i know. i'm talking about the wifi chipset though
<sven>
i'd expect that to be the same as well but that one's easier to change
<jeh[m]>
Ah! Sorry my bad here! Don't think Apple specifics which chipset they're using but I also assume that should be same across all devices can't say though - they've historically used Broadcom.
<jeh[m]>
I think they're using Broadcom BCM4378 - not sure about that at all though :)
<alyssa>
jeh[m]: sven: There are a /lot/ of different firmware files in the 4378 directory on macOS
<marcan>
corellium embedded one in their kernel (did they get a license?) and apparently it worked for people? :')
<marcan>
let me take a look
<alyssa>
...I see
<marcan>
also ideally I'd want to pull it from the recovery image, since we install that
<marcan>
in keeping with firmware version consistency
<marcan>
although for wifi it matters less
<alyssa>
marcan: If I'm reading the corellium kernel code correctly, I believe they have a pile of hacks in userspace to select the fw, set module parameters to point to it, and then re-load the wifi driver.
<marcan>
lol.
<marcan>
well their first kernel just had one embedded
<marcan>
:p
<alyssa>
wee
<marcan>
(which they summarily took down once I pointed it out)
<marcan>
(without a word)
vup2 has quit [Remote host closed the connection]
<alyssa>
nice.
vup has joined #asahi-dev
<alyssa>
I still dunno what's up with this race condition
<alyssa>
like, it seems like a genuine race we lose every time but if so, why isn't every other brcmfmac user in existence broken
<marcan>
what race?
<alyssa>
marcan: brcmfmac does "enable interrupts, then setup driver"
<alyssa>
and their interrupt handler starts off by dereferencing driver intenral stuff
<alyssa>
on BCM4378 at least, we get a very early interrupt => NULL dereference in the IRQ handler
<marcan>
there are only two BCM4378 firmwares as far as I can tell
<marcan>
what they do have is a ton of *config* files
<marcan>
which makes sense (things like RF parameters change from platform to platform)
<alyssa>
meanwhile I'm cranky that I need to build brcmfmac as a module if I don't want to bundle the blob with the kernel ..
<marcan>
you do not? you can put it in the initramfs
<nskl>
fwiw, i have a 2015 mbp, with arch on it, and both the wifi and bluetooth are under performing. especialy bluetooth. although they both 'technically' work, their signal is very poor. bluetooth i must stand within 1meter of the laptop to have functionning headset, and wifi signal reception is poor too. (it's using brcmfmac.. BCM43602)
<marcan>
nskl: sounds like bad configs
<alyssa>
.../me forgot that real initramfs exist
* alyssa
feels silly now
<nskl>
marcan: i tested many distro on it since 2015, it was always like that.. well to be fair, in the beginning it was way worse, and today it's barely usable
<jeh[m]>
nskl: BM4331 here in 2012 MBP - works perfectly fine.
<marcan>
nskl: I would not expect any distros to be better than others
<nskl>
jeh[m]: even if you compare with macos ? for me the signal reception is quite good in macos and not that great in linux
<marcan>
that sounds like nobody bothered to make sure the nvram/etc config was done properly
<nskl>
marcan: my distro of choice is artix (arch without systemd) but i tried plain arch too, and many debian derivatives and tons of other exotic distros
<jeh[m]>
nskl: Yes even compared to macOS! open source broadcom driver is bad that is b43 iirc. broadcom-wl works perfectly fine!
<nskl>
well, i have good hopes that this time, asahi linux will make it work nicely
<marcan>
alyssa: and there are only two actual *differing* config files for atlantisb
<marcan>
(which are copied and symlinked over and over)
<jeh[m]>
oh my...
<marcan>
now, we do have different instances for each machine
<marcan>
so there are, among all the M1 variants out there so far, 2 actual firmwares (each model symlinks one of those), and then 2 nvram variants for each model
<marcan>
I would just put this info in the devicetree and add some plumbing to brcmfmac to get it from there
<marcan>
alternatively we could just make the installer pull the right variant for *your* machine, but that makes the rootfs nonportable once it gets copied, which is kind of icky
<alyssa>
marcan: symlinks! oh my.
<alyssa>
marcan: ok, stuck the firmware in an initramfs (with nothing else) and passed that to linux.py and built brcmfmac=y and now it's happy
<alyssa>
still stupid that linux can't tell "hmmm I need firmware but have no filesystem maybe I should not try to load that driver before NVMe"
<marcan>
wouldn't help since it needs to mount it anyway
<marcan>
built in module, firmware needs to be in initramfs
<marcan>
that's just how it is
<alyssa>
s/module/kernel/
<j_ey>
oh, didnt know that
<marcan>
alyssa: so it does look like the specific version info is in OTP only, so we need to copy all nvram variants and then have the driver choose one
<alyssa>
ugh.
<alyssa>
so the unused OTP parser in corellium code was secretly used by their userspace?
<alyssa>
thanks for volunteering to work on that
<marcan>
and should not be used by userspace, it should be used by the driver
<marcan>
so the way this is normally done, apparently, is
<alyssa>
right, the driver first tries brcmfmac4378-pcie.apple,j274.bin
<alyssa>
but it sounds like there are 2 possible firmwares for J274 depending on... region?
<marcan>
yeah but it's not j274... the devicetree IDs this using a different naming scheme, which is in the ADT, so we ought to follow that unless we want to maintain a mapping table in the installer
<alyssa>
better in the installer than in the brcmfmac I would think?
<marcan>
also, slight issue: FAT32 does not support symlinks :')
<alyssa>
...
<marcan>
since we need a script to copy this over anyway, I guess we should dump out the mapping/symlink stuff in a text file anyway
<kettenis>
fwiw, OpenBSD's bwfm(4) uses the same firmware name mapping scheme as the linux driver
<marcan>
actually it looks like the nvrams are the same for every module revision, only there are two vendors
<marcan>
I'm thinking we basically want something like brcmfmac4378-pcie.apple,atlantisb-RASP-m-6.2.txt but with fallback requests
<marcan>
so the driver would try brcmfmac4378-pcie.apple,atlantisb-RASP-m-6.2.txt then brcmfmac4378-pcie.apple,atlantisb-RASP-m.txt then brcmfmac4378-pcie.apple,atlantisb-RASP.txt then brcmfmac4378-pcie.apple,atlantisb.txt
<marcan>
and we can provide the -m since that is where the differences stop
<marcan>
the installer can check that all the variants are the same to avoid making copies
<alyssa>
what is RASP btw?
<marcan>
"module"
<marcan>
m is the vendor
<marcan>
the thing after is the revision
<marcan>
don't ask me what RASP stands for
<marcan>
oh yeah and I forgot, the antenna matters though again this is symlink land
<marcan>
so brcmfmac4378-pcie.apple,atlantisb-RASP-m-6.2-X2.txt first, then everything with X2 but removing components, then without X2
<marcan>
(either this or we throw in a pile of symlinks)
<marcan>
kettenis: you mean the corellium driver?
<kettenis>
no, I mean the unmodified driver
<kettenis>
the way it constructs the name based on the / compatible
<marcan>
ah
<marcan>
yeah, but that doesn't work for us because we have at least two different nvram files per board
<marcan>
(potentially more with versions in the future)
<kettenis>
well, you could just have the installer install the set of files that you actually need
<marcan>
yeah, but as I said then that makes the rootfs nonportable
<marcan>
which is not ideal
<kettenis>
yeah, although the NVMe isn't exactly removable ;)
<marcan>
the wifi modules are
<marcan>
IIRC
<marcan>
(at least on some machines)
<kettenis>
anyway, patrick made our driver print the string the corellium driver uses:
<kettenis>
it prints "unknown" because the "atlantisb" bit is missing from the device tree
<marcan>
yeah
<marcan>
I wonder how this works on x86
<marcan>
no DT there to tell it the island
<marcan>
if we can get that from OTP too, it would make this whole scheme work for the x86 macs too
<kettenis>
alledgedly on x86 the nvram stuff is provided through an EFI variable
<marcan>
heh
<kettenis>
not sure if x86 used that same scheme or had a different approach
<kettenis>
I mean x86 macs
<kettenis>
the EFI variables exist on machines intended to run Windows
<kettenis>
older chips had just the firmware and the nvram file
<marcan>
hm? my iMac should have it then, pretty sure it can run windows
<kettenis>
more recent chips also have a CLM file
<marcan>
this has a BCM43602
<kettenis>
# SPDX-License-Identifier: GPL-2.0+
<kettenis>
# (C) Copyright 2018 Linaro Ltd
<kettenis>
Seriously?
<kettenis>
(that's the license somebody put on the .txt file for some ARM board in the Linux firmware repository)
<marcan>
lol
<kettenis>
it's just a bunch of parameters; really shouldn't be copyrightable
<kettenis>
anyway, your challenge is to convince the Linux brcmfmac driver maintainers of the firmware naming scheme ;)
<marcan>
sure :p
<minecrell>
kettenis: There were long attempts to get Broadcom to clarify the licensing for the NVRAM stuff, of course they didn't. The Linaro copyright is basically some strange way around it, they posted some GPL licensed NVRAM and now everyone seems to copy that with some device-specific values (from the "proprietary" config) adjusted
<marcan>
lovely
<kettenis>
well, the GPL doesn't make sense for this kind of file
kov has joined #asahi-dev
<alyssa>
marcan: "if we can get that from OTP too, it would make this whole scheme work for the x86 macs"
<alyssa>
none of this works on the T2 Macs so yes they would appreciate a proper solution for this :)
<alyssa>
or maybe they enjoy doing the ioreg dance, idk
<alyssa>
minecrell: still not convinced NVRAM is copyrightable at all but y'know
tylo1 has joined #asahi-dev
<alyssa>
marcan: OTOH if we don't care about t2 macs, we could stick all the OTP parsing stuff in m1n1 and just passing the firmware path that way
vup has quit [Ping timeout: 480 seconds]
<kettenis>
sigh, I used get_maintainer.pl for v2 of my u-boot upstream diff, but it touches enough code for the list of recipients to get too long for the mailing list :(
confusom1 has joined #asahi-dev
<minecrell>
kettenis: This is mostly get_maintainers.pl being overly verbose though, most of the people you're Cc-ing just added a few lines (e.g. drivers) in the files you're touching (:
<minecrell>
I think I'm on Cc because of doc/board/index.rst and maybe arch/arm/Kconfig
<minecrell>
Oh wow your Cc list on v2 is amazing :D