On Nov 20 18:03:36, [email protected] wrote:
> > Date: Fri, 18 Nov 2022 17:15:30 +0100
> > From: Mark Kettenis <[email protected]>
> >
> > > Date: Fri, 18 Nov 2022 14:36:18 +0100
> > > From: Jan Stary <[email protected]>
> > >
> > > On Nov 18 12:51:32, [email protected] wrote:
> > > > > Date: Fri, 18 Nov 2022 12:19:46 +0100
> > > > > From: Jan Stary <[email protected]>
> > > > >
> > > > > On Nov 17 14:44:59, [email protected] 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.
Thanks. I will be at my only other arm64 machnie tomorrow,
will test.
Jan
>
> 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;
> }
>
>
