On Fri, Sep 11, 2026 at 06:14:48PM +0200, Jeremie Courreges-Anglas wrote:
> On Sat, Sep 12, 2026 at 12:24:02AM +1000, Jonathan Gray wrote:
> > On Fri, Sep 11, 2026 at 02:41:21PM +0200, Jeremie Courreges-Anglas wrote:
> > > On Sat, May 16, 2026 at 04:32:22PM +0200, Jeremie Courreges-Anglas wrote:
> > > >
> > > > Most of the milk-v jupiter machines I have start to exhibit the same
> > > > behavior after some time:
> > > >
> > > > [...]
> > > > smtpmic0: can't read register 0x1d
> > > > smtpmic0: can't write register 0x1d
> > > > WARNING: can't update clock chip time
> > > > smtpmic0: can't read register 0x1d
> > > > smtpmic0: can't write register 0x1d
> > > > WARNING: can't update clock chip time
> > > > etc etc
> > > >
> > > > so the RTC isn't updated hourly, but later at reboot:
> > > >
> > > > smtpmic0: can't read register 0x1d
> > > > smtpmic0: can't write register 0x1d
> > > > WARNING: can't update clock chip time
> > > > syncing disks... done
> > > > smtpmic0: can't read register 0x1d
> > > > smtpmic0: can't write register 0x1d
> > > > WARNING: can't update clock chip time
> > > > xhci0: halt timeout
> > > > xhci0: halt timeout
> > > > xhci0: reset timeout
> > > > rebooting...
> > > > smtpmic0: can't read register 0x7e
> > > > smtpmic0: can't write register 0x7e
> > > > reboot failed; spinning
> > > >
> > > > oops. Looking at the conserver logs I see these messages may appear
> > > > 1h+ up to 48h+ after boot. No idea what is going on.
> > >
> > > Some more data:
> > > - is it a big deal for me since an affected machine can't reboot and
> > > that means the machines in Theo's basement
> > > - it happens whether the machines are idle or busy
> > >
> > > The dumb diff below reliably fixes clock setting and reboots. Maybe
> > > there's a better way but my more complex attempts have failed and I've
> > > been sitting on this since months.
> > >
> > > Thoughts? ok?
> >
> > The SpacemiT documentation for ICR IUE has:
> > "Software must ensure the I2C bus is idle before setting this bit."
>
> Gah, how did I manage to miss this...
>
> > which is ISR IBB
> > "I2C Bus Busy.0 = I2C bus is idle"
> >
> > untested as I don't have the hardware
>
> Currently testing this, thanks.
Alas this doesn't fix my problem.
OpenBSD/riscv64 (jupiler.leard.wxcvbn.org) (console)
login: smtpmic0: can't write register 0x1d
WARNING: can't update clock chip time
smtpmic0: can't read register 0x1d
smtpmic0: can't write register 0x1d
WARNING: can't update clock chip time
smtpmic0: can't read register 0x1d
smtpmic0: can't write register 0x1d
WARNING: can't update clock chip time
smtpmic0: can't read register 0x1d
smtpmic0: can't write register 0x1d
WARNING: can't update clock chip time
smtpmic0: can't read register 0x1d
smtpmic0: can't write register 0x1d
WARNING: can't update clock chip time
smtpmic0: can't read register 0x1d
smtpmic0: can't write register 0x1d
[...]
seen on both my machine and riscv64.p. This is kind of expected IMO,
my diff waits unconditionally *after* setting IUE, while yours waits
for the bus being idle *before* setting IUE.
Regarding the error handling: the return value of iic_acquire_bus() is
rarely checked in the tree. I suspect we should either check its
return value in smtpmic(4), AFAIK the only driver attaching to
smtiic(4). Or maybe we should ignore the return value of
smtiic_wait_state() and always set ICR_IUE and hope for the best.
The Linux driver only check the bus/device state after setting IUE.
It does attempt resetting the bus and/or the device depending on the
error conditions it meets. But a bunch of this appears self-inflicted
since they disable a device workaround.
sigh
> > Index: sys/arch/riscv64/dev/smtiic.c
> > ===================================================================
> > RCS file: /cvs/src/sys/arch/riscv64/dev/smtiic.c,v
> > diff -u -p -r1.1 smtiic.c
> > --- sys/arch/riscv64/dev/smtiic.c 6 Apr 2026 10:30:27 -0000 1.1
> > +++ sys/arch/riscv64/dev/smtiic.c 11 Sep 2026 13:30:06 -0000
> > @@ -186,6 +186,9 @@ smtiic_i2c_acquire_bus(void *cookie, int
> > {
> > struct smtiic_softc *sc = cookie;
> >
> > + if (smtiic_wait_state(sc, ISR_IBB, 0))
> > + return EIO;
> > +
> > HSET4(sc, ICR, ICR_IUE);
> > return 0;
> > }
> >
>
> --
> jca
>
--
jca
