> Date: Fri, 18 Nov 2022 17:15:30 +0100
> From: Mark Kettenis <mark.kette...@xs4all.nl>
>
> > Date: Fri, 18 Nov 2022 14:36:18 +0100
> > From: Jan Stary <h...@stare.cz>
> >
> > On Nov 18 12:51:32, mark.kette...@xs4all.nl wrote:
> > > > Date: Fri, 18 Nov 2022 12:19:46 +0100
> > > > From: Jan Stary <h...@stare.cz>
> > > >
> > > > On Nov 17 14:44:59, h...@stare.cz wrote:
> > > > > This is a freshly installed current/arm64 on a MAcBook Air,
> > > > > model 2337 (M1, 2020); full dmesg below.
> > > >
> > > > Upgrading the co-existing macOS to 12.6.1
> > > > seems to have brken the working bsd installation.
> > > > The booting bsd kernel gets to
> > > >
> > > > [...]
> > > > exuart0 at simplebus0
> > > > exuart1 at simplebus0
> > > > aplspmi0 at simplebus0
> > > > aplpmu0 at aplspmi0 sid 0xf
> > > > aplsmc0 at simplebus0
> > > >
> > > > and moves no further. Same with booting bsd.rd,
> > > > same with booting the latest one from snapshots (off a USB stick).
> > > >
> > > > Can the macOS upgrade be related? Is this known?
> > > > The macOS upgrade also switched the default boot to macOS
> > > > (while after the bsd install, the avahi boot went to bsd by default).
> > >
> > > Possible. In principle the OpenBSD install comes with its own set of
> > > Apple firmwares. But the SMC firmware (like the NVMe firmware) is
> > > stored in some sort of ROM and therefore "global". The macOS upgrade
> > > might have updated the SMC in a way that is incompatible with the
> > > aplsmc(4) driver.
> >
> > Thanks for the insight.
> > Is there something I can do to debug it?
> > Also, the line that normally follows is
> >
> > aplsart0 at simplebus0
> >
> > and some time ago there was a warning at this list
> > not to upgrade to macOS 13 specifically related to aplsart
> > - could it be that's in fact what's broken now (as opposed to SMC)?
> >
> > Jan
I managed to reproduce the issue on a 13" M1 MacBook Pro and...
> Here is a diff that changes the rtkit code to not spin forever. That
> might get you going again. You'll need to boot a kernel with this
> diff from a USB stick or something like that.
...while that diff made the machine boot, it doesn't make it usable.
But after some serious head-scratching I came up with the following
diff that does.
This will probably land in -current pretty quickly.
Index: arch/arm64/dev/aplhidev.c
===================================================================
RCS file: /cvs/src/sys/arch/arm64/dev/aplhidev.c,v
retrieving revision 1.9
diff -u -p -r1.9 aplhidev.c
--- arch/arm64/dev/aplhidev.c 9 Nov 2022 10:05:18 -0000 1.9
+++ arch/arm64/dev/aplhidev.c 20 Nov 2022 12:50:07 -0000
@@ -133,6 +133,7 @@ struct aplhidev_softc {
uint32_t *sc_gpio;
int sc_gpiolen;
+ uint8_t sc_mode;
uint16_t sc_vendor;
uint16_t sc_product;
@@ -238,7 +239,14 @@ aplhidev_attach(struct device *parent, s
break;
}
+ sc->sc_mode = APLHIDEV_MODE_HID;
aplhidev_set_mode(sc, APLHIDEV_MODE_RAW);
+ for (retry = 10; retry > 0; retry--) {
+ aplhidev_intr(sc);
+ delay(1000);
+ if (sc->sc_mode == APLHIDEV_MODE_RAW)
+ break;
+ }
printf("\n");
@@ -394,6 +402,8 @@ aplhidev_set_mode(struct aplhidev_softc
delay(100);
spi_read(sc->sc_spi_tag, (char *)&status, sizeof(status));
spi_release_bus(sc->sc_spi_tag, 0);
+
+ delay(1000);
}
int
@@ -458,6 +468,12 @@ aplhidev_intr(void *arg)
break;
}
+ return 1;
+ }
+ if (packet.flags == APLHIDEV_WRITE_PACKET &&
+ packet.device == APLHIDEV_TP_DEVICE &&
+ hdr->type == APLHIDEV_SET_MODE) {
+ sc->sc_mode = APLHIDEV_MODE_RAW;
return 1;
}
