On Sun, Oct 27, 2024 at 11:18:31PM +0100, Mark Kettenis wrote:
> > Date: Tue, 22 Oct 2024 12:15:18 +0200
> > From: Tobias Heider <tobias.hei...@stusta.de>
> >
> > On Mon, Oct 21, 2024 at 10:10:44PM GMT, Mark Kettenis wrote:
> > > > Date: Mon, 21 Oct 2024 20:40:38 +0200
> > > > From: Tobias Heider <tobias.hei...@stusta.de>
> > > >
> > > > On Mon, Oct 21, 2024 at 08:33:53PM GMT, Mark Kettenis wrote:
> > > > > > Date: Mon, 21 Oct 2024 14:12:33 +0200
> > > > > > From: Tobias Heider <tobias.hei...@stusta.de>
> > > > > >
> > > > > > On Mon, Oct 21, 2024 at 01:04:10PM GMT, Stuart Henderson wrote:
> > > > > > > On 2024/10/21 13:54, Sylvain Saboua wrote:
> > > > > > > > Are we to understand that the default wireless device
> > > > > > > > of the Apple M1 is not functional yet with openbsd ?
> > > > > > >
> > > > > > > It was working on M1, but based on this report it looks like a
> > > > > > > change on
> > > > > > > the MacOS side might have broken it for newer MacOS versions.
> > > > > > >
> > > > > >
> > > > > > Yeah, can confirm that it breaks with the latest macos update.
> > > > > > I haven't found the cause yet but I think it breaks at a lower
> > > > > > layer,
> > > > > > battery charge level and some other things also seem to not work
> > > > > > anymore.
> > > > >
> > > > > That makes (some) sense. The bwfm(4) device needs to be powered on
> > > > > using a GPIO pin that is managed by the SMC. The SMC also manages the
> > > > > batter charge level. So the problem is in aplsmc(4).
> > > > >
> > > > > Most of the firmwares on these machines are tied to the OS and the
> > > > > stripped down macOS installation used by the Asahi boot process comes
> > > > > with its own copy of those firmwares. So in general upgrading the
> > > > > main macOS installation will not break things. But the SMC firmware
> > > > > is an exception as that is part of the system firmware.
> > > > >
> > > > > Tobias, does Linux still work on the upgraded system?
> > > >
> > > > It does yeah. I haven't seen an obvious fix in their tree yet.
> > > > aplsmc was also my guess, if I remember correctly it even throws
> > > > an error here:
> > > > https://github.com/openbsd/src/blob/master/sys/arch/arm64/dev/aplsmc.c#L259-L264
> > >
> > > Hmm, does the diff below help?
> >
> > Sadly not, still seeing:
> > aplsmc0 at simplebus0: can't get SRAM address
>
> Finally got around to updating one of my machines.
>
> Apparently the new firmware expects us to send a command that the AP
> (that's us) is powered on. The diff below makes things work for me
> and doesn't hurt my M2 Pro Mini with older firmware.
>
> ok?
Tested on M1 Mac mini. No change in dmesg, not sure which fw version.
ok jsg@
>
>
> Index: arch/arm64/dev/aplsmc.c
> ===================================================================
> RCS file: /cvs/src/sys/arch/arm64/dev/aplsmc.c,v
> diff -u -p -r1.25 aplsmc.c
> --- arch/arm64/dev/aplsmc.c 16 Jul 2023 16:11:11 -0000 1.25
> +++ arch/arm64/dev/aplsmc.c 27 Oct 2024 22:15:50 -0000
> @@ -250,6 +250,12 @@ aplsmc_attach(struct device *parent, str
> return;
> }
>
> + error = rtkit_set_ap_pwrstate(sc->sc_rs, RTKIT_MGMT_PWR_STATE_ON);
> + if (error) {
> + printf(": can't set AP power state\n");
> + return;
> + }
> +
> error = rtkit_start_endpoint(sc->sc_rs, SMC_EP, aplsmc_callback, sc);
> if (error) {
> printf(": can't start SMC endpoint\n");
>
>
