On 2023-11-10, Anders Andersson <pipat...@gmail.com> wrote:
> I'm running OpenBSD on my (recently EOL) APU4 and I'm wondering how
> much of the "extra" hardware is expected to work on OpenBSD.
>
> 1) On the back of the board is a button "S1" and three status LEDs,
> The documentation says they are handled by the AMD FCH south bridge.
> Is there a way to control these in software from OpenBSD?
see gpio(4), gpioctl(8). you need to assign pins in rc.securelevel
and can then control them after boot.
while you're figuring out how to set it up in the first place, you might
want to temporarily set kern.securelevel=-1 in sysctl.conf.
> 2) There are 16 additional GPIO on a header, via the Nuvoton NCT5104D
> chip on the LPC bus. I've seen a few patches circulating that mentions
> gpio and the wbsio(4) driver but I could not figure out if anything
> has been committed or not.
AFAIK no:
DESCRIPTION
The wbsio driver provides support for the Winbond LPC Super I/O ICs.
Only the hardware monitoring function is currently supported.
> 3) There is a simple watchdog timer in the NCT5104D that can be
> connected to the reset line. Would this be implemented?
also AFAIK no.
wbsio(4) has code to probe for the device these days so it's unlikely
to be difficult for someone with an interest in such a thing to add
support for watchdog and/or gpio. Look at other superio drivers which
already have this functionality, in particular look at cvs history
from when it was added. As far as device driver coding goes, adding
GPIO/sensors/watchdog support to an existing driver for a device with
an available datasheet is fairly straightforward and doesn't need deep
coding skills.
> Would this be implemented? I'm not sure
> it's really useful, I assume there's an integrated watchdog in the
> CPU.
I don't think there's a watchdog in the cpu either.
While I've used watchdogs in the past, my feeling is that they're not
really a good fit for using with standard OpenBSD. OK so the machine
reboots, but then what? You're probably going to hit an unclean
filesystem (and if you're unlucky, it'll trigger during kernel relinking
which takes place in the background - after watchdogd has started -
which is both a time when it's more likely to happen as there's often
memory pressure, and a time when filesystems are seeing more activity
than usual). They seem better suited to a non-standard installation
which avoids RW disk mounts.
--
Please keep replies on the mailing list.
